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

[arch-dev-public] Shirts for FrOSCon
by Daniel Isenmann 12 Aug '09

12 Aug '09

Hi, I'm preparing shirts for our meeting at FrOSCon. At the moment the shop which will produce the shirt is checking the vector graphics of our logo which I have sent to him. If he accept it, I will create a shirt and send the preview of it as reply to this mail. If you want a shirt then just reply after you have seen the preview, give me your shirt size and I will bring the shirts to FrOSCon. To limit the order, this is just for the devs/helpers who will meet at FrOSCon. The logo will be http://users.archlinux.de/~pierre/arch/Artwork/archlinux-official-vertical-… large at the back of the shirt. Nothing on the front or as an alternative the logo large on the front and nothing on the back. That's because of the print method which isn't able to print small and tiny lines and to keep it relative cheap. Cheers, Daniel -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

8 24

Re: [arch-dev-public] Ohloh
by Dieter Plaetinck 12 Aug '09

12 Aug '09

On Wed, 12 Aug 2009 04:53:08 -0400 Loui Chang <louipc.ist(a)gmail.com> wrote: > On Wed 12 Aug 2009 10:16 +0200, Dieter Plaetinck wrote: > > On Wed, 12 Aug 2009 11:08:37 +0300 > > Roman Kyrylych <roman.kyrylych(a)gmail.com> wrote: > > > FYI, old Arch Linux Installer project deleted, > > > the git repo is now enlisted as part of Arch Linux project. > > > I've also added a couple of missing git repos from > > > projects.archlinux.org > > > > > > I'm unlisting the CVS repo for community from Arch Linux Packages > > > because it blocks SVN repos to be synced. > > > > > > Whenever CVS server will be up and running - let me know so I can > > > add it. > > > > > > > Hmm http://www.ohloh.net/p/arch-linux/contributors is odd. > > Something doesn't seem right there. > > > > Dieter > > Hmm. What doesn't seem right? > It puts me on top, because apparently i have most commits (which by itself I already doubt), not to mention this gives a completely wrong picture and is actually pretty useless. Dieter

5 6

[arch-dev-public] Back && [signoff] wireless-regdb
by Thomas Bächler 12 Aug '09

12 Aug '09

I didn't catch up on mailing list stuff yet (and didn't update my system yet) but I am back home. Now, I already uploaded wireless-regdb to 2009.08.05 and made it an -any package. I was confused though, does anyone know why/since when the repos/ directory in wireless-regdb is empty? The old core-{i686,x86_64} directories are missing. Anyway, please sign off on wireless-regdb (since it's an -any package, I guess that only one additional signoff is needed).

2 2

[arch-dev-public] Ohloh
by Roman Kyrylych 12 Aug '09

12 Aug '09

Hello! This is not really related to a 'real job' (sorry!) but it's quite interesting since it represents Arch on a quite large FOSS-related site, and it is actually an interesting source of statistics. As someone of you may know - there are Arch Linux related projects registered on Ohloh: * Arch Linux - most git repositories from projects.archlinux.org * Arch Linux Packages - our SVN and community CVS (we should add community SVN when it's ready, but make sure old CVS history is retained) * AUR - aur.git * Arch Linux Installer - installer.git (but not aif.git) * Pacman - pacman.git Is this structure OK or does someone have a suggestions for changes? For example, would it be better to move aif.git to Arch Linux Installer or merge installer.git into Arch Linux? (IMO 2nd way i's better). They also have Managers feature now, so it would be nice if Aaron (they suggest that it should be "Someone who works on the project. Ideally the owner, founder, lead developer, or release manager.") took management of all our projects and modified permissions to protect from vandalism. -- Roman Kyrylych (Роман Кирилич)

4 13

[arch-dev-public] vim status?
by Allan McRae 12 Aug '09

12 Aug '09

Hi, What is the current status of vim in [testing]? I would like to move the ruby-1.9 builds to [extra] at some stage but this requires the vims in [testing] to move. Allan

1 0

[arch-dev-public] Udev 145, signalfd(), and glibc with older kernels
by Dan McGee 11 Aug '09

11 Aug '09

So as has been brought up in other threads, udev 145 uses signalfd(), which unfortunately seems to be absent in older kernels. That is only half the story. >From this Debian bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537509), glibc 2.9 and later unfortunately broke compatibility with the older signalfd and eventfd syscalls that are present in all kernels after 2.6.22. A new syscall (signalfd4) was introduced in 2.6.27, and for some reason glibc decided to completely switch to this rather than be backwards-compatible. Long story short- if we apply this patch (http://patch-tracking.debian.net/patch/series/dl/eglibc/2.9-23+multiarch.2/…) from the Debian patch collection[1], we can make our glibc, and thus udev, compatible with modern-ish kernels out there and not cause unnecessary breakage for users. It should have nearly zero impact for anyone else as glibc will still prefer the new syscall. Anyone, glibc maintainer, objections or thoughts? -Dan [1] Other Debian patches: http://patch-tracking.debian.net/package/eglibc/2.9-23+multiarch.2

3 3

Re: [arch-dev-public] [arch-general] [signoff] udev-145-1
by Allan McRae 10 Aug '09

10 Aug '09

Dan McGee wrote: > On Sun, Aug 2, 2009 at 9:21 PM, Gerardo Exequiel > Pozzi<vmlinuz386(a)yahoo.com.ar> wrote: > >> Gerardo Exequiel Pozzi wrote: >> >>> Gerardo Exequiel Pozzi wrote: >>> >>> >>>> Tobias Powalowski wrote: >>>> >>>> >>>> >>>>> Hi >>>>> bump to latest udev version, please test it well. >>>>> Has many new things included, which also dig in glib2 and libusb depend. >>>>> >>>>> greetings >>>>> tpowa >>>>> >>>>> >>>>> >>>>> >>>> Sign-off both i686, x86_64. >>>> >>>> All boot OK, (custom kernel no initrd) no special setups, like raid or >>>> lvm. My usb devices are with the correct perms (4-in-1 reader, pendrive, >>>> ipod, mp3 player). The firmware for my printer is loaded OK, and kvm-88 >>>> still boot both arches (Arch Linux kernel):) >>>> >>>> >>>> One sidenote, this version support ACL, so I guess that is better now to >>>> switch /dev from ramfs to tmpfs in initscripts. (the current udev >>>> documentation talks about tmpfs not ramfs) >>>> >>>> >>>> >>>> >>> By the way, doing this also will help, at least in one step, this >>> feature request (FS#15612 - better support for selinux) [#1] >>> >>> [#1] http://bugs.archlinux.org/task/15612 >>> >>> >>> >> I filled a FS [#1] with the patch >> >> Sidenote2: This udev bump from minimal kernel version from 2.6.22 to >> 2.6.25 (mandatory) because use the signalfd(). An announce required? >> > > Wowzers, I'm not so sure we want to do that. We just got scared with > glibc from going past 2.6.18, this is a rather significant jump (and I > know my current Xen kernel is .24). > Is there a way to build udev without requiring this call? The discussions with the minimal kernel version for our glibc did not even venture beyond the .24 version... Allan

8 17

[arch-dev-public] i'm taking some days off
by Dieter Plaetinck 10 Aug '09

10 Aug '09

Hi guys, i'm taking some days off: thursday 13 - sunday 16th of august I'll be in France. 17-18 august I have off days but will probably be at home @ dev duties: I only maintain 1 package, and I'm both the upstream and downstream for it so I don't think there are much problems there ;-) (aif) @ releng: with 2009.08 behind us, i don't expect much problems. And there is no problem that Gerhard cannot solve The weekend after it I'll be at froscon in Germany where I will meet some of you guys and drink beer with my buddy Gerhard B. see http://dieter.plaetinck.be/Arch_Linux_2009.08_and_Froscon_2009 for a tiny bit more info Dieter

