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

[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] 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] 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

Re: [arch-dev-public] new vi/vim/gvim
by Tobias Kieslich 28 Apr '09

28 Apr '09

> > Has anything been decided with this? Apparently vim needs a patch to > build against the latest ruby which I was going to attempt updating soon. I'm just trying to give it a whirl on a testing box. The main issue is that the old package created a symlink that is not tracked by the version control at all. So before people can update to the new packages, they will have to remove one or two symlinks manually, which is ugly. -T

5 5

[arch-dev-public] [signoff] cracklib 2.8.13-2
by Hugo Doria 15 Apr '09

15 Apr '09

Added zlib as dependency (FS#13798) -- Hugo

2 3

[arch-dev-public] [core] lzo and pkg-config
by Jud 15 Apr '09

15 Apr '09

Hi all, In trying to be consistent with Arch's standard of naming packages the same as upstream, I have notice two packages that will need attention. lzo2 ==> lzo pkgconfig ==> pkg-config The old lzo was only required by transcode which is now fixed. Can the old lzo be moved into unsupported? lzo2 (required by): * archboot * lzop * mkvtoolnix * openvpn * transcode There seems to be a few packages that have 'pkgconfig' as a 'makedepends', this could easily be a one-off fix as needed when that particular package needs to be updated. pkgconfig (required by): * dssi * python-vpython This will be the last time I attach full PKGBUILDs, I'm off to try and learn SVN. Thanks.

4 9

[arch-dev-public] [signoff] libcap + rebuilds
by Hugo Doria 11 Apr '09

11 Apr '09

It is time to signoff libcap and all related rebuilds: * avahi * cdrkit * dovecot * libcap * muse * pinentry * pure-ftpd * samba * smbclient * vsftpd * wireshark Please, signoff for both arches. -- Hugo

3 8

[arch-dev-public] [signoff] libedit 20080712_2.11-3
by Hugo Doria 09 Apr '09

09 Apr '09

Fixing FS#13567 - libedit man page symlinks are broken -- Hugo

2 3

[arch-dev-public] [signoff] isdn4k-utils-3.2p1-5
by Allan McRae 09 Apr '09

09 Apr '09

Signoff for isdn4k-utils - License rebuild - Fix man location Needs an x86_64 builder. Allan

2 1