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

[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 12 Jul '07

12 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 11 Jul '07

11 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

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

11 Jul '07

I support reorganizing, but like the fact that a single full CD can give me a pretty useful system if I'm a disconnected install. I also support using more repos rather than fewer, since with repoman the repos will become less of a hassle to manage. I support wide driver support, but don't think wireless drivers need to be installed on every box! So let me take a shot at a scheme: [core]: installed whenever Arch is installed draws from existing base category minimize size free/unencumbered only stringent review/discussion for changing [support]: drivers/utilities needed for installs included on core install cd [lite]: fits on cd with installer free/unencumbered as much function as we can pack into 1 cd stringent review/discussion for changing [full]: everything else this should continue to fit on 1 of some medium (now DVD) Nice aspects of this include that people who want a totally free system can rely on lite providing that, core can be really small, and people can have all the drivers they need at install time. - P

6 7

Re: [arch-dev-public] [arch-dev] newsletter?
by Jason Chu 10 Jul '07

10 Jul '07

On Mon, Jun 25, 2007 at 11:41:20AM -0700, Jason Chu wrote: > On Mon, Jun 25, 2007 at 09:17:24AM -0700, eliott wrote: > > Anything happening with the newsletter lately? > > Looks like there hasn't been one in a month or two.. > > Good point. I don't write it, I just write the devland section. The other > Jason writes it. I'll send him an email. > > Jason I heard back from Jason a little while ago. He hasn't had time during the summer to write the newsletter. He said he probably will have enough time at the beginning of August. I'm sending this to the public list too. If anyone reading this wants to help with the newsletter (writing all the sections except Devland), send me an email. Let's see if we can find more support so that one person can take some time off! Jason

1 0