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

[arch-dev-public] [signoff] klibc stuff + mkinitcpio
by Thomas Bächler 23 Oct '09

23 Oct '09

I put new klibc, klibc-kbd, klibc-m-i-t, klibc-udev, klibc-extras and v86d to testing. Those are no version bumps, but just a rebuild of klibc against 2.6.31 with a small bugfix (see more below) - and the corresponding rebuilds for the new ABI, as with each change of build headers for klibc. mkinitcpio also needed a rebuild due to the klibc-kbd versioned dependency that was wrong - I didn't change the version here either. Signoff procedure: 1) cp /boot/kernel26.img /boot/kernel26.img.working 2) pacman -Syu 3) mkinitcpio -p kernel26 4) reboot i686 packages are completely untested, x86_64 works and boots. About the fixed bug: Recently, ps ax would display: 1 ? Ss 0:01 ini while it should (and does now) display 1 ? Ss 0:01 init [5] This confused and annoyed people. As for uclibc-initramfs: I didn't have time anymore, but last time I tried, I was unable to get the toolchain to work as I would expect. Thus, I keep maintaining klibc crap.

4 12

[arch-dev-public] [signoff] kernel26-lts 2.6.27.38-1
by Andreas Radke 23 Oct '09

23 Oct '09

next minor upstream update. please signoff. see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27.38 -Andy

1 0

[arch-dev-public] Arch Linux Status Report, 2009-10-05
by Aaron Griffin 22 Oct '09

22 Oct '09

Arch Linux Status Report, 2009-10-05 =================================== Aaron Griffin Yes, a new status report. I haven't put one of these out in some time, and a lot has happened since the last one, so bear with me here. There is a lot being left out from this, because there's simply to much to cover. We've had a lot of changes - repository oopses, server reinstalls, and things of that nature - that I simply won't be able to cover without writing a novel. == Newsworthy Items == * Bug Squashing Day We had our first bug squashing day in a long time. Thanks to everyone who helped, it makes everything so much easier. Andreas and Paul, many thanks for organizing this. More details can be found here: http://www.deelab.org/bash/2009/10/bug-squashing-day-results/ * kernel.org Tier 1 mirror I just now setup a mirror for kernel.org. The use geo dns re-routing, so it should work safely and quickly for any country. Additionally, this will get us images on boot.kernel.org eventually, which is impressive. Additionally, they have volunteered to be a tier 1 mirror so that others can rsync from them. == Completed Tasks == * Far too many to list As stated above, a lot has happened since I last wrote one of these. We've had numerous package rebuild frenzies, server reinstalls, code fixes, support for architecture independent packages, and so many more things. So, rather than try to cover all that, I just want to give my personal thanks out to all the developers and TUs. You guys are the ones who keep Arch going strong, and I appreciate all the hard work. It's amazing to see how much people actually care about a lil' ol' Linux distro like this :) == Pending Tasks, Short Term == * Web Server Hiccup Seems like we had our web domU hang on us the other night. This is the second time it has happened, and signs seem to point to it being Xen related. I would like anyone with knowledge or experience here to see if you can find anything. * Mirror Tiering Handling proper mirror tiering will give us a few benefits, the first of which being the fact that it will help us get rid of some of the "mirror not fully synced" issues. It will also help minimize our bandwidth. With the addition of the kernel.org mirror, and mirror.archlinux.no offering to be a tier 1 mirror, I think we can safely send out an email to the mirror admins, requesting a few more tier 1 mirrors. I'd say we shoot for around 5, just to pick a number. With these in place, we can begin the switch over. To do this, we'll simply: * Email all the mirror admins a list of the tier 1 mirrors * Have mirror admins chose a tier 1 mirror * Reply to us when changes are made * Remove their IPs from the DB * After a month or so, remove all IPs still pending (and keep a list of these offenders) * Replacing cron with fcron This was brought up on the ML a bit ago. It appears that most of us are in favor of using fcron to replace our existing dcron. I would like someone to spearhead this move. Any volunteers? * Ensuring Package Quality We run into package quality issues every so often. No, I'm not pointing fingers or anything, I'm guilty of this as well. I'd like to institute some way to ensure that our packages are of the proper quality before they hit the repos. Ideas are welcome. Currently, I had the following ideas in my head: * Add some token to the PKGINFO indicating that makechrootpkg was used This has the con of requiring this tool, when people may be using their own chroots or tools for this. * Make db-scripts check packages with namcap, and reject them on errors This has the con of making the db-scripts slower. * Combine the above: Add a PKGINFO token from namcap We should all be running namcap anyway * Support for community <-> extra moves I would like to get db-script support that allows developers to move packages across svn repos. This is actually fairly involved and should _try_ to include history. This should require ssh connections to each machine for a little boost of added security. Implementation details beyond this have not been thought of. * IRC Developer Meetings We used to have regularly monthly meetings in IRC, where we'd all get together and discuss things. We haven't done this in a while, and some of us have begun to feel like we don't really know each other to well. Well, let's try to change this. I'd like to schedule a developer's meeting for some time in October. I'd like to tentatively suggest Saturday the 24th. We'd all join #archlinux-dev and discuss things on the current status report at that time, and cover any other itches we have that need scratching. Please suggest times, or alternate days if needed. == Pending Tasks, Long Term == * Early-userspace in uClibc klibc has a slow development model, and it doesn't suit us too well anymore. Initially there was promise, but things have come to a near halt. As such, Thomas has proposed we switch from klibc to uClibc for our early-userspace. This is a great idea. This change should be near seamless to the users, but will require much work and testing on our part. I'm sure Thomas could use some help if anyone is interested. I believe all the packages needed are checked into the repos, but mkinitcpio needs changing and fixing. Thomas, would you mind pushing your changes to a branch somewhere? Or even to master if you're satisfied with them so far? This way we can all give you a hand. * Project TODO lists This was brought up a while ago, but I don't see a lot of follow through. For all our internal projects, I'd like to see some sort of public TODO list somewhere. If you'd like to use the bug tracker, that's fine, just add a link to the wiki page. In the Internal Projects wiki page located at: http://wiki.archlinux.org/index.php/DeveloperWiki:Internal_Projects we have lists of all the funny little things we maintain for our daily lives. I'd like to see, on this page, some indication of direction for these projects. This has already begun for the developer tools list. Pacman is most likely exempt as it is much more public and active than the other projects, unless Dan or Xavier feels like maintaining a list there :) It seems tedious, but this will actually give us something to point at when people say "How Can I Help?(TM)". * Repo symlinking This idea was put out by Jan a while ago, and I like it. It goes like this: When we put a package in the repos, we stick it in some master directory - we'll call it "packages" for now. Then a symlink is created, linking the "packages" instance of the package to an architecture specific dir. When and if this package moves repositories, the symlink is simply moved. What does this give us? The ability to easily move things from testing to core/extra without overwhelming our server during mirror sync (as mirrors will already have the packages). I think this is a great idea, and would require two things: db-scripts patches, and a script to convert our existing repo.

