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

[arch-dev-public] request: remove mailx from Core
by Roman Kyrylych 10 Jan '08

10 Jan '08

Hi! logrotate-3.7.5-1 no longer depends on mailx (FS#6911) and no other package in Core does. FS#4812 says that mailx should depend on smtp-forwarder as /usr/bin/mail calls /usr/sbin/sendmail. Doing this will bring an interesting situation when a package in Core depends on a virtual package provided by many of packages in Extra. I suggest we remove mailx from Core completely (after logrotate-3.7.5-1 will be signed off), because it's not required there anyway. -- Roman Kyrylych (Роман Кирилич)

4 5

[arch-dev-public] Status Report: 2008-01-07
by Aaron Griffin 09 Jan '08

09 Jan '08

ArchLinux Status Report, 2008-01-07 =================================== Aaron Griffin Ah, it's been so long since I had to shuffle through all these old emails and pump one of these reports out. With Christmas, New Years, and all that time off, I nearly forgot! That means one thing: I might forget some important things here. If I do, I will add an additional mail with additional items. We *do* have about 4 weeks to cover here, don't we? Happy Festivus to you all! == Newsworthy Items == * Ion 3 Removed from the repos Due to licensing concerns, we have removed Ion3 from the repos, as it is no longer "freely distributable" and puts unwanted constraints on the developers. * Logo Contest completion We've chosen a winner in the logo contest. The winner is Thayer Williams' Archer logo, available for your viewing pleasure in submission form here: http://dev.archlinux.org/~travis/logo-contest/thayer/1-archer.png Hooray, and congrats! We're currently going over the integration with the main site, so it may be a small amount of time before we get the changes in, but it *IS* being worked on. == Completed Tasks == * Dev/public site split Eliott has split the arch website into two distinct applications - the public site which everyone sees, and the developer site which we use to do our day-to-day tasks. This allows us to make changes to the dev site without interrupting everyone else's usage, AND allows us to increase performance on the public site through aggressive caching and other fancy terms like that. * Mozilla move to /usr All of the Mozilla related packages have been moved out of /opt and into the /usr tree. Currently these packages are still in [testing] but should reach [extra] soon. Special thanks to Alex and Jan for doing all the hard work here. == Pending Tasks, Short Term == * New initscripts and netcfg There are a handful of minor changes to the initscripts package, coming down the pipeline, but the most important one is the dropping of 'netcfg' from the package. netcfg has been completely rewritten by James, with many additional features and improvements, and should be used for any more complex networking needs beyond the simple networking in the default initscripts. More details here: http://wiki.archlinux.org/index.php/Network_Scripts * License Updates License updates are long and tedious, and they're still there. So every so often, if you can, please make sure and take a peek. See if you can fix some of your packages, and see if you've fixed any of them. It's a big list. http://archlinux.org/todo/43/ * ABS Redux ABS has been split from the pacman development tree in preparation for the pacman 3.1 release. This means that ABS can be developed and changed at a different pace than pacman, and pacman is more distro agnostic. The next big step will be getting rid of cvsup/csup and replacing it with an rsync-based system. Travis will be taking over the reins here, and this feature is currently being looked at / worked on. * Replacing CVS with SVN We've talked about this replacement for way too long, with no direct work beyond Jason's original proposal, so I am going to run with this. The proposal is to replace our CVS repos with an SVN implementation, and also restructure the layout just a bit. Jason has provided all the tools he has used to create these repos to me, and I am currently looking into the changes needed, mainly to our repo generation scripts. Once we can get these changes done, we can make the switch over to the new repo layout. * New devtools release I've been putting this one off for way too long. There are a large amount of changes we need to get into a new devtools package, including some newer scripts to aid packagers, and the chroot build tool updates. I'd like to push a release out the door soon, so if you have something you'd like included, please either email me, or add it to the Internal Dev section of the bug tracker. * Pacman 3.1 Release We're getting ever closer to a 3.1 release here (note the move from Long Term to Short Term, here). Dan and the crew are real close to getting 3.1.0 out. And it should be hitting [testing] real soon. So cross your fingers. You can see the full status here: http://archlinux.org/pipermail/pacman-dev/2008-January/010700.html * FHS Man Page support For as long as I've used arch, we've always put man pages in /usr/man. I never questioned it, and assumed it was on purpose. It turns out this is wrong, and in violation of the FHS. So we're working to fix this. Man pages *should* be installed to /usr/share/man from here on out. The new makepkg (3.1) will no longer move man pages to /usr/man. This will begin our slow-but-steady phase in of FHS compliant man pages. Users are encouraged to report packages which EXPLICITLY use /usr/man in the PKGBUILD (perhaps through a configure option) via the bug tracker. * 'codecs' Package Removal The codecs package has long been a bit of a thorn in our sides. While it adds support for some interesting formats, it also has questionable licensing issues. That said, mplayer and xine can both OPTIONALLY use the codecs package, and the dep has been removed (in [testing]). In the future, we will most likely be moving 'codecs' to [unsupported] due to the fact that it IS optional, has questionable license issues, and most video players can play a majority of formats WITHOUT the need for this package. * AUR Development Work Simo, our resident AUR pro, has been away for the holidays, and Eliott has been handling AUR development and progress. I want to point this out here because we've apparently had a resurgence of outside interest, and a lot of patches coming from Callan Barrett. Thanks a lot, Callan. Additionally, it appears that a few people are hard at work on an AUR successor, so if you're interested in starting from scratch, there is that as well. It's great to see work on the community tools again. Thanks a lot to everyone involved. == Pending Tasks, Long Term == * Perl policy implementation Kevin has been doing a great job implementing our fancy new "Perl Policy". You can see a full bug collector here: http://bugs.archlinux.org/task/8374 Apparently, one of the large leaps here is the removal of all the crazy symlinking we used to have to deal with. Cleaning this up, alone, helps us greatly with many perl related bugs and issues. * Official pacbuild usage This has gone more and more by the way side. With the advent of a manual machine to build packages on for non x86_64 devs, this is less and less of an issue. The major push for pacbuild was so that some devs could build on hardware they don't run. Is anyone willing to take up the pacbuild charge here? Give it some new life? * Modernize our Dashboard Eliott has made some great strides here. The split of public and dev websites give us a lot of flexibility and allow us to develop and make changes more rapidly. In case anyone is listening, I'd like to prioritize some changes here: - Multiple Architecture support: getting support for ALL our packages in the dashboard interface should be our first major milestone here. - Integration of Andy's 'difflist' functionality to show the differences between architectures. - Signoff functionality via the web interface. As it stands this is 90% Eliott doing all this work. If anyone would like to help out, I'm sure he'd appreciate it. * Architecture Independent Repos This will be made a reality AFTER pacman 3.1 is release. Support is already there for arch=(any) and we should start using this as soon as the DB scripts are updated to support this. Currently, this will most likely happen around the same time that the repos switch from CVS to SVN, but until then, this task is in holding. Anyone willing to help out, let me know. * ArchCon 2009: Big Baaad Idea This is staying right here until someone decides to come to Chicago to visit 8) No, the US is not dangerous! Hah.

1 1

[arch-dev-public] New extra package: gnucash
by Aaron Griffin 09 Jan '08

09 Jan '08

I said I was going to do this ages ago, due to the weirdness that is goffice, and the fact that I "maintain" both goffice and gnumeric already - does anyone take issue with pulling gnucash into [extra]?

9 16

[arch-dev-public] Updated perl 5.10.0
by K. Piche 09 Jan '08

09 Jan '08

I put perl 5.10.0 in testing. It follows the new perl hierarchy, the install file removes the symlink farm that confused everybody and it prints a small blurb about the update. Please test, k -- K. Piche <kpiche(a)rogers.com>

7 16

[arch-dev-public] [signoff] libgpg-error 1.6-1 + libgcrypt-1.4.0-1
by Andreas Radke 09 Jan '08

09 Jan '08

both packages are just updates that depend on each other and i haven't found any broken package, that depends on them. both are in testing for all archs. -Andy

5 10

[arch-dev-public] kde4
by Varun Acharya 08 Jan '08

08 Jan '08

Hi tpowa, Since you are the resident KDE guy, I was curious as to how you're going to handle kde4 when it releases this month. Most sources say that we should consider this more of a developer release, and stability and polish can be expected only from KDE 4.1. So, a couple of questions: 1. Will you get the KDE packages earlier than the actual release date, as you always seem to do? 2. Do you plan on moving these packages to extra or testing...or maybe even unstable?? 3. What naming scheme will you use? Will KDE4 packages become 'kdelibs' 'kdebase' and so on, or will kde3 packages retain that nomenclature for a while? (looking at how qt4=>qt in testing, I presume kde4=>kdelibs/kdebase). This means kde3 packages have to be rebuilt with the new naming scheme kdebase3, and of course all dependent packages with it. I just thought I'll get the ball rolling on the inevitable confusion to follow :) Thanks, Varun

