January 2009 - Arch-general - lists.archlinux.org

[arch-general] KDE 4.2.0 in [testing]
by Pierre Schmitz 26 Jan '09

26 Jan '09

Hi everybody, today I uploaded the so called "first try" of 4.2 into [testing]. Those packages are not the final one yet, but damn close. There are only two known upstream showstoppers; which will be fixed by new packages soon. See http://bugs.kde.org/buglist.cgi?keywords=kde-4.2.0-blocker. On our site only mysql is blocking a release to [extra]: http://bugs.archlinux.org/task/12798 In addition to this kde-l10n-et seems broken. So please take the chance and check those packages. An update from 4.1 should be quite smooth. And even if you hated KDE 4.1, give 4.2 a try; it really rocks. :-) If you notice any regression, showstopper or problems during the update, please report them. Packages for x86_64 should be available on your favourite mirror soon; Andrea will build i66 packages tomorrow. 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

11 28

[arch-general] thunar-thumbnailer
by Marco Antonio Gomez 26 Jan '09

26 Jan '09

Using Openbox + Thunar + Thunar thumbnailer in Arch (completely updated), I noticed that thunar-thumbnailer, since last week, does not generate video thumbnails anymore. AFAIK, the problem is related to a new version of ffmpeg... My system messages show me that ffmpegthumbnailer looks out for a libavcodec.so.51 (lib that used to be provided by ffmpeg package, that was recently replaced by libavcodec.so.52.10.0). But the newer version of ffmpegthumbnailer in community, still looks for libavcodec.so.51. Then... obviously "error while loading shared libraries - no such file of direcrory". I've already tried to create a symbolic link named libavcodec.so.51 pointing to libavcodec.so.52.10.0, and when I try to do that, the ffmpegthumbnailer returns "Error: Could not find video stream" I've also tried to recompile ffmpeg and also ffmped-thumbnailer and all of it's dependencys from the newer versions of each one in AUR, but it was a frustrated attempt. Anybody else reports the same issues? If positive, any workaround to make it work? Regards, Marco Antonio Gomez.

3 2

[arch-general] Staic libraries
by Damjan Georgievski 26 Jan '09

26 Jan '09

Since bugs on http://bugs.archlinux.org/ are too eagerly closed I'll have to ask here. I'm trying to build the latest "tuxonice-userui" since it's required by tuxonice-rc8. The compile of tuxoniceui_fbsplash fails with "/usr/bin/ld: cannot find -lfreetype" The last command (the one that fails) is: cc -static userui_core.o fbsplash/userui_fbsplash.o -o tuxoniceui_fbsplash -lmng -lpng -ljpeg -lz -lfreetype -llcms -lm Now, there are /usr/lib/libmng.a /usr/lib/libpng.a /usr/lib/libjpeg.a /usr/lib/libz.a /usr/lib/liblcms.a /usr/lib/libm.a files on my ArchLinux but there's no /usr/lib/libfreetype.a static library. In http://bugs.archlinux.org/task/11016 JGC claims: "Static libraries aren't needed to build static binaries. The makefiles contain hardcoded references to the .a files, which is wrong." Now, it's not true that the userui Makefile has a hardcoded reference to the .a file. And I don't see how to build a static binary either? Hints? -- damjan

2 1

[arch-general] consistency in iso naming
by Dieter Plaetinck 26 Jan '09

26 Jan '09

Hi, I suggest we use the following names: 2009.01-alpha 2009.01-beta 2009.01-1 (official release) (2009.01-2, 2009.01-3 etc subsequent official releases, if required) I think our isos/img's should have such versions in there filenames, instead of using 2009.01 for alpha + beta + official releases. This is useful for: 1) avoiding confusion with iso's. Users are not aware which versions the isos are hosted on dev spaces such as http://dev.archlinux.org/~aaron/archiso/. Hell, even for relengs/devs it can be confusing 2) 1:1 to mapping to version numbers on flyspray. I added some versions on flyspray (2009.01-{alpha,beta,1} etc). imo we need to update iso names as such, so bugs can be reported on the correct versions etc, otherwise it will be mess. This implies a change in archiso. is that okay? PS: i also made a version 2009.04-alpha where we can attach some non-critical tickets to. Dieter

3 3

[arch-general] [signoff] kernel26 2.6.28.2-1
by Tobias Powalowski 25 Jan '09

25 Jan '09

Hi guys, new kernel adresses the following things: - bump to latest version please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] gstreamer0.10 0.10.21-2 i686
by Baho Utot 25 Jan '09

25 Jan '09

When trying to compile gstreamer0.10 0.10.21-2 i686 I have this error checking bison version 2.4.1 >= 1.875... Argument "^B^D^A" isn't numeric in numeric lt (<) at - line 1. current bison/gcc Anyone seen this?

1 0

[arch-general] silent fsck at startup
by wahjava.ml＠gmail.com 24 Jan '09

24 Jan '09

Hi all, Is there any switch for fsck (during startup) to be somewhat verbose like displaying the progress of filesystem check ? TiA -- Ashish SHUKLA

7 13

Re: [arch-general] [arch-dev-public] [signoff] initscripts 2009.01
by Dieter Plaetinck 23 Jan '09

23 Jan '09

Hugo Doria wrote: > Signoff (both) > > -- Hugo > signoff i686. all looks good. Dieter

1 0

[arch-general] Moonlight 1.0
by Amanai 23 Jan '09

23 Jan '09

The final Version from Moonlight 1.0 released on January 20th. Will this be avaible in the Archlinux repo's extra? http://www.go-mono.com/moonlight/ Moonlight is an open source implementation of Microsoft Silverlight for Unix systems. It's avaible for 32/64 bit! Release Notes Final release of Moonlight 1.0 Support for the Microsoft Media Pack Quick and easy installation of media codecs Several media releate bug fixes I hope one of the dev's like to pick this up.

13 20

Re: [arch-general] [arch-dev-public] Divide and Konquer - Splitting KDE packages
by Loui Chang 23 Jan '09

23 Jan '09

On Thu, Jan 22, 2009 at 07:35:45PM -0600, Aaron Griffin wrote: > Best I can do after some initial hacking. Are there any assumptions we > can make based on package name to trim the list so we don't have to > check all PKGBUILDs? > > This is done without a checkout of the full repo, using svn list and svn cat... > > $ ./pkgfind 3ddesktop #first package in the repos > Repo scan complete in 51ms > Package -> 3ddesktop/ > > $ ./pkgfind bash > Repo scan complete in 3809ms > Package -> bash/ > > $ ./pkgfind libpano13 #median package in the repos > Repo scan complete in 44170ms > Package -> libpano13/ > > $ ./pkgfind zsync #2nd to last package in the repos > Repo scan complete in 90997ms > Package -> zsync/ > > These numbers are just going to grow... And even more so when community packages are added... The svn repo needs a restructuring I think.

2 1