Arch-dev-public April 2009

arch-dev-public@lists.archlinux.org

32 participants
107 discussions

[arch-dev-public] request: xz-utils into core
by Andreas Radke 31 May '09

31 May '09

Am Sat, 3 Jan 2009 08:31:55 -0600 schrieb "Dan McGee" <dpmcgee(a)gmail.com>: > On Sat, Jan 3, 2009 at 6:00 AM, Andreas Radke <a.radke(a)arcor.de> > wrote: > > I'd like to keep unneeded packages out of core. I see no need to > > move lzma into core. We only support tar.gz for our repos. Whoever > > wants to use a different format can rebuild libarchive easily. > > > > I also wonder if our new tar package now supports lzma and lzop > > compression (no tests so far). Both packages were not present when > > building the tar package in he chroot. But even when it's now > > possible to use these formats at runtime they should stay in extra > > until we may use them for our repos. > > I don't want to go too back and forth on this on the signoff thread so > I'll move it here. > > I was thinking much more in the context of archives in general rather > than just pacman using libarchive. libarchive ships with bsdtar, which > I have found to be quicker than GNU tar at extracting (so I use it > nearly exclusively). It would be a shame to tell people "we don't > support .tar.lzma for anything"- that seems rather arbitrary, doesn't > it? > > I too think [core] should stay as slim as possible, but when that > requires we compile our packages with a less than ideal set of > features, I want to at least give it some thought. > > -Dan > I've found more and more gnu tools being shipped in the new xz file format. So may I request now to move lzma-utils' successor http://tukaani.org/xz/ to be put into testing for some time and later to core? (lzma-utils is François' pkg right now) -Andy

6 7

[arch-dev-public] LZMA - in or out? ([signoff] libarchive 2.6.0)
by Dan McGee 12 May '09

12 May '09

On Sat, Jan 3, 2009 at 6:00 AM, Andreas Radke <a.radke(a)arcor.de> wrote: > I'd like to keep unneeded packages out of core. I see no need to move > lzma into core. We only support tar.gz for our repos. Whoever wants to > use a different format can rebuild libarchive easily. > > I also wonder if our new tar package now supports lzma and lzop > compression (no tests so far). Both packages were not present when > building the tar package in he chroot. But even when it's now possible > to use these formats at runtime they should stay in extra until we may > use them for our repos. I don't want to go too back and forth on this on the signoff thread so I'll move it here. I was thinking much more in the context of archives in general rather than just pacman using libarchive. libarchive ships with bsdtar, which I have found to be quicker than GNU tar at extracting (so I use it nearly exclusively). It would be a shame to tell people "we don't support .tar.lzma for anything"- that seems rather arbitrary, doesn't it? I too think [core] should stay as slim as possible, but when that requires we compile our packages with a less than ideal set of features, I want to at least give it some thought. -Dan

11 23

[arch-dev-public] Status of arch=any ?
by Firmicus 06 May '09

06 May '09

IIRC Abishek and Aaron have been recently working to implement "arch=any" in devtools etc. May I kindly ask about the current status of that? If there's any work you would like to me to do, I might be able to give a hand. I'm asking because I am about to do a mass update of the texlive packages, and that feature would be very convenient as all texlive packages save one are arch-independent. Some of them can also be very large (e.g. texlive-fontsextra with 136MB). So my question is: if the implementation of the arch=any feature is more or less imminent, I might wait before uploading the new texlive packages... Cheers F

2 8

[arch-dev-public] ttf-ms-fonts (WAS: Re: [pacman-dev] [PATCH] New feature: files verification)
by Thomas Bächler 04 May '09

04 May '09

Eric Bélanger schrieb: >>> I added this because of some fonts package which has files in /tmp. >> If a package has files in /tmp, it should be reported here, as it is >> definitely a bug in the package! It is not pacman's responsibility to fix >> this, but the packager's. >> > > I guess he's talking about ttf-ms-fonts. The files that initially get > installed in /tmp are extracted/installed properly afterwards by the > .install script. I'm not sure why this is done but it might be a > license restriction. That package has no place in Arch anyway. It's non-free, unnecessary and improperly packaged. There are good alternatives (ttf-freefont should be okay, also the standard Xorg fonts are enough IMO). AUR has a proper package for this, so people who need it can build that. I say we drop it, as it does not meet Arch's packaging standards.

4 7

[arch-dev-public] ffmpeg and x264 update/rebuild in testing
by Eric Bélanger 04 May '09

04 May '09

Hi, I've just put an updated ffmpeg and x264 in testing. I've updated ffmpeg to the latest stable version (0.5) that was released recently and x264 was updated to the latest snapshot. The x264 library has a soname bump so the following packages have been rebuilt: mplayer avidemux gstreamer0.10-bad-plugins vlc opal Because the ffmpeg version scheme change (20090217 -> 0.5) was causing problem on pacman update, I also had to rebuild the following packages to change their ffmpeg versioned dependency: cmus k3b motion nuvexport sox transcode xine-lib Some notes: - nuvexport was out-of-date so I updated it. - Concerning mplayer, I haven't done any changes related to the GUI. However, I changed the libcaca makedepends to a depends. Please test and report any problems.

1 2