3 4

[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] libgpod update and corresponding rebuilds
by Daniel Isenmann 08 Jan '08

08 Jan '08

Hi, I would like to update libgpod to version 0.6.0, because the new library supports the new ipod models. I think every ipod user with a new model would be happy about it. Now there must be some rebuilds for it. I plan to put the packages in testing first. Following packages depends on libgpod: gtkpod amarok-base kipi-plugins rhythmbox gtkpod, rhythmbox and kipi-plugins are no problems. I have rebuild them locally without problems. amarok-base (version 1.4.7-2) is in testing right now, but in CVS version 1.4.8 is commited. Should I just bump amarok to 1.4.8 in testing, together with amarok-engine-xine? Damir can you tell me more information on it? Thanks, Daniel

2 2

[arch-dev-public] [signoff] less 418-1
by Andreas Radke 08 Jan '08

08 Jan '08

in testing for both archs. just a minor update and switch to GPL3: http://www.greenwoodsoftware.com/less/news.418.html -Andy

4 3

[arch-dev-public] Daemon shutdown on uninstall?
by Aaron Griffin 08 Jan '08

08 Jan '08

Hey all, this bug report brings up an interesting point: http://bugs.archlinux.org/task/9030 Should we be stopping /etc/rc.d/ daemons on uninstall? My opinion is already expressed in the bug report, so I'll spare you here. If anyone feels strongly about it, please "sound off" in the bug report itself.

2 1