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

[arch-dev-public] [extra signoff] nvidia/nvidia-utils 169.07
by Thomas Bächler 11 Jan '08

11 Jan '08

I added new nvidia drivers 169.07 for i686 and x86_64 to testing. My nvidia machine is out of order for now, so please sign off both architectures and as many GPUs as possible. I am also interested in signoffs from users, so please don't hesitate to reply to this message to the arch-general list!

4 3

[arch-dev-public] [signoff] abs-1.0-1
by Travis Willard 11 Jan '08

11 Jan '08

abs-1.0-1 in testing for i686 (and x86_64 - somebody grabbed that for me, thanks!) Please signoff - will need pacman 3.1.0 from testing installed to avoid conflicts.

4 4

[arch-dev-public] Add patch to python to save power for pygtk apps
by Jan de Groot 10 Jan '08

10 Jan '08

Hi all, It's quite common knowledge that pygtk/pygobject programs are bad for power usage. Newer versions of pygtk and pygobject contain code that requires API from python trunk to solve this issue. However, our python 2.5 doesn't have that code. http://blogs.gnome.org/johan/2008/01/04/enough-wakeups-in-python-programs/ describes the issue, it's from the pygobject/pygtk developer that integrated the new code. http://cvs.fedora.redhat.com/viewcvs/devel/python/python2.6-set_wakeup_fd4.… is the backport to python 2.5 done by redhat. I would like to apply the python wakeup patch, put this new python in testing and build the new pygobject/pygtk releases against it. Though the added python API is development code, it's an API addition that doesn't touch existing API, so our python will stay compatible with old python scripts/libraries/etc. The downside of the patch is that this new API could be not the final API, which requires us to update the patch whenever it changes. As this patch has been developed by python and pygtk developers together, I don't see problems here. So the question is: is it ok to apply the patch to our python package?

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] request: remove mailx from Core
by Roman Kyrylych 09 Jan '08

09 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 08 Jan '08

08 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