- Arch-general - lists.archlinux.org

[arch-general] mkinitcpio 0.6.3-1 and raid hook
by Mathieu Clabaut 27 Feb '10

27 Feb '10

It looks like mkinitcpio.conf till mention the "raid" hook whereas it looks like it has been superseded by "mdadm" hook.... Indeed : >>> Generating initial ramdisk, using mkinitcpio. Please wait... ==> Building image "default" ==> Running command: /sbin/mkinitcpio -k 2.6.32-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img :: Begin build :: Parsing hook [base] :: Parsing hook [udev] :: Parsing hook [autodetect] :: Parsing hook [pata] :: Parsing hook [scsi] :: Parsing hook [sata] FATAL: Hook 'raid' can not be found. But replacing "raid" by "mdadm" leads to : # /sbin/mkinitcpio -k 2.6.32-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img :: Begin build :: Parsing hook [base] :: Parsing hook [udev] :: Parsing hook [autodetect] :: Parsing hook [pata] :: Parsing hook [scsi] :: Parsing hook [sata] :: Parsing hook [mdadm] Custom /etc/mdadm.conf file will be used in initramfs for assembling arrays. :: Parsing hook [keymap] :: Parsing hook [encrypt] :: Parsing hook [lvm2] :: Parsing hook [resume] :: Parsing hook [filesystems] :: Generating module dependencies :: Generating image '/boot/kernel26.img'...SUCCESS -Mathieu

1 0

Re: [arch-general] [arch-dev-public] Samba package sizes
by Rogutės Sparnuotos 27 Feb '10

27 Feb '10

