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

[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

[arch-dev-public] Tool tarball location
by Aaron Griffin 08 Oct '07

08 Oct '07

On 10/2/07, Jason Chu <jason(a)archlinux.org> wrote: > Since namcap is hosted on projects now, where should the tarballs go? > ftp/other or somewhere else? I don't think anyone's thought about this > yet... Yeah, let's use ftp/other/<toolname>/ for all our official stuff like pacman, devtools, etc etc.

10 18

[arch-dev-public] Find-deps script (was: hidden dependencies)
by Travis Willard 07 Oct '07

07 Oct '07

> This is what I use for checking the deps: > > [andyrtr@workstation64 cvs]$ grep -l libpcap `find . -name PKGBUILD` A while ago I posted a script to this ML that does this, but gives more concise output, finding _only_ deps and makedeps, and not random comments and such. Jurgen reworked it a bit for speed and because his bash is leet. I've reattached it here - I suggest you use it. -- Travis

4 6

[arch-dev-public] Testing policy
by Aaron Griffin 07 Oct '07

07 Oct '07

Time for the "big hat" We had some oopses today. Problems that were brought up less than 3 months ago, which reoccurred. In the past, Judd had a problem with saying that every package needs to go to testing. I don't. Going forward, every single [core] package MUST go to testing, and MUST be OKed by at least one other developer. The term here is "independent verification" - we want someone else, that is not you, to tell you this works. While we have no formal tools in place for this, eventually I'd like to have a way to "sign off" that a package in testing works. Just to clarify: This is not a request. This is not a discussion. The core repository is critical to ArchLinux systems and should never be broken like this. All core packages MUST go to testing and MUST be verified by another developer. Feel free to do this on the ML, or on IRC - just somewhere where we can look back on the logs if there are issues. -- Aaron

2 2

Re: [arch-dev-public] [arch-commits] CVS update of core/base/libpcap (PKGBUILD)
by Jan de Groot 07 Oct '07

07 Oct '07

On Sun, 2007-10-07 at 07:42 -0400, Thomas Baechler wrote: > Date: Sunday, October 7, 2007 @ 07:42:13 > Author: thomas > Path: /home/cvs-core/core/base/libpcap > > +# This package has a strict SONAME that changes in EVERY MINOR > +# release. Whenever you feel like updating this package, DON'T, > +# it will break a number of essential system tools. > +# Again, for dummies: IF YOU UPDATE THIS PACKAGE DIRECTLY TO CORE, > +# I WILL PERSONALLY CHOP YOUR HEAD OFF! Morning Mr Head Chopper... I looked at this package yesterday, it seems something is plain wrong with the soname versioning. I took a look at the debian package, where we retrieved the shared library patch from 2 years ago (yes, libpcap was one of the first packages I changed when I had current access). It seems they keep track whether a release is API/ABI stable and keep the soname the same. FYI: They have libpcap.so.0.9.8 and libpcap.so.0.8, as the 0.9.x versions share the same ABI as the 0.8 versions. They update their patches to keep things working. I'm thinking about two solutions here: - Make sure apps stop linking against the .so.0.9.x library, apps should link to the normal soname that doesn't change on minor version bumps - remove the patch completely and continue to use the static library as the libpcap project does upstream Solution 1 looks hard, but all it takes is updating the shared lib patch and adjust it to not look at the debian changelog to generate its sonames.

2 1