Bug#833607: nmu: python-mapnik_1:0.0~20160726-1c4a51d-1~exp1 & node-mapnik_3.5.13+dfsg-1~exp1

2016-08-06 Thread Adam D. Barratt
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

2016-08-06 Thread Sebastiaan Couwenberg
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)

2016-08-06 Thread Debian Bug Tracking System
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

2016-08-06 Thread Debian FTP Masters
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

2016-08-06 Thread Bas Couwenberg
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

2016-08-06 Thread Adam D. Barratt
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

2016-08-06 Thread Debian Bug Tracking System
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

2016-08-06 Thread Debian Bug Tracking System
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

2016-08-06 Thread Adam D. Barratt
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

2016-08-06 Thread Debian Bug Tracking System
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

2016-08-06 Thread Adam D. Barratt
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

2016-08-06 Thread Debian Bug Tracking System
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

2016-08-06 Thread Adam D. Barratt
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

2016-08-06 Thread Christian Hofstaedtler
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

2016-08-06 Thread Aron Xu
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

2016-08-06 Thread Julien Cristau
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 Cristau   Sat, 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