[arch-dev-public] [signoff] shell rebuilds
Looking for a signoff for i686 for the following packages in testing: bash dash (new) hwdetect shadow filesystem Most of the updates deal with adding a new shell and a new provide (sh), and the update to shadow is to remove its dependency on coreutils which was one of our remaining circular dependencies. I'd appreciate it if someone wanted to rebuild these for x86_64- I wouldn't feel comfortable building a core package outside a chroot, which I currently do not have access to. -Dan
On Wed, 28 Nov 2007, Dan McGee wrote:
Looking for a signoff for i686 for the following packages in testing:
bash dash (new) hwdetect shadow filesystem
Most of the updates deal with adding a new shell and a new provide (sh), and the update to shadow is to remove its dependency on coreutils which was one of our remaining circular dependencies.
I'd appreciate it if someone wanted to rebuild these for x86_64- I wouldn't feel comfortable building a core package outside a chroot, which I currently do not have access to.
-Dan
I'll build the x86_64 pkg. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Nov 28, 2007 8:46 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Wed, 28 Nov 2007, Dan McGee wrote:
Looking for a signoff for i686 for the following packages in testing:
bash dash (new) hwdetect shadow filesystem
Most of the updates deal with adding a new shell and a new provide (sh), and the update to shadow is to remove its dependency on coreutils which was one of our remaining circular dependencies.
I'd appreciate it if someone wanted to rebuild these for x86_64- I wouldn't feel comfortable building a core package outside a chroot, which I currently do not have access to.
I'll build the x86_64 pkg.
Um...anyone? Otherwise I'm just going to assume they are fine by the end of today. -Dan
On Dec 2, 2007 2:56 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Nov 28, 2007 8:46 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Wed, 28 Nov 2007, Dan McGee wrote:
Looking for a signoff for i686 for the following packages in testing:
bash dash (new) hwdetect shadow filesystem
Most of the updates deal with adding a new shell and a new provide (sh), and the update to shadow is to remove its dependency on coreutils which was one of our remaining circular dependencies.
I'd appreciate it if someone wanted to rebuild these for x86_64- I wouldn't feel comfortable building a core package outside a chroot, which I currently do not have access to.
I'll build the x86_64 pkg.
Um...anyone? Otherwise I'm just going to assume they are fine by the end of today.h
That's not the way signoffs work. You CAN'T just 'assume' they are fine. You have to wait. Sorry, but it breaks the whole system otherwise. Signed off for i686 (bash, dash, shadow, hwdetect) However, question about filesystem: $ pacman -Ql filesystem filesystem /etc/arch-release filesystem /etc/crypttab filesystem /etc/fstab filesystem /etc/group filesystem /etc/gshadow filesystem /etc/host.conf filesystem /etc/hosts filesystem /etc/issue filesystem /etc/ld.so.conf filesystem /etc/motd filesystem /etc/nsswitch.conf filesystem /etc/passwd filesystem /etc/protocols filesystem /etc/resolv.conf filesystem /etc/securetty filesystem /etc/services filesystem /etc/shadow filesystem /etc/shells Isn't it supposed to have a bunch of empty directories in it too (for FHS compliance and such)? Otherwise, signed off.
On Sun, 2 Dec 2007, Travis Willard wrote:
On Dec 2, 2007 2:56 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Nov 28, 2007 8:46 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Wed, 28 Nov 2007, Dan McGee wrote:
Looking for a signoff for i686 for the following packages in testing:
bash dash (new) hwdetect shadow filesystem
Most of the updates deal with adding a new shell and a new provide (sh), and the update to shadow is to remove its dependency on coreutils which was one of our remaining circular dependencies.
I'd appreciate it if someone wanted to rebuild these for x86_64- I wouldn't feel comfortable building a core package outside a chroot, which I currently do not have access to.
I'll build the x86_64 pkg.
Um...anyone? Otherwise I'm just going to assume they are fine by the end of today.h
That's not the way signoffs work. You CAN'T just 'assume' they are fine. You have to wait. Sorry, but it breaks the whole system otherwise.
Actually, these packages were already signed off by two devs: Dan for i686 and me for x86_64. From an IRC discussion with Aaron, the devs who put the packages in testing counts as one of the two signoff. That might seem strange but it's the way it works unless the signoffs gets a better definition.
Signed off for i686 (bash, dash, shadow, hwdetect)
However, question about filesystem: $ pacman -Ql filesystem filesystem /etc/arch-release filesystem /etc/crypttab filesystem /etc/fstab filesystem /etc/group filesystem /etc/gshadow filesystem /etc/host.conf filesystem /etc/hosts filesystem /etc/issue filesystem /etc/ld.so.conf filesystem /etc/motd filesystem /etc/nsswitch.conf filesystem /etc/passwd filesystem /etc/protocols filesystem /etc/resolv.conf filesystem /etc/securetty filesystem /etc/services filesystem /etc/shadow filesystem /etc/shells
Isn't it supposed to have a bunch of empty directories in it too (for FHS compliance and such)? Otherwise, signed off.
The empty directories are in the packages (run tar -tzvf on the packages). 'pacman -Ql' doesn't list directories as they are not really owned by any packages. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Dec 2, 2007 4:30 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Sun, 2 Dec 2007, Travis Willard wrote:
That's not the way signoffs work. You CAN'T just 'assume' they are fine. You have to wait. Sorry, but it breaks the whole system otherwise.
Actually, these packages were already signed off by two devs: Dan for i686 and me for x86_64. From an IRC discussion with Aaron, the devs who put the packages in testing counts as one of the two signoff. That might seem strange but it's the way it works unless the signoffs gets a better definition.
That doesn't seem sound to me. Recall the problem when the kernel package that was uploaded had something screwy in it due to a bad transfer. Under this situation, tpowa would have 'signed off' his own upload, whoever built it for x86_64 would have signed it off for their own upload, and then the buggy package i686 would have been pushed to core. If that's how we want our signoffs, then that's fine - I'm just pointing out a possible flaw. -- Travis
On Sun, 2 Dec 2007, Travis Willard wrote:
On Dec 2, 2007 4:30 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Sun, 2 Dec 2007, Travis Willard wrote:
That's not the way signoffs work. You CAN'T just 'assume' they are fine. You have to wait. Sorry, but it breaks the whole system otherwise.
Actually, these packages were already signed off by two devs: Dan for i686 and me for x86_64. From an IRC discussion with Aaron, the devs who put the packages in testing counts as one of the two signoff. That might seem strange but it's the way it works unless the signoffs gets a better definition.
That doesn't seem sound to me. Recall the problem when the kernel package that was uploaded had something screwy in it due to a bad transfer. Under this situation, tpowa would have 'signed off' his own upload, whoever built it for x86_64 would have signed it off for their own upload, and then the buggy package i686 would have been pushed to core.
If that's how we want our signoffs, then that's fine - I'm just pointing out a possible flaw.
I agree that the packager shouldn't count as a signoff. That how I undertood it before the little discussion in IRC. IMO, the way signoff should be done to prevent any potential screw up is that 2 devs other than the packagers should signoff and that each architecture should at least be signed off once. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Dec 2, 2007 3:42 PM, Travis Willard <travis@archlinux.org> wrote:
On Dec 2, 2007 4:30 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Sun, 2 Dec 2007, Travis Willard wrote:
That's not the way signoffs work. You CAN'T just 'assume' they are fine. You have to wait. Sorry, but it breaks the whole system otherwise.
Actually, these packages were already signed off by two devs: Dan for i686 and me for x86_64. From an IRC discussion with Aaron, the devs who put the packages in testing counts as one of the two signoff. That might seem strange but it's the way it works unless the signoffs gets a better definition.
That doesn't seem sound to me. Recall the problem when the kernel package that was uploaded had something screwy in it due to a bad transfer. Under this situation, tpowa would have 'signed off' his own upload, whoever built it for x86_64 would have signed it off for their own upload, and then the buggy package i686 would have been pushed to core.
If that's how we want our signoffs, then that's fine - I'm just pointing out a possible flaw.
Hey, rather than continuing this discussion in a thread/venue it's not meant to be in: sign off i686
participants (4)
-
Aaron Griffin
-
Dan McGee
-
Eric Belanger
-
Travis Willard