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

[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] 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] [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] bash 4.0 / readline 6.0 rebuilds
by Aaron Griffin 28 Mar '09

28 Mar '09

So bash 4.0 is out, and there's lots of neat little changes, but this also requires readline 6.0, which is a big old nasty soname change. Unless anyone has any objections, I'd like to do these upgrades tonight and put everything in testing if it all goes as plans. Any problems with that? Packages affected, according to the web interface: * abook * afterstep * archboot * bash * bc * cdcd * clisp * device-mapper * freeciv * fvwm * fvwm-devel * gftp * gnuchess * gnutls * gphoto2 * gutenprint * hugs98 * inetutils * jack-audio-connection-kit * lftp * libxml2 * lua * maxima * mysql-clients * ntp * pal * php * pilot-link * postgresql-libs * python24 * r * ratpoison * rosegarden * ruby * socat * sqlite3 * sqlite3 (testing) * swi-prolog * tunepimp * uml_utilities * unixodbc * wvstreams

5 18

[arch-dev-public] Scim and arphic fonts update in [testing]
by Eric Bélanger 19 Mar '09

19 Mar '09

Hi all, I've just updated several scim-related packages. They are in the [testing] repo. The updated packages are: anthy libchewing libhangul scim scim-anthy scim-chewing scim-tables uim scim-uim (no update, just rebuild against uim 1.5.5) As I don't use these packages (I believe no dev use them either), I could only do minimal testing. It would be nice if users of these packages test them and report if they work properly or if there are problems with them. I've also updated (in [testing] repo) the Arphic fonts: ttf-arphic-ukai and ttf-arphic-uming There are two points about these fonts: 1. According to upstream: "This release contains Firefly's Bitmap fonts. The Bitmap fonts are available for 11, 12, 13, 14, 15 and 16 pixel and currently cover Big5 and GB2312. HKSCS is currently not supported as there are many more characters missing. So, for Big5 and GB2312 characters the bitmap glyphs should improve the rendering, but for all other characters, the rendering is the same like without bitmap glyphs." I might be nice to get comments about someone using these fonts to see if the ttf-fireflysung package is indeed no longer needed (http://bugs.archlinux.org/task/8951). 2. The updated ttf-arphic-* packages in testing provide the fonts as a TrueType Collection, i.e. the fonts come in 4 flavors (CN, HK, TW and TW MBE), with different glyph shapes according to the preferred shapes in each region (more info here: http://www.freedesktop.org/wiki/Software/CJKUnifonts/Download). As a result TeX users will encounter trouble using this font. The following programs/libraries are known to not fully support TTC files and can usually only use the first fontface of the TTC: - jdk and openjdk6 - imlib2 and applications which use imlib2. Again, I and probably none of the devs don't use these fonts so feedback from users would be nice. Eric

2 5

[arch-dev-public] Move the catalyst drivers from extra to AUR/Community
by Eduardo Romero 19 Mar '09

19 Mar '09

Here it is, Andreas Radke and I have talked about this and have come to a conclusion. The ATI catalyst drivers are in a pitiful state and AMD is doing close to nothing to improve the situation, they just take Linux as a joke. At least, that is the impression one gets when nvidia releases great drivers for Linux and ATI in the other hand is not showing any promises in making their drivers better and well supported. In the other hand the radeonhd driver, which is in extra shows some promise, and so far have been good, they have been able to make a good driver with only some documentation released by AMD, when AMD can't make one while being the makers, go figure out. This situation is worse in the x86_64 system, we have been stuck with catalyst 8.12 while i686 has 9.2 already, because AMD just wanted to break things at will, because their approach is very strange, break some things to improve others. That is why, we hope for a TU who can bring this drivers to community to raise his hand and help us with this task. Please, if you want to give catalyst the love they don't deserve but need, do not hesitate to offer yourself as the new maintainer. In the worse case scenario where no one raises his hand, the package should be moved to AUR. I personally would not want this, so please TUs respond. A TU will be able to do what is required for the best with this drivers, which includes making 9.2 and later work with x86_64. What do the other developers think? Any developer that wants to take care of them? PS: I do use this drivers, so I do care about them, but this is a choice that had to be made. Thanks, Eduardo "kensai" Romero

