- Arch-dev-public - lists.archlinux.org

[arch-dev-public] [signoff] util-linux-ng-2.14.2-1
by Tobias Powalowski 12 Mar '09

12 Mar '09

Hi update to latest version, please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] dhcpcd 4.0.12-1
by Ronald van Haren 12 Mar '09

12 Mar '09

Hi devs, Please signoff dhcpcd 4.0.12-1 for both architectures. Changes include: - bump to latest point release - add upstream patch [1] which will be included upstream in next point release Thanks, Ronald [1] http://roy.marples.name/projects/dhcpcd/changeset/1248

3 2

[arch-dev-public] Linuxtag 2009
by Tobias Powalowski 11 Mar '09

11 Mar '09

Hi guys, just saw this http://www.linuxtag.org:80/2009/ 24. till 27. June in Berlin. anyone interested in having a booth there? greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 5

[arch-dev-public] move hddtemp to extra
by Andreas Radke 11 Mar '09

11 Mar '09

I'd like to move hddtemp from community to extra. It's of quiet high usage according to http://www.archlinux.de/?page=PackageStatistics and I'd like to use it for Xfce4-sensors-plugin to be able to show hdd temps in the panel. I have some small improvements for both packages done locally and they work well together here showing two hard drives in the panel. Any objections? -Andy

5 9

[arch-dev-public] adding xdelta3 to repo
by Allan McRae 11 Mar '09

11 Mar '09

Hi, I am going to add xdelta3 to the repos. It is a separate developmental branch to xdelta(1) that has recently been declared stable. xdelta3 can be installed alongside xdelta and following other distros it is probably best to have this as a separate package. Finally, xdelta3 is needed for the reworked delta implementation in pacman. Thanks for you lack of objection... Allan

2 1

Re: [arch-dev-public] [arch-general] [signoff] syslog-ng-3.0.1-1
by Allan McRae 11 Mar '09

11 Mar '09

