Bug#567618: Analysis/fix for grub-probe failing to identify filesystem
This is a bug in upstream grub2 code, as follows: In short, it's failing to read the start of a partition that begins on a sector that is not a multiple of 8, and the fallback code is buggy. In kern/disk.c's grub_disk_read function, an attempt is made to pull the requested sector out of the cache. For any partition type (eg. ext2) which wants a sector within the first 8 of the partition, but not the first, a disk->dev->read call is made below the comment "/* Otherwise read data from the disk actually. */" for the relevant grub-cache-block-sized block (4096 bytes, 8 sectors). This fails under Linux for partitions that do not start on multiples of 8 for the first sectors of the partition because grub (in util/hostdisk.c's open_device) want to read from the partition device, not the disk device, when reading a partition's data (for caching reasons according to the comment) The fallback code (if the if-test of the above-mentioned read call) then attempts to read just the desired sector or sectors, but when it then attempts to grub_memcpy the result into the input buffer (directly before the comment "/* Call the read hook, if any. */" it copies from too far into the resulting buffer. The fix is to remove "+ pos" from this grub_memcpy, and the previous setting of num (between grub_errno = GRUB_ERR_NONE; and p = grub_realloc). (The num setting causes it to read more sectors than necessary, but is otherwise harmless.) That's lines 444 and 461 of http://bzr.debian.org/loggerhead/pkg-grub/trunk/grub/annotate/head:/kern/disk.c revision 1967. pos is the byte offset of the desired sector within the cache-block, and at this point in the code path we are no longer within a cache-block, so adding pos is incorrect. http://bzr.debian.org/loggerhead/pkg-grub/trunk/grub/revision/1855.8.227 is the change that I think introduced this bug, although presumably it was trying to fix another bug... I can't see a bug in the upstream tracker for this. This doesn't affect grub during boot, only when running under Linux (as this fallback path should only be taken in those circumstances) -- Paul "TBBle" Hampson, paul.hamp...@pobox.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#480052: ctypes FTBFS is bug in libffi-dev
This bug is actually a correct test-case failure due to bug #480208 in libffi-dev. I'm not reassigning or merging this with that, I'll leave that up to the maintainer/submitter to decide. But once #480208 is fixed, a binNMU will resolve this bug. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpzBIdKKkWQY.pgp Description: PGP signature
Bug#456914: ia32-libs: Missing shlibs entry for libxml2
OK, I've had a look at the ia32-libs package, and the sed script for fixing the shlibs files is presumably broken, as it generates those two lines in the shlibs file without a library. I replaced the two sed calls around line 90 of debian/rules with this: sed -e "s/^\(\(udeb: \)*[^ ]* *[^ ]* *\)$*.*$$/\1$(notdir $(DEST)) (>= $(SHLIB_VERSION))/" And it seems to work, producing the following diff from the installed 2.2 to the rebuilt package: --- /var/lib/dpkg/info/ia32-libs.shlibs 2007-12-19 00:21:26.0 +1100 +++ debian/ia32-libs/DEBIAN/shlibs 2008-01-16 12:12:08.0 +1100 @@ -93,7 +93,7 @@ libQtOpenGL 4 ia32-libs (>= 1.6) libQtAssistantClient 4 ia32-libs (>= 1.6) libQtDesigner 4 ia32-libs (>= 1.6) -ia32-libs (>= 1.6) +libsane 1 ia32-libs (>= 1.6) libsasl2 2 ia32-libs (>= 1.6) libSDL-1.2 0 libsdl1.2debian (>= 1.2.10-1) libsigc-2.0 0 ia32-libs (>= 1.6) @@ -119,7 +119,7 @@ libXft 2 ia32-libs (>= 1.6) libXi 6 ia32-libs (>= 1.6) libXinerama 1 ia32-libs (>= 1.6) -ia32-libs (>= 1.6) +libxml2 2 ia32-libs (>= 1.6) libXmu 6 ia32-libs (>= 1.6) libXmuu 1 ia32-libs (>= 1.6) libXp 6 ia32-libs (>= 1.6) So that seems to fix the two occurances of bad shlibs lines, and should hence fix the wine build. I guess the udeb: could really be [^ ]*:, but I dunno if that syntax is generic in shlibs files, or an exception for udebs. And in fact, udebs support here is probably wrong, since udebs built under -m32 would end up with dependancies on ia32-libs rather than the original -udeb package. I'm not totally sure the should be left alone, either. It just looks messy all over, maybe it'd be best to strip udeb: lines? Regardless of udebs, this change looks to only be improvements to me. I hope this change or equivalent can go in soonish so I can stop rebuilding the wine package locally. ^_^ -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpzDpQvz8kdh.pgp Description: PGP signature
Bug#457557: wine: FTBFS on amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ove Kaaven wrote: > Paul TBBle Hampson skrev: >> If I understand the last comment correctly, configure is still being run >> because on x86_64 debian/rules still sets NATIVE_BUILD = build32, and >> the build-indep-stamp depends on $(subst >> build,configure,$(NATIVE_BUILD)) (which turns out to be "configure32") >> which runs configure since DEB_SAVEBUILD isn't set. > I thought autobuilders didn't have to run build-indep, since it's only > used for Arch: all packages, which only have to be built once for all, > and this is done by the package maintainer. Do they really run it? I think they don't _have_ to, but the AMD64 builder for the -1 and - -2 versions of 0.9.51 (according to buildd.debian.org) ran debian/rules build, rather than just debian/rules build-arch It _does_ only run the binary-arch rule, rather than the full binary rule. I just checked policy, and build-arch and build-indep are optional rules, so I guess sbuild doesn't check for them before running the build rule... - -- - --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ - --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHcvzeexDuohKLFuARAt/ZAKCnMFtGj4N6SaYs67kJPDTSQR2AcwCfRTOL 9xGqkcmQs4ItT2nOrLOThOM= =2Ccz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457557: wine: FTBFS on amd64
If I understand the last comment correctly, configure is still being run because on x86_64 debian/rules still sets NATIVE_BUILD = build32, and the build-indep-stamp depends on $(subst build,configure,$(NATIVE_BUILD)) (which turns out to be "configure32") which runs configure since DEB_SAVEBUILD isn't set. After it runs configure (at least on my laptop) it then happily extracts the tarball and builds packages, so it's almost working fine. (Although I can't actually vouch for the other comments in this bug regarding dependancies or gendeps.sh, it seems to work here but I haven't looked too hard, since it seems to just work) -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpfmRqLbttcB.pgp Description: PGP signature
Bug#415116: Patch to upgrade Horde 3's /tmp cleanup script
tags 415116 +patch Thankyou This is simply a diff between 3.1.3 and 3.1.4 with the patch from the .diff.gz. It fixes the problem whereby a specially-created file in /tmp could allow arbitrary deletion of files by being broken up into space- delimited results by the for loops. The upstream changes are at [1]. It also adds the 'Files from cancelled imports' check, which may or may not be appropriate for a security fix. [1] http://cvs.horde.org/diff.php?r1=1.1.12.1&r2=1.1.12.2&f=horde%2Fscripts%2Ftemp-cleanup.cron --- horde3-3.1.3/scripts/temp-cleanup.cron 2007-03-24 22:15:09.0 +1100 +++ horde-3.1.4/scripts/temp-cleanup.cron 2007-03-24 22:35:08.0 +1100 @@ -24,26 +24,19 @@ echo ${TMP_DIR:=/tmp} > /dev/null # MSWord attachments (generated by the MSword viewer) -for MSWORD_FILE in `find $TMP_DIR -type f -name msword\* -ctime +2 `; do - rm -f $MSWORD_FILE -done +find $TMP_DIR -type f -name msword\* -ctime +2 -exec rm -f {} \; # IMP attachments -for IMP_FILE in `find $TMP_DIR -type f -name impatt\* -ctime +2 `; do - rm -f $IMP_FILE -done +find $TMP_DIR -type f -name impatt\* -ctime +2 -exec rm -f {} \; # Klutz temporary files -for KLUTZ_FILE in `find $TMP_DIR -type f -name Klutz\* -ctime +2 `; do - rm -f $KLUTZ_FILE -done +find $TMP_DIR -type f -name Klutz\* -ctime +2 -exec rm -f {} \; # Spell checking temporary files -for SPELL_FILE in `find $TMP_DIR -type f -name spell\* -ctime +2 `; do - rm -f $SPELL_FILE -done +find $TMP_DIR -type f -name spell\* -ctime +2 -exec rm -f {} \; # VFS temporary files -for IMP_FILE in `find $TMP_DIR -type f -name vfs\* -ctime +2 `; do - rm -f $IMP_FILE -done +find $TMP_DIR -type f -name vfs\* -ctime +2 -exec rm -f {} \; + +# Files from cancelled imports +find $TMP_DIR -type f -name import\* -ctime +2 -exec rm -f {} \; -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpmYKVUVyamB.pgp Description: PGP signature
Bug#413968: [php-maint] xmlrpc-epi turns out to be libxmlrpc in php
On Sun, Mar 11, 2007 at 01:56:42PM +0100, sean finney wrote: > On Sun, 2007-03-11 at 17:44 +1100, Paul TBBle Hampson wrote: >> I'm suggesting either. I'm happy to maintain the package seperately, but >> I intend to go through the differences between the versions and confirm >> that they are compatible, and steal anything good from the php-bundled >> version, so in effect I'd be doing both. I'd also have to track upstream >> PHP in case they add anything else to the library in the future. So >> maybe a PHP package team member might want to be a co-maintainer... > okay, perhaps we can revisit this after you're done. if you decide to > use the upstream version we can see how hard it is to build php against > that instead of the bundled code. if you decide you want to use the > php-bundled version, then we should probably just generate it from the > php5 source package directly. i don't use this extension myself, so in > any event it would be wise to find someone who does so we can test that > it still works :) I've uploaded a test version to http://www.tbble.net/debian/xmlrpc-epi/. It's almost but not quite ready for sponsorship. I've not yet reinstalled pbuilder after my last server hard disk crash, so the build-depends aren't set yet. I suspect it's only missing libexpat-dev, but want to be sure. Also, I've not included the samples in the .debs. I'd like to get the compliance-tests run during build, but see below... I've also only built it on PowerPC; the pbuilder will be on i386, and if I have the time, I can get access to an AMD64 machine next week to do a test-build there. I did a file-by-file comparison with the PHP5 code, and the only differences I didn't bring across were whitespace, // => /* comment replacement and the xmlrpc_win32 header. If anyone's available to do a test-build against PHP5, that'd be great, otherwise it'll have to wait until I have the time, sometime this week, given a following wind. On a side-note, the server compliance tests fail, expecting an i4 tag but getting an int tag from the server, as well as large whitespace changes. The latter is prolly due to the much more recent expat library, the former is a mystery to me, but I suspect it is actually a change in the spec that post-dates the compliance-test creation. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpvHm8exbTNg.pgp Description: PGP signature
Bug#413968: [php-maint] xmlrpc-epi turns out to be libxmlrpc in php
On Sun, Mar 11, 2007 at 01:56:42PM +0100, sean finney wrote: > On Sun, 2007-03-11 at 17:44 +1100, Paul TBBle Hampson wrote: >> I'm suggesting either. I'm happy to maintain the package seperately, but >> I intend to go through the differences between the versions and confirm >> that they are compatible, and steal anything good from the php-bundled >> version, so in effect I'd be doing both. I'd also have to track upstream >> PHP in case they add anything else to the library in the future. So >> maybe a PHP package team member might want to be a co-maintainer... > okay, perhaps we can revisit this after you're done. if you decide to > use the upstream version we can see how hard it is to build php against > that instead of the bundled code. if you decide you want to use the > php-bundled version, then we should probably just generate it from the > php5 source package directly. i don't use this extension myself, so in > any event it would be wise to find someone who does so we can test that > it still works :) Well, my plan was to effectively use the php5 version (since it's the main place the code's being actively used) but treat it as the upstream version with patches. If the package was generated straight out of the PHP source, it'd miss the samples and tests included in the upstream tarball. (Not that I've run the tests myself yet, the first roll of the package was pretty quick 'n' dirty.) >> A quick poke around the Internet suggested that the only patches being >> made by other distros to xmlrpc-epi are for gcc4, 64-bit and expat, but >> I haven't looked at the PHP-bundled version's changes yet, apart from >> verifying that the .h files match semanticly. > did you check that visually, or did you use a utility like icheck? Visually: [EMAIL PROTECTED]:~/code/php/php5-5.2.0/ext/xmlrpc/libxmlrpc$ for d in *.h; do diff ~/code/xmlrpcepi/build/xmlrpc-epi-0.51/src/$d $d; done 79,80c79,80 < intQ_Iter_Put(q_iter qi, void* data); // not read only! here for completeness. < void* Q_Iter_Del(queue *q, q_iter iter); // not read only! here for completeness. --- > intQ_Iter_Put(q_iter qi, void* data); /* not read only! here for > completeness. */ > void* Q_Iter_Del(queue *q, q_iter iter); /* not read only! here for > completeness. */ 161c161 < xml_element* xml_elem_new(); --- > xml_element* xml_elem_new(void); 43a44,48 > /* allow version to be specified via compile line define */ > #ifndef XMLRPC_LIB_VERSION > #define XMLRPC_LIB_VERSION "0.51" > #endif > 48c53 < #define XMLRPC_VERSION_STR "xmlrpc-epi v. " VERSION --- > #define XMLRPC_VERSION_STR "xmlrpc-epi v. " XMLRPC_LIB_VERSION 302c307 < XMLRPC_CASE XMLRPC_GetDefaultIdCase(); --- > XMLRPC_CASE XMLRPC_GetDefaultIdCase(void); 304c309 < XMLRPC_CASE_COMPARISON XMLRPC_GetDefaultIdCaseComparison(); --- > XMLRPC_CASE_COMPARISON XMLRPC_GetDefaultIdCaseComparison(void); 326c331 < XMLRPC_VALUE XMLRPC_CreateValueEmpty(); --- > XMLRPC_VALUE XMLRPC_CreateValueEmpty(void); 376c381 < XMLRPC_REQUEST XMLRPC_RequestNew(); --- > XMLRPC_REQUEST XMLRPC_RequestNew(void); 386,387c391,392 < XMLRPC_SERVER XMLRPC_ServerCreate(); < XMLRPC_SERVER XMLRPC_GetGlobalServer(); /* better to use XMLRPC_ServerCreate if you can */ --- > XMLRPC_SERVER XMLRPC_ServerCreate(void); > XMLRPC_SERVER XMLRPC_GetGlobalServer(void); /* better to use > XMLRPC_ServerCreate if you can */ 407c412 < const char* XMLRPC_GetVersionString(); --- > const char* XMLRPC_GetVersionString(void); diff: /home/tbble/code/xmlrpcepi/build/xmlrpc-epi-0.51/src/xmlrpc_win32.h: No such file or directory -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpK29xrF41d9.pgp Description: PGP signature
Bug#413968: [php-maint] xmlrpc-epi turns out to be libxmlrpc in php
On Sat, Mar 10, 2007 at 06:19:09PM +0100, sean finney wrote: > hi paul, > On Sun, 2007-03-11 at 03:05 +1100, Paul TBBle Hampson wrote: >> Would there be any interest in having PHP5 link its xmlrpc extension >> against a distinct library packaging of xmlrpc-epi? (ie. to avoid >> the situation which once existed for zlib being statically compiled >> into various other packages, causing security headaches...) > just to clarify, are you proposing that php link against an externally > provided xmlrpc-epi library, or are you proposing that php provide its > bundled version *as* the xmlrpc-epi library for other apps to use? i'm > fairly open to both ideas though i think the former sounds better than > the latter, assuming there are no api/abi differences. also, are you > volunteering to do the packaging? :) I'm suggesting either. I'm happy to maintain the package seperately, but I intend to go through the differences between the versions and confirm that they are compatible, and steal anything good from the php-bundled version, so in effect I'd be doing both. I'd also have to track upstream PHP in case they add anything else to the library in the future. So maybe a PHP package team member might want to be a co-maintainer... A quick poke around the Internet suggested that the only patches being made by other distros to xmlrpc-epi are for gcc4, 64-bit and expat, but I haven't looked at the PHP-bundled version's changes yet, apart from verifying that the .h files match semanticly. Hmm, I'd better check this now, all the files in the libxmlrpc directory carry the same copyright headers as the upstream xmlrpc-epi distribution (BSD-like), does the PHP license override them and prevent debundling? I'd like to keep the distinct package under its upstream license if possible, as it's very very permissive, and the seconde-life client is GPLd. -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- pgp8YXc3VGmF6.pgp Description: PGP signature
Bug#413968: xmlrpc-epi turns out to be libxmlrpc in php
(For the php-maint team. I've just ITP'd xmlrpc-epi as a dependancy of the second-life client, and was poking around to see if there was a good way of not having to package it.) Interestingly, the code in ext/xmlrpc/libxmlrpc in the php5 5.2.0 tarball is a derivative of xmlrpc-epi. A quick check of the headers indicates no API changes (just some ANSI C fixes). I haven't looked at the code changes yet, but I'm not expecting anything API-breaking. (I'd read on the site that it went into PHP 4.1, but I'd not clicked that meant the actual xmlrpc-epi source had slipped into the PHP tree, nor did I realise PHP5 was still using it, since I thought they'd rewritten the xmlrpc extension in PHP5...) The PHP5 version compiles the xmlrpc-epi code plus the PHP5 extension code xmlrpc-epi-php.c together into one .so file. Would there be any interest in having PHP5 link its xmlrpc extension against a distinct library packaging of xmlrpc-epi? (ie. to avoid the situation which once existed for zlib being statically compiled into various other packages, causing security headaches...) xmlrpc-epi seems like a useful standalone library to me, since (unlike libxmlrpc-c3) it doesn't include a network transport layer, allowing the actual transport to be handled by the user, and it's in C (unlike libxmlrpc++). And second-life client will be user number 2, that I know of. Of course, if PHP5 was using an external xmlrpc-epi library, it would have to be something other than /usr/lib/libxmlrpc.so, as that's already taken by libxmlrpc-c3. Interestingly Mandriva and PLD both consider libxmlrpc-epi to be /usr/lib/libxmlrpc.so and libxmlrpc-c3 is instead /usr/lib/libxmlrpc-c.so. Gentoo appears to be happy to have them both be libxmlrpc.so, and FreeBSD's ports collection conflicts them. So the naming field is wide open. I'm leaning towards libxmlrpc-epi.so I plan to go through the changes to the library in PHP5 and see if there's anything that would preclude general use. I suspect many of the .c changes were the result of either bugfixes that I want, or the conversion to use a modern expat API rather than the API circa 2000, which I've also done to my copy of xmlrpc-epi. On a side note, config.m4 in ext/xmlrpc is currently forcing the xmlrpc-epi version to 0.50, even though comments in the code in the libxmlrpc directory indicate it was later synced up with 0.51 (the last upstream release of xmlrpc-epi). -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpHWjZLIxXp9.pgp Description: PGP signature
Bug#411438: vlc: FTBFS (powerpc): x264's ppc/quant.h does not #include altivec.h
Package: vlc Version: 0.8.6.a.debian-1 Severity: serious Tags: patch Justification: no longer builds from source Changeset 621 [1] in the upstream x264 subversion tree appears to fix this, dated three weeks after 0.8.6a was released. [1] http://trac.videolan.org/x264/changeset/621 -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpXcxIiBDZu3.pgp Description: PGP signature
Bug#395034: Bug affects all autobuilt arches
tags 395034 -patch Thankyou On Wed, Jan 10, 2007 at 01:36:20PM +1100, Paul TBBle Hampson wrote: > According to packages.debian.org, every arch except i386 has > this bug. > The bug is really that install_text is being run which puts > stuff in /usr/share/doc/4Suite. Actually, the bug is just exposed by doing that. Here's the relevant chunk from the buildd: dh_installchangelogs -a dh_link -a And here's the failure my patched caused on a local build: dh_installchangelogs -i for pkgname in python-4suite-xml python-4suite-rdf python-4suite-server; do \ cat "debian/${pkgname}/usr/share/doc/4Suite/COPYRIGHT" >>"debian/${pkgname}/usr/share/doc/${pkgname}/copyright"; \ rm "debian/${pkgname}/usr/share/doc/4Suite/COPYRIGHT"; \ mv "debian/${pkgname}/usr/share/doc/4Suite/"* "debian/${pkgname}/usr/share/doc/${pkgname}" 2>/dev/null; \ rm -r "debian/${pkgname}/usr/share/doc/4Suite"; \ done cat: debian/python-4suite-xml/usr/share/doc/4Suite/COPYRIGHT: No such file or directory rm: cannot remove `debian/python-4suite-xml/usr/share/doc/4Suite/COPYRIGHT': No such file or directory rm: cannot remove `debian/python-4suite-xml/usr/share/doc/4Suite': No such file or directory cat: debian/python-4suite-rdf/usr/share/doc/4Suite/COPYRIGHT: No such file or directory rm: cannot remove `debian/python-4suite-rdf/usr/share/doc/4Suite/COPYRIGHT': No such file or directory rm: cannot remove `debian/python-4suite-rdf/usr/share/doc/4Suite': No such file or directory cat: debian/python-4suite-server/usr/share/doc/4Suite/COPYRIGHT: No such file or directory rm: cannot remove `debian/python-4suite-server/usr/share/doc/4Suite/COPYRIGHT': No such file or directory rm: cannot remove `debian/python-4suite-server/usr/share/doc/4Suite': No such file or directory make: *** [binary-indep] Error 1 So the fix is to move the for pkgname lines from the binary-indep rule to the binary-arch rule in debian/rules, as they operate on the Arch: any packages. So that's an easy fix. ^_^ -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpXJvbPjmVMt.pgp Description: PGP signature
Bug#395034: Bug affects all autobuilt arches
tags 395034 +patch Thankyou According to packages.debian.org, every arch except i386 has this bug. The bug is really that install_text is being run which puts stuff in /usr/share/doc/4Suite. i386 build doesn't even have this directory. Well, hurd-i386 doesn't have it either... I don't know why people's local builds are working... Check your logs for "running install_text"... Anyway, here's a dpatch to try (not tested, I don't have an autobuilder ^_^) -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. #! /bin/sh -e ## 21-stdint-include.dpatch by Matthias Klose <[EMAIL PROTECTED]> ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Don't install stuff into /usr/share/doc/4Suite if [ $# -lt 1 ]; then echo "`basename $0`: script expects -patch|-unpatch as argument" >&2 exit 1 fi [ -f debian/patches/00patch-opts ] && . debian/patches/00patch-opts patch_opts="${patch_opts:--f --no-backup-if-mismatch} ${2:+-d $2}" case "$1" in -patch) patch -p1 ${patch_opts} < $0;; -unpatch) patch -R -p1 ${patch_opts} < $0;; *) echo "`basename $0`: script expects -patch|-unpatch as argument" >&2 exit 1;; esac exit 0 @DPATCH@ --- ./4Suite/setup.py.org 2007-01-10 13:27:33.0 +1100 +++ ./4Suite/setup.py 2007-01-10 13:27:36.0 +1100 @@ -38,7 +38,7 @@ ], # Used by Windows binary installer (bdist_inno) -license_file='COPYRIGHT', +#license_file='COPYRIGHT', # Fields used in package metadata 1.0 (PEP 241 / Python 2.1+): name='4Suite', --- ./4Suite/packages/Xml.pkg.org 2007-01-10 13:27:47.0 +1100 +++ ./4Suite/packages/Xml.pkg 2007-01-10 13:28:27.0 +1100 @@ -206,7 +206,7 @@ ] doc_files = [ -File('README'), +#File('README'), Document('docs/xml/index.doc', 'sdocbook', title='4Suite Documentation Index', pgpE1rXanUTYC.pgp Description: PGP signature
Bug#405606: Ayiya bug?
On Tue, Jan 09, 2007 at 09:24:55PM +0100, Pim van Pelt wrote: > On Tue, Jan 09, 2007 at 05:06:06PM +0100, Pim van Pelt wrote: || On Wed, Jan 10, 2007 at 12:32:23AM +1100, Paul TBBle Hampson wrote: | || (CC list trimmed to those relevant to the bug) || I've bounced this to Jeroen, who has better judgment on these || things than I do. > Jeroen suggests that he has changed more things than just what you > mention. He prefers a full integrate of our 20070107 release, amongst > others because we relicensed it and would prefer to see all > distributions using the same source. Ubuntu, Fedora, Redhat, OpenWRT > and Free/Net/OpenBSD (*) have taken the 20070107 release. We recommend that > Debian jump on the bandwagon. Fair 'nuff. I can't see the other changes in the Ayiya code, but I've only had one look at it so far. I guess this is staying out of Etch then, and until either the maintainer does a new upload or someone NMUs or takes over the package, it'll stay broken in Sid. -- ----------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpRaZ39wvcpo.pgp Description: PGP signature
Bug#405606: Ayiya bug? (Was: aiccu is now under 3-clause BSD license)
(CC list trimmed to those relevant to the bug) On Mon, Jan 08, 2007 at 02:03:53PM +0100, Pim van Pelt wrote: > Hoi, > On Mon, Jan 08, 2007 at 12:13:13AM -0800, Steve Langasek wrote: || So I'd say releasing it in main is still an option, *if* someone were || interested in a targetted fix and thought that would be a supportable || configuration. > To recap, the most important goal for us is to get the old version > out of Debian. If that could be done for the Etch release, that'd be > good. If there is anything I or SixXS can do to help this, let me know. I've just been having a look at the difficulty of the targetted fix. Am I right in my understanding that the bug is trimming the 4 bytes from the start of the packet in the reader is only needed on the BSD platforms, but the old version does it on any non-DARWIN, non-WIN32 platform? The only other differences that I can see are that there is now a heartbeat for Ayiya, a slight structure change which may or may not be hidden by not packing the struct, and the change in port number. All four of these are trivial to produce a targetted patch for... Am I on the right track, or have I missed something? (There's also a good bit of refactoring work done, but I think I've followed it all OK...) -- ----------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpsWbo7mh9Wq.pgp Description: PGP signature
Bug#403426: cryptsetup/linux-image-2.6.18-3-ixp4xx buglog divergence
Just poking around for low-hanging RC fruit... This bug appears to me to have split into three seperate bugs: cryptsetup bug, when given bad data upgrade-header code corrupts header This seems to be serious, and the point of #403426 On the other hand, if this bug only triggers when the kernel page caching gets boned, it's probably not serious against cryptsetup, but is the fault of the next bug. Either way, fixed by the changes in rev20 upstream SVN, or the 1.0.5 release. linux-image-2.6.18-3-ixp4xx bug, LUKS (and FUSE?) triggers page-cache corruption. This one seems critical, but has known fixe in flush_anon_page-generic.patch and flush_anon_page-arm.patch in debian-kernel SVN. linux-image-2.6.18-3-ixp4xx bug, LUKS (but not FUSE?) fails to mount under heavy load. This seems less than serious (it's not actively corrupting data from what I'm reading in the buglog) but prolly should be a seperate bug for tracking purposes. Anyway, from the looks of things there ought to be three seperate bugs here, #403426 against cryptsetup, maybe downgraded and two against linux-image-2.6.18-3-ixp4xx one critical (making an entire partition unusable) and one important) This would mean that cryptsetup is not unneccsarily RC, and the critical data-corruption bug in linux-image-...-ixp4xx _is_ both visible and appropriately RC. Obviously it's submitter's and maintainer's calls, and I've already done one impossible^wstupid thing before breakfast today with the BTS control bot, so I'll just leave this here as a suggestion. On the other hand I am glad now I didn't bother setting up LUKS on the slug I built last week... -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpB6jhu56RPi.pgp Description: PGP signature
Bug#405529: Patch to remove DevFS code from drbd
tags 405529 +patch Thankyou Mr Bug Control Robot Here's a patch, culled from a diff between 0.7.21 and 0.7.22 and so hopefully able to sneak into Etch. I've compile-tested it, but I don't run drbd myself so I can't confirm its operation... Happily it was pretty easy, upstream just put a #define around all the devfs code and defaulted the define (NO_MORE_DEV_FS) to on. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. diff -ru drbd-0.7.21/drbd/drbd_int.h drbd-0.7.22/drbd/drbd_int.h --- drbd-0.7.21/drbd/drbd_int.h 2006-07-21 17:44:53.0 +1000 +++ drbd-0.7.22/drbd/drbd_int.h 2006-10-19 22:50:13.0 +1000 @@ -73,8 +73,10 @@ extern int major_nr; extern int use_nbd_major; +#ifndef NO_MORE_DEV_FS // use_nbd_major ? "nbd" : "drbd"; extern char* drbd_devfs_name; +#endif #include #ifdef DRBD_MAJOR diff -ru drbd-0.7.21/drbd/drbd_main.c drbd-0.7.22/drbd/drbd_main.c --- drbd-0.7.21/drbd/drbd_main.c 2006-07-21 17:44:53.0 +1000 +++ drbd-0.7.22/drbd/drbd_main.c 2006-10-19 20:43:02.0 +1000 @@ -49,7 +49,9 @@ #include #endif #include +#ifndef NO_MORE_DEV_FS #include +#endif #define __KERNEL_SYSCALLS__ #include @@ -144,9 +146,10 @@ #endif int disable_bd_claim = 0; +#ifndef NO_MORE_DEV_FS // devfs name char* drbd_devfs_name = "drbd"; - +#endif // global panic flag volatile int drbd_did_panic = 0; @@ -1695,8 +1698,10 @@ #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0) devfs_unregister(devfs_handle); #else +#ifndef NO_MORE_DEV_FS devfs_remove(drbd_devfs_name); #endif +#endif if (unregister_blkdev(MAJOR_NR, DEVICE_NAME) != 0) printk(KERN_ERR DEVICE_NAME": unregister of device failed\n"); @@ -1769,7 +1774,9 @@ return err; } +#ifndef NO_MORE_DEV_FS drbd_devfs_name = (major_nr == NBD_MAJOR) ? "nbd" : "drbd"; +#endif /* * allocate all necessary structs @@ -1791,7 +1798,9 @@ if (unlikely(!drbd_blocksizes)) goto Enomem; #else +#ifndef NO_MORE_DEV_FS devfs_mk_dir(drbd_devfs_name); +#endif for (i = 0; i < minor_count; i++) { drbd_dev*mdev = drbd_conf + i; @@ -1814,7 +1823,9 @@ disk->first_minor = i; disk->fops = &drbd_ops; sprintf(disk->disk_name, DEVICE_NAME "%d", i); +#ifndef NO_MORE_DEV_FS sprintf(disk->devfs_name, "%s/%d", drbd_devfs_name, i); +#endif disk->private_data = mdev; add_disk(disk); diff -ru drbd-0.7.21/drbd/linux/drbd_config.h drbd-0.7.22/drbd/linux/drbd_config.h --- drbd-0.7.21/drbd/linux/drbd_config.h 2006-08-02 00:33:07.0 +1000 +++ drbd-0.7.22/drbd/linux/drbd_config.h 2006-10-23 18:38:56.0 +1000 @@ -69,4 +69,6 @@ // but more recent kernels define it in arch/um/include/mem.h #define HAVE_UML_TO_VIRT +//#define NO_MORE_DEV_FS + #endif diff -ru drbd-0.7.21/drbd_config.h drbd-0.7.22/drbd_config.h --- drbd-0.7.21/drbd_config.h 2006-08-02 00:33:07.0 +1000 +++ drbd-0.7.22/drbd_config.h 2006-10-23 18:38:56.0 +1000 @@ -69,4 +69,6 @@ // but more recent kernels define it in arch/um/include/mem.h #define HAVE_UML_TO_VIRT +//#define NO_MORE_DEV_FS + #endif diff -ru drbd-0.7.21/scripts/adjust_drbd_config_h.sh drbd-0.7.22/scripts/adjust_drbd_config_h.sh --- drbd-0.7.21/scripts/adjust_drbd_config_h.sh 2005-05-09 18:01:56.0 +1000 +++ drbd-0.7.22/scripts/adjust_drbd_config_h.sh 2006-10-23 18:38:57.0 +1000 @@ -80,6 +80,7 @@ else have_mm_inline_h=0 fi +no_more_dev_fs=0 else # 2.6. kernel. just leave it alone... need_sighand_hack=0 @@ -87,6 +88,7 @@ need_RH_2_4_18_hack=0 have_find_next_bit=0 have_mm_inline_h=0 +no_more_dev_fs=1 fi test -e ./linux/drbd_config.h.orig || cp ./linux/drbd_config.h{,.orig} @@ -101,7 +103,9 @@ s{.*(#define HAVE_FIND_NEXT_BIT.*)} { ( $have_find_next_bit ? '' : '//' ) . \$1}e; s{.*(#define HAVE_MM_INLINE_H.*)} - { ( $have_mm_inline_h ? '' : '//' ) . \$1}e;" \ + { ( $have_mm_inline_h ? '' : '//' ) . \$1}e; + s{.*(#define NO_MORE_DEV_FS.*)} + { ( $no_more_dev_fs ? '' : '//' ) . \$1}e;" \ < ./linux/drbd_config.h \ > ./linux/drbd_config.h.new pgpErsWfKc3YC.pgp Description: PGP signature
Bug#378382: Puppetmaster works in unstable
I just tried the same procedure Alex R. Owen tried, on an unstable powerpc box, and the PID file was created fine, and had a PID in it, and puppetmaster stopped when the init.d script told it to. So something else's up, but maybe this isn't RC if it can't be reproduced (in its new variant, the empty-pidfile bug). Alex, try adding File.open(@pidfile + ".%d" % $$, "w") { |f| f.puts $$ } directly below the existing File.open(@pidfile... line, and see if you get a /var/run/puppetmasterd.pid.[PID] file created. 0.22.0 seems unlikely to go into Etch, so that's not a solution that'll help the RC bug count. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpg6gV4zQwU8.pgp Description: PGP signature
Bug#405606: Drop aiccu from etch?
Given that it's non-free, badly outdated, and the upstream site is providing their own repository with i386, amd64 and armeb builds (which is more than Debian's non-free tree has) I'd suggest this should be dropped from Etch. Also, it wasn't in Sarge, so there's no upgrade issue here. It's not on backports.org either. This is also the only Etch-relevant non-free RC bug left. [1] [1] http://bugs.debian.org/release-critical/debian/non-free.html (I've not CC'd debian-release, as this bug is only fairly new and the maintainer has not yet responded.) -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgplMTGy7x1AH.pgp Description: PGP signature
Bug#389163: Aleph is a language interpreter, renaming will break it
Renaming /usr/bin/aleph will break scripts that #! it... I dunno if that's common, or actually possible in the language, but it's something to keep in mind. Anyway, PDO says it's out of testing now anyway... I guess that's what happens when you're the first non-not-in-testing RC bug of the week. ^_^ -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpiiejX2kDkR.pgp Description: PGP signature
Bug#395019: More details regarding disk numbering change
For people (like me) who've picked up this bug via rc-alert or apt-list-bugs and paniced.. The change is simply that partition numbers start at 1, not 0. See [1] As for the bug itself... I'd suggest a NEWS.Debian file entry that says that grub2 users must do an install-grub and update-grub cycle when upgrading to this version, and make update-grub deal with the new numbering, as well as telling users to update any static grub.cfg stanzas. I guess the hard part is fixing the existing groot line in grub.cfg. Maybe reconvert the boot/root device, and if it comes out as ,1 higher than current groot, make the change, otherwise whinge to the user that the system may be unbootable until the groot is fixed? (Presumably, that's done in the postinst script. However, update-grub shouldn't be run, since install-grub hasn't been run and the change to the groot line in the grub.cfg isn't actually effective until update-grub is run) Given that I don't think you can tell where grub2 was installed to in the first place, detected which version of the grub2 bootsector stuff is in use would be basically ineffective, so update-grub can't be relied up. The only people who'd see this then early-adopters in sid and etch. If 1.95 could be snuck into the etch release, then the list of people who'll get bitten by this shrinks enormously, but that's something for the grub2 maintainers and the RMs to decide amongst themselves. I'd vote for it, since the upgrade process described above is kind of fragile and that way only people who're expected to be able to deal with whinging upgrade scripts will see whinges from the upgrade script. Of course, this'd require updating d-i with the new grub udeb. I get the impression that's harder than just migrating to etch. [1] http://www.mail-archive.com/grub-devel@gnu.org/msg02180.html -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgptWJAhoFxWP.pgp Description: PGP signature
Bug#392776: MBR still useful
Just a quick note, I noticed this bug using rc-alert. mbr is still useful, at least in one specific case, which is when using grub and a Highpoint HPT366 or 370 device (and possible later devices) Basically, these IDE/RAID controllers use a sector on the disk which is also one of the sectors grub tries to install its stage 1.5 loader into when installed as the MBR. The trivially easy solution is to install grub as the boot sector on your /boot (or /) partition, and install mbr onto the MBR. See bug #394868 for details of the HPT/grub conflict -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpIt8UmQmn1D.pgp Description: PGP signature
Bug#390304: Solved by what??
reopen 390304 ! Thankyou Mr Bug Control Robot Umm, -3 hasn't been uploaded to unstable yet... It was tagged in SVN but never uploaded... This illustrates nicely the dangers of closing bugs with things that aren't a Closes: tag in the changelog, or the 'upload has been accepted' message in the case of a bug that's too late for the changelog. ^_^ I'm gonna steal this bug, since the original submitter apparently solved their problem by installing the pacakge version whose versioned dependancy was missed. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpcrEIRmdXFt.pgp Description: PGP signature
Bug#365192: Packages containing RFCs
On Thu, 27 Apr 2006 22:22:43 +0200, Francesco Poli wrote: > On Wed, 26 Apr 2006 11:32:30 +0200 Simon Josefsson wrote: >> Some additional filtering should probably be done, some earlier RFC >> are (I believe) in the public domain. > Public domain RFCs (if there are any) can be identified by looking at > them. > They must carry an appropriate notice to state that they are public > domain or else be knowingly published with no copyright notice in a > jurisdiction where, and at a time when, no copyright notice used to mean > public domain[1]. > Better be sure that something is public domain, before saying that > everything is fine, IMHO. Does this discussion mean the suggestion at the top of #199810 is wrong? (ie. that RFCs not licensed under the license that first appeared (I think) in RFC2220, October 1997 are OK) Certainly I've been trimming the RFC list every new-upstream version removing anything after that point... Handily, I've got a new upstream version due for upload, so if I need to whack the rest of the RFCs, now's a great time to do it. -- ----------- Paul "TBBle" Hampson, Bsc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpuegeqvAAav.pgp Description: PGP signature
Bug#351732: diff for 1.1.0-1.1 NMU
On Sat, Apr 01, 2006 at 11:51:45AM +0100, Stephen Gran wrote: > Attached is the diff for my freeradius 1.1.0-1.1 NMU. > I'll sit on this for a few hours to let you have time to tel me you are > working on it. Otherwise, I plan to upload this later today. I don't object, go ahead. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpRT4QK3igu4.pgp Description: PGP signature
Bug#349123: Is mkvmlinuz a ramdisk creator?
On Tue, Jan 24, 2006 at 10:35:43AM +0100, Simon Richter wrote: > Hi, > Paul TBBle Hampson wrote: > >Reading the manpage of mkvmlinuz indicates it can _include_ an initrd in > >its output, but doesn't indicate it can assemble a ramdisk from scripts > >+ modules + fairy dust. (Or whatever it is they use...) > Yes, that was badly worded. If it is rightfully not detected as a > ramdisk creator because it isn't one, then the problem of not > depending on one still remains, however. Ah, I apologise. I did indeed read that in the way that made it a nonbug, and now that I look, it is indeed missing the depends on a ramdisk tool. -- ----------- Paul "TBBle" Hampson, BSc, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgp2RVD47qDRL.pgp Description: PGP signature
Bug#349123: Is mkvmlinuz a ramdisk creator?
Reading the manpage of mkvmlinuz indicates it can _include_ an initrd in its output, but doesn't indicate it can assemble a ramdisk from scripts + modules + fairy dust. (Or whatever it is they use...) I think this is a non-bug. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpnMxEridis2.pgp Description: PGP signature
Bug#334367: php4-curl: php4 FTBFS due to libcurl3-dev disappearing from unstable
Package: php4-curl Severity: serious Justification: no longer builds from source libcurl3-dev disappeared from unstable on or about October 10th (based on the upload date in the changelog) and the last PHP4 upload got caught in the transition. Some architectures' autobuilders could still get ahold of libcurl3-dev, and some couldn't: [1] arm hppa sparc (Other build-failures) m68k<== Died on unixodbc-dev being uninstallable ia64<== Died on _both_ unixodbc-dev and libcurl3-dev, unlucky! powerpc <== Somehow died on libcrypto... [1] http://people.debian.org/~igloo/status.php?email=&packages=php4&arches= (Sorry, I couldn't work out how to make reportbug submit against a source package...) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (950, 'unstable'), (900, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 8th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgpNsN0HLaq9K.pgp Description: PGP signature
Bug#283320: Still building fine on rem
rem: 5.8.7-6, success http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.7-6&arch=mipsel&stamp=1129187254&file=log&as=raw -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 8th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgp1cziOxAOIL.pgp Description: PGP signature
Bug#279391: freeradius: please upgrade to newer libtool
On Sun, Oct 02, 2005 at 05:53:04PM +0200, Kurt Roeckx wrote: > severity 279391 serious > tags 279391 + patch > thanks > Hi, > With the following patch, it should build with libtool 1.5. It > should hopefully also fix #288547. > I've also attached a patch that for things I changed that aren't > in upstream's snapshot that you should probably send upstream. > Please test this. I did not test it, I only tried to build it, > and that seems to work as far as I can see. I have no clue about > what the package is supposed to do, and if it works or not. > I'm setting this to serious since you're currently unable to > build the package with libtool1.4. Thanks for that. I'll review the patch, and try and get it integrated over the next day or two. Once I've gotten that done, I'll take the CVS HEAD patch upstream and see what becomes of it. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 8th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgpmyZ01GQhv8.pgp Description: PGP signature
Bug#288547: patch for nonPIC code in rlm_eap.so and rlm_eap_sim.so
eap/types/Makefile --- freeradius-1.0.5~/src/modules/rlm_eap/types/Makefile2005-04-12 07:18:28.0 +1000 +++ freeradius-1.0.5/src/modules/rlm_eap/types/Makefile 2005-09-26 02:48:12.0 +1000 @@ -16,7 +16,7 @@ $(MAKE) $(MFLAGS) WHAT_TO_MAKE=$@ common common: - @for mod in rlm_eap*; do \ + @for mod in rlm_eap_tls rlm_eap*; do \ what=$(WHAT_TO_MAKE); \ [ "$$what" = "all" ] && what="$(TARGET_LIBS)"; \ if [ -d $$mod ] && [ -f $$mod/Makefile ]; then \ diff -urNad freeradius-1.0.5~/src/modules/rlm_eap/types/rlm_eap_peap/Makefile.in freeradius-1.0.5/src/modules/rlm_eap/types/rlm_eap_peap/Makefile.in --- freeradius-1.0.5~/src/modules/rlm_eap/types/rlm_eap_peap/Makefile.in 2004-06-04 01:49:23.0 +1000 +++ freeradius-1.0.5/src/modules/rlm_eap/types/rlm_eap_peap/Makefile.in 2005-09-26 02:48:12.0 +1000 @@ -3,7 +3,7 @@ RLM_CFLAGS = $(INCLTDL) -I../.. @eap_peap_cflags@ -I../rlm_eap_tls -DOPENSSL_NO_KRB5 [EMAIL PROTECTED]@/../../libeap HEADERS = ../rlm_eap_tls/rlm_eap_tls.h eap_peap.h ../../eap.h ../../rlm_eap.h RLM_INSTALL = -RLM_LIBS= [EMAIL PROTECTED]@/../../libeap -leap @eap_peap_ldflags@ +RLM_LIBS= @srcdir@/../../libeap/libeap.la @srcdir@/../rlm_eap_tls/liblrlm_eap_tls.la @eap_peap_ldflags@ $(STATIC_OBJS): $(HEADERS) diff -urNad freeradius-1.0.5~/src/modules/rlm_eap/types/rlm_eap_sim/Makefile.in freeradius-1.0.5/src/modules/rlm_eap/types/rlm_eap_sim/Makefile.in --- freeradius-1.0.5~/src/modules/rlm_eap/types/rlm_eap_sim/Makefile.in 2004-05-29 02:17:48.0 +1000 +++ freeradius-1.0.5/src/modules/rlm_eap/types/rlm_eap_sim/Makefile.in 2005-09-26 02:48:12.0 +1000 @@ -2,7 +2,7 @@ SRCS= rlm_eap_sim.c RLM_CFLAGS = $(INCLTDL) [EMAIL PROTECTED]@/../.. [EMAIL PROTECTED]@/../../libeap HEADERS = eap_sim.h -RLM_LIBS= [EMAIL PROTECTED]@/../../libeap -leap +RLM_LIBS= @srcdir@/../../libeap/libeap.la RLM_INSTALL = $(STATIC_OBJS): $(HEADERS) diff -urNad freeradius-1.0.5~/src/modules/rlm_eap/types/rlm_eap_ttls/Makefile.in freeradius-1.0.5/src/modules/rlm_eap/types/rlm_eap_ttls/Makefile.in --- freeradius-1.0.5~/src/modules/rlm_eap/types/rlm_eap_ttls/Makefile.in 2004-06-04 01:49:24.0 +1000 +++ freeradius-1.0.5/src/modules/rlm_eap/types/rlm_eap_ttls/Makefile.in 2005-09-26 02:48:12.0 +1000 @@ -3,7 +3,7 @@ RLM_CFLAGS = $(INCLTDL) [EMAIL PROTECTED]@/../.. [EMAIL PROTECTED]@/../../libeap @eap_ttls_cflags@ -I../rlm_eap_tls -DOPENSSL_NO_KRB5 HEADERS = ../rlm_eap_tls/rlm_eap_tls.h eap_ttls.h ../../eap.h ../../rlm_eap.h RLM_INSTALL = -RLM_LIBS= [EMAIL PROTECTED]@/../../libeap -leap @eap_ttls_ldflags@ +RLM_LIBS= @srcdir@/../../libeap/libeap.la @srcdir@/../rlm_eap_tls/librlm_eap_tls.la @eap_ttls_ldflags@ $(STATIC_OBJS): $(HEADERS) diff -urNad freeradius-1.0.5~/src/modules/rules.mak freeradius-1.0.5/src/modules/rules.mak --- freeradius-1.0.5~/src/modules/rules.mak 2005-07-31 22:48:01.0 +1000 +++ freeradius-1.0.5/src/modules/rules.mak 2005-09-26 02:48:12.0 +1000 @@ -98,6 +98,13 @@ $(LIBTOOL) --mode=link $(CC) -release $(RADIUSD_VERSION) \ -module $(LINK_MODE) $(LDFLAGS) $(RLM_LDFLAGS) \ -o $@ -rpath $(libdir) $^ $(RLM_LIBS) $(LIBS) + for file in .libs/rlm_eap_*.so ; do \ + [ -f $$file ] || continue; \ + name=$${file#.libs/}; \ + name=$${name%.so}; \ + ln -s .libs/$${name}.so lib$${name}.so; \ + ln -s .libs/$${name}.la lib$${name}.la; \ + done ### # @@ -138,6 +145,7 @@ @rm -f *.a *.o *.lo *.la *~ @rm -rf .libs _libs @rm -f config.cache config.log config.status $(RLM_UTILS) + @rm -f librlm_eap_*.la librlm_eap_*.so @[ "x$(RLM_SUBDIRS)" = "x" ] || $(MAKE) $(MFLAGS) WHAT_TO_MAKE=clean common distclean: clean @@ -155,6 +163,7 @@ # Otherwise, install the libraries into $(libdir) # install: + @[ "x$(RLM_PREINSTALL)" = "x" ] || $(MAKE) $(MFLAGS) $(RLM_PREINSTALL) if [ "x$(TARGET)" != "x" ]; then \ $(LIBTOOL) --mode=install $(INSTALL) -c \ $(TARGET).la $(R)$(libdir)/$(TARGET).la; \ -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 8th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgplm2uEFdT1h.pgp Description: PGP signature
Bug#288547: New life in an old bug
severity 288547 serious tags 288547 +sarge +etch +sid Thanks to a recent extension of lintian nonPIC checking to libraries that the linker doesn't see, it seems that this bug is simply a libtool1.4 breakage, and _should_ affect any architecture that can't load nonPIC code in a shared object, rather than just AMD64. It only affects rlm_eap and rlm_eap_sim, that I can see, but it is probably present all the way back to their introduction to Debian. (rlm_eap_sim was enabled in 1.0.2-1, rlm_eap has been around for ages, but wouldn't have had this problem before rlm_eap_sim was introduced in 1.0.0, as that caused libeap to be split out of rlm_eap, and that's where this problem started.) The annoying part is that during the build, the library is fine and dandy. Then during "make install" libtool decides to slurp in libeap.a (non-PIC, static) instead of continuing to NEEDSing libeap.so (PIC, sharable) for rlm_eap.so and rlm_eap_sim.so. Since this bug was reported against 1.0.1-2, it's already part of Sarge's tree. And etch's, and sid's. Yuck! On the plus side, this means it shouldn't interfere with testing propagation. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 8th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgp0C8pKepLBp.pgp Description: PGP signature
Bug#329697: libltdl3-dev: needs to conflict/replaces with libtool1.4 due to file overlap
Package: libltdl3-dev Version: 1.5.20-1 Severity: serious Justification: Policy 6.5 The move of /usr/share/aclocal/ltdl.m4 from libtool to libltdl3-dev means that libtool1.4 now clashese with libltdl3-dev. It is important to me that libltdl3-dev and libtool1.4 remain parallel- installable, so that FreeRADIUS is buildable without serious surgery of its build environment. Either a Replaces: libtool1.4, or a new upload of libtool1.4 without /usr/share/aclocal/ltdl.m4 and an appropriate Conflicts: against the previous (current) libscripts.tool1.4 would work, I think. Otherwise, maybe a diversion or something? The S390 buildd has just his this issue: http://buildd.debian.org/fetch.php?&pkg=freeradius&ver=1.0.5-1&arch=s390&stamp=1127297196&file=log&as=raw -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (950, 'unstable'), (900, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages libltdl3-dev depends on: ii libltdl3 1.5.20-1 A system independent dlopen wrappe Versions of packages libltdl3-dev recommends: pn libtool(no description available) -- no debconf information -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 8th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgpAMLP9mwsfN.pgp Description: PGP signature
Bug#283320: Has this FTBFS bug been fixed on mipsel now?
This bug appears to have been fixed in July. remake: 5.8.4-4, failed (12 test failures) http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.4-4&arch=mipsel&stamp=1099771004&file=log&as=raw remake: 5.8.4-4, failed (12 test failures) http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.4-4&arch=mipsel&stamp=1101291814&file=log&as=raw repeat.rfc822.org: 5.8.4-5, failed (12 test failures) Presumably the same machine as remake... http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.4-5&arch=mipsel&stamp=1102820411&file=log&as=raw remake: 5.8.4-5, failed (12 test failures) http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.4-5&arch=mipsel&stamp=1103895333&file=log&as=raw solitude: 5.8.4-6, success http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.4-6&arch=mipsel&stamp=1107362357&file=log&as=raw remake: 5.8.4-7, failed (outlier?) Errno architecture (mipsel-linux-thread-multi-2.4.27-sb1-swarm-bn) does not match executable architecture (mipsel-linux-thread-multi-2.4.20-pre6) at /usr/lib/perl/5.8/Errno.pm line 11. http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.4-7&arch=mipsel&stamp=1110208039&file=log&as=raw remake: 5.8.4-8, failed (12 test failures) http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.4-8&arch=mipsel&stamp=1110314271&file=log&as=raw solitude: 5.8.4-8, success http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.4-8&arch=mipsel&stamp=1110579504&file=log&as=raw (Presumably remake was rebuilt and became rem here?) rem: 5.8.7-2, failed (only one test, t/op/fork, failed) http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.7-2&arch=mipsel&stamp=1118196397&file=log&as=raw rem: 5.8.7-3, success http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.7-3&arch=mipsel&stamp=1118273494&file=log&as=raw rem: 5.8.7-4, failed (only one test, t/op/fork, failed) http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.7-4&arch=mipsel&stamp=1120885183&file=log&as=raw rem: 5.8.7-4, failed (only one test, t/op/fork, failed) http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.7-4&arch=mipsel&stamp=1121067847&file=log&as=raw rem: 5.8.7-4, success http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.7-4&arch=mipsel&stamp=1121104986&file=log&as=raw rem: 5.8.7-5, success http://buildd.debian.org/fetch.php?&pkg=perl&ver=5.8.7-5&arch=mipsel&stamp=1126486805&file=log&as=raw So it appears to me that this FTBFS bug filed against remake can be closed, as the machine in question has been either rebuilt or retired. I haven't actually done anything to this bug as there may be more going on here than I'm aware of, but from what I can see this isn't a bug in perl, but an issue with the buildd that has since been solved. (If remake and repeat are seperate machines, then there's at least something repeatable across machines here.) If it was/is an issue with the buildd, then the 12-test failure first appears in 5.8.4-2.2 on 2004-09-07, and last appears 2005-03-08, and the t/op/fork test failure first appears 2005-06-07 and was last seen 2005-07-11 (and a rebuild 10 hours later on the same machine didn't fail, so if this was an issue, it may have been fixed that day?) (The 12 tests failing earlier don't include t/op/fork, BTW) -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 8th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgpa7RDzkcgzV.pgp Description: PGP signature
Bug#325643: libcurl and moc
On Sat, Sep 03, 2005 at 05:02:14AM -0700, Steve Langasek wrote: > On Sat, Sep 03, 2005 at 08:16:48AM +1000, Paul TBBle Hampson wrote: >> As far as packaging goes, this means you get the following packages: >> libcurl3, providing libcurl3-openssl (linked against OpenSSL to avoid >> breaking >> sarge packages that use this functionality) >> libcurl3-gnutls (linked against gnuTLS, doesn't support SSL_CTX_FUNCTION) >> libcurl3-dev (Do we need a second -dev? Static linking maybe requires it? If >> this becomes a testable feature, then a second -dev is definately >> needed.) >> Packages which don't use SSL_CTX_FUNCTION can Depend on either libcurl3 | >> libcurl3-gnutls, or if they're GPL'd can depend on libcurl3-gnutls only. >> Packages which need SSL_CTX_FUNCTION can depend on libcurl3-openssl >> grepping the source of libcurl3's direct rdepends should tell you which >> packages in Debian need SSL_CTX_FUNCTION. >> GPL'd packages which need SSL_CTX_FUNCTION are out of luck. And have always >> been so. >> Before etch ships, no package should depend on libcurl3, they should depend >> on >> libcurl3-openssl or libcurl3 | libcurl3-gnutls or libcurl3-gnutls. >> After etch ships, upload: >> libcurl3, providing libcurl3-gnutls (linked against gnuTLS) >> libcurl3-openssl, providing libcurl3 (linked against openSSL) >> libcurl3-dev >> At this point, packages who don't like having libcurl3-gnutls is their >> Depends line can do a versioned depends on libcurl3, which won't match >> the libcurl3 virtual dependancy provide by libcurl3-openssl, and will >> also prevent them accidentally linking against an openSSL version of >> libcurl3. (At least, I _think_ that's how versioned dependancies on >> virtual packages work. Possibly they'll _always_ match, in which case a >> Conflicts is in order instead.) > Do libcurl3 and libcurl3-gnutls provide different sonames to allow > co-installability of the packages, or does libcurl3 use diversions to > override the libcurl.so.3 that lacks SSL_CTX_FUNCTION support (if any) > when installing? (We know that directly conflicting between the two > packages is not really an option, unless we're doing this like the C++ > ABI transition and we either don't believe there are any packages in > Debian which will need to retain SSL_CTX_FUNCTION support or we assume > they're packages that we don't care about co-installability of -- which > seems far-fetched to me.) Ooops. I forgot about diversions. And yes, I'm expecting them to conflict. If they don't want to conflict, I believe the suggestion I posted much earlier about changing coname for the gnuTLS version would do it, but it makes the transition more painful in my opinion. > It may be worthwhile to simply survey all the curl-using packages in > sarge, though, and find out if there is a non-zero number of them that > need SSL_CTX_FUNCTION. If *not*, then I don't think there's much sense > in going through a multi-stage transition: just switch libcurl3 directly > to gnutls, and add libcurl3-openssl which provides libcurl-openssl.so.3? Very true... apt-cache rdepends libcurl3: libcurl3 Reverse Depends: python-mapscript php4-mapscript perl-mapscript openoffice.org2-core mapserver-bin cgi-mapserver ida xmms-scrobbler xine-ui xen xastir wmweather wmget vorbis-tools telak tclcurl sylpheed-claws-gtk2-clamav streamtuner rtorrent redland-utils rasqal-utils raptor-utils python2.4-pycurl python2.3-pycurl python2.3-librdf python2.2-librdf python-mapscript php5-curl php4-curl perl-mapscript paintlib2c2 openoffice.org-bin moc metar mapserver-bin logjam linuxtrade libwww-curl-perl libsword5 libstonith0 librdf0 librdf-ruby librdf-perl librasqal0 libraptor1 libofx2 libmultisync-plugin-opie liblrdf0 libcurl3-gssapi libcurl3-gssapi libcurl3-gnutls libcurl3-dev libcurl3-dbg libcurl-ocaml libclamav1 libapache2-webkdc libapache2-webauth jigdo jabber-msn icecast2 grip gnomesword gambas-gb-net-curl freepops fbi drivel diatheke darcs-server darcs curl cogito clamcour clamav-milter clamav-freshclam clamav-daemon clamav cgi-mapserver centericq-utf8 centericq-fribidi centericq cduce came bzflag-server bzflag bidwatcher bibletime beep-media-player-scrobbler ardour-gtk-i686 ardour-gtk apt-spy approx aegis-web aegis apt-get source `apt-cache rdepends libcurl3 |grep '^ '` --download-only Move the following out of the way: curl_7.14.0-5 fbi_2.01-1.2 gnomesword_2.1.2-2 ida_2.01-1.2 libwww-curl-perl_2.0-8 openoffice.org_1.1.4
Bug#325643: libcurl and moc
nd you need to make a choice of some kind, but apt will _tell_ you when that happens, it won't break silently. And non-SSL_CTC third-party software will never lose ABI-compatibility. The _problem_ with this setup is you can't parallel-install a GPL'd libcurl3-using application and an application that uses SSL_CTX_FUNCTION (as libcurl3 and libcurl3-gnutls must conflict as they provide shared libs with the same soname/sover. As you'd expect as they're ABI-compatible, albeit functionaly different.) The impact of this should be taken into account, and balanced against the fact that right now, we can't have a GPL'd libcurl3-using application installed at all. ^_^ There are possibly some optimisations that could be made above with Conflicts. Maybe both -openssl and -gnutls should provide libcurl3, all users depend on libcurl3, and GPL packages conflict with libcurl3-openssl and SSL_CTX_FUNCTION users conflict with libcurl3-gnutls. I'm not sure if this is an improvement... And of course a libcurl4 which doesn't expose internal SSL implementation details to the library user would allow us to short-cut a whole load of this stuff. ^_^ > On Sat, Sep 03, 2005 at 12:47:06AM +1000, Paul TBBle Hampson wrote: >> If I've understood correctly, it is because curl expects the client program >> or library to -lgnutls or -lopenssl and therefore provide the SSL symbols >> to match the symbols which that build of the .so file is expecting. >> >> This is the point I move from suggesting things to spectating, 'cause I >> can't wrap my head above the reason for the above. > No, you're mixing things up. I believe you're talking about what is > described towards the end of > <http://curl.haxx.se/legal/distro-dilemma.html>. Whenever libcurl switches > to the described mechanism, then _at_that_moment_ it might be necessary to > increase the .so version. > That's because programs are then required to link explicitly against one of > the SSL-enabling "backend libs", called "lib2" on the page above. You don't > suddenly want your old libcurl3-using programs to fail with run-time link > errors... Quite probably. Certainly _something_ confused me. ^_^ I think the backend libs thingy is kinda awful-looking, and rather unneccesary under the current circumstances, adding ABI differences we don't actually need. -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpSnjWAe5Gh1.pgp Description: PGP signature
Bug#325643: Bug#318590: Bug#325643: libcurl and moc
On Fri, Sep 02, 2005 at 04:04:27AM -0700, Steve Langasek wrote: > On Fri, Sep 02, 2005 at 12:24:18PM +0200, Domenico Andreoli wrote: > > >> - libcurl3 (GnuTLS, soname: libcurl.so.3) > But no one has yet answered my question: *why* are there ABI differences > between the gnutls and openssl builds? If I've understood correctly, it is because curl expects the client program or library to -lgnutls or -lopenssl and therefore provide the SSL symbols to match the symbols which that build of the .so file is expecting. This is the point I move from suggesting things to spectating, 'cause I can't wrap my head above the reason for the above. -- ----------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpsUHeo7JFA3.pgp Description: PGP signature
Bug#309308: [Secure-testing-team] Re: Bug#309308: kernel-image-2.6.8-2-686-smp: VLAN Oops fix for 2.6.8
On Thu, Aug 11, 2005 at 11:04:17AM +0200, Moritz Muehlenhoff wrote: > Horms wrote: > >> below patch has been slurped into the Debian patches for 2.6.8, but the > >> error posted looks like the same error I suffered when hitting this bug. > >> > >> Patch from > >> http://lists.osdl.org/pipermail/bridge/2004-September/000638.html > >> > >> Cut and paste from the web archive, so spacing etc. may be boned. > >> But it's a typo-only fix anyway, so easy enough to recreate. >> >> Thanks I have added this to SVN. >> >> Is this considered a security bug and if so does it have a CAN number? > There is no public CVE assignment for this issue. If's it easily reproducable > for non-root, it might account as a local DoS vulnerability. mii-tool's IOCTL is only allowed by root. The remote DoS comes from the fact that snmpd will call this IOCTL when it gets a request for the interface statistics. So it's exploitable via SNMP if the exploiter has access to the SNMP tree in question. (Which is not the default, if I recall correctly?) However, this means that cricket will bone the machine during the boot process, or soon after. ^_^ -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpMi1FkN0UbN.pgp Description: PGP signature
Bug#309308: kernel-image-2.6.8-2-686-smp: VLAN Oops fix for 2.6.8
Package: kernel-image-2.6.8-2-686-smp Followup-For: Bug #309308 Just noticed this bug in the testing-security list. I don't know if the below patch has been slurped into the Debian patches for 2.6.8, but the error posted looks like the same error I suffered when hitting this bug. Patch from http://lists.osdl.org/pipermail/bridge/2004-September/000638.html The patch was taken into 2.6.9-rc2, and the bug was in code introduced very late in the 2.6.8 cycle. (August 2004 I believe) diff -Nru a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c --- a/net/8021q/vlan_dev.c 2004-09-10 06:12:16 -07:00 +++ b/net/8021q/vlan_dev.c 2004-09-10 06:12:16 -07:00 @@ -772,7 +772,7 @@ case SIOCGMIIREG: case SIOCSMIIREG: if (real_dev->do_ioctl && netif_device_present(real_dev)) - err = real_dev->do_ioctl(dev, &ifrr, cmd); + err = real_dev->do_ioctl(real_dev, &ifrr, cmd); break; case SIOCETHTOOL: Cut and paste from the web archive, so spacing etc. may be boned. But it's a typo-only fix anyway, so easy enough to recreate. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (950, 'unstable'), (900, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 8th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgp3zZ7JToe0F.pgp Description: PGP signature
Bug#319176: freeradius: FTBFS: build-depends on both libltdl3-dev and libtool1.4 | libtool (< 1.5)
On Wed, Jul 20, 2005 at 12:24:22PM +0200, Nicolas Boullis wrote: > Package: freeradius > Severity: serious > Justification: fails to build from source > I have to rebuild freeradius to add PEAP support. UNfortunately, the > current source package does not even build from source, since it > build-depends on both libltdl3-dev and libtool1.4 | libtool (< 1.5) > which cannot be installed together. http://buildd.debian.org/build.php?arch=&pkg=freeradius suggests it's building fine. Given both packages are orphaned, I doubt they've actually changed such that they're broken. > I think such a bug is worth fixing in the next sarge point release, as > FTBFS are especially annoying for the security team. Is this a bug against the sarge version, the sid version, or both? I'm open to receiving buildlogs to demonstrate the issue, but unless a third package has changed and is interfering (and certainly my unstable machine's not been forced to uninstall either package recently) I think this is a misdiagnosis. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgpACswuYhZR2.pgp Description: PGP signature
Bug#315770: freeradius: FTBFS: credits: No such file or directory.
On Sat, Jun 25, 2005 at 10:50:39PM +0200, Kurt Roeckx wrote: > Package: freeradius > Version: 1.0.4-1 > Severity: serious > Tags: sid > Hi, > Your package is failing to build with the following error: > # man pages & docs > install -g root -m 644 CREDITS > /build/buildd/freeradius-1.0.4/debian/freeradius > //usr/share/doc/freeradius/credits > install: cannot create regular file > `/build/buildd/freeradius-1.0.4/debian/free > radius//usr/share/doc/freeradius/credits': No such file or directory > make: *** [binary-arch] Error 1 Ah, blast. I misunderstood how to do the arch/indep split in debhelper, and boned it up. Fixing now, new packages to my sponsor hopefully within 24 hours. Thankyou for catching this one. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgpz6MJjeuRGT.pgp Description: PGP signature
Bug#307720: "Minor" bug rationale
OK, here's the deal. I missed the SQL injection vulnerability until I was applying the patch, by which point it didn't seem to matter. However, this is not a huge risk since the main piece of user-supplied data that is used in the SQL queries is the username, and that gets passed through the sql-escaping procedure elsewhere, as I recall. In fact, there is an optimisation to the patch that fixed this problem which I chose not to apply, which removes the specific username escaping after this change was made to escape _all_ queries. So unless someone's rewritten the SQL queries to use User-Password, this is only exploitable by the NAS, whom we trust enough to let them write accounting information to the database anyway. Otherwise, to exploit this bug, you'd need details from two files in /etc/freeradius, which should only be readable by root and the freerad user. (To get the SQL query, and the NAS shared secret) The buffer overflow is _very_ hard to exploit as the buffer the output is being written to is 4096 bytes, and a single RADIUS attribute may only be up to 253 bytes. The longest query in the system is the stop_alt query (used when a stop is received without a start record) at about 1k, which contains 23 radius substitutions, so it may indeed be pushed out to a total length of 6k. However, only an accepted NAS may send data into this query (or in fact any module) so it's only a problem for people who're using FreeRADIUS in a situation where a NAS may try and break into the system. None of the buffers being written to are the first declared in their functions, so unless C is free to reorder stack-local variables (maybe it is?) this can't push into the return address of the stack. So this buffer overflow doesn't render the package unusable, cause data loss or introduce a security hole in the account of the users of this package. (Although that last may depend on what you mean by 'users'. People do not _run_ FreeRADIUS, they query it. It has its own user by default just in case something like this slips through.) And just to remind people, I _upgraded_ this report from wishlist to minor, on the grounds that it is trivial to fix and doesn't affect the usefulness of the package. On further reflection, maybe it should have been 'normal', since it only affects one particular option (rlm_sql) rather than the core server. I certainly don't consider it grave, criticial, or release-critical, but I'm gonna let this sit for a bit before I consider changing the severity, since it's fixed now so it's much less important now. (BTW, I loved the Security Focus comment "No exploit is required.". ^_^) [1] [1] http://www.securityfocus.com/bid/13540/exploit/ -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. pgpR0yKAXFIhG.pgp Description: PGP signature