9 23

[arch-dev-public] new vi/vim/gvim
by Tobias Kieslich 11 Mar '09

11 Mar '09

Hi guys, just thought I'll let you know that the vi/vim/gvim layout will change again. After some slightly heated discussion and some thinking, I came to the conclusion that we could benefit from some different layout. I'll spare you all the reasons, here is some reading if you are really into it: http://bugs.archlinux.org/task/13109 http://bugs.archlinux.org/task/13239 http://bugs.archlinux.org/task/13240 The new layout is pretty much settled: nvi/core, provides vi,ex and view binary, really tiny vim/extra, only perl support, provides runtime, no X, no whistles gvim/extra, perl,python+ruby and gtk2, depends on vim, replaces the vim binary(as symlink) on install so your terminal vim is more powerful Benefits: - changes of (n)vi in core don't stall vim updates in extra - no vi runtime in core cuts down the install size (about 8MB compressed, 28 deflated) - we have a truely lightweight vim, it's something people really seem to want things left to figure out: I really, really hope the gvim package provides a binary that can be started as vim and runs in a terminal on a computer with no X/gtk2 installed ... I doubt it though. The reason is that I like to provide a fully scriptable vim for sysadmins that requires no X/GTK. Otherwise I could build the vim package with perl AND python support. It's not a big deal but it bumps the binary size from 1.5 MB to 4.5 ... that pretty big. Thoughts, opinions, complaints? -T

3 4

[arch-dev-public] [signoff] wpa_supplicant 0.6.8-1
by Thomas Bächler 10 Mar '09

10 Mar '09

wpa_supplicant declared the 0.6 branch as stable, changes compared to the old version are: - Disabled prism54, hostap, madwifi and IPW drivers, these should all be obsolete and work with the "wext" driver. If any problems occur, I can enable them again, but I think having only wext is enough. - Enabled the new nl80211 driver. This has additional features over the wext driver, like setting the country code (this driver currently only works with compat-wireless or maybe 2.6.29 release candidates) - Enabled readline support for wpa_cli - Enabled WPS (WiFi protected setup), I don't know if anyone really wants that, but it is there now. wpa_supplicant_gui has also been considerably improved. Please sign off.

4 11

[arch-dev-public] [signoff] coreutils 7.1-1
by Andreas Radke 10 Mar '09

10 Mar '09

