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

[arch-dev-public] Integrity Check x86_64: core, extra, community 26-02-2010
by repomaint＠archlinux.org 26 Feb '10

26 Feb '10

================================================== = Integrity Check x86_64 of core,extra,community = ================================================== Performing integrity checks... ==> parsing pkgbuilds ==> parsing db files ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking hierarchy ==> checking for circular dependencies ==> checking for differences between db files and pkgbuilds Missing Dependencies ---------------------- community/airsnort --> 'wlan-ng26-utils' community/sysprof-module --> 'kernel26<2.6.' Missing Makedepends --------------------- core/dash --> 'klibc>=1.5' Repo Hierarchy for Dependencies --------------------------------- extra/pan depends on community/gmime22 (0 extra (make)deps to pull) Repo Hierarchy for Makedepends -------------------------------- core/ca-certificates depends on extra/ruby (25 extra (make)deps to pull) core/crda depends on extra/python-m2crypto (26 extra (make)deps to pull) core/e2fsprogs depends on extra/bc (0 extra (make)deps to pull) core/groff depends on extra/ghostscript (137 extra (make)deps to pull) core/groff depends on extra/netpbm (45 extra (make)deps to pull) core/groff depends on extra/psutils (138 extra (make)deps to pull) core/iputils depends on extra/docbook-xsl (26 extra (make)deps to pull) core/iputils depends on extra/libxslt (25 extra (make)deps to pull) core/iputils depends on extra/opensp (30 extra (make)deps to pull) core/sqlite3 depends on extra/tcl (0 extra (make)deps to pull) core/udev depends on extra/gobject-introspection (26 extra (make)deps to pull) core/udev depends on extra/gperf (0 extra (make)deps to pull) core/udev depends on extra/libxslt (25 extra (make)deps to pull) core/udev-compat depends on extra/gobject-introspection (26 extra (make)deps to pull) core/udev-compat depends on extra/gperf (0 extra (make)deps to pull) core/udev-compat depends on extra/libxslt (25 extra (make)deps to pull) extra/bigloo depends on community/jdk (1 extra (make)deps to pull : jre) extra/dbus-python depends on community/docutils (0 extra (make)deps to pull) extra/gnome-speech depends on community/espeak (2 extra (make)deps to pull : portaudio docutils) extra/grml-zsh-config depends on community/txt2tags (0 extra (make)deps to pull) extra/opengtl depends on community/llvm (0 extra (make)deps to pull) extra/xqf depends on community/chrpath (0 extra (make)deps to pull) Packages found in db, but not in tree --------------------------------------- community/chicken Packages found in tree, but not in db --------------------------------------- community/kbd-ru-keymaps Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 3 Repo hierarchy problems: 23 Circular dependencies: 0 In db, but not in tree: 1 In tree, but not in db: 1

1 0

[arch-dev-public] Fwd: FS#17503: [unzip] zsh completion missing for unzip patches
by Thayer Williams 26 Feb '10

26 Feb '10

Hoping for some feedback here from more experienced devs on this one: At some point we began patching unzip with additional flags, allowing it to properly extract UTF-encoded zip files made on the win32 platform. Apparently this has broken zsh autocompletion features. Similar unzip patches have been submitted upstream and all have been rejected. Upstream has considered adding proper support, but has stopped short of committing to it. The question is do we keep the patch and make this a zsh issue, or do we remove the patch, fixing zsh in the process and screwing some win32 zip files? More info: http://bugs.archlinux.org/task/17503 http://bugs.archlinux.org/task/15256

2 6

Re: [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 Friday 26 February 2010 13:28:44 Pierre Schmitz wrote: > I am fine with this. I am using it at al.de for some time now. I would > suggest to create a git repo for it. Yes, I also think that a git repo is a good idea. Who can set up one? -- Andrea `bash` Scarpino Arch Linux Developer

1 0

[arch-dev-public] [signoff] dcron 4.4-2
by Paul Mattal 26 Feb '10

26 Feb '10

This release addresses a number of packaging issues: * eliminates the logrotate script (now integrated into syslog-ng) * warns to restart crond on update to 4.x from earlier major ver * adds /etc/conf.d/crond for managing commandline options * adds patch to declare LOGNAME env var to be same as USER env var Please signoff, 1 for each arch. - P

3 3

[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