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

[arch-dev-public] [signoff] syslog-ng 3.0.4-3
by Paul Mattal 26 Feb '10

26 Feb '10

This version adds more log files to syslog-ng's logrotate script, and should be the only difference. Log files added since released 3.0.4-1: /var/log/crond.log /var/log/lpr.log /var/log/uucp.log /var/log/news.log /var/log/ppp.log /var/log/debug.log Eric also requested I add /var/log/acpid.log, but it was already there. Please signoff, 1 for each architecture. - P

3 3

[arch-dev-public] postfix 2.7.0 in testing for both arches
by Paul Mattal 26 Feb '10

26 Feb '10

I'll leave it in [testing] for 1 week to catch any gotchas. If no serious issues are identified by then, I will move it to [extra]. - P

1 0

[arch-dev-public] Replace Planet with Planet-Venus? (WAS: [arch-general] Planet Arch Linux atom feed)
by Andrea Scarpino 26 Feb '10

26 Feb '10

On Sunday 21 February 2010 03:07:45 gt wrote: > Yes, they simply show the website instead of the particular article. while > other feeds take to the specific article on the website. Maybe i am not > able to explain it clearly, but i think you can try it yourself, even with > firefox live bookmarks. I mean each entry in a feed has a link, but the > link on the problematic feed is simply > http://planet.archlinux.org/atom.xml > > So clicking on it sort of makes an endless loop, and to read the full > article i have to manually open the planet arch website and then go the > respective (only problematic ones) blog from there. To fix this and future issue, we could switch to planet-venus. Planet is not developed anymore and development is focused on this "new" project. I already set up a local installation of planet-venus and Atom feeds work fine. You can try it here: http://dev.archlinux.org/~andrea/planet/archplanet/output -- Andrea `bash` Scarpino Arch Linux Developer

3 2

[arch-dev-public] Namcap/XZ compatibility (was: Accept any *.pkg.tar.* package file name)
by Dan McGee 26 Feb '10

26 Feb '10

On Sun, Feb 21, 2010 at 11:15 PM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > Am Montag, 22. Februar 2010 05:33:56 schrieb Dan McGee: >> >> > Another thing: it was mentionned on the IRC channel that namcap >> >> > doesn't work with the new xz packages. It would be nice to have xz >> >> > support in namcap before we start pushing these changes out. >> >> >> >> Yeah, this is IMHO a blocker to going gung-ho on this. It is not going >> >> to be super-easy either as we use python's built-in archive support >> >> that doesn't know about XZ as far as I know... >> > >> > Why not? Just call bsdtar to extract the tar somewhere. This way you >> > don#t have to worry how the package is compressed. >> >> Maybe you can get away with this in a shell script, but no one is >> happy with this BS in a python program. Or at least I wouldn't be, but >> feel free to send a patch to the namcap maintainer since it is so >> easy. I'll be impressed when you fix every check that uses >> tar.getmembers() too... > > What's wrong with you? That was meant as a serious question. I am not familiar > with the namcap python code. Sorry if I came across as snarky, but it drives me crazy when people make unfeasible suggestions without looking at the completely open code first. Namcap does a lot more than simply look at an extracted set of files, a lot of which requires access to the tar metadata. My point was only to say "this isn't as easy as you make it out to be". > I don't really want to drop the idea of xz compressed packages just because > python does not support it. I'm not advocating that, I can assure you. I am glad Allan came up with that link showing that XZ support in Python does have some traction upstream. > It might sound silly but the probably easiest solution might be to modify > namcap to support uncompressed tar archives. Then we can add a simple Bash > wrapper script which uncompresses the package and calls namcap with the pure > tar. Looking at the code, there is nothing preventing this right now- we just use a generic tar interface which will support any compression or no compression at all. -Dan

2 3

Re: [arch-dev-public] Fwd: Re: Fwd: Perl packaging guidelines.
by Firmicus 25 Feb '10

25 Feb '10

