Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])

2013-01-29 Thread Alexander Rødseth
It's not a given that a vi clone is the most desirable replacement. If an editor that is not a vi clone should be preferred, now or in the future, a symlink named vi looks funny. But mainly, the motivation for a thorough examination of where vi is actually used in [core] was to bring some peace of

Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])

2013-01-29 Thread Allan McRae
On 30/01/13 09:47, Alexander Rødseth wrote: > Hi, > > > 5 days have passed. > > > There are exactly 8 packages in [core] that falls back on vi. > > Why would we make all those adjustments over just putting a vi symlink in the vim package?

Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])

2013-01-29 Thread Alexander Rødseth
Hi, 5 days have passed. There are exactly 8 packages in [core] that falls back on vi. === visudo === People can either run visudo like this: # EDITOR=vim visudo Or this could be added to /etc/sudoers (possibly by default): Defaults editor=/usr/bin/vim This can be configured by the user,

Re: [arch-dev-public] Steam License

2013-01-29 Thread Gaetan Bisson
[2013-01-29 10:27:05 -0500] Daniel Wallace: > I recently received a license from steam to redistribute the bootstrap, > and modify it where required. I want to share it and ask everyones > opinion on if I could go ahead and move it back into the repos This looks good to me from a legal standpoint

Re: [arch-dev-public] Winter Cleanup of [extra]

2013-01-29 Thread Alexander Rødseth
I guess that concludes this winter's (for some part of the world) cleanup of [extra]. Thanks everyone. - Alexander

[arch-dev-public] Steam License

2013-01-29 Thread Daniel Wallace
I recently received a license from steam to redistribute the bootstrap, and modify it where required. I want to share it and ask everyones opinion on if I could go ahead and move it back into the repos, or if I should wait until the amd64 version is released.[1] YOU SHOULD CAREFULLY READ THE ENT

Re: [arch-dev-public] filesystem package

2013-01-29 Thread Allan McRae
On 29/01/13 23:18, Sébastien Luttringer wrote: > On Tue, Jan 29, 2013 at 1:31 PM, Allan McRae wrote: >> On 29/01/13 22:24, Xyne wrote: Yup. For post_upgrade we can depend on 'base' being installed. >>> >>> Why are you assuming anything? If those packages are needed, why not make >>> them >>>

Re: [arch-dev-public] filesystem package

2013-01-29 Thread Sébastien Luttringer
On Tue, Jan 29, 2013 at 1:31 PM, Allan McRae wrote: > On 29/01/13 22:24, Xyne wrote: >>> Yup. For post_upgrade we can depend on 'base' being installed. >> >> Why are you assuming anything? If those packages are needed, why not make >> them >> explicit dependencies? >> >> I don't see how that turn

Re: [arch-dev-public] filesystem package

2013-01-29 Thread Allan McRae
On 29/01/13 22:24, Xyne wrote: > Tom Gundersen wrote: > >>> , and then make glibc depend on >>> filesystem. We can assume coreutils and bash are installed before an >>> upgrade of filesystem. >> >> Yup. For post_upgrade we can depend on 'base' being installed. > > Why are you assuming anything? I

Re: [arch-dev-public] filesystem package

2013-01-29 Thread Xyne
Tom Gundersen wrote: >> , and then make glibc depend on >> filesystem. We can assume coreutils and bash are installed before an >> upgrade of filesystem. > >Yup. For post_upgrade we can depend on 'base' being installed. Why are you assuming anything? If those packages are needed, why not make the

[arch-dev-public] Signoff report for [testing]

2013-01-29 Thread Arch Website Notification
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 11 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 12 fully signed off packages * 17 packages missing signoffs * 6 packages older than 14 days (Note: