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

[arch-dev-public] Please build and test testing/madwifi on i686
by Alexander Baldeck 17 Jul '07

17 Jul '07

Could somebody please take care of that? Thanks a bunch, -U

2 3

[arch-dev-public] Definition of non-free for repo-reorg
by James Rayner 14 Jul '07

14 Jul '07

If we do separate "non-free" and "free" in the new repo layout, what will be the definition of "non-free"? Will anything closed source be non-free (acroread, nvidia)? or only things that have license/patent/distribution issues, like codecs? Will we just follow debian's definition and tests? James

10 20

[arch-dev-public] i686: missing packages
by Andreas Radke 13 Jul '07

13 Jul '07

==> Generating Text Package List... notice: Missing bluez-libs-3.12-1.pkg.tar.gz in ftp site notice: Missing fetchmail-6.3.8-3.pkg.tar.gz in ftp site notice: Missing xf86-input-joystick-1.2.2-1.pkg.tar.gz in ftp site notice: Missing xf86-video-nv-1.0.1.4-1.pkg.tar.gz in ftp site ANdyRTR

2 1

[arch-dev-public] kvm-modules package
by Thomas Bächler 13 Jul '07

13 Jul '07

With 2.6.22, we have had numerous reports that kvm locks up or doesn't load. On the other hand, according to Attila (http://bugs.archlinux.org/task/7598) we can use the kvm version shipped with 2.6.22. This would be easier and it is better tested than the one we build externally. Are there any reasons for keeping kvm-modules separately?

3 2

[arch-dev-public] GPL v3
by Dan McGee 13 Jul '07

13 Jul '07

Since some software we are going to package soon will be released under GPL v3 instead of GPL v2 or later, should we add this license as a separate one named "GPLv3" in the licenses package and begin using this in the license field? This seems like the easiest solution to me, rather than go back and change every occurrence of GPL to GPLv2. Thoughts? This isn't a very extreme change, but something that we need to consider and I didn't want to make the change without a bit of feedback first. -Dan

5 9

[arch-dev-public] will DVD size be the limit for our official repos?
by Andreas Radke 12 Jul '07

12 Jul '07

for x86_64 we now have [andyrtr@server64 ~]$ du -sh /home/andyrtr/mirror/packages/extra/ 3,6G /home/andyrtr/mirror/packages/extra/ [andyrtr@server64 ~]$ du -sh /home/andyrtr/mirror/packages/current/ 486M /home/andyrtr/mirror/packages/current/ i686 is ~100MB bigger. do we want to limit the amount of both repos to fit on a DVD (singlelayer)? this might become hard as pkg size usually raises each release. maybe we can go over that limit but would have keep out packages (e.g. i18n) from DVD releases. opinions? Andy

9 14

[arch-dev-public] stellarium update
by Damir Perisa 12 Jul '07

12 Jul '07

can somebody with a highspeed-internet connection update stellarium for me? extra - science - stellarium 0.8.2 -> 0.9.0 its 34mb of source and probably 20mb of pkg afterwards. thanx Damir -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

2 3

[arch-dev-public] New toolchain stuff in testing
by Jan de Groot 12 Jul '07

12 Jul '07

