Bug#953562: libcrypt1 should ship file in /lib, Replaces is useless
Control: retitle -1 libcrypt1: Wrong soname on ia64 On 14 Mar 2020, at 14:20, John Paul Adrian Glaubitz wrote: > > Package: libcrypt1 > Version: 1:4.4.15-1 > Followup-For: Bug #953562 > User: debian-i...@lists.debian.org > Usertags: ia64 > > Hello! > > This actually causes issues on ia64 now: > > Setting up libc6.1:ia64 (2.30-2) ... > /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot > open shared object file: No such file or directory > dpkg: error processing package libc6.1:ia64 (--configure): > installed libc6.1:ia64 package post-installation script subprocess returned > error exit status 127 > Errors were encountered while processing: > libc6.1:ia64 > E: Sub-process /usr/bin/dpkg returned an error code (1) > apt-get failed. > E: Package installation failed > > So it's not just a theoretical issue. This is just the opposite of #947606; ia64 is meant to have libcrypt.so.1, not libcrypt.so.1.1 like alpha, and so that change needs to be reverted. See [1] for an old glibc build log to demonstrate the correct name (and note that, unlike alpha, sysdeps/unix/sysv/linux/ia64/shlib-versions does not override libcrypt's version). James [1] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=ia64&ver=2.28-2&stamp=1544971021&raw=0
Bug#927358: segemehl: Please stop building on any-i386
Package: segemehl Version: 0.3.4-1 Severity: serious Hi, This package uses htslib, which is no longer supported on any-i386. #914991 removed the binaries on any-i386, but until any-i386 is removed from Architecture:, wanna-build will re-build the package, thereby reinstating the binaries on any-i386. Please upload a new version of the source package with any-i386 removed from Architecture: for this binary package. Regards, James
Bug#927359: tabix: Please stop building on any-i386
Package: tabix Version: 1.9-10 Severity: serious Hi, This package uses htslib, which is no longer supported on any-i386. #914991 removed the binaries on any-i386, but until any-i386 is removed from Architecture:, wanna-build will re-build the package, thereby reinstating the binaries on any-i386. Please upload a new version of the source package with any-i386 removed from Architecture: for this binary package. Regards, James
Bug#927357: samtools: Please stop building on any-i386
Package: samtools Version: 1.9-4 Severity: serious Hi, This package uses htslib, which is no longer supported on any-i386. #914991 removed the binaries on any-i386, but until any-i386 is removed from Architecture:, wanna-build will re-build the package, thereby reinstating the binaries on any-i386. Please upload a new version of the source package with any-i386 removed from Architecture: for this binary package. Regards, James
Bug#927356: qtltools: Please stop building on any-i386
Package: qtltools Version: 1.1+dfsg-3 Severity: serious Hi, This package uses htslib, which is no longer supported on any-i386. #914991 removed the binaries on any-i386, but until any-i386 is removed from Architecture:, wanna-build will re-build the package, thereby reinstating the binaries on any-i386. Please upload a new version of the source package with any-i386 removed from Architecture: for this binary package. Regards, James
Bug#927354: libhts2: Please stop building on any-i386
Package: libhts2 Version: 1.9-10 Severity: serious Hi, This package uses htslib, which is no longer supported on any-i386. #914991 removed the binaries on any-i386, but until any-i386 is removed from Architecture:, wanna-build will re-build the package, thereby reinstating the binaries on any-i386. Please upload a new version of the source package with any-i386 removed from Architecture: for this binary package. Regards, James
Bug#927353: libhts-dev: Please stop building on any-i386
Package: libhts-dev Version: 1.9-10 Severity: serious Hi, This package uses htslib, which is no longer supported on any-i386. #914991 removed the binaries on any-i386, but until any-i386 is removed from Architecture:, wanna-build will re-build the package, thereby reinstating the binaries on any-i386. Please upload a new version of the source package with any-i386 removed from Architecture: for this binary package. Regards, James
Bug#927352: delly: Please stop building on any-i386
Package: delly Version: 0.8.1-2 Severity: serious Hi, This package uses htslib, which is no longer supported on any-i386. #914991 removed the binaries on any-i386, but until any-i386 is removed from Architecture:, wanna-build will re-build the package, thereby reinstating the binaries on any-i386. Please upload a new version of the source package with any-i386 removed from Architecture: for this binary package. Regards, James
Bug#927351: augustus: Please stop building on any-i386
Package: augustus Version: 3.3.2+dfsg-2 Severity: serious Hi, This package uses htslib, which is no longer supported on any-i386. #914991 removed the binaries on any-i386, but until any-i386 is removed from Architecture:, wanna-build will re-build the package, thereby reinstating the binaries on any-i386. Please upload a new version of the source package with any-i386 removed from Architecture: for this binary package. Regards, James
Bug#927355: nanopolish: Please stop building on any-i386
Package: nanopolish Version: 0.11.0-2 Severity: serious Hi, This package uses htslib, which is no longer supported on any-i386. #914991 removed the binaries on any-i386, but until any-i386 is removed from Architecture:, wanna-build will re-build the package, thereby reinstating the binaries on any-i386. Please upload a new version of the source package with any-i386 removed from Architecture: for this binary package. Regards, James
Bug#921838: ppl: FTBFS (LaTeX error)
Looks like this common issue is in fact #921272. (i.e. the currently-packaged tabu broke with recent TeX Live) James
Bug#919855: Bug#919857: 2.0.5-1 crashes
Control: forcemerge 919855 919857 On Sun, Jan 20, 2019 at 02:22:38PM +, Thorsten Glaser wrote: > Ben Hutchings dixit: > > >the new Debian version crashes on s390x. It looks like this is due to > >an address collision between the build ID in the shared library and > >the code in the executables. > > > Helge Deller dixit: > > >[ 58.612345] 117 (fstype): Uhuuh, elf segment at 0001 > >requested but the memory is mapped already > > > Are these two maybe related? Pretty sure it's the same, given we have it on sparc64 too: > [9.765691] 426 (fstype): Uhuuh, elf segment at 0010 requested > but the memory is mapped already > Segmentation fault > [9.777174] aes_sparc64: sparc64 aes opcodes not available. (second line included to convince you I haven't just copied the error :P) James
Bug#919399: FTBFS: undefined reference to makedev
Control: forcemerge 916062 -1 > On 15 Jan 2019, at 14:05, Ritesh Raj Sarraf wrote: > > Source: cowdancer > Version: 0.87 This was already reported as the bug mentioned above and fixed in the 0.88 upload a week ago. Also please don't forward raw multi-part MIME messages; you end up with the horrendous mess that you can see below. James > Severity: serious > Tags: patch > Justification: fails to build from source (but built successfully in the past) > > Content-Type: multipart/mixed; boundary="===1317036836604284426==" > MIME-Version: 1.0 > From: Ritesh Raj Sarraf > To: Debian Bug Tracking System > Subject: FTBFS: undefined reference to makedev > Message-ID: > <154756077354.13753.2447109323940488229.report...@priyasi.researchut.com> > X-Mailer: reportbug 7.5.1 > Date: Tue, 15 Jan 2019 19:29:33 +0530 > X-Debbugs-Cc: r...@debian.org > > This is a multi-part MIME message sent by reportbug. > > > --===1317036836604284426== > Content-Type: text/plain; charset="utf-8" > MIME-Version: 1.0 > Content-Transfer-Encoding: base64 > Content-Disposition: inline > > U291cmNlOiBjb3dkYW5jZXIKVmVyc2lvbjogMC44NwpTZXZlcml0eTogc2VyaW91cwpUYWdzOiBw > YXRjaApKdXN0aWZpY2F0aW9uOiBmYWlscyB0byBidWlsZCBmcm9tIHNvdXJjZSAoYnV0IGJ1aWx0 > IHN1Y2Nlc3NmdWxseSBpbiB0aGUgcGFzdCkKCgpsaWJ0b29sOiBjb21waWxlOiAgZ2NjIC1EUEFD > S0FHRV9OQU1FPVwiY293ZGFuY2VyXCIgLURQQUNLQUdFX1RBUk5BTUU9XCJjb3dkYW5jZXJcIiAt > RFBBQ0tBR0VfVkVSU0lPTj1cIjAuODdcIiAiLURQQUNLQUdFX1NUUklORz1cImNvd2RhbmNlciAw > Ljg3XCIiIC1EUEFDS0FHRV9CVUdSRVBPUlQ9XCJcIiAtRFBBQ0tBR0VfVVJMPVwiXCIgLURQQUNL > QUdFPVwiY293ZGFuY2VyXCIgLURWRVJTSU9OPVwiMC44N1wiIC1EU1REQ19IRUFERVJTPTEgLURI > QVZFX1NZU19UWVBFU19IPTEgLURIQVZFX1NZU19TVEFUX0g9MSAtREhBVkVfU1RETElCX0g9MSAt > REhBVkVfU1RSSU5HX0g9MSAtREhBVkVfTUVNT1JZX0g9MSAtREhBVkVfU1RSSU5HU19IPTEgLURI > QVZFX0lOVFRZUEVTX0g9MSAtREhBVkVfU1RESU5UX0g9MSAtREhBVkVfVU5JU1REX0g9MSAtREhB > VkVfRExGQ05fSD0xIC1ETFRfT0JKRElSPVwiLmxpYnMvXCIgLUkuIC1XZGF0ZS10aW1lIC1EX0ZP > UlRJRllfU09VUkNFPTIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLURDT1dEQU5DRVJfU089XCIvdXNy > L2xpYi9jb3dkYW5jZXIvbGliY293ZGFuY2VyLnNvXCIgLWcgLU8yIC1mZGVidWctcHJlZml4LW1h > cD0vYnVpbGQvY293ZGFuY2VyLTAuODc9LiAtZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgLVdmb3Jt > YXQgLVdlcnJvcj1mb3JtYXQtc2VjdXJpdHkgLWMgY293ZGFuY2VyLmMgLW8gbGliY293ZGFuY2Vy > X2xhLWNvd2RhbmNlci5vID4vZGV2L251bGwgMj4mMQpsaWJ0b29sOiBsaW5rOiBnY2MgLWZuby1z > dHJpY3QtYWxpYXNpbmcgLURDT1dEQU5DRVJfU089XCIvdXNyL2xpYi9jb3dkYW5jZXIvbGliY293 > ZGFuY2VyLnNvXCIgLWcgLU8yIC1mZGVidWctcHJlZml4LW1hcD0vYnVpbGQvY293ZGFuY2VyLTAu > ODc9LiAtZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgLVdmb3JtYXQgLVdlcnJvcj1mb3JtYXQtc2Vj > dXJpdHkgLVdsLC16IC1XbCxyZWxybyAtV2wsLXogLVdsLG5vdyAtbyBjb3didWlsZGVyIGNvd2J1 > aWxkZXIubyBwYXJhbWV0ZXIubyBmb3JrZXhlYy5vIGlsaXN0Y3JlYXRlLm8gbWFpbi5vIGNvd2J1 > aWxkZXJfdXRpbC5vIGxvZy5vICAtbGRsIC1sbmN1cnNlcwpsaWJ0b29sOiBsaW5rOiBnY2MgLWZu > by1zdHJpY3QtYWxpYXNpbmcgLURDT1dEQU5DRVJfU089XCIvdXNyL2xpYi9jb3dkYW5jZXIvbGli > Y293ZGFuY2VyLnNvXCIgLWcgLU8yIC1mZGVidWctcHJlZml4LW1hcD0vYnVpbGQvY293ZGFuY2Vy > LTAuODc9LiAtZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgLVdmb3JtYXQgLVdlcnJvcj1mb3JtYXQt > c2VjdXJpdHkgLVdsLC16IC1XbCxyZWxybyAtV2wsLXogLVdsLG5vdyAtbyBxZW11YnVpbGRlciBx > ZW11YnVpbGRlci1xZW11YnVpbGRlci5vIHFlbXVidWlsZGVyLXBhcmFtZXRlci5vIHFlbXVidWls > ZGVyLWZvcmtleGVjLm8gcWVtdWJ1aWxkZXItcWVtdWlwc2FuaXRpemUubyBxZW11YnVpbGRlci1x > ZW11YXJjaC5vIHFlbXVidWlsZGVyLWZpbGUubyBxZW11YnVpbGRlci1tYWluLm8gcWVtdWJ1aWxk > ZXItbG9nLm8gIC1sZGwgLWxuY3Vyc2VzCi91c3IvYmluL2xkOiBxZW11YnVpbGRlci1xZW11YXJj > aC5vOiBpbiBmdW5jdGlvbiBgcWVtdV9jcmVhdGVfYXJjaF9zZXJpYWxkZXZpY2UnOgouL3FlbXVh > cmNoLmM6NjA6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYG1ha2VkZXYnCi91c3IvYmluL2xkOiAu > L3FlbXVhcmNoLmM6NjI6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYG1ha2VkZXYnCi91c3IvYmlu > L2xkOiBxZW11YnVpbGRlci1xZW11YXJjaC5vOiBpbiBmdW5jdGlvbiBgcWVtdV9jcmVhdGVfYXJj > aF9kZXZpY2VzJzoKLi9xZW11YXJjaC5jOjg1OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBtYWtl > ZGV2JwovdXNyL2Jpbi9sZDogLi9xZW11YXJjaC5jOjg3OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv > IGBtYWtlZGV2JwovdXNyL2Jpbi9sZDogLi9xZW11YXJjaC5jOjg5OiB1bmRlZmluZWQgcmVmZXJl > bmNlIHRvIGBtYWtlZGV2JwovdXNyL2Jpbi9sZDogcWVtdWJ1aWxkZXItcWVtdWFyY2gubzouL3Fl > bXVhcmNoLmM6OTE6IG1vcmUgdW5kZWZpbmVkIHJlZmVyZW5jZXMgdG8gYG1ha2VkZXYnIGZvbGxv > dwpjb2xsZWN0MjogZXJyb3I6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMKbWFrZVsxXTogKioq > IFtNYWtlZmlsZTo5OTY6IHFlbXVidWlsZGVyXSBFcnJvciAxCm1ha2VbMV06ICoqKiBXYWl0aW5n > IGZvciB1bmZpbmlzaGVkIGpvYnMuLi4uCm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5ICcvYnVp > bGQvY293ZGFuY2VyLTAuODcnCmRoX2F1dG9fYnVpbGQ6IG1ha2UgLWo0IHJldHVybmVkIGV4aXQg > Y29kZSAyCm1ha2U6ICoqKiBbZGViaWFuL3J1bGVzOjY6IGJpbmFyeV0gRXJyb3IgMgpkcGtnLWJ1 > aWxkcGFja2FnZTogZXJyb3I6IGRlYmlhbi9ydWxlcyBiaW5hcnkgc3VicHJvY2VzcyByZXR1cm5l > ZCBleGl0IHN0YXR1cyAyCkk6IGNvcHlpbmcgbG9jYWwgY29uZmlndXJhdGlvbgpFOiBGYWlsZWQg > YXV0b2J1aWxkaW5nIG9mIHBhY2thZ2UKSTogdW5tb3VudGluZyAvdmFyL2NhY2hlL2FwdC9hcmNo > aXZlcy8gZmlsZXN5c3RlbQpJOiB1bm1vdW50aW5nIGRldi9wdG14IGZpbGVzeXN0ZW0KSTogdW5t > b3VudGluZyBkZXYvcHRzIGZpbGVzeXN0ZW0KSTogdW5tb3VudGluZyBkZXYvc2htIGZpbGVzeXN0 > ZW0KSTogdW5tb3VudGluZyBwc
Bug#916004: Bug #916004 in makefs marked as pending
Control: tag -1 pending Hello, Bug #916004 in makefs reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/bsd-team/makefs/commit/563dfab97012c40a82f1d28607d097e3526b5d85 Fix FTBFS with glibc 2.28 Closes: #916004 (this message was generated automatically) -- Greetings https://bugs.debian.org/916004
Bug#916062: Bug #916062 in cowdancer marked as pending
Control: tag -1 pending Hello, Bug #916062 in cowdancer reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/pbuilder-team/cowdancer/commit/92044b3f09b5085e99ee7361df3798ff5e49c931 Fix FTBFS with glibc 2.28 Closes: #916062 (this message was generated automatically) -- Greetings https://bugs.debian.org/916062
Bug#902729: Missing Conflicts with libmariadb2
Package: libmariadb3 Version: 1:3.0.3-2 Severity: serious Hi, Trying to install libmariadb3 on a system which already has libmariadb2 installed fails with: > Unpacking libmariadb3:amd64 (1:3.0.3-2) ... > dpkg: error processing archive > /var/cache/apt/archives/libmariadb3_1%3a3.0.3-2_amd64.deb (--unpack): > trying to overwrite '/usr/lib/x86_64-linux-gnu/mariadb/plugin/dialog.so', > which is also in package libmariadb2:amd64 2.3.3-1 The plugins are in an unversioned directory, present in both packages, and so the two packages cannot be co-installed. Please add suitable dependency relationships to the new libmariadb3 package to allow upgrades to work. Regards, James
Bug#895540: nx-libs: FTBFS with parallel > 1 due to errors cleaning
On 25 Apr 2018, at 17:16, Mike Gabriel wrote: > > Control: reopen -1 > > Hi James, hi Adrian, hi Niels, > (also Cc:ed: Mihai Moldovan, upstream nx-libs) > > On Do 12 Apr 2018 13:02:45 CEST, James Clarke wrote: > >> Source: nx-libs >> Version: 3.5.99.16-1 >> Severity: serious >> >> Hi, >> Currently, nx-libs FTBFS (likely only probabilistically) when built with >> parallel > 1; this occurred on the ia64 buildd lenz[1], but I have >> reproduced it locally in an amd64 cowbuilder chroot. >> >> Please either fix the Makefile dependency issues, or disable parallel >> cleaning. >> >> Regards, >> James >> >> [1] >> https://buildd.debian.org/status/fetch.php?pkg=nx-libs&arch=ia64&ver=2%3A3.5.99.16-1%2Bb1&stamp=1523508333&raw=0 > > I spent two days with this after my possible fix (running make clean with -j1 > did not fix the problem). > > One reason for the persistance of the bug is: the build does not fail in > clean anymore, but in the build target instead. For the same reason. > > The "cause" of the underlying problem is the fix for debhelper bug #894573 > (building with -Oline make option). Or at least, if I drop -Oline from the > make build calls, the package builds ok. > > Unfortunately, there is not much history on the reasoning behind adding > -Oline to DH's make build call. Can any of you provide some background > information? > > And: I am aware of the real underlying cause might possibly being a > dependency flaw in nx-libs's highly complicated Makefile target stack. > However, I spent two days now cleaning that up but to no avail. > > I'd be happy to get some clue from any of you. I also Cc: one of our other > upstream devs to follow our discussion here. If any of you dislikes being > Cc:ed directly in this thread, please let me know. All -Oline does is ensure that the output from the parallel commands doesn't get mixed up: -O[type], --output-sync[=type] When running multiple jobs in parallel with -j, ensure the output of each job is collected together rather than interspersed with output from other jobs. If type is not specified or is target the output from the entire recipe for each target is grouped together. If type is line the output from each command line within a recipe is grouped together. If type is recurse output from an entire recursive make is grouped together. If type is none output synchronization is disabled. It should therefore be merely a cosmetic change so reading the build logs is easier. However, this will of course slightly affect timings, and potentially briefly block make processes from running whilst their output buffer is full, so if you do have missing dependencies, the change in timing could be enough to reveal the bug; the fact that it used to work is merely a coincidence, and there's no guarantee it would have continued to do so on different systems. Regards, James
Bug#887315: libgc FTBFS on armel: missing symbol AO_locks
On Sun, Jan 14, 2018 at 11:20:49PM +0200, Adrian Bunk wrote: > Source: libgc > Version: 1:7.4.2-8.1 > Severity: serious > > https://buildd.debian.org/status/fetch.php?pkg=libgc&arch=armel&ver=1%3A7.4.2-8.1&stamp=1515764936&raw=0 > > ... >dh_makeshlibs -a > dh_makeshlibs: Compatibility levels before 9 are deprecated (level 7 in use) > dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols > file: see diff output below > dpkg-gensymbols: warning: no debian/symbols file used as basis for generating > debian/libgc1c2/DEBIAN/symbols > --- new_symbol_file (libgc1c2_1:7.4.2-8.1_armel) > +++ dpkg-gensymbolsCP1Zv9 2018-01-12 13:48:50.806274887 + > @@ -1,7 +1,7 @@ > libgc.so.1 libgc1c2 #MINVER# > (arch=armel)AO_compare_double_and_swap_double_emulation@Base 1:7.4.2 > (arch=armel)AO_fetch_compare_and_swap_emulation@Base 1:7.4.2 > - (arch=armel)AO_locks@Base 1:7.4.2 > +#MISSING: 1:7.4.2-8.1# (arch=armel)AO_locks@Base 1:7.4.2 > (arch=armel)AO_pause@Base 1:7.4.2 > (arch=armel)AO_pt_lock@Base 1:7.4.2 > (arch=armel)AO_store_full_emulation@Base 1:7.4.2 > dh_makeshlibs: failing due to earlier errors > debian/rules:11: recipe for target 'binary-arch' failed > make: *** [binary-arch] Error 2 > > > This might be caused by the recent armv4t -> armv5te armel > baseline change. > > I am completely lost regarding what is going on here, > starting with the fact that this looks a Libatomic-ops symbol? This one turned out to be pretty easy; libatomic-ops 7.6.0 made AO_locks static and therefore a local symbol; from the upstream changelog: > == [7.6.0] 2017-05-19 == > [...] > * Hide AO_locks symbol Thus the symbol should be dropped from the symbols file in libgc, which shouldn't cause any problems, since it was an implementation detail that was only ever exported on armel so nobody should be using it (but of course, when has that stopped anyone...). Regards, James
Bug#895540: nx-libs: FTBFS with parallel > 1 due to errors cleaning
Source: nx-libs Version: 3.5.99.16-1 Severity: serious Hi, Currently, nx-libs FTBFS (likely only probabilistically) when built with parallel > 1; this occurred on the ia64 buildd lenz[1], but I have reproduced it locally in an amd64 cowbuilder chroot. Please either fix the Makefile dependency issues, or disable parallel cleaning. Regards, James [1] https://buildd.debian.org/status/fetch.php?pkg=nx-libs&arch=ia64&ver=2%3A3.5.99.16-1%2Bb1&stamp=1523508333&raw=0
Bug#893691: sbuild: Missing Depends on lintian after defaults change
Package: sbuild Version: 0.74.0-1 Severity: serious Hi, Now that lintian defaults to enabled in 0.74.0-1, sbuild by default will need lintian installed, but it has no dependency on it, and thus fails with: > Error reading configuration: LINTIAN binary 'lintian' does not exist or is > not executable at /usr/share/perl5/Sbuild/Conf.pm line 76 Please fix this (I don't care if it's Depends or the default) so sbuild isn't broken out of the box. James
Bug#893608: sbuild: Silent arch:all defaults change breaks buildd setups
Package: sbuild Version: 0.74.0-1 Severity: serious [Feel free to downgrade severity, but from my PoV this needs addressing before Buster is released] Hi, In the latest upload, #870263 was fixed (which I support, for what it's worth; any+all builds is the right default for users), meaning that buildd setups now build arch:all packages, which we *have* to work around by setting $build_arch_all=0 in sbuild.conf. Without this, uploads are rejected by the archive (the buildd's signing key does not have upload rights for arch:all packages, the arch:all packages already exist, etc). This is therefore a breaking change, and so deserves at least a mention in the NEWS file. Moreover, having to configure this in sbuild.conf is sub-optimal; ideally, buildd would pass --no-arch-all to sbuild when an arch:any build is requested by wanna-build; as far as I know, the assumption is always that a non-Architecture:all build is arch:any. We probably also don't want lintian run during buildd builds as it fork-bombs on packages like gcc-8-cross-ports (#890873), and there's lintian.debian.org doing that for x86, which is probably good enough, though I suppose in an ideal world it would be run too. Regards, James
Bug#891773: [PATCH] ieee1275: Fix crash in of_path_of_nvme when of_path is empty
On Thu, Mar 01, 2018 at 05:00:28PM +0100, John Paul Adrian Glaubitz wrote: > The of_path_of_nvme function (commit 2391d57, ieee1275: add nvme > support within ofpath) introduced a functional regression: > > On systems which are not based on Open Firmware but have at > least one NVME device, find_obppath will return an empty path > and appending the disk name to of_path will therefore result > in a crash. Thus, when of_path is empty, just return the > disk name in of_path_of_nvme. > > Signed-off-by: John Paul Adrian Glaubitz > --- > grub-core/osdep/linux/ofpath.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/grub-core/osdep/linux/ofpath.c b/grub-core/osdep/linux/ofpath.c > index 1c30e7233..daf0f 100644 > --- a/grub-core/osdep/linux/ofpath.c > +++ b/grub-core/osdep/linux/ofpath.c > @@ -389,8 +389,13 @@ of_path_of_nvme(const char *sys_devname > __attribute__((unused)), > } > >of_path = find_obppath (sysfs_path); > + > + if(of_path) > +strcat (of_path, disk); > + else > +of_path = strdup(disk); > + Whitespace issues aside, should it not be returning NULL if of_path is NULL, like the other users of find_obppath, such as of_path_of_scsi? This should restore the behaviour from before of_path_of_nvme was added, as grub_util_devname_to_ofpath would have previously returned NULL due to the unknown type? James >free (sysfs_path); > - strcat (of_path, disk); >return of_path; > } > > -- > 2.16.2
Bug#853461: jackd2: ftbfs with GCC-7
On Tue, Jan 31, 2017 at 09:32:23AM +, Matthias Klose wrote: > Package: src:jackd2 > Version: 1.9.10+20150825git1ed50c92~dfsg-4 > Severity: normal > Tags: sid buster > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-7 > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The > severity of this report may be raised before the buster release. > There is no need to fix this issue in time for the stretch release. > > The full build log can be found at: > http://people.debian.org/~doko/logs/gcc7-20170126/jackd2_1.9.10+20150825git1ed50c92~dfsg-4_unstable_gcc7.log > The last lines of the build log are at the end of this report. > > To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly, > or install the gcc, g++, gfortran, ... packages from experimental. > > apt-get -t=experimental install g++ > > Common build failures are new warnings resulting in build failures with > -Werror turned on, or new/dropped symbols in Debian symbols files. > For other C/C++ related build failures see the porting guide at > http://gcc.gnu.org/gcc-7/porting_to.html This has been fixed upstream for over half a year, with no commits in the packaging VCS since 2017-03-29, other than for the mass migration to Salsa. Please upload a fixed version, either by adding the upstream patch, or uploading a newer upstream version. Regards, James
Bug#889829: ghc: error while loading shared libraries: libHShaskeline-0.7.3.0-ghc8.0.2.so
On 8 Feb 2018, at 19:46, Holger Levsen wrote: > > On Thu, Feb 08, 2018 at 03:04:22PM +0100, Petter Reinholdtsen wrote: >> [Clint Adams] >>> objdump -p /usr/lib/ghc/bin/ghc-pkg | grep RUNPATH > > $ objdump -p /usr/lib/ghc/bin/ghc-pkg | grep RUNPATH > RUNPATH > > $ORIGIN/../terminfo-0.4.0.2:$ORIGIN/../ghc-boot-8.0.2:$ORIGIN/../ghc-boot-th-8.0.2:$ORIGIN/../Cabal-1.24.2.0:$ORIGIN/../process-1.4.3.0:$ORIGIN/../pretty-1.1.3.3:$ORIGIN/../directory-1.3.0.0:$ORIGIN/../unix-2.7.2.1:$ORIGIN/../time-1.6.0.1:$ORIGIN/../filepath-1.4.1.1:$ORIGIN/../binary-0.8.3.0:$ORIGIN/../containers-0.5.7.1:$ORIGIN/../bytestring-0.10.8.1:$ORIGIN/../deepseq-1.4.2.0:$ORIGIN/../array-0.5.1.1:$ORIGIN/../base-4.9.1.0:$ORIGIN/../integer-gmp-1.0.0.1:$ORIGIN/../ghc-prim-0.5.0.0:$ORIGIN/../rts > > is what I get. Do you need any more info? I still see this... Well that's correct; you can see $ORIGIN/../terminfo-0.4.0.2 in there which is where it should be getting libHSterminfo-0.4.0.2-ghc8.0.2.so, but for some reason your ld.so is not looking at RUNPATH; once it fails to find it on the system search path it's supposed to then print something like: 15470: search path=/usr/lib/ghc/bin/../terminfo-0.4.0.2:/usr/lib/ghc/bin/../ghc-boot-8.0.2:/usr/lib/ghc/bin/../ghc-boot-th-8.0.2:/usr/lib/ghc/bin/../Cabal-1.24.2.0:/usr/lib/ghc/bin/../process-1.4.3.0:/usr/lib/ghc/bin/../pretty-1.1.3.3:/usr/lib/ghc/bin/../directory-1.3.0.0:/usr/lib/ghc/bin/../unix-2.7.2.1:/usr/lib/ghc/bin/../time-1.6.0.1:/usr/lib/ghc/bin/../filepath-1.4.1.1:/usr/lib/ghc/bin/../binary-0.8.3.0:/usr/lib/ghc/bin/../containers-0.5.7.1:/usr/lib/ghc/bin/../bytestring-0.10.8.1:/usr/lib/ghc/bin/../deepseq-1.4.2.0:/usr/lib/ghc/bin/../array-0.5.1.1:/usr/lib/ghc/bin/../base-4.9.1.0:/usr/lib/ghc/bin/../integer-gmp-1.0.0.1:/usr/lib/ghc/bin/../ghc-prim-0.5.0.0:/usr/lib/ghc/bin/../rts/tls/x86_64/x86_64:/usr/lib/ghc/bin/../rts/tls/x86_64:/usr/lib/ghc/bin/../rts/tls/x86_64:/usr/lib/ghc/bin/../rts/tls:/usr/lib/ghc/bin/../rts/x86_64/x86_64:/usr/lib/ghc/bin/../rts/x86_64:/usr/lib/ghc/bin/../rts/x86_64:/usr/lib/ghc/bin/../rts (RUNPATH from file /usr/lib/ghc/bin/ghc-pkg) What version of glibc do you have? Have you got any interesting (to ld.so) environment variables exported or configuration files changed? Regards, James
Bug#889829: ghc: error while loading shared libraries: libHShaskeline-0.7.3.0-ghc8.0.2.so
Control: tags -1 moreinfo On Wed, Feb 07, 2018 at 05:02:09PM +0100, Holger Levsen wrote: > Package: ghc > Version: 8.0.2-11 > Severity: serious > > Selecting previously unselected package ghc. > Preparing to unpack .../ghc_8.0.2-11_amd64.deb ... > Unpacking ghc (8.0.2-11) ... > Setting up libbsd-dev:amd64 (0.8.7-1) ... > Setting up ghc (8.0.2-11) ... > /usr/lib/ghc/bin/ghc: error while loading shared libraries: > libHShaskeline-0.7.3.0-ghc8.0.2.so: cannot open shared object file: No > such file or directory > update-alternatives: using /usr/bin/ghc to provide > /usr/bin/haskell-compiler (haskell-compiler) in auto mode > /usr/lib/ghc/bin/ghc-pkg: error while loading shared libraries: > libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No > such file or directory > dpkg: error processing package ghc (--configure): > installed ghc package post-installation script subprocess returned > error exit status 127 > Processing triggers for man-db (2.8.0-2) ... > Errors were encountered while processing: > ghc > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > This is from a sid schroot which I first upgraded as usual, which failed > like the above, so I removed ghc and tried to install it again, which > then produced the output above. Hi, I just upgraded my sid system without issue. I also tried installing ghc in an up-to-date cowbuilder chroot and it all worked. Can you run `/usr/lib/ghc/bin/ghc-pkg --version` successfully? Please try running with LD_DEBUG=libs,files and post the output. Regards, James
Bug#880332: libgudev: FTBFS: Test failures
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=792845 Control: tag -1 upstream patch On Mon, Oct 30, 2017 at 09:09:12PM +0100, Lucas Nussbaum wrote: > Source: libgudev > Version: 232-1 > Severity: serious > Tags: buster sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20171030 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): > > gtkdoc-mkhtml 2>&1 --help | grep >/dev/null "\-\-path"; \ > > if test "$?" = "0"; then \ > > mkhtml_options="$mkhtml_options --path=\"/<>/docs\""; \ > > fi; \ > > cd html && gtkdoc-mkhtml $mkhtml_options --path=/<>/docs > > --path=/<>/docs gudev ../gudev-docs.xml > > gtkdoc-fixxref --module=gudev --module-dir=html > > --html-dir=/usr/share/gtk-doc/html >/dev/null 2>&1 > > touch html-build.stamp > > Making all in tests > > gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 > > -I/usr/include/umockdev-1.0 -I/usr/include/glib-2.0 > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I.. -g -O2 > > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -c -o > > test_enumerator_filter-test-enumerator-filter.o `test -f > > 'test-enumerator-filter.c' || echo './'`test-enumerator-filter.c > > /bin/bash ../libtool --tag=CC --mode=link gcc > > -I/usr/include/umockdev-1.0 -I/usr/include/glib-2.0 > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I.. -g -O2 > > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wl,-z,relro -o test-enumerator-filter > > test_enumerator_filter-test-enumerator-filter.o -lumockdev -lgobject-2.0 > > -lglib-2.0 ../libgudev-1.0.la > > libtool: link: gcc -I/usr/include/umockdev-1.0 -I/usr/include/glib-2.0 > > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I.. -g -O2 > > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wl,-z -Wl,relro -o .libs/test-enumerator-filter > > test_enumerator_filter-test-enumerator-filter.o -lumockdev -lgobject-2.0 > > -lglib-2.0 ../.libs/libgudev-1.0.so -pthread > > TEST: test-enumerator-filter... (pid=87060) > > ** > > ERROR:test-enumerator-filter.c:77:main: assertion failed: > > (umockdev_in_mock_environment ()) > > FAIL: test-enumerator-filter > > Makefile:646: recipe for target 'test' failed > > The full build log is available from: >http://aws-logs.debian.net/2017/10/30/libgudev_232-1_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. This is caused by the newer umockdev; details and a proposed patch are in the upstream bug report linked above. Regards, James
Bug#886119: e2fsprogs: FTBFS on big-endian architectures
Source: e2fsprogs Version: 1.43.8-1 Severity: serious Tags: upstream patch Hi, The latest upload of e2fsprogs FTBFS on all big-endian architectures due to two problems in swapfs.c: > ../../../../lib/ext2fs/swapfs.c: In function 'ext2fs_swap_super': > ../../../../lib/ext2fs/swapfs.c:132:2: warning: implicit declaration of > function 'EXT2FS_BUILD_BUG_ON'; did you mean 'EXT2FS_NUM_B2C'? > [-Wimplicit-function-declaration] > EXT2FS_BUILD_BUG_ON(sizeof(sb->s_reserved) != 98 * sizeof(__le32)); > ^~~ > EXT2FS_NUM_B2C > ../../../../lib/ext2fs/swapfs.c: In function 'ext2fs_swap_inode_full': > ../../../../lib/ext2fs/swapfs.c:361:29: error: 'ext2_inode_large' undeclared > (first use in this function) > EXT2FS_BUILD_BUG_ON(sizeof(ext2_inode_large) != 160); > ^~~~ > ../../../../lib/ext2fs/swapfs.c:361:29: note: each undeclared identifier is > reported only once for each function it appears in > Makefile:657: recipe for target 'swapfs.o' failed Please apply the attached patch to include ext2fsP.h (for EXT2FS_BUILD_BUG_ON) and add the missing "struct" keyword before ext2_inode_large, which has been tested on sparc64. Regards, James --- a/lib/ext2fs/swapfs.c +++ b/lib/ext2fs/swapfs.c @@ -19,6 +19,7 @@ #include "ext2_fs.h" #include "ext2fs.h" +#include "ext2fsP.h" #include #ifdef WORDS_BIGENDIAN @@ -358,7 +359,7 @@ void ext2fs_swap_inode_full(ext2_filsys if (inode_includes(inode_size, i_projid)) t->i_projid = ext2fs_swab16(f->i_projid); /* catch new static fields added after i_projid */ - EXT2FS_BUILD_BUG_ON(sizeof(ext2_inode_large) != 160); + EXT2FS_BUILD_BUG_ON(sizeof(struct ext2_inode_large) != 160); i = sizeof(struct ext2_inode) + extra_isize + sizeof(__u32); if (bufsize < (int) i)
Bug#884680: xul-ext-quotecolors: Please depend on thunderbird | icedove
Package: xul-ext-quotecolors Version: 0.3-4 Severity: serious Hi, Icedove has been re-rebranded to Thunderbird, but xul-ext-quotecolors depends on icedove | iceape. Please fix this to depend on thunderbird (perhaps | icedove) so the extension can be installed again. Regards, James
Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
On Fri, Dec 08, 2017 at 09:49:05AM +0100, Andreas Tille wrote: > Hi Flavien, > > I have put the porter lists of the affected architectures in CC whether > there is somebody who has a hint for a better solution than removing > these architectures from the supported architectures. This kind of > "random failure"[1] is quite hard to debug for somebody who is not > familiar for the said architectures. f4 is (long, long, long) -> long, and so the generated Qt metacall magic wrapper around f4 treats its arguments as an array of long*, dereferences them, passes them to f4 and stores the return value for the caller. However, camp's own Value class only has camp::intType; it has no type for long or long long. This means that valueToVariant always gives a QVariant storing an int, so QtFunction::execute invokes the meta method with QGenericArgument's pointing to ints. Therefore, when the metacall wrapper reads them, it reads too much, and gets 32 bits of garbage after them in memory. Normally in C arguments are promoted automatically, but because of all these levels of indirection it has to be done manually (as you can see for example with the double tests, which must use the double literal 1. rather than the int literal 1). Now, as to why it only affects 64-bit big-endian. Obviously, 32-bit is unaffected, as sizeof(int) == sizeof(long) there. On 64-bit little-endian, reading too much data puts the garbage in the *higher* bits in the registers; if you then add values with garbage in the higher half, the lower half will remain correct, and it gets stored as a 64-bit value. Then eventually it gets read as an int (variantType sees that the function returns a QMetaType::Long, which is mapped to a return QVariant::Int), so the higher 32 bits get dropped, and all appears fine (despite the horrendous out-of-bounds memory accesses). On 64-bit big-endian systems, though, it's not quite so forgiving. When it reads the 32-bit value as a 64-bit value, the endianness means that the 32 bits of garbage are the *lower* 32 bits in the registers, and so when adding three numbers together, the sum of these garbage halves could overflow (up to twice) into the higher 32 bits, which store the desired values, causing the upper half to non-deterministically be 20, 21 or 22. This gets stored as a 64-bit quantity again, and then later re-read as a 32-bit quantity, and again due to the endianness it only reads what was the higher half in the register, i.e. either 20, 21 or 22. I don't have a patch, because fixing this requires a fairly involved trawl through the source. I haven't tried using it, but valgrind might catch these out-of-bounds reads regardless of the system's endianness. TL;DR camp needs to stop treating longs like ints. Regards, James
Bug#878899: dpkg-buildpackage no longer calls build, only binary
On Tue, Oct 17, 2017 at 06:03:20PM +0300, Adrian Bunk wrote:
> Package: dpkg-dev
> Version: 1.19.0.1
> Severity: serious
>
> 14:39 < _rene_> hmm. dpkg-dev 1.19.0.1 broken for anyone else? looks like it
> doesn't call build(-arch,indep) anymore at
> dpkg-buildpackage -b, but just binary?
>
> I seen the same debugging a FTBFS.
I believe this is caused by [0]:
[16:26:57] my understanding is that rules_requires_root is going
to be returning 0 for the build-* targets
[16:27:06] jrtc27: clearly the default tries to be binary-targets
which would preserve the original behaviour
[16:27:19] since $rules_requires_root{'binary-targets'} will be
set, but $target_legacy_root{'build'} will be false
[16:27:33] aha
[16:28:17] so I think the two instances of
rules_requires_root($buildtarget) should be rules_requires_root($binarytarget)
[16:28:33] jrtc27: thank you. so it should say "return if not
any_target_requires_root;" in build_target_fallback
[16:28:43] or that
[16:28:53] rules_requires_root('build') is correct to return 0
[16:28:58] build doesn't need root :P
[16:29:08] no package building today I guess
Regards,
James
[0]
https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=fca1bfe8406898105d1d724fb808f0cbcf985ae4
Bug#876848: haskell-cryptonite FTBFS on non-x86: error: redefinition of 'store_le32'
Control: tags -1 patch
On Tue, Sep 26, 2017 at 02:07:07PM +0300, Adrian Bunk wrote:
> Source: haskell-cryptonite
> Version: 0.23-1
> Severity: serious
>
> https://buildd.debian.org/status/package.php?p=haskell-cryptonite&suite=sid
>
> ...
> [119 of 119] Compiling Crypto.Cipher.AES ( Crypto/Cipher/AES.hs,
> dist-ghc/build/Crypto/Cipher/AES.p_o )
>
> In file included from cbits/aes/block128.h:35:0: error:
> 0,
> from cbits/cryptonite_aes.h:36,
> from cbits/aes/generic.c:35:
>
> cbits/cryptonite_align.h:160:20: error:
> error: redefinition of 'store_le32'
> static inline void store_le32(uint8_t *dst, const uint32_t v)
> ^~
>
> cbits/cryptonite_align.h:135:20: error:
> note: previous definition of 'store_le32' was here
> static inline void store_le32(uint8_t *p, uint32_t val)
> ^~
>
> cbits/cryptonite_align.h:169:20: error:
> error: redefinition of 'store_be32'
> static inline void store_be32(uint8_t *dst, const uint32_t v)
> ^~
>
> cbits/cryptonite_align.h:104:20: error:
> note: previous definition of 'store_be32' was here
> static inline void store_be32(uint8_t *p, uint32_t val)
> ^~
>
> cbits/cryptonite_align.h:178:20: error:
> error: redefinition of 'store_le64'
> static inline void store_le64(uint8_t *dst, const uint64_t v)
> ^~
>
> cbits/cryptonite_align.h:143:20: error:
> note: previous definition of 'store_le64' was here
> static inline void store_le64(uint8_t *p, uint64_t val)
> ^~
>
> cbits/cryptonite_align.h:188:20: error:
> error: redefinition of 'store_be64'
> static inline void store_be64(uint8_t *dst, const uint64_t v)
> ^~
>
> cbits/cryptonite_align.h:112:20: error:
> note: previous definition of 'store_be64' was here
> static inline void store_be64(uint8_t *p, uint64_t val)
> ^~
> `gcc' failed in phase `C Compiler'. (Exit code: 1)
> /usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc-stamp'
> failed
> make: *** [build-ghc-stamp] Error 1
>
>
> debian/patches/more-alignment.patch and upstream seem to add
> the same code with different formatting to cryptonite_align.h
This is because more-alignment.patch included changes to
cryptonite_align.h which were in 0.22, so after the upload of 0.23 these
duplicates appeared. The fix is to simply drop those hunks from
more-alignment.patch, as in the attached debdiff.
Regards,
James
diff -Nru haskell-cryptonite-0.23/debian/patches/more-alignment.patch
haskell-cryptonite-0.23/debian/patches/more-alignment.patch
--- haskell-cryptonite-0.23/debian/patches/more-alignment.patch 2017-09-16
21:10:13.0 +0100
+++ haskell-cryptonite-0.23/debian/patches/more-alignment.patch 2017-10-16
11:56:40.0 +0100
@@ -3,119 +3,6 @@
Forwarded: https://github.com/haskell-crypto/cryptonite/pull/175
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
a/cbits/cryptonite_align.h
-+++ b/cbits/cryptonite_align.h
-@@ -34,9 +34,24 @@
- #define need_alignment(p,n) IS_ALIGNED(p,n)
- #endif
-
-+static inline uint32_t load_be32_aligned(const uint8_t *p)
-+{
-+ return be32_to_cpu(*((uint32_t *) p));
-+}
-+
-+static inline uint64_t load_be64_aligned(const uint8_t *p)
-+{
-+ return be64_to_cpu(*((uint64_t *) p));
-+}
-+
-+static inline uint64_t load_le64_aligned(const uint8_t *p)
-+{
-+ return le64_to_cpu(*((uint64_t *) p));
-+}
-+
- static inline uint32_t load_le32_aligned(const uint8_t *p)
- {
-- return le32_to_cpu(*((uint32_t *) p));
-+ return le32_to_cpu(*((uint32_t *) p));
- }
-
- static inline void store_le32_aligned(uint8_t *dst, const uint32_t v)
-@@ -60,12 +75,83 @@ static inline void store_be64_aligned(ui
- }
-
- #ifdef UNALIGNED_ACCESS_OK
--#define load_le32(a) load_le32_aligned(a)
-+
-+#define load_be32(p) load_be32_aligned(p)
-+#define load_be64(p) load_be64_aligned(p)
-+
-+#define store_be32(p, v) store_be32_aligned((p), (v))
-+#define store_be64(p, v) store_be64_aligned((p), (v))
-+
-+#define load_le32(p) load_le32_aligned(p)
-+#define load_le64(p) load_le64_aligned(p)
-+
-+#define store_le32(p, v) store_le32_aligned((p), (v))
-+#define store_le64(p, v) store_le64_aligned((p), (v))
-+
- #else
-+
-+static inline uint32_t load_be32(const uint8_t *p)
-+{
-+ return ((uint32_t)p[0] << 24) | ((uint32_t)p[1] << 16) |
((uint32_t)p[2] << 8) | ((uint32_t)p[3]);
-+}
-+
-+static inline uint64_t load_be64(const uint8_t *p)
-+{
-+ return ((uint64_t)p[0] << 56) | ((uint64_t)p[1] << 48) |
((uint64_t)p[2] << 40) | ((uint64_t)p[3] << 32) |
-+ ((uint64_t)p[4] << 24) | ((uint64_t)p[5] << 16) |
((uint64_t)p[6] << 8) | ((uint64_t)p[7]);
-+}
-+
-+static inline void store_be32(uint8_t *p, uint32_t val
Bug#878322: ax25-tools: Various tools segfault when run
Package: ax25-tools Version: 0.0.10-rc4-1 Severity: serious Tags: upstream patch Hi, As discussed on IRC, various tools in ax25-tools segfault when run. For example: > $ /usr/sbin/kissnetd -p 5 > kissnetd V 1.5 by Frederic RIBLE F1OAT - ATEPRA FPAC/Linux Project > [1]22672 segmentation fault /usr/sbin/kissnetd -p 5 This because the prototype for ptsname is not available, so it implicitly returns an int, which gets cast back to a pointer, truncating the return value. The attached patch fixes this by defining the relevant feature macros to their required values so ptsname's prototype is declared. Regards, James --- a/kiss/kissattach.c +++ b/kiss/kissattach.c @@ -1,5 +1,6 @@ +#define _DEFAULT_SOURCE +#define _XOPEN_SOURCE 500 #include -#define __USE_XOPEN #include #include #include --- a/kiss/kissnetd.c +++ b/kiss/kissnetd.c @@ -9,8 +9,9 @@ * F1OAT 960804 - Frederic RIBLE */ +#define _DEFAULT_SOURCE +#define _XOPEN_SOURCE 500 #include -#define __USE_XOPEN #include #include #include --- a/kiss/mkiss.c +++ b/kiss/mkiss.c @@ -37,8 +37,9 @@ * 1.08 xx/xx/99 Tom Mazouch - Adjustable poll interval */ +#define _DEFAULT_SOURCE +#define _XOPEN_SOURCE 500 #include -#define __USE_XOPEN #include #include #include --- a/kiss/net2kiss.c +++ b/kiss/net2kiss.c @@ -30,8 +30,9 @@ /*/ +#define _DEFAULT_SOURCE +#define _XOPEN_SOURCE 500 #include -#define __USE_XOPEN #include #include #include --- a/6pack/m6pack.c +++ b/6pack/m6pack.c @@ -33,8 +33,9 @@ * */ +#define _DEFAULT_SOURCE +#define _XOPEN_SOURCE 500 #include -#define __USE_XOPEN #include #include #include
Bug#877419: How to deal with pandas
On 4 Oct 2017, at 14:43, Anton Gladky wrote: > 2017-10-04 15:13 GMT+02:00 Andreas Tille : >> Hi, >> >> to deal with #877419 I'd suggest the following approach: >> >> 1. Ignore test suite errors on those architectures that are >> known to fail (see attached patch, NOT TESTED, please review) >> 2. Drop severity of the bug from serious to important >> 3. Fix bug #877419 later but let pandas and its dependencies >> (statsmodels and lots of others) migrate to testing >> >> If you think this is a sensible strategy and you want me to upload >> pandas with this patch I would also do >> >> 4. Move pandas to Debian Science as discussed before >> >> Kind regards >> >>Andreas. > > Hi Andreas, > > one more option is to drop pandas on those archs (filing > RM bug) and fill the list of supported archs explicitly > in d/control. Please, no, don't put a specific list of architectures in d/control. The inability to build pandas on those architectures is a bug, whereas explicit architecture lists in d/control should only be used if the package fundamentally cannot work on others. Otherwise these failures disappear on buildd.d.o and porters are unaware of them. You can still file an RM for the currently-broken architectures if you really need the new version to migrate to testing, and then they will reappear once the build starts succeeding again. Regards, James
Bug#875556: haskell-text-show: FTBFS in unstable due to overlapping instances
Source: haskell-text-show Version: 3.4.1.1-1 Severity: serious Hi, haskell-text-show now FTBFS in unstable[0] due to overlapping instances; the relevant part of the build log is given below: > tests/Spec/Data/List/NonEmptySpec.hs:27:32: error: > * Overlapping instances for Data.Functor.Classes.Show1 NonEmpty > arising from a use of `prop_matchesTextShow1' > Matching instances: > instance Data.Functor.Classes.Show1 NonEmpty > -- Defined in `Data.Orphans' > instance Data.Functor.Classes.Show1 NonEmpty > -- Defined at tests/Instances/Data/List/NonEmpty.hs:20:3 > * In the second argument of `prop', namely > `(prop_matchesTextShow1 :: Int -> NonEmpty Int -> Bool)' > In the second argument of `($)', namely > `prop >"TextShow1 instance" >(prop_matchesTextShow1 :: Int -> NonEmpty Int -> Bool)' > In the expression: > parallel . describe "NonEmpty Int" > $ prop > "TextShow1 instance" > (prop_matchesTextShow1 :: Int -> NonEmpty Int -> Bool) Regards, James [0] https://buildd.debian.org/status/fetch.php?pkg=haskell-text-show&arch=sparc64&ver=3.4.1.1-1%2Bb1&stamp=1505187046&raw=0
Bug#874805: haskell-vector: FTBFS due to ambiguous occurrences
Source: haskell-vector Version: 0.11.0.0-8 Severity: serious Hi, haskell-vector now FTBFS in unstable[0]; the relevant tail of the log is given below: > Data/Vector.hs:223:14: error: > Ambiguous occurrence `fromList' > It could refer to either `Exts.fromList', > imported from `Data.Primitive.Array' at > Data/Vector.hs:164:1-37 > (and originally defined in `GHC.Exts') > or `Data.Vector.fromList', defined at > Data/Vector.hs:1528:1 > > Data/Vector.hs:224:15: error: > Ambiguous occurrence `fromListN' > It could refer to either `Exts.fromListN', > imported from `Data.Primitive.Array' at > Data/Vector.hs:164:1-37 > (and originally defined in `GHC.Exts') > or `Data.Vector.fromListN', defined at > Data/Vector.hs:1537:1 > > Data/Vector.hs:344:19: error: > Ambiguous occurrence `fromList' > It could refer to either `Exts.fromList', > imported from `Data.Primitive.Array' at > Data/Vector.hs:164:1-37 > (and originally defined in `GHC.Exts') > or `Data.Vector.fromList', defined at > Data/Vector.hs:1528:1 > /usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc-stamp' > failed Regards, James [0] https://buildd.debian.org/status/fetch.php?pkg=haskell-vector&arch=sparc64&ver=0.11.0.0-8%2Bb1&stamp=1504966021&raw=0
Bug#873508: parsing horst source code fails on s390x and ppc64el
On 28 Aug 2017, at 20:23, Uwe Kleine-König wrote: > On Mon, Aug 28, 2017 at 03:10:10PM -0400, Antoine Beaupré wrote: >> On 2017-08-28 20:53:02, Uwe Kleine-König wrote: >>> On 08/28/2017 04:32 PM, Antoine Beaupré wrote: >>>> Control: severity 873508 serious >>>> Control: affects 873508 horst >>>> >>>> On 2017-08-28 15:22:20, James Clarke wrote: >>>>> As discussed on IRC, ppc64 and sparc64 are also affected; while they are >>>>> not release architectures and are thus less important, it would make >>>>> sense to fix those (and check any other Debian architectures) at the >>>>> same time. >>>> >>>> Also discussed on IRC is the above change in severity to make the bug >>>> RC. >>> >>> As I didn't follow that irc discussion and fail to see why this bug >>> should be severity serious. Can you please repeat the justification >>> here? I would have picked "normal". >> >> I believe the reason is that it doesn't actually work on two supported >> architectures. > > That would in my eyes still be "important". Looking at the definitions > on https://www.debian.org/Bugs/Developer#severities there is: > > - serious > is a severe violation of Debian policy (roughly, it violates a "must" > or "required" directive), or, in the package maintainer's or release > manager's opinion, makes the package unsuitable for release. > - important > a bug which has a major effect on the usability of a package, without > rendering it completely unusable to everyone. > > IMHO important is an exact match here. It's basically unusable on those arches except for trivial code. Even headers like stdio.h pull in stubs.h, and many other things will likely break due to not having the right defines. Shipping this as-is is just asking for trouble. IMO the only way to make this non-RC would be to RM on the affected arches and make test suite failures fatal so we don't get broken binaries again. James
Bug#873508: parsing horst source code fails on s390x and ppc64el
On 28 Aug 2017, at 20:10, Antoine Beaupré wrote: > On 2017-08-28 20:53:02, Uwe Kleine-König wrote: >> Hello, >> >> On 08/28/2017 04:32 PM, Antoine Beaupré wrote: >>> Control: severity 873508 serious >>> Control: affects 873508 horst >>> >>> On 2017-08-28 15:22:20, James Clarke wrote: >>>> As discussed on IRC, ppc64 and sparc64 are also affected; while they are >>>> not release architectures and are thus less important, it would make >>>> sense to fix those (and check any other Debian architectures) at the >>>> same time. >>> >>> Also discussed on IRC is the above change in severity to make the bug >>> RC. >> >> As I didn't follow that irc discussion and fail to see why this bug >> should be severity serious. Can you please repeat the justification >> here? I would have picked "normal". > > I believe the reason is that it doesn't actually work on two supported > architectures. Specifically that it's built for the architectures but can't actually be used. Looking at the build logs, some of the tests run as part of the test suite hit this error, but the upstream test harness always exits with code 0[0] so it's not fatal. Boo. James [0] https://anonscm.debian.org/cgit/collab-maint/sparse.git/tree/validation/test-suite#n251
Bug#872464: zimlib: FTBFS all over the place due to symbols diff
Source: zimlib Version: 2.0.0-1 Severity: serious Hi, Once again zimlib FTBFS due to symbols file diffs. Please at least *try* to get a working symbols file; you can at least build amd64 locally, and we have porterboxen for a reason... James
Bug#870783: mptp: FTBFS with lex_utree.l:22:25: fatal error: parse_utree.h: No such file or directory
On 5 Aug 2017, at 01:04, Andreas Tille wrote: > On Sat, Aug 05, 2017 at 12:09:30AM +0100, James Clarke wrote: >> Source: mptp >> Version: 0.2.2-1 >> Severity: serious >> >> Hi, >> mptp FTBFS when built with sufficient levels of parallelism (15 is >> enough); the relevant tail of the log is given below: >>> ... >>> make[3]: *** Waiting for unfinished jobs >>> lex_rtree.l:22:25: fatal error: parse_rtree.h: No such file or directory >>> #include "parse_rtree.h" >>> ^ >>> compilation terminated. >>> Makefile:473: recipe for target 'lex_rtree.o' failed > > It looks to me as if --no-parallel would be a sensible solution for this > problem, right? Yes, that should work (though you only need to do it for dh_auto_build; everything else can still be parallelised). It would be nice to be able to fix the generated Makefile, but the package is small enough that it won't make much difference, and I fear that would be a pain given it's all generated by automake. In fact, there's an open bug for this[0] which even has a comment from you from 2009 :) Regards, James [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541713
Bug#870783: mptp: FTBFS with lex_utree.l:22:25: fatal error: parse_utree.h: No such file or directory
Source: mptp Version: 0.2.2-1 Severity: serious Hi, mptp FTBFS when built with sufficient levels of parallelism (15 is enough); the relevant tail of the log is given below: > gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -I. -O3 > -mtune=native -Wall -Wsign-compare -g -lgsl -lgslcblas -lm -g -O2 > -fdebug-prefix-map=/build/mptp-0.2.2=. -fstack-protector-strong -Wformat > -Werror=format-security -c -o lex_utree.o lex_utree.c > gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -I. -O3 > -mtune=native -Wall -Wsign-compare -g -lgsl -lgslcblas -lm -g -O2 > -fdebug-prefix-map=/build/mptp-0.2.2=. -fstack-protector-strong -Wformat > -Werror=format-security -c -o lex_rtree.o lex_rtree.c > lex_utree.l:22:25: fatal error: parse_utree.h: No such file or directory > #include "parse_utree.h" > ^ > compilation terminated. > Makefile:473: recipe for target 'lex_utree.o' failed > make[3]: *** [lex_utree.o] Error 1 > make[3]: *** Waiting for unfinished jobs > lex_rtree.l:22:25: fatal error: parse_rtree.h: No such file or directory > #include "parse_rtree.h" > ^ > compilation terminated. > Makefile:473: recipe for target 'lex_rtree.o' failed > make[3]: *** [lex_rtree.o] Error 1 > updating parse_utree.h > updating parse_rtree.h Regards, James
Bug#866578: haskell-yesod-bin: FTBFS due to missing yesod-ghc-wrapper
Source: haskell-yesod-bin Version: 1.5.2.3-1 Severity: serious Hi, The latest upload of haskell-yesod-bin FTBFS everywhere: > dh_install -pyesod dist-ghc/build/yesod-ghc-wrapper/yesod-ghc-wrapper usr/bin > dh_install: Cannot find (any matches for) > "dist-ghc/build/yesod-ghc-wrapper/yesod-ghc-wrapper" (tried in ., debian/tmp) > > dh_install: yesod missing files: > dist-ghc/build/yesod-ghc-wrapper/yesod-ghc-wrapper > dh_install: missing files, aborting > /usr/share/cdbs/1/class/hlibrary.mk:245: recipe for target 'install/yesod' > failed > make: *** [install/yesod] Error 25 > dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit > status 2 Regards, James
Bug#865711: haskell-yaml: FTBFS everywhere (except all)
Source: haskell-yaml Version: 0.8.23-2 Severity: serious Hi, haskell-yaml FTBFS on every architecture (except all) due to testsuite failures: > Failures: > > test/Data/YamlSpec.hs:440: > 1) Data.Yaml.Data.Yaml encode invalid numbers >expected: ".\n" > but got: ".\n...\n" > > test/Data/YamlSpec.hs:458: > 2) Data.Yaml.numbers integers have no decimals >expected: "1\n" > but got: "1\n...\n" > > Randomized with seed 1628861893 Regards, James
Bug#865706: haskell-http-link-header: FTBFS everywhere (except all)
Source: haskell-http-link-header Version: 1.0.3-1 Severity: serious Hi, haskell-http-link-header FTBFS on every architecture (other than all): > Network.HTTP.Link > writeLinkHeader tests: : commitBuffer: invalid argument (invalid > character) > Test suite tests: FAIL Regards, James
Bug#865062: haskell-sockets: FTBFS due to missing B-D on libghc-sha-dev/prof
Source: haskell-websockets Version: 0.9.8.2-1 Severity: serious Hi, It seems the B-D on libghc-sha-dev got dropped when importing the new upstream version; it's still needed: > hlibrary.setup: Encountered missing dependencies: > SHA >=1.5 && <1.7 > /usr/share/cdbs/1/class/hlibrary.mk:142: recipe for target > 'configure-ghc-stamp' failed Regards, James
Bug#863493: symfony: diff for NMU version 2.8.7+dfsg-1.3
Dear maintainer,
I've prepared an NMU for symfony (versioned as 2.8.7+dfsg-1.3) and
uploaded it to unstable. The diff is attached to this message.
Regards,
James
diff -Nru symfony-2.8.7+dfsg/debian/changelog symfony-2.8.7+dfsg/debian/changelog
--- symfony-2.8.7+dfsg/debian/changelog 2017-01-29 16:05:28.0 +
+++ symfony-2.8.7+dfsg/debian/changelog 2017-05-27 20:39:09.0 +0100
@@ -1,3 +1,13 @@
+symfony (2.8.7+dfsg-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport additional upstream patches needed after PHP 7.0.18 upload
+(Closes: #863493):
+- [VarDumper] Relax tests to adapt for php 7.1rc4
+- [VarDumper] Relax line number for CliDumperTest
+
+ -- James Clarke Sat, 27 May 2017 20:39:09 +0100
+
symfony (2.8.7+dfsg-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru symfony-2.8.7+dfsg/debian/patches/series symfony-2.8.7+dfsg/debian/patches/series
--- symfony-2.8.7+dfsg/debian/patches/series 2017-01-29 16:05:28.0 +
+++ symfony-2.8.7+dfsg/debian/patches/series 2017-05-27 20:39:09.0 +0100
@@ -7,3 +7,5 @@
do-not-depend-on-a-fixed-date-in-layout-
update-ipvalidatortest-data-set-with-a-v
relax-1-test-failing-with-latest-php-ver
+vardumper-relax-tests-to-adapt-for-php-7
+vardumper-relax-line-number-for-clidumpe
diff -Nru symfony-2.8.7+dfsg/debian/patches/vardumper-relax-line-number-for-clidumpe symfony-2.8.7+dfsg/debian/patches/vardumper-relax-line-number-for-clidumpe
--- symfony-2.8.7+dfsg/debian/patches/vardumper-relax-line-number-for-clidumpe 1970-01-01 01:00:00.0 +0100
+++ symfony-2.8.7+dfsg/debian/patches/vardumper-relax-line-number-for-clidumpe 2017-05-27 20:39:09.0 +0100
@@ -0,0 +1,28 @@
+From: James Clarke
+Date: Sat, 27 May 2017 19:48:09 +0100
+X-Dgit-Generated: 2.8.7+dfsg-1.3 d28625b7a6b1b5e9be0b3e2af3e79cbabf6a8bbe
+Subject: [VarDumper] Relax line number for CliDumperTest
+
+Origin: backport, https://github.com/symfony/symfony/commit/6ef78ec55317ac473fa045706244ef1f97d4b2de
+
+---
+
+--- symfony-2.8.7+dfsg.orig/src/Symfony/Component/VarDumper/Tests/CliDumperTest.php
symfony-2.8.7+dfsg/src/Symfony/Component/VarDumper/Tests/CliDumperTest.php
+@@ -188,7 +188,6 @@ EOTXT
+ }
+ };'),
+ ));
+-$line = __LINE__ - 2;
+ $ref = (int) $out;
+
+ $data = $cloner->cloneVar($out);
+@@ -261,7 +260,7 @@ stream resource {@{$ref}
+ }
+ %d. %slosure%s() ==> Twig_Template->render(): {
+ src: {
+- %sCliDumperTest.php:{$line}: """
++ %sCliDumperTest.php:%d: """
+ %A
+ """
+ }
diff -Nru symfony-2.8.7+dfsg/debian/patches/vardumper-relax-tests-to-adapt-for-php-7 symfony-2.8.7+dfsg/debian/patches/vardumper-relax-tests-to-adapt-for-php-7
--- symfony-2.8.7+dfsg/debian/patches/vardumper-relax-tests-to-adapt-for-php-7 1970-01-01 01:00:00.0 +0100
+++ symfony-2.8.7+dfsg/debian/patches/vardumper-relax-tests-to-adapt-for-php-7 2017-05-27 20:39:09.0 +0100
@@ -0,0 +1,22 @@
+From: Nicolas Grekas
+Date: Fri, 7 Apr 2017 11:49:35 +0200
+X-Dgit-Generated: 2.8.7+dfsg-1.3 0d8f420c173478e3c199b75e16417bdee99faedf
+Subject: [VarDumper] Relax tests to adapt for php 7.1rc4
+
+Origin: https://github.com/symfony/symfony/commit/3672c01e3c7182888a42b74e2864a20e21cfe7f5
+
+---
+
+--- symfony-2.8.7+dfsg.orig/src/Symfony/Component/VarDumper/Tests/CliDumperTest.php
symfony-2.8.7+dfsg/src/Symfony/Component/VarDumper/Tests/CliDumperTest.php
+@@ -262,9 +262,7 @@ stream resource {@{$ref}
+ %d. %slosure%s() ==> Twig_Template->render(): {
+ src: {
+ %sCliDumperTest.php:{$line}: """
+-}\\n
+-};'),\\n
+-));\\n
++%A
+ """
+ }
+ }
Bug#863493: FTBFS with PHP 7.0.18+
Source: symfony
Version: 2.8.7+dfsg-1.2
Severity: serious
Tags: patch upstream fixed-upstream
Hi,
I noticed that symfony now FTBFS after the upload of php7.0 7.0.18-1,
with the following error in the test suite:
> 1) Symfony\Component\VarDumper\Tests\CliDumperTest::testThrowingCaster
> Failed asserting that format description matches text.
> --- Expected
> +++ Actual
> @@ @@
> stream resource {@239
> -%Awrapper_type: "PHP"
> + timed_out: false
> + blocked: true
> + eof: false
> + wrapper_type: "PHP"
>stream_type: "MEMORY"
> - mode: "%s+b"
> + mode: "w+b"
>unread_bytes: 0
>seekable: true
>uri: "php://memory"
> -%Aoptions: []
> - ⚠: Symfony\Component\VarDumper\Exception\ThrowingCasterException {#%d
> + options: []
> + ⚠: Symfony\Component\VarDumper\Exception\ThrowingCasterException {#411
> #message: "Unexpected Exception thrown from a caster: Foobar"
> -trace: {
> - %d. __TwigTemplate_VarDumperFixture_u75a09->doDisplay() ==> new
> Exception(): {
> + 22. __TwigTemplate_VarDumperFixture_u75a09->doDisplay() ==> new
> Exception(): {
> src: {
> - %sTwig.php:19: """
> +
> /<>/symfony-2.8.7+dfsg/src/Symfony/Component/VarDumper/Tests/Fixtures/Twig.php:19:
> """
>
> @@ @@
>}
> - %d. Twig_Template->displayWithErrorHandling() ==>
> __TwigTemplate_VarDumperFixture_u75a09->doDisplay(): {
> + 21. Twig_Template->displayWithErrorHandling() ==>
> __TwigTemplate_VarDumperFixture_u75a09->doDisplay(): {
> src: {
> - %sTemplate.php:%d: """
> + /usr/share/php/Twig/Template.php:381: """
>
> @@ @@
>}
> - %d. Twig_Template->display() ==>
> Twig_Template->displayWithErrorHandling(): {
> + 20. Twig_Template->display() ==>
> Twig_Template->displayWithErrorHandling(): {
> src: {
> - %sTemplate.php:%d: """
> + /usr/share/php/Twig/Template.php:355: """
>
> @@ @@
>}
> - %d. Twig_Template->render() ==> Twig_Template->display(): {
> + 19. Twig_Template->render() ==> Twig_Template->display(): {
> src: {
> - %sTemplate.php:%d: """
> + /usr/share/php/Twig/Template.php:366: """
>
> @@ @@
>}
> - %d. %slosure%s() ==> Twig_Template->render(): {
> + 18. Symfony\Component\VarDumper\Tests\CliDumperTest->{closure}() ==>
> Twig_Template->render(): {
> src: {
> - %sCliDumperTest.php:189: """
> -}\n
> -};'),\n
> -));\n
> +
> /<>/symfony-2.8.7+dfsg/src/Symfony/Component/VarDumper/Tests/CliDumperTest.php:183:
> """
> +$cloner->addCasters(array(\n
> +':stream' => eval('return function () use ($twig) {\n
> +try {\n
> """
> }
>}
> }
>}
> }
>
> /<>/symfony-2.8.7+dfsg/src/Symfony/Component/VarDumper/Tests/CliDumperTest.php:277
The difference is that the line number for CliDumperTest.php right at
the end is no longer correct, and has some different code after it.
Upstream fixed this already[1,2], and these changes are also in #863441,
but there are other changes not required for PHP 7.0, hence the separate
bug. I am happy to NMU again with just the changes needed, and will do
so if I do not hear anything soon, as the release is approaching and
this will otherwise become a stretch-will-remove bug.
Regards,
James
[1]
https://github.com/symfony/symfony/commit/3672c01e3c7182888a42b74e2864a20e21cfe7f5
[2]
https://github.com/symfony/symfony/commit/6ef78ec55317ac473fa045706244ef1f97d4b2de
(only the change to CliDumperTest.php)
Bug#862842: FTBFS invoking debian/rules binary-arch manually
Source: linux
Version: 4.9.25-1
Severity: serious
Tags: jessie-ignore stretch-ignore
[{jessie,stretch}-ignore pre-approval from jcristau]
Hi,
Invoking debian/rules manually without the help of dpkg-buildpackage
causes src:linux to FTBFS:
> dh_strip: -strip --strip-debug --remove-section=.comment
> --remove-section=.note --enable-deterministic-archives
> debian/libusbip-dev/usr/lib/libusbip.a failed to to execute: No such file or
> directory
Note the extra - prefix to the commands. How this comes about:
1. debian/rules.real exports DEB_HOST_ARCH DEB_HOST_GNU_TYPE
DEB_BUILD_ARCH but does not ensure they are defined, so they are
inserted into the environment as empty strings.
2. Debian::Debhelper::Dh_Lib checks if DEB_HOST_GNU_TYPE != BUILD, but
its dpkg_architecture_value uses value in the environment if
defined, even if empty, so it thinks DEB_HOST_GNU_TYPE is "", but
DEB_BUILD_GNU_TYPE is "x86_64-linux-gnu" (for example), and
therefore thinks it's cross-compiling. It then prepends
"DEB_HOST_GNU_TYPE-" to "strip", which expands to just "-".
Now, debian/rules.real is also checking DEB_{BUILD,HOST}_ARCH itself
(and potentially using DEB_HOST_GNU_TYPE), without ensuring they are
defined, although this is unlikely to cause a problem in reality, since
when cross-compiling you will probably ensure these are all set anyway,
not just the ones that aren't the default. However, it's probably good
practice not to rely on that.
So, to fix this, please either move the "include debian/rules.defs" in
debian/rules.real to before any use of the DEB_* variables (which
includes /usr/share/dpkg/default.mk [which itself includes
architecture.mk], though I don't know if rules.defs has to be that late
in the file for other reasons) or add the appropriate DEB_FOO := ...
definitions to the group at the top of debian/rules.real
Regards,
James
Bug#860625: zimlib: FTBFS on i386: dh_makeshlibs: failing due to earlier errors
> On 20 Apr 2017, at 14:52, James Clarke wrote: > I have checked the build (no symbol diff, even warnings) on amd64 and > i386. I will continue to test other architectures and update this bug > later today. Attached is an updated patch. I have done porterbox test builds for the following architectures: * amd64 * arm64 * armel * armhf * i386 * kfreebsd-amd64 * kfreebsd-i386 * mips * mips64el * mipsel * powerpc * ppc64 * ppc64el * s390x * sparc64 The logs for these are available on people.debian.org[1]. I also performed builds for the following architectures either locally or on non-porterbox machines: * alpha * hppa * hurd-i386 * sh4 (qemu-user) * x32 There were no symbol warnings or errors for any of these builds. Regards, James [1] https://people.debian.org/~jrtc27/zimlib_1.4-2.1_.build 0001-Clean-up-symbols-file.patch Description: Binary data
Bug#860625: zimlib: FTBFS on i386: dh_makeshlibs: failing due to earlier errors
Control: tags -1 patch
These symbol files differences have been fixed by Ubuntu. I came to an
identical patch independently before being told about it. I have also
performed some additional cleanup where things are clearly based on
bitness or endianness, which are *not* included in the Ubuntu delta, but
I think should be in Debian for everyone's sanity.
Now for a slight rant: Please stop blindly applying patches to symbols
files without thinking about what's going on. There were many instances
of:
> arch=!amd64 !arm64 !armel !armhf !hppa !hurd-i386 !kfreebsd-amd64
> !kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc !powerpcspe !ppc64
> !ppc64el !s390x !x32
with the same symbol disappearing on alpha, sh4 and sparc64, causing the
build to fail. Additionally, the symbol also disappeared on i386, but
binary uploads to unstable were used. These must have been done in an
outdated chroot. Source-only uploads are highly recommended to avoid
things like this, but if you *are* going to do binary uploads, *please
ensure your chroot is up to date*.
Similarly, there were instances of:
> arch=amd64 arm64 armel armhf hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 m68k
> mips mips64el mipsel powerpc powerpcspe ppc64 ppc64el s390x x32
with the symbol appearing on i386.
I have checked the build (no symbol diff, even warnings) on amd64 and
i386. I will continue to test other architectures and update this bug
later today.
Regards,
James
[1] https://launchpadlibrarian.net/315416100/zimlib_1.4-2_1.4-2ubuntu1.diff.gz
>From 0ebfab1dd29efa1c1a35b7eada65290880a747d6 Mon Sep 17 00:00:00 2001
From: James Clarke
Date: Thu, 20 Apr 2017 14:34:07 +0100
Subject: [PATCH] Clean up symbols file
Closes: #860625
---
debian/libzim0v5.symbols | 85 ++--
1 file changed, 25 insertions(+), 60 deletions(-)
diff --git a/debian/libzim0v5.symbols b/debian/libzim0v5.symbols
index e1bd3dd..bad4e2f 100644
--- a/debian/libzim0v5.symbols
+++ b/debian/libzim0v5.symbols
@@ -8,9 +8,6 @@ libzim.so.0 libzim0v5 #MINVER#
_ZN3zim10LzmaStreamD1Ev@Base 1.2
_ZN3zim10RefCounted6addRefEv@Base 1.2
_ZN3zim10RefCounted7releaseEv@Base 1.2
- (arch=i386)_ZN3zim10RefCountedD0Ev@Base 1.4
- (arch=i386)_ZN3zim10RefCountedD1Ev@Base 1.4
- (arch=i386)_ZN3zim10RefCountedD2Ev@Base 1.4
_ZN3zim10ZIntStream3getEv@Base 1.2
_ZN3zim10ZIntStream3putEj@Base 1.2
_ZN3zim10envMemSizeEPKcj@Base 1.2
@@ -18,7 +15,6 @@ libzim.so.0 libzim0v5 #MINVER#
_ZN3zim11ClusterImpl12read_contentERSi@Base 1.4
_ZN3zim11ClusterImpl13finalise_readEv@Base 1.4
(subst)_ZN3zim11ClusterImpl16init_from_streamERNS_8ifstreamE{uint64_t}@Base
1.4
-#MISSING: 1.4# _ZN3zim11ClusterImpl4readERSi@Base 1.2
_ZN3zim11ClusterImpl5clearEv@Base 1.2
_ZN3zim11ClusterImpl7addBlobEPKcj@Base 1.2
_ZN3zim11ClusterImpl7addBlobERKNS_4BlobE@Base 1.2
@@ -37,8 +33,6 @@ libzim.so.0 libzim0v5 #MINVER#
_ZN3zim12IndexArticle12readEntriesBEv@Base 1.2
_ZN3zim12IndexArticle12readEntriesZEv@Base 1.2
_ZN3zim12IndexArticle8noOffsetE@Base 1.2
- (arch=!amd64 !arm64 !armel !armhf !hppa !hurd-i386 !kfreebsd-amd64
!kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc !powerpcspe !ppc64
!ppc64el !s390x !x32)_ZN3zim12IndexArticleD1Ev@Base 1.3
- (arch=!amd64 !arm64 !armel !armhf !hppa !hurd-i386 !kfreebsd-amd64
!kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc !powerpcspe !ppc64
!ppc64el !s390x !x32)_ZN3zim12IndexArticleD2Ev@Base 1.3
_ZN3zim12Md5streambuf4syncEv@Base 1.2
_ZN3zim12Md5streambuf8overflowEi@Base 1.2
_ZN3zim12Md5streambuf9getDigestEPh@Base 1.2
@@ -50,12 +44,9 @@ libzim.so.0 libzim0v5 #MINVER#
_ZN3zim12Md5streambufD2Ev@Base 1.2
_ZN3zim12SearchResult9foundWordERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEjj@Base
1.2
(arch=armel armhf hppa powerpc powerpcspe ppc64 ppc64el
s390x)_ZN3zim12SearchResultC1EOS0_@Base 1.4
- (arch=!amd64 !arm64 !armel !armhf !hppa !hurd-i386 !kfreebsd-amd64
!kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc !powerpcspe !ppc64
!ppc64el !s390x !x32)_ZN3zim12SearchResultC1ERKS0_@Base 1.3
(arch=armel armhf hppa powerpc powerpcspe ppc64 ppc64el
s390x)_ZN3zim12SearchResultC2EOS0_@Base 1.4
- (arch=!amd64 !arm64 !armel !armhf !hppa !hurd-i386 !kfreebsd-amd64
!kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc !powerpcspe !ppc64
!ppc64el !s390x !x32)_ZN3zim12SearchResultC2ERKS0_@Base 1.3
_ZN3zim12SearchResultD1Ev@Base 1.2
_ZN3zim12SearchResultD2Ev@Base 1.2
- (arch=!amd64 !arm64 !armel !armhf !hppa !hurd-i386 !kfreebsd-amd64
!kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc !powerpcspe !ppc64
!ppc64el !s390x !x32)_ZN3zim12SearchResultaSERKS0_@Base 1.3
_ZN3zim12Teestreambuf4syncEv@Base 1.2
_ZN3zim12Teestreambuf8overflowEi@Base 1.2
_ZN3zim12Teestreambuf9underflowEv@Base 1.2
@@ -90,8 +81,7 @@ libzim.so.0 libzim0v5 #MINVER#
_ZN3zim14TemplateParser15state_token_endEc@Base 1.2
_ZN3zim14TemplateParser5flushEv@Base 1.2
_ZN3zim14TemplateParser8state_ltEc@Base 1.
Bug#859510: Generated header file without means to regenerate
Source: ruby-unf-ext Version: 0.0.7.2-2 Severity: serious Hi, While investigating #859463 with Niels, we noticed that the file in question, ext/unf_ext/unf/table.hh, is pre-generated, but the original sources[1] (and script used to process the sources[2]) are not present in main. Regards, James [1] https://github.com/sile/unf/tree/master/data [2] https://github.com/sile/unf/blob/master/lisp/gen-table.lisp
Bug#857067: dsdp: diff for NMU version 5.8-9.4
Control: tags 857067 + patch
Dear maintainer,
I've prepared an NMU for dsdp (versioned as 5.8-9.4). The diff
is attached to this message.
Regards,
James
diff -Nru dsdp-5.8/debian/changelog dsdp-5.8/debian/changelog
--- dsdp-5.8/debian/changelog 2017-03-28 16:40:25.0 +0100
+++ dsdp-5.8/debian/changelog 2017-03-28 18:22:35.0 +0100
@@ -1,3 +1,13 @@
+dsdp (5.8-9.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Revert previous patches in 5.8-9.2 and 5.8-9.3, they are completely wrong
+and end up causing *flags to always be 0 on 64-bit big-endian systems.
+ * Use correct integer type for Fortran prototypes and variables
+(Closes: #857067)
+
+ -- James Clarke Tue, 28 Mar 2017 18:22:35 +0100
+
dsdp (5.8-9.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru dsdp-5.8/debian/patches/type-mismatch.patch dsdp-5.8/debian/patches/type-mismatch.patch
--- dsdp-5.8/debian/patches/type-mismatch.patch 2017-03-28 16:26:15.0 +0100
+++ dsdp-5.8/debian/patches/type-mismatch.patch 2017-03-28 18:20:40.0 +0100
@@ -1,42 +1,39 @@
-Description: Cast INFO to int before storing it in the flag
-Author: Dimitri John Ledkov
-Bug-Ubuntu: https://bugs.launchpad.net/bugs/1543982
-
dsdp-5.8.orig/src/vecmat/dlpack.c
-+++ dsdp-5.8/src/vecmat/dlpack.c
-@@ -97,7 +97,7 @@
+Description: Use correct integer type for Fortran prototypes and variables
+ GNU Fortran's default integer width is 32-bit, the same as GCC, therefore use
+ int rather than long int when interfacing with Fortran. This was an issue on
+ 64-bit big-endian systems, since the upper 32 bits of the long would be set,
+ which would also be lost when truncating to a 32-bit integer.
+Author: James Clarke
+Bug-Debian: https://bugs.debian.org/857067
+Last-Update: 2017-03-28
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/include/dsdplapack.h
b/include/dsdplapack.h
+@@ -4,11 +4,11 @@
+ \file dsdplapack.h
+ \brief DSDP uses BLAS and LAPACK for many of its operations.
+ */
+-
+-typedef long int ffinteger;
+ /*
+-typedef int ffinteger;
++typedef long int ffinteger;
+ */
++typedef int ffinteger;
++
+ /*
+ #define __DSDP_NONAMEMANGLING
+ #undef __DSDP_NONAMEMANGLING
+--- a/src/vecmat/dtrsm2.c
b/src/vecmat/dtrsm2.c
+@@ -1,7 +1,7 @@
+ #include "dsdplapack.h"
- static int DTPUMatSolve(void* AA, double b[], double x[], int n){
- dtpumat* A=(dtpumat*) AA;
-- ffinteger INFO,NRHS=1,LDB=A->n,N=A->n;
-+ ffinteger INFO=0,NRHS=1,LDB=A->n,N=A->n;
- double *AP=A->val,*ss=A->sscale;
- char UPLO=A->UPLO;
+-typedef long int integer;
+-typedef long int logical;
++typedef int integer;
++typedef int logical;
-@@ -111,7 +111,7 @@
- static int DTPUMatCholeskyFactor(void* AA, int *flag){
- dtpumat* A=(dtpumat*) AA;
- int i;
-- ffinteger INFO,LDA=1,N=A->n;
-+ ffinteger INFO=0,LDA=1,N=A->n;
- double *AP=A->val,*ss=A->sscale,*v;
- char UPLO=A->UPLO;
-
-@@ -123,7 +123,7 @@
- dtpuscalemat(AP,ss,N);
- }
- dpptrf(&UPLO, &N, AP, &INFO );
-- *flag=INFO;
-+ *flag=(int) INFO;
- return 0;
- }
-
-@@ -370,7 +370,7 @@
-
- static int DTPUMatInvert(void* AA){
- dtpumat* A=(dtpumat*) AA;
-- ffinteger INFO,N=A->n,nn=N*(N+1)/2;
-+ ffinteger INFO=0,N=A->n,nn=N*(N+1)/2;
- double *v=A->val,*AP=A->v2,*ss=A->sscale;
- char UPLO=A->UPLO;
- memcpy((void*)AP,(void*)v,nn*sizeof(double));
+ #define max(a,b) ((a) >= (b) ? (a) : (b))
+ #define dmax(a,b) (double)max(a,b)
Bug#857067: closed by Ole Streicher (Bug#857067: fixed in dsdp 5.8-9.3)
Control: reopen 857067 Control: tags 857067 - patch On Tue, Mar 28, 2017 at 04:39:07PM +, Debian Bug Tracking System wrote: > Changes: > dsdp (5.8-9.3) unstable; urgency=medium > . >* Non-maintainer upload. >* Initialize all INFO vars. Closes: #857067 This is not the right fix at all, it merely papers over the issue by meaning that *flag will *always* be zero on 64-bit big-endian platforms no matter what INFO was actually set to. Please don't make changes you don't understand. I will upload the *real* fix for this (mismatched types between prototype and implementation). Regards, James >* Revert unneeded changes in d/rules
Bug#857067: dsdp: diff for NMU version 5.8-9.3
Dear maintainer, I've prepared an NMU for dsdp (versioned as 5.8-9.3). The diff is attached to this message. Regards, James diff -Nru dsdp-5.8/debian/changelog dsdp-5.8/debian/changelog --- dsdp-5.8/debian/changelog 2017-03-28 08:22:18.0 +0100 +++ dsdp-5.8/debian/changelog 2017-03-28 17:46:46.0 +0100 @@ -1,3 +1,11 @@ +dsdp (5.8-9.3) unstable; urgency=medium + + * Non-maintainer upload. + * Use correct integer type for Fortran prototypes and variables +(Closes: #857067) + + -- James Clarke Tue, 28 Mar 2017 17:46:46 +0100 + dsdp (5.8-9.2) unstable; urgency=medium * Non-maintainer upload. diff -Nru dsdp-5.8/debian/patches/ffinteger-type-mismatch.patch dsdp-5.8/debian/patches/ffinteger-type-mismatch.patch --- dsdp-5.8/debian/patches/ffinteger-type-mismatch.patch 1970-01-01 01:00:00.0 +0100 +++ dsdp-5.8/debian/patches/ffinteger-type-mismatch.patch 2017-03-28 17:45:50.0 +0100 @@ -0,0 +1,39 @@ +Description: Use correct integer type for Fortran prototypes and variables + GNU Fortran's default integer width is 32-bit, the same as GCC, therefore use + int rather than long int when interfacing with Fortran. This was an issue on + 64-bit big-endian systems, since the upper 32 bits of the long would be set, + which would also be lost when truncating to a 32-bit integer. +Author: James Clarke +Bug-Debian: https://bugs.debian.org/857067 +Last-Update: 2017-03-28 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/include/dsdplapack.h b/include/dsdplapack.h +@@ -4,11 +4,11 @@ + \file dsdplapack.h + \brief DSDP uses BLAS and LAPACK for many of its operations. + */ +- +-typedef long int ffinteger; + /* +-typedef int ffinteger; ++typedef long int ffinteger; + */ ++typedef int ffinteger; ++ + /* + #define __DSDP_NONAMEMANGLING + #undef __DSDP_NONAMEMANGLING +--- a/src/vecmat/dtrsm2.c b/src/vecmat/dtrsm2.c +@@ -1,7 +1,7 @@ + #include "dsdplapack.h" + +-typedef long int integer; +-typedef long int logical; ++typedef int integer; ++typedef int logical; + + #define max(a,b) ((a) >= (b) ? (a) : (b)) + #define dmax(a,b) (double)max(a,b) diff -Nru dsdp-5.8/debian/patches/series dsdp-5.8/debian/patches/series --- dsdp-5.8/debian/patches/series 2017-03-28 08:21:43.0 +0100 +++ dsdp-5.8/debian/patches/series 2017-03-28 17:45:50.0 +0100 @@ -1 +1 @@ -type-mismatch.patch +ffinteger-type-mismatch.patch diff -Nru dsdp-5.8/debian/patches/type-mismatch.patch dsdp-5.8/debian/patches/type-mismatch.patch --- dsdp-5.8/debian/patches/type-mismatch.patch 2017-03-28 08:21:43.0 +0100 +++ dsdp-5.8/debian/patches/type-mismatch.patch 1970-01-01 01:00:00.0 +0100 @@ -1,15 +0,0 @@ -Description: Cast INFO to int before storing it in the flag -Author: Dimitri John Ledkov -Bug-Ubuntu: https://bugs.launchpad.net/bugs/1543982 - dsdp-5.8.orig/src/vecmat/dlpack.c -+++ dsdp-5.8/src/vecmat/dlpack.c -@@ -123,7 +123,7 @@ static int DTPUMatCholeskyFactor(void* A - dtpuscalemat(AP,ss,N); - } - dpptrf(&UPLO, &N, AP, &INFO ); -- *flag=INFO; -+ *flag=(int) INFO; - return 0; - } -
Bug#855163: [debian-mysql] Bug#855163: Missing mariadb-plugin-tokudb binary package on amd64
Control: reassign -1 release.debian.org Control: user release.debian@packages.debian.org Control: usertags -1 binnmu Control: severity -1 normal Control: retitle -1 nmu: mariadb-10.1_10.1.21-5 On 14 Feb 2017, at 22:00, Otto Kekäläinen wrote: >> 2017-02-14 23:58 GMT+02:00 James Clarke : >>> On 14 Feb 2017, at 21:54, Otto Kekäläinen wrote: >>> >>> So you suggest I upload 10.1.21-6 and go though all the hassle of >>> filing unblocks etc? Is there no possibility to trigger a rebuild on >>> amd64 with the current source package? >> >> I don't know which is preferred, just that both solve the problem. > > I would prefer somebody would just trigger the rebuild on amd64. There > is no need to fill the archives with an indentical upload. I thought the NEW-ness might introduce issues, but apparently not. nmu mariadb-10.1_10.1.21-5 . amd64 . -m "Rebuild to build missing mariadb-plugin-tokudb." Regards, James
Bug#855163: [debian-mysql] Bug#855163: Missing mariadb-plugin-tokudb binary package on amd64
> On 14 Feb 2017, at 21:54, Otto Kekäläinen wrote: > > So you suggest I upload 10.1.21-6 and go though all the hassle of > filing unblocks etc? Is there no possibility to trigger a rebuild on > amd64 with the current source package? I don't know which is preferred, just that both solve the problem. James
Bug#855163: Missing mariadb-plugin-tokudb binary package on amd64
Source: mariadb-10.1 Version: 10.1.21-5 Severity: serious As can be seen in the discussion for #852709, the source+amd64 upload for 10.1.21-5 did not include mariadb-plugin-tokudb, despite the package's architecture being base-any-any-amd64. Either a binNMU or a new source upload is needed (a test rebuild on barriere worked). Regards, James
Bug#854794: Does not install build-deps for some dscs
Package: apt Version: 1.4~rc1 Severity: serious It seems invoking apt build-dep on a dsc doesn't always work: > jrtc27@deb4g:~$ sudo apt build-dep > ~/src/debian-installer/debian-installer_201701XX.dsc > Note, using file > '/home/jrtc27/src/debian-installer/debian-installer_201701XX.dsc' to get the > build dependencies > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages were automatically installed and are no longer > required: > libmagickcore-6.q16-2 libmagickwand-6.q16-2 libsane-bin python3-olefile > Use 'sudo apt autoremove' to remove them. > 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. Using the package name still works though: > jrtc27@deb4g:~$ sudo apt build-dep debian-installer > Reading package lists... Done > Selected version '20170127' (unstable) for debian-installer > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages were automatically installed and are no longer > required: > libmagickcore-6.q16-2 libmagickwand-6.q16-2 libsane-bin python3-olefile > Use 'sudo apt autoremove' to remove them. > The following NEW packages will be installed: > bf-utf-source debiandoc-sgml genext2fs genromfs libbogl-dev libbogl0 > libnewt-pic libroman-perl libslang2-pic libtext-format-perl mklibs mklibs-copy > 0 upgraded, 12 newly installed, 0 to remove and 1 not upgraded. > Need to get 1,743 kB of archives. > After this operation, 15.3 MB of additional disk space will be used. > Do you want to continue? [Y/n] n This is the full dsc being used: > Format: 1.0 > Source: debian-installer > Binary: debian-installer > Architecture: any > Version: 201701XX > Maintainer: Debian Install System Team > Uploaders: Cyril Brulebois > Standards-Version: 3.9.5 > Vcs-Browser: https://anonscm.debian.org/cgit/d-i/debian-installer.git > Vcs-Git: https://anonscm.debian.org/git/d-i/debian-installer.git > Build-Depends: debhelper (>= 7.0.0), apt (>= 0.8.16), apt-utils, gnupg, > debian-archive-keyring (>= 2006.11.22), dctrl-tools, wget, bc, > debiandoc-sgml, xsltproc, docbook-xml, docbook-xsl, libbogl-dev, > libslang2-pic (>= 2.0.6-4), libnewt-pic (>= 0.52.2-11.3) [!mipsel], > libnewt-dev (>= 0.52.2-11.3) [mipsel], libgcc1 [i386 amd64], genext2fs (>= > 1.3-7.1), e2fsprogs, mklibs (>= 0.1.40), mklibs-copy (>= 0.1.40), genisoimage > [!s390 !s390x], genromfs [sparc sparc64], hfsutils [powerpc], dosfstools > [i386 m68k amd64 armhf arm64], cpio, xz-utils, devio [armeb armel], slugimage > (>= 0.10+r58-6) [armeb armel], dns323-firmware-tools (>= 0.7.3-1~) [armel], > u-boot-tools [armel armhf], syslinux [i386 amd64], syslinux-utils [i386 > amd64], isolinux [i386 amd64], pxelinux [i386 amd64], syslinux-common (>= > 3:6) [i386 amd64], yaboot [powerpc], aboot (>= 0.9b-2) [alpha], silo [sparc > sparc64], sparc-utils [sparc sparc64], atari-bootstrap [m68k], vmelilo > [m68k], m68k-vme-tftplilo [m68k], amiboot [m68k], emile [m68k], > emile-bootblocks [m68k], apex-nslu2 [armeb armel], grub-efi-amd64-bin > [amd64], grub-efi-arm64-bin [arm64], grub-efi-ia32-bin [i386], grub-common > [amd64 arm64 i386], xorriso, grub-ieee1275-bin [ppc64el], u-boot-imx [armhf], > u-boot-omap (>= 2016.09~rc1) [armhf], u-boot-sunxi [armhf], u-boot-rockchip > (>= 2016.09~rc1) [armhf], u-boot (>= 2016.01+dfsg1-1~) [armel], tofrodos > [i386 amd64 kfreebsd-i386 kfreebsd-amd64], mtools [i386 m68k amd64 armhf > arm64 kfreebsd-i386 kfreebsd-amd64 hurd-i386], kmod [linux-any], > bf-utf-source [!s390 !s390x], mkvmlinuz [powerpc], openssl, win32-loader (>= > 0.7.2) [i386 amd64 kfreebsd-i386 kfreebsd-amd64 hurd-i386], makefs (>= > 20100306-5+kbsd8u1~) [kfreebsd-any], grub-pc (>= 2.02~beta2~) [kfreebsd-i386 > kfreebsd-amd64 hurd-i386], xorriso (>= 1.3.2-1~) [kfreebsd-i386 > kfreebsd-amd64 hurd-i386], debian-ports-archive-keyring [sh4 sparc64], > librsvg2-bin [any-amd64 any-i386] > Build-Conflicts: libnewt-pic [mipsel] > Package-List: > debian-installer deb devel optional arch=any > Checksums-Sha1: > dbb51d9c6be93bb3891c215a05f3bfb4eb5a33d5 21201400 > debian-installer_201701XX.tar.gz > Checksums-Sha256: > c925c952ae8be3d31ea8fbac60bc5497b0ed70bba1ecdadfb0cf4b6a9d111eb3 21201400 > debian-installer_201701XX.tar.gz > Files: > 12638f3c5fef207b58483ac0038464b3 21201400 debian-installer_201701XX.tar.gz Other dscs do seem to work, however. I don't know if this is a regression, but there is something weird going on. Regards, James
Bug#854463: FTBFS without user input with a controlling TTY
Source: kodi Version: 2:17.0~rc3+dfsg1-2 Severity: serious In a freshly-unpacked source directory, dpkg-buildpackage (or pdebuild, or sbuild) blocks in the clean target trying to reverse some patches, because they were never applied (they get applied during configure) and patch prompts the user for input. The user needs to answer 44 questions before the clean target actually finishes: > ls /«BUILDDIR»/kodi-17.0~rc3+dfsg1/debian/patches/libdvdnav-* | tac | xargs > cat > ls /«BUILDDIR»/kodi-17.0~rc3+dfsg1/debian/patches/libdvdnav-* | tac | xargs > cat | patch -R --no-backup-if-mismatch -r - -s -p1 \ > -d libdvdnav-5-0-3 || true > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 2 out of 2 hunks ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > ls /«BUILDDIR»/kodi-17.0~rc3+dfsg1/debian/patches/libdvdread-* | tac | xargs > cat | patch -R --no-backup-if-mismatch -r - -s -p1 \ > -d libdvdread-5-0-3 || true > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 2 out of 2 hunks ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 5 out of 5 hunks ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 2 out of 2 hunks ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored > Unreversed patch detected! Ignore -R? [n] > Apply anyway? [n] > 1 out of 1 hunk ignored
Bug#852434: cowdancer 0.84 MIGRATED to testing
On 31 Jan 2017, at 17:09, James Clarke wrote: > On 31 Jan 2017, at 14:56, James Clarke wrote: >> However, given that I did not notice the "--build .dsc-file" bit when I first >> re-read it, I have changed my mind and will allow the old style to work. This >> *will* give a deprecation warning though, and I intend to remove it during >> the >> Buster release cycle; is that ok for you? I don't want to support this >> forever >> as I can give better error messages without this backwards-compatibility. It >> will also remain undocumented in the manpage. > > I have pushed this change and intend to upload to unstable soon. Please > confirm > this is ok. Having looked more closely at src:cowdancer's reverse depends, I have found at least one package that calls cowbuilder without giving --build first. Therefore I will remove the deprecation warnings for Stretch, as reverse-depends will not be able to be fixed in time. Regards, James
Bug#852434: cowdancer 0.84 MIGRATED to testing
On 31 Jan 2017, at 14:56, James Clarke wrote: > However, given that I did not notice the "--build .dsc-file" bit when I first > re-read it, I have changed my mind and will allow the old style to work. This > *will* give a deprecation warning though, and I intend to remove it during the > Buster release cycle; is that ok for you? I don't want to support this forever > as I can give better error messages without this backwards-compatibility. It > will also remain undocumented in the manpage. I have pushed this change and intend to upload to unstable soon. Please confirm this is ok. Regards, James
Bug#852434: in cowdancer marked as pending
Control: tag 852434 pending Hello, Bug #852434 in cowdancer reported by you has been fixed in the Git repository. You can see the commit message below, and you can check the diff of the fix at: https://anonscm.debian.org/git/pbuilder/cowdancer.git/commit/?id=86493b0 (this message was generated automatically based on the git commit message) --- commit 86493b05640cc2dd1dde303f69805b293ae5b432 Author: James Clarke Date: Tue Jan 31 16:50:48 2017 + parameter.c: Allow commands to come later, but give deprecation warning Closes: #852434
Bug#852434: cowdancer 0.84 MIGRATED to testing
Control: tags -1 - wontfix Control: severity -1 serious On 31 Jan 2017, at 12:41, Thorsten Glaser wrote: > > James Clarke dixit: > >> Your mail server rejected my message (again). My guess is you didn't get the >> message from the mailing list because it saw it was already addressed to you. > > Ah, okay. (My mailserver does not reject properly sent messages > after passing greylisting, except for servers on a blacklist, > which the ones you use aren’t on.) I don't have problems sending to anyone else. I use Google's SMTP server for sending my messages, but SPF should be correctly set up. >>> I disagree that --build is a command; it is an option that expects >>> an argument (the .dsc file). >>> >>> Please revert this! >> >> What's your reasoning? This was never officially supported. Ever. Just give >> the > > If for no other reason, then for, that cowbuilder is invoked by > other tools, and such a breaking change ought to not be uploaded > less than two weeks before the hard freeze. > >> command first, like everyone has always had to do for pbuilder. And yes >> --build >> *is* a command; it says so in the manpage[0]. Whether or not *you* think it >> is > > The manpage of 0.83 says so: > > --build .dsc-file > >> is irrelevant. All it takes is for you to change the order of the arguments >> you >> give to your c script. > > This is not very helpful. Do I reorder --build first, or the > entirety of --build .dsc-file – after all, --build was always > documented as requiring an argument (and has option format!), > yet your changelog entry says something about parsing it now > separately, which WILL break existing users. Ok, so, on re-reading 0.83's manpage, it's actually wrong; --build never took an argument directly. However, by virtue of getop_long, you could put the dsc anywhere in the arguments; the following all worked: > cowbuilder --build foo.dsc --option > cowbuilder --build --option foo.dsc > cowbuilder --option1 --build foo.dsc --option2 > cowbuilder --option1 --build --option2 foo.dsc However, given that I did not notice the "--build .dsc-file" bit when I first re-read it, I have changed my mind and will allow the old style to work. This *will* give a deprecation warning though, and I intend to remove it during the Buster release cycle; is that ok for you? I don't want to support this forever as I can give better error messages without this backwards-compatibility. It will also remain undocumented in the manpage. Regards, James
Bug#832858: symfony: diff for NMU version 2.8.7+dfsg-1.2
Dear maintainer,
I've prepared an NMU for symfony (versioned as 2.8.7+dfsg-1.2). The diff
is attached to this message. This fixes the test suite failures on the
buildd which I failed to notice when preparing my previous NMU (I was
using an outdated chroot). I have uploaded directly to unstable again.
Regards,
James
diff -Nru symfony-2.8.7+dfsg/debian/changelog symfony-2.8.7+dfsg/debian/changelog
--- symfony-2.8.7+dfsg/debian/changelog 2017-01-29 13:54:28.0 +
+++ symfony-2.8.7+dfsg/debian/changelog 2017-01-29 16:05:28.0 +
@@ -1,3 +1,12 @@
+symfony (2.8.7+dfsg-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport additional upstream patches needed to fix FTBFS:
+- Update IpValidatorTest data set with a valid reserved IP
+- Relax 1 test failing with latest PHP versions
+
+ -- James Clarke Sun, 29 Jan 2017 16:05:28 +
+
symfony (2.8.7+dfsg-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru symfony-2.8.7+dfsg/debian/patches/relax-1-test-failing-with-latest-php-ver symfony-2.8.7+dfsg/debian/patches/relax-1-test-failing-with-latest-php-ver
--- symfony-2.8.7+dfsg/debian/patches/relax-1-test-failing-with-latest-php-ver 1970-01-01 01:00:00.0 +0100
+++ symfony-2.8.7+dfsg/debian/patches/relax-1-test-failing-with-latest-php-ver 2017-01-29 16:05:28.0 +
@@ -0,0 +1,26 @@
+From: Remi Collet
+Date: Fri, 5 Aug 2016 09:21:03 +0200
+X-Dgit-Generated: 2.8.7+dfsg-1.2 5f7c01770fe23c699caa96782ce8a6e2cad4811a
+Subject: Relax 1 test failing with latest PHP versions
+
+Related to php bug #52646 which is fixed in 5.6.25RC1, 7.0.10RC1, 7.1.0beta2
+
+Origin: https://github.com/symfony/symfony/commit/6703b416d8e7edc2fd04a214b317ea4a189cac51
+
+---
+
+--- symfony-2.8.7+dfsg.orig/src/Symfony/Component/VarDumper/Tests/Caster/SplCasterTest.php
symfony-2.8.7+dfsg/src/Symfony/Component/VarDumper/Tests/Caster/SplCasterTest.php
+@@ -94,10 +94,10 @@ SplFileObject {
+ file: true
+ dir: false
+ link: false
+-%AcsvControl: array:2 [
++%AcsvControl: array:%d [
+ 0 => ","
+ 1 => """
+- ]
++%A]
+ flags: DROP_NEW_LINE|SKIP_EMPTY
+ maxLineLen: 0
+ fstat: array:26 [
diff -Nru symfony-2.8.7+dfsg/debian/patches/series symfony-2.8.7+dfsg/debian/patches/series
--- symfony-2.8.7+dfsg/debian/patches/series 2017-01-29 13:54:28.0 +
+++ symfony-2.8.7+dfsg/debian/patches/series 2017-01-29 16:05:28.0 +
@@ -5,3 +5,5 @@
HttpFoundation-Fix-incompatibility-with-php-memcache.patch
fix-php-7.1-related-failures
do-not-depend-on-a-fixed-date-in-layout-
+update-ipvalidatortest-data-set-with-a-v
+relax-1-test-failing-with-latest-php-ver
diff -Nru symfony-2.8.7+dfsg/debian/patches/update-ipvalidatortest-data-set-with-a-v symfony-2.8.7+dfsg/debian/patches/update-ipvalidatortest-data-set-with-a-v
--- symfony-2.8.7+dfsg/debian/patches/update-ipvalidatortest-data-set-with-a-v 1970-01-01 01:00:00.0 +0100
+++ symfony-2.8.7+dfsg/debian/patches/update-ipvalidatortest-data-set-with-a-v 2017-01-29 16:05:28.0 +
@@ -0,0 +1,22 @@
+From: Jakub Zalas
+Date: Tue, 13 Sep 2016 12:11:56 +0100
+X-Dgit-Generated: 2.8.7+dfsg-1.2 007ac6e42739ef24a35a1872a566ac35e90f0aaf
+Subject: Update IpValidatorTest data set with a valid reserved IP
+
+The validator uses PHP filter which was recently fixed (see https://bugs.php.net/bug.php?id=72972).
+
+Origin: https://github.com/symfony/symfony/commit/86a151c9f57adc3cb3734aa7b74d5bf1462bf0ce
+
+---
+
+--- symfony-2.8.7+dfsg.orig/src/Symfony/Component/Validator/Tests/Constraints/IpValidatorTest.php
symfony-2.8.7+dfsg/src/Symfony/Component/Validator/Tests/Constraints/IpValidatorTest.php
+@@ -221,7 +221,7 @@ class IpValidatorTest extends AbstractCo
+ {
+ return array(
+ array('0.0.0.0'),
+-array('224.0.0.1'),
++array('240.0.0.1'),
+ array('255.255.255.255'),
+ );
+ }
Bug#852709: [debian-mysql] Bug#852709: Patch
On 29 Jan 2017, at 15:24, Otto Kekäläinen wrote: > 2017-01-29 17:12 GMT+02:00 James Clarke : >> Yeah, I'm not sure what's wrong with your setup. I would suggest checking the >> version of dpkg-dev inside your chroot, since that should be the only thing >> determining whether the package is built. Does the build log show it building >> the TokuDB sources (even though it didn't build a package)? Did the build log >> include the DEB_HOST_ARCH_ABI in the dpkg-architecture dump? > > > http://labs.seravo.fi/~otto/debian/mariadb-10.1-sid-amd64/mariadb-10.1_10.1.21-5_amd64.build-d237cd1-pbuilder.log > > dpkg-architecture: error: DEB_HOST_ARCH_ABI is not a supported variable name > > > So pbuilder update has stopped working or something. I shall delete > the whole sid chroot and create a new one from scratch. That's coming from debian/rules clean being run outside the chroot to build the source package, before it gets copied into the chroot. It doesn't seem fatal though, and shouldn't be needed for the clean target. You have a version of dpkg-dev inside the chroot which knows about DEB_HOST_ARCH_ABI, since there's DEB_HOST_ARCH_ABI=base printed later on. TokuDB was definitely built and installed: > -- Installing: > /tmp/buildd/mariadb-10.1-10.1.21/debian/tmp/usr/lib/x86_64-linux-gnu/mariadb18/plugin/ha_tokudb.so For some reason dh_builddeb (which delegates to Debhelper::Dh_Lib to get the packages to build) didn't think it should build the package. Very strange... Regards, James
Bug#852709: [debian-mysql] Bug#852709: Patch
On 29 Jan 2017, at 09:27, Otto Kekäläinen wrote: > Hello! > > 2017-01-28 3:32 GMT+02:00 James Clarke : >> Are you using a very old chroot? You need dpkg-dev (>= 1.18.11) to support >> quadruplets in the Architecture field, though that was uploaded on the 6th >> November... > > No TokuDB in unstable now: > https://packages.debian.org/unstable/mariadb-plugin-tokudb > This problably due to me uploading binaries, and as other no than > amd64 will build TokuDB, and the amd64 had no reason to trigger a > rebuild, so only my binaries (without TokuDB) are in the repositories > now. > > I am using pbuilder to build, and I updated the chroots just a few > days ago (http://labs.seravo.fi/~otto/debian/update-chroots.sh), so it > is unlikely the dpkg versio was old, unless the pbuilder update is > somehow broken. If it worked for you on barreire, then I don't know > what caused it here. Yeah, I'm not sure what's wrong with your setup. I would suggest checking the version of dpkg-dev inside your chroot, since that should be the only thing determining whether the package is built. Does the build log show it building the TokuDB sources (even though it didn't build a package)? Did the build log include the DEB_HOST_ARCH_ABI in the dpkg-architecture dump? Regards, James
Bug#832858: symfony: diff for NMU version 2.8.7+dfsg-1.1
Control: tags 832858 + patch
Dear maintainer,
I've prepared an NMU for symfony (versioned as 2.8.7+dfsg-1.1). The diff
is attached to this message. I have uploaded directly to unstable since
there has been no maintainer activity on this bug.
Regards,
James
diff -Nru symfony-2.8.7+dfsg/debian/changelog symfony-2.8.7+dfsg/debian/changelog
--- symfony-2.8.7+dfsg/debian/changelog 2016-06-08 01:52:05.0 +0100
+++ symfony-2.8.7+dfsg/debian/changelog 2017-01-29 13:54:28.0 +
@@ -1,3 +1,12 @@
+symfony (2.8.7+dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix PHP 7.0/7.1 related failures (Closes: #832858)
+ * Do not depend on a fixed date in layout tests (fixes FTBFS in 2017 and
+beyond)
+
+ -- James Clarke Sun, 29 Jan 2017 13:54:28 +
+
symfony (2.8.7+dfsg-1) unstable; urgency=medium
[ Fabien Potencier ]
diff -Nru symfony-2.8.7+dfsg/debian/patches/do-not-depend-on-a-fixed-date-in-layout- symfony-2.8.7+dfsg/debian/patches/do-not-depend-on-a-fixed-date-in-layout-
--- symfony-2.8.7+dfsg/debian/patches/do-not-depend-on-a-fixed-date-in-layout- 1970-01-01 01:00:00.0 +0100
+++ symfony-2.8.7+dfsg/debian/patches/do-not-depend-on-a-fixed-date-in-layout- 2017-01-29 13:54:28.0 +
@@ -0,0 +1,163 @@
+From: Christian Flothmann
+Date: Sun, 1 Jan 2017 13:18:05 +0100
+X-Dgit-Generated: 2.8.7+dfsg-1.1 804ee09c5a98f4ff4ed1132b68bf4c4afa17facc
+Subject: Do not depend on a fixed date in layout tests
+
+By default, the `DateType` as well as the `DateTimeType` set the choices
+being available for the year to a range starting five years in the past.
+After some time, this will make tests fail when the year of the fixed
+date being used as the initial data is before the first year being part
+of the choices.
+
+Origin: backport, https://github.com/symfony/symfony/commit/97b7fabf519b48333b772924b141f84efdb44c1e
+
+---
+
+--- symfony-2.8.7+dfsg.orig/src/Symfony/Component/Form/Tests/AbstractBootstrap3LayoutTest.php
symfony-2.8.7+dfsg/src/Symfony/Component/Form/Tests/AbstractBootstrap3LayoutTest.php
+@@ -1346,7 +1346,7 @@ abstract class AbstractBootstrap3LayoutT
+
+ public function testDateTime()
+ {
+-$form = $this->factory->createNamed('name', 'Symfony\Component\Form\Extension\Core\Type\DateTimeType', '2011-02-03 04:05:06', array(
++$form = $this->factory->createNamed('name', 'Symfony\Component\Form\Extension\Core\Type\DateTimeType', date('Y').'-02-03 04:05:06', array(
+ 'input' => 'string',
+ 'with_seconds' => false,
+ ));
+@@ -1365,7 +1365,7 @@ abstract class AbstractBootstrap3LayoutT
+ /following-sibling::select
+ [@id="name_date_year"]
+ [@class="form-control"]
+-[./option[@value="2011"][@selected="selected"]]
++[./option[@value="'.date('Y').'"][@selected="selected"]]
+ /following-sibling::select
+ [@id="name_time_hour"]
+ [@class="form-control"]
+@@ -1420,7 +1420,7 @@ abstract class AbstractBootstrap3LayoutT
+
+ public function testDateTimeWithHourAndMinute()
+ {
+-$data = array('year' => '2011', 'month' => '2', 'day' => '3', 'hour' => '4', 'minute' => '5');
++$data = array('year' => date('Y'), 'month' => '2', 'day' => '3', 'hour' => '4', 'minute' => '5');
+
+ $form = $this->factory->createNamed('name', 'Symfony\Component\Form\Extension\Core\Type\DateTimeType', $data, array(
+ 'input' => 'array',
+@@ -1442,7 +1442,7 @@ abstract class AbstractBootstrap3LayoutT
+ /following-sibling::select
+ [@id="name_date_year"]
+ [@class="form-control"]
+-[./option[@value="2011"][@selected="selected"]]
++[./option[@value="'.date('Y').'"][@selected="selected"]]
+ /following-sibling::select
+ [@id="name_time_hour"]
+ [@class="form-control"]
+@@ -1459,7 +1459,7 @@ abstract class AbstractBootstrap3LayoutT
+
+ public function testDateTimeWithSeconds()
+ {
+-$form = $this->factory->createNamed('name', 'Symfony\Component\Form\Extension\Core\Type\DateTimeType', '2011-02-03 04:05:06', array(
++$form = $this->factory->createNamed('name', 'Symfony\Component\Form\Extension\Core\Type\DateTimeType', date('Y').'
Bug#852709: [debian-mysql] Bug#852709: Patch
> On 27 Jan 2017, at 21:07, Otto Kekäläinen wrote: > > I've now built and uploaded 10.1.21-5. > > Post upload I diffed the filelists (public at > http://labs.seravo.fi/~otto/debian/mariadb-10.1-sid-amd64/?C=M;O=D) > and I noticed my amd64 sid pbuilder is not generating > mariadb-plugin-tokudb anymore... > > James: can you please review your commits today and track down where > the mistake was? Now we have the problem at hand, that if I re-upload > a version where mariadb-plugin-tokudb is back again, then DAK will > detect a new package and the whole mariadb-10.1 will need to go though > the NEW queue again.. > > > $ diff -u filelist-2db349e.log filelist-d237cd1.log > --- filelist-2db349e.log 2017-01-25 16:03:08.0 +0200 > +++ filelist-d237cd1.log 2017-01-27 22:02:01.0 +0200 > @@ -177,8 +177,8 @@ > drwxr-xr-x root/root ./usr/lib/ > drwxr-xr-x root/root ./usr/lib/debug/ > drwxr-xr-x root/root ./usr/lib/debug/.build-id/ > -drwxr-xr-x root/root ./usr/lib/debug/.build-id/80/ > --rw-r--r-- root/root > ./usr/lib/debug/.build-id/80/7640a5d6deb080854ee8a35ee5156f876be14c.debug > +drwxr-xr-x root/root ./usr/lib/debug/.build-id/e4/ > +-rw-r--r-- root/root > ./usr/lib/debug/.build-id/e4/1ba3aae4ba6b95b07e7f31c1b001fa1fddcdac.debug > drwxr-xr-x root/root ./usr/share/ > drwxr-xr-x root/root ./usr/share/doc/ > lrwxrwxrwx root/root ./usr/share/doc/libmariadbd18-dbgsym > @@ -529,45 +529,6 @@ > drwxr-xr-x root/root ./usr/share/doc/ > lrwxrwxrwx root/root ./usr/share/doc/mariadb-plugin-spider-dbgsym > > -mariadb-plugin-tokudb > -drwxr-xr-x root/root ./ > -drwxr-xr-x root/root ./etc/ > -drwxr-xr-x root/root ./etc/mysql/ > -drwxr-xr-x root/root ./etc/mysql/mariadb.conf.d/ > --rw-r--r-- root/root ./etc/mysql/mariadb.conf.d/tokudb.cnf > -drwxr-xr-x root/root ./usr/ > -drwxr-xr-x root/root ./usr/bin/ > --rwxr-xr-x root/root ./usr/bin/tokuftdump > -drwxr-xr-x root/root ./usr/lib/ > -drwxr-xr-x root/root ./usr/lib/x86_64-linux-gnu/ > -drwxr-xr-x root/root ./usr/lib/x86_64-linux-gnu/mariadb18/ > -drwxr-xr-x root/root ./usr/lib/x86_64-linux-gnu/mariadb18/plugin/ > --rw-r--r-- root/root ./usr/lib/x86_64-linux-gnu/mariadb18/plugin/ha_tokudb.so > -drwxr-xr-x root/root ./usr/share/ > -drwxr-xr-x root/root ./usr/share/doc/ > -drwxr-xr-x root/root ./usr/share/doc/mariadb-plugin-tokudb/ > --rw-r--r-- root/root > ./usr/share/doc/mariadb-plugin-tokudb/changelog.Debian.gz > --rw-r--r-- root/root ./usr/share/doc/mariadb-plugin-tokudb/copyright > -drwxr-xr-x root/root ./usr/share/doc/mariadb-plugin-tokudb/README.md/ > --rw-r--r-- root/root > ./usr/share/doc/mariadb-plugin-tokudb/README.md/README.md.gz > -drwxr-xr-x root/root ./usr/share/man/ > -drwxr-xr-x root/root ./usr/share/man/man1/ > --rw-r--r-- root/root ./usr/share/man/man1/tokuftdump.1.gz > - > -mariadb-plugin-tokudb-dbgsym > -drwxr-xr-x root/root ./ > -drwxr-xr-x root/root ./usr/ > -drwxr-xr-x root/root ./usr/lib/ > -drwxr-xr-x root/root ./usr/lib/debug/ > -drwxr-xr-x root/root ./usr/lib/debug/.build-id/ > -drwxr-xr-x root/root ./usr/lib/debug/.build-id/d9/ > --rw-r--r-- root/root > ./usr/lib/debug/.build-id/d9/72c47905eb64c2b1755e086ae77db8ffa2b004.debug > -drwxr-xr-x root/root ./usr/lib/debug/.build-id/fd/ > --rw-r--r-- root/root > ./usr/lib/debug/.build-id/fd/7bb08c929158052c7eb0428c7180568374eb29.debug > -drwxr-xr-x root/root ./usr/share/ > -drwxr-xr-x root/root ./usr/share/doc/ > -lrwxrwxrwx root/root ./usr/share/doc/mariadb-plugin-tokudb-dbgsym > - > mariadb-server-10.1 > drwxr-xr-x root/root ./ > drwxr-xr-x root/root ./etc/ > @@ -678,6 +639,9 @@ > -rw-r--r-- root/root ./usr/share/man/man1/aria_ftdump.1.gz > -rw-r--r-- root/root ./usr/share/man/man1/aria_pack.1.gz > -rw-r--r-- root/root ./usr/share/man/man1/aria_read_log.1.gz > +-rw-r--r-- root/root ./usr/share/man/man1/galera_new_cluster.1.gz > +-rw-r--r-- root/root ./usr/share/man/man1/galera_recovery.1.gz > +-rw-r--r-- root/root ./usr/share/man/man1/mariadb-service-convert.1.gz > -rw-r--r-- root/root ./usr/share/man/man1/msql2mysql.1.gz > -rw-r--r-- root/root ./usr/share/man/man1/myisamchk.1.gz > -rw-r--r-- root/root ./usr/share/man/man1/myisam_ftdump.1.gz > @@ -688,6 +652,7 @@ > -rw-r--r-- root/root ./usr/share/man/man1/mysql_convert_table_format.1.gz > -rw-r--r-- root/root ./usr/share/man/man1/mysqld_multi.1.gz > -rw-r--r-- root/root ./usr/share/man/man1/mysqld_safe.1.gz > +-rw-r--r-- root/root ./usr/share/man/man1/mysqld_safe_helper.1.gz > -rw-r--r-- root/root ./usr/share/man/man1/mysqlhotcopy.1.gz > -rw-r--r-- root/root ./usr/share/man/man1/mysql_install_db.1.gz > -rw-r--r-- root/root ./usr/share/man/man1/mysql_plugin.1.gz > @@ -921,8 +886,8 @@ > -rw-r--r-- root/root > ./usr/lib/debug/.build-id/09/df4fe8db8d9dbf6167dbca178e9e6fc785891c.debug > drwxr-xr-x root/root ./usr/lib/debug/.build-id/33/ > -rw-r--r-- root/root > ./usr/lib/debug/.build-id/33/de9dda2392436
Bug#852709: [debian-mysql] Bug#852709: Patch
Patch actually attached this time...
Regards,
James
>From 47cc704d11d8991818fb7bf5ebff63c5a727da01 Mon Sep 17 00:00:00 2001
From: James Clarke
Date: Thu, 26 Jan 2017 21:46:28 +
Subject: [PATCH] Allow mariadb-plugin-tokudb/mroonga on non-linux and
non-release arches
---
debian/control | 5 +++--
debian/rules | 6 +-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 5cca4947..852aa7ac 100644
--- a/debian/control
+++ b/debian/control
@@ -360,7 +360,7 @@ Description: OQGraph storage engine for MariaDB
This package contains the OQGraph plugin for MariaDB.
Package: mariadb-plugin-tokudb
-Architecture: amd64
+Architecture: base-any-any-amd64
Depends: mariadb-server-10.1, ${misc:Depends}, ${shlibs:Depends}
Breaks: mariadb-server-10.0, mariadb-server-10.1 (<< ${source:Version})
Replaces: mariadb-server-10.0, mariadb-server-10.1 (<< ${source:Version})
@@ -371,7 +371,8 @@ Description: TokuDB storage engine for MariaDB
This package contains the TokuDB plugin for MariaDB.
Package: mariadb-plugin-mroonga
-Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el
+# Supports little-endian architectures only
+Architecture: any-i386 any-ia64 any-alpha any-amd64 any-arm any-arm64 any-mipsel any-mipsr6el any-mips64el any-mips64r6el any-nios2 any-powerpcel any-ppc64el any-sh3 any-sh4 any-tilegx
Depends: mariadb-server-10.1, ${misc:Depends}, ${shlibs:Depends}
Breaks: mariadb-server-10.0, mariadb-server-10.1 (<< ${source:Version})
Replaces: mariadb-server-10.0, mariadb-server-10.1 (<< ${source:Version})
diff --git a/debian/rules b/debian/rules
index f0b3aec4..abcae5fe 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,8 @@ BUILDDIR := builddir
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_SYSTEM ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_SYSTEM)
DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
+DEB_BUILD_ARCH_ABI ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_ABI)
+DEB_BUILD_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU)
DEB_BUILD_ARCH_OS ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
DEBVERSION := $(shell dpkg-parsechangelog | awk '/^Version: / { print $$2 }' | sed 's/^.*-//' )
DEB_SOURCE_PACKAGE ?= $(strip $(shell egrep '^Source: ' debian/control | cut -f 2 -d ':'))
@@ -48,7 +50,9 @@ else
endif
# Skip TokuDB if arch is not amd64
-ifneq ($(ARCH), amd64)
+# Skipped on the x32 ABI too; untested, but unlikely to work given i386 is not
+# supported.
+ifneq ($(DEB_HOST_ARCH_ABI)-$(DEB_HOST_ARCH_CPU), base-amd64)
CMAKEFLAGS += -DWITHOUT_TOKUDB=true
endif
--
2.11.0
Bug#852709: [debian-mysql] Bug#852709: Patch
On Thu, Jan 26, 2017 at 09:42:01PM +, James Clarke wrote:
> On Thu, 26 Jan 2017 22:07:51 +0200 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=
> wrote:
> > Great work Dieter!
> >
> > I'll merge and upload immediately. I just hope this will be in time
> > before the Feb 5th freeze... Because the unstable->testing counter
> > resets on every upload, all old fixes are still pending +10 days after
> > this upload.
>
> That's not right. You've ignored all of kfreebsd (and hurd);
> kfreebsd-amd64 currently builds mroonga but not tokudb, but in theory it
> could build both. I was about to finalise a patch myself which does it
> more thoroughly.
I have attached a patch to fix this. It also re-enables mroonga on many
of the ports architectures, which were neglected, as well as those that
aren't even available in the archive. Generated with:
> awk '/^#/{next;} $5 == "little"{print "any-"$1}' /usr/share/dpkg/cputable |
> xargs
Regards,
James
Bug#852709: [debian-mysql] Bug#852709: Patch
On Thu, 26 Jan 2017 22:07:51 +0200 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= wrote: > Great work Dieter! > > I'll merge and upload immediately. I just hope this will be in time > before the Feb 5th freeze... Because the unstable->testing counter > resets on every upload, all old fixes are still pending +10 days after > this upload. That's not right. You've ignored all of kfreebsd (and hurd); kfreebsd-amd64 currently builds mroonga but not tokudb, but in theory it could build both. I was about to finalise a patch myself which does it more thoroughly. Regards, James
Bug#852709: Modifies debian/control during the build
Source: mariadb-10.1 Version: 10.1.21-2 Severity: serious During the build, mariadb-plugin-tokudb and mariadb-plugin-mroonga get removed from debian/control if their binaries are not built. This is relevant for release architectures - mariadb-plugin-tokudb only seems to be built on amd64, and mariadb-plugin-mroonga is missing on at least s390x. https://ftp-master.debian.org/REJECT-FAQ.html clearly states this isn't allowed for *adding* new binary packages, and implies that it also isn't allowed for *removing* them; having asked on IRC I was not alone in thinking that RC is justified.
Bug#852434: cowbuilder: does not work any more
Control: severity -1 wishlist Control: tags -1 wontfix Control: retitle -1 cowbuilder: No longer accepts command later in arguments list > On 24 Jan 2017, at 12:07, Thorsten Glaser wrote: > > Package: cowbuilder > Version: 0.84 > Severity: grave > Justification: renders package unusable > > tglase@tglase:/tmp $ c dpo --hookdir /home/tglase/.hook/ --debbuildopts > "-m'$DEBEMAIL'" --binary-arch --build glibc_2.24-9.dsc > + sudo env 'DIST=dpo' 'LANG=C' 'LC_CTYPE=C' 'LC_NUMERIC=C' 'LC_TIME=C' > 'LC_COLLATE=C' 'LC_MONETARY=C' 'LC_MESSAGES=C' 'LC_PAPER=C' 'LC_NAME=C' > 'LC_ADDRESS=C' 'LC_TELEPHONE=C' 'LC_MEASUREMENT=C' 'LC_IDENTIFICATION=C' > 'LC_ALL=C' 'LD_LIBRARY_PATH=/usr/lib/libeatmydata' > 'LD_PRELOAD=libeatmydata.so' cowbuilder --hookdir /home/tglase/.hook/ > --debbuildopts '-m'\''Thorsten Glaser '\' --binary-arch > --build glibc_2.24-9.dsc > E: Unknown operation: --hookdir You will note from the cowbuilder manpage* that the command should be given as the first argument, just like pbuilder. Past versions of cowbuilder would accept the command anywhere in the argument list due to an implementation detail (it used getopt_long). For 0.84, I added the ability to say "build" or "b" instead of "--build", like pbuilder accepts. As a result of implementing this, I removed the "--build" and others from the getopt_long list, and instead parsed the first argument manually, since getopt_long doesn't let you tell it about arguments that don't start with "-". While in theory I could scan the entire list, I don't want to do this. Please fix your script to pass "--build" (or "build"/"b") as the *first* argument. Regards, James * This includes old versions; it was made clear in version 0.22: > SYNOPSIS >cowbuilder [commands] [options]
Bug#843032: qemu-user-static: Upgrade fails: unable to close /proc/sys/fs/binfmt_misc/register
On Mon, Nov 07, 2016 at 12:51:52PM +, Riku Voipio wrote: > On Sun, Nov 06, 2016 at 03:59:12PM +, James Cowgill wrote: > > On Thu, 3 Nov 2016 13:15:47 +0300 Michael Tokarev wrote: > > > 03.11.2016 12:46, Toby Speight wrote: > > > > I was able to work around this issue by hand-editing the postinst it to > > > > add > > > > '|mips*' to the end of $omit (luckily, I don't need MIPS emulation on my > > > > systems). > > > > > > > > The one thing that stands out about the MIPS registration is that the > > > > magic > > > > and mask are much longer than for other systems - is it possible that > > > > the > > > > kernel can't handle such long patterns? If so, can this be detected and > > > > avoided? > > > > > > This change was introduced very recently, see #829243. But it works fine > > > on my system. I wonder if 3.16 kernel is unable to process that binfmt > > > while 4.1+ can handle it... Oh well. > > > > Looks like this kernel commit added support for longer formats: > > bbaecc088245e840e59a5abe23d69cf7748b3c88 > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/binfmt_misc.c?id=bbaecc088245e840e59a5abe23d69cf7748b3c88 > > > > This is probably what causes this. The above commit exists only in 3.18+ > > The attached patch only registers the new longer patterns on 3.18+. I still > need another round for the patch. The kernel version check requires bash, and > the naive >> to > change doesn't actually make the script a bash script. But > before I invest more time into this I'd like to know if others agree this > change > is the right way. > > The other option is to revert the change from #829243 until a better way to > handle the change is done. Something needs to be done about this in testing. Upgrades from Jessie to Stretch are currently broken, since those will be running a 3.16 kernel when the upgraded version's postinst script is run. I verified this on a clean, minimal Jessie install (nothing selected in tasksel): 1. Install qemu-user-static 2. Change APT sources to stretch 3. apt-get update 4. apt-get upgrade - fails Regards, James
Bug#850453: in cowdancer marked as pending
Control: tag 850453 pending Hello, Bug #850453 in cowdancer reported by you has been fixed in the Git repository. You can see the commit message below, and you can check the diff of the fix at: https://anonscm.debian.org/git/pbuilder/cowdancer.git/commit/?id=d36c911 (this message was generated automatically based on the git commit message) --- commit d36c9110a6993b4845649a3aa992961b1a6b4426 Author: James Clarke Date: Fri Jan 6 19:02:11 2017 + Symlink multiarch path to non-multiarch path This is not ideal, since some users may already have updated their unstable chroots to 0.82, but unstable is unstable, and trying to make upgrades from 0.82 work would be a nightmare. Sorry for the breakage. Closes: #850453
Bug#850453: Non-fatal harmful errors upgrading from pre-0.82 to 0.82 under cow-shell
Package: cowdancer Version: 0.82 Severity: serious Running cowbuilder --update gives a load of the following errors: > ERROR: ld.so: object '/usr/lib/cowdancer/libcowdancer.so' from LD_PRELOAD > cannot be preloaded (cannot open shared object file): ignored. The entire update process runs under cow-shell, so when a pre-0.82 chroot is upgraded to 0.82 (which moved libcowdancer.so to a multiarch path), future processes run in the same session can no longer load libcowdancer.so, as they still think it's in the old place. Either a compatibility symlink needs to be provided, or if that cannot be done so that pre-0.82 *and* 0.82 chroots can be upgraded without these errors, the file should just be duplicated for the stretch release in the old and new paths. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cowdancer depends on: ii libc62.24-8 ii libncurses5 6.0+20161126-1 ii libtinfo56.0+20161126-1 cowdancer recommends no packages. cowdancer suggests no packages. -- no debconf information
Bug#849136: gdk-pixbuf FTBFS on mips64el: pixbuf-randomly-modified test failures
On Sat, Dec 24, 2016 at 08:32:26AM +0100, Petter Reinholdtsen wrote: > [Adrian Bunk] > > https://buildd.debian.org/status/fetch.php?pkg=gdk-pixbuf&arch=mips64el&ver=2.36.2-1&stamp=1482373676 > [...] > > ERROR: pixbuf-randomly-modified > > I tried reproducing this on eller.debia.org, but when I built it there the > test was successful. I tried again, and it built as it should now too. > > Is there some difference between the porterbox and the autobuilder that > could be relevant? If not, I guess the randomness part of the test someone > affected the result. :( It also FTBFS on sparc64 due to crashing in pixbuf-randomly-modified (although with SIGSEGV instead)[0], but I couldn't reproduce it, even using the same random seed as in the build log. I gave it back and it rebuilt successfully (albeit on a different buildd). I suggest it is given back on mips64el and the severity of this lowered (unless this build also fails). Regards, James [0] https://buildd.debian.org/status/fetch.php?pkg=gdk-pixbuf&arch=sparc64&ver=2.36.2-1&stamp=1482373648
Bug#844233: python-passlib: FTBFS with probability of 0.22% due to non-deterministic testsuite
Control: retitle -1 python-passlib: FTBFS with probability of 0.46% due to
non-deterministic testsuite
On Sun, Nov 13, 2016 at 04:25:30PM +, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed
> that python-passlib's testsuite will non-determinstically FTBFS:
>
> ==
> FAIL: test_getrandstr (passlib.tests.test_utils.MiscTest)
> --
> Traceback (most recent call last):
> File "/build/python-passlib-1.6.5/2nd/passlib/tests/test_utils.py", line
> 129, in test_getrandstr
> self.assertEqual(sorted(set(x)), [u('a'),u('b'),u('c')])
> AssertionError: Lists differ: [u'a', u'b'] != [u'a', u'b', u'c']
>
> Second list contains 1 additional elements.
> First extra element 2:
> u'c'
>
> - [u'a', u'b']
> + [u'a', u'b', u'c']
> ?++
>
> This is because of:
>
> 125 x = f(u('abc'), 16)
> 126 y = f(u('abc'), 16)
> 127 self.assertIsInstance(x, unicode)
> 128 self.assertNotEqual(x,y)
> 129 self.assertEqual(sorted(set(x)), [u('a'),u('b'),u('c')])
>
> If the random string ``x`` doesn't contain a certain character, the
> assertion will fail. By my quick calculation this will happen with a
> probability of (2/3)^(16-1).
I believe it's actually (3C2)*(2/3)^16 - (3C1)*(1/3)^16 ~= 0.46% (the
subtracted value is negligible).
> It will also FTBFS if it generates the exact same random string, but
> that seems a little more unlikely.
P = (1/3)^16 = 2.3e-8 or 0.023%, which isn't quite as absurdly small
as you might think.
Regards,
James
Bug#844115: Version tracking no longer knows about unstable versions
Control: tags -1 patch
Control: user bugs.debian@packages.debian.org
Control: usertag -1 bugscan
On Sat, Nov 12, 2016 at 05:13:15PM +, Mattia Rizzolo wrote:
> On Sat, Nov 12, 2016 at 06:06:35PM +0200, Adrian Bunk wrote:
> > This is likely caused by
> > https://lists.debian.org/debian-devel-announce/2016/11/msg5.html
>
> Not only this, unknown-package@ receive email of packages with known
> maintainer.
>
> You can have a look at archive-unknown-package on quantz to see them,
> for example I just receive notification that 835685 is closed, but that
> bug really is on a package with a maintainer.
> (removing myself from the alias until this is fixed).
Attached is a patch for bugscan which I believe should fix the issue.
It has been semi-tested (I extracted the methods to a separate file,
stubbed out the config and ran readpackages), but it's not exactly easy
to test properly...
Regards,
James
>From 8984ec2d25b0d0c73423350cc29139cd71237926 Mon Sep 17 00:00:00 2001
From: James Clarke
Date: Sat, 12 Nov 2016 22:29:25 +
Subject: [PATCH] Handle .xz, .bz2 and uncompressed Sources and Packages files
---
scanlib.pm | 39 +++
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/scanlib.pm b/scanlib.pm
index 7cd2e63..ee995ec 100644
--- a/scanlib.pm
+++ b/scanlib.pm
@@ -30,7 +30,27 @@ package scanlib;
our (%maintainer,%section,%packagelist,%debbugssection,%bugs);
-# Read the list of maintainer
+sub findcompressedfile {
+ my ($file) = @_;
+ my @types = (
+ { cat => "xzcat", ext => ".xz" },
+ { cat => "bzcat", ext => ".bz2" },
+ { cat => "zcat", ext => ".gz" },
+ { cat => "cat", ext => "" },
+ );
+ for my $type (@types) {
+ my $cat = $type->{cat};
+ my $ext = $type->{ext};
+ my $fileext = $file . $ext;
+ if (-f $fileext and system("which $cat >/dev/null 2>&1") == 0) {
+ return ($fileext, $cat);
+ }
+ }
+ die "Unable to find compressed file for $file";
+}
+
+
+# Read the list of maintainer
sub readmaintainers() {
my $pkg;# Name of package
my $mnt;# Maintainer name &
email
@@ -55,8 +75,9 @@ sub readsources {
my ($root,$archive) = @_;
for my $sect (@bugcfg::sections) {
- open(P, "zcat $root/$sect/source/Sources.gz|")
- or die open "open: $sect sourcelist: $!\n";
+ my ($file, $cat) =
findcompressedfile("$root/$sect/source/Sources");
+ open(P, "$cat $file|")
+ or die "open: $sect sourcelist ($cat $file): $!\n";
while () {
chomp;
next unless m/^Package:\s/;
@@ -71,23 +92,25 @@ sub readpackages {
my ($root,$archive) = @_;
for my $arch ( @bugcfg::architectures ) {
for my $sect ( @bugcfg::sections) {
- open(P, "zcat $root/$sect/binary-$arch/Packages.gz|")
- or die "open:
$root/$sect/binary-$arch/Packages.gz: $!\n";
+ my ($file, $cat) =
findcompressedfile("$root/$sect/binary-$arch/Packages");
+ open(P, "$cat $file|")
+ or die "open: $cat $file: $!\n";
while () {
chomp;
next unless m/^Package:\s/; # We're only
interested in the packagenames
s/^Package:\s*//; # Strip
the fieldname
$section{$_} = "$archive/$sect";
- print "$root/$sect/binary-$arch/Packages.gz\n"
if ($_ eq 'xtla');
+ print "$file\n" if ($_ eq 'xtla');
}
close(P);
}
}
# handle the source packages
for my $sect (@bugcfg::sections) {
+ my ($file, $cat) = findcompressedfile("$root/$sect/source/Sources");
my $fh;
- open($fh,'-|','zcat',"$root/$sect/source/Sources.gz") or
- die "Unable to open zcat $root/$sect/source/Sources.gz for reading:
$!";
+ open($fh,'-|',"$cat","$file") or
+ die "Unable to open $cat $file for reading: $!";
while (<$fh>) {
chomp;
next unless m/^Package:\s/; # We're only interested in the
packagenames
--
2.10.2
Bug#812160: qtwebkit: FTBFS with GCC 6: symbol changes
Hi Lisandro, On Fri, Jan 22, 2016 at 01:42:25PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Just for the sake of completeness, we are trying to remove this package from > the archive. We still have quite a lot of packages to fix, but we hope to get > this done before Stretch's release. This is blocking src:kde4libs from being built on some of the ports, which is obviously an important package. I see Pino committed a fix almost 2 months ago; could one of you please upload this? Regards, James signature.asc Description: PGP signature
Bug#841124: elfutils: diff for NMU version 0.166-2.2
Control: tags 841124 + patch Dear maintainer, I've prepared an NMU for elfutils (versioned as 0.166-2.2). The diff is attached to this message. Regards, James diff -Nru elfutils-0.166/debian/changelog elfutils-0.166/debian/changelog --- elfutils-0.166/debian/changelog 2016-10-07 15:16:12.0 +0100 +++ elfutils-0.166/debian/changelog 2016-10-18 08:13:34.0 +0100 @@ -1,3 +1,11 @@ +elfutils (0.166-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * testsuite-amd64-fix-backtrace-native.patch: Backport upstream patch to fix +FTBFS on amd64 (Closes: #841124) + + -- James Clarke Tue, 18 Oct 2016 08:13:34 +0100 + elfutils (0.166-2.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru elfutils-0.166/debian/patches/series elfutils-0.166/debian/patches/series --- elfutils-0.166/debian/patches/series2016-07-23 17:46:11.0 +0100 +++ elfutils-0.166/debian/patches/series2016-10-18 08:12:01.0 +0100 @@ -10,3 +10,4 @@ 0003-Add-mips-n64-relocation-format-hack.patch hurd_path.patch ignore_strmerge.diff +testsuite-amd64-fix-backtrace-native.patch diff -Nru elfutils-0.166/debian/patches/testsuite-amd64-fix-backtrace-native.patch elfutils-0.166/debian/patches/testsuite-amd64-fix-backtrace-native.patch --- elfutils-0.166/debian/patches/testsuite-amd64-fix-backtrace-native.patch 1970-01-01 01:00:00.0 +0100 +++ elfutils-0.166/debian/patches/testsuite-amd64-fix-backtrace-native.patch 2016-10-18 08:12:51.0 +0100 @@ -0,0 +1,220 @@ +From 9008499a5276c45b37bc0adb47e7ad227e6ba2a9 Mon Sep 17 00:00:00 2001 +From: Mark Wielaard +Date: Thu, 25 Aug 2016 17:17:23 +0200 +Subject: [PATCH 1/1] tests: Simplify backtrace-native tests. Drop raise jmp + patching for x86_64. + +The backtrace-native[-biarch] testcase was a little too clever in places +making it unreliable. + +On x86_64 we tried to make an interesting backtrace by catching the +first signal and then replacing the pc with the address of the first +instruction of a function. Then we would raise a new signal, through +ptrace, to create a backtrace that went from a signal frame into a +frame at the start of a function. That way we could check that we were +trying to fetch the correct CFI for the (jmp) function even at the +first instruction (normally we would substract one from the return +address to get at the call address). + +This works as long as the CFI for the jmp() function is identical to +the CFI for the raise() function that we "patched away". Unfortunately +on Fedora rawhide glibc has a rewritten raise() implementation that has +different CFI, in particular the CFA is calculated differently. Making +the testcase fail because we cannot properly unwind from jmp(). +So this special x86_64 case has been disabled (the code is still there +in case we find another way to test this in a more reliable way). + +On Ubuntu there have been spurious testcase failures because +see_exec_module found two Dwfl_Modules with the same path. This would +trigger an assert. Although this might indicate some issue (maybe we +are not parsing the proc/pid/map correctly?) it isn't clear that it +really is a bug. Since the assert is not very helpful finding any +actual bug and for the testcase it is only necessary that the first +Dwfl_Module that represents the executable is found we just pick that +Dwfl_Module and don't iterate through any of the others. + +Signed-off-by: Mark Wielaard +--- + tests/backtrace-child.c | 18 ++ + tests/backtrace.c | 39 +-- + 3 files changed, 51 insertions(+), 22 deletions(-) + +diff --git a/tests/backtrace-child.c b/tests/backtrace-child.c +index 40e7b32..cf4547c 100644 +--- a/tests/backtrace-child.c b/tests/backtrace-child.c +@@ -1,5 +1,5 @@ + /* Test child for parent backtrace test. +- Copyright (C) 2013 Red Hat, Inc. ++ Copyright (C) 2013, 2016 Red Hat, Inc. +This file is part of elfutils. + +This file is free software; you can redistribute it and/or modify +@@ -19,7 +19,8 @@ +--ptraceme will call ptrace (PTRACE_TRACEME) in the two threads. +--gencore will call abort () at its end. +Main thread will signal SIGUSR2. Other thread will signal SIGUSR1. +- On x86_64 only: ++ There used to be a difference between x86_64 and other architectures. ++ To test getting a signal at the very first instruction of a function: + PC will get changed to function 'jmp' by backtrace.c function + prepare_thread. Then SIGUSR2 will be signalled to backtrace-child + which will invoke function sigusr2. +@@ -66,8 +67,17 @@ +# 5 0xf77c1a48 - 1 start +# 6 0xf77699da - 1 start_thread +# 7 0xf769bbfe - 1 __clone ++ ++ But the raise jmp patching was unreliable. It depends on the CFI for the raise() ++ function in glibc to be the same as for the jmp() function. This is not always ++ the case. Some newer gli
Bug#841124: FTBFS on amd64
Control: tags -1 patch fixed-upstream
On Mon, Oct 17, 2016 at 08:40:21PM +0100, James Clarke wrote:
> Source: elfutils
> Version: 0.166-2.1
> Severity: serious
>
> Hi,
> My NMU (#832584) FTBFS on amd64[1]. However, the only changes were
> adding Build-Depends on sparc64, and 0.166-2 itself FTBFS in a clean
> amd64 chroot (log attached), so it seems the more recent dependencies
> are problematic.
>
> Important part of the (buildd) log:
>
> > FAIL: run-backtrace-native.sh
> > =
> >
> > 0x7fa73d9dc000 0x7fa73dd76000 /lib/x86_64-linux-gnu/libc-2.24.so
> > 0x7fa73dd7a000 0x7fa73df93000 /lib/x86_64-linux-gnu/libpthread-2.24.so
> > 0x7fa73df97000 0x7fa73e1bb000 /lib/x86_64-linux-gnu/ld-2.24.so
> > 0x7fa73e1bc000 0x7fa73e3bf000 / PKGBUILDDIR /tests/backtrace-child
> > 0x7ffe5aaf5000 0x7ffe5aaf7000 [vdso: 16415]
> > TID 16415:
> > # 0 0x7fa73dd8afdf raise
> > # 1 0x7fa73e1bcad5 - 1 main
> > # 2 0x7fa73d9fc2b1 - 1 __libc_start_main
> > # 3 0x7fa73e1bcc0a - 1 _start
> > TID 16416:
> > # 0 0x7fa73dd8afdf raise
> > # 1 0x7fa73e1bcd6b - 1 sigusr2
> > # 2 0x7fa73da0f040 (null)
> > # 3 0x7fa73e1bce70 jmp
> > # 4 0xa8428197 - 1 (null)
> > backtrace: backtrace.c:128: callback_verify: Assertion `symname != NULL
> > && strcmp (symname, "stdarg") == 0' failed.
> > ./test-subr.sh: line 84: 16412 Aborted
> > LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
> > $VALGRIND_CMD "$@"
> > # 1 0x7fa73e1bcad5 - 1 main
> > backtrace-child: neither empty nor just out of DWARF
> > FAIL run-backtrace-native.sh (exit status: 1)
>
> Regards,
> James
>
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=amd64&ver=0.166-2.1&stamp=1476727320
This was fixed upstream by [1]. I intend to perform another NMU to fix
this; please let me know if you disagree.
Regards,
James
[1]
https://git.fedorahosted.org/cgit/elfutils.git/commit/?id=9008499a5276c45b37bc0adb47e7ad227e6ba2a9
signature.asc
Description: PGP signature
Bug#841124: FTBFS on amd64
Source: elfutils
Version: 0.166-2.1
Severity: serious
Hi,
My NMU (#832584) FTBFS on amd64[1]. However, the only changes were
adding Build-Depends on sparc64, and 0.166-2 itself FTBFS in a clean
amd64 chroot (log attached), so it seems the more recent dependencies
are problematic.
Important part of the (buildd) log:
> FAIL: run-backtrace-native.sh
> =
>
> 0x7fa73d9dc000 0x7fa73dd76000 /lib/x86_64-linux-gnu/libc-2.24.so
> 0x7fa73dd7a000 0x7fa73df93000 /lib/x86_64-linux-gnu/libpthread-2.24.so
> 0x7fa73df97000 0x7fa73e1bb000 /lib/x86_64-linux-gnu/ld-2.24.so
> 0x7fa73e1bc000 0x7fa73e3bf000 / PKGBUILDDIR /tests/backtrace-child
> 0x7ffe5aaf5000 0x7ffe5aaf7000 [vdso: 16415]
> TID 16415:
> # 0 0x7fa73dd8afdf raise
> # 1 0x7fa73e1bcad5 - 1 main
> # 2 0x7fa73d9fc2b1 - 1 __libc_start_main
> # 3 0x7fa73e1bcc0a - 1 _start
> TID 16416:
> # 0 0x7fa73dd8afdf raise
> # 1 0x7fa73e1bcd6b - 1 sigusr2
> # 2 0x7fa73da0f040 (null)
> # 3 0x7fa73e1bce70 jmp
> # 4 0xa8428197 - 1 (null)
> backtrace: backtrace.c:128: callback_verify: Assertion `symname != NULL
> && strcmp (symname, "stdarg") == 0' failed.
> ./test-subr.sh: line 84: 16412 Aborted
> LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
> $VALGRIND_CMD "$@"
> # 1 0x7fa73e1bcad5 - 1 main
> backtrace-child: neither empty nor just out of DWARF
> FAIL run-backtrace-native.sh (exit status: 1)
Regards,
James
[1]
https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=amd64&ver=0.166-2.1&stamp=1476727320
[0mI: Copying COW directory[0m
[0mI: forking: rm -rf /var/cache/pbuilder/build/cow.17575[0m
[0mI: forking: cp -al /var/cache/pbuilder/base.cow
/var/cache/pbuilder/build/cow.17575[0m
[0mI: removed stale ilistfile /var/cache/pbuilder/build/cow.17575/.ilist[0m
[0mI: forking: chroot /var/cache/pbuilder/build/cow.17575
cowdancer-ilistcreate /.ilist 'find . -xdev -path ./home -prune -o \( \( -type
l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ''[0m
[0mI: Invoking pbuilder[0m
[0mI: forking: pbuilder build --binary-arch --buildplace
/var/cache/pbuilder/build/cow.17575 --buildresult /var/cache/pbuilder/result/
--binary-arch --no-targz --internal-chrootexec 'chroot
/var/cache/pbuilder/build/cow.17575 cow-shell'
/home/james/src/elfutils/elfutils_0.166-2.dsc[0m
[0mI: Running in no-targz mode[0m
[0mI: using fakeroot in build.[0m
[0mI: pbuilder: network access will be disabled during build[0m
[0mI: Current time: Mon Oct 17 20:16:01 BST 2016[0m
[0mI: pbuilder-time-stamp: 1476731761[0m
[0mI: copying local configuration[0m
[0mI: mounting /proc filesystem[0m
[0mI: mounting /sys filesystem[0m
[0mI: mounting /run/shm filesystem[0m
[0mI: mounting /dev/pts filesystem[0m
[0mI: Mounting /pbuilder-repo[0m
[0mI: policy-rc.d already exists[0m
[0mI: Obtaining the cached apt archive contents[0m
[0mI: Installing the build-deps[0m
-> Attempting to parse the build-deps
-> Considering build-depdebhelper (>= 9)
-> Trying to add debhelper
-> Considering build-dep autotools-dev
-> Trying to add autotools-dev
-> Considering build-dep autoconf
-> Trying to add autoconf
-> Considering build-dep automake
-> Trying to add automake
-> Considering build-dep bzip2
-> Trying to add bzip2
-> Considering build-dep zlib1g-dev
-> Trying to add zlib1g-dev
-> Considering build-dep libbz2-dev
-> Trying to add libbz2-dev
-> Considering build-dep liblzma-dev
-> Trying to add liblzma-dev
-> Considering build-dep m4
-> Trying to add m4
-> Considering build-dep gettext
-> Trying to add gettext
-> Considering build-dep gawk
-> Trying to add gawk
-> Considering build-dep dpkg-dev (>= 1.16.1~)
-> Trying to add dpkg-dev
-> Considering build-dep gcc-multilib [any-amd64]
-> Trying to add gcc-multilib
-> Considering build-dep libc6-dbg [powerpc powerpcspe ppc64 ppc64el armel
armhf arm64]
-> This package is not for this architecture
-> Considering build-dep flex
-> Trying to add flex
-> Considering build-dep bison
-> Trying to add bison
-> Installing debhelper autotools-dev autoconf automake bzip2 zlib1g-dev
libbz2-dev liblzma-dev m4 gettext gawk dpkg-dev gcc-multilib flex bison
Reading package lists...
Building dependency tree...
Reading state information...
bzip2 is already the newest version (1.0.6-8).
dpkg-dev is already the newest version (1.18.10).
The following additional packages will be installed:
autopoint bsdmainutils dh-autoreconf dh-strip-nondeterminism file
gcc-6-multilib gettext-base groff-base intltool-debian lib32asan3
lib32atomic1 lib32cilkrts5 lib32gcc-6-dev lib32gcc1 lib32gomp1 lib32itm1
lib32mpx2 lib32quadmath0 lib32stdc++6 lib32ubsan0 libarchive-zip-perl
libbison-dev libbsd0 libc6-dev-i386 libc6-dev-x32 libc6-i386 libc6-x32
libcroco3 libffi6 libfile-stripnondeterminism-perl libfl-dev libglib2.0-0
libicu57 libmagic-mgc libmagic1 libpipeline1 libsigsegv2 libtimedate
Bug#840146: pbuilder: remove_packages checks for existence in host, not in chroot
Control: found -1 0.224 Control: severity -1 important Hi Thorsten, > On 8 Oct 2016, at 21:20, Thorsten Glaser wrote: > > Package: pbuilder > Version: 0.226.1 > Severity: serious > Justification: breaks basic use > > The remove_packages function in pbuilder-modules contains: > >if (dpkg -s "$pkg" 2>&1)>/dev/null ; then > > This obviously must be: > >if ($CHROOTEXEC dpkg -s "$pkg" 2>&1)>/dev/null ; then > > Because of this, I can’t “upgrade” (reads: switch between apt- and > aptitude-based resolvers) my sarge chroot any more. I agree, this is bad. However, if this is only affecting sarge chroots, I fail to see how this is release-critical. I understand it's a pain for your use, but it certainly does not break "basic use". If it's problematic for wheezy+ chroots, please feel free to change the severity back to serious. Regards, James
Bug#831823: in pbuilder marked as pending
Control: tag 831823 pending Hello, Bug #831823 in pbuilder reported by you has been fixed in the Git repository. You can see the commit message below, and you can check the diff of the fix at: https://anonscm.debian.org/git/pbuilder/pbuilder.git/commit/?id=8d69336 (this message was generated automatically based on the git commit message) --- commit 8d69336a654a37f03d2f72351d92a2a4934cdc66 Author: James Clarke Date: Tue Jul 19 22:26:06 2016 +0100 pbuilder-modules: Don't trash CHROOTEXEC when using eatmydata Closes: #831823
Bug#831823: cowbuilder: doesn't copy on write when using eatmydata
Control: reassign -1 pbuilder 0.225 Control: affects -1 cowbuilder cowdancer Hi Emilio, > On 19 Jul 2016, at 21:31, Emilio Pozuelo Monfort wrote: > > Package: cowbuilder > Version: 0.80 > Severity: grave > Tags: security Agreed. > I enabled eatmydata by adding EATMYDATA=eatmydata to my ~/.pbuilderrc, > and the result is that copy-on-write no longer works, making any modifications > persistent: > > eatmydata enabled > > emilio@tatooine:~$ sudo cowbuilder --login > root@tatooine:/# echo asdf > /etc/apt/sources.list > root@tatooine:/# logout > emilio@tatooine:~$ sudo cowbuilder --login > root@tatooine:/# cat /etc/apt/sources.list > asdf Confirmed. And an echo $LD_PRELOAD will show only libeatmydata. > Note how it has overwritten sources.list even though --save-after-login > wasn't passed. It also overwrites files during a package build, which > is a big problem. > > Now, with eatmydata disabled: > > First, restore sources.list: > > emilio@tatooine:~$ sudo cowbuilder --login --save-after-login > root@tatooine:/# cat /etc/apt/sources.list > asdf > root@tatooine:/# echo "deb http://ftp.es.debian.org/debian/ unstable main" > > /etc/apt/sources.list > root@tatooine:/# logout > > It is restored. Now, let's try to overwrite it without --save-after-login: > > emilio@tatooine:~$ sudo cowbuilder --login > root@tatooine:/# cat /etc/apt/sources.list > deb http://ftp.es.debian.org/debian/ unstable main > root@tatooine:/# echo asdf > /etc/apt/sources.list > root@tatooine:/# logout > emilio@tatooine:~$ sudo cowbuilder --login > root@tatooine:/# cat /etc/apt/sources.list > deb http://ftp.es.debian.org/debian/ unstable main > root@tatooine:/# > > It isn't overwritten. Turns out this is a pbuilder bug. When EATMYDATA=yes, it overwrites its CHROOTEXEC variable to just be a plain "chroot $BUILDPLACE eatmydata", and so cowbuilder’s cow-shell that adds libcowdancer to LD_PRELOAD is not executed. Fix incoming. Regards, James
Bug#822369: fixed in qemu 1:2.6+dfsg-1
Control: affects -1 - src:qemu On Thu, 19 May 2016 18:07:27 +0300 Michael Tokarev wrote: > Control: affects -1 - qemu > Control: That should have been src:qemu; fixed above :) Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#822849: qemubuilder: fix --update by checking for the correct asprintf() return value
Control: severity -1 important On Fri, May 13, 2016 at 03:25:44PM +0200, Michael Prokop wrote: > * Peter Pentchev [Thu Apr 28, 2016 at 01:28:54PM +0300]: > > Package: qemubuilder > > Version: 0.79 > > Severity: grave > > Tags: patch > > What's the rational for marking this as grave? > > (Asking because packages like jenkins-debian-glue are marked for > autoremoval because of their dependency on qemubuilder [related] > packages and this bug report doesn't look like it would satisfy > severity grave to me) Indeed, this should not be grave: > grave > makes the package in question unusable or mostly so, or causes > data loss, or introduces a security hole allowing access to the > accounts of users who use the package. > > serious > is a severe violation of Debian policy (roughly, it violates a > must or required directive), or, in the package maintainer's or > release manager's opinion, makes the package unsuitable for > release. > > important > a bug which has a major effect on the usability of a package, > without rendering it completely unusable to everyone. I class this as important. It does not make the package "completely unusable to everyone", as it only affects updating. There is a very simple workaround: re-create the image. Regards, James signature.asc Description: PGP signature
Bug#823705: src:firebird3.0: FTBFS On Big-Endian Architectures
Package: src:firebird3.0
Version: 3.0.0.32483.ds4-1
Severity: serious
Tags: upstream patch
Justification: Policy 4.2
Control: forwarded -1 https://github.com/FirebirdSQL/firebird/pull/21
As can be seen from
https://buildd.debian.org/status/package.php?p=firebird3.0&suite=experimental,
this package fails to build from source on any big-endian architecture. Please
apply the attached patch to fix this.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-
debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
--- a/src/jrd/Relation.cpp
+++ b/src/jrd/Relation.cpp
@@ -308,7 +308,7 @@
const USHORT relLockLen = relation->getRelLockKeyLength();
Lock* lock = FB_NEW_RPT(*pool, relLockLen) Lock(tdbb, relLockLen, lckType, relation);
- relation->getRelLockKey(tdbb, &lock->lck_key.lck_string[0]);
+ relation->getRelLockKey(tdbb, lock->getKeyString());
lock->lck_type = lckType;
switch (lckType)
--- a/src/jrd/btr.cpp
+++ b/src/jrd/btr.cpp
@@ -223,7 +223,7 @@
void BtrPageGCLock::disablePageGC(thread_db* tdbb, const PageNumber &page)
{
- page.getLockStr(lck_key.lck_string);
+ page.getLockStr(getKeyString());
LCK_lock(tdbb, this, LCK_read, LCK_WAIT);
}
@@ -235,7 +235,7 @@
bool BtrPageGCLock::isPageGCAllowed(thread_db* tdbb, const PageNumber& page)
{
BtrPageGCLock lock(tdbb);
- page.getLockStr(lock.lck_key.lck_string);
+ page.getLockStr(lock.getKeyString());
ThreadStatusGuard temp_status(tdbb);
--- a/src/jrd/cch.cpp
+++ b/src/jrd/cch.cpp
@@ -4055,7 +4055,7 @@
fb_assert(lock->lck_ast != NULL);
}
- bdb->bdb_page.getLockStr(lock->lck_key.lck_string);
+ bdb->bdb_page.getLockStr(lock->getKeyString());
if (LCK_lock_opt(tdbb, lock, lock_type, wait))
{
if (!lock->lck_ast)
--- a/src/jrd/lck.cpp
+++ b/src/jrd/lck.cpp
@@ -739,7 +739,7 @@
const SINT64 data =
dbb->dbb_lock_mgr->readData2(lock->lck_type,
- lock->lck_key.lck_string, lock->lck_length,
+ lock->getKeyString(), lock->lck_length,
lock->lck_owner_handle);
fb_assert(LCK_CHECK_LOCK(lock));
return data;
@@ -909,7 +909,7 @@
fb_assert(LCK_CHECK_LOCK(lock));
lock->lck_id = dbb->dbb_lock_mgr->enqueue(tdbb, statusVector, lock->lck_id,
- lock->lck_type, lock->lck_key.lck_string, lock->lck_length,
+ lock->lck_type, lock->getKeyString(), lock->lck_length,
level, lock->lck_ast, lock->lck_object, lock->lck_data, wait,
lock->lck_owner_handle);
@@ -1036,7 +1036,7 @@
if (!att->att_compatibility_table)
hash_allocate(lock);
- const USHORT hash_value = hash_func((UCHAR*) &lock->lck_key, lock->lck_length);
+ const USHORT hash_value = hash_func(lock->getKeyString(), lock->lck_length);
if (hash_slot)
*hash_slot = hash_value;
@@ -1061,7 +1061,7 @@
{
// check that the keys are the same
- if (!memcmp(lock->lck_key.lck_string, collision->lck_key.lck_string, lock->lck_length))
+ if (!memcmp(lock->getKeyString(), collision->getKeyString(), lock->lck_length))
return collision;
}
@@ -1426,7 +1426,7 @@
// with the local ast handler, passing it the lock block itself
lock->lck_id = dbb->dbb_lock_mgr->enqueue(tdbb, statusVector, lock->lck_id,
- lock->lck_type, (const UCHAR*) &lock->lck_key, lock->lck_length,
+ lock->lck_type, lock->getKeyString(), lock->lck_length,
level, external_ast, lock, lock->lck_data, wait, lock->lck_owner_handle);
// If the lock exchange failed, set the lock levels appropriately
--- a/src/jrd/lck.h
+++ b/src/jrd/lck.h
@@ -134,10 +134,19 @@
union
{
- UCHAR lck_string[1];
+ UCHAR lck_string[8];
SINT64 lck_long;
} lck_key; // Lock key string
+ UCHAR* getKeyString()
+ {
+#ifdef WORDS_BIGENDIAN
+ if (lck_length <= 8)
+ return &lck_key.lck_string[8-lck_length];
+#endif
+ return &lck_key.lck_string[0];
+ }
+
UCHAR lck_tail[1];// Makes the allocator happy
};
--- a/src/jrd/met.epp
+++ b/src/jrd/met.epp
@@ -1390,7 +1390,7 @@
const USHORT key_length = item->lock->lck_length;
AutoPtr temp_lock(FB_NEW_RPT(*tdbb->getDefaultPool(), key_length)
Lock(tdbb, key_length, LCK_dsql_cache));
- memcpy(temp_lock->lck_key.lck_string, item->lock->lck_key.lck_string, key_length);
+ memcpy(temp_lock->getKeyString(), item->lock->getKeyString(), key_length);
if (LCK_lock(tdbb, temp_lock, LCK_EX, LCK_WAIT))
LCK_release(tdbb, temp_lock);
@@ -4134,7 +4134,7 @@
item->locked = false;
item->lock = FB_NEW_RPT(*attachment->att_pool, key.length())
Lock(tdbb, key.length(), LCK_dsql_cache, item, blocking_ast_dsql_cache);
- memcpy(item->lock->lck_key.lck_string, key.c_str(), key.length());
+ memcpy(item->lock->getKeyString(), key.c_str(), key.length());
}
else
{
--- a/src/jrd/GlobalRWLock.cpp
+++ b/src/jrd/GlobalRWLock.cpp
@@ -78,7 +78,7 @@
cachedLock = FB_NEW_RPT(getPool(), lockLen)
Lo
Bug#822849: in cowdancer marked as pending
Control: tag 822849 pending Hello, Bug #822849 in cowdancer reported by you has been fixed in the Git repository. You can see the commit message below, and you can check the diff of the fix at: https://anonscm.debian.org/git/pbuilder/cowdancer.git/commit/?id=464f508 (this message was generated automatically based on the git commit message) --- commit 464f5088e5fbde3543c2749be611947f3fbda215 Author: Peter Pentchev Date: Thu Apr 28 13:17:22 2016 +0300 qemubuilder.c: Fixed inverted error check for asprintf breaking --update Closes: #822849
Bug#822849: qemubuilder: fix --update by checking for the correct asprintf() return value
Control: tags -1 confirmed Hi, > On 28 Apr 2016, at 11:28, Peter Pentchev wrote: > > Package: qemubuilder > Version: 0.79 > Severity: grave > Tags: patch > > Hi, > > Thanks for writing and maintaining cowdancer, cowbuilder, and qemubuilder! I didn’t write it originally, I just maintain it :) > What do you think about the attached patch that makes "qemubuilder --update" > actually work by checking the asprintf() return value for the correct error > indication? :) Thanks; good catch. I guess the lack of bug reports is an indication of how many people actually use qemubuilder! > Actually, the error checking after asprintf() in the whole cowdancer source > is a bit inconsistent - some places check for < 0 (or 0>), some places check > for the IMHO more precise == -1, some places don't check at all... I have > a larger change in the works that makes the checks a bit more consistent and > introduces a couple more of them, along with some other checks, but it's not > quite ready yet. Yeah... Personally I prefer the < 0 checks, even if it should never return a negative number other than -1, but not enough to go and change == -1 to < 0 everywhere. If there are any places where error checks are missing (which I seem to recall noticing when trawling through the code before), patches are definitely appreciated! Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#822470: qemu: FTBFS: error: redefinition of 'struct fsxattr'
Control: reassign -1 xfsprogs Control: forcemerge 822369 -1 Control: affects -1 src:qemu (hopefully I got it right this time…) > On 27 Apr 2016, at 00:05, James Clarke wrote: > > Control: package xfsprogs > Control: forcemerge 822369 -1 > Control: affects -1 src:qemu > > On Wed, 27 Apr 2016 00:02:56 +0200 John Paul Adrian Glaubitz > wrote: >>> This smells like a bug in the build environment, not in qemu. >>> There must be ability to include both headers without failing >>> to build. >> >> Not really. I can reproduce the problem here in my own environment, >> this used to work before. I assume there were incompatible changes >> in xfslibs-dev or the kernel. > > This was caused by > https://github.com/torvalds/linux/commit/2155355fda502e75cd942db101fbb08e1a826ba8 I meant https://github.com/torvalds/linux/commit/334e580a6f97e2e84d1c19a8679603956acaa622 > which moved the definition from xfs_fs.h to fs.h. Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#822470: qemu: FTBFS: error: redefinition of 'struct fsxattr'
Control: package xfsprogs Control: forcemerge 822369 -1 Control: affects -1 src:qemu On Wed, 27 Apr 2016 00:02:56 +0200 John Paul Adrian Glaubitz wrote: >> This smells like a bug in the build environment, not in qemu. >> There must be ability to include both headers without failing >> to build. > > Not really. I can reproduce the problem here in my own environment, > this used to work before. I assume there were incompatible changes > in xfslibs-dev or the kernel. This was caused by https://github.com/torvalds/linux/commit/2155355fda502e75cd942db101fbb08e1a826ba8 which moved the definition from xfs_fs.h to fs.h. Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#820795: polari: program segfaults (libgjs.so)
I have also run into this, but I found that upgrading libgjs0e to 1.45.3-1 from experimental resolves it. Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#704303: Patch for debian/copyright
tags 704303 patch thanks Hi, Please find attached a patch to include the full text for the MPL-1.1 and MPL-2.0 licenses inside debian/copyright. Regards, James debian-copyright.diff Description: Binary data
