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

[arch-dev-public] Fwd: lddd from devtools rewritten
by Allan McRae 28 Jul '09

28 Jul '09

Hi devs, I thought I would forward this here so we all see it. From my testing of this, it runs much faster (~5x) than the current lddd. It also gives me no false positives (although the results from the current lddd can be restored with the -L flag). I have not spent much time looking at the code, but this seems a great candidate to replace the current lddd after some review. Cheers, Allan -------- Original Message -------- I rewrote lddd from extra/devtools. The intent was to make it faster and remove false positives, as well as support for ignoring certain files completely, filtering the list of missing libs to handle optional dependencies, take /etc/ld.so.conf into account and in general make it more usable. NB: uses bash-4 features. URL: http://ino-waiting.gmxhome.de/files/lddd-c.sh Here's the help screen: $ lddd-c.sh -h Use lddd-c.sh [options] [paths] Default-paths: $PATH, /lib:/usr/lib:/opt/qt/lib:/opt/kde/lib:/usr/lib/libfakeroot:/opt/NX/lib:/usr/local/lib:/usr/local/libexec options: -d <item>: do not check glob <item>, can be given multiple times. -l <item>: ignore missing library glob <item>, multiple times. -L: do not use LD_LIBRARY_PATH running ldd(1)[1]. -v: be more and more chatty. -D <glob>: trigger tracing on meeting <glob>, debugging aid. Environment variables: $LDDD_LIB_IGNORE: globs of missing lib-names to ignore[2]. $LDDD_DONT_CHECK: globs of file names to completely ignore[2]. [1] risks false positives, but finds all broken ELF dependencies. [2] space separated list of globs, needs to be quoted to the shell. NB: A broken ELF file will be reported unless it is ignored ('-d' option or $LDDD_DONT_CHECK) or _ALL_ of its missing libs are ignored ('-l' or $LDDD_LIB_IGNORE)! _version: 20090727-2016_ The "new and improved" algorithm goes like this: 1. All files executable by the user or matching the customary *.so patterns are collected after verifying their ELFness. 2. The file paths are checked to see if their base directories contain any libraries and these directories are collected into LD_LIBRARY_PATH. 3. In a third loop, the files from step one are checked by ldd(1) prefixed with this LD_LIBRARY_PATH to see if any prerequisites are missing. This step is repeated without the path to check the odd customer. 4. Suspects aquired this way are sent to a co-process to determine the packages they belong to. 5. Results are collected into files in /tmp/lddd-c.sh-$UID and a summary listed to stdout. This makes it easy to use in cron-jobs. Detail is controlled by the number of '-v' options. Step four was intended to speed up the process, but as it turns out it doesn't help all that much. The pacman call is indeed expensive and can be done in parallel, but it obviously competes for disk access. Therefore the co-process caches the file list of any broken package expecting to find more broken files in it, but this only helps big packages with several broken executables. All in all lddd-c.sh is an improvement over the simpler lddd and the terribly hacked findbrokenpkgs[1]. As there should be no false positives, it should report b0rked packages after botched or incomplete updates in a reliable way. Valuable testing was done by Allan McRae and AttilaH. Some nasty bugs would still stink the code without their patience. [1] http://bbs.archlinux.org/viewtopic.php?id=13882 clemens

2 1

[arch-dev-public] general packaging question about symlinks
by Andreas Radke 28 Jul '09

28 Jul '09