Gerardo Exequiel Pozzi wrote: > Tobias Powalowski wrote: > >> Am Mittwoch 11 März 2009 schrieb Allan McRae: >> >> >>> Gerardo Exequiel Pozzi wrote: >>> >>> >>>> Pierre Schmitz wrote: >>>> >>>> >>>>> Does anybody know what this message in dmesg is about? Was syslog-ng >>>>> compiled for i686? >>>>> >>>>> warning: `syslog-ng' uses 32-bit capabilities (legacy support in use) >>>>> >>>>> >>>> Very out-of-date libcap, not only syslog-ng, also proftpd, vsftpd, >>>> pulseaudio, ntpd, virtualbox, etc, etc... >>>> >>>> http://www.archlinux.org/packages/extra/i686/libcap/ (for linux 2.4) >>>> >>>> Need to have libcap2 package for kernel 2.6 in Arch Linux >>>> http://www.kernel.org/pub/linux/libs/security/linux-privs/ >>>> >>>> >>> I was confused about this as libcap is in [extra] so how can it make >>> problems with a package in [core]? >>> >>> So going from this comment in the bug report about libcap >>> (http://bugs.archlinux.org/task/11917#comment41046) I get... >>> >>> >>> >>>> readelf -s /usr/sbin/syslog-ng | grep cap >>>> >>>> >>> 33: 00000000 0 FUNC GLOBAL DEFAULT UND capset(a)GLIBC_2.1 (4) >>> 177: 00000000 0 FUNC GLOBAL DEFAULT UND capget(a)GLIBC_2.1 (4) >>> 473: 08228bd8 4 OBJECT GLOBAL DEFAULT 26 OPENSSL_ia32cap_P >>> >>> Looks like libcap is a soft dep there. How? >>> >>> Then rebuild in clean chroot: >>> >>> >>>> readelf -s syslog-ng | grep cap >>>> >>>> >>> 467: 08221b18 4 OBJECT GLOBAL DEFAULT 26 OPENSSL_ia32cap_P >>> >>> And then the dmesg warning goes away... So, the lesson to learn is to >>> _always build in a clean chroot_! >>> >>> Allan >>> >>> >> hrm i normally build in chroots, seems somehow this one slipped into it. >> Shall i add it as makedepend? >> >> >> > Yes, is a makedepends, capget, capset are glibc symbols. > > But these symbols are defined in sys/capability.h (that are part of > libcap) don't confuse with linux/capability.h > > So you can make syslog-ng with capabilities, and don't have libcap > installed. ;) > > See libc.so ;) > # readelf -s /lib/libc.so.6 | grep cap > 1745: 000d10e0 67 FUNC GLOBAL DEFAULT 11 capset@@GLIBC_2.1 > 1923: 000d1090 67 FUNC GLOBAL DEFAULT 11 capget@@GLIBC_2.1 > 3801: 000d1090 67 FUNC LOCAL DEFAULT 11 __GI_capget > 4043: 000d10e0 67 FUNC LOCAL DEFAULT 11 __GI_capset > 5388: 000d10e0 67 FUNC GLOBAL DEFAULT 11 capset > 6337: 000d1090 67 FUNC GLOBAL DEFAULT 11 capget > > > Allan: I hope you have cleared up the confusion. > Not really..... so I did some research. Here we go: From the release announcement for syslog-ng OSE 3.0: * support for capabilities under Linux, this running syslog-ng as non-root is possible, also with reload support, see the documentation of Linux capabilities in capabilities(7), for the syntax of the --caps option, see cap_from_text(3) And from capabilities(7): For the purpose of performing permission checks, traditional Unix implementations distinguish two categories of processes: /privileged/ processes (whose effective user ID is 0, referred to as superuser or root), and /unprivileged/ processes (whose effective UID is non-zero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process's credentials (usually: effective UID, effective GID, and supplementary group list). So my conclusion is that it would probably be a good idea to add the makedepends on libcap. Allan

2 1

[arch-dev-public] Integrity Check x86_64 06-03-2009
by repomaint＠archlinux.org 11 Mar '09

11 Mar '09

======================================== = Integrity Check x86_64 of core,extra = ======================================== Performing integrity checks... ==> parsing pkgbuilds ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking for circular dependencies Missing Dependencies ---------------------- archboot --> 'netkit-telnet>=0.17-8' archboot --> 'wlan-ng26>=0.2.9-2' archboot --> 'atl2>=2.0.5-2' Missing Makedepends --------------------- crda --> 'python-m2crypto' wpa_supplicant --> 'kernel26<2.6.28' gnome-speech --> 'espeak' Repo Hierarchy for Makedepends -------------------------------- core/sqlite3 depends on extra/tcl core/iputils depends on extra/opensp core/iputils depends on extra/libxslt core/iputils depends on extra/docbook-xsl core/madwifi-utils depends on extra/sharutils core/e2fsprogs depends on extra/bc core/ca-certificates depends on extra/ruby core/madwifi depends on extra/sharutils Circular Dependencies ----------------------- gcc-gcj>eclipse-ecj>gcc-gcj Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 6 Repo hierarchy problems: 8 Circular dependencies: 1

5 6

Re: [arch-dev-public] [arch-general] [signoff] syslog-ng-3.0.1-1
by Allan McRae 11 Mar '09

11 Mar '09

Gerardo Exequiel Pozzi wrote: > Pierre Schmitz wrote: > >> Does anybody know what this message in dmesg is about? Was syslog-ng compiled >> for i686? >> >> warning: `syslog-ng' uses 32-bit capabilities (legacy support in use) >> >> >> > Very out-of-date libcap, not only syslog-ng, also proftpd, vsftpd, > pulseaudio, ntpd, virtualbox, etc, etc... > > http://www.archlinux.org/packages/extra/i686/libcap/ (for linux 2.4) > > Need to have libcap2 package for kernel 2.6 in Arch Linux > http://www.kernel.org/pub/linux/libs/security/linux-privs/ > I was confused about this as libcap is in [extra] so how can it make problems with a package in [core]? So going from this comment in the bug report about libcap (http://bugs.archlinux.org/task/11917#comment41046) I get... > readelf -s /usr/sbin/syslog-ng | grep cap 33: 00000000 0 FUNC GLOBAL DEFAULT UND capset(a)GLIBC_2.1 (4) 177: 00000000 0 FUNC GLOBAL DEFAULT UND capget(a)GLIBC_2.1 (4) 473: 08228bd8 4 OBJECT GLOBAL DEFAULT 26 OPENSSL_ia32cap_P Looks like libcap is a soft dep there. How? Then rebuild in clean chroot: > readelf -s syslog-ng | grep cap 467: 08221b18 4 OBJECT GLOBAL DEFAULT 26 OPENSSL_ia32cap_P And then the dmesg warning goes away... So, the lesson to learn is to _always build in a clean chroot_! Allan

2 2

[arch-dev-public] new vi/vim/gvim
by Tobias Kieslich 11 Mar '09

11 Mar '09

Hi guys, just thought I'll let you know that the vi/vim/gvim layout will change again. After some slightly heated discussion and some thinking, I came to the conclusion that we could benefit from some different layout. I'll spare you all the reasons, here is some reading if you are really into it: http://bugs.archlinux.org/task/13109 http://bugs.archlinux.org/task/13239 http://bugs.archlinux.org/task/13240 The new layout is pretty much settled: nvi/core, provides vi,ex and view binary, really tiny vim/extra, only perl support, provides runtime, no X, no whistles gvim/extra, perl,python+ruby and gtk2, depends on vim, replaces the vim binary(as symlink) on install so your terminal vim is more powerful Benefits: - changes of (n)vi in core don't stall vim updates in extra - no vi runtime in core cuts down the install size (about 8MB compressed, 28 deflated) - we have a truely lightweight vim, it's something people really seem to want things left to figure out: I really, really hope the gvim package provides a binary that can be started as vim and runs in a terminal on a computer with no X/gtk2 installed ... I doubt it though. The reason is that I like to provide a fully scriptable vim for sysadmins that requires no X/GTK. Otherwise I could build the vim package with perl AND python support. It's not a big deal but it bumps the binary size from 1.5 MB to 4.5 ... that pretty big. Thoughts, opinions, complaints? -T

3 4

[arch-dev-public] [signoff] pam-1.0.4-1
by Tobias Powalowski 10 Mar '09

10 Mar '09

Hi update to latest version, please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 3