Bug#833607: nmu: python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 & node-mapnik_3.5.13+dfsg-1~exp1
On Sun, 2016-08-07 at 00:11 +0200, Sebastiaan Couwenberg wrote: > The wanna-build documentation on release.d.o [0] mentions "If you are > asking for a dep-wait, an additional give-back is not needed", which > seems to be incorrect based on your reply. > > Is the documentation outdated perhaps? > > [0] https://release.debian.org/wanna-build.txt No, I think I was just impatient and forgot that while the state initially changed to "bd-uninstallable", the dep-wait would have become visible after the next trigger run, rather than immediately. (However, it appears that it didn't work, in any case: dose-builddebcheck changed state of node-mapnik_3.5.13+dfsg-1~exp1 (ppc64el) from dep-wait to Needs-Build dose-builddebcheck changed state of python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 (ppc64el) from dep-wait to Needs-Build followed by repeated failures. If there any other queries, please raise them on debian-wb-team@). Regards, Adam
Bug#833607: nmu: python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 & node-mapnik_3.5.13+dfsg-1~exp1
Hi Adam, On 08/07/2016 12:04 AM, Adam D. Barratt wrote: > On Sat, 2016-08-06 at 23:47 +0200, Bas Couwenberg wrote: >> Please binNMU python-mapnik & node-mapnik in experimental, they need to >> be rebuild with libmapnik-dev (3.0.12~rc1+ds-1~exp2) which depends on >> the correct libmapbox-variant-dev (from experimental not unstable). >> >> dep-wait was already set for these packages by the wanna-build team, but >> that was not sufficient for the architectures where the build had >> already failed. > > One can't binNMU a package on an architecture where it hasn't built; > that's rather by definition - a binNMU is a rebuild of the existing > binary package. > > You want give-backs, which are handled on the wanna-build side. I've > actioned them this time - and added the dep-waits on those architectures > - but please use the correct address in future. Thanks for this. The wanna-build documentation on release.d.o [0] mentions "If you are asking for a dep-wait, an additional give-back is not needed", which seems to be incorrect based on your reply. Is the documentation outdated perhaps? [0] https://release.debian.org/wanna-build.txt Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#833607: marked as done (nmu: python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 & node-mapnik_3.5.13+dfsg-1~exp1)
Your message dated Sat, 06 Aug 2016 23:04:50 +0100 with message-id <1470521090.32336.32.ca...@adam-barratt.org.uk> and subject line Re: Bug#833607: nmu: python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 & node-mapnik_3.5.13+dfsg-1~exp1 has caused the Debian Bug report #833607, regarding nmu: python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 & node-mapnik_3.5.13+dfsg-1~exp1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 833607: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833607 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binNMU python-mapnik & node-mapnik in experimental, they need to be rebuild with libmapnik-dev (3.0.12~rc1+ds-1~exp2) which depends on the correct libmapbox-variant-dev (from experimental not unstable). dep-wait was already set for these packages by the wanna-build team, but that was not sufficient for the architectures where the build had already failed. nmu python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 . arm64 i386 powerpc ppc64el . experimental . -m "Rebuild with libmapnik-dev (3.0.12~rc1+ds-1~exp2)" nmu node-mapnik_3.5.13+dfsg-1~exp1 . arm64 i386 powerpc ppc64el . experimental . -m "Rebuild with libmapnik-dev (3.0.12~rc1+ds-1~exp2)" Kind Regards, Bas --- End Message --- --- Begin Message --- On Sat, 2016-08-06 at 23:47 +0200, Bas Couwenberg wrote: > Please binNMU python-mapnik & node-mapnik in experimental, they need to > be rebuild with libmapnik-dev (3.0.12~rc1+ds-1~exp2) which depends on > the correct libmapbox-variant-dev (from experimental not unstable). > > dep-wait was already set for these packages by the wanna-build team, but > that was not sufficient for the architectures where the build had > already failed. One can't binNMU a package on an architecture where it hasn't built; that's rather by definition - a binNMU is a rebuild of the existing binary package. You want give-backs, which are handled on the wanna-build side. I've actioned them this time - and added the dep-waits on those architectures - but please use the correct address in future. > nmu python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 . arm64 i386 powerpc ppc64el > . experimental . -m "Rebuild with libmapnik-dev (3.0.12~rc1+ds-1~exp2)" > nmu node-mapnik_3.5.13+dfsg-1~exp1 . arm64 i386 powerpc ppc64el . > experimental . -m "Rebuild with libmapnik-dev (3.0.12~rc1+ds-1~exp2)" Regards, Adam--- End Message ---
NEW changes in stable-new
Processing changes file: chromium-browser_52.0.2743.82-1~deb8u1_i386.changes ACCEPT Processing changes file: chromium-browser_52.0.2743.82-1~deb8u1_amd64.changes ACCEPT Processing changes file: curl_7.38.0-4+deb8u4_amd64.changes ACCEPT Processing changes file: curl_7.38.0-4+deb8u4_arm64.changes ACCEPT Processing changes file: curl_7.38.0-4+deb8u4_armel.changes ACCEPT Processing changes file: curl_7.38.0-4+deb8u4_armhf.changes ACCEPT Processing changes file: curl_7.38.0-4+deb8u4_i386.changes ACCEPT Processing changes file: curl_7.38.0-4+deb8u4_mips.changes ACCEPT Processing changes file: curl_7.38.0-4+deb8u4_mipsel.changes ACCEPT Processing changes file: curl_7.38.0-4+deb8u4_powerpc.changes ACCEPT Processing changes file: curl_7.38.0-4+deb8u4_ppc64el.changes ACCEPT Processing changes file: curl_7.38.0-4+deb8u4_s390x.changes ACCEPT Processing changes file: firefox-esr_45.3.0esr-1~deb8u1_amd64.changes ACCEPT Processing changes file: firefox-esr_45.3.0esr-1~deb8u1_arm64.changes ACCEPT Processing changes file: firefox-esr_45.3.0esr-1~deb8u1_armel.changes ACCEPT Processing changes file: firefox-esr_45.3.0esr-1~deb8u1_armhf.changes ACCEPT Processing changes file: firefox-esr_45.3.0esr-1~deb8u1_i386.changes ACCEPT Processing changes file: firefox-esr_45.3.0esr-1~deb8u1_mips.changes ACCEPT Processing changes file: firefox-esr_45.3.0esr-1~deb8u1_mipsel.changes ACCEPT Processing changes file: firefox-esr_45.3.0esr-1~deb8u1_powerpc.changes ACCEPT Processing changes file: firefox-esr_45.3.0esr-1~deb8u1_ppc64el.changes ACCEPT Processing changes file: firefox-esr_45.3.0esr-1~deb8u1_s390x.changes ACCEPT Processing changes file: lighttpd_1.4.35-4+deb8u1_amd64.changes ACCEPT Processing changes file: lighttpd_1.4.35-4+deb8u1_arm64.changes ACCEPT Processing changes file: lighttpd_1.4.35-4+deb8u1_armel.changes ACCEPT Processing changes file: lighttpd_1.4.35-4+deb8u1_armhf.changes ACCEPT Processing changes file: lighttpd_1.4.35-4+deb8u1_i386.changes ACCEPT Processing changes file: lighttpd_1.4.35-4+deb8u1_mips.changes ACCEPT Processing changes file: lighttpd_1.4.35-4+deb8u1_mipsel.changes ACCEPT Processing changes file: lighttpd_1.4.35-4+deb8u1_powerpc.changes ACCEPT Processing changes file: lighttpd_1.4.35-4+deb8u1_ppc64el.changes ACCEPT Processing changes file: lighttpd_1.4.35-4+deb8u1_s390x.changes ACCEPT Processing changes file: openjdk-7_7u111-2.6.7-1~deb8u1_amd64.changes ACCEPT Processing changes file: openjdk-7_7u111-2.6.7-1~deb8u1_arm64.changes ACCEPT Processing changes file: openjdk-7_7u111-2.6.7-1~deb8u1_armel.changes ACCEPT Processing changes file: openjdk-7_7u111-2.6.7-1~deb8u1_armhf.changes ACCEPT Processing changes file: openjdk-7_7u111-2.6.7-1~deb8u1_i386.changes ACCEPT Processing changes file: openjdk-7_7u111-2.6.7-1~deb8u1_mips.changes ACCEPT Processing changes file: openjdk-7_7u111-2.6.7-1~deb8u1_mipsel.changes ACCEPT Processing changes file: openjdk-7_7u111-2.6.7-1~deb8u1_powerpc.changes ACCEPT Processing changes file: openjdk-7_7u111-2.6.7-1~deb8u1_ppc64el.changes ACCEPT Processing changes file: openjdk-7_7u111-2.6.7-1~deb8u1_s390x.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u4_amd64.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u4_arm64.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u4_armel.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u4_armhf.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u4_i386.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u4_mips.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u4_mipsel.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u4_powerpc.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u4_ppc64el.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u4_s390x.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u5_amd64.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u5_arm64.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u5_armel.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u5_armhf.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u5_i386.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u5_mips.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u5_mipsel.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u5_powerpc.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u5_ppc64el.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u5_s390x.changes ACCEPT Processing changes file: wordpress_4.1+dfsg-1+deb8u9_amd64.changes ACCEPT
Bug#833607: nmu: python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 & node-mapnik_3.5.13+dfsg-1~exp1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binNMU python-mapnik & node-mapnik in experimental, they need to be rebuild with libmapnik-dev (3.0.12~rc1+ds-1~exp2) which depends on the correct libmapbox-variant-dev (from experimental not unstable). dep-wait was already set for these packages by the wanna-build team, but that was not sufficient for the architectures where the build had already failed. nmu python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 . arm64 i386 powerpc ppc64el . experimental . -m "Rebuild with libmapnik-dev (3.0.12~rc1+ds-1~exp2)" nmu node-mapnik_3.5.13+dfsg-1~exp1 . arm64 i386 powerpc ppc64el . experimental . -m "Rebuild with libmapnik-dev (3.0.12~rc1+ds-1~exp2)" Kind Regards, Bas
Bug#827352: jessie-pu: package automake-1.14/1.14.1-4+deb8u1
Control: tags -1 + confirmed On Wed, 2016-06-15 at 11:12 +0200, Petter Reinholdtsen wrote: > On my Debian Jessie machine, I would like to fix a security problem with > automake-1.14 that show up the debsecan report, see > https://security-tracker.debian.org/tracker/source-package/automake-1.14 >. > The issue never got a CVE (no reply to the request), so I point to the > source package entry instead of the some times changing TEMP reference. > > The issue is fixed in automake-1.15, but not in automake-1.14 that is in > stable but removed from unstable. > > The issue is unsafe use of /tmp/. The patch is similar to the code in > version 1.15. > > OK to upload? Assuming that the resulting package has been tested on stable, please go ahead, except: +automake-1.14 (1:1.14.1-4+deb8u1) unstable; urgency=medium That distribution is a little wrong. :-p "jessie", please. Regards, Adam
Processed: Re: Bug#827352: jessie-pu: package automake-1.14/1.14.1-4+deb8u1
Processing control commands: > tags -1 + confirmed Bug #827352 [release.debian.org] jessie-pu: package automake-1.14/1.14.1-4+deb8u1 Added tag(s) confirmed. -- 827352: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827352 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Bug#833550: jessie-pu: package gnome-maps/3.14.1.2-1
Processing control commands: > tags -1 + confirmed Bug #833550 [release.debian.org] jessie-pu: package gnome-maps/3.14.1.2-1 Added tag(s) confirmed. -- 833550: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833550 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#833550: jessie-pu: package gnome-maps/3.14.1.2-1
Control: tags -1 + confirmed On Fri, 2016-08-05 at 23:14 +0200, Emilio Pozuelo Monfort wrote: > gnome-maps is currently unusable in Jessie. It used the MapQuest provider, > which has closed access to external applications[1]. > > This is already fixed in unstable, see #830842. > > For Jessie, I have updated to the new point release. Excluding the autotools > changes in the debdiff (which are autogenerated anyway through dh_autoreconf), > the only changes are a few translation updates, and the changes for this fix > (which are the changes in src/, plus the mapbox logo), as can also be seen > in [2]. fwiw, this didn't make it to debian-release, probably due to the size of the debdiff; you might want to compress larger ones in future. > I could backport these changes instead, but given that the new release is > basically this fix, I thought it would be fine. const MapType = { -STREET: Champlain.MAP_SOURCE_OSM_MAPQUEST, -AERIAL: Champlain.MAP_SOURCE_OSM_AERIAL_MAP, -CYCLING: Champlain.MAP_SOURCE_OSM_CYCLE_MAP, -TRANSIT: Champlain.MAP_SOURCE_OSM_TRANSPORT_MAP +STREET: 'MapsStreetSource', +AERIAL: 'MapsAerialSource' }; I assume this means that the change also ends up dropping functionality? :-( Please go ahead. Regards, Adam
Processed: Re: Bug#833575: jessie-pu: package javatools/0.48+deb8u1
Processing control commands: > tags -1 + confirmed Bug #833575 [release.debian.org] jessie-pu: package javatools/0.48+deb8u1 Added tag(s) confirmed. -- 833575: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833575 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#833575: jessie-pu: package javatools/0.48+deb8u1
Control: tags -1 + confirmed On Sat, 2016-08-06 at 11:02 +0200, Julien Cristau wrote: > collectd on security.d.o fails to build on ppc64el, apparently because > java changed its paths there and javatools needs an update. Please go ahead. Regards, Adam
Processed: Re: Bug#831335: jessie-pu: package publicsuffix/20160703-1
Processing control commands: > tags -1 + confirmed Bug #831335 [release.debian.org] jessie-pu: package publicsuffix/20160703-1 Added tag(s) confirmed. -- 831335: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831335 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#831335: jessie-pu: package publicsuffix/20160703-1
Control: tags -1 + confirmed On Fri, 2016-07-15 at 00:25 +0200, Daniel Kahn Gillmor wrote: > On Thu 2016-07-14 20:06:27 +0200, Adam D. Barratt wrote: > > Please could we have a debdiff, relative to the current package in > > jessie, in this bug log? (We prefer p-u bugs to be self-contained, and > > not have to rely on your git tree existing for arbitrary periods in the > > future, or on it not changing after we give an ack.) > > sure. the debdiff is quite large, primarily due to upstream renaming > effective_tld_names.dat to public_suffix_list.dat (and adding a > python-based "linter", and changing how they produce their upstream > changelog), but i've attached the gzip'ed debdiff below. Thanks; please feel free to upload that, with a small tweak: +publicsuffix (20160703-0+deb8u1) stable; urgency=medium + + * prepare for stable-proposed-updates. "jessie" is generally preferred as the changelog distribution and maybe "Upload to stable" or something similar? > The git tree's jessie branch which i'm proposing is at commit ID > 6520ee81d3e2d73192e67685652ef6bccdb2e637, fwiw, so you don't have to > worry about it changing. Thanks for that, but we'd still prefer p-u bug reports to be free-standing. [...] > I expect the packaging should be able to remain basically as-is for > jessie's lifetime, since we're basically just shipping a static global > file. That's good to know. > > How frequently would you imagine that the package would need to be > > updated in stable? > > Upstream makes several additions to the psl per month, but the new > editions are rarely super-urgent. I'd imagine doing a "roll-up" release > of changes every month or two to more accurately track the state of > global DNS administrative boundaries. Every couple of months is when we aim (not always successfully) to do a stable point release, so that hopefully works out well all around. Regards, Adam
Bug#833595: jessie-pu: package nullmailer/1.13-1+deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu Dear Release Team, #831813 is an rc-bug in nullmailer, which, for some configurations, keeps username/passwords in the debconf db. I've fixed this in unstable as an NMU; Security has suggested doing the same for jessie in a point release. Debdiff attached. Cheers, -- ,''`. Christian Hofstaedtler: :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- diff -Nru nullmailer-1.13/debian/changelog nullmailer-1.13/debian/changelog --- nullmailer-1.13/debian/changelog2014-08-08 00:19:32.0 + +++ nullmailer-1.13/debian/changelog2016-08-06 17:38:32.0 + @@ -1,3 +1,12 @@ +nullmailer (1:1.13-1+deb8u1) jessie; urgency=medium + + * Non-maintainer upload. + * Do not keep relayhost data in debconf database longer than +strictly needed. (Closes: #831813) +Backport of 1:1.13-1.2 from unstable. + + -- Christian Hofstaedtler Sat, 06 Aug 2016 17:36:35 + + nullmailer (1:1.13-1) unstable; urgency=low * Ack NMU, thankyou for your help with this package. diff -Nru nullmailer-1.13/debian/postinst nullmailer-1.13/debian/postinst --- nullmailer-1.13/debian/postinst 2012-08-21 08:07:21.0 + +++ nullmailer-1.13/debian/postinst 2016-08-06 17:35:13.0 + @@ -37,6 +37,8 @@ -e 's/[[:space:]]*:[[:space:]]*/\n/g' \ -e ':b s/(\[[^]=]*)=/\1:/; tb' \ -e 's/[][]//g' > /etc/nullmailer/remotes + # zap debconf entry, as this key may contain sensitive data. + db_set nullmailer/relayhost "" db_get nullmailer/adminaddr if [ "$RET" ]; then signature.asc Description: PGP signature
Bug#833589: transition: opencc
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to kick off the opencc transition, which has been in experimental for quite some time. Dependencies: - ibus-libzhuyin: experimental version works - libpyzy: binNMU is okay - librime: new upstream release upload needed, to fix 811637 at the same time Please tell me when I can do uploads to unstable, thanks. Cheers, Aron
Bug#833575: jessie-pu: package javatools/0.48+deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: javato...@packages.debian.org Hi, collectd on security.d.o fails to build on ppc64el, apparently because java changed its paths there and javatools needs an update. Cheers, Julien diff -Nru javatools-0.48/debian/changelog javatools-0.48+deb8u1/debian/changelog --- javatools-0.48/debian/changelog 2014-12-12 07:44:41.0 +0100 +++ javatools-0.48+deb8u1/debian/changelog 2016-08-06 10:59:39.0 +0200 @@ -1,3 +1,10 @@ +javatools (0.48+deb8u1) jessie; urgency=medium + + * Non-maintainer upload. + * Fixed the arch returned for ppc64el in java-arch.sh (closes: #833572) + + -- Julien CristauSat, 06 Aug 2016 10:59:36 +0200 + javatools (0.48) unstable; urgency=medium * Team upload. diff -Nru javatools-0.48/java-arch.sh javatools-0.48+deb8u1/java-arch.sh --- javatools-0.48/java-arch.sh 2014-12-12 07:44:41.0 +0100 +++ javatools-0.48+deb8u1/java-arch.sh 2016-08-06 10:46:07.0 +0200 @@ -24,7 +24,7 @@ echo ppc ;; ppc64el) - echo ppc64 + echo ppc64le ;; hppa) echo parisc