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

[arch-dev-public] Can we trust our mirrors?
by Pierre Schmitz 04 Dec '08

04 Dec '08

Hi all, at first: it is really great that the number of mirrors is increasing and I am really thankfull to those who provide one. The point why I feel more and more uncomfortable is that we have no way to ensure tat one will get the same file from a mirror as from archlinux.org. A mirror owner might be a "bad" person himself, his servers might have weak security, the government of their home country cannot be trusted, they might sync from another "bad" mirror. etc... Of course since several years demand package signing. I have even seen some first code, but nothing was ever finished. It should be clear that something has to be done. Manipulating packages is just too easy. The simplest solution would be if we sign the db files (automatically) on gerolde. Of course this is less secure than signing every single package by its packager; but on the other side it would be easy to implement and there would be no overhead for packagers. I am aware that this method would only ensure that packages on a mirror are the same as on gerolde; if our server gets "hacked" we would have lost. But this should be fine and is far more better than just nothing and hoping that there are no "bad guys" out there. Gerhard has written a small patch as a proof of concept. Ignore the details at this point. The idea is as follows: 1) patch repo-add in order to create a .sig file everytime the db file will be changed. For this a private key readable by every dev or just sudo can be used 2) use this version of repo-add on gerolde. So we'll have the sinatures propagated to our mirrors. 3) For testing the whole thing one could just write a small download script which checks the signatures of db files. (Abusing the XferCommand statement in pacman.conf) 4) If all went well we could think about a build-in check in pacman itself. (we might be able to reuse some code here that was written for package signing) 5) Enable those checks by default for all official repos 6) The public key should not be in a package but people have to get it from our website. What do you think about this? Step 1 to 3 could be implemented in a rather short time. Pierre -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

5 7

[arch-dev-public] Repository Maintenance 03-12-2008 18:00
by repomaint＠archlinux.org 03 Dec '08

03 Dec '08

Scan complete for extra (i686) at /srv/ftp/extra/os/i686/ The following files are out of date They will be moved to /srv/package-cleanup postfix-2.5.3-1-i686.pkg.tar.gz Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64/ The following files are out of date They will be moved to /srv/package-cleanup postfix-2.5.3-1-x86_64.pkg.tar.gz Scan complete for testing (i686) at /srv/ftp/testing/os/i686/ The following files are in the repo but not the db They will be moved to /srv/package-cleanup postfix-2.5.5-1-i686.pkg.tar.gz Scan complete for testing (x86_64) at /srv/ftp/testing/os/x86_64/ The following files are in the repo but not the db They will be moved to /srv/package-cleanup postfix-2.5.5-1-x86_64.pkg.tar.gz

1 0

[arch-dev-public] Grub splashimage
by Aaron Griffin 03 Dec '08

03 Dec '08

Just throwing this out there - I'm not really stating my opinion on this, as I'm fairly neutral. Considering grub development is basically dead (waiting for grub2), what do you guys think about adding the splashimage patch to our official grub? See grub-gfx in community. I have used it for ages on my machine with no issues. It simply adds one config file variable. As I said, I'm neutral on this. It kinda flies in the face of the minimal patches idea, but grub is pretty much all patches these days.

13 23

[arch-dev-public] [testing] Cleanup?
by Jud 03 Dec '08

03 Dec '08

Hi, It seems there are alot of packages still listed in [testing] that have been moved to core/extra, would it be possible if this could be fixed please? Thanks

5 9

Re: [arch-dev-public] Grub2
by Ronald van Haren 03 Dec '08

03 Dec '08

Hi all, Grub2 is now in my staging dir for both architectures. I'll move it into extra shortly. Things to know: - config file changed to /boot/grub/grub.cfg - config syntax changed a bit - most information can be found on the grub2 archwiki page [1] If you have any experience with grub2 and know your way around, the wiki page still needs some attention for some more special options. The basic stuff should be covered. If you have a more exotic configuration than I have, give it a try. I can't test a lot of use cases myself. Ronald [1] http://wiki.archlinux.org/index.php/GRUB2

2 2

[arch-dev-public] KDE: Call for a Co-Maintainer and an unstable repo
by Pierre Schmitz 03 Dec '08

03 Dec '08

