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

[arch-dev-public] WARNING: mkinitcpio 0.5.99.3 (kill-klibc) live in testing!
by Thomas Bächler 11 Feb '10

11 Feb '10

Okay, this is it. The busybox-based mkinitcpio is entering testing now. BACK UP YOUR OLD (WORKING) INITRAMFS (kernel26.img) FILE! Also, do NOT use this if you have root on NFS, it is NOT IMPLEMENTED yet. Known issues: If you use 2.6.33 and enable the support for ext2/ext3 in the ext4 driver, root on ext2/3 won't work with the autodetect hook, I'll fix that for the next version. Number of systems that failed to boot after the upgrade: 0 (so far) Hooks adjusted: All base hooks + keymap, encrypt, lvm2, mdadm, dmraid, raid (now a symlink to mdadm), v86d. (Also, I hear that the uresume hook works without modification). I am still looking for someone to implement NFS root with this, please contact me if you are interested. This will not be the final version, there is still some work to do, but for now this requires more testing.

9 14

[arch-dev-public] [signoff] udev-151-3
by Tobias Powalowski 11 Feb '10

11 Feb '10

Hi guys, just removed base group from udev-compat please signoff both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] makechrootpkg without aufs2
by Pierre Schmitz 11 Feb '10

11 Feb '10

Hi devs, I always had problems with aufs2 but during the recent rebuilds and KDE development it really annoyed me. It seems the aufs2 kernel module triggers all kinds of (not) so funny errors; especially on high I/O. E.g. building kdebase-workspace with makechrootpkg is a good idea to check i your filesystem or raid correctly recovers from a hard crash. Aside from FS and RAID errors I had funny segfaults of umount on reboot, massive system slowdowns etc.. In general I like the approach of makechrootpkg. Starting from a clean base chroot environment is a good idea to avoid all kinds of packaging issues. So I checked what other options there are. I thought it would be less problematic if it could be handled in userspace. There are solutions like unionfs-fuse; but unfortunately they are quite slow and cannot handle all kinds of special fiels we need (fiofos etc.) In the end I found a much simpler and cleaner way to handle this. All we want is to build our package in a clean chroot and revert all changes when building the next package. So why not just make just a copy of our base system, work on that and revert it when we are done. This can be easily done by changing this in makechrootpkg: mount -t aufs none -o "dirs=$chrootdir/$LAYER=rw:$chrootdir/root=ro" "$uniondir" to rsync -a --delete --progress -h -c -W "$chrootdir/root/" "$uniondir" On my system this sync takes less than 40 seconds in worst case (if uniondir is empty). On the other hand building the package is faster because there is no aufs overhead. And the best thing is that this cannot crash and freeze your system. :-) Pierre PS: We should probably get rid of aufs and merge this change into our devtools. -- Pierre Schmitz, https://users.archlinux.de/~pierre

5 14

[arch-dev-public] [PATCH] Move build logs to WORKDIR, otherwise they're lost
by Francois Charette 11 Feb '10

11 Feb '10