Dan McGee (2010-02-26 19:09): > Guys, does anyone else think this is getting out of hand? <...> > Seriously, 45 f-ing MB for samba? How can that be possible? <...> Samba is growing up fast. It is long known upstream ( http://bugs.debian.org/474543 ) and already anecdotal: http://lists.samba.org/archive/samba/2009-December/152549.html -- -- Rogutės Sparnuotos

3 2

Re: [arch-general] [arch-dev-public] Fwd: FS#17503: [unzip] zsh completion missing for unzip patches
by Xavier Chantry 26 Feb '10

26 Feb '10

On Fri, Feb 26, 2010 at 8:20 PM, Thayer Williams <thayerw(a)gmail.com> wrote: > > Bumping this for feedback. 7z correctly unzips localized win32 zip > files, but bsdtar/unzip cannot. Is that good enough to remove the > conflicting win32 patches from unzip? > Links to feature request for adding support to bsdtar / unzip would be good. If I understand correctly, there should already be some for unzip. And what about bsdtar ?

2 1

[arch-general] Postfix Package Upgrade
by Carlos Williams 26 Feb '10

26 Feb '10

I was curious how a user like myself can find out when the 'Postfix' package from Arch Linux will be upgraded from 2.6.5 to 2.7.0? Is there a way I can see the release schedule or a round about guess-tamite as to when it will be released?

4 7

Re: [arch-general] [arch-dev-public] Clean up the base group
by Leandro Inacio 26 Feb '10

26 Feb '10

On Fri, Feb 26, 2010 at 10:03, Allan McRae <allan(a)archlinux.org> wrote: > On 26/02/10 22:31, Thomas Bächler wrote: > >> Am 26.02.2010 10:28, schrieb Allan McRae: >> >>> HI, >>> >>> I mentioned this several months ago and got no response so I will post >>> again. If there are no objections in 48 hours, the rebuilds will start >>> hitting [testing]. >>> >>> FS#12890 suggests cleaning some of the packages from the base group. >>> The goals are to remove old packages that are really no longer needed >>> (e.g. cpio) and packages that are only needed as dependencies for other >>> packages and would not be installed otherwise (e.g. libfetch). That >>> will clean up the package selection list for the base group in the >>> installer. >>> >>> Here is the list of what I will do: >>> http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup >>> It splits the packages in the base group into those staying in base; >>> those removed from base but staying in [core]; those removed from >>> [core]. Packages marked with (???) mean I am not sure what category to >>> put them in. If there are no comments, I will be playing it safe with >>> these. >>> >> >> We don't need rp-pppoe in base (IMO not even in core, but others >> disagree). >> > > I'll flag it for removal from base but leave in [core] for the moment. I am > on the side that thinks it is probably best to keep this on the installer. > :P > > > We should also remove wpa_supplicant from base. My plans were to create >> a new "base-networking" and "base-wireless" group. The base-wireless >> group would (among others) cover wpa_supplicant. >> > > I will leave wpa_supplicant in base until such a group is created. > > Cheers, > Allan > I guess that a group for related network packages in base-network seems reasonable and less confusing at time of installation. Another group as base-support for other packages that are "loose" within the core, at least in the installation, so you know there are other packages to be selected or not. -- Leandro Inácio

1 0

Re: [arch-general] [arch-dev-public] Clean up the base group
by Heiko Baums 26 Feb '10

26 Feb '10

Am Fri, 26 Feb 2010 13:31:36 +0100 schrieb Thomas Bächler <thomas(a)archlinux.org>: > We don't need rp-pppoe in base (IMO not even in core, but others > disagree). I disagree because configuring a pppoe client with pure ppp is far too complicated. For people who haven't got a router and establish their DSL connections directly from their PC it's much easier to configure the pppoe client and establish the connections with rp-pppoe than with pure ppp. I tried both and reverted very fast to rp-pppoe. And because configuring and establishing the DSL connections is an essential task and also necessary on the LiveCD I think that rp-pppoe needs to stay in [core] and in the base group. Greetings, Heiko

2 1

Re: [arch-general] [arch-dev-public] Clean up the base group
by Heiko Baums 26 Feb '10

26 Feb '10

Am Fri, 26 Feb 2010 19:28:24 +1000 schrieb Allan McRae <allan(a)archlinux.org>: > I mentioned this several months ago and got no response so I will > post again. If there are no objections in 48 hours, the rebuilds > will start hitting [testing]. > > FS#12890 suggests cleaning some of the packages from the base group. > The goals are to remove old packages that are really no longer needed > (e.g. cpio) and packages that are only needed as dependencies for > other packages and would not be installed otherwise (e.g. libfetch). > That will clean up the package selection list for the base group in > the installer. > > Here is the list of what I will do: > http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup > It splits the packages in the base group into those staying in base; > those removed from base but staying in [core]; those removed from > [core]. Packages marked with (???) mean I am not sure what category > to put them in. If there are no comments, I will be playing it safe > with these. > > Any comments before I start? cpio is probably not necessarily needed by the average user, but as far as I know it's needed to uncompress or read the content of the initrd (e.g. xzcat kernel26.img | cpio -t), which sometimes can be necessary for debugging purposes. So I'm not sure if cpio must be kept in the base group but it should stay in [core]. And cryptsetup definitely needs to stay in [core] and in the base group because this is needed for encrypting hard disks, which is supported by AIF anyway. And cryptsetup is needed at boot time and during the installation from the LiveCDs. This is an essential tool which mustn't be removed from the base group and from [core]. And I'm not sure if cracklib should be removed from [core]. If it's moved to [extra] then this may be an option. Greetings, Heiko

3 4

[arch-general] Unable to upgrade
by Nilesh Govindarajan 25 Feb '10

25 Feb '10

See this guys - http://dpaste.com/157512/ All of you're facing the same ? If not, what's the fix ? -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com

14 19

[arch-general] init showing as ini
by gt 25 Feb '10

25 Feb '10

Hi guys, this has been known for a while, that init shows as ini. http://bugs.archlinux.org/task/15362 Now that we have ditched klibc, can this bug be fixed now?

1 1

Re: [arch-general] [arch-dev-public] [PATCH 4/4] ftpdir-cleanup: lock repo before doing the cleanup
by Evangelos Foutras 25 Feb '10

25 Feb '10

On Thu, Feb 25, 2010 at 3:36 AM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: <snip> > for arch in ${ARCHES[@]}; do > > + IS_LOCKED=0 > + count=0 > + while [ $count -le $LOCK_TRIAL ]; do > + if repo_lock $reponame $arch ; then > + IS_LOCKED=1 > + let count=$LOCK_TRIAL+1 > + continue I'd just use a 'break' here, instead of making the conditional expression false and jumping to the check again. > + fi > + sleep $LOCK_DELAY > + let count=$count+1 > + done > + > + if [ $IS_LOCKED -eq 0 ]; then <snip> Thanks for creating this patch. :)

2 1