Bug#729698: libc0.1: wait6 is broken on 9.2+
The fix for this issue has been committed upstream: http://svnweb.freebsd.org/base?view=revisionrevision=258281 Can this be cherry picked into 9.2 kernel? Should this also be included in the 10 11 kernels, or do those stay in experimental / tracking svn head? I can prepare the debdiffs. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729697: libc0.1: wait6 is broken on 9.2+
Package: libc0.1 Severity: serious Dear Maintainer, FreeBSD 9.2+ kernels have broken implementation of wait6 syscall. In particular: * if pointer to siginfo_t structured is passed * and WEXITED is ORed in options The return value of siginfo_t.si_status is wrong. It is returned the same as status, instead of result of WEXITSTATUS(status). Thus this is an off-by-one error, or more precisely off-by-bitmask error. A PR has been filed in FreeBSD at: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/184002 Affected kernels are 9.2+ all the way to HEAD. I've chatted with developers on #bsddev and they are recognising that this is a severe bug, as current behaviour doesn't comply with freebsd/linux manpages, POSIX, other implmentations of waitid. Furthermore, it appears that other functions that set values of siginfo_t.si_status incorrectly in other parts of FreeBSD kernels. E.g. sigwaitinfo() from stable/8 onwards... The wait6 / waitid() calls are added in the eglibc2.18 debian packaging branch. Therefore I request to do following: * make wait6() a proper wrapper around wait6 syscall and correct si_status. * make waitid implementation use the wait6() wrapper An example patch against current waitid patch, as I don't know how to make proper syscall wrapper functions, is attached. Please advice if Debian kFreeBSD maintainers are willing to patch this issue in the kernels ahead of FreeBSD releasing fixes / updates (at least for the wait6 syscall) Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724089: source-highlight: FTBFS: Tests failed
I believe this is related to boost1.54. I found some vague references to that whilst doing web-search for a patch. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726009: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))
On 11 October 2013 20:32, Steve Langasek vor...@debian.org wrote: severity 726009 serious thanks This remains a serious bug. Your package, which previously built on multiple architectures, is now failing to build due to memory exhaustion. While in some circumstances it is permissible to remove the old binaries and drop support for an architecture, this remains a serious bug until this has been done. (And anyway, your package won't reach testing in the current state, so is de facto unreleasable.) On Fri, Oct 11, 2013 at 09:00:36PM +0200, Anton Gladky wrote: severity 726009 wishlist retitle 726009 Yade requires too much RAM for building thanks thanks for bug-report. The problem is, that all build-failures are due to insufficient RAM on build-machines [1]. I do not really know how to fix that except of backlisting of some machines, as was suggested by Julien [2]. The same package builds fine on Launchpad's PPA. It seems, the package builds only on machines, where 4Gb RAM is available. This diagnosis is incorrect. The error you are hitting here is not that you are exhausting the available memory on the machine, it's that you're exhausting the *address space* on the machine. Adding more memory to the buildd would have zero effect, because you're on a 32-bit system which has a limit of 4GB of address space anyway. (In practice, I believe this is 3GB for userspace and 1GB for kernel on i386.) The buildd almost certainly has swap already, giving it total available memory in excess of 4GB, but that doesn't help if you have a single process - in this case g++ - that needs more than 3GB all to itself. If this same package version built on Launchpad but is failing to build in Debian unstable, then you should look at differences in toolchain versions between the two. It's possible that Ubuntu has a compiler fix that isn't yet available in unstable; it's equally possible that the successful builds in Launchpad were done with an earlier toolchain, and that there's a more recent regression in g++ memory usage. Either way, it's not the buildd's fault. I'm not sure, but launchpad is running 64-bit machines even when compiling for the i386 architecture, and then launchpad supports PAE only and thus can get 4GB of address space. I think debian buildds are also all 64-bit apart from one (or something like that) thus it shouldn't be a problem there. Last time I spoke with Colin about yade FTBFS due to memory exhaustion, the recommendation he gave was to reduce translation units and thus to reduce the compiler memory usage. GCC memory usage can go very large and has regressed since 3.3 when templates are used http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850 It has been done before for some other packages, but i haven't yet had time to look more into yade. I think that's the best way to go for yade, to address it in the source-code / restructure it to use less memory at compile time. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726009: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))
On 11 October 2013 22:34, Ben Hutchings b...@decadent.org.uk wrote: On Fri, Oct 11, 2013 at 09:55:34PM +0100, Dmitrijs Ledkovs wrote: [...] I'm not sure, but launchpad is running 64-bit machines even when compiling for the i386 architecture, and then launchpad supports PAE only and thus can get 4GB of address space. [...] Which bit of 'Physical Address Extension' do you not understand? ignore me, friday evening. the parts where virtual address space is limitted to 4gb per process none the less. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718138: ocaml-estrings
ocaml-estrings has been accepted just now. So a build-dependencies on libestring-ocaml-dev should be all that's needed here. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720744: dh-python: I don't speak Perl, but it stricly doesn't come dancing.
Package: dh-python
Version: 1.20130819-1
Severity: critical
Tags: patch
Dear Maintainer,
In ubuntu the following bug report was filed:
https://bugs.launchpad.net/ubuntu/+source/dh-python/+bug/1214553
dpkg-source --before-build openteacher-3.1
fakeroot debian/rules clean
dh clean --with python2 --buildsystem=pybuild
dh_testdir -O--buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
Can't use string (pybuild --clean ) as an ARRAY ref while strict refs in
use at /usr/share/perl5/Debian/Debhelper/Buildsystem/pybuild.pm line 78.
make: *** [clean] Error 255
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
debuild: fatal error at line 1361:
dpkg-buildpackage -rfakeroot -d -us -uc -S -sa failed
I have no idea if this is right or not, but I applied the following
patch and it seems to be working now:
Description: Hopefully unbreak pybuild by properly pushing array arguments to @result array-ref.
Author: Dmitrijs Ledkovs dmitrij.led...@ubuntu.com
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1214553
--- dh-python-1.20130819.orig/dh/pybuild.pm
+++ dh-python-1.20130819/dh/pybuild.pm
@@ -88,7 +88,7 @@ sub pybuild_commands {
my @result;
if ($ENV{'PYBUILD_INTERPRETERS'}) {
- push @result, pybuild --$step @options;
+ push @result, ['pybuild', --$step, @options];
}
else {
# get interpreter packages from Build-Depends{,-Indep}:
Regards,
Dmitrijs.
Bug#713306: marked as done (netgen: FTBFS: /usr/share/automake-1.13/am/ltlibrary.am: warning: 'libcsg.la': linking libtool libraries using a non-POSIX)
On 22 August 2013 20:43, Boris Pek tehnic...@yandex.ru wrote: control: reopen 713306 Hi Dmitrijs, Unfortunately your patch [1] did not fix build error [2][3]. Yeap, thanks for reopening. I did notice. Will reupload a fix for that in a moment. Regards, Dmitrijs. [1] http://anonscm.debian.org/gitweb/?p=debian-science/packages/netgen.git;a=commitdiff;h=ea5a05f [2] https://buildd.debian.org/status/logs.php?pkg=netgenver=4.9.13.dfsg-6 [3] https://buildd.debian.org/status/fetch.php?pkg=netgenarch=i386ver=4.9.13.dfsg-6stamp=1377127517 Best regards, Boris -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718123: aufs-tools: FTBFS: aufs-util for aufs3.0 and later, but aufs is 3.x-rcN-20130520.
Control: tag -1 patch Patch attached. Regards, Dmitrijs. fix-ftbfs-with-rc-kernel.patch Description: Binary data
Bug#707537: [Pkg-crosswire-devel] Bug#707537: sword: FTBFS: zlib.h:86:5: error: 'z_const' does not name a type
On 4 August 2013 16:20, Rene Engelhard r...@debian.org wrote: tag 707537 + patch thanks [ looking at this bug for the clucene transition which this FTBFS blocks, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718375 ] Hi, On Thu, May 23, 2013 at 12:20:47AM +0100, Dmitrijs Ledkovs wrote: I don't have time to further look into this atm, ie. this week. Patches / nmu / team uploads are welcome, straight into archive with no delays. The patch actually is trivial. Just remove the internal zconf.h. See attached debdiff. Thanks a lot for the patch =) NMU still welcome? I'll upload this in a sec, once I figure out the pending patch for clucene as well. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709422: Depending on binary that is not available on boot (liblzo2.so.2)
Both btrfs and fsck.btrfs are now unconditionally included in the initramfs, and thus should be available on your system to boot mount '/' and '/usr'. Together with the ongoing work to mount and fsck '/' and '/usr' from initramfs, you should have less problems booting going into the future. It is unfortunate that lzo2 is not installed into /lib/, I will request the maintainer of that package to do so, by reassigning the bug there. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709422: Depending on binary that is not available on boot (liblzo2.so.2)
On 29 July 2013 16:55, Klaus Ethgen kl...@ethgen.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, Am Mo den 29. Jul 2013 um 16:00 schrieb Dmitrijs Ledkovs: Both btrfs and fsck.btrfs are now unconditionally included in the initramfs, and thus should be available on your system to boot mount '/' and '/usr'. Together with the ongoing work to mount and fsck '/' and '/usr' from initramfs, you should have less problems booting going into the future. Not really as I use no initrd on all of my systems at all. (Well, on some very few I use it but this an other story.) I see. That's fine. Without or without initrd, I agree this is a valid bug and should be fixed. It is unfortunate that lzo2 is not installed into /lib/, I will request the maintainer of that package to do so, by reassigning the bug there. Well, btrfs-tools was not depending on lzo2 before and now it depends on it. So it is still a bug and still a grave one breaking the debian policy. Sorry to say this. Sure. I'll provide a patch to fix the issue in the liblzo2 package, unless maintainer does it before me. I understand that btrfs is the cause for the bug affecting two package, with a correct fix, IMHO, going into lzo2 package to move library into /lib/. Not sure what is the correct way to express this in BTS. Is the liblzo2 really needed by btrfs fsck? Or could that tool be compiled without the need for this library? To support / check compressed btrfs filesystems, yes. And the general debian policy is to enable all/most options. I wouldn't want to disable lzo2 support, you may wish to either statically link fsck.btrfs or compile without lzo2 if you don't use that feature. https://btrfs.wiki.kernel.org/index.php/Compression Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709499: Is this bug really valid?
Looking at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709499 seems to be a duplicate of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695793 which is now fixed. Or is there something missing? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713794: vtk: FTBFS: make[2]: *** [Wrapping/CMakeFiles/vtkWrapPython.dir/all] Error 2
On 26 June 2013 08:59, Julien Cristau julien.cris...@logilab.fr wrote: On Tue, Jun 25, 2013 at 22:34:11 +0100, Dmitrijs Ledkovs wrote: tag 713794 patch pending thanks Uploaded into delayed/5 queue. Your patch is missing a versioned dependency on python2.7 (and dpkg-dev 1.16.1). It's also terrible that the path isn't detected automatically. I disagree that versioned build-dependency on dpkg-dev is required, and it's wrong for uploads to be rejected on that basis. Also, please explain why a versioned dependency on python2.7 is needed, and whether you mean build-dep or dep. FindPythonLibs.cmake module correctly detects proper python paths and can be hinted which version should be preferred (in case when multiple pythons are available). It's terrible that maintainer/upstream did not choose to use standard cmake interface. I just provided a minimal patch to resolve the issue. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713794: vtk: FTBFS: make[2]: *** [Wrapping/CMakeFiles/vtkWrapPython.dir/all] Error 2
tag 713794 patch pending thanks Uploaded into delayed/5 queue. Regards, Dmitrijs. vtk.deb.diff Description: Binary data
Bug#707488: emacs24: FTBFS: /bin/bash: line 3: cd: /«BUILDDIR»/emacs24-24.3+1/debian/emacs24-el: No such file or directory
tags 707488 pending thanks Uploaded to delayed/5. Regards, Dmitrijs. emacs24.deb.diff Description: Binary data
Bug#707512: emacs23: FTBFS: /bin/bash: line 3: cd: /«BUILDDIR»/emacs23-23.4+1/debian/emacs23-el: No such file or directory
tag 707512 patch pending thanks Uploaded to delayed/5. Regards, Dmitrijs. emacs23.deb.diff Description: Binary data
Bug#712985: cloud-init: Correctly implement Debian Policy 9.11.1 w.r.t integrating alternative init system
Package: cloud-init Severity: serious Tags: patch User: upst...@packages.debian.org Usertags: upstart-job Dear Maintainer, Your package correctly provides upstart job file and sysv init script. To fully comply with Debian Policy 9.11.1 [1] w.r.t. integrating with upstart, the init.d script must also include a safeguard, in case upstart is currently PID 1. I have prepared a patch with that check integrated, please consider to apply it in your package. I have not tested bringing up Debian cloud-init instances with usptart as pid 1, as that's a non-trivial task. diff -Nru cloud-init-0.7.2/debian/changelog cloud-init-0.7.2/debian/changelog --- cloud-init-0.7.2/debian/changelog 2013-05-29 07:21:09.0 +0100 +++ cloud-init-0.7.2/debian/changelog 2013-06-21 14:39:06.0 +0100 @@ -1,3 +1,13 @@ +cloud-init (0.7.2-1.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Comply with debian policy 9.11.1 by checking if init is upstart and +exiting in the init.d script. + * Depend on lsb-base 4.1+Debian3 or higher to use init_is_upstart +function. + + -- Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Fri, 21 Jun 2013 14:37:18 +0100 + cloud-init (0.7.2-1) unstable; urgency=low * New upstream release. diff -Nru cloud-init-0.7.2/debian/cloud-init.init cloud-init-0.7.2/debian/cloud-init.init --- cloud-init-0.7.2/debian/cloud-init.init 2013-05-27 14:58:26.0 +0100 +++ cloud-init-0.7.2/debian/cloud-init.init 2013-06-21 14:37:13.0 +0100 @@ -33,6 +33,17 @@ # and status_of_proc is working. . /lib/lsb/init-functions +if init_is_upstart; then +case $1 in + stop) + exit 0 + ;; + *) + exit 1 + ;; +esac +fi + case $1 in start) log_daemon_msg Starting $DESC $NAME diff -Nru cloud-init-0.7.2/debian/control cloud-init-0.7.2/debian/control --- cloud-init-0.7.2/debian/control 2013-05-29 07:20:59.0 +0100 +++ cloud-init-0.7.2/debian/control 2013-06-21 14:38:41.0 +0100 @@ -26,7 +26,7 @@ Package: cloud-init Architecture: all -Depends: lsb-base, +Depends: lsb-base (= 4.1+Debian3), ifupdown, procps, python, [1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-upstart Regards, Dmitrijs.
Bug#701322: [Debian-med-packaging] Bug#701322: Brief update on this bug (ftbfs with GCC-4.8)
On 6 June 2013 01:02, Charles Plessy ple...@debian.org wrote: Le Wed, Jun 05, 2013 at 09:34:04AM +0900, Charles Plessy a écrit : - there is a patch for building with a recent BOOST in Ubuntu, which looks needed to build on unstable but is not sufficient. - the new stable upstream release need further work on BOOST (maybe something trivial like updating build dependancies), so I did not have time to see if the failure related to GCC is still present there. I also did not have time to try the development version. Thanks Thorsten for upgrading the package. I am puzzled by the build failure in Unstable. Do we miss build-dependancies, or could it be related to the changes in the default parameters for the C linker ? http://wiki.debian.org/ToolChain/DSOLinking#Not_resolving_symbols_in_indirect_dependent_shared_libraries boost-thread, now links/requires against boost-system. And up until recently, the dependencies between boost-thread boost-system packages was missing. I took, 3.4.0.1-3ubuntu1 from ubuntu, and it compiles correctly in sid. I think I'll just upload a fix for this. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701322: [Debian-med-packaging] Bug#701322: Bug#701322: Brief update on this bug (ftbfs with GCC-4.8)
On 6 June 2013 14:17, Charles Plessy ple...@debian.org wrote: Le Thu, Jun 06, 2013 at 09:22:43AM +0100, Dmitrijs Ledkovs a écrit : boost-thread, now links/requires against boost-system. And up until recently, the dependencies between boost-thread boost-system packages was missing. I took, 3.4.0.1-3ubuntu1 from ubuntu, and it compiles correctly in sid. I think I'll just upload a fix for this. Thanks ! Do you think this is something that should be forwarded upstream ? I've committed initial patch to the svn, note the use of dh_autoreconf, thus other patches of Makefile.ins need to patch Makefile.am instead. The changes should be forwarded upstream when ready. At the moment, it builds fine for me on my system, but not in the sbuild/chroot and I am very confused about that =) I guess I can cherrypick patch I did in ubuntu for the 3.4 release, and continue working on fixing svn trunk with the new upstream release in the mean time. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701322: [Debian-med-packaging] Bug#701322: Bug#701322: Brief update on this bug (ftbfs with GCC-4.8)
On 6 June 2013 09:22, Dmitrijs Ledkovs x...@debian.org wrote: On 6 June 2013 01:02, Charles Plessy ple...@debian.org wrote: Le Wed, Jun 05, 2013 at 09:34:04AM +0900, Charles Plessy a écrit : - there is a patch for building with a recent BOOST in Ubuntu, which looks needed to build on unstable but is not sufficient. - the new stable upstream release need further work on BOOST (maybe something trivial like updating build dependancies), so I did not have time to see if the failure related to GCC is still present there. I also did not have time to try the development version. Thanks Thorsten for upgrading the package. I am puzzled by the build failure in Unstable. Do we miss build-dependancies, or could it be related to the changes in the default parameters for the C linker ? http://wiki.debian.org/ToolChain/DSOLinking#Not_resolving_symbols_in_indirect_dependent_shared_libraries All fixed in svn trunk now. Builds correctly with gcc4.8 either current boost or boost1.53. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707537: [Pkg-crosswire-devel] Bug#707537: sword: FTBFS: zlib.h:86:5: error: 'z_const' does not name a type
On 22 May 2013 18:20, Andrey Rahmatullin w...@wrar.name wrote: On Thu, May 09, 2013 at 11:18:45AM +0200, Lucas Nussbaum wrote: /usr/bin/c++ -DCURLAVAILABLE -D_ICU_ -DGLOBCONFPATH=\/etc/sword.conf\ -DUSELUCENE -D_FORTIFY_SOURCE=2 -D_FTPLIB_NO_COMPAT -DSWICU_DATA=\/usr/lib/sword/9_icu_4.8.1.1\ -I/«BUILDDIR»/sword-1.6.2+dfsg/include -I/usr/lib-D_REENTRANT -o CMakeFiles/sword_static.dir/src/mgr/installmgr.cpp.o -c /«BUILDDIR»/sword-1.6.2+dfsg/src/mgr/installmgr.cpp In file included from /«BUILDDIR»/sword-1.6.2+dfsg/include/untgz.h:4:0, from /«BUILDDIR»/sword-1.6.2+dfsg/src/mgr/installmgr.cpp:27: /usr/include/zlib.h:86:5: error: 'z_const' does not name a type /usr/include/zlib.h:94:5: error: 'z_const' does not name a type /usr/include/zlib.h:1025:29: error: 'z_const' has not been declared /usr/include/zlib.h:1025:29: error: two or more data types in declaration of 'parameter' /usr/include/zlib.h:1341:29: error: 'voidpc' has not been declared /usr/include/zlib.h:1349:32: error: expected initializer before 'Z_ARG' /usr/include/zlib.h:1673:5: error: 'z_off64_t' does not name a type /usr/include/zlib.h:1748:15: error: 'z_crc_t' does not name a type /usr/include/zlib.h:1758:44: error: expected initializer before 'Z_ARG' make[4]: *** [CMakeFiles/sword_static.dir/src/mgr/installmgr.cpp.o] Error 1 sword ships include/zconf.h which is apparently loaded instead of the system one and when included into /usr/include/zlib.h it breaks. Hmm care was previously taken to use a system zlib.h, yet the local untgz.h, since untgz.h is not shipped in the zlib package. This could have easily regressed though, since sword's buildsystems (either autofoo or cmake one) are not as robust as one would wish them to be. I don't have time to further look into this atm, ie. this week. Patches / nmu / team uploads are welcome, straight into archive with no delays. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680856: offlineimap: NMU diff for 6.5.4-2.1
On 19 April 2013 09:13, jari jaa...@picasso.cante.net wrote: Dear maintainer, I have some free time and I'm offering help. Here is the NMU diff[1] to fix SERIOUS bug #680856 for the release. If the fix is correct and you have tested it, and can take care of fixing fallout, then no need to NMU it. Just do a normal upload, with normal version number and use something like * Team upload As first entry. I'd encourage all debian developers to upload their offlineimap fixes and sponsor fixes from contributors that way. My mail setup is very simplistic compared with many other DDs = Please let me know if it is ok to proceed with the NMU. Feel free to contact if you have any questions. Just upload away ;-) but yeah, no need to spell out NMU and don't try to migrate it to wheezy =) Thank you for maintaining the package, Jari Aalto [1] http://www.debian.org/doc/developers-reference/pkgs.html#nmu [2] http://dep.debian.net/deps/dep1.html lsdiff(1) of changes: offlineimap-6.5.4/debian/changelog offlineimap-6.5.4/debian/control Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703444: ecere-sdk: Must build-dep on and use libgif-dev instead of included libungif
Package: ecere-sdk Severity: serious Version: 0.44.03-1 libungif has been removed from debian in favour of libgif. ecere-sdk should build-dep on libgif-dev use that instead of the included copy of code. Also it would be preferred for ecere-sdk to not have /deps/ - external copies of code included in the release tarball Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701776: fsck.btrfs do not accept -a so the system will not boot anymore
On 27/02/13 13:05, Axel Beckert wrote: Control: tag -1 + patch Hi, Klaus Ethgen wrote: Package: btrfs-tools Version: 0.19+20130131-1 Severity: important The new fsck.btrfs do not ignore »-a« or handle it propperly as other fsck do. Do this version breaks package initscripts. When a system start, checkfs.sh will check all file systems but the check of btrfs fails as the tool has not the same usage than other. I think the following packaging change caused this issue: * Dropping fsck.patch, not needed anymore. Because this patch added code which made -a being accepted as option: But it shouldn't be needed anymore, now that cmd_check function in cmds-check.c correctly takes 'a' argument and ignores it. Does it exit with a non-zero exit code? or are additional args passed? Or something like that causing boot failure. -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#701776: fsck.btrfs do not accept -a so the system will not boot anymore
On 27 February 2013 13:46, Axel Beckert a...@debian.org wrote: Hi, Dmitrijs Ledkovs wrote: I think the following packaging change caused this issue: * Dropping fsck.patch, not needed anymore. Because this patch added code which made -a being accepted as option: But it shouldn't be needed anymore, now that cmd_check function in cmds-check.c correctly takes 'a' argument and ignores it. Ok, thanks for the information. (I must admit, I haven't checked if the patch still applies.) Does it exit with a non-zero exit code? IIRC yes. Otherwise fsck wouldn't have aborted. or are additional args passed? According to /var/log/fsck/checkroot it's called with fsck -C -a -t btrfs /run/rootdev. See also /etc/init.d/checkfs.sh. Does something like in the attached patch works? Regards, Dmitrijs. fix-up-fsck.patch Description: Binary data
Bug#646704: live-installer: installer doesn't write /etc/crypttab for crypt+LV
I'd like to work on this bug. Do we have recent wheezy rc images which I can use to reproduce fix this bug? -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#697698: broken configury with glibc headers moved to the multiarch location
severity 697698 normal thanks stdint.h is arch independent and is located in /usr/include/stdin.h during native compilation. During cross compilation there is a second copy in the multi arched location. Cross compilation fixes by them self are not RC and are no longer accepted by the release team for wheezy. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697697: ecere-sdk: binary package conflict with eclib
On 9 January 2013 00:01, Jerome St-Louis jerstlo...@gmail.com wrote: Will renaming the package mean renaming the actual library as well for Lintian to be happy? The ecere-dev package also provides /usr/lib/i386-linux-gnu/libec.so Renaming just the package will not be enough as there would still be left file conflict with the other libec. So you'd need to rename package, rename library or use a different path (e.g. /usr/lib/i386-linux-gnu/ec/libec.so or /usr/lib/i386-linux-gnu/ecere/libec.so). (This can be just a Debian patch not upstream) And we can silence lintian's chatter about package name not matching the soname. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697697: ecere-sdk: binary package conflict with eclib
On 8 January 2013 19:11, Ansgar Burchardt ans...@debian.org wrote: Control: severity -1 serious Dmitrijs Ledkovs x...@debian.org writes: ecere-sdk and eclib packages both have binary package libec0. Two packages building the same binary is certainly a RC bug. Both are Library for modular symbols and elliptic curves over Q, but I am not sure if the two packages are the same or different sources, and how to name them. No, eclib's libec0 says that, but the one from ecere-sdk says eC Compiler Library, see [1]. [1] http://packages.debian.org/search?keywords=libec0 Ah, thanks for this link. I must have mixed up the pages I was looking at. The options are: 1) ecere-sdk drops the package build-deps on the eclib one 2) eclib is dropped in favor of ecere-sdk 3) ecere-sdk renames its libec0 to something else 4) eclib renames its libec0 to something else 5) both rename libec0 to something else, and possibly both Provides: libec0 (if compatible) Just from the package description they seem to be completly unrelated libraries. In that case ecere-sdk should probably use a different name for that package. libecec?! since the .so file is already in /usr/lib/.*/ec/libec.so Also, we should decide above in context when/where we want to implement this: wheezy and jessie. BTW Ubuntu already synced both packages, so the clash is more evident there. Both packages are not in testing, so there is nothing to deal with for wheezy. Cool. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695604: libnih: upstart test-suite fails on xfs
Here is the cherry-pick of the fix applied in ubuntu, ready to be
uploaded as NMU.
It's a git-am patch against current master, also pushed as nmu-685604 head.
--
Regards,
Dmitrijs.
From a7b0fd700367bce815169f3475677707714db957 Mon Sep 17 00:00:00 2001
From: Dmitrijs Ledkovs x...@debian.org
Date: Mon, 17 Dec 2012 22:12:57 +
Subject: [PATCH] Fallback to lstat, if dirent.d_type is not available (not
portable)
---
debian/changelog | 9
nih/file.c| 12 +-
nih/tests/test_file.c | 61 +++
3 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index 23f8543..e961c97 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libnih (1.0.3-4.1) raring; urgency=low
+
+ [ Petr Lautrbach plaut...@redhat.com, Dmitrijs Ledkovs ]
+ * NMU
+ * Fallback to lstat, if dirent.d_type is not available (not portable)
+(LP: #672643) (Closes: #695604)
+
+ -- Dmitrijs Ledkovs x...@debian.org Mon, 17 Dec 2012 22:11:27 +
+
libnih (1.0.3-4) unstable; urgency=low
* Rebuild for new libc to update versioned dependency; this comes from
diff --git a/nih/file.c b/nih/file.c
index eda3f7b..e32f949 100644
--- a/nih/file.c
+++ b/nih/file.c
@@ -619,6 +619,8 @@ nih_dir_walk_scan (const char*path,
struct dirent *ent;
char **paths;
size_t npaths;
+ int isdir;
+ struct stat statbuf;
nih_assert (path != NULL);
@@ -640,7 +642,15 @@ nih_dir_walk_scan (const char*path,
subpath = NIH_MUST (nih_sprintf (NULL, %s/%s,
path, ent-d_name));
- if (filter filter (data, subpath, ent-d_type == DT_DIR))
+ if (ent-d_type == DT_UNKNOWN) {
+ if ( lstat (subpath, statbuf))
+isdir = 0;
+ else
+isdir = S_ISDIR(statbuf.st_mode);
+ } else
+ isdir = ent-d_type == DT_DIR;
+
+ if (filter filter (data, subpath, isdir))
continue;
NIH_MUST (nih_str_array_addp (paths, NULL, npaths, subpath));
diff --git a/nih/tests/test_file.c b/nih/tests/test_file.c
index a40eca3..b62dbae 100644
--- a/nih/tests/test_file.c
+++ b/nih/tests/test_file.c
@@ -724,6 +724,25 @@ my_filter (void *data,
return FALSE;
}
+/* find only frodo files */
+static int
+my_filter_frodo_file (void *data,
+ const char *path,
+ int is_dir)
+{
+ char *slash;
+
+ if (is_dir)
+ return FALSE;
+
+ slash = strrchr (path, '/');
+ if (strcmp (slash, /frodo))
+ return TRUE;
+
+ return FALSE;
+}
+
+
static int logger_called = 0;
static int
@@ -905,6 +924,48 @@ test_dir_walk (void)
TEST_EQ_STR (v-path, filename);
nih_free (visited);
+
+/* Try also inverse filter */
+ TEST_ALLOC_SAFE {
+ visitor_called = 0;
+ visited = nih_list_new (NULL);
+ }
+
+ ret = nih_dir_walk (dirname, my_filter_frodo_file,
+my_visitor, NULL, ret);
+
+ TEST_EQ (ret, 0);
+ TEST_EQ (visitor_called, 4);
+
+ v = (Visited *)visited-next;
+ TEST_EQ (v-data, ret);
+ TEST_EQ_STR (v-dirname, dirname);
+ strcpy (filename, dirname);
+ strcat (filename, /bar);
+ TEST_EQ_STR (v-path, filename);
+
+ v = (Visited *)v-entry.next;
+ TEST_EQ (v-data, ret);
+ TEST_EQ_STR (v-dirname, dirname);
+ strcpy (filename, dirname);
+ strcat (filename, /bar/frodo);
+ TEST_EQ_STR (v-path, filename);
+
+ v = (Visited *)v-entry.next;
+ TEST_EQ (v-data, ret);
+ TEST_EQ_STR (v-dirname, dirname);
+ strcpy (filename, dirname);
+ strcat (filename, /baz);
+ TEST_EQ_STR (v-path, filename);
+
+ v = (Visited *)v-entry.next;
+ TEST_EQ (v-data, ret);
+ TEST_EQ_STR (v-dirname, dirname);
+ strcpy (filename, dirname);
+ strcat (filename, /frodo);
+ TEST_EQ_STR (v-path, filename);
+
+ nih_free (visited);
}
--
1.8.0
signature.asc
Description: OpenPGP digital signature
Bug#692327: libotr: Please provide libotr2
Package: libotr, release.debian.org Severity: serious User: release.debian@packages.debian.org Usertags: transition Recently libotr has been updated to version 4.x.x with binary package name libotr5. By the looks of things, it was done because of pidgin-otr package which now requires libotr5. But this means an un-coordinated transition has started, as there are 6 other packages that build-depend on libotr2-dev and all of them fail to build from source against libotr5-dev: * bitlbee * irssi-plugin-otr * kdenetwork * mcabber * psi-plus * python-otr Please do something to resolve this. Input from release team is highly welcome. Possibilities I can think of are: * revert libotr source package to 3.2.1-1 upload libotr5 (4.0.0-2) source package * keep libotr source package as it is, upload libotr2 (3.2.1-1) source package * provide patches/NMUs to fix FTBFS for above packages when built against libotr5-dev. Usually disruptive uploads like this one, should be co-ordinated with the release team with a transition bug, and staged in experimental to do test rebuilds. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651795: [lustre] linux-3.1 is not supported by upstream
As outlined over here [1] have you considered for cherry-picking config patches from [2]. These are patches for configuration. On the related issues there are references to the patches for 3.0+ client support. Can any of them be cherry-picked for Debian? [1] http://jira.whamcloud.com/browse/LU-858?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel#issue-tabs [2] http://review.whamcloud.com/#change,3396 -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#684708: mdadm: support external metadata arrays correctly
On 20/08/12 10:42, Michael Tokarev wrote: On 13.08.2012 14:10, Miquel van Smoorenburg wrote: Package: mdadm Version: 3.2.5-1 Severity: serious Tags: patch wheezy sid The initramfs hook supplied by mdadm doesn't install mdmon. Also, mdmon is not included in the .udeb for the installer. This means that if you have an array with external metadata (ddf or, more widely used, imsm - Intel Matrix Raid) that it will come up readonly. This causes the installer to hang or the system not being able to boot if root is on that array. The attached patch does a couple of things: - it makes sure mdadm is included in the initramfs and the udeb package - it adds a mdadm-waitidle script that runs just before reboot/halt. For all arrays that are still running, it sets safe_mode_delay to a low version, sets sync_action to idle, and waits for the array(s) to go idle. This is needed so that the array is clean, otherwise it will start to resync at the next boot. - it adds 2 lines of code to mdmon.c so that it symlinks its pidfile into /run/sendsigs.omit.d - mdmon should not be killed at shutdown, we still need it after the rootfs has been unmounted. There's one more thing missing in there: mdmon should be re-started from real root after switching from rootfs -- the takeover. I guess it needs to be added to mdadm-raid. Why restarted... surely it just can carry-on as it was. Since e.g. /run doesn't change pre-/post- real-root. BTW, why mdadm-waitidle is a separate script? Can't we fold it into mdadm-raid directly? The more I think about this all, the more it looks like it is too heavily change for wheezy. I understand the situation, but I still think it is not a good idea in general. Oh well. -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684708: mdadm: support external metadata arrays correctly
On 13/08/12 12:43, Michael Tokarev wrote: On 13.08.2012 14:10, Miquel van Smoorenburg wrote: Package: mdadm Version: 3.2.5-1 Severity: serious Tags: patch wheezy sid The initramfs hook supplied by mdadm doesn't install mdmon. Also, mdmon is not included in the .udeb for the installer. This means that if you have an array with external metadata (ddf or, more widely used, imsm - Intel Matrix Raid) that it will come up readonly. This causes the installer to hang or the system not being able to boot if root is on that array. I'm not sure this is the right course of actions -- speaking of the initramfs part, not about the d-i part. Why the system is not being able to boot if root is on such an array? I disagree with Michael, and agree with Miquel. mdmon is needed in the initramfs and I wanted to propose it's inclusion myself as well. Reading mdmon(8) section START UP AND SHUTDOWN, I am convinced that mdmon is required when rootfs is on an external metadata array. Does it make sense to you, Michael? The attached patch does a couple of things: - it makes sure mdadm is included in the initramfs and the udeb package s/mdadm/mdmon/ as mdadm was available already ;-) Sure it is needed in the d-i (udeb), because d-i have to write the system to it. But I'm not convinced it is needed in the initramfs. ok. - it adds a mdadm-waitidle script that runs just before reboot/halt. For all arrays that are still running, it sets safe_mode_delay to a low version, sets sync_action to idle, and waits for the array(s) to go idle. This is needed so that the array is clean, otherwise it will start to resync at the next boot. This is risky - we may never finish shutdown. This is especially risky for things like raid - eg, stalled raid (resync) thread (we've seen these more than once) -- in such cases current code will shut down, but with this wait it wont anymore. Especially useful for remote systems. Such an approach should be tested with extra care, I'm not sure we have resources to do that for wheezy. Generally it is a good idea I think. Agree, sounds risky but doing this right is worth the effort. - it adds 2 lines of code to mdmon.c so that it symlinks its pidfile into /run/sendsigs.omit.d - mdmon should not be killed at shutdown, we still need it after the rootfs has been unmounted. And I'm not sure this is needed, either: it can trivially be done in the initscript. No patching of mdmon is required. We simply need MDMON_DIR configure option to be set to /run/sendsigs.omit.d. -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684708: mdadm: support external metadata arrays correctly
On 13/08/12 16:31, Michael Tokarev wrote: On 13.08.2012 18:20, Dmitrijs Ledkovs wrote: On 13/08/12 12:43, Michael Tokarev wrote: On 13.08.2012 14:10, Miquel van Smoorenburg wrote: Package: mdadm Version: 3.2.5-1 Severity: serious Tags: patch wheezy sid The initramfs hook supplied by mdadm doesn't install mdmon. Also, mdmon is not included in the .udeb for the installer. This means that if you have an array with external metadata (ddf or, more widely used, imsm - Intel Matrix Raid) that it will come up readonly. This causes the installer to hang or the system not being able to boot if root is on that array. I'm not sure this is the right course of actions -- speaking of the initramfs part, not about the d-i part. Why the system is not being able to boot if root is on such an array? I disagree with Michael, and agree with Miquel. mdmon is needed in the initramfs and I wanted to propose it's inclusion myself as well. Reading mdmon(8) section START UP AND SHUTDOWN, I am convinced that mdmon is required when rootfs is on an external metadata array. Does it make sense to you, Michael? Well. Sort of. mdmon utility is supposed to be used in the initramfs, with support of taking over, etc. But this is apparently due to defects in some filesystems (I guess it is ext[34]fs), which performs writes even if asked to do a read-only mount. I still don't see a reason why a _cleanly_ shut down system should have issues booting - I don't know which case Miquel referred to above when saying that a system does not boot. Well... based on the patch, my guess is that because the shutdown does not wait for raid to be synchronised the filesystem ends up being dirty after a clean shut down, hence to reliable boot you should (not must) have mdmon with rootfs on external metadata raid. Can we include mdmon conditionally, if rootfs is on external metadata raid? BTW, is it still the case that ext4 performs writes behind the scenes even if asked for read-only mount? I think I've seen some fixes in this area, but it might be me dreaming. True. Maybe we should ask Ted? =) -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678586: btrfs-tools: broken on 32-bit machines
On 22/06/12 23:35, shawn wrote: Package: btrfs-tools Version: 0.19+20120328-4 Severity: serious Justification: Policy 2.2.1 The patch that I submitted and got applied to the latest version (only) is broken, and may cause so-far-unknown file corruption issues. See Bug #656955 for original buggy patch, and corrected patch. Need to make sure the buggy version (0.19+20120328-4) never gets into testing. Great. -4 did get auto-synced into Ubuntu. I will upload your patch there at least. But why did you open this new bug instead of: * reopen 656955 * raise severity to make 656955 RC ? If there is no response from Maintainer, I intent to upload NMU with fixed patch. Regards, Dmitrijs. -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676633: python-numpy dependency
On 20/06/12 09:07, Jakub Wilk wrote:
* Dmitrijs Ledkovs x...@debian.org, 2012-06-20, 03:54:
Since this is python compiled extension, shouldn't we actually use
dh_numpy thing to get the correct ABI dependency?
Yes, you should:
$ lintian python-opencv_2.3.1-10_i386.deb | grep numpy
E: python-opencv: missing-dependency-on-numpy-abi
Let's close our eyes for now, on how it's currently done in experimental.
*cough*
debian/control:
Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends},
python-numpy-abi9, python-numpy (= 1:1.6.1)
Can't find an svn branch for stable. I guess trunk is in use to upload
to both?
--
Regards,
Dmitrijs.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676633: python-numpy dependency
Hello, Since this is python compiled extension, shouldn't we actually use dh_numpy thing to get the correct ABI dependency? -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667417: [Debian-med-packaging] Bug#667417: wrapitk-python: ftbfs with GCC-4.7
On 17/06/12 17:42, Ilya Barygin wrote: tags 667417 patch thanks Hello, #675181 is fixed, but wrapitk-python still FTBFS with gcc 4.7, now because of a problem in insighttoolkit headers. Here's the patch. wrapitk-python gets it's sourcecode from the insighttoolkit. I have attempted to apply your patch to both experimental and unstable of inisghttolkit, and it fails with fuzzy matching / reverse applied patch. Which source package and which version of said source package was this patch generated against? -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676097: [Pkg-crosswire-devel] Bug#676097: Bug#676097: sword: FTBFS: CMakeFiles/buildtest.dir/buildtest.cpp.o: could not read symbols: Bad value
On 06/06/12 10:35, Daniel Glassey wrote: tags 676097 pending thanks On Tue, Jun 5, 2012 at 5:18 AM, Lucas Nussbaum lu...@lucas-nussbaum.net wrote: Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: /usr/bin/ld: CMakeFiles/buildtest.dir/buildtest.cpp.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/buildtest.dir/buildtest.cpp.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status I'm not set up to deal with bzr and stuff at the mo to do the build but the fix that is needed is to modify configure.ac to only get the libs to link from icu-config You can simply do an NMU, bzr is optional. But what does configure.ac got to do with anything if the package uses CMake to build =) i.e. ICU_LIBS=`$ICU_CONFIG --ldflags-libsonly` Thanks for the heads-up. The icu package has been fixed to not leak the pie flags so it should build ok with the current libicu-dev in sid, but this change is still useful. ok. Funnily enough, this helped spot the same problem in grcompiler. = -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#671271: folder '.' could not be created / 'Empty mailbox name'
Dear Stefano,
*** Processing account Upsilon
Establishing connection to upsilon.censor:993
Creating folder .[UpsilonImaps]
ERROR: Creating folder on repository UpsilonImaps
Folder '.'[UpsilonImaps] could not be created. Server responded: ('NO',
['Empty mailbox name.'])
ERROR: Folder '.'[UpsilonImaps] could not be created. Server responded:
('NO',
['Empty mailbox name.'])
*** Finished account 'Upsilon' in 0:02
The newly uploaded 6.5.4 has a new option, which may be applicable in
your case. From the docs:
createfolders
-
By default OfflineImap propagates new folders in both
directions. Sometimes this is not what you want. E.g. you might want
new folders on your IMAP server to propagate to your local MailDir,
but not the other way around. The 'readonly' setting on a repository
will not help here, as it prevents any change from occuring on that
repository. This is what the `createfolders` setting is for. By
default it is `True`, meaning that new folders can be created on this
repository. To prevent folders from ever being created on a
repository, set this to `False`. If you set this to False on the
REMOTE repository, you will not have to create the `Reverse
nametrans`_ rules on the LOCAL repository.
From above error message, I recommend you try adding disabling
createfolders on the remote UpsilonImaps repository like so:
[Repository UpsilonImaps]
createfolders = False
Please let me know if this fixes it for you.
--
Regards,
Dmitrijs.
signature.asc
Description: OpenPGP digital signature
Bug#674391: autofs: diff for NMU version 5.0.6-1.1
Hi Dmitrij, First of all thank you for picking up the maintenance of this package. It is non-trivial. On 01/06/12 01:57, Dmitry Smirnov wrote: Hi Dmitrijs, I'd like to thank you for your care for the 'autofs' package but please excuse me for expressing my non-appreciation of your NMU. I have cancelled it due to bug that Jakub Wilk expressed. Although perhaps not fast enough we're working on 'autofs' - we have a team of three and a different fix to the problem is already committed to repository. The changelog entry says: * declare myself as Maintainer (adopting package) And the control says, that there is one maintainer one uploader. Please, either change the maintainer to a team, or list all people on the team. Please, set Vcs-* fields as per: http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-vcs If the fix has been committed to Vcs-*, you should set the 'pending' tag on the bug. Correct Vcs-* headers, together with the pending tag would allowed me to find the patches I was looking for. I do believe the pressure you impose with your NMU is unnecessary because simply asking or sharing your suggestions in email to any of us would be better. True. I'm sorry for putting you in the spotlight. We are days away from the freeze, the package has RC bugs and did not transition to testing yet. I do not want to release wheezy without autofs. There is pressure from the release team. Friendly discussion is always preferable to aggressive pushing of your implementation over the shoulders of active maintainers who at least trying to discuss changes between themselves. From the changelog, I understood that there was only one maintainer who did ample of work to update the package. RC http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673796 has no response from maintainer. Do you have a patch committed to some private Vcs repository? RC http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674391 has no response from maintainer. And you say you do have a patch ready. Who sponsored your upload? Because bug #674391 is Fail To Build From Source (in a sane manner) filed the day after the upload. Autoconf was last updated on 2012-05-12. Did the package FTBFS (in a sane manner) on the upload? Also I'm sure you're aware that I'm not a DD, so to override your NMU I must complete changes for new release and find a sponsor within 5 days only. I am aware that you are not a DD. To cancel an NMU you only need to get any DD to 'sponsor' this one line: dcut ftp-eu cancel autofs_5.0.6-1.1_amd64.changes Nobody is forcing you to complete changes for a new release in an unreasonable quick amount of time. I am sure anyone from #debian-mentors would have done it, if it was not already done by me. Do you have a DD in your team of three people to review and sponsor packages? You're welcome to the team if you want to help but please consider first to communicate whatever improvements you might have and then perhaps sponsor the existing effort rather than override it with premature NMU. Yes, I do want to be part of the team. Do you have a team setup on alioth with a Vcs repository and mailing list? Or do you want help to set this up? Improvements I want to achieve: This package to migrate to testing. This means: * fix FTBFS in a sane way * fix FTBFS with gold / ld --as-needed * fix conf file upgrade handling Meanwhile I'll do my best to address the problem ASAP. Great. * Please comment on the bugs that are being worked on. * Please attach the patch to the BTS or point to VCS where this patch is available. * Please tag pending, if a solution for the bug is found and it will be part of the next upload. Above action, would have prevented spending me time doing duplicate work in a different time zone. Thank you. Thank you for you contributions to debian. I hope you will keep up the excellent work you are doing with this package. But please do fix the issues with the package I have outlined above. -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#674391: NMU cancelled
tags 671391 -pending thanks NMU has been cancelled last night. Sorry, for any inconvenience caused. -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#674391: autofs: diff for NMU version 5.0.6-1.1
tags 674391 + patch
tags 674391 + pending
thanks
Dear maintainer,
I've prepared an NMU for autofs (versioned as 5.0.6-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru autofs-5.0.6/debian/changelog autofs-5.0.6/debian/changelog
--- autofs-5.0.6/debian/changelog 2012-04-25 08:20:20.0 +0100
+++ autofs-5.0.6/debian/changelog 2012-05-31 13:56:56.0 +0100
@@ -1,3 +1,14 @@
+autofs (5.0.6-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/patches/18ftbfs_autoreconf.patch: Fix FTBFS due to autoconf run
+at clean target. (Closes: #674391)
+ * debian/rules, debian/control: Run autoconf and autotools with dh
+helper instead.
+ * debian/patches/17ld.patch: FTBFS with gold / ld --no-add-needed
+
+ -- Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Thu, 31 May 2012 13:51:39
+0100
+
autofs (5.0.6-1) unstable; urgency=low
* New upstream release
diff -Nru autofs-5.0.6/debian/control autofs-5.0.6/debian/control
--- autofs-5.0.6/debian/control 2012-04-25 05:38:18.0 +0100
+++ autofs-5.0.6/debian/control 2012-05-31 13:55:14.0 +0100
@@ -4,7 +4,7 @@
Maintainer: Dmitry Smirnov only...@member.fsf.org
Uploaders: Jan Christoph Nordholz he...@pool.math.tu-berlin.de
Standards-Version: 3.9.3
-Build-Depends: debhelper (= 9), autoconf, lsb-base,
+Build-Depends: debhelper (= 9), autotools-dev, dh-autoreconf, lsb-base,
bison, flex, libhesiod-dev, libkrb5-dev, libldap-dev, libsasl2-dev,
libssl-dev, libxml2-dev
Homepage: http://www.kernel.org/pub/linux/daemons/autofs/v5/
diff -Nru autofs-5.0.6/debian/patches/17ld.patch
autofs-5.0.6/debian/patches/17ld.patch
--- autofs-5.0.6/debian/patches/17ld.patch 1970-01-01 01:00:00.0
+0100
+++ autofs-5.0.6/debian/patches/17ld.patch 2012-05-31 13:57:26.0
+0100
@@ -0,0 +1,68 @@
+Description: FTBFS with gold / ld --no-add-needed
+
+diff -Naurp autofs5-5.0.6.orig//aclocal.m4 autofs5-5.0.6//aclocal.m4
+--- autofs5-5.0.6.orig//aclocal.m4 2011-06-28 03:34:35.0 -0400
autofs5-5.0.6//aclocal.m4 2011-07-03 21:44:22.090944882 -0400
+@@ -241,9 +241,9 @@ dnl
+ AC_DEFUN([AF_CHECK_LIBHESIOD],
+ [AC_MSG_CHECKING(for libhesiod)
+
+-# save current ldflags
+-af_check_hesiod_save_ldflags=$LDFLAGS
+-LDFLAGS=$LDFLAGS -lhesiod -lresolv
++# save current libs
++af_check_hesiod_save_libs=$LIBS
++LIBS=$LIBS -lhesiod -lresolv
+
+ AC_TRY_LINK(
+ [ #include hesiod.h ],
+@@ -253,8 +253,8 @@ AC_TRY_LINK(
+ AC_MSG_RESULT(yes) ],
+ [ AC_MSG_RESULT(no) ])
+
+-# restore ldflags
+-LDFLAGS=$af_check_hesiod_save_ldflags
++# restore libs
++LIBS=$af_check_hesiod_save_ldflags
+ ])
+
+ dnl --
+diff -Naurp autofs5-5.0.6.orig//configure autofs5-5.0.6//configure
+--- autofs5-5.0.6.orig//configure 2011-06-28 03:34:35.0 -0400
autofs5-5.0.6//configure 2011-07-03 21:44:22.100944883 -0400
+@@ -4030,9 +4030,9 @@ then
+ { $as_echo $as_me:${as_lineno-$LINENO}: checking for libhesiod 5
+ $as_echo_n checking for libhesiod... 6; }
+
+-# save current ldflags
+-af_check_hesiod_save_ldflags=$LDFLAGS
+-LDFLAGS=$LDFLAGS -lhesiod -lresolv
++# save current libs
++af_check_hesiod_save_ldflags=$LIBS
++LIBS=$LIBS -lhesiod -lresolv
+
+ cat confdefs.h - _ACEOF conftest.$ac_ext
+ /* end confdefs.h. */
+@@ -4057,8 +4057,8 @@ fi
+ rm -f core conftest.err conftest.$ac_objext \
+ conftest$ac_exeext conftest.$ac_ext
+
+-# restore ldflags
+-LDFLAGS=$af_check_hesiod_save_ldflags
++# restore libs
++LIBS=$af_check_hesiod_save_ldflags
+
+ if test $HAVE_HESIOD == 1; then
+
+diff -Naurp autofs5-5.0.6.orig//daemon/Makefile autofs5-5.0.6//daemon/Makefile
+--- autofs5-5.0.6.orig//daemon/Makefile2011-06-28 03:34:35.0
-0400
autofs5-5.0.6//daemon/Makefile 2011-07-03 21:44:22.100944883 -0400
+@@ -20,7 +20,7 @@ CFLAGS += -DAUTOFS_FIFO_DIR=\$(autofsfi
+ CFLAGS += -DAUTOFS_FLAG_DIR=\$(autofsflagdir)\
+ CFLAGS += -DVERSION_STRING=\$(version)\
+ LDFLAGS += -rdynamic
+-LIBS = -ldl
++LIBS = -ldl -lpthread
+
+ ifeq ($(LDAP), 1)
+ CFLAGS += $(XML_FLAGS)
diff -Nru autofs-5.0.6/debian/patches/18ftbfs_autoreconf.patch
autofs-5.0.6/debian/patches/18ftbfs_autoreconf.patch
--- autofs-5.0.6/debian/patches/18ftbfs_autoreconf.patch1970-01-01
01:00:00.0 +0100
+++ autofs-5.0.6/debian/patches/18ftbfs_autoreconf.patch2012-05-31
13:33:30.0 +0100
@@ -0,0 +1,30 @@
+Description: Fix FTBFS. Remove unconditional autoreconf in clean target.
+Author: Dmitrijs Ledkovs dmitrijs.ledk...@canonical.com
+Bug-Debian: http://bugs.debian.org/674391
+Last-Update: 2012-05-31
+
+=== modified file 'Makefile'
+--- old/Makefile 2008-04-28 15:55:37 +
new/Makefile 2012-05-31 12:32:27 +
+@@ -38,8 +38,6 @@
+ echo x .autofs-`cat .version`
+ sed -e s/(\.autofs-[0-9.]\+)/(.autofs-`cat
Bug#615696: barada-pam: diff for NMU version 0.5-3.1
tags 615696 + pending
thanks
Dear maintainer,
I've prepared an NMU for barada-pam (versioned as 0.5-3.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru barada-pam-0.5/debian/changelog barada-pam-0.5/debian/changelog
--- barada-pam-0.5/debian/changelog 2012-02-13 07:22:44.0 +
+++ barada-pam-0.5/debian/changelog 2012-05-31 18:55:25.0 +0100
@@ -1,3 +1,11 @@
+barada-pam (0.5-3.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Update patch to really fix FTBFS with gold or ld --no-add-needed
+(Closes: #615696)
+
+ -- Dmitrijs Ledkovs x...@debian.org Thu, 31 May 2012 18:54:17 +0100
+
barada-pam (0.5-3) unstable; urgency=low
* debian/rules: add build-{arch,indep} targets
diff -Nru barada-pam-0.5/debian/patches/fix_615696
barada-pam-0.5/debian/patches/fix_615696
--- barada-pam-0.5/debian/patches/fix_6156962011-05-26 05:53:11.0
+0100
+++ barada-pam-0.5/debian/patches/fix_6156962012-05-31 18:53:37.0
+0100
@@ -1,32 +1,40 @@
a/Makefile.am
-+++ b/Makefile.am
-@@ -8,7 +8,7 @@
+Description: explicitly link with boost_system and boost_filesystem
+ to fix a FTBFS
+Author: Andreas Moog am...@ubuntu.com, Dmitrijs Ledkovs
dmitrij.led...@ubuntu.com
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/765927
+Bug-Debian: http://bugs.debian.org/615696
+
+Index: barada-pam/Makefile.am
+===
+--- barada-pam.orig/Makefile.am2011-05-28 17:05:27.364231843 +0200
barada-pam/Makefile.am 2011-05-28 17:05:05.345349346 +0200
+@@ -10,6 +10,8 @@
- barada_add_SOURCES = barada-add.cpp HOTPCredentials.cpp Util.cpp
-
--barada_add_LDFLAGS = $(BOOST_FILESYSTEM)
-+barada_add_LDFLAGS = $(BOOST_FILESYSTEM) -lboost_system
+ barada_add_LDFLAGS = $(BOOST_FILESYSTEM)
++LIBS += $(BOOST_FILESYSTEM) -lboost_system
++
pam_barada_sodir = /lib/security/
-@@ -16,6 +16,6 @@
-
- pam_barada_so_SOURCES = HOTP.cpp HOTPCredentials.cpp HOTPWindow.cpp
pam_barada.cpp Util.cpp
+ pam_barada_so_PROGRAMS = pam_barada.so
+@@ -18,4 +20,4 @@
--pam_barada_so_LDFLAGS = -shared
-+pam_barada_so_LDFLAGS = -shared -lboost_system
+ pam_barada_so_LDFLAGS = -shared
-HexTest_SOURCES = HexTest.cpp Util.cpp
\ No newline at end of file
+HexTest_SOURCES = HexTest.cpp Util.cpp
a/Makefile.in
-+++ b/Makefile.in
-@@ -125,7 +125,7 @@
- INSTALL_PROGRAM = @INSTALL_PROGRAM@
- INSTALL_SCRIPT = @INSTALL_SCRIPT@
+Index: barada-pam/Makefile.in
+===
+--- barada-pam.orig/Makefile.in2011-05-28 17:05:27.434228322 +0200
barada-pam/Makefile.in 2011-05-28 17:05:24.674367340 +0200
+@@ -127,7 +127,7 @@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
--LDFLAGS = @LDFLAGS@
-+LDFLAGS = @LDFLAGS@ -lboost_system
+ LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
- LIBS = @LIBS@
+-LIBS = @LIBS@
++LIBS = @LIBS@ $(BOOST_FILESYSTEM) -lboost_system
LTLIBOBJS = @LTLIBOBJS@
+ MAKEINFO = @MAKEINFO@
+ MKDIR_P = @MKDIR_P@
+
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/debian-bugs-rc
Bug#674391: autofs: diff for NMU version 5.0.6-1.1
On 31/05/12 23:34, Jakub Wilk wrote: * Dmitrijs Ledkovs dmitrij.led...@ubuntu.com, 2012-05-31, 16:12: -dh $@ +dh $@ --with autotools-dev,autoreconf dh_autoreconf is a superset of the autotools-dev debhelper addons, so you do not need --with=autotools_dev if you use --with=autoreconf. In fact, in most cases they should not be used together, as it may lead to unpredictable behaviour. (from dh-autoreconf(7) manpage) I was not aware of this detail. My, wrong, understanding was that autootols-dev only replaced config.sub and config.guess, while autoreconf did autoconf, aclocal and etc. I did not know that autoreconf replaces config.sub/config.guess. I had a doubt when adding this (do I need both?!), but didn't check as I was not expecting it to cause harm. Should there be a lintian guard? Or warning? I will dcut and reupload. Again, thank you for noticing this. -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#615696: Fwd: Reopening Bug #615696 barada-pam: ftbfs with gold or ld --no-add-needed
The patch that was proposed to fix #615696 [1] turned out to be insufficient, as can be seen in LP 765927 [2]. I noticed this, as it is holding out ubuntu's boost1.49 transition. [3] Ideally both boost libraries should be part of the LIBS variable substituted by configure, as any combinations of automake's magic variables did not produce something that does not FTBFS. Therefore, I just append the two libraries to the LIBS variable in Makefile.am. I hope that this new patch (take 3?!) is cleaner than what is currently in ubuntu and that it will be of use to you. Please, replace the current fix_615696 patch with a new version attached. If you upload, it will get packages in sync in ubuntu once again and help with the boost transition. I have tested this patch in clean sid quantal pbuilder. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615696 [2] https://bugs.launchpad.net/bugs/765927 [3] http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html -- Regards, Dmitrijs. Description: explicitly link with boost_system and boost_filesystem to fix a FTBFS Author: Andreas Moog am...@ubuntu.com, Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Bug-Ubuntu: https://bugs.launchpad.net/bugs/765927 Bug-Debian: http://bugs.debian.org/615696 Index: barada-pam/Makefile.am === --- barada-pam.orig/Makefile.am 2011-05-28 17:05:27.364231843 +0200 +++ barada-pam/Makefile.am 2011-05-28 17:05:05.345349346 +0200 @@ -10,6 +10,8 @@ barada_add_LDFLAGS = $(BOOST_FILESYSTEM) +LIBS += $(BOOST_FILESYSTEM) -lboost_system + pam_barada_sodir = /lib/security/ pam_barada_so_PROGRAMS = pam_barada.so @@ -18,4 +20,4 @@ pam_barada_so_LDFLAGS = -shared -HexTest_SOURCES = HexTest.cpp Util.cpp \ No newline at end of file +HexTest_SOURCES = HexTest.cpp Util.cpp Index: barada-pam/Makefile.in === --- barada-pam.orig/Makefile.in 2011-05-28 17:05:27.434228322 +0200 +++ barada-pam/Makefile.in 2011-05-28 17:05:24.674367340 +0200 @@ -127,7 +127,7 @@ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ LDFLAGS = @LDFLAGS@ LIBOBJS = @LIBOBJS@ -LIBS = @LIBS@ +LIBS = @LIBS@ $(BOOST_FILESYSTEM) -lboost_system LTLIBOBJS = @LTLIBOBJS@ MAKEINFO = @MAKEINFO@ MKDIR_P = @MKDIR_P@
Bug#674541: ruby1.8.7 workaround
forwarded 674541 https://bugs.ruby-lang.org/issues/6383 thanks The comment on the upstream bug has this workaround: Try to build Ruby 1.8.7 with the following config options: ./configure CFLAGS=-O2 -fno-tree-dce -fno-optimize-sibling-calls Don't ask me why. I just found it by trial and error. -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673766: sudo: CVE-2012-2337: diff for NMU version 1.8.3p2-1.1
tags 673766 + patch
tags 673766 + pending
user ubuntu-de...@lists.ubuntu.com
usertag 673766 + ubuntu-patch
thanks
Dear maintainer,
I've prepared an NMU for sudo (versioned as 1.8.3p2-1.1).
Please consider uploading this Security fix.
Regards.
diff -Nru sudo-1.8.3p2/debian/changelog sudo-1.8.3p2/debian/changelog
--- sudo-1.8.3p2/debian/changelog 2012-01-30 16:11:54.0 +
+++ sudo-1.8.3p2/debian/changelog 2012-05-22 12:26:47.0 +0100
@@ -1,3 +1,14 @@
+sudo (1.8.3p2-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * SECURITY UPDATE: Properly handle netmasks in sudoers Host and Host_List
+values (LP: #1000276, Closes: #673766)
+- debian/patches/CVE-2012-2337.patch: Don't perform IPv6 checks on IPv4
+ addresses. Based on upstream patch.
+- CVE-2012-2337
+
+ -- Dmitrijs Ledkovs dmitrijs.ledk...@canonical.com Tue, 22 May 2012
12:23:00 +0100
+
sudo (1.8.3p2-1) unstable; urgency=high
* new upstream version, closes: #657985 (CVE-2012-0809)
diff -Nru sudo-1.8.3p2/debian/patches/CVE-2012-2337.patch
sudo-1.8.3p2/debian/patches/CVE-2012-2337.patch
--- sudo-1.8.3p2/debian/patches/CVE-2012-2337.patch 1970-01-01
01:00:00.0 +0100
+++ sudo-1.8.3p2/debian/patches/CVE-2012-2337.patch 2012-05-22
12:21:08.0 +0100
@@ -0,0 +1,47 @@
+Description: Prevent IPv6 netmask-based address matching logic from incorrectly
+ being applied to IPv4 addresses.
+Author: Todd C. Miller todd.mil...@courtesan.com
+Origin: upstream, http://www.sudo.ws/repos/sudo/rev/672a4793931a
+
+Index: sudo-1.8.3p1/plugins/sudoers/match_addr.c
+===
+--- sudo-1.8.3p1.orig/plugins/sudoers/match_addr.c 2011-10-21
08:01:25.0 -0500
sudo-1.8.3p1/plugins/sudoers/match_addr.c 2012-05-16 09:45:03.289738323
-0500
+@@ -73,7 +73,7 @@
+ for (ifp = interfaces; ifp != NULL; ifp = ifp-next) {
+ if (ifp-family != family)
+ continue;
+- switch(family) {
++ switch (family) {
+ case AF_INET:
+ if (ifp-addr.ip4.s_addr == addr.ip4.s_addr ||
+ (ifp-addr.ip4.s_addr ifp-netmask.ip4.s_addr)
+@@ -91,6 +91,7 @@
+ }
+ if (j == sizeof(addr.ip6.s6_addr))
+ return TRUE;
++ break;
+ #endif
+ }
+ }
+@@ -154,10 +155,11 @@
+ for (ifp = interfaces; ifp != NULL; ifp = ifp-next) {
+ if (ifp-family != family)
+ continue;
+- switch(family) {
++ switch (family) {
+ case AF_INET:
+ if ((ifp-addr.ip4.s_addr mask.ip4.s_addr) == addr.ip4.s_addr)
+ return TRUE;
++ break;
+ #ifdef HAVE_IN6_ADDR
+ case AF_INET6:
+ for (j = 0; j sizeof(addr.ip6.s6_addr); j++) {
+@@ -166,6 +168,7 @@
+ }
+ if (j == sizeof(addr.ip6.s6_addr))
+ return TRUE;
++ break;
+ #endif /* HAVE_IN6_ADDR */
+ }
+ }
diff -Nru sudo-1.8.3p2/debian/patches/series sudo-1.8.3p2/debian/patches/series
--- sudo-1.8.3p2/debian/patches/series 2011-10-23 00:49:16.0 +0100
+++ sudo-1.8.3p2/debian/patches/series 2012-05-22 12:22:07.0 +0100
@@ -1,2 +1,3 @@
typo-in-classic-insults.diff
paths-in-samples.diff
+CVE-2012-2337.patch
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/debian-bugs-rc
Bug#673283: btrfs-tools: FTBFS: dh_builddeb unknown compression strategy
Package: btrfs-tools Severity: serious Version: 0.19+20120328-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu quantal During rebuild of your package in a recent clean sid pbuilder, it has failed to build from source. I believe this is due to dh_builddeb switching to xz compression by default (for udebs). I have a debdiff to resolve this problem (removing override_dh_builddeb). If there is a good reason for using gzip compression instead of the default, let me know. debian/rules override_dh_builddeb make[1]: Entering directory `/tmp/buildd/btrfs-tools-0.19+20120328' dh_builddeb -- -Zgzip -z9 dpkg-deb: building package `btrfs-tools' in `../btrfs-tools_0.19+20120328-1_amd64.deb'. dpkg-deb: building package `btrfs-tools-dbg' in `../btrfs-tools-dbg_0.19+20120328-1_amd64.deb'. dpkg-deb: error: invalid compressor parameters: unknown compression strategy Type dpkg-deb --help for help about manipulating *.deb files; Type dpkg --help for help about installing and deinstalling packages. dh_builddeb: dpkg-deb -z1 -Zxz -Sextreme -Zgzip -z9 --build debian/btrfs-tools-udeb ../btrfs-tools-udeb_0.19+20120328-1_amd64.udeb returned exit code 2 make[1]: *** [override_dh_builddeb] Error 1 make[1]: Leaving directory `/tmp/buildd/btrfs-tools-0.19+20120328' make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 E: Failed autobuilding of package -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673283: btrfs-tools: diff for NMU version 0.19+20120328-1.1
user ubuntu-de...@lists.ubuntu.com usertag 673283 + ubuntu-patch tags 673283 + patch thanks Dear maintainer, I've prepared an NMU for btrfs-tools (versioned as 0.19+20120328-1.1) and I'm intending to upload it into DELAYED/10. Please tell me if I shouldn't. Regards, Dmitrijs. diff -Nru btrfs-tools-0.19+20120328/debian/changelog btrfs-tools-0.19+20120328/debian/changelog --- btrfs-tools-0.19+20120328/debian/changelog 2012-04-16 10:19:46.0 +0100 +++ btrfs-tools-0.19+20120328/debian/changelog 2012-05-17 14:55:32.0 +0100 @@ -1,3 +1,11 @@ +btrfs-tools (0.19+20120328-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix FTBFS, due to unknown compression format, as xz is now the default +(Closes: #673283). + + -- Dmitrijs Ledkovs dmitrijs.ledk...@canonical.com Thu, 17 May 2012 13:44:50 +0100 + btrfs-tools (0.19+20120328-1) unstable; urgency=low * Including ioctl.h in btrfs-tools (Closes: #658471). diff -Nru btrfs-tools-0.19+20120328/debian/rules btrfs-tools-0.19+20120328/debian/rules --- btrfs-tools-0.19+20120328/debian/rules 2012-04-16 10:17:46.0 +0100 +++ btrfs-tools-0.19+20120328/debian/rules 2012-05-17 13:44:35.0 +0100 @@ -30,9 +30,6 @@ install -D -m 0755 debian/local/btrfs.hook debian/btrfs-tools/usr/share/initramfs-tools/hooks/btrfs install -D -m 0755 debian/local/btrfs.local-premount debian/btrfs-tools/usr/share/initramfs-tools/scripts/local-premount/btrfs -override_dh_builddeb: - dh_builddeb -- -Zgzip -z9 - override_dh_install: dh_install -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-bugs-rc
Bug#615520: Fwd: Bug#579105: fixed in turbogears 1.1.3-1
Source: turbogears Source-Version: 1.1.3-1 We believe that the bug you reported is fixed in the latest version of turbogears, which is due to be installed in the Debian FTP archive: python-turbogears_1.1.3-1_all.deb to main/t/turbogears/python-turbogears_1.1.3-1_all.deb turbogears_1.1.3-1.debian.tar.gz to main/t/turbogears/turbogears_1.1.3-1.debian.tar.gz turbogears_1.1.3-1.dsc to main/t/turbogears/turbogears_1.1.3-1.dsc turbogears_1.1.3.orig.tar.gz to main/t/turbogears/turbogears_1.1.3.orig.tar.gz A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 579...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Dmitrijs Ledkovs x...@debian.org (supplier of updated turbogears package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) Format: 1.8 Date: Thu, 19 Apr 2012 01:34:46 +0100 Source: turbogears Binary: python-turbogears Architecture: source all Version: 1.1.3-1 Distribution: unstable Urgency: low Maintainer: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org Changed-By: Dmitrijs Ledkovs x...@debian.org Description: python-turbogears - Python-based web framework Closes: 556424 579105 Changes: turbogears (1.1.3-1) unstable; urgency=low . * Team upload * New upstream release * Add missing dependencies (Closes: #556424 #615520) * Switch to 3.0 (quilt) format * Fix spelling mistake in README.Debian (thanks lintian) * Switch to dh_python2, aids with correct dependencies (Closes: #579105) * Depend on libjs-mochikit symlink mochikit.js (thanks lintian) * Remove ez_setup calls from setup.py so ez_setup doesn't try to download packages during build (thanks ubuntu) * Update watch file Checksums-Sha1: 5434d49173a55c851ee056d3250684afbf4fcd95 2344 turbogears_1.1.3-1.dsc 967375612df09e5b8fc5a05302b73fc9e842003d 1207543 turbogears_1.1.3.orig.tar.gz 58dc61f0b51b6d1950db4278ff9ed8ce3b16b882 10360 turbogears_1.1.3-1.debian.tar.gz f87f3d81d0d0b60adbcf3106dd880f379b3965e5 1184172 python-turbogears_1.1.3-1_all.deb Checksums-Sha256: 25da42ed5de8437408c8e6eaaa9a630556838ba13b68320ac190fa90a4dc9df1 2344 turbogears_1.1.3-1.dsc 051ac9f0d0aeca009ea8b2bc24a46c148dcb1f7df8335655bd4f672b6751d854 1207543 turbogears_1.1.3.orig.tar.gz d4207af97ef1b97e77accdd7360ecc48b0e0fefe5281870d2d91a848b065612e 10360 turbogears_1.1.3-1.debian.tar.gz 9ce87f53120b57fd24ba338e9bf484d092bd94c788ba1dbb4a548b6a2bf47516 1184172 python-turbogears_1.1.3-1_all.deb Files: ae89654ccd82c6c0dd8cbe8cfbae9f58 2344 python optional turbogears_1.1.3-1.dsc a2ed1c571290f7eea3330c240f15abf4 1207543 python optional turbogears_1.1.3.orig.tar.gz 6258460eff9d82581714c97888c70e79 10360 python optional turbogears_1.1.3-1.debian.tar.gz 8f054c403db0e0be29e4cea785d85493 1184172 python optional python-turbogears_1.1.3-1_all.deb signature.asc Description: OpenPGP digital signature
Bug#665421: pcre3: Invalid version string 8.30..-3 makes impossible to download the packages with apt
Source: pcre3 Version: 8.30..-3 Severity: grave Justification: renders package unusable Upon apt-get install, it fails with: Err http://ftp.debian.org/debian/ sid/main libpcre3 amd64 8.30..-3 403 Forbidden file type or location: http://ftp.debian.org/debian/pool/main/p/pcre3/libpcre3_8.30..-3_amd64.deb Please do not use two consecutive dots in the package name? I'm confused how that got published / allowed by debian archive. =/ Just one more bug on top of the recent bugs. -- With regards, Dmitrijs Ledkovs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654511: Doesn't contain source for waf binary code
3.1.5 release is imminent. Will be fixed part of that upload. Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#606696: Patch to fix purge after dependencies removed
tags 606690 + patch tags 606695 + patch tags 606696 + patch thanks Dear maintainer, I have prepared the fix for the three RC bugs reported against poker-network's packages. This patch changes affected postrm scripts to comply with Debian Policy and dbconfig-common policy/documentation. Please consider applying these changes. I'm also seeking NMU to upload these fixes. Dear Jakub Wilk, Please review and sponsor this NMU. With regards, Dmitrijs. pgppYAE3QulXC.pgp Description: PGP signature === modified file 'debian/changelog' --- poker-network-1.7.7-3/debian/changelog 2010-09-08 07:50:35 + +++ poker-network-1.7.7-3.1/debian/changelog 2010-12-15 22:49:58 + @@ -1,3 +1,18 @@ +poker-network (1.7.7-3.1) unstable; urgency=high + + * Non-maintainer upload. + * Fix failing to purge packages after dependencies have been +removed. Add check that dbconfig-common postrm scripts exist before +sourcing them. And also use dbc_go during purge only if the previous +check passes. This is inline with dbconfig-common documentation / +examples. Affected packages are: + ++ poker-web (postrm.mysql and dbc_go) (Closes: #606690) ++ python-poker-prizes.postrm (frontend.postrm.mysql and dbc_go) (Closes: #606695) ++ python-poker-stats.postrm (frontend.postrm.mysql and dbc_go) (Closes: #606696) + + -- Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Wed, 15 Dec 2010 20:59:51 + + poker-network (1.7.7-3) unstable; urgency=low * add da and ru translations from NMU 1.7.7-1.1 accidentaly removed === modified file 'debian/poker-web.postrm' --- poker-network-1.7.7-3/debian/poker-web.postrm 2010-09-06 16:05:27 + +++ poker-network-1.7.7-3.1/debian/poker-web.postrm 2010-12-15 22:11:31 + @@ -23,11 +23,13 @@ if [ -f /usr/share/debconf/confmodule ]; then . /usr/share/debconf/confmodule fi -. /usr/share/dbconfig-common/dpkg/postrm.mysql -dbc_dbname=currency_one -dbc_go poker-web-currency-one $@ -dbc_dbname=pokerweb -dbc_go poker-web $@ +if [ -f /usr/share/dbconfig-common/dpkg/postrm.mysql ]; then +. /usr/share/dbconfig-common/dpkg/postrm.mysql +dbc_dbname=currency_one +dbc_go poker-web-currency-one $@ +dbc_dbname=pokerweb +dbc_go poker-web $@ +fi # Dh_installdeb will replace this with shell code automatically # generated by other debhelper scripts. === modified file 'debian/python-poker-prizes.postrm' --- poker-network-1.7.7-3/debian/python-poker-prizes.postrm 2009-04-14 13:48:25 + +++ poker-network-1.7.7-3.1/debian/python-poker-prizes.postrm 2010-12-15 22:37:37 + @@ -8,8 +8,10 @@ # Establish the preliminaries. db_version 2.0 -. /usr/share/dbconfig-common/dpkg/frontend.postrm.mysql -dbc_go python-poker-prizes $@ +if [ -f /usr/share/dbconfig-common/dpkg/frontend.postrm.mysql ]; then +. /usr/share/dbconfig-common/dpkg/frontend.postrm.mysql +dbc_go python-poker-prizes $@ +fi # dh_installdeb will replace this with shell code automatically # generated by other debhelper scripts. === modified file 'debian/python-poker-stats.postrm' --- poker-network-1.7.7-3/debian/python-poker-stats.postrm 2008-12-22 21:52:48 + +++ poker-network-1.7.7-3.1/debian/python-poker-stats.postrm 2010-12-15 22:37:55 + @@ -8,8 +8,10 @@ # Establish the preliminaries. db_version 2.0 -. /usr/share/dbconfig-common/dpkg/frontend.postrm.mysql -dbc_go python-poker-stats $@ +if [ -f /usr/share/dbconfig-common/dpkg/frontend.postrm.mysql ]; then +. /usr/share/dbconfig-common/dpkg/frontend.postrm.mysql +dbc_go python-poker-stats $@ +fi # dh_installdeb will replace this with shell code automatically # generated by other debhelper scripts. pgpMk6oXFnzTQ.pgp Description: PGP signature
Bug#606696: Patch to fix purge after dependencies removed
On 16 December 2010 19:08, Julien Valroff jul...@kirya.net wrote: Hi Dmitrijs, Le jeudi 16 déc. 2010 à 12:53:38 (+), Dmitrijs Ledkovs a écrit : Dear maintainer, I have prepared the fix for the three RC bugs reported against poker-network's packages. This patch changes affected postrm scripts to comply with Debian Policy and dbconfig-common policy/documentation. Please consider applying these changes. I'm also seeking NMU to upload these fixes. Please forgive me, I have just uploaded an NMU to DELAYED/4 and have only noticed afterwards you had already worked on this issue. no worries. The changes are the same as yours, I have also added a part removing backup files possibly left by ucf. I was under impression purge was rather generous and did rm -rf on those. I will learn from your NMU ;-) Again, all my apologies for this. Cheers, Julien -- ,''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `' http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605167: Less hacking patch
Jakub Wilk jw...@debian.org writes: * Dmitrijs Ledkovs dmitrij.led...@ubuntu.com, 2010-12-11, 18:47: -Architecture: any +Architecture: all I'm not sure if the release team will be happy with the above change... --- gnome-schedule-2.0.2~/Makefile.am2007-12-21 08:30:24.0 -0500 +++ gnome-schedule-2.0.2/Makefile.am 2008-03-09 22:49:35.0 -0500 @@ -11,7 +11,6 @@ This change is not documented in the changelog AFAICS. If you run the configure script from an untrusted directory, you are doomed anyway (the script created files with predictable names). IOW, you are not supposed to do that. While the hunk is technically correct, I'd omit it, so that we don't need to regenerate ./configure. OK. --- gnome-schedule2.1.1-3/debian/rules2009-11-09 10:01:57 + +++ gnome-schedule2.1.1-3.1/debian/rules 2010-12-11 18:16:11 + + dh_autotools-dev_updateconfig + dh_autotools-dev_restoreconfig + dh_clean I think it's too late in the release process for this change (and it wouldn't be suitable for an NMU anyway). Fixed above mentioned issues. Here is the updated debdiff: pgptp4BNZlB2O.pgp Description: PGP signature === modified file 'debian/changelog' --- gnome-schedule-2.1.1-3/debian/changelog 2010-01-29 11:37:55 + +++ gnome-schedule-2.1.1-3.1/debian/changelog 2010-12-13 22:33:36 + @@ -1,3 +1,12 @@ +gnome-schedule (2.1.1-3.1) unstable; urgency=high + + * Non-maintainer upload. + * Fix setting PYTHONPATH in an insecure way (Closes: #605167): +- Update debian/patches/03_distclean.patch to fix trailing slash error +from make. + + -- Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Sat, 11 Dec 2010 11:12:35 + + gnome-schedule (2.1.1-3) unstable; urgency=low * Added dpatch to fix exception Syntax error (Closes: #567406) === modified file 'debian/patches/00list' --- gnome-schedule-2.1.1-3/debian/patches/00list 2010-01-29 11:37:55 + +++ gnome-schedule-2.1.1-3.1/debian/patches/00list 2010-12-11 10:58:07 + @@ -1,2 +1,3 @@ 03_distclean xwrapper_bug567406 +bug605167-pythonpath.dpatch === modified file 'debian/patches/03_distclean.dpatch' --- gnome-schedule-2.1.1-3/debian/patches/03_distclean.dpatch 2009-11-08 17:17:39 + +++ gnome-schedule-2.1.1-3.1/debian/patches/03_distclean.dpatch 2010-12-13 22:32:01 + @@ -5,14 +5,14 @@ ## DP: don't remove gnome-doc-utils.make in the distclean target. @DPATCH@ -diff -urNad gnome-schedule-2.0.2~/Makefile.am gnome-schedule-2.0.2/Makefile.am --- gnome-schedule-2.0.2~/Makefile.am 2007-12-21 08:30:24.0 -0500 +++ gnome-schedule-2.0.2/Makefile.am 2008-03-09 22:49:35.0 -0500 @@ -11,7 +11,6 @@ intltool-merge \ intltool-update \ - po/.intltool-merge-cache \ +- po/.intltool-merge-cache \ - gnome-doc-utils.make ++ po/.intltool-merge-cache EXTRA_DIST = \ gnome-doc-utils.make \ @@ -22,8 +22,9 @@ @@ -239,7 +239,6 @@ intltool-merge \ intltool-update \ - po/.intltool-merge-cache \ +- po/.intltool-merge-cache \ - gnome-doc-utils.make ++ po/.intltool-merge-cache EXTRA_DIST = \ gnome-doc-utils.make \ === added file 'debian/patches/bug605167-pythonpath.dpatch' --- gnome-schedule-2.1.1-3/debian/patches/bug605167-pythonpath.dpatch 1970-01-01 00:00:00 + +++ gnome-schedule-2.1.1-3.1/debian/patches/bug605167-pythonpath.dpatch 2010-12-13 22:29:52 + @@ -0,0 +1,26 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## bug605167_hackish.dpatch by chrysn chr...@fsfe.org +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: Patch for debian bug #605167. + +...@dpatch@ +--- a/src/config.py.in b/src/config.py.in +@@ -21,7 +21,7 @@ version = @VERSION@ + image_dir = @prefix@/share/pixmaps/gnome-schedule + gs_dir = @prefix@/share/gnome-schedule + glade_dir = gs_dir +-xwrapper_exec = pythonpa...@pythonpath@/gtk-2.0/:$PYTHONPATH @PYTHON@ @prefix@/share/gnome-schedule/xwrapper.py ++xwrapper_exec = @PYTHON@ @prefix@/share/gnome-schedule/xwrapper.py + locale_dir = @prefix@/share/locale + crontabbin = @CRONTAB_CONFIG@ + atbin = @AT_CONFIG@ +--- a/src/gnome-schedule.in b/src/gnome-schedule.in +@@ -1,2 +1,2 @@ + #! /bin/sh +-pythonpa...@pythonpath@/gtk-2.0/:$PYTHONPATH @PYTHON@ @prefix@/share/gnome-schedule/gnome-schedule.py $1 +...@python@ @prefix@/share/gnome-schedule/gnome-schedule.py $1 + +
Bug#605167: Less hacking patch
There is like nothing left from the original patch. pgp8Cse4YPebW.pgp Description: PGP signature === modified file 'debian/changelog' --- gnome-schedule-2.1.1-3/debian/changelog 2010-01-29 11:37:55 + +++ gnome-schedule-2.1.1-3.1/debian/changelog 2010-12-14 01:31:21 + @@ -1,3 +1,10 @@ +gnome-schedule (2.1.1-3.1) unstable; urgency=high + + * Non-maintainer upload. + * Fix setting PYTHONPATH in an insecure way (Closes: #605167): + + -- Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Sat, 11 Dec 2010 11:12:35 + + gnome-schedule (2.1.1-3) unstable; urgency=low * Added dpatch to fix exception Syntax error (Closes: #567406) === modified file 'debian/patches/00list' --- gnome-schedule-2.1.1-3/debian/patches/00list 2010-01-29 11:37:55 + +++ gnome-schedule-2.1.1-3.1/debian/patches/00list 2010-12-11 10:58:07 + @@ -1,2 +1,3 @@ 03_distclean xwrapper_bug567406 +bug605167-pythonpath.dpatch === added file 'debian/patches/bug605167-pythonpath.dpatch' --- gnome-schedule-2.1.1-3/debian/patches/bug605167-pythonpath.dpatch 1970-01-01 00:00:00 + +++ gnome-schedule-2.1.1-3.1/debian/patches/bug605167-pythonpath.dpatch 2010-12-13 22:29:52 + @@ -0,0 +1,26 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## bug605167_hackish.dpatch by chrysn chr...@fsfe.org +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: Patch for debian bug #605167. + +...@dpatch@ +--- a/src/config.py.in b/src/config.py.in +@@ -21,7 +21,7 @@ version = @VERSION@ + image_dir = @prefix@/share/pixmaps/gnome-schedule + gs_dir = @prefix@/share/gnome-schedule + glade_dir = gs_dir +-xwrapper_exec = pythonpa...@pythonpath@/gtk-2.0/:$PYTHONPATH @PYTHON@ @prefix@/share/gnome-schedule/xwrapper.py ++xwrapper_exec = @PYTHON@ @prefix@/share/gnome-schedule/xwrapper.py + locale_dir = @prefix@/share/locale + crontabbin = @CRONTAB_CONFIG@ + atbin = @AT_CONFIG@ +--- a/src/gnome-schedule.in b/src/gnome-schedule.in +@@ -1,2 +1,2 @@ + #! /bin/sh +-pythonpa...@pythonpath@/gtk-2.0/:$PYTHONPATH @PYTHON@ @prefix@/share/gnome-schedule/gnome-schedule.py $1 +...@python@ @prefix@/share/gnome-schedule/gnome-schedule.py $1 + + pgpRH2zzWNofF.pgp Description: PGP signature -- With regards Dmitrijs.
Bug#605167: Less hacking patch
I've started with chrysn patch and improved it.
I'm using dh_autotools-dev dh_autoreconf to update configury at build
time to avoid make timestamp screw issues, which seems to be the current
knowhow.
I've also have taken the liberty to fix #606516 in this debdiff.
I hope this debdiff will be sponsored.
With regards,
Dmitrijs.
pgpIRYe6vMDfg.pgp
Description: PGP signature
=== modified file 'debian/changelog'
--- gnome-schedule2.1.1-3/debian/changelog 2010-01-29 11:37:55 +
+++ gnome-schedule2.1.1-3.1/debian/changelog 2010-12-11 18:39:34 +
@@ -1,3 +1,13 @@
+gnome-schedule (2.1.1-3.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Fix setting PYTHONPATH in an insecure way (Closes: #605167):
+- Using dh_autotools-dev to update config.*
+- Using dh_autoreconf to update autotools
+ * Set architecture to all (Closes: #606516)
+
+ -- Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Sat, 11 Dec 2010 11:12:35 +
+
gnome-schedule (2.1.1-3) unstable; urgency=low
* Added dpatch to fix exception Syntax error (Closes: #567406)
=== modified file 'debian/control'
--- gnome-schedule2.1.1-3/debian/control 2010-01-29 11:37:55 +
+++ gnome-schedule2.1.1-3.1/debian/control 2010-12-11 18:39:00 +
@@ -2,12 +2,12 @@
Section: gnome
Priority: optional
Maintainer: Alejandro Rios P. aler...@debian.org
-Build-Depends: debhelper (= 7.4.3), autotools-dev, python-dev, pkg-config, python-gtk2-dev, libgtk2.0-dev, yelp, libxml-parser-perl, cron, at, scrollkeeper, python-support (= 1.0.4), python-glade2, python-gnome2-dev, dpatch, gnome-doc-utils, python-all-dev, intltool
+Build-Depends: debhelper (= 7.4.3), autotools-dev, python-dev, pkg-config, python-gtk2-dev, libgtk2.0-dev, yelp, libxml-parser-perl, cron, at, scrollkeeper, python-support (= 1.0.4), python-glade2, python-gnome2-dev, dpatch, gnome-doc-utils, python-all-dev, intltool, dh-autoreconf
Homepage: http://gnome-schedule.sf.net/
Standards-Version: 3.8.3
Package: gnome-schedule
-Architecture: any
+Architecture: all
Depends: ${python:Depends}, python-gtk2, at, anacron, python-gnome2, python-glade2, ${misc:Depends}
Description: GNOME scheduler for automatic tasks
GNOME GUI for configuring a users' cron (automatic jobs).
=== modified file 'debian/patches/00list'
--- gnome-schedule2.1.1-3/debian/patches/00list 2010-01-29 11:37:55 +
+++ gnome-schedule2.1.1-3.1/debian/patches/00list 2010-12-11 10:58:07 +
@@ -1,2 +1,3 @@
03_distclean
xwrapper_bug567406
+bug605167-pythonpath.dpatch
=== modified file 'debian/patches/03_distclean.dpatch'
--- gnome-schedule2.1.1-3/debian/patches/03_distclean.dpatch 2009-11-08 17:17:39 +
+++ gnome-schedule2.1.1-3.1/debian/patches/03_distclean.dpatch 2010-12-11 11:10:32 +
@@ -5,25 +5,14 @@
## DP: don't remove gnome-doc-utils.make in the distclean target.
@DPATCH@
-diff -urNad gnome-schedule-2.0.2~/Makefile.am gnome-schedule-2.0.2/Makefile.am
--- gnome-schedule-2.0.2~/Makefile.am 2007-12-21 08:30:24.0 -0500
+++ gnome-schedule-2.0.2/Makefile.am 2008-03-09 22:49:35.0 -0500
@@ -11,7 +11,6 @@
intltool-merge \
intltool-update \
- po/.intltool-merge-cache \
-- gnome-doc-utils.make
-
- EXTRA_DIST = \
- gnome-doc-utils.make \
-diff -urNad gnome-schedule-2.0.2~/Makefile.in gnome-schedule-2.0.2/Makefile.in
gnome-schedule-2.0.2~/Makefile.in 2008-02-08 13:21:45.0 -0500
-+++ gnome-schedule-2.0.2/Makefile.in 2008-03-09 22:54:35.0 -0500
-@@ -239,7 +239,6 @@
- intltool-merge \
- intltool-update \
- po/.intltool-merge-cache \
-- gnome-doc-utils.make
+- po/.intltool-merge-cache \
+- gnome-doc-utils.make
++ po/.intltool-merge-cache
EXTRA_DIST = \
gnome-doc-utils.make \
=== added file 'debian/patches/bug605167-pythonpath.dpatch'
--- gnome-schedule2.1.1-3/debian/patches/bug605167-pythonpath.dpatch 1970-01-01 00:00:00 +
+++ gnome-schedule2.1.1-3.1/debian/patches/bug605167-pythonpath.dpatch 2010-12-11 10:57:01 +
@@ -0,0 +1,57 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## bug605167_hackish.dpatch by chrysn chr...@fsfe.org
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Patch for debian bug #605167.
+
+...@dpatch@
+--- a/configure.ac
b/configure.ac
+@@ -10,15 +10,6 @@ AC_SUBST(PYGTK_CFLAGS)
+ AC_SUBST(PYGTK_LIBS)
+
+
+-AC_PATH_PROG( PKGCONFIG, pkg-config, no, $PATH:/usr/bin:/usr/local/bin)
+- if test $PKGCONFIG != no ; then
+-AC_MSG_CHECKING([PYTHONPATH env variable for PyGTK])
+-PYTHONPATH=$($PKGCONFIG --variable=pyexecdir pygtk-2.0)
+-AC_SUBST([PYTHONPATH])
+-AC_MSG_RESULT($PYTHONPATH)
+- fi
+-
+-export PYTHONPATH=$PYGTK_DIR:$PYTHONPATH
+ dnl check for libglade
+ AC_MSG_CHECKING(for gtk.glade)
+ prog=
+@@ -42,7 +33,6 @@ fi
+
+ PKG_CHECK_MODULES(GNOMEPYTHON, gnome-python-2.0 = 2.12.0)
+
+-export PYTHONPATH=$PYGTK_DIR:$PYTHONPATH
+ dnl check for python-gconf
+ AC_MSG_CHECKING(for python gconf)
+ prog=
+diff --git a/desktop/Makefile.in b/desktop/Makefile.in
+index 76ccd31
Bug#605157: calendarserver: Use of PYTHONPATH env var in an insecure way
tags 605157 + patch
thanks
Jakub Wilk jw...@debian.org writes:
tags 605157 - patch
thanks
* Dmitrijs Ledkovs dmitrij.led...@ubuntu.com, 2010-12-03, 22:37:
With my patch applied the resulting /usr/bin/caldavd has:
PYTHONPATH=/usr/lib/twisted-calendarserver/lib/python2.6/site-packages/:+:$PYTHONPATH
So if PYTHONPATH was originally empty or unset, this expands to:
PYTHONPATH=/usr/lib/twisted-calendarserver/lib/python2.6/site-packages/:+:
Err, that's wrong.
You are right. That is wrong. But it's not doing that. It does this in
sh scripts:
export PYTHONPATH=`${python} -c 'import sys; print
/usr/lib/twisted-calendarserver/lib/python%s/site-packages %
(sys.version[:3])'`
and in py scripts:
PYTHONPATH = /usr/lib/twisted-calendarserver/lib/python%s/site-packages %
(sys.version[:3])
So these are fine. The setup.py was rewriting:
#PATH
#PYTHONPATH
in all sh/python scripts to paths that include calendarserver
stuff. setup.py substituted #PYTHONPATH in an insecure way. Currently it
was only used in caldavd, but not needed at all.
I have tested this by running calendarserver with without new patch
and I can add/retrieve calendar events over the network using
thunderbird-lightning.
With regards,
Dmitrijs.
pgpnxfCVpzkD8.pgp
Description: PGP signature
=== modified file 'debian/changelog'
--- calendarserver-2.4.dfsg-2/debian/changelog 2010-08-25 15:23:37 +
+++ calendarserver-2.4.dfsg-2.1/debian/changelog 2010-12-10 00:54:12 +
@@ -1,3 +1,11 @@
+calendarserver (2.4.dfsg-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Do not set PYTHONPATH env var, not needed (Closes: #605166, #605157)
+ * Prevent setup.py from automagically setting #PYTHONPATH in an insecure way
+
+ -- Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Fri, 03 Dec 2010 21:28:40 +
+
calendarserver (2.4.dfsg-2) unstable; urgency=low
* Removed Uploaders field in debian/changelog
=== added file 'debian/patches/secure-python-path.patch'
--- calendarserver-2.4.dfsg-2/debian/patches/secure-python-path.patch 1970-01-01 00:00:00 +
+++ calendarserver-2.4.dfsg-2.1/debian/patches/secure-python-path.patch 2010-12-10 00:52:31 +
@@ -0,0 +1,64 @@
+Removes setting PYTHONPATH in an insecure way, not needed on Debian.
+Removes rewritting rules from setup.py that did that.
+Index: b/setup.py
+===
+--- a/setup.py 2010-12-09 19:21:45.0 -0500
b/setup.py 2010-12-09 19:22:25.0 -0500
+@@ -125,43 +125,3 @@
+ if root:
+ install_lib = install_lib[len(root):]
+
+-for script in dist.scripts:
+-scriptPath = os.path.join(install_scripts, os.path.basename(script))
+-
+-print rewriting %s % (scriptPath,)
+-
+-script = []
+-
+-fileType = None
+-
+-for line in file(scriptPath, r):
+-if not fileType:
+-if line.startswith(#!):
+-if python in line.lower():
+-fileType = python
+-elif sh in line.lower():
+-fileType = sh
+-
+-line = line.rstrip(\n)
+-if fileType == sh:
+-if line == #PYTHONPATH:
+-script.append('PYTHONPATH=%s:$PYTHONPATH' % (install_lib,))
+-elif line == #PATH:
+-script.append('PATH=%s:$PATH' % (os.path.join(base, bin),))
+-else:
+-script.append(line)
+-
+-elif fileType == python:
+-if line == #PYTHONPATH:
+-script.append('PYTHONPATH=%s' % (install_lib,))
+-elif line == #PATH:
+-script.append('PATH=%s' % (os.path.join(base, bin),))
+-else:
+-script.append(line)
+-
+-else:
+-script.append(line)
+-
+-newScript = open(scriptPath, w)
+-newScript.write(\n.join(script))
+-newScript.close()
+Index: b/bin/caldavd
+===
+--- a/bin/caldavd 2010-12-09 19:21:51.0 -0500
b/bin/caldavd 2010-12-09 19:22:41.0 -0500
+@@ -16,9 +16,6 @@
+ # limitations under the License.
+ ##
+
+-#PATH
+-#PYTHONPATH
+-
+ daemonize=;
+ username=;
+ groupname=;
=== modified file 'debian/patches/series'
--- calendarserver-2.4.dfsg-2/debian/patches/series 2010-08-25 15:23:37 +
+++ calendarserver-2.4.dfsg-2.1/debian/patches/series 2010-12-10 00:52:31 +
@@ -2,3 +2,4 @@
ldapdirectory.patch
paths.diff
linux-xattr-fix.patch
+secure-python-path.patch
Bug#605157: calendarserver: Use of PYTHONPATH env var in an insecure way
tags 605157 patch
thanks
Dear maintainer,
I've prepared an NMU for calendarserver (versioned as 2.4.dfsg-2.1). I
will seek sponsorship to upload for delayed queue.
pgpnKC0OaxJiL.pgp
Description: PGP signature
=== modified file 'debian/changelog'
--- a/debian/changelog 2010-08-25 15:23:37 +
+++ b/debian/changelog 2010-12-03 21:33:05 +
@@ -1,3 +1,10 @@
+calendarserver (2.4.dfsg-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Set PYTHONPATH env var in a secure way (Closes: #605166, #605157)
+
+ -- Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Fri, 03 Dec 2010 21:28:40 +
+
calendarserver (2.4.dfsg-2) unstable; urgency=low
* Removed Uploaders field in debian/changelog
=== modified file 'debian/patches/paths.diff'
--- a/debian/patches/paths.diff 2010-08-25 15:23:37 +
+++ b/debian/patches/paths.diff 2010-12-03 21:33:05 +
@@ -173,3 +173,12 @@
ext_modules = extensions,
py_modules = [kqreactor, memcacheclient],
)
+@@ -145,7 +145,7 @@
+ line = line.rstrip(\n)
+ if fileType == sh:
+ if line == #PYTHONPATH:
+-script.append('PYTHONPATH=%s:$PYTHONPATH' % (install_lib,))
++script.append('PYTHONPATH=%s:+:$PYTHONPATH' % (install_lib,))
+ elif line == #PATH:
+ script.append('PATH=%s:$PATH' % (os.path.join(base, bin),))
+ else:
Bug#605157: calendarserver: Use of PYTHONPATH env var in an insecure way
Jakub Wilk jw...@debian.org writes:
Hi Dmitrijs,
+@@ -145,7 +145,7 @@
+ line = line.rstrip(\n)
+ if fileType == sh:
+ if line == #PYTHONPATH:
+-script.append('PYTHONPATH=%s:$PYTHONPATH' %
(install_lib,))
++script.append('PYTHONPATH=%s:+:$PYTHONPATH' %
(install_lib,))
+ elif line == #PATH:
+ script.append('PATH=%s:$PATH' % (os.path.join(base,
bin),))
+ else:
This patch looks very suspicious. Have you actually tested it?
Besides, as far as I can see, /usr/bin/caldavd doesn't need PYTHONPATH
mangling
at all.
Hello Jakub,
Yes the patch is strange, because the build-system is strange. The
source scripts actually have line #PYTHONPATH which is rewritten
during buildtime. From build log:
rewriting
/home/tdlk/src/build-dir/calendarserver-2.4.dfsg/debian/calendarserver/usr/bin/caldavd
rewriting
/home/tdlk/src/build-dir/calendarserver-2.4.dfsg/debian/calendarserver/usr/bin/calendarserver_export
rewriting
/home/tdlk/src/build-dir/calendarserver-2.4.dfsg/debian/calendarserver/usr/bin/calendarserver_manage_principals
With my patch applied the resulting /usr/bin/caldavd has:
PYTHONPATH=/usr/lib/twisted-calendarserver/lib/python2.6/site-packages/:+:$PYTHONPATH
Then in goes to perform many checks and finally (after finding
everything it needs) it sets:
export PYTHONPATH=`${python} -c 'import sys; print
/usr/lib/twisted-calendarserver/lib/python%s/site-packages %
(sys.version[:3])'`
echo exec ${python} ${twistdpath} ${twistd_reactor} ${daemonize}
${username} ${groupname} ${plugin_name} ${configfile} ${service_type}
${profile} ${child_reactor};
exec ${python} ${twistdpath} ${twistd_reactor} ${daemonize} ${username}
${groupname} ${plugin_name} ${configfile} ${service_type} ${profile}
${child_reactor};
Between the first PYTHONPATH and the second it executes this:
echo $(${python} -c from distutils.sysconfig import get_python_version;
print get_python_version());
So if I drop evil distutils.sysconfig in the current dir I can
potentially do something evil? Or I'm getting this wrong?
Thanks for a review.
pgpNv4WkMPRgn.pgp
Description: PGP signature
Bug#605157: calendarserver: Use of PYTHONPATH env var in an insecure way
Jakub Wilk jw...@debian.org writes:
Hi Dmitrijs,
+@@ -145,7 +145,7 @@
+ line = line.rstrip(\n)
+ if fileType == sh:
+ if line == #PYTHONPATH:
+-script.append('PYTHONPATH=%s:$PYTHONPATH' %
(install_lib,))
++script.append('PYTHONPATH=%s:+:$PYTHONPATH' %
(install_lib,))
+ elif line == #PATH:
+ script.append('PATH=%s:$PATH' % (os.path.join(base,
bin),))
+ else:
This patch looks very suspicious. Have you actually tested it?
Besides, as far as I can see, /usr/bin/caldavd doesn't need PYTHONPATH
mangling
at all.
Now to answer your question =
No it doesn't seem to need 1st PYTHONPATH mangling, but I think it does need the
second one:
export PYTHONPATH=`${python} -c 'import sys; print
/usr/lib/twisted-calendarserver/lib/python%s/site-packages %
(sys.version[:3])'`
But this one is secure way to set it.
pgpjx2BUfOCh4.pgp
Description: PGP signature
Bug#582904: [Pkg-crosswire-devel] Bug#582904: xiphos: FTBFS on hppa (waf parallel build issues)
On 24 May 2010 14:00, Adam D. Barratt a...@adam-barratt.org.uk wrote: Package: xiphos Version: 3.1.3-1 Severity: serious Hi, xiphos FTBFS on hppa due to an issue with waf's parallel building on that platform. The patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=51;filename=patchage-0.4.4-1.2-nmu.diff;att=1;bug=561305 should be fairly easily adaptable; most likely only the debian/rules changes would need any modification. I think I can come up with a better / more portable / more pythonic patch and push it upstream? =) Can you confirm that my wild guesses match the output of these two commands on hppa? $ python -c import platform; print platform.machine() hppa $ python -c import sys; print sys.platform linux2-hppa -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582904: [Pkg-crosswire-devel] Bug#582904: xiphos: FTBFS on hppa (waf parallel build issues)
I'm impatient =) considering this is true:
$ python -c import sys; print sys.platform
linux2-hppa
Can you please try building ?
http://mentors.debian.net/debian/pool/main/x/xiphos/xiphos_3.1.3-3.dsc
As you can see in the patch it uses waf functionality to load
additional python modules from any tooldir from the top-level wscript.
With this patch you can drop nothreads.py into debian/patches and have
a one liner patch for wscript
+ conf.check_tool('nothreads', tooldir=debian/patches)
under configure =)
with no changes to debian/rules or fiddling with private waf dir ;-)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582904: [Pkg-crosswire-devel] Bug#582904: xiphos: FTBFS on hppa (waf parallel build issues)
On 24 May 2010 20:50, Adam D. Barratt a...@adam-barratt.org.uk wrote: On Mon, 2010-05-24 at 15:27 +0100, Dmitrijs Ledkovs wrote: I'm impatient =) considering this is true: $ python -c import sys; print sys.platform linux2-hppa Can you please try building ? http://mentors.debian.net/debian/pool/main/x/xiphos/xiphos_3.1.3-3.dsc Yes, that builds happily on the hppa porter box. 3.1.3-2 gets stuck at Checking for header locale.h : for at least 20 minutes (I got bored at that point and killed it). Great stuff = I will get this package sponsored then, commit it in xiphos trunk ping waf upstream about this ;-) Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580824: jack-audio-connection-kit: FTBFS on hppa (multiple issues)
On 9 May 2010 08:05, Adam D. Barratt a...@adam-barratt.org.uk wrote: On Sun, May 9, 2010 01:05, Dmitrijs Ledkovs wrote: On 9 May 2010 00:44, Adam D. Barratt a...@adam-barratt.org.uk wrote: - waf's parallel building and hppa don't mix; I've stolen a patch which Jakub Wilk provided for xmms2 and applied it to j-a-c-k. It will break if anything causes the .waf.-* directory to be renamed, but that seems like another reason not to use waf ;-) Running waf with -j1 flag should stop all paralelism. e.g. ./waf configure build -j1 Is this not enough to make waf behave on hppa? From what I could see from reading the code, the number of jobs should automatically default to the number of available CPUs in any case, so should automatically be 1 at least on the porter box. However, assuming that adding the following to debian/rules would implement your suggestion, then sadly no it does not appear to be enough: waf-configure-options += $(if $(filter hppa,$(DEB_HOST_ARCH)),-j1) Even with this change, the ./waf configure call hangs after outputting Checking for dbus-1 = 1.0.0 : ok Checking for dbus-1 flags : ok Checking for header expat.h : ok I killed it after 15 minutes of inactivity; the build output shows that -j1 was passed to the configure call. If I add the Runner.py patch instead, it gets past that point with ease (and later fails with the second error I mentioned, which is trivially fixable by adding !defined(__hppa__) to an existing patch). Regards, Adam Can you please run it as (without any patches) ./waf -vvv -j1 And send me buildlog please? This is quite disturbing. I'm a waf lover =) and have submitted a few patches upstream. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580824: jack-audio-connection-kit: FTBFS on hppa (multiple issues)
On 9 May 2010 00:44, Adam D. Barratt a...@adam-barratt.org.uk wrote: - waf's parallel building and hppa don't mix; I've stolen a patch which Jakub Wilk provided for xmms2 and applied it to j-a-c-k. It will break if anything causes the .waf.-* directory to be renamed, but that seems like another reason not to use waf ;-) Running waf with -j1 flag should stop all paralelism. e.g. ./waf configure build -j1 Is this not enough to make waf behave on hppa? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
