- Arch-general - lists.archlinux.org

[arch-general] FYI: PPPoE with ppp script
by Damjan Georgievski 27 Feb '10

27 Feb '10

This is a script I use to connect to PPPoE with plain pppd... it expects the corresponding variables: INTERFACE, USERNAME and PASSWORD set up beforehand. /usr/sbin/pppd plugin rp-pppoe $INTERFACE \ user "$USERNAME" password "$PASSWORD" \ noipdefault noauth defaultroute default-asyncmap \ noaccomp nodeflate nopcomp novj novjccomp \ mtu 1492 mru 1492 \ lcp-echo-interval 30 lcp-echo-failure 4 I usually add either or both of " nodetach debug " at the end for more information about the status. ps. I know that the password "$PASSWORD" is not very secure (since the pass is visible in "ps ax"), but on a single user system it mostly doesn't matter. There are alternatives to that too: 1. put the password in /etc/ppp/pap-secrets and chap-secrets 2. use the "passwordfd" plugin for pppd and write the password to a specific fd 3. use the "passprompt" plugin and only enter the password on the terminal when you start pppd - no need to store the pass ever -- damjan

1 0

Re: [arch-general] [arch-dev-public] kernel 2.6.33-1
by Damjan Georgievski 27 Feb '10

27 Feb '10

> this makes me curious. how do you test this? > dmesg > dmesg-before > <upgrade and reboot> > dmesg > dmesg-after > > diff dmesg-* ? > or is there a better way? > what's the recommended approach too see "what's new" ? I usually do "dmesg -c" which clears the ring buffer, and then start testing whatever I'm testing, and now dmesg will show only the new stuff. -- damjan

1 0

Re: [arch-general] [arch-dev-public] Clean up the base group
by Pierre Chapuis 27 Feb '10

27 Feb '10

(Forked from arch-dev-public) On Fri, 26 Feb 2010 15:40:27 +0200, Roman Kyrylych <roman.kyrylych(a)gmail.com> wrote: > The following packages are questionable: > * diffutils - why it should be on every system? > * gawk - why it should be on every system? > [...] > * mailx > [...] > * vi - ok, no bikeshed thing here, but there's nano for base Those are required for Single UNIX Specification v3 conformance. However I think Arch Linux doesn't conform for other reasons anyway, and I support their removal from the base group. I always remove the 2 latter by hand after installing. -- catwell

4 3

[arch-general] ld-2.11.1.so and segfaults
by christopher floess 27 Feb '10

27 Feb '10

Hi all, I installed arch 64-bit on my t61 this weekend, and when I try to run midori or epiphany, and some other apps as well, I get midori[16445]: segfault at 8 ip 00007f0d1093d963 sp 00007fffb6e8a1e0 error 4 in ld-2.11.1.so[7f0d10933000+1e000] and epiphany[16664]: segfault at 8 ip 00007fbe5670e963 sp 00007fffff76fc10 error 4 in ld-2.11.1.so[7fbe56704000+1e000] By doing pacman -Qo /lib/ld-2.11.1.so, I get glibc, which is at version 2.11.1-1. I've tried doing pacman -Syu, but that hasn't resolved anything. I some how think this isn't a bug, but something I'm doing wrong on my end. Any pointers on how to trouble shoot this? As a final note, heres uname -a: Linux turnstile 2.6.32-ARCH #1 SMP PREEMPT Tue Feb 9 15:12:10 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux Of course, any other info is also available, just let me know what might be needed. Thanks in advance -- Chris

4 12

[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