Bug#801305: log4cplus: broken -dev package directory
On Thu, Oct 08, 2015 at 11:05:53AM +, Gianfranco Costamagna wrote: > Source: log4cplus > Version: 1.1.2-3 > Severity: serious > Justification: completely broken lib directory > > Hi, seems that the current log4cplus unconditionally installs the library > symlink in > /usr/lib/x86_64-linux-gnu/liblog4cplus-1.1.so > /usr/lib/x86_64-linux-gnu/liblog4cplus.a > /usr/lib/x86_64-linux-gnu/liblog4cplus.la > /usr/lib/x86_64-linux-gnu/liblog4cplus.so > > for every architecture (including non x86_64*) > > > I guess this breaks the linker > http://anonscm.debian.org/cgit/collab-maint/log4cplus.git/tree/debian/liblog4cplus-dev.links *facepalm* I can't believe I did that.
Bug#791190: nmu diff for log4cplus 1.0.4-1.3
On Mon, Aug 17, 2015 at 09:04:36PM +0200, Julien Cristau wrote:
Dear maintainer,
I've prepared a NMU for log4cplus, to deal with the libstdc++ transition,
and will shortly upload it to the 1-day delayed queue. Please find the
debdiff below.
So I've just uploaded 1.1.2 to experimental and plan on asking for a
transition slot. That would make this redundant, right?
Cheers,
Julien
From abe047c9096df4dcfcff888a5abdda8ffba994c5 Mon Sep 17 00:00:00 2001
From: Julien Cristau jcris...@debian.org
Date: Sun, 16 Aug 2015 17:45:42 +0200
Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
791190).
---
debian/changelog| 7 +++
debian/control | 12 +++-
debian/liblog4cplus-1.0-4.install | 1 -
debian/liblog4cplus-1.0-4v5.install | 1 +
4 files changed, 15 insertions(+), 6 deletions(-)
delete mode 100644 debian/liblog4cplus-1.0-4.install
create mode 100644 debian/liblog4cplus-1.0-4v5.install
diff --git a/debian/changelog b/debian/changelog
index 586d070..46b1b89 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+log4cplus (1.0.4-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Rename library packages for g++5 ABI transition (closes: 791190).
+
+ -- Julien Cristau jcris...@debian.org Sun, 16 Aug 2015 17:45:42 +0200
+
log4cplus (1.0.4-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff --git a/debian/control b/debian/control
index b218fc4..b064b4f 100644
--- a/debian/control
+++ b/debian/control
@@ -12,9 +12,11 @@ Homepage: http://log4cplus.sourceforge.net
Vcs-Browser: http://git.debian.org/?p=collab-maint/log4cplus.git;a=summary
Vcs-Git: git://git.debian.org/collab-maint/log4cplus.git
-Package: liblog4cplus-1.0-4
+Package: liblog4cplus-1.0-4v5
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: liblog4cplus-1.0-4
+Replaces: liblog4cplus-1.0-4
Description: C++ logging API modeled after the Java log4j API - shared
library
log4cplus is a simple to use C++ logging API providing thread-safe,
flexible, and arbitrarily granular control over log management and
@@ -23,9 +25,9 @@ Description: C++ logging API modeled after the Java log4j
API - shared library
Package: liblog4cplus-dev
Architecture: any
Section: libdevel
-Depends: liblog4cplus-1.0-4 (= ${binary:Version}), ${misc:Depends}
-Breaks: liblog4cplus-1.0-4 ( 1.0.4-1.1~)
-Replaces: liblog4cplus-1.0-4 ( 1.0.4-1.1~)
+Depends: liblog4cplus-1.0-4v5 (= ${binary:Version}), ${misc:Depends}
+Breaks: liblog4cplus-1.0-4v5 ( 1.0.4-1.1~)
+Replaces: liblog4cplus-1.0-4v5 ( 1.0.4-1.1~)
Description: C++ logging API modeled after the Java log4j API - development
library
log4cplus is a simple to use C++ logging API providing thread-safe,
flexible, and arbitrarily granular control over log management and
@@ -38,7 +40,7 @@ Package: liblog4cplus-dbg
Section: debug
Priority: extra
Architecture: any
-Depends: ${misc:Depends}, liblog4cplus-1.0-4 (= ${binary:Version})
+Depends: ${misc:Depends}, liblog4cplus-1.0-4v5 (= ${binary:Version})
Description: C++ logging API modeled after the Java log4j API - debug library
log4cplus is a simple to use C++ logging API providing thread-safe,
flexible, and arbitrarily granular control over log management and
diff --git a/debian/liblog4cplus-1.0-4.install
b/debian/liblog4cplus-1.0-4.install
deleted file mode 100644
index fc08b1c..000
--- a/debian/liblog4cplus-1.0-4.install
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib/liblog4cplus-1.0.so.*
diff --git a/debian/liblog4cplus-1.0-4v5.install
b/debian/liblog4cplus-1.0-4v5.install
new file mode 100644
index 000..fc08b1c
--- /dev/null
+++ b/debian/liblog4cplus-1.0-4v5.install
@@ -0,0 +1 @@
+usr/lib/liblog4cplus-1.0.so.*
--
2.5.0
signature.asc
Description: Digital signature
Bug#791190: log4cplus: library transition may be needed when GCC 5 is the default
On Wed, Aug 12, 2015 at 12:49:21PM +0200, Julien Cristau wrote: Control: severity -1 serious Control: tag -1 confirmed On Fri, Jul 3, 2015 at 13:12:38 +, Matthias Klose wrote: - Rebuild the library using g++/g++-5 from experimental. Note that most likely all C++ libraries within the build dependencies need a rebuild too. You can find the log for a rebuild in https://people.debian.org/~doko/logs/gcc5-20150701/ Search for BEGIN GCC CXX11 in the log. - Decide if the symbols matching __cxx11 or B5cxx11 are part of the library API, and are used by the reverse dependencies of the library. log4cplus does expose std::string through the log4cplus::tstring typedef, so liblog4cplus-1.0-4 will need to be renamed. A possible patch is available from https://launchpad.net/ubuntu/+source/log4cplus/1.0.4-1.2ubuntu1 I've got a new upstream release almost ready to upload anyway. I'll try and upload it over the weekend. signature.asc Description: Digital signature
Bug#778101: rcs-blame: ftbfs with GCC-5
Hi, It looks like rcs-blame has bitrotted a bit with GCC-5. Is this something you could address? If you maintain the Cc on this email, our bug tracking system will be kept in the loop. regards Andrew On Thu, Feb 12, 2015 at 10:36:32AM +, Matthias Klose wrote: Package: src:rcs-blame Version: 1.3.1-4 Severity: normal Tags: sid stretch User: debian-...@lists.debian.org Usertags: ftbfs-gcc-5 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-5/g++-5, but succeeds to build with gcc-4.9/g++-4.9. The severity of this report may be raised before the stretch release. The full build log can be found at: http://people.debian.org/~doko/logs/gcc5-20150205/rcs-blame_1.3.1-4_unstable_gcc5.log The last lines of the build log are at the end of this report. To build with GCC 5, either set CC=gcc-5 CXX=g++-5 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t experimental install g++ Common build failures are C11 as the default C mode, new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-5/porting_to.html [...] ../lib/libmisc.a(argp-parse.o): In function `_option_is_end': /«PKGBUILDDIR»/lib/argp.h:605: multiple definition of `_option_is_end' blame.o:/«PKGBUILDDIR»/src/../lib/argp.h:605: first defined here ../lib/libmisc.a(argp-pvh.o): In function `argp_usage': /«PKGBUILDDIR»/lib/argp.h:587: multiple definition of `argp_usage' blame.o:/«PKGBUILDDIR»/src/../lib/argp.h:587: first defined here ../lib/libmisc.a(argp-pvh.o): In function `_option_is_short': /«PKGBUILDDIR»/lib/argp.h:593: multiple definition of `_option_is_short' blame.o:/«PKGBUILDDIR»/src/../lib/argp.h:593: first defined here ../lib/libmisc.a(argp-pvh.o): In function `_option_is_end': /«PKGBUILDDIR»/lib/argp.h:605: multiple definition of `_option_is_end' blame.o:/«PKGBUILDDIR»/src/../lib/argp.h:605: first defined here ../lib/libmisc.a(argp-fmtstream.o): In function `argp_fmtstream_set_lmargin': /«PKGBUILDDIR»/lib/argp-fmtstream.h:243: multiple definition of `argp_fmtstream_set_lmargin' ../lib/libmisc.a(argp-help.o):/«PKGBUILDDIR»/lib/argp-fmtstream.h:243: first defined here ../lib/libmisc.a(argp-fmtstream.o): In function `argp_fmtstream_set_rmargin': /«PKGBUILDDIR»/lib/argp-fmtstream.h:255: multiple definition of `argp_fmtstream_set_rmargin' ../lib/libmisc.a(argp-help.o):/«PKGBUILDDIR»/lib/argp-fmtstream.h:255: first defined here ../lib/libmisc.a(argp-fmtstream.o): In function `argp_fmtstream_set_wmargin': /«PKGBUILDDIR»/lib/argp-fmtstream.h:267: multiple definition of `argp_fmtstream_set_wmargin' ../lib/libmisc.a(argp-help.o):/«PKGBUILDDIR»/lib/argp-fmtstream.h:267: first defined here ../lib/libmisc.a(argp-fmtstream.o): In function `argp_fmtstream_point': /«PKGBUILDDIR»/lib/argp-fmtstream.h:280: multiple definition of `argp_fmtstream_point' ../lib/libmisc.a(argp-help.o):/«PKGBUILDDIR»/lib/argp-fmtstream.h:280: first defined here ../lib/libmisc.a(argp-fmtstream.o): In function `argp_fmtstream_write': /«PKGBUILDDIR»/lib/argp-fmtstream.h:207: multiple definition of `argp_fmtstream_write' ../lib/libmisc.a(argp-help.o):/«PKGBUILDDIR»/lib/argp-fmtstream.h:207: first defined here ../lib/libmisc.a(argp-fmtstream.o): In function `argp_fmtstream_putc': /«PKGBUILDDIR»/lib/argp-fmtstream.h:233: multiple definition of `argp_fmtstream_putc' ../lib/libmisc.a(argp-help.o):/«PKGBUILDDIR»/lib/argp-fmtstream.h:233: first defined here ../lib/libmisc.a(argp-fmtstream.o): In function `argp_fmtstream_puts': /«PKGBUILDDIR»/lib/argp-fmtstream.h:220: multiple definition of `argp_fmtstream_puts' ../lib/libmisc.a(argp-help.o):/«PKGBUILDDIR»/lib/argp-fmtstream.h:220: first defined here collect2: error: ld returned 1 exit status make[4]: *** [blame] Error 1 Makefile:353: recipe for target 'blame' failed make[4]: Leaving directory '/«PKGBUILDDIR»/src' make[3]: *** [all] Error 2 Makefile:275: recipe for target 'all' failed make[3]: Leaving directory '/«PKGBUILDDIR»/src' make[2]: *** [all-recursive] Error 1 Makefile:322: recipe for target 'all-recursive' failed make[2]: Leaving directory '/«PKGBUILDDIR»' make[1]: *** [all] Error 2 Makefile:258: recipe for target 'all' failed make[1]: Leaving directory '/«PKGBUILDDIR»' dh_auto_build: make -j1 returned exit code 2 make: *** [build-arch] Error 2 debian/rules:7: recipe for target 'build-arch' failed dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 signature.asc Description: Digital signature
Bug#760170: Reproduced with sysvinit
On Mon, Jan 19, 2015 at 03:10:17AM -0500, Michael Gilbert wrote: Andrew, do you have any historical knowledge about this? I have this funny feeling that it's always done this, from before I took over maintenance of it. You're right though, this is clearly suboptimal, so we should fix it. I will attempt to do some work on it this coming week. signature.asc Description: Digital signature
Bug#599972: argus_3.0.0-3.1_mipsel.changes REJECTED
On Sat, Feb 15, 2014 at 12:03:39PM +1100, Aníbal Monsalve Salazar wrote: On Sat, Feb 15, 2014 at 12:03:22AM +, Debian FTP Masters wrote: argus-server: lintian output: 'embedded-library usr/sbin/argus: libpcap', automatically rejected package. argus-server: If you have a good reason, you may override this lintian tag. === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. Hello Andrew, The patch below is the debdiff between 3.0.0-3 and Steven's NMU. The NMU was rejected as you could see above. Do you think there is a good reason to override the lintian error? I have no familiarity with argus 3.0. Someone else has packaged it for experimental, not me. On the face of it, I see no reason to be statically linking libpcap into argus, so I don't think overriding the lintian error is the right approach. Regards, Aníbal debdiff argus_3.0.0-3.dsc argus_3.0.0-3.1.dsc diff -u argus-3.0.0/debian/rules argus-3.0.0/debian/rules --- argus-3.0.0/debian/rules +++ argus-3.0.0/debian/rules @@ -14,6 +14,7 @@ export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) confflags += --build $(DEB_HOST_GNU_TYPE) @@ -42,7 +43,8 @@ --bindir=/usr/bin \ --sysconfdir=/etc \ --mandir=/usr/share/man \ - --includedir=/usr/include CFLAGS=$(CFLAGS) + --includedir=/usr/include CFLAGS=$(CFLAGS) \ + --with-libpcap=/usr/lib/$(DEB_HOST_MULTIARCH) binary-indep: build dh_testroot diff -u argus-3.0.0/debian/changelog argus-3.0.0/debian/changelog --- argus-3.0.0/debian/changelog +++ argus-3.0.0/debian/changelog @@ -1,3 +1,10 @@ +argus (2:3.0.0-3.1) experimental; urgency=medium + + * Non-maintainer upload. + * Set libpcap library path. Patch by Dejan Latinovic. Closes: #599972 + + -- Steven J. Hill steven.h...@imgtec.com Fri, 14 Feb 2014 20:39:51 + + argus (2:3.0.0-3) experimental; urgency=low * debian/rules: make /var/log/argus 750 again signature.asc Description: Digital signature
Bug#678968: libpam-barada: Authentication service cannot retrieve user credentials on successful login
severity 678968 normal thanks On Mon, Oct 22, 2012 at 10:48:53PM +0200, Salvatore Bonaccorso wrote: Having this, I'm usure the bug is really 'grave', as the intended use of the pam-module is documented this way. Thank you for doing the research, Salvatore. Given the original submitter has not communicated further on this bug, and it looks like they are doing it wrong anyway, I'm downgrading the severity of this bug. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670483: Looks like a fix is in the works
https://github.com/PromyLOPh/pianobar/issues/236#issuecomment-5436544 implies that we can expect a new upstream release in a week or so. signature.asc Description: Digital signature
Bug#645760: Bug#643470: [pkg-dhcp-devel] Bug#643470: Status of isc-dhcp-client
On Mon, Mar 05, 2012 at 09:48:48AM +, peter green wrote: I just reviewed the most recent email I exchanged with the ISC product manager, and she actually said end of February, although she wasn't a betting woman. So let's wait until March 1 to take stock of the situation. If no 4.2.4 upstream release has been made by March 1, I will check in with them to get an updated timeframe, and if it's anything more than a week or so, I'll repack the tarball. It's now the 5th of match and still no new upstream release. Has any progress with upstream been made? I just heard back that they're running behind schedule by about a month, so I'll proceed with making a release with a stripped tarball to address #645760 signature.asc Description: Digital signature
Bug#643470: Bug#643569: Bug#643470: [pkg-dhcp-devel] Bug#643470: Status of isc-dhcp-client
On Wed, Mar 07, 2012 at 09:28:48PM +0100, Robert Millan wrote: El 7 de març de 2012 20:15, Andrew Pollock apoll...@debian.org ha escrit: I just heard back that they're running behind schedule by about a month, so I'll proceed with making a release with a stripped tarball to address #645760 Please don't forget 643569. ACK. I'll get this patch in as well. signature.asc Description: Digital signature
Bug#643470: [pkg-dhcp-devel] Bug#643470: Status of isc-dhcp-client
On Mon, Mar 05, 2012 at 09:48:48AM +, peter green wrote: I just reviewed the most recent email I exchanged with the ISC product manager, and she actually said end of February, although she wasn't a betting woman. So let's wait until March 1 to take stock of the situation. If no 4.2.4 upstream release has been made by March 1, I will check in with them to get an updated timeframe, and if it's anything more than a week or so, I'll repack the tarball. It's now the 5th of match and still no new upstream release. Has any progress with upstream been made? I'll check in with them tomorrow. signature.asc Description: Digital signature
Bug#643470: [pkg-dhcp-devel] Bug#643470: Status of isc-dhcp-client
On Fri, Feb 17, 2012 at 07:29:19PM +, peter green wrote: Currently, the version of isc-dhcp-client in unstable suffers two rc bugs, a FTBFS bug ( 643569 ) and a non-free IETF documents bug ( 645760 ) both related to embedded bind source. Furthermore isc-dhcp-client FTBFS in testing due to bug 643470 (which is fixed in unstable). It has been a month since the lastest post to any of these bug reports Is there any progress on solving these issues in a clean manner? It seems the ideal soloution is to stop embedding bind at all (but that requires changes on the bind side) and second best would be for upstream to make a new upstream release of isc-dhcp-client with an updated bind tarball If not would you consider applying the quick and dirty soloution of simply repacking the upstream tarball to contain a fixed bind tarball? Hello, I have been working with upstream on addressing both of these issues, and I am hopeful that the 4.2.4 release, which is due in the next couple of months, to address these issues. I'm waiting to see how much better that release looks. regards Andrew signature.asc Description: Digital signature
Bug#643470: [pkg-dhcp-devel] Bug#643470: Status of isc-dhcp-client
On Sun, Feb 19, 2012 at 10:33:52PM +0100, Julien Cristau wrote: On Sun, Feb 19, 2012 at 13:22:27 -0800, Andrew Pollock wrote: I have been working with upstream on addressing both of these issues, and I am hopeful that the 4.2.4 release, which is due in the next couple of months, to address these issues. I'm waiting to see how much better that release looks. Hrm. I'd very much appreciate a fix in sid sooner than next couple of months, if possible. At least for the ftbfs. I just reviewed the most recent email I exchanged with the ISC product manager, and she actually said end of February, although she wasn't a betting woman. So let's wait until March 1 to take stock of the situation. If no 4.2.4 upstream release has been made by March 1, I will check in with them to get an updated timeframe, and if it's anything more than a week or so, I'll repack the tarball. signature.asc Description: Digital signature
Bug#643470: [pkg-dhcp-devel] Bug#643470: Status of isc-dhcp-client
On Sun, Feb 19, 2012 at 11:03:17PM +, peter green wrote: Hello, I have been working with upstream on addressing both of these issues, and I am hopeful that the 4.2.4 release, which is due in the next couple of months, to address these issues. I'm waiting to see how much better that release looks. Speaking both as someone trying to get the armhf port into shape and more generally we would really like to get the rc bugs fixed sooner than the next couple of months. See my other email. Turns out I was grossly generalising, and they're targeting around the end of the month. Especially as 4.1.1-P1-17 (in testing) has a FTBFS bug on all architectures so we can't do a binnmu in testing. I have prepared a NMU to fix the rc bugs in isc-dhcp-client by the most direct approaches and was in the processor of discussing it's sponsorship to delayed/5 with Hector Oron (i'm not a dd yet) when I received your mail. I appreciate the work I have put into this NMU will be thrown away when the ultimate soloution of eliminating the embedded code copy is implemented but I still thing the NMU is worth doing so we can get armhf teting into shape sooner rather than later. The package I'm in the process of trying to get NMU'd is at http://mentors.debian.net/package/isc-dhcp Please tell me if you are happy with the NMU so I can upload it promptly. Alternatively if you have problems with the NMU then please point them out to me so I can prepare a fixed NMU. How about you just send me a patch against what's in the Git repository (at head)? I've got an unreleased 4.2.2-3 in there that I've been working on. Until/unless I get a response I plan to go through with the plan of a NMU to delayed/5. signature.asc Description: Digital signature
Bug#643569: [pkg-dhcp-devel] Bug#643569: [ISC-Bugs #26273] 4.2.2 fails to build with -Werror=unused-but-set-variable (Debian/kFreeBSD)
On Mon, Jan 23, 2012 at 06:04:41PM +, Tomasz Mrugalski via RT wrote: Thank you for reporting this bug. It is already fixed in BIND 9.8.2rc1. That verison is planned to be included in the next ISC DHCP release. The code now builds properly on my Debian box with kFreeBSD kernel. Thanks. Can you confirm that this fix will be present in 4.2.3? signature.asc Description: Digital signature
Bug#645760: [pkg-dhcp-devel] Bug#645760: Dynamically linking to bind (bugs #643569 and #645760)
On Mon, Jan 16, 2012 at 05:21:29PM -0500, Michael Gilbert wrote: tag 645670 patch thanks Hi, Here is a patch that fixes these two issues. It dynamically links to bind and removes the embedded code (note that it would be more ideal to repackage the upstream source without bind, but for clarity I just remove it in the clean rule for now). Note that you'll have to apply the patch in bug #656150 to bind in order for these changes to work. Hey Michael, Thanks for working on this. I've taken a quick look at the patch in #656150 as well, and I really think this should be sent back to the ISC BIND folks if you haven't already. I'm meeting with the ISC DHCP folks over lunch today, so I'll discuss these two patches with them. signature.asc Description: Digital signature
Bug#643470: [pkg-dhcp-devel] Bug#643470: Still failing
On Sun, Jan 08, 2012 at 11:43:18PM +0100, Christoph Egger wrote: found 643569 4.2.2-2 bye Hi! Still failing the same way on kfreebsd. See https://buildd.debian.org/status/fetch.php?pkg=isc-dhcparch=kfreebsd-amd64ver=4.2.2-2stamp=1325997447 Agreed that it's still failing, but this looks like #643569, not #643470, don't you agree? I can see plenty of unused-but-set-variable warnings in the build log you're referring to, but I don't see them being fatal. I do see the redefinition of 'struct in6_pktinfo' error being fatal. If you concur, I'd like to mark this bug as notfound in 4.2.2-2 regards Andrew signature.asc Description: Digital signature
Bug#648676: [pkg-dhcp-devel] Bug#648676: NMU
On Wed, Jan 04, 2012 at 07:11:43PM +0100, Bastian Blank wrote: tags 648676 patch thanks I'll upload this NMU later the day. This removes the option to set a hostname from the script completely. Further changes needs to move this file to be a conffile. I just got around to looking at your patch. It is completely unacceptable. You do *NOT* have permission to NMU with this patch. I am working on returning to previous behaviour now. If I get it done tonight I'll test tomorrow night and then upload. signature.asc Description: Digital signature
Bug#648676: [pkg-dhcp-devel] Bug#648676: NMU
On Wed, Jan 04, 2012 at 07:11:43PM +0100, Bastian Blank wrote: tags 648676 patch thanks I'll upload this NMU later the day. This removes the option to set a hostname from the script completely. Further changes needs to move this file to be a conffile. Please don't. I have a large upload prepared already. I intend to revert the hostname setting functionality before making that upload. signature.asc Description: Digital signature
Bug#648676: [pkg-dhcp-devel] Bug#648676: NMU
On Wed, Jan 04, 2012 at 07:44:25PM +0100, Bastian Blank wrote: On Wed, Jan 04, 2012 at 10:26:54AM -0800, Andrew Pollock wrote: Please don't. You got until end of the week. I don't like being given ultimatums. I'm well aware of the issue, and I will get around to working on it as soon as time permits. That may or may not be the end of the week. You have proposed an NMU and I have indicated that it conflicts with a larger body of work that I already have queued up. What would be more constructive and expedient would be to send me a patch to the Git repository that incorporates the intent of your NMU, then I can move to testing and making an upload faster. That said, once I get a chance to look at your NMU diff I can probably just apply that to the repository and move onto testing the package and making the upload, so no big deal either way. I will get to this as soon as I can. signature.asc Description: Digital signature
Bug#650245: python-asterisk: fails to work with current version of Asterisk
Package: python-asterisk Version: 0.1a3+r160-4.1 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I tried to use python-asterisk to connect to my Asterisk server, after recently upgrading to Squeeze, and it failed to connect, raising an exception about Server banner was incorrect. Turns out, the expected banner is hardcoded as Asterisk Call Manager/1.0, and Asterisk is now advertising itself as Asterisk Call Manager/1.1 A naive change to the hardcoded string expected fixes this, but I'm not sure if there are other compatibility issues beyond that. Given I'm having this issue with Asterisk 1:1.6.2.9-2+squeeze3 in stable, it most probably is also applicable to 1:1.8.7.1~dfsg-2 in unstable - -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-asterisk depends on: ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii python-support 1.0.10 automated rebuilding support for P python-asterisk recommends no packages. python-asterisk suggests no packages. - -- Configuration Files: /etc/asterisk/py-asterisk.conf [Errno 13] Permission denied: u'/etc/asterisk/py-asterisk.conf' - -- no debconf information - -- debsums errors found: debsums: changed file /usr/share/pyshared/Asterisk/Manager.py (from python-asterisk package) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJO0zCLAAoJEFHf2Ts++3nvsDMQAI+M2F8xMW51Z97JVUX8SpME xu8iQG6DfgR+Gde7PwhB2RwC3tzxd8ugPura1FPKiG1HvpQkvjww4NTL+ANK+mCa SodFRAe7W6mNG7cjGnYktIUdqEbX3Ooc7JLe5Fo5Pt6rATZt1FkS8oDC8mok9rne hsG8TZ8vYhw5B9zXnVBrrZ6+X4rfpouf2W9wwmKc1/FETocNpyYxqk6OtcBkkTfG wW7lZBKOkHj75D2IRJzO6tO6PcJycCaxB0WhH7syX5qiMoQQYhwa/onp41MSdXE2 em1RCgzpC4ppKFkOOFbl7L1UKg7/zAdDtHAUndiS8hEgPMXG+p3ggfEZZkz8H5iZ 1611BrhRIff/wQ/422mFFAYFkUc8sVcAuHy+yMlDydyJvfoZ3ZZAbLM2GSD16SCh Ix87bPZHsMkV1QzA/R8/OKLppZocjIdKpEsoRJRMchzBkQ3FgzO6t2yzSooL11W1 ZeRuftYRoQjo1pTJEZiGhh8eWfdCwG26cwhy+toPLliNsVawWxANvifGhh8uMcrB yHClJrqwwEcIXsXQwUcbDdpHfCM4E0po9939SAIgpKMIbOotQtbxGDalPbj5Uhq2 SAuOIIyXDFCTegzScUjBc0EekiIeERLCbvOpbNSoq7oXUkY68hmjGgT4495caMyT DJc+HVfjKXQzjg4tVVi1 =gK8G -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609851: [updated] incorrect variables used to set hostname in dhclient-script
On Fri, Nov 25, 2011 at 01:25:39AM -0500, Tim Heckman wrote: On Thu, Nov 24, 2011 at 11:06 PM, Andrew Pollock apoll...@debian.orgwrote: I've actually been poking at this some more, and it turns out I've made a grave error in assuming that by not requesting a particular option you don't get it anyway. It turns out in testing, that even not requesting the host-name option, if it's set in the server, the client seems to get it, so this totally blows up my grand plans of telling people who don't like the hostname setting behaviour to just not request the hostname, so I have to revisit everything. regards Andrew I'm usually not a fan of the files, depending on the software, but maybe an '/etc/default/dhclient' file would make sense here. I don't mean to over-complicate the dhclient-script here, but it would allow the administrator to configure how the hostname is set with a simply flip of a switch, instead of a hook needing to be made as well as having to worry about what logic to use in the script. For example in /etc/default/dhclient: set_hostname=yes # sets the hostname every time set_hostname=no # never sets the hostname set_hostname=detect # maybe dynamic, or something. This option sets the hostname based on what /etc/hostname looks like. If the file exists and contains no data, set the hostname. If not, have the local hostname override the one given out by DHCP. I'm willing to bet, however, that there may be better options available. For anyone who comes looking for a fix, here is a workaround I've managed to throw together for an exit hook for dhclient that sets the hostname and does some logic so it only sets it if needed. Unfortunately, I do not have the file on my local system but you can download the raw version of this pastebin to /etc/dhcp/dhclient-exit-hooks.d/set_hostname: - http://pastie.org/2917845 That could probably use a little bit of cleaning up, but it works. Is this targeted at 4.2.2-1 or earlier? If it's targeted at 4.2.2-1, it should be a case of a dhclient-enter-hook that redefines the set_hostname() function. Using an exit hook means the hostname is going to flip flop, which probably isn't the end of the world. signature.asc Description: Digital signature
Bug#609851: [updated] incorrect variables used to set hostname in dhclient-script
On Thu, Nov 24, 2011 at 09:27:12AM -0500, Tim Heckman wrote: Andrew, Thank you for explaining the policy on your policy being no policy. :p No worries :-) But in all seriousness. I completely forgot about the hooks that can be used for DHCP and I entirely agree this makes more sense to do it this way. Thanks for the explanation. No worries also :-) If you are State-side I hope you have a great Thanksgiving! Thanks, you too. I've actually been poking at this some more, and it turns out I've made a grave error in assuming that by not requesting a particular option you don't get it anyway. It turns out in testing, that even not requesting the host-name option, if it's set in the server, the client seems to get it, so this totally blows up my grand plans of telling people who don't like the hostname setting behaviour to just not request the hostname, so I have to revisit everything. regards Andrew signature.asc Description: Digital signature
Bug#609851: [updated] incorrect variables used to set hostname in dhclient-script
On Sun, Nov 20, 2011 at 07:06:52PM -0500, Tim Heckman wrote: [snip] Andrew, Thanks for the information about how it'll be implemented moving forward. Not to shy too far off-topic, I'm just trying to explain my use case for this. I work for a pretty well known cloud services provider. We create distribution templates for Debian as well as others. Most other distributions look at the state of the system to determine whether the hostname should be set by DHCP. I've yet to find a use case where this mechanism is wrong. We have our DHCP servers set the hostname by default so the system gets an initial hostname and is ready to go. Every other distribution checks the state of the system to determine if the hostname should be set. If the hostname setting is blank/empty they will set the hostname as obtained by DHCP. Otherwise, it sets the configured hostname. I believe the behavior of it not even checking if the hostname should be set or not is surprising people as it had not forced it before (as far as I am aware). This bug was opened because dhclient wasn't setting the hostname when it should. I'm not a huge fan of using it on servers, but the patch I submitted earlier was based on an idea I obtained from the way Ubuntu handles this. It checks to see if the /etc/hostname file contains any data. If the length of the file is zero, it sets the dhcp hostname. Otherwise, if it has data, it sets that instead. This provides a more uniform behavior across distributions. I definitely understand your insight on the changes you feel should be made. I agree that by default it should not request host-name, but I still think the dhclient-script should contain the logic to check to whether it should set the hostname or not when it does request it. Thanks for getting it to set the hostname again in 4.2.2-1. I hope you'll consider my feedback about the path that will be taken moving forward. Here's how I feel about the topic: dhclient-script shouldn't have policy decisions hard-coded in it. So my policy is that there is no policy. I know that I can't please everyone on this matter, which is why dhclient-script is slowly getting refactored so that everything is broken out into shell functions that can be overridden by the local admin. Currently in 4.2.2-1, the hostname stuff is handled by a set_hostname() function. You're free to provide a dhclient-enter-hook in /etc/dhcp/dhclient-enter-hooks.d/ that redefines set_hostname() with whatever local business logic floats your boat. I really feel like this is the best compromise, because I can assure you that someone else will come out of the woodwork and argue the exact opposite position to you. My end goal is to get dhclient-script so that all of the logic can be overridden by the local admin, without requiring local modifications to dhclient-script itself. regards Andrew signature.asc Description: Digital signature
Bug#609851: [updated] incorrect variables used to set hostname in dhclient-script
On Sun, Nov 20, 2011 at 03:06:03PM -0500, Tim Heckman wrote: On Sun, Nov 20, 2011 at 12:22 AM, Andrew Pollock apoll...@debian.orgwrote: dhclient-script got some major overhauling in 4.2.2-1, and your patch is no longer applicable. Is the original bug still present in 4.2.2-1? regards Andrew Andrew, It does appear to work normally in 4.2.2-1 on Sid. However, unless I am missing something it appears that you cannot specify a hostname locally without modifying '/etc/dhcp/dhclient.conf' to not request that information via DHCP or simply using static IP addresses. For example if I make the following entry in /etc/hosts and issue the following command, the hostname (sid-test) is not set on boot: 10.0.0.2sid-testsid-test.timheckman.net `echo sid-test /etc/hostname` Instead, the hostname that was provided by DHCP is set every time. Am I missing a way to allow you to specify a hostname locally and not use the one the DHCP server is providing without digging too deep in to configuration files? I do not feel the dhclient-script should handle this way and should only set the hostname provided via DHCP if the local hostname is '(none)', 'localhost', if /etc/hostname has a size of 0, or if /etc/hostname has a size of zero and it differs from the current hostname set. 4.2.2-2 is going to stop requesting the host-name option by default. I don't feel that dhclient-script should be making implicit assumptions by looking at the state of the system, it should only do what it is explicitly configured to do, i.e. if the host-name option is requested, it should set the host-name. Since this behaviour (by default) is clearly surprising people (and causing problems), I'm changing it to not be the default behaviour. Also, it's good to see progress was made on an unstable version. How is this going to be fixed up in the Debian Stable (6.0/Squeeze) package? I'll have to review the situation in Squeeze. signature.asc Description: Digital signature
Bug#645760: Please remove RFCs from embedded BIND sources
Hi, Could you please remove the RFCs from the embedded BIND sources in the DHCP sources? As they're non-free, this makes DHCP non-free from Debian's perspective, which royally complicates things. Please maintain the Cc of this email to keep our bug tracking system in the loop. regards Andrew - Forwarded message from Simon Josefsson si...@josefsson.org - Date: Tue, 18 Oct 2011 14:24:57 +0200 From: Simon Josefsson si...@josefsson.org To: sub...@bugs.debian.org Subject: Bug#645760: Source package contains non-free IETF RFC/I-D Severity: serious Package: isc-dhcp Version: 4.2.2-1 User: debian-rele...@lists.debian.org Usertags: nonfree-doc rfc Hi! This source package contains the following files from the IETF under non-free license terms: dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/contrib/zkt/doc/rfc5011.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1032.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc5011.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1033.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1034.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1035.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1101.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1122.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1123.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1183.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1348.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1535.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1536.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1537.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1591.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1611.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1612.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1706.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1712.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1750.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1876.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1886.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1912.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1982.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1995.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1996.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2052.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2104.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2119.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2133.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2136.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2137.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2163.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2168.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2181.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2230.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2308.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2317.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2373.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2374.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2375.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2418.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2535.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2536.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2537.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2538.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2539.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2540.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2541.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2553.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2671.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2672.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2673.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2782.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2825.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2826.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2845.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2874.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2915.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2929.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2930.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2931.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc3007.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc3008.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc3071.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc3090.txt
Bug#648676: [pkg-dhcp-devel] Bug#648676: isc-dhcp-client - Changes hostname
On Mon, Nov 14, 2011 at 12:37:39AM +0100, Bastian Blank wrote: Package: isc-dhcp-client Version: 4.2.2-1 Severity: critical dhclient-script changes the hostname without being asked to do so. This breaks all kinds of stuff that relates to the hostname, like sudo. And it is also wrong, because the network name is not the hostname. Well actually it is asked to by requesting the host-name option in dhclient.conf. Since this is an ongoing point of contention, I'll be making a future upload with the host-name option removed from the default list of options requested. signature.asc Description: Digital signature
Bug#645760: [dhcp-b...@isc.org: [ISC-Bugs #26650] AutoReply: Please remove RFCs from embedded BIND sources]
- Forwarded message from DHCP Bugs via RT dhcp-b...@isc.org - From: DHCP Bugs via RT dhcp-b...@isc.org To: apoll...@debian.org Subject: [ISC-Bugs #26650] AutoReply: Please remove RFCs from embedded BIND sources Date: Sun, 20 Nov 2011 04:43:25 + Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: Please remove RFCs from embedded BIND sources, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [ISC-Bugs #26650]. Please include the string: [ISC-Bugs #26650] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, dhcp-b...@isc.org - Hi, Could you please remove the RFCs from the embedded BIND sources in the DHCP sources? As they're non-free, this makes DHCP non-free from Debian's perspective, which royally complicates things. Please maintain the Cc of this email to keep our bug tracking system in the loop. regards Andrew - Forwarded message from Simon Josefsson si...@josefsson.org - Date: Tue, 18 Oct 2011 14:24:57 +0200 From: Simon Josefsson si...@josefsson.org To: sub...@bugs.debian.org Subject: Bug#645760: Source package contains non-free IETF RFC/I-D Severity: serious Package: isc-dhcp Version: 4.2.2-1 User: debian-rele...@lists.debian.org Usertags: nonfree-doc rfc Hi! This source package contains the following files from the IETF under non-free license terms: dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/contrib/zkt/doc/rfc5011.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1032.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc5011.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1033.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1034.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1035.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1101.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1122.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1123.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1183.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1348.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1535.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1536.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1537.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1591.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1611.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1612.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1706.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1712.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1750.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1876.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1886.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1912.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1982.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1995.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc1996.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2052.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2104.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2119.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2133.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2136.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2137.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2163.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2168.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2181.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2230.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2308.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2317.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2373.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2374.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2375.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2418.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2535.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2536.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2537.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2538.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2539.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2540.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2541.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2553.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2671.txt dhcp-4.2.2/bind/bind.tar.gz:bind-9.8.0-P4/doc/rfc/rfc2672.txt
Bug#609851: [updated] incorrect variables used to set hostname in dhclient-script
On Wed, Nov 02, 2011 at 06:35:37PM -0400, Tim Heckman wrote: User error on my last diff here is an updated one that is correct: dhclient-script got some major overhauling in 4.2.2-1, and your patch is no longer applicable. Is the original bug still present in 4.2.2-1? regards Andrew signature.asc Description: Digital signature
Bug#643569: 4.2.2 fails to build with -Werror=unused-but-set-variable
Hello, 4.2.2 doesn't build on kfreebsd. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643569 for more details. I've been given a patch that fixes it, but it needs to be made to the BIND sources that are in the tarball that gets unpacked at build time, so I don't have a good way of applying the patch during the build. I think I'm stuck resolving this bug until you make a new release that includes the patch. Please maintain the Cc to keep our bug tracking system in the loop. - Forwarded message from Robert Millan r...@debian.org - Date: Sat, 15 Oct 2011 13:29:36 +0200 From: Robert Millan r...@debian.org To: 643...@bugs.debian.org Subject: Bug#643569: patch tag 643569 patch thanks Hi, Here's a patch to fix this. -- Robert Millan --- bind/bind-9.8.0-P4/configure.in~2011-02-03 06:50:05.0 +0100 +++ bind/bind-9.8.0-P4/configure.in 2011-10-15 12:56:31.911737774 +0200 @@ -263,7 +263,7 @@ # as it breaks how the two halves (Basic and Advanced) of the IPv6 # Socket API were designed to be used but we have to live with it. # Define _GNU_SOURCE to pull in the IPv6 Advanced Socket API. - *-linux*) + *-linux* | *-*-gnu | *-gnu*) STD_CDEFINES=$STD_CDEFINES -D_GNU_SOURCE CPPFLAGS=$CPPFLAGS -D_GNU_SOURCE ;; - End forwarded message - -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643470: 4.2.2 fails to build with -Werror=unused-but-set-variable
Hello,
Due to a rather fabulous chain of events, I can't build 4.2.2 with GCC 4.6.1
(which is what we're using in Debian to build packages in unstable)
In a nutshell, it looks like configure.ac completely clobbers CFLAGS under
some circumstances, and adds the -Werror flag. The -Werror flag now seems to
imply -Werror=unused-but-set-variable, and well, there's plenty of that in
the DHCP source :-)
Michael Gilbert was kind enough to provide a cleanup patch to fix 4.2.2, but
it's going to be a nightmare to maintain in Debian. Please consider using it
to clean up your codebase.
Please also consider revising the logic in configure.ac. I'm about to trial
a build with that CFLAGS clobbering logic patched out to see if I can get
the package to build.
Please maintain the Cc line to keep our bug tracking system in the loop
- Forwarded message from Michael Gilbert michael.s.gilb...@gmail.com -
Date: Sun, 23 Oct 2011 15:17:58 -0400
From: Michael Gilbert michael.s.gilb...@gmail.com
To: 643...@bugs.debian.org, control cont...@bugs.debian.org
Subject: Bug#643470: isc-dhcp: FTBFS: comapi.c:425:15: error: variable 'status'
set
but not used [-Werror=unused-but-set-variable]
tag 643470 patch
thanks
I've created a patch that addresses all of the unused-but-set-variable
issues. See attached.
Best wishes,
Mike
--- isc-dhcp-4.2.2.orig/dst/prandom.c
+++ isc-dhcp-4.2.2/dst/prandom.c
@@ -694,7 +694,6 @@
{
int dir = 0, b;
int bytes, n, cmd = 0, dig = 0;
- int start =0;
/*
* now get the initial seed to put into the quick random function from
* the address of the work structure
@@ -709,7 +708,6 @@
/* pick a random number in the range of 0..7 based on that random number
* perform some operations that yield random data
*/
- start = work-filled;
n = (dst_s_quick_random(bytes) DST_SHIFT) 0x07;
switch (n) {
case 0:
only in patch2:
unchanged:
--- isc-dhcp-4.2.2.orig/client/clparse.c
+++ isc-dhcp-4.2.2/client/clparse.c
@@ -59,7 +59,9 @@
{
struct client_config *config;
struct interface_info *ip;
- struct parse *parse;
+#ifdef LATER
+ struct parse *parse = NULL;
+#endif
isc_result_t status;
unsigned code;
@@ -159,7 +161,6 @@
(struct interface_info *)0,
top_level_config);
- parse = NULL;
if (status != ISC_R_SUCCESS) {
;
#ifdef LATER
only in patch2:
unchanged:
--- isc-dhcp-4.2.2.orig/client/dhclient.c
+++ isc-dhcp-4.2.2/client/dhclient.c
@@ -1818,7 +1818,6 @@
{
struct client_state *client = cpp;
- int result;
int interval;
int increase = 1;
struct timeval tv;
@@ -1901,7 +1900,7 @@
ntohs (sockaddr_broadcast.sin_port), (long)(client - interval));
/* Send out a packet. */
- result = send_packet (client - interface, (struct packet *)0,
+ send_packet (client - interface, (struct packet *)0,
client - packet,
client - packet_length,
inaddr_any, sockaddr_broadcast,
@@ -2037,7 +2036,6 @@
{
struct client_state *client = cpp;
- int result;
int interval;
struct sockaddr_in destination;
struct in_addr from;
@@ -2169,7 +2167,7 @@
if (destination.sin_addr.s_addr != INADDR_BROADCAST
fallback_interface)
- result = send_packet (fallback_interface,
+ send_packet (fallback_interface,
(struct packet *)0,
client - packet,
client - packet_length,
@@ -2177,7 +2175,7 @@
(struct hardware *)0);
else
/* Send out a packet. */
- result = send_packet (client - interface, (struct packet *)0,
+ send_packet (client - interface, (struct packet *)0,
client - packet,
client - packet_length,
from, destination,
@@ -2194,15 +2192,13 @@
{
struct client_state *client = cpp;
- int result;
-
log_info (DHCPDECLINE on %s to %s port %d,
client - name ? client - name : client - interface - name,
inet_ntoa (sockaddr_broadcast.sin_addr),
ntohs (sockaddr_broadcast.sin_port));
/* Send out a packet. */
- result = send_packet (client - interface, (struct packet *)0,
+ send_packet (client - interface, (struct packet *)0,
client - packet,
client - packet_length,
inaddr_any, sockaddr_broadcast,
@@ -2214,7 +2210,6 @@
{
struct client_state *client = cpp;
-
Bug#628141: [pkg-dhcp-devel] Bug#628141: reopening 628141
On Sat, Jun 18, 2011 at 02:23:23PM +0200, Tomas Janousek wrote: reopen 628141 thanks It's not fixed in 4.1.1-P1-17. The hostname is being reset to whatever DHCP says, even if the machine is supposed to have a fixed hostname. The problem with X rejecting connections was experienced with 4.1.1-P1-17. Please, take a closer look. If you don't want your hostname set by DHCP, don't request the host-name option in dhclient.conf. See also #627825 signature.asc Description: Digital signature
Bug#628141: [pkg-dhcp-devel] Bug#628141: patch that should fix the isue
On Sat, Jun 18, 2011 at 06:36:23PM +0200, Peter Marschall wrote: Hi Andrew, Tomas has a point here. While the part regarding the invalid variables was fixed in 4.1.1-17, the logic still looks a bit fishy: only set the host name if the old one and the new one are given (I am aware that I am the one to blame ;-) You may be, but I'm not convinced this kind of logic belongs in dhclient-script in the first place. Please find attached a patch that hopefully fixes the issue for good: Here's the logic it tries to implement: For the non-udeb case, set the hostname in Linux kfreebsd only if 1) the new hostname isn't empty = make sure that we do not reset the hostname to empty 2) the current hostname is empty (or '(none)' or 'localhost') or matches the old hostname from DHCP = make sure that we only set the host name if there is no valid one or if the old hostname came from DHCP too 3) the current hostname is empty or the new hostname from DHCP differs from the old one from DHCP = make sure that we set the host name only if it really changed If you think it is the correct solution, please consider including it in the next release of isc-dhcp for Debian As I've said on this bug and another, I really think the best solution if you don't want DHCP to be determining your hostname is to not request it in the first place, not to have some tricky logic in dhclient-script itself to try and infer the intent of the local administrator. regards Andrew signature.asc Description: Digital signature
Bug#628141: [pkg-dhcp-devel] Bug#628141: reopening 628141
On Sat, Jun 18, 2011 at 08:11:44PM +0200, Tomáš Janoušek wrote: Hello, On Sat, Jun 18, 2011 at 09:57:17AM -0700, Andrew Pollock wrote: On Sat, Jun 18, 2011 at 02:23:23PM +0200, Tomas Janousek wrote: It's not fixed in 4.1.1-P1-17. The hostname is being reset to whatever DHCP says, even if the machine is supposed to have a fixed hostname. The problem with X rejecting connections was experienced with 4.1.1-P1-17. Please, take a closer look. If you don't want your hostname set by DHCP, don't request the host-name option in dhclient.conf. See also #627825 Okay, sorry. I think that maybe it shouldn't be set in the default dhclient.conf, or there should at least be a note about it in NEWS.Debian. This is going to bite everyone who uses dhclient on a portable computer. I'm open to changing the default to not request the host-name option, especially since there is the behaviour change that you have observed. I can also add a mention to NEWS.Debian. This wasn't an intentional change, but I also didn't realise the old behaviour existed either. Also, what's going to happen if the DHCP server does send the hostname anyway? I'm afraid that the hostname will be changed then, allowing a malicious DHCP server to change hostnames of Debian machines whenever it likes to. A malicious DHCP server can do a lot worse than just change the hostname. What exactly is breaking for you with respect to X when the hostname changes? You get inconsistencies between $DISPLAY and reality, which messes up local X11 applications? signature.asc Description: Digital signature
Bug#615696: setting package to barada-pam libpam-barada, tagging 615696
# Automatically generated email from bts, devscripts version 2.10.35lenny7 # via tagpending # # barada-pam (0.5-2) unstable; urgency=low # # * Add patch from Andreas Moog to fix FTBFS with gold or ld --no-add-needed #(closes: #615696) # package barada-pam libpam-barada tags 615696 + pending -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611217: [pkg-dhcp-devel] Bug#611217: cve-2011-0413
On Fri, Feb 25, 2011 at 11:30:33AM -0500, Michael Gilbert wrote: Hi, Are you working on an updated squeeze package for this? If not, I'll prepare one for a DSA since the patch is fairly straightforward. If you could do an update for Squeeze I'd really appreciate it. signature.asc Description: Digital signature
Bug#611217: [pkg-dhcp-devel] Bug#611217: CVE-2011-0413: crash after DHCPv6 decline message
On Sat, Feb 12, 2011 at 01:09:30PM +0100, Julien Cristau wrote: On Thu, Feb 3, 2011 at 07:58:24 +1000, Andrew Pollock wrote: On Wed, Feb 02, 2011 at 09:51:05PM +0100, Moritz Mühlenhoff wrote: Hmm, that was a misunderstanding, then: It was tagged by release managers as not-a-blocker, i.e. it doesn't hold back the release if not fixed, a fix through unstable would still have been possible. Any way, not it's too late and we need a DSA. I'll open a ticket in the Debian Security Team queue. My apologies for the misunderstanding. I will proceed with fixing this in unstable ASAP, probably this evening. Any news? Sigh. Looks like I managed to do everything *except* upload it. Uploading now. signature.asc Description: Digital signature
Bug#611217: setting package to dhcp3-common dhcp3-client dhcp3-relay isc-dhcp-server-ldap dhcp3-server isc-dhcp-client-udeb isc-dhcp-relay isc-dhcp-server dhcp3-dev isc-dhcp-relay-dbg isc-dhcp-server-
# Automatically generated email from bts, devscripts version 2.10.35lenny7 # via tagpending # # isc-dhcp (4.1.1-P1-16) unstable; urgency=high # # * Patch by Raphael Geissert from 4.1-ESV for CVE-2011-0413 (closes: #611217) package dhcp3-common dhcp3-client dhcp3-relay isc-dhcp-server-ldap dhcp3-server isc-dhcp-client-udeb isc-dhcp-relay isc-dhcp-server dhcp3-dev isc-dhcp-relay-dbg isc-dhcp-server-dbg isc-dhcp-client-dbg isc-dhcp isc-dhcp-client isc-dhcp-common isc-dhcp-dev tags 611217 + pending -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611217: [pkg-dhcp-devel] Bug#611217: CVE-2011-0413: crash after DHCPv6 decline message
On Wed, Feb 02, 2011 at 09:15:39PM +0100, Moritz Mühlenhoff wrote: Why was there no maintainer reaction since a week? No we need to prepare a DSA for this :-/ There was no maintainer reaction because I thought previous responses were that it was okay to deal with post-release. Is this now not the case? signature.asc Description: Digital signature
Bug#611217: [pkg-dhcp-devel] Bug#611217: CVE-2011-0413: crash after DHCPv6 decline message
On Wed, Feb 02, 2011 at 09:51:05PM +0100, Moritz Mühlenhoff wrote: Hmm, that was a misunderstanding, then: It was tagged by release managers as not-a-blocker, i.e. it doesn't hold back the release if not fixed, a fix through unstable would still have been possible. Any way, not it's too late and we need a DSA. I'll open a ticket in the Debian Security Team queue. My apologies for the misunderstanding. I will proceed with fixing this in unstable ASAP, probably this evening. signature.asc Description: Digital signature
Bug#548099: severity of 548099 is serious
On Fri, Sep 10, 2010 at 08:43:00PM +0200, Peter Palfrader wrote:
# Automatically generated email from bts, devscripts version 2.10.35lenny7
severity 548099 serious
Please explain your rationale for making this a release critical bug.
According to http://release.debian.org/lenny/arch_qualify.html I don't think
kfreebsd-{i386,amd64} is even a release goal for Squeeze
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592361: [pkg-dhcp-devel] Bug#592361: libcrypto.so.0.9.8 accessed before /usr is mounted
On Wed, Oct 20, 2010 at 11:01:06PM +0100, Simon McVittie wrote: A possible patch follows. S Dude. Thank you so much for this patch. I've been lacking the time to dive into this particular bug. Unfortunately, I've been unable to get a successful build. ./configure: line 5723: syntax error near unexpected token `OPENSSL,' ./configure: line 5723: ` PKG_CHECK_MODULES(OPENSSL, openssl)' make: *** [patched-ldap/build-stamp] Error 2 on the face of it, it looks like your patch uncomments PKG_CHECK_MODULES(OPENSSL, [openssl]), which was previously commented out in the LDAP patch. This seems to be what's angering the build. I spent a considerable amount of time this evening tweaking patches, until I got to the point where I essentially had your patches, but with the above line still commented out. The build still failed. It looked like it couldn't find the symbols that had previously been found in libcrypto. I tried a build that omitted the LDAP stuff entirely, and just pulled out libcrypto, and that worked fine. I'm at a bit of a loss. But I have done the hard work that I'd been failing to find time to do, so I'll continue poking at this as time permits. I have a largish upload pending in the Git repository for this package, I just want to address this RC bug in that upload. You can see it at http://git.debian.org/?p=pkg-dhcp/isc-dhcp.git;a=summary if you want to try any additional patches. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592361: [pkg-dhcp-devel] Bug#592361: Bug#592361: libcrypto.so.0.9.8 accessed before /usr is mounted
On Thu, Oct 21, 2010 at 07:08:08PM +0100, Simon McVittie wrote: On Fri, 22 Oct 2010 at 03:16:59 +1000, Andrew Pollock wrote: ../configure: line 5723: syntax error near unexpected token `OPENSSL,' ../configure: line 5723: ` PKG_CHECK_MODULES(OPENSSL, openssl)' make: *** [patched-ldap/build-stamp] Error 2 on the face of it, it looks like your patch uncomments PKG_CHECK_MODULES(OPENSSL, [openssl]), which was previously commented out in the LDAP patch. This seems to be what's angering the build. Oh, sorry, I've only tried it in an unclean build environment (I'd have used sbuild if I NMU'd it, but I didn't want to NMU without knowing how to test the LDAP-patched version). You'll need to build-depend on pkg-config (and re-run autoconf, but you already do that) for that line to work. Aha! Success. Thanks again. Because the call to PKG_CHECK_MODULES is conditional, that code is actually wrong (although it's harmless because it's the only pkg-config call); strictly speaking you ought to add PKG_PROG_PKG_CONFIG earlier in configure.ac, in a location where it'll always be executed. Fortunately upstream has accepted that patch (or a variant of it), so I'll raise this with them and let them sort it out. Alternatively, you could probably just re-add the -lcrypto check at that location, and put it in CRYPTO_LIBS; that'd probably be sufficient too. I spent a considerable amount of time this evening tweaking patches, until I got to the point where I essentially had your patches, but with the above line still commented out. The build still failed. It looked like it couldn't find the symbols that had previously been found in libcrypto. Yes, that's why I uncommented that line. The story is: * the unpatched source tree thinks it needs -lcrypto for MD5, but it also contains a copypaste of openssl's MD5 implementation (in dst/), so the one in -lcrypto is never actually used (symbols in the executable win when linking) * the patched LDAP tree indirectly links -lssl and -lcrypto, as an implementation detail of libldap * using the MD5 implementation in -lcrypto when called via libldap, or the one in the executable otherwise, seems like badness, so the LDAP patchset builds a version of the dst library that lacks MD5 support * ... but then you need to link against -lcrypto explicitly, or you'll fail to find an MD5 implementation * I uncommented the check for OPENSSL instead of adding one for libcrypto, because I couldn't be bothered to devise one for libcrypto (it was getting late at night), and they're both in the libssl0.9.8 Debian package anyway Wee. I have a largish upload pending in the Git repository for this package, I just want to address this RC bug in that upload. You can see it at http://git.debian.org/?p=pkg-dhcp/isc-dhcp.git;a=summary if you want to try any additional patches. A git repository! I could have done with that (I imported it into git locally to hack on, in fact). Please add the Vcs-Git and Vcs-Browser fields to your source package, so any future bug-squashers get a nice hyperlink on packages.qa.debian.org, and can use debcheckout(1) :-) Ah yes. I'll do that. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592361: setting package to dhcp3-common dhcp3-client dhcp3-relay isc-dhcp-server-ldap dhcp3-server isc-dhcp-client-udeb isc-dhcp-relay isc-dhcp-server dhcp3-dev isc-dhcp-relay-dbg isc-dhcp-server-
# Automatically generated email from bts, devscripts version 2.10.35lenny7 # via tagpending # # isc-dhcp (4.1.1-P1-10) UNRELEASED; urgency=low # # * Added patch from Simon McVittie to stop unnecessary linking with libcrypto #(closes: #592361) # package dhcp3-common dhcp3-client dhcp3-relay isc-dhcp-server-ldap dhcp3-server isc-dhcp-client-udeb isc-dhcp-relay isc-dhcp-server dhcp3-dev isc-dhcp-relay-dbg isc-dhcp-server-dbg isc-dhcp-client-dbg isc-dhcp isc-dhcp-client isc-dhcp-common isc-dhcp-dev tags 592361 + pending -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590186: setting package to dhcp3-common dhcp3-client dhcp3-relay isc-dhcp-server-ldap dhcp3-server isc-dhcp-client-udeb isc-dhcp-relay isc-dhcp-server dhcp3-dev isc-dhcp-relay-dbg isc-dhcp-server-
# Automatically generated email from bts, devscripts version 2.10.35lenny7 # via tagpending # # isc-dhcp (4.1.1-P1-9) UNRELEASED; urgency=high # # * debian/control: really don't make the new packages conflict with the #old/transitional packages (closes: #590186) # package dhcp3-common dhcp3-client dhcp3-relay isc-dhcp-server-ldap dhcp3-server isc-dhcp-client-udeb isc-dhcp-relay isc-dhcp-server dhcp3-dev isc-dhcp-relay-dbg isc-dhcp-server-dbg isc-dhcp-client-dbg isc-dhcp isc-dhcp-client isc-dhcp-common isc-dhcp-dev tags 590186 + pending -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577366: [Pkg-puppet-devel] Bug#577366: Bug#577366: puppet: FTBFS: install: invalid user `puppet'
On Sun, Apr 18, 2010 at 10:10:39PM -0400, micah anderson wrote: On Fri, 16 Apr 2010 14:23:25 +1000, Andrew Pollock apoll...@debian.org wrote: On Sun, Apr 11, 2010 at 10:15:14AM +0200, Lucas Nussbaum wrote: install -Dp -m0644 -o puppet -g puppet ext/rack/files/config.ru \ /build/user-puppet_0.25.4-3-amd64-zxBvTe/puppet-0.25.4/debian/puppetmaster/usr/share/puppet/rack/puppetmasterd install: invalid user `puppet' make: *** [install] Error 1 Looks like this was introduced in commit 93a3ed1e3b70fe394f7ac96c235d527347ad57d2. Micah, the brown paper bag is all yours ;-) Right, however I'm afraid your solution to this issue was not the right one. We actually *do* want the config.ru file owned by the user puppet because passenger will suid to that user. Perhaps a better answer would be to do this in a postinst? I think you'll have to, from my reading of dh_fixperms, and what it's inferring about Debian Policy, which I haven't read. signature.asc Description: Digital signature
Bug#577366: [Pkg-puppet-devel] Bug#577366: puppet: FTBFS: install: invalid user `puppet'
On Sun, Apr 11, 2010 at 10:15:14AM +0200, Lucas Nussbaum wrote: install -Dp -m0644 -o puppet -g puppet ext/rack/files/config.ru \ /build/user-puppet_0.25.4-3-amd64-zxBvTe/puppet-0.25.4/debian/puppetmaster/usr/share/puppet/rack/puppetmasterd install: invalid user `puppet' make: *** [install] Error 1 Looks like this was introduced in commit 93a3ed1e3b70fe394f7ac96c235d527347ad57d2. Micah, the brown paper bag is all yours ;-) signature.asc Description: Digital signature
Bug#555668: elfsign uses MD5
On Sun, Jan 24, 2010 at 12:25:12PM +0100, Stefan Potyra wrote: Hi, here's my 5 minute try of converting elfsign to use sha1. It builds fine, but I must admit that I have no clue how to test it. Maybe it helps nonetheless... Hi Stefan, I'd missed the fact that you'd done this until now. Thanks! It looks anatomically correct, but makes it impossible to check existing signed binaries that have MD5 checksums. It's a good start though, and is definitely better than nothing. I'll have a play with it. regards Andrew signature.asc Description: Digital signature
Bug#555668: marked as forwarded (elfsign uses MD5)
tags 555668 + help thanks On Sat, Jan 23, 2010 at 04:17:19PM +0100, Alexander Reichle-Schmehl wrote: Hi! * Andrew Pollock apoll...@debian.org [091115 16:47] What's the status of elfsign? It doesn't look like you've made a new release in nearly 5 years. Are you planning on addressing the deficiencies of MD5 by releasing a new version with SHA1 support? Any news regarding this bug? Maybe it would be a good idea to remove the package from testing as there is no immediate fix possible. No, I haven't heard anything back. I imagine (although I'm incapable) that it'd be relatively easy to switch to SHA1, given it's using OpenSSL to do the MD5 calculation. The popcon numbers for elfsign are pretty low, so it's probably not worth the effort. If no one comes out of the woodwork with a patch to switch it to generate SHA1 signatures, I'll request its removal altogether. signature.asc Description: Digital signature
Bug#551073: Assessment
Fixed: 0.25.2-1 This looks feasible to backport to 0.24.5 Commit: http://projects.reductivelabs.com/projects/puppet/repository/revisions/e32f980fd7c6291abc2841ede397c962798d9a9c/diff signature.asc Description: Digital signature
Bug#551073: setting package to puppet puppetmaster, tagging 518831, tagging 561231, tagging 551073 ...
# Automatically generated email from bts, devscripts version 2.10.35lenny7
# via tagpending
#
# puppet (0.25.1-3) unstable; urgency=low
#
# * Require modification of /etc/default/puppet to start puppet client daemon.
#(closes: #518831)
# * cherry pick upstream fix for puppetrun with tags (closes: #559092)
# * cherry pick upstream fix for supplementary groups not being reset.
#(CVE-2009-3564) (closes: #551073)
# * debian/{puppet,puppetmaster}.pid: Correct the path to the pidfiles
#(closes: #561231)
# * debian/control: version the build dependency on facter (closes: #551055)
package puppet puppetmaster
tags 518831 + pending
tags 561231 + pending
tags 551073 + pending
tags 551055 + pending
tags 559092 + pending
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551073: setting package to puppet puppetmaster, tagging 561231, tagging 551073, tagging 559092
# Automatically generated email from bts, devscripts version 2.10.35lenny7
# via tagpending
#
# puppet (0.25.1-3) unstable; urgency=low
#
# * cherry pick upstream fix for puppetrun with tags (closes: #559092)
# * cherry pick upstream fix for supplementary groups not being reset.
#(CVE-2009-3564) (closes: #551073)
# * debian/{puppet,puppetmaster}.pid: Correct the path to the pidfiles
#(closes: #561231)
#
package puppet puppetmaster
tags 561231 + pending
tags 551073 + pending
tags 559092 + pending
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549584: NMU
On Sun, Oct 04, 2009 at 05:56:58PM +0200, Giuseppe Iuculano wrote: Hi, Attached is a debdiff of the changes I made for 3.1.2p1-1.1 2-day NMU Thanks. I'm making an upload now. regards Andrew signature.asc Description: Digital signature
Bug#533382: Fails to upgrade when trousers is stopped
Package: trousers Version: 0.3.1-9 Severity: serious Justification: Policy 9.3.2 Hi, When tcsd is not already running, say because of #521245, upgrading to say 0.3.1-9 fails, because the when the trousers prerm tries to stop tcsd, it's already not running. The init script should not return non-zero on failure to stop tcsd. I'll provide a patch in a bit regards Andrew -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages trousers depends on: ii adduser 3.110add and remove users and groups ii libc6 2.7-18 GNU C Library: Shared libraries ii libssl0.9.8 0.9.8g-15+lenny1 SSL shared libraries pn libtspi1none (no description available) trousers recommends no packages. trousers suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528068: setting package to puppet puppetmaster, tagging 530752, tagging 528068, tagging 527381
# Automatically generated email from bts, devscripts version 2.10.35lenny3 # via tagpending # # puppet (0.24.8-2) UNRELEASED; urgency=high # # * Re-ship the vim syntax file in the correct location (it fell out after the #0.24.5-3 upload) (closes: #530752) # * debian/puppet.postrm: don't delete the user or group (closes: #528068, ##527381) # package puppet puppetmaster tags 530752 + pending tags 528068 + pending tags 527381 + pending -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495683: Remove sshguard from testing?
Hi, Given #495683 is months old, and the maintainer hasn't commented on it, and it's never been in a stable release, should it just get removed from testing? regards Andrew signature.asc Description: Digital signature
Bug#427214: dstat - FTBFS: /build/user/dstat-0.6.3/docs/dstat.1.xml does not validate
On Sat, Jun 02, 2007 at 02:49:06PM +0200, Dag Wieers wrote: On Sat, 2 Jun 2007, Michael Ablassmeier wrote: while doing an archive wide package rebuild your package failed to build from source for the following reason: dh_clean -k dh_installdirs # Add here commands to install the package into debian/dstat. /usr/bin/make install DESTDIR=/build/user/dstat-0.6.3/debian/dstat make[1]: Entering directory `/build/user/dstat-0.6.3' install -Dp -m0755 dstat /build/user/dstat-0.6.3/debian/dstat/usr/bin/dstat install -d -m0755 /build/user/dstat-0.6.3/debian/dstat/usr/share/dstat/ install -Dp -m0755 dstat /build/user/dstat-0.6.3/debian/dstat/usr/share/dstat/dstat.py install -Dp -m0755 plugins/dstat_*.py /build/user/dstat-0.6.3/debian/dstat/usr/share/dstat/ /usr/bin/make -C docs install make[2]: Entering directory `/build/user/dstat-0.6.3/docs' asciidoc -b docbook -d manpage dstat.1.txt xmlto man dstat.1.xml xmlto: input does not validate (status 3) /build/user/dstat-0.6.3/docs/dstat.1.xml:407: element listitem: validity error : Element listitem content does not follow the DTD, expecting (calloutlist | glosslist | itemizedlist | orderedlist | segmentedlist | simplelist | variablelist | caution | important | note | tip | warning | literallayout | programlisting | programlistingco | screen | screenco | screenshot | synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara | para | simpara | address | blockquote | graphic | graphicco | mediaobject | mediaobjectco | informalequation | informalexample | informalfigure | informaltable | equation | example | figure | table | msgset | procedure | sidebar | qandaset | anchor | bridgehead | remark | highlights | abstract | authorblurb | epigraph | indexterm | beginpage)+, got () /build/user/dstat-0.6.3/docs/dstat.1.xml:417: element listitem: validity error : Element listitem content does not follow the DTD, expecting (calloutlist | glosslist | itemizedlist | orderedlist | segmentedlist | simplelist | variablelist | caution | important | note | tip | warning | literallayout | programlisting | programlistingco | screen | screenco | screenshot | synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara | para | simpara | address | blockquote | graphic | graphicco | mediaobject | mediaobjectco | informalequation | informalexample | informalfigure | informaltable | equation | example | figure | table | msgset | procedure | sidebar | qandaset | anchor | bridgehead | remark | highlights | abstract | authorblurb | epigraph | indexterm | beginpage)+, got () Document /build/user/dstat-0.6.3/docs/dstat.1.xml does not validate make[2]: *** [dstat.1] Error 3 rm dstat.1.xml make[2]: Leaving directory `/build/user/dstat-0.6.3/docs' make[1]: *** [install] Error 2 make[1]: Leaving directory `/build/user/dstat-0.6.3' make: *** [install] Error 2 The Full Build log is available and can be viewed at: http://people.debian.org/~lucas/logs/2007/06/01/ First of all, dstat 0.6.3 is considered old now. (Debian is behind) Working on that now. Secondly, one does not need to rebuild the docs as I offer the docs already premade. I do not see any benefit for Debian to rebuild the docs because I explicitely DO NOT WANT a dependency on asciidoc or xmlto. Umm, well I'm not doing anything out of my way to build them, from my reading of those build logs. It looks to me like the top-level Makefile is invoking the one in the docs directory, but I've only given it a very preliminary read through at the moment. So I'm interested to learn whether the 0.6.6 release still has the same problem on Debian, but my solution is to not build the docs but use the man-page as it is distributed. I just tried to build that, and had some other build issues relating to the man page. I'll have to fiddle around some more. regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402791: tclxml: Package misses most files
On Thu, Dec 14, 2006 at 10:22:32PM -0200, Fernando Ike de Oliveira wrote: Em Ter, 2006-12-12 às 19:25 +0100, Hermann Schwarting escreveu: The package contains only the files under /usr/share/doc/tclxml and nothing else. Hi. This is critical bug and a greatest failed mine. Please, consider will test new version package and will report if success. - http://www.midstorm.org/~fike/debian/tclxml_3.1-2.diff.gz - http://www.midstorm.org/~fike/debian/tclxml_3.1-2.dsc - http://www.midstorm.org/~fike/debian/tclxml_3.1-2_amd64.changes - http://www.midstorm.org/~fike/debian/tclxml_3.1-2_amd64.deb Fernando, This package looks good. I have sponsored it for you, as this bug is currently blocking #355327 regards Andrew signature.asc Description: Digital signature
Bug#403294: NMU to fix this bug
Hi,
I'm about to upload an NMU that fixes this bug, here's the diff:
diff -u aoetools-11/debian/changelog aoetools-11/debian/changelog
--- aoetools-11/debian/changelog
+++ aoetools-11/debian/changelog
@@ -1,3 +1,11 @@
+aoetools (11-1.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Apply patch from Nelson A. de Oliveira to fix missing dependency on
+lsb-base (closes: #403294)
+
+ -- Andrew Pollock [EMAIL PROTECTED] Sat, 16 Dec 2006 10:37:05 -0800
+
aoetools (11-1.1) unstable; urgency=high
* Non-maintainer upload.
diff -u aoetools-11/debian/control aoetools-11/debian/control
--- aoetools-11/debian/control
+++ aoetools-11/debian/control
@@ -9,7 +9,7 @@
Architecture: any
Section: admin
Priority: optional
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, lsb-base
Description: tools to assist in using ATA over Ethernet
The aoetools are programs that assist in using ATA over Ethernet. This
tools are designed to work with the aoe driver for Linux 2.6 kernels;
signature.asc
Description: Digital signature
Bug#382645: mypasswordsafe: FTBFS with sudo as gain-root command
Khalid, I've made a 0-day NMU of Christian's patch to fix this bug. regards Andrew On Sat, Aug 12, 2006 at 03:51:02PM +0200, Luk Claes wrote: Package: mypasswordsafe Severity: serious Version: 0.0.20050615-1 Hi Your package fails to build from source with sudo as gain-root command as can be seen in the build log on the alpha buildd [1]. Cheers Luk [1] http://buildd.debian.org/fetch.php?pkg=mypasswordsafever=0.0.20050615-1arch=alphastamp=1151848757file=logas=raw -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: Digital signature
Bug#382645: mypasswordsafe: FTBFS with sudo as gain-root command
On Wed, Oct 04, 2006 at 04:34:58AM +0200, Christian Aichinger wrote: On Sat, Aug 12, 2006 at 03:51:02PM +0200, Luk Claes wrote: Your package fails to build from source with sudo as gain-root command as can be seen in the build log on the alpha buildd [1]. The problem is that qmake automatically creates 3 directories during `make clean`. As clean is being called via rootcmd, those dirs are created with owner=root if sudo is used as rootcmd. During package build files should be placed in those directories, which fails as build doesn't run as root. Removing those 3 directories at the end of the debian/rules clean target solves the problem. I have attached the patch (-fix) and an NMU diff (-nmu). Hi Christian, Are you planning on making an NMU to fix this? regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394051: asterisk-app-fax: AGI installed in wrong directory
Package: asterisk-app-fax Version: 0.0.20060218-1 Severity: grave Justification: renders package unusable I was troubleshooting why another AGI script wasn't working, when I discovered that whilst /var/lib/asterisk/agi-bin is where receive_fax is installed, /etc/asterisk/asterisk.conf has astagidir = /usr/share/asterisk/agi-bin in it. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages asterisk-app-fax depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libspandsp1 0.0.2pre26-1 Telephony signal processing librar Versions of packages asterisk-app-fax recommends: ii gs-common 0.3.9 Common files for different Ghostsc pn libconfig-tiny-perl none (no description available) pn libfile-sync-perl none (no description available) ii liblocale-gettext-perl1.05-1 Using libc functions for internati pn libmime-lite-perl none (no description available) ii libpaper1 [libpaperg] 1.1.14-5 Library for handling paper charact ii perl [libstorable-perl] 5.8.8-6.1 Larry Wall's Practical Extraction ii psutils 1.17-21A collection of PostScript documen -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340660: I'm smoking crack
reopen 340660 thanks I'm smoking crack. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229955: Please test version 3.1.19-2
Hello, I've just made a QA upload of xcircuit, which works for me on x86. Can you please test it in powerpc and let me know if this problem still exists? regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325605: dhcp3-server core dumps when receiving a request on sparc64
tags 325605 + moreinfo thanks On Mon, Aug 29, 2005 at 08:27:40PM +0200, Sebastien Bernard wrote: Package: dhcp3-server Version: 3.0.2-3 Severity: grave Justification: renders package unusable dhcp3-server do a sigsegv each time a client send a request for a lease. Recompiling the package with gcc-3.3 fix the problem. core dumps seems to be a miscompilation from gcc-4.0.1. Hello, A similiar issue in dhcp3-client disappeared in version 3.0.3-2, which is now available in unstable. Would you mind testing the same version of the server and let me know if the problem persists? regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297009: Patch doesn't apply cleanly
On Thu, Aug 25, 2005 at 09:53:00AM +0200, Andreas Jochens wrote: Hello, On 05-Aug-25 11:46, Andrew Pollock wrote: [EMAIL PROTECTED]:~/debian/qa/robotour-3.1.1$ patch -p0 --dry-run /tmp/robotour.patch patching file ./libRT/rtcollect.special.h Hunk #1 succeeded at 100 (offset 15 lines). Hunk #2 succeeded at 127 (offset 15 lines). patching file ./libRT/rtcollect.templ.cpp Hunk #1 FAILED at 184. Hunk #2 FAILED at 265. Hunk #3 FAILED at 274. 3 out of 3 hunks FAILED -- saving rejects to file ./libRT/rtcollect.templ.cpp.rej patching file ./libRT/rtmap.h Hunk #1 FAILED at 145. 1 out of 1 hunk FAILED -- saving rejects to file ./libRT/rtmap.h.rej I guess this is because the package uses some CRLFs as line separations (DOS format). I'll defer making the upload at this time to give you some time to refine the patch. The attached new patch should work. No love again: [EMAIL PROTECTED]:~/debian/qa/robotour-3.1.1$ patch -p0 --dry-run /tmp/robotour_unstable.diff patching file ./libRT/rtcollect.special.h Hunk #1 succeeded at 99 with fuzz 1. patching file ./libRT/rtcollect.templ.cpp Hunk #1 FAILED at 199. Hunk #2 FAILED at 280. Hunk #3 FAILED at 289. 3 out of 3 hunks FAILED -- saving rejects to file ./libRT/rtcollect.templ.cpp.rej patching file ./libRT/rtmap.h Hunk #1 FAILED at 159. 1 out of 1 hunk FAILED -- saving rejects to file ./libRT/rtmap.h.rej regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324886: 3.0.3-0 works fine
On Thu, Aug 25, 2005 at 09:31:49AM -0600, Valerio Aimale wrote: Andrew, I've tested the preliminary 3.0.3-0 and it works fine with one-lease-per-client set to on. Leases are obtained correctly and no more infinite loops. Thank you for your help Great. I'll look at making a few cosmetic changes to the maintainer scripts and another build, give the server a spot of testing, and make an upload of 3.0.3 today that closes this bug. regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297009: Patch doesn't apply cleanly
Hi, I was looking to apply this patch as part of a QA upload, however it didn't apply cleanly: [EMAIL PROTECTED]:~/debian/qa/robotour-3.1.1$ patch -p0 --dry-run /tmp/robotour.patch patching file ./libRT/rtcollect.special.h Hunk #1 succeeded at 100 (offset 15 lines). Hunk #2 succeeded at 127 (offset 15 lines). patching file ./libRT/rtcollect.templ.cpp Hunk #1 FAILED at 184. Hunk #2 FAILED at 265. Hunk #3 FAILED at 274. 3 out of 3 hunks FAILED -- saving rejects to file ./libRT/rtcollect.templ.cpp.rej patching file ./libRT/rtmap.h Hunk #1 FAILED at 145. 1 out of 1 hunk FAILED -- saving rejects to file ./libRT/rtmap.h.rej I'll defer making the upload at this time to give you some time to refine the patch. regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324886: dhcp3-server: server goes in infitine loop if one-lease-per-client is set
On Wed, Aug 24, 2005 at 07:26:34PM -0600, Valerio Aimale wrote: andrew, thank you for your reply, I will check 3.0.2 out and will report you my findings. There is a preliminary package of dhcp3-3.0.3 available at http://people.debian.org/~apollock/dhcp3 Please test it (or build it on amd64 and test it) and copy the bug with your findings. regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316729: bashism in the init script
On Sun, Jul 03, 2005 at 02:00:38PM +0200, Marco d'Itri wrote: Package: dhcp3-server Version: 3.0.2-1 Severity: serious Tags: patch This breaks with dash: - if ! /usr/sbin/dhcpd3 -t /dev/null; then + if ! /usr/sbin/dhcpd3 -t 21 /dev/null; then Nice of you to check the open bugs... #225893 is pending an upload once I sort out DEB_BUILD_OPTIONS support. regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#272364: Maybe just remove kernel-patch-redhat
Hi Dan, I see you've recently orphaned kernel-patch-redhat. Maybe you're better off just requesting its removal from the archive, given that it has a release critical bug filed against it, which suggests it's going to be useless in Sarge anyway? Just my $AUD 0.05 worth. regards Andrew -- linux.conf.au 2005 - http://linux.conf.au/ - Birthplace of Tux April 18th to 23rd - http://linux.conf.au/ - LINUX Canberra, Australia - http://linux.conf.au/ -Get bitten! signature.asc Description: Digital signature
Bug#295614: Fails to purge correctly
Package: argus-server Severity: grave On Wed, Feb 16, 2005 at 01:14:31PM -0600, Jason Wohlford wrote: Hi Andrew, I'm having some trouble uninstalling argus-server from Sarge. Here's my aptitude output. Any ideas? Cheers, Jason (Reading database ... 45960 files and directories currently installed.) Removing argus-server ... Purging configuration files for argus-server ... Purging init entries... Purging logfiles .. dpkg: error processing argus-server (--purge): subprocess post-removal script returned error exit status 128 Errors were encountered while processing: argus-server E: Sub-process /usr/bin/dpkg returned an error code (1) Ack! Something bad happened while installing packages. Trying to recover: Press return to continue. Hi Jason, As a temporary workaround, edit /var/lib/dpkg/info/argus-server.postrm and comment out everything from the first case statement to the esac statement (so the script should only have the initial shebang line and the stuff that is automatically added by dh_installdebconf) Then try to purge the package again. I'll upload a new version with a fixed postrm shortly. regards Andrew -- linux.conf.au 2005 - http://linux.conf.au/ - Birthplace of Tux April 18th to 23rd - http://linux.conf.au/ - LINUX Canberra, Australia - http://linux.conf.au/ -Get bitten! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