3 4

[arch-dev-public] [PATCH 1/3] checkpkg: Added split package support
by Eric Bélanger 22 Oct '09

22 Oct '09

Signed-off-by: Eric Bélanger <snowmaniscool(a)gmail.com> --- checkpkg | 83 ++++++++++++++++++++++++++++++++------------------------------ 1 files changed, 43 insertions(+), 40 deletions(-) diff --git a/checkpkg b/checkpkg index e9426a6..aa56c74 100755 --- a/checkpkg +++ b/checkpkg @@ -26,64 +26,67 @@ source PKGBUILD if [ "$arch" == "any" ]; then CARCH="any" fi -pkgfile=${pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT} -oldstylepkgfile=${pkgname}-${pkgver}-${pkgrel}${PKGEXT} - -if [ -f "$(pwd)/$pkgfile" ]; then - pkgfile=$(pwd)/$pkgfile -elif [ -f "$PKGDEST/$pkgfile" ]; then - pkgfile=$PKGDEST/$pkgfile -elif [ -f "$(pwd)/$oldstylepkgfile" ]; then - pkgfile=$(pwd)/$oldstylepkgfile -elif [ -f "$PKGDEST/$oldstylepkgfile" ]; then - pkgfile=$PKGDEST/$oldstylepkgfile -else - echo "File \"$pkgfile\" doesn't exist" - exit 1 -fi -tmp=`pacman -Spd --noconfirm $pkgname` +for _pkgname in ${pkgname[@]}; do + pkgfile=${_pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT} + oldstylepkgfile=${_pkgname}-${pkgver}-${pkgrel}${PKGEXT} + + if [ -f "$(pwd)/$pkgfile" ]; then + pkgfile=$(pwd)/$pkgfile + elif [ -f "$PKGDEST/$pkgfile" ]; then + pkgfile=$PKGDEST/$pkgfile + elif [ -f "$(pwd)/$oldstylepkgfile" ]; then + pkgfile=$(pwd)/$oldstylepkgfile + elif [ -f "$PKGDEST/$oldstylepkgfile" ]; then + pkgfile=$PKGDEST/$oldstylepkgfile + else + echo "File \"$pkgfile\" doesn't exist" + exit 1 + fi + + tmp=`pacman -Spd --noconfirm $_pkgname` -if [ $? -ne 0 ]; then - echo "Couldn't download previous package." + if [ $? -ne 0 ]; then + echo "Couldn't download previous package for $_pkgname." exit 1 -fi + fi -pkgurl=`echo $tmp | rev | cut -d ' ' -f 1 | rev` + pkgurl=`echo $tmp | rev | cut -d ' ' -f 1 | rev` -oldpkg=`strip_url $pkgurl` + oldpkg=`strip_url $pkgurl` -if [ "$(basename $oldpkg)" = "$(basename $pkgfile)" ]; then - echo "The built package is the one in the repo right now!" + if [ "$(basename $oldpkg)" = "$(basename $pkgfile)" ]; then + echo "The built package ($_pkgname) is the one in the repo right now!" exit 1 -fi + fi -if [ ! -f $oldpkg ]; then + if [ ! -f $oldpkg ]; then if echo $pkgurl | grep "^file:///" > /dev/null 2>&1; then - cp `echo $pkgurl | sed 's#^file://##'` . + cp `echo $pkgurl | sed 's#^file://##'` . else - wget $pkgurl + wget $pkgurl fi -fi + fi -bsdtar tf $oldpkg > filelist-old -bsdtar tf "$pkgfile" > filelist + bsdtar tf $oldpkg > filelist-$_pkgname-old + bsdtar tf "$pkgfile" > filelist-$_pkgname -sort -o filelist filelist -sort -o filelist-old filelist-old + sort -o filelist-$_pkgname filelist-$_pkgname + sort -o filelist-$_pkgname-old filelist-$_pkgname-old -diff filelist-old filelist + diff filelist-$_pkgname-old filelist-$_pkgname -if diff filelist-old filelist | grep '\.so\.' > /dev/null 2>&1; then + if diff filelist-$_pkgname-old filelist-$_pkgname | grep '\.so\.' > /dev/null 2>&1; then mkdir -p pkg cd pkg bsdtar xf "$pkgfile" > /dev/null - for i in `diff ../filelist-old ../filelist | grep \> | grep \.so\. | awk '{print $2}'`; do - echo -n "${i}: " - objdump -p $i | grep SONAME + for i in `diff ../filelist-$_pkgname-old ../filelist-$_pkgname | grep \> | grep \.so\. | awk '{print $2}'`; do + echo -n "${i}: " + objdump -p $i | grep SONAME done -else - echo "No filename differences" -fi + else + echo "No filename differences for $_pkgname." + fi +done # vim:ft=sh:ts=4:sw=4:et: -- 1.6.5.1