This is the new release declared "stable" by upstream devs after "beta" 7.0 release we left out. I've added info file handling taking care of a possible missing texinfo not sure if it is needed. All patches have been updated to the latest Fedora/Gentoo versions. The formerly preset POSIX behavior should be obsolete now. "tail -x" works well here. Maybe you know for what case it was added in the past. Please do some tests and give me signoffs. -Andy * Noteworthy changes in release 7.1 (2009-02-21) [stable] ** New features Add extended attribute support available on certain filesystems like ext2 and XFS. cp: Tries to copy xattrs when --preserve=xattr or --preserve=all specified mv: Always tries to copy xattrs install: Never copies xattrs cp and mv accept a new option, --no-clobber (-n): silently refrain from overwriting any existing destination file dd accepts iflag=cio and oflag=cio to open the file in CIO (concurrent I/O) mode where this feature is available. install accepts a new option, --compare (-C): compare each pair of source and destination files, and if the destination has identical content and any specified owner, group, permissions, and possibly SELinux context, then do not modify the destination at all. ls --color now highlights hard linked files, too stat -f recognizes the Lustre file system type ** Bug fixes chgrp, chmod, chown --silent (--quiet, -f) no longer print some diagnostics [bug introduced in coreutils-5.1] cp uses much less memory in some situations cp -a now correctly tries to preserve SELinux context (announced in 6.9.90), doesn't inform about failure, unlike with --preserve=all du --files0-from=FILE no longer reads all of FILE into RAM before processing the first file name seq 9223372036854775807 9223372036854775808 now prints only two numbers on systems with extended long double support and good library support. Even with this patch, on some systems, it still produces invalid output, from 3 to at least 1026 lines long. [bug introduced in coreutils-6.11] seq -w now accounts for a decimal point added to the last number to correctly print all numbers to the same width. wc --files0-from=FILE no longer reads all of FILE into RAM, before processing the first file name, unless the list of names is known to be small enough. ** Changes in behavior cp and mv: the --reply={yes,no,query} option has been removed. Using it has elicited a warning for the last three years. dd: user specified offsets that are too big are handled better. Previously, erroneous parameters to skip and seek could result in redundant reading of the file with no warnings or errors. du: -H (initially equivalent to --si) is now equivalent to --dereference-args, and thus works as POSIX requires shred: now does 3 overwrite passes by default rather than 25. ls -l now marks SELinux-only files with the less obtrusive '.', rather than '+'. A file with any other combination of MAC and ACL is still marked with a '+'. * Noteworthy changes in release 7.0 (2008-10-05) [beta] ** New programs timeout: Run a command with bounded time. truncate: Set the size of a file to a specified size. ** New features chgrp, chmod, chown, chcon, du, rm: now all display linear performance, even when operating on million-entry directories on ext3 and ext4 file systems. Before, they would exhibit O(N^2) performance, due to linear per-entry seek time cost when operating on entries in readdir order. Rm was improved directly, while the others inherit the improvement from the newer version of fts in gnulib. comm now verifies that the inputs are in sorted order. This check can be turned off with the --nocheck-order option. comm accepts new option, --output-delimiter=STR, that allows specification of an output delimiter other than the default single TAB. cp and mv: the deprecated --reply=X option is now also undocumented. dd accepts iflag=fullblock to make it accumulate full input blocks. With this new option, after a short read, dd repeatedly calls read, until it fills the incomplete block, reaches EOF, or encounters an error. df accepts a new option --total, which produces a grand total of all arguments after all arguments have been processed. If the GNU MP library is available at configure time, factor and expr support arbitrarily large numbers. Pollard's rho algorithm is used to factor large numbers. install accepts a new option --strip-program to specify the program used to strip binaries. ls now colorizes files with capabilities if libcap is available ls -v now uses filevercmp function as sort predicate (instead of strverscmp) md5sum now accepts the new option, --quiet, to suppress the printing of 'OK' messages. sha1sum, sha224sum, sha384sum, and sha512sum accept it, too. sort accepts a new option, --files0-from=F, that specifies a file containing a null-separated list of files to sort. This list is used instead of filenames passed on the command-line to avoid problems with maximum command-line (argv) length. sort accepts a new option --batch-size=NMERGE, where NMERGE represents the maximum number of inputs that will be merged at once. When processing more than NMERGE inputs, sort uses temporary files. sort accepts a new option --version-sort (-V, --sort=version), specifying that ordering is to be based on filevercmp. ** Bug fixes chcon --verbose now prints a newline after each message od no longer suffers from platform bugs in printf(3). This is probably most noticeable when using 'od -tfL' to print long doubles. seq -0.1 0.1 2 now prints 2,0 when locale's decimal point is ",". Before, it would mistakenly omit the final number in that example. shuf honors the --zero-terminated (-z) option, even with --input-range=LO-HI shuf --head-count is now correctly documented. The documentation previously claimed it was called --head-lines. ** Improvements Improved support for access control lists (ACLs): On MacOS X, Solaris 7..10, HP-UX 11, Tru64, AIX, IRIX 6.5, and Cygwin, "ls -l" now displays the presence of an ACL on a file via a '+' sign after the mode, and "cp -p" copies ACLs. join has significantly better performance due to better memory management ls now uses constant memory when not sorting and using one_per_line format, no matter how many files are in a given directory od now aligns fields across lines when printing multiple -t specifiers, and no longer prints fields that resulted entirely from padding the input out to the least common multiple width. ** Changes in behavior stat's --context (-Z) option has always been a no-op. Now it evokes a warning that it is obsolete and will be removed.

4 7

[arch-dev-public] [signoff] e2fsprogs 1.41.4-1
by Thomas Bächler 05 Mar '09

05 Mar '09

Just a minor update. It is not really my package, but I noticed that resize2fs segfaulted and then I updated it and it works. Please sign off (I tested resize2fs on x86_64, seems fine so far).

3 2