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

[arch-dev-public] [signoff] libelf 0.8.10
by Andreas Radke 12 Oct '07

12 Oct '07

in testing for both architectures.

2 2

[arch-dev-public] [to sign off] grep, man-pages
by Andreas Radke 10 Oct '07

10 Oct '07

I've built grep and man-pages for x86_64 and ise has both for i686. They are now in testing. Please sign them off and move then to core. -Andy

4 3

[arch-dev-public] Plans for renaming kernel26suspend2 to kernel26tuxonice
by Daniel Isenmann 10 Oct '07

10 Oct '07

Hi, I plan to rename the kernel26suspend2 package to kernel26tuxonice and the corresponding modules are getting the suffix tuxonice instead of suspend2. Since the suspend2 developers change their name to tuxonice, this is the logical decision to avoid confusion. The next reason for changing the package name is the fact, that the tuxonice developers changed all refernces in their code to tuxonice. I think it's logical to name the package like the original one. I know, that there are other packages which would be affected by these changes. But I'm going to find those packages and rebuild/fix them or inform the maintainer of it. But no panic, I don't do it now...This is just an information to start discussion about this step. tuxonice doesn't released a stable version which build fine with kernel 2.6.23, so there is some time to think about it. But my plan is, that the next version of kernel26suspend2 becomes kernel26tuxonice. Daniel

1 0

[arch-dev-public] where to put unstable/testing packages?
by Andreas Radke 09 Oct '07

09 Oct '07

I've built my first pkg for unstable repo. It is built against testing packages. So do I put it into testing first and move it later to unstable or directly to unstable? Andy

5 5

[arch-dev-public] Replacing slocate?
by Aaron Griffin 09 Oct '07

09 Oct '07

Hey guys, I wanted to get some opinions on this bug here. http://bugs.archlinux.org/task/4490 I'm entirely neutral on it, but if one is technically superior, we should probably switch to it. So I'm going to put this out there so someone with more of an opinion can chime in. (Please comment on the bug tracker itself)

1 0

[arch-dev-public] kernel26 unionfs patch
by Simo Leone 09 Oct '07

09 Oct '07

The unionfs patch being used on our kernel was old and unstable (like... they're already on a new stable branch... old), so I went ahead and updated the PKGBUILD in CVS, after making sure the kernel built with the new patch. Anywho, just shootin ya'll a message so I don't step on anyone's toes. -S

1 0

[arch-dev-public] kmplayer 0.10.0 in [testing]
by Damir Perisa 08 Oct '07

08 Oct '07

kmplayer depends on gtk2 for its npplayer - because my i86_64 machine is on testing, i built it against testing and put it there. (i686 follows tomorrow) please anybody in charge of gtk2 update move kmplayer to [extra] together with gtk2 rebuild-group. by the way: who ever moved xorg out of testing seemed to have forgoten to remove the pkgs from it after putting them to extra: http://archlinux.org/packages/search/?q=libx11 : 13579 Extra x11-libs libx11 1.1.3-1 X11 client-side library 2007-09-16 13230 Testing x11-libs libx11 1.1.3-4 X11 client-side library 2007-09-05 thanx + greetings, Damir ---------- Message transmis ---------- Betreff: [arch-commits] CVS update of extra/multimedia/kmplayer (PKGBUILD) Datum: Monday 08 October 2007 Von: Damir Perisa <damir(a)archlinux.org> An: arch-commits(a)archlinux.org Date: Sunday, October 7, 2007 @ 21:17:32 Author: damir Path: /home/cvs-extra/extra/multimedia/kmplayer Modified: PKGBUILD (1.28 -> 1.29) upgpkg: kmplayer 0.10.0-1 ----------+ PKGBUILD | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) Index: extra/multimedia/kmplayer/PKGBUILD diff -u extra/multimedia/kmplayer/PKGBUILD:1.28 extra/multimedia/kmplayer/PKGBUILD:1.29 --- extra/multimedia/kmplayer/PKGBUILD:1.28 Sat Apr 7 08:22:33 2007 +++ extra/multimedia/kmplayer/PKGBUILD Sun Oct 7 21:17:32 2007 @@ -1,20 +1,27 @@ -# $Id: PKGBUILD,v 1.28 2007/04/07 12:22:33 damir Exp $ +# $Id: PKGBUILD,v 1.29 2007/10/08 01:17:32 damir Exp $ # Maintainer: damir <damir(a)archlinux.org> # Contributor: Damir Perisa <damir.perisa(a)bluewin.ch> + pkgname=kmplayer -pkgver=0.9.4.a -origver=0.9.4a +pkgver=0.10.0 +origver=0.10.0 force=y pkgrel=1 pkgdesc="Video player plugin for Konqueror and basic MPlayer/Xine/ffmpeg/ffserver/VDR frontend for KDE" arch=("i686" "x86_64") +license=('GPL2') url="http://kmplayer.kde.org" -depends=('libx11' 'libxv' 'cairo' 'kdelibs>=3.5.6' 'gstreamer0.10-base' 'xine-lib') +depends=('libx11' 'libxv' 'cairo' 'kdelibs>=3.5.7' 'gstreamer0.10-base' 'xine-lib' 'dbus-glib' 'dbus-qt3' 'gtk2') +# gtk2 and dbus-glib is needed only by opt/kde/bin/knpplayer so it probably may be also made optional if needed source=($url/pkgs/$pkgname-$origver.tar.bz2) build() { export MAKEFLAGS="-j1" cd $startdir/src/$pkgname-$origver + + # fix include path of some headers (0.10.0): + sed -i "s|\"prtypes.h\"|<nspr/prtypes.h>|g" src/moz-sdk/jni_md.h src/moz-sdk/jri_md.h src/moz-sdk/npapi.h || return 1 + ./configure --prefix=/opt/kde make || return 1 make prefix=$startdir/pkg/opt/kde install @@ -22,3 +29,4 @@ rm -f ${startdir}/pkg/opt/kde/share/mimelnk/application/x-mplayer2.desktop } +md5sums=('8e8d3df2cdebc4c08fd6f8ab6bf1bda4') _______________________________________________ arch-commits mailing list arch-commits(a)archlinux.org http://archlinux.org/mailman/listinfo/arch-commits ------------------------------------------------------- -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

5 10

[arch-dev-public] New ISO release thread, please all read!
by Tobias Powalowski 08 Oct '07

08 Oct '07

Ok, according to the last thread about releasing on saturday i summarize: - most agree with releasing a new iso that just works - New codename? A new iso will be released in november which contains a new major kernel, which we all agreed earlier this year should trigger a new codename and release/filename. At the moment it would mean much work to regenerate the ISOs with only to include a new code name. With entering kernel .23 series we should bump initscripts to a new code name, suggestions are welcome :) one mentioned was Hardcore - Release/File name of ISOs? ok here started the confusion, these ISOs will still contain the same major kernel series as in 2007.08 ISOs. There was also a thread about name scheme and we wanted to use -0.x as developer ISOs and [1-9] as release/bugfix versions. According to this it would be logical to use here 2007.08-2 as release/filename we could still use the iso/2007.08 directory on ftp and remove the others directories, see section below. - Remove of old ISOs and addons? All old ISOs ftp routines are broken. Also every ISO had some kind of itches which now are all fixed, it would make sense to remove all old ISOs and addons from ftp/iso. Addons are not necessary anymore with latest ISOs because most fast enough drivers are now included on the media itself. comments, thoughts and simple agrees/denies are welcome thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