[arch-dev-public] our FAT support and Microsoft
by Andreas Radke 03 May '09

03 May '09

http://www.linux-foundation.org/weblogs/jzemlin/2009/03/31/on-the-tomtom-se… I haven't done further investigations but it seems we should take care about keep supporting the FAT file system. How is the state with NTFS? Is the license situation there more safe? Opinions? -Andy

11 14

[arch-dev-public] Fixing licenses / sources
by Aaron Griffin 02 May '09

02 May '09

On Thu, Feb 26, 2009 at 12:57 PM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: > On Tue, Feb 17, 2009 at 6:00 PM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: >> Please check /var/log/sourceballs/ to see if some of your packages are >> there. These failures cause a slow down of the script. The script now >> runs in 30 min compared to the few hours it took when I first started >> the tests. Please post here if you can fix your packages sometime this >> week. If not, post anyway. This way we'll know what packages are >> taken care off. >> >> BTW, fssos-nsvs will need to be rebuild to fix the license among other >> things. But it doesn't build anymore (latest version is from 2005). I >> have an updated PKGBUILD if you want to give it a shot. >> And I'm upgrading openal so leave that to me. >> >> If you are interested (and have time) in helping out for steps 2 & 3 >> that I mentionned earlier in this thread, post here. This way we'll >> know who will work on this and we'll be able to organize ourselves. >> You can count me in although an upcoming faad2 rebuild (and perhaps an >> ffmpeg/x264 update/rebuild) will probably take most of my time this >> week. >> >> Eric >> > > A week has passed and still no volunteers? Anyway, I've kept myself > busy lately by updating out-of-date orphaned packages, fixing their > licenses and other stuff as needed. I 've also started fixing the > packages in /var/log/sourceballs/. Changing the subject and ML to make this more visible Please take a look at the packages that fail in /var/log/sourceballs If any of your packages are there, please fix them so that "makepkg --allsource" works. Additionally, please check ftp://ftp.archlinux.org/sources/failed.txt ftp://ftp.archlinux.org/sources/errors.txt [1] for additional failures 1: This output sucks. I've committed a fix for it, but it's not released

5 27

[arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages
by Allan McRae 01 May '09

01 May '09

Hi all, The gcc-4.4.0 toolchain rebuild is now in [testing]. Here is a rough ChangeLog: kernel-headers: - upstream updated (2.6.29.1) glibc: - update cvs snapshot from 2.9 branch - removed glibc-2.5-localedef_segfault-1.patch (old and appears fixed upstream) - removed glibc-2.7-bz4781.patch (rejected upstream as bug in gcc - Andy: please check if your issue is solved) - compress info pages - fix info page handling in install script binutils: - update cvs snapshot from 2.19 branch - remove texinfo dep through install script - add upstream patch to improve -Wl,--as-needed usage - add linker scripts for libbfd.so and libopcodes.so - compress info pages gcc-libs - new makedepends (ppl and cloog-ppl) - removed unneeded bison build patch - removed treelang (done upstream) gcc - removals as in gcc-libs - added dependencies on new packages ppl and cloog-ppl (for graphite optimizations) - update libstdc++ man pages - install license exception - compress info pages I am having great difficultly getting a working gcc-gcj... It builds fine using the gcc-gcj-4.3.x package but when I rebuild eclipse-ecj with the freshly built 4.4.0 package, I can not rebuild gcc-gcj again. Updating eclipse-ecj to the latest build does not fix the issue. After two and a half days of trying to track this down, I am ready to give up. If someone else wants to look at this, go ahead but... Do we really need gcc-gcj, eclipse-ecj and java-gcj-compat any more? Reason I see for removing it: - I can't get it to build - java-gcj-compat provides java-runtime, but I checked six packages in the repos against this and none actually fully worked - which also is very bad as it is the first package found by pacman for java-runtime - we have a free java now in openjdk6 Opinions? Allan

3 5

[arch-dev-public] [signoff] kernel-2.6.29.2-1
by Tobias Powalowski 01 May '09

01 May '09

Hi update 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

5 5

[arch-dev-public] go-openoffice to testing/extra
by Andreas Radke 01 May '09

01 May '09

I'd like to bring the Novell "fork" of OpenOffice.org to testing and later to extra. But it's not (yet) a real fork. More a major improvement in features and lower packager maintenance. It also allows installation into /usr instead of /opt. Beside Novell/SuSE also Gentoo, Frugalware, ArkLinux and Debian use it as their main office suite. It has some additional features (svg support, multimedia for presentations, faster startup and kde(3) integration, hopefully later easy splitted packages). But main reason is faster integration of fixes and features. Not one additional patch is required to build it :) See http://go-oo.org/discover/ for more. I'm still unsure if it will become an additional flavor of OOo in our repos or if I will make it later a complete replacement of the Vanilla Sun OpenOffice for ArchLinux. It also gives our devs and community members an easier way to contribute to go-oo, e.g. you can help porting for KDE4 integration that is still in (so they told me) unusable state. Any objections adding go-openoffice? -Andy (technical note: build requirements are even higher than for vanilla OOo, 13gb space proved to be no more enough space to build this monster... - have fun with 'abs')

8 12

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-dev-public April 2009