--- makechrootpkg | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/makechrootpkg b/makechrootpkg index e48db6f..80b5e16 100755 --- a/makechrootpkg +++ b/makechrootpkg @@ -254,6 +254,11 @@ if mkarchroot -r "/chrootbuild" "$uniondir"; then mv "$f" "${WORKDIR}" fi done + + if [ -f $uniondir/build/*-build.log ]; then + echo "Moving build log(s) to ${WORKDIR}" + mv $uniondir/build/*-{build,package}.log* "${WORKDIR}" + fi else #just in case. We returned 1, make sure we fail touch "${chrootdir}/union/build/BUILD_FAILED" -- 1.6.6.1

4 5

[arch-dev-public] package signoffs
by Jan de Groot 10 Feb '10

10 Feb '10

These days it looks like almost nobody in our developer team uses i686 anymore. I still have a laptop running it, but I barely use it. I think it's time to revise our signoff policy. I was thinking about making it a bit more flexible: - signoff by 3 devs, no matter what architecture, and no bugs within 3 days -> move - signoff for both architectures, 2 each -> move - no signoff, no bugs for a week -> move For the last thing to get implemented, this can be a bit tricky. Sometimes developers throw something in testing, just to test something, and it sits there for weeks without anyone knowing why it's in testing. I would like to have every package that goes to testing getting committed with a reason in the commit message. This way we can find out why something is in testing and if we can easily move it out without breaking things.

8 13

[arch-dev-public] My status
by Firmicus 10 Feb '10

10 Feb '10

Hello all, Given the current discussion, I believe it is appropriate for me to provide a status update as far as my role within the Arch community is concerned. As a father of three (soon four!) I don't have much time at my disposal, and would like to concentrate the little I have on other open-source projects I am involved in. But I am well-aware that stepping down right now would leave you with yet another bunch of orphan packages, including the texlive-* ones, which is really not what you guys need at this moment. I am thus proposing this: I'll stay on board and will continue maintaining my stuff until we have found someone who is ready to take up maintainance of the texlive packages. I have written a collection of helper scripts for this purpose which are publically available on our projects page. Of course I'd also be available for help. So that should be feasible by anyone who uses TeX Live already, knows its internals moderately well (configuration files and tools, web2c, kpathsea, etc), and is not afraid of complex build processes. I hope this can be achieved within the next, say, six months, but hopefully sooner, since our baby is expected early April and I won't have much time in the three months thereafter. Ideally that person should be one of you, which would make things very easy, but I don't think this is realistic, given the workload you already have. There is also the possibility of moving the texlive pkgs back to community if a TU is interested, but I'd really prefer they stay in extra. In other words, you can still count on me, but not for too long ;) In the meanwhile, if anyone is interested in a particular package I maintain, just ask and I'll orphan it. Regards, François

3 4

[arch-dev-public] [PATCH] Move build log to WORKDIR, otherwise it is lost
by Francois Charette 10 Feb '10

10 Feb '10

--- makechrootpkg | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/makechrootpkg b/makechrootpkg index e48db6f..06877b0 100755 --- a/makechrootpkg +++ b/makechrootpkg @@ -254,6 +254,11 @@ if mkarchroot -r "/chrootbuild" "$uniondir"; then mv "$f" "${WORKDIR}" fi done + + if [ -f $uniondir/build/*-build.log ]; then + echo "Moving build log to ${WORKDIR}" + mv $uniondir/build/*-build.log "${WORKDIR}" + fi else #just in case. We returned 1, make sure we fail touch "${chrootdir}/union/build/BUILD_FAILED" -- 1.6.6.1

3 2

[arch-dev-public] Fwd: Re: Fwd: Perl packaging guidelines.
by Firmicus 09 Feb '10

09 Feb '10

[Forwarding this from Xyne] > This is an area where I have a pretty solid experience, as as perl dev, > arch user, and maintainer of several perl packages in extra and > community. I tend to agree with Allan here. We should only package and > take into consideration what on CPAN is called a distribution, i.e. a > tarball containing a bunch or related perl modules. The mapping between > modules and distributions is available in a plain text database on each > CPAN mirror, and can be figured out by the common tools used to install > cpan stuff from the command-line (cpan and cpanp). I think it is quite a > BAD idea to put all module names in the provides array, as this can > easily yield hundreds of elements without obvious advantage I can think > of. Our poor lil Pacman has better things to do than take that overload > into account. Is the overhead even significant? How expensive are PROVIDES lookups? (Coincidentally, I've thought for a while now that there should be a single PROVIDES list for the local database to avoid opening hundreds of files unnecessarily, even if that is quite fast). What about when distributions change their module roster? This has happened before and will happen again. I see robust dependency resolution as an "obvious advantage". If any important modules ever get moved around (e.g. subsumed into the base distribution from a popular module), then all packages which depend on that module would need to update their depends array. The fact that META.yml files for distributions on CPAN specify modules and not distributions shows that the dependencies are actually the modules themselves. Ignoring upstream convention and Pacman's built-in capabilities to shave a little bit of time off of a PROVIDES lookup doesn't right to me, especially when you factor in the potential dependency breakage, however unlikely that is to affect large distributions. > That said, I do acknowledge Xyne's effort! I have written a very similar > tool years ago, which is still available in AUR (perl-cpanplus-pacman), > but for which I have alas not dedicated as much effort and commitment as > Xyne did with pacpan. My own approach has however inspired another > project, called perl-cpanplus-dist-arch (also in AUR), which IMHO is > superior to both my own cpan4pacman and Xyne's pacpan. (That said I > still use cpan4pacman (together with a few helper shell scripts and the > devtools) to maintain my own local repository of 550 CPAN packages, all > of which I keep uptodate with relative ease). I've looked at perl-cpanplus-dist-arch while rewriting the pacpan backend. I found the entire CPANPLUS backend to be overkill for creating Pacman packages. Pacpan uses the same files and gets the same results, but without the CPAN shell and other bells and whistles that have no significance for Pacman packaging. That said, if there are particular features that perl-cpanplus-dist-arch has that pacman lacks, let me know which and I will consider adding them. If that project does show itself to be superior for Pacman packaging then I probably switch the backend over to it, but so far the current backend works as expected and is fairly simple with no external dependencies. Two follow-up questions: Do you at least support the idea of renaming CPAN packages with non-standard names to their standard names? If not, what about including the standard name in the provides array? If pacpan didn't include the individual modules in the arrays but instead mapped then all to their distribution, how would you see the matter then? Regards, Xyne

4 4

[arch-dev-public] New Developer: Dan Griffiths
by Aaron Griffin 09 Feb '10

09 Feb '10

I just want to shoot a welcome message to the newest member of the team: Dan Griffiths (Ghost1227). Welcome aboard!

11 13

[arch-dev-public] Setting up a dev on main site (was: New Developer: Dan Griffiths)
by Dan McGee 09 Feb '10

09 Feb '10

On Tue, Feb 9, 2010 at 12:27 PM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On Tue, Feb 9, 2010 at 12:25 PM, Daniel J Griffiths (Ghost1227) > <ghost1227(a)archlinux.us> wrote: >> On 02/09/2010 12:23 PM, Aaron Griffin wrote: >>> >>> I just want to shoot a welcome message to the newest member of the >>> team: Dan Griffiths (Ghost1227). >>> >>> Welcome aboard! >>> >>> >> >> Thank you! Glad to be here! > > I setup as much access as I recalled, so you should now be able to > adopt packages in extra (core is disabled for now), and are a > developer everywhere (forums, flyspray, wiki) > > Please read this for more info: > http://wiki.archlinux.org/index.php/DeveloperWiki:Developer_Checklist Aaron- as a side note, what is involved in setting up a developer on the main site? While I'm on my archweb kick I want to see what is required and what might be older cruft still sitting around. So I guess I'm looking for a walkthrough of whatever you did. And to the new Dan- welcome! Don't confuse anyone around here. :) -Dan

2 4