2 1

[arch-dev-public] Away Thurs-Sun
by Aaron Griffin 10 Aug '09

10 Aug '09

I'm heading down to Indy this weekend to win some mega nerd points (http://www.gencon.com/2009/indy/) and will not have my laptop on me. But I will be checking email via my phone (inbox only). If you need anything important, send me a direct email. Cheers, Aaron

1 0

[arch-dev-public] GNOME 2.28 - changes ahead
by Jan de Groot 10 Aug '09

10 Aug '09

There's a release of GNOME 2.27.90 scheduled for this week, which means that GNOME will enter a code freeze. This is the point where I usually pick up packaging the next major version. For GNOME 2.27/28, some things will change in the distribution: - DeviceKit-Disks (new package) - PolicyKit 1.0 replacing 0.9 - PulseAudio (new package) - Esound DeviceKit-Disks will replace the functionality that used to be provided by hal. GNOME will no longer use hal for this. I don't know about KDE, but I think they will follow soon. Hal will stay alive, but it has received deprecation status upstream, which means that only bugfixes will get applied, no new features anymore. My plans are to replace PolicyKit 0.9 with 1.0 completely. Yes, they can be installed side-by-side, but I don't like to have a deprecated policy framework on my system. Any application depending on PolicyKit needs to be ported. Fedora has patches available for most of them. In case of KDE and GNOME: both support PolicyKit 1.0 in the latest versions, KDE 4.3 and GNOME 2.27/28. The only package that I know of not supporting PolicyKit 1.0 is hal. Hal will get a special treatment: removal of PolicyKit interaction. The next version of hal will use an at_console ruleset. ConsoleKit has backwards compatibility for this. I don't want to return to the group setup we had before. Since Udev 145 will use ACLs once our initscripts mount /dev/ on tmpfs instead of ramfs, a ConsoleKit login will create ACLs for access to devices on /dev. This means users don't have to be member of any group to listen to sound, use DRI or write CDs once this is changed. Enforcing group membership to hal users would be a stupid thing to do then. Then there's PulseAudio. Though I still don't feel the need for this one on the systems I own, a lot of users have requested this. PA has matured a lot in the meanwhile, and PA is more than just an ordinary ESD replacement. Another issue is ESD. This package is not really maintained upstream anymore, and I don't think it makes sense to have two sound servers as dependency for one desktop. Given the fact that Fedora disables esound support since 2.23.4, I think it won't be a problem to remove it from the dependency chain. Esound will stay in the repositories, but won't be used by GNOME as sound server anymore.

3 3