Bug#567618: Analysis/fix for grub-probe failing to identify filesystem

2010-02-03 Thread Paul "TBBle" Hampson
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

2008-05-09 Thread Paul TBBle Hampson
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

2008-01-15 Thread Paul TBBle Hampson
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

2007-12-26 Thread Paul "TBBle" Hampson
-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

2007-12-26 Thread Paul TBBle Hampson
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

2007-03-24 Thread Paul TBBle Hampson
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

2007-03-18 Thread Paul TBBle Hampson
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

2007-03-11 Thread Paul TBBle Hampson
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

2007-03-10 Thread Paul TBBle Hampson
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

2007-03-10 Thread Paul TBBle Hampson
(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

2007-02-18 Thread Paul TBBle Hampson
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

2007-01-09 Thread Paul TBBle Hampson
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

2007-01-09 Thread Paul TBBle Hampson
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?

2007-01-09 Thread Paul TBBle Hampson
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)

2007-01-09 Thread Paul TBBle Hampson
(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

2007-01-08 Thread Paul TBBle Hampson
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

2007-01-07 Thread Paul TBBle Hampson
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

2007-01-07 Thread Paul TBBle Hampson
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?

2007-01-07 Thread Paul TBBle Hampson
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

2006-12-16 Thread Paul TBBle Hampson
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

2006-11-03 Thread Paul TBBle Hampson
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

2006-11-03 Thread Paul TBBle Hampson
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??

2006-10-11 Thread Paul TBBle Hampson
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

2006-04-28 Thread Paul TBBle Hampson
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

2006-04-02 Thread Paul TBBle Hampson
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?

2006-01-24 Thread Paul TBBle Hampson
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?

2006-01-23 Thread Paul TBBle Hampson
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

2005-10-17 Thread Paul TBBle Hampson
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

2005-10-16 Thread Paul TBBle Hampson
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

2005-10-02 Thread Paul TBBle Hampson
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

2005-09-25 Thread Paul TBBle Hampson
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

2005-09-22 Thread Paul TBBle Hampson
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

2005-09-22 Thread Paul TBBle Hampson
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?

2005-09-22 Thread Paul TBBle Hampson
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

2005-09-04 Thread Paul TBBle Hampson
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

2005-09-02 Thread Paul TBBle Hampson
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

2005-09-02 Thread Paul TBBle Hampson
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

2005-08-11 Thread Paul TBBle Hampson
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

2005-08-10 Thread Paul TBBle Hampson
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)

2005-07-20 Thread Paul TBBle Hampson
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.

2005-06-26 Thread Paul TBBle Hampson
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

2005-05-26 Thread Paul TBBle Hampson
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