Hi all, Andy and I uploaded a new toolchain to testing. This includes a new binutils, a new gcc and a new glibc. On AMD64, the old stable 2.17 binutils doesn't function correctly in all cases with gcc 4.2 and glibc 2.6 (I was waiting for a binutils 2.18 release, but it's not coming within the next month I'm afraid). One big new feature in the new binutils is the support for GNU hashing, which is, according to Redhat, 50% faster in symbol lookups when doing dynamic linking. The GNU hashing is incompatible with the older hashing. There's a way inbetween: supporting both hash styles. The gcc in testing enforces both hash styles in the resulting linked binary. This means the size increases (I've seen libstdc++.so.6 and libc.so.6 getting increased by 10-20KB on a 1-2MB sized binary), but we maintain compatibility with other distributions and with our current "old style" glibc whenever something gets built with this toolchain. this is also the road taken by Debian. As long as binutils 2.17.50.xx isn't a so called stable release, we will keep this duplicate hashing style around, we have to decide what to do after the 2.18 release of binutils. (gcc-fortran will follow later tomorrow btw). Have fun testing this new toolchain, please report any bugs you find in flyspray.

3 4

[arch-dev-public] more repo reorg - take 2
by Paul Mattal 11 Jul '07

11 Jul '07

So the discussion so far suggests to me that I was wrong; in fact, it would not be easy to maintain any sort of [lite] or [full] that was limited in any way amongst the entire group. We will no longer have a set of packages of any predictable size we can carry around. One point still being missed about base vs. support: right now we are sloppy. We assume that certain packages are installed because they are in base or just because they are important. We should either: a) make our dependencies complete and not rely on such things OR b) have some group of packages that users should assume will break things if they remove. I think a) is better. So I amend my suggestion: [core]: has 2 categories - base, support base is by default fully installed when Arch is installed (base category pkgs also in base group for easy depends) support is by default not installed when Arch is installed only package dependencies require base pkgs to be installed (means we must fix our dependencies) draws from existing base category + drivers/utilities needed for installs minimize size stringent review/discussion for changing base, less so for support [main]: everything else Also, this can be done now because it's relatively easy. - P

1 0

[arch-dev-public] New /arch/db-* scripts
by Thomas Bächler 11 Jul '07

11 Jul '07

I started writing new database scripts to replace the old db-*/updatesync-many/pkgdb2 scripts. The reason are support for the new pacman 3 naming scheme and fixing some design issues. The old scripts use PKGBUILDs a lot for their operation and don't check the package file for consistency with the PKGBUILD (only the filename). They also move every file from the staging dir, regardless of whether the package will be added in any repository. And they recreate much of the functionality from updatesync, sort of reinventing the wheel. My new draft has a cleaner design, but some new problems appear. It performs the following steps: 1) Check every file in the staging/add dir using a small libalpm-based tool and obtain the pkgname, pkgver, pkgrel and architecture. Compare the arch specified in the commandline with the arch from the package (this step is missing in the old scripts). Find the PKGBUILD and compare pkgname, pkgver and pkgrel with the values from the package. If all checks are okay, add the package to a list. If additionally, a force flag is set in the PKGBUILD, add it to a "force-list". 2) Check every file in the staging/del dir and obtain its pkgname. Add this package to a delete list. 3) Lock the database 4) Move all packages and force-packages to the ftp dir, add them with repo-add. 5) Pass the package files to a pkgdb2-like tool to add them to the web interface. 6) Delete all package from the delete-list with repo-remove. 7) Pass the package names to a pkgdb2-like tool to remove them from the web interface. 8) Release the database lock. The problems I run into are these: a) In step 4) I can't determinte the filename of the old package and remove it from the ftp. I could scan for certain filename schemes, but take into account that the package filename could be anything now, the script doesn't care. We could however rely on our current filename scheme to find/remove the dupes (who would go through the trouble to rename his package to sth like wrongname-notapackage.zip.bz8 anyway?). b) The same thing counts for step 6). But we mv our packages to the staging/del anyway so the script won't have to remove them from the ftp. c) This is the biggest problem currently. In step 5), due to the new script design, I don't have any data from the PKGBUILD any more and don't want to go find it again. That means I only use data from the package file itself to add it to the mysql db. The package file lacks the "package category" and "source" which are in the web interface. I could only solve this by either removing this data from the web interface or adding it to the package file. d) The web interface doesn't support different architectures, so only data for the i686 packages is shown. That is a bad thing imo, but once data for more architectures is added, we need to be more careful about removing things from the web interface, as one architecture might lose a package that the other still keeps. I'd appreciate any comments on this, especially to problem c).

6 8