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

[arch-dev-public] [signoff] kernel26 2.6.27.10-1
by Tobias Powalowski 23 Dec '08

23 Dec '08

Hi guys, new kernel adresses the following things: - bump to latest version Plan to avoid file conflict: - Move module-init-tools 2 weeks after .10 kernel moved to core. - Release a NEWS ITEM: Possible file confilct, while upgrading kernel26 2.6.27.10 and module-init-tools 3.5, please use 'pacman -Sf kernel26' to avoid warnings about existing module-init-tools files. any other suggestion? please signoff for both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [Fwd: Re: replace man with man-db?]
by Jan de Groot 22 Dec '08

22 Dec '08

This is what I got from the upstream man-db maintainer. -------- Forwarded Message -------- From: Colin Watson <cjwatson(a)debian.org> To: Jan de Groot <jan(a)jgc.homeip.net> Cc: arch-dev-public(a)archlinux.org Subject: Re: [arch-dev-public] replace man with man-db? Date: Mon, 22 Dec 2008 18:20:51 +0000 On Mon, Dec 22, 2008 at 07:03:19PM +0100, Jan de Groot wrote: > On Mon, 2008-12-22 at 18:57 +0100, Andreas Radke wrote: > > What's your opinion? Should we stay with "man" and fix what will be > > reported or satisfy the replacement request. > > > > I'd like to stay with our man until we can't fix something. > > If we want to switch to man-db, note that we have to update the man > database after installing a package with manpages. No, this is completely incorrect. It's no more true for man-db than for man. Both man and man-db maintain a database that's used by whatis and apropos. With man, you update it with makewhatis; with man-db, you update it with mandb. If you don't mind whatis and apropos being out of date until the database is next updated by a cron job or whatever, then it's absolutely fine to leave the database alone. You do *not* need to update man-db's database in order to read manual pages using man. In Debian, I arranged for the database to be updated after package installation once we gained the dpkg triggers mechanism so that this could be done reasonably non-intrusively, but this is a nicety. We got by just fine without doing that for well over a decade, and if it weren't the case that it's now really quite straightforward in Debian to keep the database up to date I'd be entirely happy to carry on the old way. > I'm not comfortable with updating every package in our repository with > such a command. It's entirely reasonable for you to be uncomfortable with that, but there's no reason why this should have the slightest bearing on whether you use man-db or man. Regards,

1 0

[arch-dev-public] replace man with man-db?
by Andreas Radke 22 Dec '08

22 Dec '08

This was brought up a while ago: http://bugs.archlinux.org/task/9130 There's a usable man-db pkg in AUR that could replace man in core after some testing. I haven't heard of many issues with localized man-pages. Reading around Gentoo and Fedora still use "man" while Debian only provides "man-db". There are many patches in the Fedora cvs to solve the claimed issues with man. We have not one bug report for our "man" package. What's your opinion? Should we stay with "man" and fix what will be reported or satisfy the replacement request. I'd like to stay with our man until we can't fix something. -Andy

4 7

[arch-dev-public] [signoff] tar 1.20-3
by Andreas Radke 22 Dec '08

22 Dec '08

this is only a minor rebuild adding info files and updating the man-page as requested in FS#12188. no new release expected in the new future. please signoff. -Andy

2 1

[arch-dev-public] We seek for you all day!
by arch-dev-public＠archlinux.org 22 Dec '08

22 Dec '08

1 0

[arch-dev-public] [signoff] sudo-1.7.0-1
by Allan McRae 21 Dec '08

21 Dec '08

