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

[arch-dev-public] [signoff] Openswan 2.4.11-1
by Tom K 12 Feb '08

12 Feb '08

Now in testing for both archs - thanks for that, phrak. :) T.

3 3

[arch-dev-public] NFS 4 support request, opinions?
by Tobias Powalowski 09 Feb '08

09 Feb '08

Hi http://bugs.archlinux.org/task/8486 http://wiki.archlinux.org/index.php/NFSv4 required packages for core: http://aur.archlinux.org/packages.php?do_Details=1&ID=13630 http://aur.archlinux.org/packages.php?do_Details=1&ID=13625 http://aur.archlinux.org/packages.php?do_Details=1&ID=13629 nfs4-utils is not really needed it will be included in nfs-utils i think it would be a good idea to provide the users nfs4 support out of the box, i haven't used it but it seems reasonable to me. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 5

[arch-dev-public] Fwd: [signoff] bash 3.2.0330-1 and filesystem 2007.11-4
by Aaron Griffin 23 Jan '08

23 Jan '08

Please retest. This bash package overrides the previous one. Patch level updated, profile.bash added to backup=() array. Potential issue: Apparently /etc/profile is not replaced if modified. Can someone verify if this is fixed or not? I will investigate further as I fear it may be a pacman bug - if so, I'm guessing keeping etc/profile in BOTH backup arrays for the time being may fix this. filesystem changes: Setup for FHS compliant man pages - FS#8839 Claim ownership of /etc/profile from bash - FS#4766 Remove LESSCHARSET env var from /etc/profile - FS#8877 bash changes: Update patch level to 033 Remove /etc/profile from package. Move bashisms to /etc/profile.bash - FS#4766 /etc/profile was also largely revamped. Please comment on the changes there if you'd like.

5 12

[arch-dev-public] Mozilla move from testing?
by Jan de Groot 15 Jan '08

15 Jan '08

I see the todo list for mozilla -> /usr move is completed. Do we have any issues left here? I'd like to have it moved so I can update some extra applications.

3 5

[arch-dev-public] What not to do when packaging (vbetool)
by Dan McGee 13 Jan '08

13 Jan '08

Problem here: <http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/system/vbetool/PKGBUILD.diff?r…> There are about 4 revisions in a row of this, and none of them had a pkgrel bump. Our dbscripts suck, but it looks like they got messed up parsing the dependencies into the sync DB, leaving a nice little problem on my system: $ testdb missing dependency for vbetool : libx86 The package contains the correct deps (zlib and libx86), but the sync db only contains zlib. Thus, my system is "broken" at the moment. We need to be careful when it comes to this kind of situation. If you make a dependency change to a package, you must ensure you bump the pkgrel when changing the PKGBUILD. It isn't the end of the world if the end user doesn't see a built package for every pkgrel bump- that is really for our internal use anyway. -Dan

3 3

[arch-dev-public] [signoff] iputils -4
by Tobias Powalowski 10 Jan '08

10 Jan '08

Hi http://bugs.archlinux.org/task/8846 please signoff both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 6

[arch-dev-public] [signoff] syslog-ng 2.0.6-1
by Eric Belanger 08 Jan '08

08 Jan '08

In testing for both arch. Changes: upstream update, rebuilt against libol-less eventlog (close FS#8849), moved location of syslog-ng.persist from /var to /var/lib/syslog-ng, minor PKGBUILD improvements Please signoff. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

4 7

[arch-dev-public] [signoff] man-pages 2.74-1
by Andreas Radke 08 Jan '08

08 Jan '08

in testing for both architectures. just an update. -Andy

5 5

[arch-dev-public] JaDa - Scale organization (LA Linux con)
by Travis Willard 08 Jan '08

08 Jan '08

Hey guys - JaDa just sent me an email wanting to help set us up for Scale - an LA Linux convention. AFAIK we don't currently have a presence there - does anyone live in/near LA and is interested on working with him to get us going with this con? ---------- Forwarded message ---------- From: JaDa <jada(a)usalug.net> Date: Dec 20, 2007 9:27 PM Subject: Question from JaDa To: travis(a)archlinux.org JaDa from Arch Linux Forums has sent you a message. You can reply to JaDa by replying to this e-mail. The message reads as follows: ----------------------------------------------------------------------- http://www.socallinuxexpo.org/scale6x/ 2007, I helped Gael Duval with his Ulteo at the Scale5x in Los Angeles In 2008, I like to help Archlinux :) Maybe you can tell me how I can contact to organize it or forward this email to the right person! http://my.opera.com/Jada0007/blog/2007/03/21/ulteo-scale-5x http://my.opera.com/Jada0007/blog/2007/03/24/linux-astronomy JaDa ----------------------------------------------------------------------- -- Arch Linux Forums Mailer

3 4

[arch-dev-public] dependency rebuilds
by Paul Mattal 05 Jan '08

05 Jan '08

When package y depends on package x and package x is updated, there are essentially two clean ways to divide up responsibility for rebuilding dependent package(s) y: 1) the package y maintainer(s) notices package x in testing and rebuilds package y 2) the package x maintainer(s) is responsible to find all packages y and rebuilds all such packages y against the new package x I've seen many variations on how this gets handled over the last three or four years as a a developer, and we usually just try to do what makes things best for most people, but it's good to have some idea what to expect in general. We all want to do what's best for the most people, but it's not always clear what that is. A merit of #1 is that the actual maintainers of the dependent packages, who can sanity check and test the new dependency, are involved in making sure the packages get built and function correctly against the new version of dependent software. A downside is that this is likely to take some time-- the dependent package maintainers need to notice the dependency update, have time, and do the update properly. A merit of #2 is that the updates get done quickly. A disadvantage is that they may not be done correctly, possibly even introducing uncaught security holes or result in data loss. Another disadvantage is that for really core low-level packages (like glibc or even something like sqlite), the number of rebuilds is potentially huge and the likelihood of getting things wrong is even larger, and it will be increasingly hard to get people to agree to maintain those low-level packages because of the amount of work involved. How have people generally been approaching this issue and with what rationale? As a starting point, in absence of other communication, I generally expect developers to rebuild and test their own packages when their dependencies are upgraded, but perhaps I'm in the minority. I think we should be sensitive to the general number and kind of dependencies we have on packages we maintain, and make sure to put those things into testing to give other developers lots of time to rebuild and test against them, but not assume we each have sufficient knowledge and experience to rebuild any of the potentially vast spectrum of dependent packages with any reasonable certainty they will work. - P

7 11