2 3

[arch-dev-public] [signoff] perl 5.10.1-4 both arches
by Paul Mattal 22 Oct '09

22 Oct '09

Please signoff both arches. Minor change to install scriptlet to avoid error message, closing bug #16436. - P

7 10

[arch-dev-public] The udev rule nightmare
by Thomas Bächler 22 Oct '09

22 Oct '09

So, I wanted to revisit the subject of udev rules. Right now, we have rules in /etc/udev/rules.d and /lib/udev/rules.d - the idea was that "upstream" rules goes to /lib and whatever else goes to /etc. This was interpreted by some of our own dev team that we should put whatever udev and packages ship to /lib and whatever we created ourselves to /etc - which is dumb. Right now we have: - rules from upstream packages in /lib - patched rules from upstream packages in /lib - rules from upstream packages in /etc - Arch rules in /etc It is pure chaos and nobody understands what is where and why. It is a nightmare. Back when we had the discussion, I suggested what I will re-suggest now: - All our packages should have udev rules in /lib only. What Arch officially ships is what we consider "upstream". (To put it in the same terminology that perl uses: core-rules and vendor-rules) - User or site specific rules go to /etc, overriding or complementing the "official" rule set (site-rules) This will lead to a clear distinction and a clear rule instead of the chaos we have until now. It is also the only way that makes sense, everything else will lead to the same chaos again. Please comment.

5 9

[arch-dev-public] [signoff] tzdata 2009o
by Jan de Groot 22 Oct '09

22 Oct '09

Please signoff for both architectures. Changelog: - update to 2009o (svn commit says 2009n btw) - add patch from http://bugs.archlinux.org/task/16732

2 1

[arch-dev-public] binutils-2.20 toolchain rebuild in [testing]
by Allan McRae 21 Oct '09

21 Oct '09

Hi The binutils-2.20 toolchain rebuild is in [testing] for i686. I will do the x86_64 rebuilds in the next day or two. A summary of changes: kernel-headers - bump to latest binutils - bump to latest glibc - grab upstream patchset for proposed future stable release, fix overflow bug (FS#16253), patch to build against latest binutils gcc - bump to latest, use package spitting (gcc-libs, gcc, gcc-fortran, gcc-objc), move static libraries from gcc-libs to gcc, add gcc-ada package, do not run fixincludes during build. I will call for a signoff a few days after getting the x86_64 builds done. Allan

4 8

[arch-dev-public] should be esound an optdepends?
by Andrea Scarpino 21 Oct '09

21 Oct '09

>From FS#16502: With GNOME 2.28 arriving, it's time to make esound an optional package, which is currently not the case. Here is the list of the packages which requires esound. I think for all of them that esound should be an optional dependency (except maybe enlightenment?). * bmp * cinelerra-cv * enlightenment * epplet-base * freeciv * gmerlin * gstreamer0.10-good-plugins * kvirc * kvm * libgnome * qemu * vice * xine-lib * xmms What's our decision about this? -- Andrea `bash` Scarpino Arch Linux Developer

3 3

[arch-dev-public] List of packages that could be rebuilt if you have nothing better to do...
by Allan McRae 20 Oct '09

20 Oct '09

Hi, I have created a list of packages the could use a rebuild but for which there is no hurry. These include packages without the arch in their filename, packages containing a .FILELIST file, packages with man pages in /usr/man or uncompress man and info pages. See http://wiki.archlinux.org/index.php/User:Allan/Unimportant_Rebuild_List Do people think this is useful and should I move it to the DeveloperWiki? Allan

3 4