Hi all, This is a major upstream update so test away. Allan Major changes between version 1.6.9p19 and 1.7.0: * Rewritten parser that converts sudoers into a set of data structures. This eliminates a number of ordering issues and makes it possible to apply sudoers Defaults entries before searching for the command. It also adds support for per-command Defaults specifications. * Sudoers now supports a #include facility to allow the inclusion of other sudoers-format files. * Sudo's -l (list) flag has been enhanced: - applicable Defaults options are now listed - a command argument can be specified for testing whether a user may run a specific command. - a new -U flag can be used in conjunction with sudo -l to allow root (or a user with sudo ALL) to list another user's privileges. * A new -g flag has been added to allow the user to specify a primary group to run the command as. The sudoers syntax has been extended to include a group section in the Runas specification. * A uid may now be used anywhere a username is valid. * The secure_path run-time Defaults option has been restored. * Password and group data is now cached for fast lookups. * The file descriptor at which sudo starts closing all open files is now configurable via sudoers and, optionally, the command line. * visudo will now warn about aliases that are defined but not used. * The -i and -s command line flags now take an optional command to be run via the shell. Previously, the argument was passed to the shell as a script to run. * Improved LDAP support. SASL authentication may now be used in conjunction when connecting to an LDAP server. The krb5_ccname parameter in ldap.conf may be used to enable Kerberos. * Support for /etc/nsswitch.conf. LDAP users may now use nsswitch.conf to specify the sudoers order. E.g.: sudoers: ldap files to check LDAP, then /etc/sudoers. The default is files, even when LDAP support is compiled in. This differs from sudo 1.6 where LDAP was always consulted first. * Support for /etc/environment on AIX and Linux. If sudo is run with the -i flag, the contents of /etc/environment are used to populate the new environment that is passed to the command being run. * Sudo now ignores user .ldaprc files as well as system LDAP defaults. All LDAP configuration is now in /etc/ldap.conf (or whichever file was specified by configure's --with-ldap-conf-file option). If you are using TLS, you may now need to specify: tls_checkpeer no in sudo's ldap.conf unless ldap.conf references a valid certificate authority file(s). * If no terminal is available or if the new -A flag is specified, sudo will use a helper program to read the password if one is configured. Typically, this is a graphical password prompter such as ssh-askpass. * A new Defaults option, "mailfrom" that sets the value of the "From:" field in the warning/error mail. If unspecified, the login name of the invoking user is used. * Resource limits are now set to the default value for the user the command is being run as on AIX systems. * A new Defaults option, "env_file" that refers to a file containing environment variables to be set in the command being run. * A new -n flag is available which may be used to indicate that sudo should not prompt the user for a password and, instead, exit with an error if authentication is required. * A new Defaults option, "sudoers_locale" that can be used to set the locale to be used when parsing the sudoers file. * sudoedit now checks the EDITOR and VISUAL environment variables to make sure sudoedit is not re-invoking itself (or sudo). This allows one to set EDITOR to sudoedit without getting into an infinite loop for programs that need to invoke an editor such as crontab(1). Also added SUDO_EDITOR environment variable which is used by sudoedit in preference to EDITOR/VISUAL. * The versions of glob(3) and fnmatch(3) bundled with sudo now support POSIX character classes. * If sudo needs to prompt for a password and it is unable to disable echo (and no askpass program is defined), it will refuse to run unless the "visiblepw" Defaults option has been specified. * Prior to version 1.7.0, hitting enter/return at the Password: prompt would exit sudo. In sudo 1.7.0 and beyond, this is treated as an empty password. To exit sudo, the user must now press ^C or ^D at the prompt.

2 1

[arch-dev-public] [signoff] kernel26 2.6.27.9-1
by Tobias Powalowski 21 Dec '08

21 Dec '08

Hi guys, new kernel adresses the following things: - bump to latest version please signoff for both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

9 13

[arch-dev-public] Let's meet as usually
by arch-dev-public＠archlinux.org 20 Dec '08

20 Dec '08

1 0

[arch-dev-public] About libcap
by Hugo Doria 19 Dec '08

19 Dec '08

I just adopted libcap and realized that it is really out-dated. Any reason for us use libcap 1.10 and grab it from kernel-2.4? http://www.kernel.org/pub/linux/libs/security/linux-privs/ http://www.archlinux.org/packages/extra/i686/libcap/ -- Hugo

2 2

[arch-dev-public] Python packaging policy
by Allan McRae 19 Dec '08

19 Dec '08

Hi all, A few recent bugs have highlighted issues with how we deal with compiled versions (.pyo/.pyc) of python (.py) files. We should probably make a policy on how these should be handled during packaging. Given I am the python maintainer, I suppose I should be doing this, but I am wanting to do some more makepkg/pacman stuff so it would be good if someone else wants to take the lead on this. Here is a couple of policies from other distros Debian: http://www.debian.org/doc/packaging-manuals/python-policy/ Fedora: https://fedoraproject.org/wiki/Packaging/Python If someone (not necessarily a dev) wants to help out with this, then it would be much appreciated. Thanks, Allan

2 5