we have a bugreport to change a relative symlink to an absolute symlink http://bugs.archlinux.org/task/14895. I don't really get the point where there difference will be and if the links would be broken when using different filesystems/partitions and links in itself. I'd like to hear your opinions for a general packaging rule. -Andy from coreutils info page: 12.2 `ln': Make links between files =================================== `ln' makes links between files. By default, it makes hard links; with the `-s' option, it makes symbolic (or "soft") links. Synopses: ln [OPTION]... [-T] TARGET LINKNAME ln [OPTION]... TARGET ln [OPTION]... TARGET... DIRECTORY ln [OPTION]... -t DIRECTORY TARGET... * If two file names are given, `ln' creates a link to the first file from the second. * If one TARGET is given, `ln' creates a link to that file in the current directory. * If the `--target-directory' (`-t') option is given, or failing that if the last file is a directory and the `--no-target-directory' (`-T') option is not given, `ln' creates a link to each TARGET file in the specified directory, using the TARGETs' names. Normally `ln' does not remove existing files. Use the `--force' (`-f') option to remove them unconditionally, the `--interactive' (`-i') option to remove them conditionally, and the `--backup' (`-b') option to rename them. A "hard link" is another name for an existing file; the link and the original are indistinguishable. Technically speaking, they share the same inode, and the inode contains all the information about a file--indeed, it is not incorrect to say that the inode _is_ the file. On all existing implementations, you cannot make a hard link to a directory, and hard links cannot cross file system boundaries. (These restrictions are not mandated by POSIX, however.) "Symbolic links" ("symlinks" for short), on the other hand, are a special file type (which not all kernels support: System V release 3 (and older) systems lack symlinks) in which the link file actually refers to a different file, by name. When most operations (opening, reading, writing, and so on) are passed the symbolic link file, the kernel automatically "dereferences" the link and operates on the target of the link. But some operations (e.g., removing) work on the link file itself, rather than on its target. The owner, group, and mode of a symlink are not significant to file access performed through the link. *Note Symbolic Links: (libc)Symbolic Links. Symbolic links can contain arbitrary strings; a "dangling symlink" occurs when the string in the symlink does not resolve to a file. There are no restrictions against creating dangling symbolic links. There are trade-offs to using absolute or relative symlinks. An absolute symlink always points to the same file, even if the directory containing the link is moved. However, if the symlink is visible from more than one machine (such as on a networked file system), the file pointed to might not always be the same. A relative symbolic link is resolved in relation to the directory that contains the link, and is often useful in referring to files on the same device without regards to what name that device is mounted on when accessed via networked machines. When creating a relative symlink in a different location than the current directory, the resolution of the symlink will be different than the resolution of the same string from the current directory. Therefore, many users prefer to first change directories to the location where the relative symlink will be created, so that tab-completion or other file resolution will find the same target as what will be placed in the symlink.

6 11

[arch-dev-public] [signoff] cryptsetup 1.0.7-1
by Thomas Bächler 26 Jul '09

26 Jul '09

New upstream release, tested and working on x86_64. Please sign off. cryptsetup 1.0.7 Release Notes (2009-07-22) =========================================== Changes since 1.0.7-rc1 - ----------------------- [committer name] * Allow removal of last slot in luksRemoveKey and luksKillSlot. [Milan Broz] * Add --disable-selinux option and fix static build if selinux is required. [Milan Broz] * Reject unsupported --offset and --skip options for luksFormat and update man page. [Milan Broz] Changes since 1.0.6 - ------------------- [committer name] * Various man page fixes. Also merged some Debian/Ubuntu man page fixes. (thanks to Martin Pitt) [Milan Broz] * Set UUID in device-mapper for LUKS devices. [Milan Broz] * Retain readahead of underlying device. [Milan Broz] * Display device name when asking for password. (thanks to Till Maas) [Milan Broz] * Check device size when loading LUKS header. Remove misleading error message later. [Milan Broz] * Add error hint if dm-crypt mapping failed. (Key size and kernel version check for XTS and LRW mode for now.) [Milan Broz] * Use better error messages if device doesn't exist or is already used by other mapping. [Milan Broz] * Fix make distcheck. (thanks to Mike Kelly) [Milan Broz] * Check if all slots are full during luksAddKey. [Clemens Fruhwirth] * Fix segfault in set_error (thanks to Oliver Metz). [Clemens Fruhwirth] * Remove precompiled pot files. Fix uninitialized return value variable in setup.c. [Clemens Fruhwirth] * Code cleanups. (thanks to Ivan Stankovic) [Clemens Fruhwirth] * Remove unnecessary files from po directory. They will be regenerated by autogen.sh. [Clemens Fruhwirth] * Fix wrong output for remaining key at key deletion. Allow deletion of key slot while other keys have the same key information. [Clemens Fruhwirth] * Add missing AM_PROG_CC_C_O to configure.in [Milan Broz] * Remove duplicate sentence in man page (thanks to Till Maas). [Milan Broz] * Wipe start of device (possible fs signature) before LUKS-formatting. [Milan Broz] * Do not process configure.in in hidden directories. [Milan Broz] * Return more descriptive error in case of IO or header format error. [Milan Broz] * Use remapping to error target instead of calling udevsettle for temporary crypt device. [Milan Broz] * Check device mapper communication and warn user in case the communication fails. (thanks to Milan Broz) [Clemens Fruhwirth] * Fix signal handler to proper close device. (thanks to Milan Broz) [Clemens Fruhwirth] * write_lseek_blockwise: declare innerCount outside the if block, add -Wall to the default CFLAGS, * fix some signedness issues (thanks to Ivan Stankovic) [Clemens Fruhwirth] * Error handling improvement. (thanks to Erik Edin) [Clemens Fruhwirth] * Add non-exclusive override to interface definition. [Clemens Fruhwirth] * Refactor key slot selection into keyslot_from_option. Either autoselect next free keyslot or honor user choice (after checking). [Clemens Fruhwirth]

