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

[arch-dev-public] [signoff] pcre 7.5
by Eric Belanger 22 Jan '08

22 Jan '08

Simple upstream update. Please signoff. Thanks. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

4 4

[arch-dev-public] Building mplayer
by Thomas Bächler 22 Jan '08

22 Jan '08

I have been maintaining mplayer for a while now. Unfortunately, during my absence mplayer had to be rebuilt by someone else. The x86_64 version (built by Eric) is fine, but the i686 (built by someone who doesn't know what the "Packager" option in makepkg.conf is for) version is missing features (bug #9288). The mplayer build system sucks. Seriously, it is the worst idea people have ever had, but the guys who are currently maintaining it are proud of it (I had the pleasure of arguing with one of them about autotools vs. mplayer during a two hour car trip last summer). Here is the thing: In autotools, you can use --enable-FOO to force configure to enable a feature. However, configure still checks if all libraries and headers are present and will add the needed options to gcc, or abort if a check fails. In mplayer, --enable-FOO forces the build system to enable a feature, but also skips all checks and doesn't add any options to the compiler, thus making 'make' fail unless you modify Makefiles by hand. This is not only unintuitive but also completely inconsistent with the way autotools work. The only way to properly enable a feature in mplayer is to put no --enable or --disable flag in and hope that configure's autodetection detects it properly. And of course you have to check if everything went fine after configure finished by reading the output summary. I don't have to tell you that this is very distributior-unfriendly. Since there is no way to force mplayer's configure to abort if something we want is missing, we must have the necessary makedepends listed - which we don't, as they are not easy to determine. The only way to properly build mplayer is to watch everything it does carefully and abort if something is wrong. For a while, a "we need clean build chroots so that our packages are not corrupted" attitude has spread, and this is exactly what broke mplayer (I have no idea which makedepend may be missing though). So please, unless you know exactly what you are doing and have much time to check everything, don't build mplayer!

4 4

[arch-dev-public] moving qt-4 and qt3 to [extra]
by Pierre Schmitz 22 Jan '08

22 Jan '08

Hi all, finally with pacman 3.1 qt3 and qt-4 can be moved to [extra] without problems. I want to start this tonight or at the weekend (if I have internet access). So please make sure the packages in testing are the latest and do not touch qt related packages during the move. Here is a first list of packages that I want to move. Please check if I missed some (@tpowa: there are some kde-4 related packages in testing). eric oprofile qgit arts kdebindings kdebluetooth kdegraphics kdelibs dbus-qt3 poppler-qt poppler-qt3 pyqt pyqt3 python-qscintilla qca qca-qt3 qca-tls qscintilla qscintilla-qt3 qt qt-doc qt3 qt3-doc qwt qwtplot3d amarok-base amarok-engine-xine kmplayer qjackctl qsynth scribus fwbuilder opera psi twinkle twinkle-kdefree wpa_supplicant_gui djvulibre kile kmobiletools lyx qtparted spassgen gtk-qt-engine qtiplot speedcrunch stellarium xdrawchem Pierre PS: If someone knows an elegant way to do the move without untagging,copying to add and del, retag and run db-scripts, please let me know. :-) -- archlinux.de

11 23

[arch-dev-public] [signoff] xulrunner packages
by Aaron Griffin 22 Jan '08

22 Jan '08

Just so this doesn't get buried in the middle of a thread: https://dev.archlinux.org/todo/44/ On Jan 21, 2008 8:17 AM, Alexander Baldeck <kth5(a)archlinuxppc.org> wrote: > I'll push them as soon as I get a sign-off for all the xulrunner packages.

2 1

[arch-dev-public] [signoff] pacman 3.1.1
by Dan McGee 21 Jan '08

21 Jan '08

In testing for both architectures. Changes here: http://projects.archlinux.org/git/gitweb.cgi?p=pacman.git;a=blob;f=NEWS;h=7… -Dan

5 7

[arch-dev-public] Mozilla status
by Aaron Griffin 21 Jan '08

21 Jan '08

On Jan 18, 2008 9:28 AM, Jan de Groot <jan(a)jgc.homeip.net> wrote: > BTW: How do we handle the mozilla /usr move, is it done yet, or do we still > have a big mess (AFAIK half of mozilla was moved to extra on i686 while it's > still in testing for amd64 :X) According to the list here: https://dev.archlinux.org/todo/44/ the recompiles are complete. Any reason we can't move these to [extra]? Jan, you mentioned that some packages were moved to extra already, do you know which ones? If I get no objections, I'd like to push these packages to extra tonight.

3 2

[arch-dev-public] [draft] QT-4 and QT3 moved to [extra]
by Pierre Schmitz 20 Jan '08

20 Jan '08

As announced last year* and after a longer period of testing, QT in version 4 and 3 was moved to [extra]. At least until the final release of KDE4 there are plenty of packages which still use version 3 of QT. Therefore a new package called qt3 was introduced. The dependencies of all packages are updated according to this change. The update should be quite smooth. Pacman only notfies about replacing qt by qt3 and qt4 by qt. If you don't want to have qt-4 installed just remove it with "pacman -Rc qt" after the update. If you are using any third party repositories like KDEmod please wait until they have updated their packages, too. Do not force any updates! If there are still any issues, please report them at http://bugs.archlinux.org. *) http://archlinux.org/pipermail/arch-dev-public/2007-November/002910.html -- http://www.archlinux.de

3 4

[arch-dev-public] [draft] QT-4 and QT3 moved to [extra]
by Pierre Schmitz 20 Jan '08

20 Jan '08

As announced last year* and after a longer period of testing, QT versions 3 and 4 have now been moved to [extra]. At least until the final release of KDE4 there are plenty of packages which still use version 3 of QT. Therefore a new package called qt3 was introduced. The dependencies of all packages are updated according to this change. The update should be quite smooth. Pacman only notifies about replacing qt by qt3 and qt4 by qt. If you don't want to have QT version 4 installed just remove it with "pacman -Rc qt" after the update. If you are using any third party repositories like KDEmod please wait until they have updated their packages, too. Do not force any updates! If there are still any issues, please report them at http://bugs.archlinux.org. Community packages may not be updated with the new versioning scheme of QT, so give your TUs some time to make the required changes. *) http://archlinux.org/pipermail/arch-dev-public/2007-November/002910.html -- http://www.archlinux.de

1 0

[arch-dev-public] [signoff] wpa_supplicant
by Pierre Schmitz 20 Jan '08

20 Jan '08

Hi, it seems I have missed the fact that wpa_supplicant_gui I moved from testing to extra forces wpa_supplicant to be moved from testing to core, too. So please signoff to fix this issue. I have tested it on i686. -- http://www.archlinux.de

3 4

[arch-dev-public] [signoff] e2fsprogs 1.40.4-1
by Tom K 19 Jan '08

19 Jan '08

Hi all. In testing now, for both arches. Release notes: http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.4 T.

3 2