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

[arch-dev-public] [signoff] file-5.05-1
by Allan McRae 20 Jan '11

20 Jan '11

Fairly minor upstream update Signoff both, Allan

3 2

[arch-dev-public] Number of items in bug tracker rss feed
by Allan McRae 19 Jan '11

19 Jan '11

Hi, The current default of 10 is a bit low, as even someone who checks this as obsessively as me regularly runs into more than 10 bugs being filed between going to bed and waking up... Can a flyspray admin look to see if there is an option for bumping this? Up to 20 should be enough. Allan

2 1

[arch-dev-public] [signoff] lvm2/device-mapper 2.02.80-1
by Eric Bélanger 19 Jan '11

19 Jan '11

Hi, lvm2/device-mapper 2.02.80-1 is in testing for upstream update. Please test and signoff. Thanks, Eric

1 1

[arch-dev-public] Status of AUFS2.1
by Tobias Powalowski 17 Jan '11

17 Jan '11

Hi guys, i'm getting tired of building aufs2 into the standard kernel, there are no stable snapshots, everytime you need grab patches and at the moment the utils don't even build without any real reason. Can we ditch aufs2 support? Does archiso really need this filesystem? Thanks for clarification, i would be happy if we can remove this. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] [signoff] cracklib-2.8.18-1
by Tobias Powalowski 17 Jan '11

17 Jan '11

v2.8.18 also include stdlib.h in stringlib.c (Mike Frysinger) make sure python lib builds against build dir instead of system installed libs (Arfrever Frehtes Taifersar Arahesis) v2.8.17 fixed compilation on interix systems updated Hindi translation (Rajesh Ranjan) fixed NLS issue in cracklib-check add Ukrainian translation (Yuri Chornoivan) fix segmentation fault in Python extension (Peter Palfrader) add -Wall to AM_CFLAGS to discover possible programming errors (Jan Dittberner) updated Wei Liu (zh_CN) translation (Leah Liu) fixed NLS support in python module compilation (Mike Frysinger) Please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] pcre-8.12-1
by Allan McRae 17 Jan '11

17 Jan '11

Upstream update. Signoff both, Allan Version 8.12 15-Jan-2011 ------------------------ 1. Fixed some typos in the markup of the man pages, and wrote a script that checks for such things as part of the documentation building process. 2. On a big-endian 64-bit system, pcregrep did not correctly process the --match-limit and --recursion-limit options (added for 8.11). In particular, this made one of the standard tests fail. (The integer value went into the wrong half of a long int.) 3. If the --colour option was given to pcregrep with -v (invert match), it did strange things, either producing crazy output, or crashing. It should, of course, ignore a request for colour when reporting lines that do not match. 4. Another pcregrep bug caused similar problems if --colour was specified with -M (multiline) and the pattern match finished with a line ending. 5. In pcregrep, when a pattern that ended with a literal newline sequence was matched in multiline mode, the following line was shown as part of the match. This seems wrong, so I have changed it. 6. Another pcregrep bug in multiline mode, when --colour was specified, caused the check for further matches in the same line (so they could be coloured) to overrun the end of the current line. If another match was found, it was incorrectly shown (and then shown again when found in the next line). 7. If pcregrep was compiled under Windows, there was a reference to the function pcregrep_exit() before it was defined. I am assuming this was the cause of the "error C2371: 'pcregrep_exit' : redefinition;" that was reported by a user. I've moved the definition above the reference.

3 2

[arch-dev-public] [signoff] glibc-2.12.2-2
by Allan McRae 17 Jan '11

17 Jan '11

Fix a threading issue on x86_64: http://sourceware.org/bugzilla/show_bug.cgi?id=12403 i686 rebuild just to keep package versions the same. Signoff both, Allan

4 3

[arch-dev-public] libnl 2.0 rebuild
by Thomas Bächler 16 Jan '11

16 Jan '11