2 1

[arch-dev-public] [signoff] readline-6.0.003-1
by Allan McRae 25 Jul '09

25 Jul '09

Bump upstream patch level, moved static libraries to /usr/lib Signoff both arches. Allan

5 4

[arch-dev-public] New namcap version
by Hugo Doria 25 Jul '09

25 Jul '09

Hi guys, I just released a new namcap version (2.3). These are the changes: namcap (2.3) - New tags: elffile-not-in-allowed-dirs (FS#15299) gnome-mime-file (checks for GNOME mime files) mime-cache-not-updated (checks for update-mime-database calls) hicolor-icon-cache-not-updated (FS#15028) insecure-rpath (FS#14049) non-fhs-info-page (FHS compliance of installed info pages) pkgname-in-description (pkgname should not be in description) potential-non-fhs-info-page - Removed tags: missing-cvs-id maintainer-tags-for-tus-devs cvs-id-for-tus-devs - Added rule to look for .a files with wrong permissions - Report dangling symlinks as an error (dangling-symlink) - Added sf.net urls in sfurl module. - Support machine-parseable tags (use -m to see them) - Add covered packages to dependencies - gnomemime uses /usr/share/ directory now - Removed obsolete module gnomemenu - Namcap now prints a warning if a package is empty - Prevent crash when namcap fails to open a file (FS#14371) - Script detection generalised, supports more scripts (FS#15160) - Documentation updates (manual page, AUTHORS, README) - Add an option to exclude some rules from the checks I would like to thanks Abhishek Dasgupta, who helped a lot and was very important to this release. If you find a bug or have a feature request, please, report it on our bug tracker. Don't be shy. :) -- Hugo

4 4

[arch-dev-public] Introducing capchroot
by Thomas Bächler 25 Jul '09

25 Jul '09

I don't know if you use dchroot or schroot. They're both tools that let a user chroot to a different directory. dchroot was easy to configure, but behaved weird: There was always some PAM message in the logs about 'su'. And it required root privileges through the setuid bit. dchroot is also discontinued. Now there is schroot. It seems awfully bloated, has unnecessary features like mounting filesystems when chrooting, running linux32 and whatnot. Configuration is complex, and it also has some weird interaction with PAM. schroot, like dchroot, requires root privileges through the setuid bit. I need a tool like this frequently, and was fed up with the above two. So I wrote my own. Features: - Lets an unprivileged user chroot to directories defined in /etc/capchroot.allow - Does nothing more than chroot, chdir and exec a program or shell, really! - Does not require root privileges, but only a kernel >=2.6.24, a filesystem with xattr support and the cap_sys_chroot capability set on its executable. This way, the only possible security problem is that a programming error might allow a user to bypass the restrictions in capchroot.allow and chroot to an arbitrary directory. I use it in a script like this: #!/bin/sh exec linux32 capchroot -d $PWD /mnt/arch32 -- "$@" My /home is mounted in /mnt/arch32/home, so changing the directory to $PWD after the chroot will actually work. Enough talk, if anyone finds it useful, here it is: http://dev.archlinux.org/~thomas/capchroot/ http://projects.archlinux.org/?p=users/thomas/capchroot.git;a=summary

1 0

[arch-dev-public] [signoff] openvpn 2.1_rc19-2
by Thomas Bächler 25 Jul '09

25 Jul '09

Tested on x86_64, please sign off. Fixes: - Upstream URL was wrong: http://repos.archlinux.org/viewvc.cgi/openvpn/trunk/PKGBUILD?r1=47204&r2=47… - Display of right configuration files on /etc/rc.d/openvpn stop: http://repos.archlinux.org/viewvc.cgi/openvpn/trunk/openvpn.rc?r1=47204&r2=… - Typo in the script that made it fail when one of the openvpn daemons wouldn't start. http://repos.archlinux.org/viewvc.cgi/openvpn/trunk/openvpn.rc?r1=47594&r2=… There is also another request here: http://bugs.archlinux.org/task/15673 The user says that not all /etc/openvpn/*.conf should be started, but there should be a configuration file that says which ones to start. I am against this, as it adds redundancy and the starting can be avoided by renaming the file to something not ending on .conf. What do you think?

1 0

[arch-dev-public] Updating ABS
by Allan McRae 25 Jul '09

25 Jul '09

There have been a lot of changes going on to the repos and ABS needs updated to reflect these. As it see it the following need fixed: 1) arch=('any') support Fix commited to git 2) split package support Currently the PKGBUILD is only found in /var/abs/$repo/$pkgbase. This would make it difficult to find a split package directly. Should the db-scripts add symlinks from $pkgbase to ${pkgname[@]}? That would have a bonus effect of reserving at the split package names. 3) community support I can see this being achieved in two ways - svn2abs is run on sigurd then rsynced to gerolde - svn2abs is run directly on gerolde (requires complete svn checkout on gerolde) The second is easier but uses a bit more resources. 4) community-testing support. Comes directly as part of #3 but will need to be added to the abs.conf file So should we do anything for #2 (requires changes to db-scripts) and which is the best way to go for #3? Allan