11 23

[arch-dev-public] adopted more packages
by Varun Acharya 08 Oct '07

08 Oct '07

I just adopted foobillard,bluez-gnome,xcdroast,nicotine. one question, which I asked on IRC too, is libdivxdecore actually used by anyone for anything? does it still need to be in extra? The package hasn't been updated in three years (I assume thats how long ago projectmayo.com shifted to divx.com) Varun

2 1

[arch-dev-public] hidden dependencies
by Andreas Radke 08 Oct '07

08 Oct '07

I want to ask something about our own packaging rules. Right now we don't add any dependencies that are already covered by another. Namcap usually tells you that right. But this makes it hard to do all the .so rebuilds or if you simply want to check over all packages where a pkg foo is a dependency. This is what I use for checking the deps: [andyrtr@workstation64 cvs]$ grep -l libpcap `find . -name PKGBUILD` ./arch/build/base/ppp/PKGBUILD ./arch/build/base/libpcap/PKGBUILD ./arch/build/network/nmap/PKGBUILD ./arch/build/network/ngrep/PKGBUILD ./arch/build/network/tcpdump/PKGBUILD ./arch/build/network/wireshark/PKGBUILD ./core/base/ppp/PKGBUILD ./core/base/libpcap/PKGBUILD ./core/support/ppp/PKGBUILD ./extra/lib/libnetdude/PKGBUILD ./extra/lib/libnids/PKGBUILD ./extra/lib/libpcapnav/PKGBUILD ./extra/emulators/user-mode-linux/PKGBUILD ./extra/network/lft/PKGBUILD ./extra/network/nmap/PKGBUILD ./extra/network/ntop/PKGBUILD ./extra/network/ngrep/PKGBUILD ./extra/network/ulogd/PKGBUILD ./extra/network/etherape/PKGBUILD ./extra/network/tcpdump/PKGBUILD ./extra/network/ssldump/PKGBUILD ./extra/network/ettercap/PKGBUILD ./extra/network/kismet/PKGBUILD ./extra/network/wireshark/PKGBUILD ./extra/network/xprobe/PKGBUILD ./extra/network/tcptraceroute/PKGBUILD ./extra/system/snort/PKGBUILD ./extra/daemons/knockd/PKGBUILD Do you know any way to write some code for namcap or checkpkg to show those hidden "already covered by another dep" dependencies? To run lddd.sh is only a poor solution as it only detects packages that are installed on your system. If not I'd vote to change the old packaging rule and switch to fully shown deps. Andy

5 7