So, libnl 2.0 was declared stable in October as I just learned. These packages are compatible with libnl 2.0: - crda - iw - wpa_supplicant - hostapd These packages don't as far as I can see: - libpcap - networkmanager These I didn't check: - kismet - net-snmp - knemo - libvirt - simh Can the respective maintainers find out whether there are patches for libnl 2.0 support? I'd like to do the rebuild on the weekend. If we can't fix all packages, we could put a libnl1 package to [extra]. (If there are no patches, it seems that porting to libnl 2.0 is not that difficult, so we could do it ourselves and submit it)

3 5

Re: [arch-dev-public] [arch-notifications] Core/Extra Cleanup 15-01-2011
by Pierre Schmitz 16 Jan '11

16 Jan '11

On Sat, 15 Jan 2011 21:14:33 -0500 (EST), repomaint(a)archlinux.org wrote: > ==> WARNING: Repo [core] (i686) is already locked by root. > -> Retrying in 10 seconds... > ==> WARNING: Repo [core] (i686) is already locked by root. > -> Retrying in 10 seconds... > ==> WARNING: Repo [core] (i686) is already locked by root. > -> Retrying in 10 seconds... > ==> Removing old packages from [extra] (i686)... > -> libmpdclient-2.3-1-i686.pkg.tar.xz > ==> Removing old packages from [extra] (x86_64)... > -> libmpdclient-2.3-1-x86_64.pkg.tar.xz > ==> Removing old packages from package pool... > -> libmpdclient-2.3-1-i686.pkg.tar.xz > -> libmpdclient-2.3-1-x86_64.pkg.tar.xz > ==> WARNING: Repo lock [core] (i686) was not locked! > ==> WARNING: Repo lock [core] (x86_64) was not locked! > ==> WARNING: Repo lock [extra] (i686) was not locked! > ==> WARNING: Repo lock [extra] (x86_64) was not locked! > ==> WARNING: Repo lock [testing] (i686) was not locked! > ==> WARNING: Repo lock [testing] (x86_64) was not locked! > ==> WARNING: Repo lock [staging] (i686) was not locked! > ==> WARNING: Repo lock [staging] (x86_64) was not locked! > ==> WARNING: Repo lock [kde-unstable] (i686) was not locked! > ==> WARNING: Repo lock [kde-unstable] (x86_64) was not locked! > ==> WARNING: Repo lock [gnome-unstable] (i686) was not locked! > ==> WARNING: Repo lock [gnome-unstable] (x86_64) was not locked! Does anybody know what might have happened here? Maybe some kind of race condition I didn't think about yet? At first it was waiting for a lock being released by root (which is still fine) but at the end it looks like someone else unlocked all repos during that time which is definitely not fine. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

1 0

[arch-dev-public] Update tomcat from 5.5 to 6.0?
by Guillaume ALAUX 16 Jan '11

16 Jan '11

Hi everyone, User servernyc (gmail) flagged extra/tomcat as out-of-date and asked: "where is tomcat 6? any reason for 5.5 still?" I unflagged it as our tomcat package is currently from the 5.5 branch and is up to date on its branch but still his question is relevant. I think it is high time to make the move. Both branches 5.5 [0] and 6 [1] are widely used and considered stable. (I am currently working on both tomcat 5.5 and tomcat 6.0 packages built from source with dependencies extracted) So the feature request is "Update tomcat from 5.5 to 6.0". Has anyone got something against it? If no-one has, how to proceed regarding package names? - Rename "tomcat" to "tomcat5"? (careful because the 5.0 branch existed [2]) OR - Rename "tomcat" to "tomcat5.5"? AND - Use "tomcat" for 6.0 branch? OR - Create "tomcat6" for 6.0 branch? [0] http://tomcat.apache.org/download-55.cgi [1] http://tomcat.apache.org/download-60.cgi [2] http://archive.apache.org/dist/tomcat/tomcat-5/ -- Guillaume

4 5