2 4

[arch-dev-public] Integrity Check i686 24-07-2009
by repomaint＠archlinux.org 24 Jul '09

24 Jul '09

====================================== = Integrity Check i686 of core,extra = ====================================== Performing integrity checks... ==> parsing pkgbuilds ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking for circular dependencies Mismatched Pkgnames --------------------- phonon vs. /srv/abs/rsync/i686//extra/phonon-xine Missing Dependencies ---------------------- archboot --> 'portmap>=6.0-2' archboot --> 'vim>=7.2.166-1' archboot --> 'rt2500>=1.1.0_B4-27' Missing Makedepends --------------------- gnome-themes-extras --> 'intltooll' v86d --> 'kernel26<2.6.30' gnome-speech --> 'espeak' Repo Hierarchy for Makedepends -------------------------------- core/crda depends on extra/python-m2crypto core/iputils depends on extra/opensp core/iputils depends on extra/libxslt core/iputils depends on extra/docbook-xsl core/e2fsprogs depends on extra/bc core/sqlite3 depends on extra/tcl core/ca-certificates depends on extra/ruby Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 1 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 6 Repo hierarchy problems: 7 Circular dependencies: 0

3 2

[arch-dev-public] Integrity Check x86_64 24-07-2009
by repomaint＠archlinux.org 24 Jul '09

24 Jul '09

======================================== = Integrity Check x86_64 of core,extra = ======================================== Performing integrity checks... ==> parsing pkgbuilds ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking for circular dependencies Mismatched Pkgnames --------------------- phonon vs. /srv/abs/rsync/x86_64//extra/phonon-xine Missing Dependencies ---------------------- archboot --> 'portmap>=6.0-2' archboot --> 'rt2500>=1.1.0_B4-27' Missing Makedepends --------------------- gnome-themes-extras --> 'intltooll' v86d --> 'kernel26<2.6.30' gnome-speech --> 'espeak' Repo Hierarchy for Makedepends -------------------------------- core/crda depends on extra/python-m2crypto core/iputils depends on extra/opensp core/iputils depends on extra/libxslt core/iputils depends on extra/docbook-xsl core/e2fsprogs depends on extra/bc core/sqlite3 depends on extra/tcl core/ca-certificates depends on extra/ruby Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 1 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 5 Repo hierarchy problems: 7 Circular dependencies: 0

1 0