Forwarding again --------------------------------------- Hi Firmicus, Thanks for forwarding my previous message. Here's the follow-up. Firmicus wrote: > >>> Two follow-up questions: > >>> Do you at least support the idea of renaming CPAN packages with > >>> non-standard names to their standard names? > >>> > Example? > >>> If not, what about including the standard name in the provides array? > >>> > Makes sense. glib-perl -> perl-glib gtk2-perl -> perl-gtk2 perlio-* -> perl-perlio-* These are just a few examples from my system. I'm sure that there are others. At least we agree that the "proper" name should be provided if it doesn't match the pkgname. > >>> If pacpan didn't include the individual modules in the arrays but > >>> instead mapped them all to their distribution, how would you see the > >>> matter then? > >>> > Not sure I understand... pacpan maps all modules to their distributions. If I removed modules from the provides|depends|makedepends|optdepends arrays and replaced them with their corresponding distributions, would you support the recommendation of using pacpan as a starting point for packaging CPAN packages for pacman? This would still provide the advantage of using upstream metadata to create the default PKGBUILDS (including depends, makedepends, optdepends and provides). I think specifiy modules explicitly is the better way, but I think this would be better than nothing. Ignore this for now actually. I don't want to split the discussion into one about renaming existing packages. That's probably worth its own thread and will just mix up the arguments for and against pacpan. > Back to the issue of the provides array: I do see the advantage. My > point is that in many cases, including ALL modules in there leads to > things like this: > http://aur.archlinux.org/packages/perl-kiokudb/perl-kiokudb/PKGBUILD > which looks insane to me! And do we really want the PKGBUILD of > perl-datetime-timezone to provide all modules listed here: > http://search.cpan.org/~drolsky/DateTime-TimeZone-1.10/ ? > > In comparision the traditional approach is cleaner, for instance here: > http://aur.archlinux.org/packages/perl-catalyst-runtime/perl-catalyst-runti… > (for which pacpan would have created a very long string of modules in > the provides array). I don't really see the problem with this. If you had to enter that by hand then yes, it would be tedious, but generating such arrays programmatically eliminates that issue. To me this is like arguing against the inclusion of all locales in locale.gen because it makes the list too long and nobody uses most of them. I just don't see that as a real argument. > Note that in the above two examples all dependencies are versioned, > which makes Allan fume :) More often than not, this introduces needless > problems, so yes, Allan is right on this. OTOH there are many > "bleeding-edge" modules on CPAN than do require very recent versions of > other modules to work properly, so there would be a clear downside in > getting rid of them... There are enough distributions/modules in CPAN that specify specific versions of modules that I feel their inclusion in the provides array is justified. If pacman's provides array isn't meant to list the packages and their versions provided by a package, then what is it meant for? The only real argument I can see here is one of overhead, but isn't most of the overhead in opening the file? How much more is there from reading a few extra lines? > Perhaps I am just being too conservative... I do understand Xyne's > point: if the module Catalyst::Foo::Bar in the distribution > Catalyst-FooStuff which is packaged as perl-catalyst-foostuff were > eventually to become part of perl-catalyst-runtime, then having it in > the provides array would indeed be of some help. But in real life such > situations occur very rarely. And this extra metadata in the PKGBUILD is > convenient mainly for the ideal situation where everything is fully > automated, which is not very realistic, as errors also creep in the CPAN > metadata and human beings still have to fix those things manually. The > human packager should review the generated PKGBUILDs anyway. That's why I've used the term "starting point" throughout this discussion. I know that CPAN's metadata is not always correct and that the PKGBUILDs created using that metadata thus require intervention sometimes. Most of the time though the PKGBUILD is fine, and in the few cases when it isn't, it usually only requires a few tweaks. It very rarely fails miserably (in some cases when it does, it even includes a prominent warning in the generated PKGBUILD. That said, the provides array never fails because it's generated from the database that I create, which in turn is generated by mapping modules to common source files and thus distributions. Thus in the event that the PKGBUILD is incomplete, the packager doesn't have to manually enter the provides. The missing information is the information that he/she would have had to enter without pacpan anyway. So far these are the pros and cons that I see of the proposed approach: PROS: *) robust and explicit dependency resolution *) follows CPANs convention (they specify modules as dependencies, not distributions) *) uses pacman's built-in functionality *) enables pacman's searches to find modules *) automated (intervention will still be required occasionally) CONS: *) slight increase in overhead for pacman (negligible?) *) PKGBUILD arrays will be huge in some cases Regards, Xyne

2 1

[arch-dev-public] [signoff] e2fsprogs 1.41.10
by Ronald van Haren 25 Feb '10

25 Feb '10