Hi, I have some KDE related points I want to discuss here: 1) I need someone who helps me to maintain KDE. It develops quite fast and 4.2 introduces some new features, moredependencies and we need to add/update some packages in [extra]. I know that you allready have more than enough to do. So if ther is noone among us we might ask if there is some TU willing to help. With some additional help the following issues can be fixed: 2) KDE-4.2 will be released in a few weeks. So it makes sense to start packaing beta and rc snapshots. What do you think about a kde-unstable repo? I think it could be live in <package>/repos/kde-unstable and db -update should be able to handle this. The size of this repo would be about 350MB for each architecture. 3) The package dependencies of KDE are goning to be a mess. If you install the kde group you will find nearly the whole [extra] repo on your harddrive. Some of these deps are only on package level and can be fixed. E.g. kde depends on gnome due to some "strange" deps of ghostscript and gstreamer for example. Having a look at 4.2 this situation is getting worse. KDE is more or less modular, but they put a lot of apps in one package like kdegraphics. The only sane way to solve this issue is to split some packages. Optdepends does not help here because some features are enabled at runtime if certain files exist. Support for splitting packages in makepkg/devtools woulbd be more than helpfull if not needed. Who wants to install java, php, ruby, perl etc. just because some apps in kdebase makes use of the python -bindings which iare included in the kdebindings package? Summing things up, this is a call for increasing man power. I need somone to help with packaging KDE (and its dependencies) and somone to implement support for splitting packages in makepkg (and don't forget about the devtools and db- scripts here) Greetings, Pierre -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

4 9

[arch-dev-public] Repository Maintenance 03-12-2008 12:00
by repomaint＠archlinux.org 03 Dec '08

03 Dec '08

Scan complete for extra (i686) at /srv/ftp/extra/os/i686/ The following files are out of date They will be moved to /srv/package-cleanup libv4l-0.5.6-1-i686.pkg.tar.gz Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64/ The following files are out of date They will be moved to /srv/package-cleanup libv4l-0.5.6-1-x86_64.pkg.tar.gz

1 0

[arch-dev-public] Repository Maintenance 03-12-2008 09:00
by repomaint＠archlinux.org 03 Dec '08

03 Dec '08

Scan complete for extra (i686) at /srv/ftp/extra/os/i686/ The following files are out of date They will be moved to /srv/package-cleanup linuxdcpp-1.0.1-1-i686.pkg.tar.gz Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64/ The following files are out of date They will be moved to /srv/package-cleanup linuxdcpp-1.0.1-1-x86_64.pkg.tar.gz

1 0

[arch-dev-public] Forgotten everything I ever knew about our SVN...
by Tom K 03 Dec '08

03 Dec '08

OK... as my first major piece of work since returning, I have run extrapkg on a bunch of libpcap rebuilds that should have gone to testing. I haven't run the db script on gerolde yet. I'd really appreciate some pointers on how to sort this out. I'm away for a few hours now, but I'll get it fixed asap. Sorry and thanks. Tom.

4 8

[arch-dev-public] Repository Maintenance 03-12-2008 06:00
by repomaint＠archlinux.org 03 Dec '08

03 Dec '08

Scan complete for core (i686) at /srv/ftp/core/os/i686/ The following files are out of date They will be moved to /srv/package-cleanup wpa_supplicant-0.5.10-1-i686.pkg.tar.gz The following files are in the repo but not the db They will be moved to /srv/package-cleanup dosfstools-3.0.0-1-i686.pkg.tar.gz Scan complete for core (x86_64) at /srv/ftp/core/os/x86_64/ The following files are out of date They will be moved to /srv/package-cleanup wpa_supplicant-0.5.10-1-x86_64.pkg.tar.gz The following files are in the repo but not the db They will be moved to /srv/package-cleanup dosfstools-3.0.0-1-x86_64.pkg.tar.gz Scan complete for extra (i686) at /srv/ftp/extra/os/i686/ The following files are out of date They will be moved to /srv/package-cleanup dosfstools-3.0.0-1-i686.pkg.tar.gz drscheme-4.1.2-1-i686.pkg.tar.gz wpa_supplicant_gui-0.5.10-1-i686.pkg.tar.gz Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64/ The following files are out of date They will be moved to /srv/package-cleanup dosfstools-3.0.0-1-x86_64.pkg.tar.gz drscheme-4.1.2-1-x86_64.pkg.tar.gz wpa_supplicant_gui-0.5.10-1-x86_64.pkg.tar.gz Scan complete for testing (i686) at /srv/ftp/testing/os/i686/ The following files are in the repo but not the db They will be moved to /srv/package-cleanup dosfstools-3.0.1-1-i686.pkg.tar.gz wpa_supplicant-0.5.11-1-i686.pkg.tar.gz wpa_supplicant_gui-0.5.11-1-i686.pkg.tar.gz Scan complete for testing (x86_64) at /srv/ftp/testing/os/x86_64/ The following files are in the repo but not the db They will be moved to /srv/package-cleanup dosfstools-3.0.1-1-x86_64.pkg.tar.gz wpa_supplicant-0.5.11-1-x86_64.pkg.tar.gz wpa_supplicant_gui-0.5.11-1-x86_64.pkg.tar.gz

1 0