please signoff for both architectures. Ronald Local changes: - FS#18043: add com_right_r() function for heimdal Upstream Changes: ix resize2fs bug which causes it to access invalid memory. Add libss support for libreadline.so.6. Fix e2fsck's check for extent-mapped directory with an incorrect file type. Add new e2fsck.conf configuration option, default/broken_system_clock to support systems with broken CMOS hardware clocks. Also, since too many distributions seem to have broken virtualization scripts now, e2fsck will by default accept dates which are off by up to 24 hours by default. (Addresses Debian Bugs: #559776, #557636) Fix a bug where mke2fs may not use the best placement of the inode table when there is only room for a single block group in the last flex_bg. E2fsck is now smarter when it needs to allocate blocks in the course of fixing file system problems. This reduces the number of spurious differences found in pass #5. E2fsck will no longer rehash directories which fit in a single directory block. E2fsck now correctly handles holes in extent-mapped directories (i.e., sparse directories which use extents). Fix big-endian problems with ext2fs_bmap() and ext2fs_bmap2(). Fix a bug in filefrag where on platforms which can allow file systems with 8k blocks, that it doesn't core dump when it sees a file system with 8k block sizes. (Thanks to Mikulas Patocka for pointing this out.) E2fsck will correctly fix directories that are have an inaccurate i_size as well as other problems in a single pass, instead of requiring two e2fsck runs before the file system is fully fixed. Fix e2fsck so it will correctly find and detect duplicate directory entries for non-indexed directories. ( Addresses Sourceforge Bug: #2862551) Mke2fs will use BLKDISCARD to pre-discard all blocks on an SSD or thinly-provisioned storage device. This can be disabled using the -K option. Enhance libext2fs so it works around bug in Linux version 2.6.19 and earlier where the /proc/swaps file was missing the header on the first line. Fix bug in Linux version 2.6.19 and earlier where the /proc/swaps file was missing the header on the first line. Fix some big-endian bugs in e2fsck and libext2fs. Fix resize2fs so it works correctly on file systems with external journals instead of failing early with the error "Illegal inode number". Fix libss so that it does not seg fault when using a readline library which does not supply a readline_shutdown() function. Updated dumpe2fs's usage message so it correctly gives the right arguments summary for "-o superblock=<num>" and "-o blocksize=<num>". (Addresses Launchpad Bug: #448099) Teach libext2fs to ignore the high 32 bits of the i_blocks field when huge_file file system feature is set, but the inode does not have the HUGE_FILE_FL flag set. Fix e2fsck's handling of 64-bit i_blocks fields. E2fsck will now print "Illegal indirect block", "Illegal double-indirect block", etc., instead of "Illegal block #-1" or "Illegal block #-2", etc. This makes it easier for users to understand what has gone wrong. (Addresses SourceForge Bug: #2871782) Mke2fs now will obtain get device topology information from blkid and use it to populate the superblock stride and stripe sizes. It will also warn if the block device is misaligned Fix file descriptor leaks in fsck and debugfs. (Addresses Novell Bug: ##524526) Fix the libext2fs library code to round up the bitmap size to a 4-byte boundary, to prevent spurious seg faults caused by the x86 architecture. This doesn't affect Linux systems, but was a major problem on a number of *BSD systems. (Addresses Sourceforge Bug: #2328708) Fix resize2fs's minimum size required for a file system so it doesn't fail when "resize2fs -M" is run. (Addresses RedHat Bugzilla: #519131) Dumpe2fs now prints summary information about the contents of the journal. Avoid printing scary error messages when e2fsck starts running problems on low-memory systems, as it tends to panic and mislead the user. (Addresses Debian Bug: #509529) Fix blkid's modules.dep parser so it handles compressed (.ko.gz) modules files. (Address Red Hat Bug: #518572) Fix tune2fs so it can add a journal when an extent-enabled file system is mounted. (Addresses Launchpad bug: #416648) Update Czech, Indonesian, Polish and Vietnamese translations (from the Translation Project). Update/clarify man pages. (Addresses Sourceforge Bug: #2822186) Fixed various Debian packaging issues --- see debian/changelog for details. (Addresses Debian Bugs: #540111)

3 3

[arch-dev-public] sudo-1.7.2p4-1
by Allan McRae 25 Feb '10

25 Feb '10

Security fix release: A flaw in exists in sudo's -e option (aka sudoedit) in sudo versions 1.6.9 through 1.7.2p3 that may give a user with permission to run sudoedit the ability to run arbitrary commands. Fast signoffs would be appreciated. Signoff both, Allan

3 2

[arch-dev-public] [signoff] iputils-20100214-2
by Tobias Powalowski 25 Feb '10

25 Feb '10

Hi, fixed missing manpages. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

Re: [arch-dev-public] [arch-general] [PATCH 4/4] ftpdir-cleanup: lock repo before doing the cleanup
by Eric Bélanger 25 Feb '10

25 Feb '10

On Wed, Feb 24, 2010 at 8:52 PM, Evangelos Foutras <foutrelis(a)gmail.com> wrote: > On Thu, Feb 25, 2010 at 3:36 AM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: > <snip> >> for arch in ${ARCHES[@]}; do >> >> + IS_LOCKED=0 >> + count=0 >> + while [ $count -le $LOCK_TRIAL ]; do >> + if repo_lock $reponame $arch ; then >> + IS_LOCKED=1 >> + let count=$LOCK_TRIAL+1 >> + continue > > I'd just use a 'break' here, instead of making the conditional > expression false and jumping to the check again. You're right. That's what I intended to do but I couldn't remember the name of the command. ;) I'll wait for other feedback before making a new patch. Also, for LOCK_TRIAL and LOCK_DELAY I chose what I believe is a sane default, i.e. try every 10 seconds for 1 minute. These could be tweaked of course. BTW, I also removed some trailing spaces. That's why some lines in the patch don't appear to have any changes. > >> + fi >> + sleep $LOCK_DELAY >> + let count=$count+1 >> + done >> + >> + if [ $IS_LOCKED -eq 0 ]; then > <snip> > > Thanks for creating this patch. :) >

1 0

[arch-dev-public] [signoff] kernel 2.6.32.9-1
by Tobias Powalowski 24 Feb '10

24 Feb '10

Hi guys, bump to latest bugfix version. Please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 4