Bug#840295: Requesting RC exception for stretch for browserified javascript

[Pirate Praveen]

On Wednesday 23 November 2016 01:07 AM, Emilio Pozuelo Monfort wrote:
> I am quite reluctant to give an exception to this. IMHO if it has to go in
> non-free with rdeps in contrib, that's better than not having those rdeps at
> all, and it can be improved to having them in main in the future when all 
> issues
> are resolved.

It is now in contrib as recent upload of node-handlebars includes the
source code.

> Obviously if those issues can be fixed in time for stretch, then all the 
> better.

We are trying our best, but its dependency chain is too long.

> But in order to make an informed decision, please answer these questions:
> 
> Is libjs-handlebars the only package for which you are asking an exception?

Yes, fuzzaldrin-plus was recently built using grunt and browserify-lite.

> What is the exact issue with it? Is the only issue that you need
> webpack/node-browserify-lite to "browserify" (as in /bin/cat) it? Or do you 
> also
> need to get it to use the packaged jison? Any other issues?

It needs babel (which needs gulp) before we try browserify. I think
browserify-lite won't be enough to browserify it and would need webpack
too (I tried using browserify-lite and it appears it did not concat all
the files, though I did not really test it with diaspora). With grunt
packaged, the build process goes past jison and now it is waiting for babel.


Summary,

1. jison - packaged
2. grunt - packaged (build process uses packaged jison with grunt)
3. babel - in progress (114 binary packages to be built from babel
source package, working on automating it)
4. gulp - in progress (needed for building babel)
5. webpack - not started (after we complete babel, we'll try again with
browserify-lite, but I don't think it would be sufficient)



signature.asc
Description: OpenPGP digital signature

Bug#825342: marked as done (mips/mipsel: make sure all packages built with fpxx enabled)

[Debian Bug Tracking System]

Your message dated Wed, 23 Nov 2016 10:55:48 +0800
with message-id 

[RFC] Enabling bindnow by default in dpkg-buildflags?

[Guillem Jover]

Hi!

This was discussed relatively recently, but it was not entirely clear
to me what was the conclusion, if there was any(?), about enabling
bindnow by default.

And although this got enabled by default in gcc-6 6.2.0-7 when PIE
also got enabled, it seems it got disabled in 6.2.0-10 when I pointed
out that enabling bindnow in gcc w/o enabling relro too didn't seem to
make much sense, but then I didn't notice any rationale for the
reversion, instead of say enabling relro too.


My mine concern is and has always been that bindnow changes the
run-time behavior (instead of the build-time one) and could break
things such as dlopen() on shared libraries or plugins and similar.
And detecting problems becomes harder, and reverting this change
iff we notice that it breaks too much might imply rebuilding an
unspecified number of packages. So in a way it feels kind of like
a transition?

OTOH Ubuntu seems to have been enabling not only PIE and bindnow by
default in gcc for a long time, but also relro, stack-protector and
fortify. Which would seem to imply this might not break that much?
(I'm not sure why we are not enabling all those in gcc in Debian
too, but that's probably a different conversation to have if at all.)


So at this point, I guess I still have concerns, but only very mild
ones, and would not mind one way or another, but would like input
from at least the release team, because I don't feel like possibly
deciding on this on my own, even more at this stage of the release.

Thanks,
Guillem

Bug#845387: jessie-pu: package glibc/2.19-18+deb8u7

[Aurelien Jarno]

On 2016-11-22 16:18, Stephen Dowdy wrote:
> sorry to butt-in here, but:
> 
> FYI: typo alert?   fqsrt -> fsqrt ??  (transposition of q & s)
> 
> I know it's just in the e-mail twice and the patch changelog once, but it'd 
> be good if the changelog was typographically correct, esp for searches.

Thanks for the notice. I have just fix the changelog in our git.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#845387: jessie-pu: package glibc/2.19-18+deb8u7

[Stephen Dowdy]

sorry to butt-in here, but:

FYI: typo alert?   fqsrt -> fsqrt ??  (transposition of q & s)

I know it's just in the e-mail twice and the patch changelog once, but it'd be 
good if the changelog was typographically correct, esp for searches.
--stephen

Bug#845387: jessie-pu: package glibc/2.19-18+deb8u7

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Dear stable release managers,

I would like to upload a new glibc package for the next jessie release.
Here is the changelog with some additional comment:

  * Update from upstream stable branch:
- Do not unconditionally use the fqsrt instruction on 64-bit PowerPC
  CPUs.  Closes: #843904.

The sqrt functions on powerpc unconditionally use the fqsrt instruction
when running on a 64-bit CPU. However while IBM based PowerPC CPUs all
have this instruction, it's not part of the ISA and not available on
some embedded CPUs like the Freescale^WNXP^Qualcomm  e5500 CPU. The
change is available in stretch/sid since glibc 2.21-1 and mostly
consists in #ifdefery.


  * debian/patches/any/cvs-hesiod-resolver.diff: patch from upstream to
fix a regression introduced by cvs-resolv-ipv6-nameservers.diff in
hesiod.  Closes: #821358.

The glibc 2.19-18+deb8u6 from the last point update introduced a
regression as an additional patch had to be backported. This is done
with this patch, which is in stretch/sid since glibc 2.22-8.


  * debian/sysdeps/{amd64,i386,x32}.mk: disable lock elision (aka Intel TSX)
on x86 architectures. This causes programs (wrongly) unlocking an already
unlocked mutex to abort. More importantly most of the other distributions
decided to disable it, so we don't want to be the only distribution left
testing this code path.

See this thread [1] on debian-devel@ for more background. While I was a
bit reluctant to disable lock elision in jessie, the fact that many
distributions decided to disable it convinced me we should do the same.
Note that it is still not yet disabled in stretch/sid, but I guess we
will end up doing the same before the freeze.

Thanks,
Aurelien

[1] https://lists.debian.org/debian-devel/2016/11/msg00210.html

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index 97e2a76..4fdfb65 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+glibc (2.19-18+deb8u7) UNRELEASED; urgency=medium
+
+  [ Aurelien Jarno ]
+  * Update from upstream stable branch:
+- Do not unconditionally use the fqsrt instruction on 64-bit PowerPC
+  CPUs.  Closes: #843904.
+  * debian/patches/any/cvs-hesiod-resolver.diff: patch from upstream to
+fix a regression introduced by cvs-resolv-ipv6-nameservers.diff in
+hesiod.  Closes: #821358.
+  * debian/sysdeps/{amd64,i386,x32}.mk: disable lock elision (aka Intel TSX)
+on x86 architectures. This causes programs (wrongly) unlocking an already
+unlocked mutex to abort. More importantly most of the other distributions
+decided to disable it, so we don't want to be the only distribution left
+testing this code path.
+
+ -- Aurelien Jarno   Sun, 04 Sep 2016 01:26:19 +0200
+
 glibc (2.19-18+deb8u6) stable; urgency=medium
 
   * Update from upstream stable branch:
diff --git a/debian/patches/any/cvs-hesiod-resolver.diff b/debian/patches/any/cvs-hesiod-resolver.diff
new file mode 100644
index 000..d47c6f9
--- /dev/null
+++ b/debian/patches/any/cvs-hesiod-resolver.diff
@@ -0,0 +1,420 @@
+2016-05-02  Florian Weimer  
+ 
+	[BZ #19573]
+	* hesiod/Makefile (libnss_hesiod-routines): Remove hesiod-init.
+	* hesiod/nss_hesiod/hesiod-init.c: Remove file.
+	* hesiod/nss_hesiod/nss_hesiod.h: Likewise.
+	* hesiod/hesiod.h (__hesiod_res_get, __hesiod_res_set): Remove.
+	(hesiod_init, hesiod_end, hesiod_to_bind, hesiod_resolve)
+	(hesiod_free_list): Mark as hidden.
+	* hesiod/hesiod_p (struct hesiod_p): Remove res, free_res,
+	res_set, res_get.
+	* hesiod/hesiod.c: Remove unnecessary forward declarations.
+	(init, __hesiod_res_get, __hesiod_res_set): Remove.
+	(hesiod_init): Remove obsolete res_ninit call.
+	(hesiod_end): Do not free resolver state.  Do not invoke callback.
+	(hesiod_bind): Do not call init.
+	(get_txt_records): Use res_mkquery, res_send instead of
+	res_nmkquery, res_nsend.
+	* hesiod/nss_hesiod/hesiod-grp.c (lookup): Call hesiod_init
+	instead of _nss_hesiod_init.
+	(_nss_hesiod_initgroups_dyn): Likewise.
+	* hesiod/nss_hesiod/hesiod-proto.c (lookup): Likewise.
+	* hesiod/nss_hesiod/hesiod-pwd.c (lookup): Likewise.
+	* hesiod/nss_hesiod/hesiod-service.c (lookup): Likewise.
+
+--- a/hesiod/Makefile
 b/hesiod/Makefile
+@@ -28,7 +28,7 @@ extra-libs-others = $(extra-libs)
+ subdir-dirs = nss_hesiod
+ vpath %.c nss_hesiod
+ 
+-libnss_hesiod-routines	:= hesiod hesiod-grp hesiod-init hesiod-proto \
++libnss_hesiod-routines	:= hesiod hesiod-grp hesiod-proto \

Bug#842846: marked as done (transition: ros-vision-opencv)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 21:11:09 +0100
with message-id 
and subject line Re: Bug#842846: New ros-vision-opencv transition
has caused the Debian Bug report #842846,
regarding transition: ros-vision-opencv
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.)


-- 
842846: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842846
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: transition

Dear Release Team,

I'm filing this bug for a new transition of ros-vision-opencv. It is 
in experimental. It builds on all architectures in testing, where it built 
previously. 


Ben file:

title = "ros-vision-opencv";
is_affected = .depends ~ 
/\b(libcv\-bridge1d|cl\-opencv\-apps|libcv\-bridge0d|libopencv\-apps\-dev|libopencv\-apps0d|opencv\-apps\-tools|python\-opencv\-apps)\b/
is_good = .depends ~ /\b(libcv\-bridge1d)\b/
is_bad = .depends ~ 
/\b(cl\-opencv\-apps|libcv\-bridge0d|libopencv\-apps\-dev|libopencv\-apps0d|opencv\-apps\-tools|python\-opencv\-apps)\b/

All reverse dependencies test rebuilds. All rdepends are listed here:

https://release.debian.org/transitions/html/auto-ros-vision-opencv.html

-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
On 05/11/16 10:28, Emilio Pozuelo Monfort wrote:
> On 01/11/16 23:30, Leopold Palomo-Avellaneda wrote:
>> El dimarts, 1 de novembre de 2016, a les 19:49:35 CET, Emilio Pozuelo 
>> Monfort 
>> va escriure:
>>> Control: tags -1 confirmed
>>>
>>> On 01/11/16 19:13, Leopold Palomo-Avellaneda wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition

 Dear Release Team,

 I'm filing this bug for a new transition of ros-vision-opencv. It is
 in experimental. It builds on all architectures in testing, where it built
 previously.
>>>
>>> Go ahead.
>>>
>>> BTW I'm happy if you skip the transition bug when only a small number of
>>> rdeps are involved and you maintain all of them (like in this case). Of
>>> course if you want to file the bug and wait for an ack, that is fine too!
>>>
>> Thx,
>>
>> just following the normal procedure. Although I agree that it's a bit heavy 
>> in 
>> these cases.
> 
> This needs an update to ros-metapackages for the dropped binaries.

That's done.

Emilio--- End Message ---

Processed: Re: Bug#819530: transition: icu

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 819530 + pending
Bug #819530 [release.debian.org] transition: icu
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
819530: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819530
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#842571: marked as done (transition: tango)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 21:07:57 +0100
with message-id 
and subject line Re: Bug#842571: transition: tango
has caused the Debian Bug report #842571,
regarding transition: tango
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.)


-- 
842571: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842571
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: transition

Hello

I would like to start the tango transition tango8 -> tango9

This is required in order to have tango into Stretch (it add the MariaDB 
support).

You can find here [1] that there is only one dependency "pytango" for which I 
am also the maintainer.
this package was already rebuilt in experimental.

So all reverse depdency are ready for the migration from the tango point of view

Except that this transition require the ipython one before.
Inddeed the new pytango 9.x added a dependency to python-itango which depends 
on python-qtconsole.

thanks for considering

Frédéric


https://release.debian.org/transitions/html/auto-tango.html

Ben file:

I would take the one from [1]


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On 30/10/16 23:07, Emilio Pozuelo Monfort wrote:
> Go ahead when that is started.

This is done; closing.

Emilio--- End Message ---

Bug#841911: marked as done (transition: pari)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 21:13:25 +0100
with message-id 
and subject line Re: Bug#841911: transition: pari
has caused the Debian Bug report #841911,
regarding transition: pari
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.)


-- 
841911: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841911
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: transition

Dear release team, I would like to upgrade PARI to the upcoming 2.9.0
stable version, which bump the soname of libpari-gmp-tls4 to
libpari-gmp-tls5.

libpari-gmp-tls5 is in the NEW queue.

There are very few packages that build against libpari (I found only
two: lcalc and eclib).

Ben file:

title = "pari";
is_affected = .depends ~ "libpari-gmp-tls4" | .depends ~ "libpari-gmp-tls5";
is_good = .depends ~ "libpari-gmp-tls5";
is_bad = .depends ~ "libpari-gmp-tls4";

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Bill. 

Imagine a large red swirl here. 
--- End Message ---
--- Begin Message ---
On 02/11/16 10:54, Bill Allombert wrote:
> On Tue, Oct 25, 2016 at 11:16:43AM +0200, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 confirmed
>>
>> On 25/10/16 10:48, Bill Allombert wrote:
>>> On Tue, Oct 25, 2016 at 12:19:29AM +0200, Emilio Pozuelo Monfort wrote:
 Hi,

 On 24/10/16 13:44, Bill Allombert wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Dear release team, I would like to upgrade PARI to the upcoming 2.9.0
> stable version, which bump the soname of libpari-gmp-tls4 to
> libpari-gmp-tls5.
>
> libpari-gmp-tls5 is in the NEW queue.
>
> There are very few packages that build against libpari (I found only
> two: lcalc and eclib).

 Do they build against the new version?
>>>
>>> Yes, we checked that already.
>>
>> Cool, go ahead then.
> 
> libpari-gmp-tls5 has cleared the NEW queue, so I have uploaded it to
> unstable.

This is in testing; closing.

Cheers,
Emilio--- End Message ---

Processed: Re: Bug#842821: transition: hypre

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 842821 + pending
Bug #842821 [release.debian.org] transition: hypre
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
842821: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842821
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#843334: transition: czmq

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 843334 + pending
Bug #843334 [release.debian.org] transition: czmq
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
843334: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843334
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: ITM: Britney2 branch britney-patch-bundle-201611 into master -- small update

[Niels Thykier]

Martin Pitt:
> Hello Niels,
> 
> Niels Thykier [2016-11-13 12:53 +]:
>> [...]
>>  * It cherry-picks 4 commits proposed by Martin Pitt to assist Ubuntu
>>with refactoring some their changes into policies.
>>
>> Martin Pitt (4):
>>   Move build checks before running policies
> 
> This needs another small refinement which we previously overlooked:
> With that patch excuse.is_valid was only updated after *all* policies
> ran. But the idea was that some "expensive" policy can detect whether
> a previous policy already invalidated the excuse, and for that we need
> to update excuse.is_valid after each policy run.
> 
> Patch from Robert attached (I added a more complete changelog).
> 
> I'll keep that in our branch for now, but if you take the above I
> think you should also take this one so that this actually works.
> 
> Thanks for considering,
> 
> Martin
> 

Thanks, I will schedule it into the next bundle. :)

Have you thought about "force" hints here?  The end result for a "force"
hinted item is that it will always be valid.  Therefore, I would expect
policies to see the item as valid, but I am not quite sure that is the
case with this patch.
  Admittedly, other parts needs fixing as well now for this to hold, but
until now we never had a policy that was "lazy" before.

Thanks,
~Niels

Bug#841863: marked as done (transition: nvidia-cuda-toolkit)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 21:05:58 +0100
with message-id 
and subject line Re: Bug#841863: transition: nvidia-cuda-toolkit
has caused the Debian Bug report #841863,
regarding transition: nvidia-cuda-toolkit
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.)


-- 
841863: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841863
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: transition

Hi,

NVIDIA released the CUDA toolkit 8.0 earlier this month. I'd like to see
this version in the non-free part of stretch.
This will bump the SOVERSION of all the libraries from 7.5 to 8.0.
New packages targetting experimental are currently sitting in NEW.
The transition has been done for Ubuntu 16.10 right before its release,
therefore I do not expect problems rebuilding the reverse dependencies.
They will need maintainer uploads (or manual binNMUs) anyway, since it
involves B-D from non-free. I'll take care of NMUs if needed.

Rdepends as I remember them (coccia is currently missing dak due to the
ongoing ftp-master move):

eztrace-contrib
hwloc-contrib
starpu-contrib
pycuda

The auto-generated ben file worked fine for the past transitions,
therefore I didn't try to come up with a manual one (there are 10+ libraries).


Andreas
--- End Message ---
--- Begin Message ---
On 25/10/16 00:18, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 24/10/16 12:20, Graham Inggs wrote:
>> On 24/10/16 00:04, Emilio Pozuelo Monfort wrote:
>>> On 23/10/16 23:54, Andreas Beckmann wrote:
 Rdepends as I remember them (coccia is currently missing dak due to the
 ongoing ftp-master move):

 eztrace-contrib
 hwloc-contrib
 starpu-contrib
 pycuda
>>>
>>> Do they build fine with CUDA 8.0?
>>
>> The nvidia-cuda-toolkit 8.0 transition was done in Ubuntu recently.
>>
>> eztrace-contrib 1.1-5-1 - no changes needed
>> hwloc-contrib 1.11.3-2 - no changes needed
>> starpu-contrib 1.1.4+dfsg-6 - not in testing due to #837911,
>> 1.2.0+dfsg-1 is in NEW with a fix.  Ubuntu's 1.1.5-0 needed no
>> changes.
>> pycuda 2016.1.2+git20160809-1 - included patch from upstream (attached)
> 
> OK, go ahead.

This is done. Closing.

Emilio--- End Message ---

Bug#840501: marked as done (transition: ipython)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 21:07:06 +0100
with message-id 
and subject line Re: Bug#840501: transition: ipython
has caused the Debian Bug report #840501,
regarding transition: ipython
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.)


-- 
840501: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840501
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: transition

Hi,

we would like to transition to ipython 5. The version currently in
Debian (2.4.1) includes a notebook and a qt console. These components
(at least the notebook functionality) were moved to the separate project
jupyter. Because of this, the old ipython is replaced by a bunch of
packages, which are currently in experimental:

ipython
ipykernel
jupyter_client
jupyter_core
nbconvert
nbformat

Some additional are currently being packaged:

ipywidgets ITP: #838684
jupyter-notebook   ITP: #801366
widgetsnbextension ITP: #838683

There are two categories of ipython reverse dependencies: The ones that
depend only on ipython and/or ipython3, and the ones that also depend on
packages that do not exist anymore in this form in ipython 5,
ipython(3)-notebook and ipython(3)-qtconsole.

Below is a list of all these reverse dependencies. With the exception of
yade, I was able to build all the ones that have a reverse dependency
only on ipython(3) successfully against ipython 5.1.0-1.

It is clear that apart from yade, the dependencies on
ipython(3)-notebook and/or ipython(3)-qtconsole need special attention.
I would start by filing bugs against these packages to see what needs to
be done. They are:

glueviz, lmfit-py, plotly, sardana, vistrails, yade

The maintainer of lmfit-py and sardana already promised to take care of
these packages:
http://lists.alioth.debian.org/pipermail/debian-science-sagemath/Week-of-Mon-20161010/000231.html

Would you say I should also file bugs against all the other affected
packages?

Here's the list of reverse dependencies, originating from dak:

# Build-Depend only on ipython / ipython3:

ipdb builds with ipython 5.1.0-1
matplotlib   builds with ipython 5.1.0-1
nova builds with ipython 5.1.0-1
patsybuilds with ipython 5.1.0-1
pysurfer builds with ipython 5.1.0-1
python-cyclerbuilds with ipython 5.1.0-1
python-geopandas builds with ipython 5.1.0-1
python-skbio builds with ipython 5.1.0-1
sfepybuilds with ipython 5.1.0-1
yade FTBFS with ipython 5.1.0-1


# Build-Depend on ipython(3)-notebook or ipython(3)-qtconsole:

glueviz: ipython (>= 2.3.0)
 ipython3 (>= 2.3.0)
 ipython3-qtconsole (>= 2.3.0)
lmfit-py: ipython-notebook
  ipython3-notebook
plotly: ipython-notebook (>= 2.3.0)
ipython3-notebook (>= 2.3.0)


# Depend only on ipython / ipython3:

accerciser: accerciser
androguard: androguard
connectomeviewer: connectomeviewer
ipdb: python-ipdb
  python3-ipdb
plaso: plaso
pytango: python-pytango
 python3-pytango
python-pypump: pypump-shell
python-skbio: python-skbio
  python3-skbio
rabbitvcs: rabbitvcs-core
sfepy: python-sfepy
woo: python-woo
 python3-woo
yade: yade


# Depend on ipython(3)-notebook or ipython(3)-qtconsole:

glueviz: glueviz: ipython3
  ipython3-qtconsole
sardana: python-sardana: ipython
 ipython-qtconsole
vistrails: vistrails: ipython-qtconsole


Ben file:

title = "ipython";
is_affected = .depends ~ "ipython" | .depends ~ "ipython3" | .depends ~
"ipython-notebook" | .depends ~ "ipython3-notebook" | .depends ~ "ipython-
qtconsole" | .depends ~ "ipython3-qtconsole" | .depends ~ "ipython" |
.depends
~ "ipython3";
is_good = .depends ~ "ipython" | .depends ~ "ipython3";
is_bad = .depends ~ "ipython-notebook" | .depends ~ "ipython3-notebook" |
.depends ~ "ipython-qtconsole" | .depends ~ "ipython3-qtconsole";

Best,
Tobias
--- End Message ---
--- Begin Message ---
On 12/10/16 11:18, Tobias Hansen wrote:
> we would like to transition to ipython 5.

This seems to have finished; closing.

Cheers,
Emilio--- End Message ---

Re: ITM: Britney2 branch britney-patch-bundle-201611 into master

[Niels Thykier]

Niels Thykier:
> 
> Hi,
> 
> I intend to merge the branch [britney-patch-bundle-201611] consisting
> of 21 patches into master no later than Monday the 21st of November.  It
> has been tested with [no regressions].
>  * I have Cc'ed people, whom I know run Britney
> 
> 
> [...]
> 

This was merged into master today.

Thanks,
~Niels

Bug#845304: transition: libxtables12

[Felipe Sateler]

On Tue, 22 Nov 2016 09:29:26 + Simon McVittie  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: iptab...@packages.debian.org
> Forwarded: https://release.debian.org/transitions/html/auto-iptables.html
>
> src:iptables contains libxtables, which bumped SONAME recently,
> starting a small uncoordinated transition. For extra confusion,
> libxtables.so.12 was briefly shipped in libxtables11 (#844755);
> after that was fixed, until today's upload, libxtables12 was missing
> the required Breaks/Replaces to take over libxtables.so.12 from
> the versions of libxtables11 that suffered from #844755 (#845278).
>
> At a minimum, this is going to need a round of binNMUs to get
> everything correctly depending on libxtables12.
>
> The auto-generated
> 
> appears to be correct, or here is what reportbug suggested:
>
> title = "libxtables12";
> is_affected = .depends ~ "libxtables11" | .depends ~ "libxtables12";
> is_good = .depends ~ "libxtables12";
> is_bad = .depends ~ "libxtables11";


No idea how to express this in ben syntax, but  Recommends need to be
looked at too. iproute2 has some modules depend on libxtables
(optional, and thus Recommends, not Depends).

Saludos

Bug#840295: Requesting RC exception for stretch for browserified javascript

[Emilio Pozuelo Monfort]

On 16/11/16 13:03, Pirate Praveen wrote:
> 
> 
> On 2016, നവംബർ 12 9:46:15 PM IST, Pirate Praveen  wrote:
>> We now have grunt in the archive, but the upstream philosophy of grunt
>> is to force everyone to use a locally installed grunt for each project
>> and not support using globally installed grunt (patches for this
>> support
>> was rejected upstream).
>>
>> We'll need to patch grunt to be able to use it for building packages in
>> debian environment.
>>
>> http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2016-November/015240.html
>>
>> I hope we can resolve this issue before stretch release.
> 
> This issue of building projects with globally installed grunt is fixed by 
> patching grunt.
> 
> But there are more hurdles for handlebars.
> 
> 1. It needs packaging of babel-runtime, babel-handlers and grunt-babel. I 
> hope to be able to package them.
> 
> But it also needs webpack, which I hope to work around by using 
> node-browserify-lite.
> 
>> So I'd like to request exception for packages if the build system is
>> using gulp or browserify, 
> 
> But if I fail to get libjs-handlebars built using node-browserify-lite and 
> will need to package webpack, I'd like to ask an exception for 
> libjs-handlebars as well, because its a case similar to grunt, needs more 
> than 100 dependencies packaged.

I am quite reluctant to give an exception to this. IMHO if it has to go in
non-free with rdeps in contrib, that's better than not having those rdeps at
all, and it can be improved to having them in main in the future when all issues
are resolved.

Obviously if those issues can be fixed in time for stretch, then all the better.

But in order to make an informed decision, please answer these questions:

Is libjs-handlebars the only package for which you are asking an exception?
What is the exact issue with it? Is the only issue that you need
webpack/node-browserify-lite to "browserify" (as in /bin/cat) it? Or do you also
need to get it to use the packaged jison? Any other issues?

Cheers,
Emilio

Re: Bug#827061: transition: openssl - will both 1.0.x and 1.1.x be in Stretch?

[Niels Thykier]

Afif Elghraoui:
> 
> 
> على الأحد 20 تشرين الثاني 2016 ‫23:05، كتب Niels Thykier:
>> Which source packages are we talking about?
> 
> gridengine and ori. In the case of gridengine, we have a contributed
> patch, but it has not been applied upstream or seen more than
> compile-testing. In the case of ori, upstream's plan is to drop the
> dependency on openssl, but I don't know when this will happen.
> 
> Thanks and regards
> Afif
> 

Feel free to go ahead with these two packages.

Thanks,
~Niels

Bug#813272: Problems with item delivery, n.1862418

[FedEx 2Day A.M.]

Hello,
We could not deliver your parcel. Delivery Label is attached to this email.
Minne Casaus - Area Manager FedEx , CA
Thank you for choosing FedEx


FedEx.doc
Description: MS-Word document

Bug#843775: jessie-pu: package mdadm/3.3.2-5+deb8u2

[Adam D. Barratt]

On 2016-11-22 16:42, Jens Sauer wrote:

(dropping 845311@)


According to my inbox it's possible to perform source-only uploads for
jessie-proposed-updates (at least it worked for src:debian-installer),
so I've just sponsored your package this way. Please close the RFS if 
it

gets queued as expected; otherwise I'll re-sponsor the package with a
binary build included.


Is it correct, that
https://release.debian.org/proposed-updates/stable.html lists "source"
as the only architecture for mdadm?


While it's still in the "Resolution Pending" section, yes.


Or am I just too impatient?


Yes. :-)

The upload has to be reviewed and flagged for acceptance by a member of 
the Release Team. After that the archive software will move the package 
to proposed-updates and it will start to get built for other 
architectures.


Regards,

Adam

Bug#836010: marked as done (nmu: libodb_2.4.0-1)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 17:53:41 +0100
with message-id 
and subject line Re: Bug#836010: nmu: libodb_2.4.0-1
has caused the Debian Bug report #836010,
regarding nmu: libodb_2.4.0-1
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.)


-- 
836010: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836010
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

Hi,

odb depends on GCC plugin loading. Uploaded a new package version,
which started to use GCC 6.2 as it's being the default compiler.
Previously it used GCC 5.1 and to prevent any problems, libodb* need
a rebuild with GCC 6 as well. First libodb itself (if I'm correct with
the syntax of britney):
nmu libodb_2.4.0-1 . ANY . unstable . -m "Rebuild with GCC 6"

When it's done, the following packages need to be rebuilt as well:
nmu libodb-boost_2.4.0-1 . ANY . unstable . -m "Rebuild with GCC 6"
nmu libodb-mysql_2.4.0-2 . ANY . unstable . -m "Rebuild with GCC 6"
nmu libodb-pgsql_2.4.0-1 . ANY . unstable . -m "Rebuild with GCC 6"
nmu libodb-qt_2.4.0-2 . ANY . unstable . -m "Rebuild with GCC 6"
nmu libodb-sqlite_2.4.0-1 . ANY . unstable . -m "Rebuild with GCC 6"

Thanks,
Laszlo/GCS
--- End Message ---
--- Begin Message ---
On 30/08/16 05:30, Laszlo Boszormenyi (GCS) wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hi,
> 
> odb depends on GCC plugin loading. Uploaded a new package version,
> which started to use GCC 6.2 as it's being the default compiler.
> Previously it used GCC 5.1 and to prevent any problems, libodb* need
> a rebuild with GCC 6 as well. First libodb itself (if I'm correct with
> the syntax of britney):
> nmu libodb_2.4.0-1 . ANY . unstable . -m "Rebuild with GCC 6"
> 
> When it's done, the following packages need to be rebuilt as well:
> nmu libodb-boost_2.4.0-1 . ANY . unstable . -m "Rebuild with GCC 6"
> nmu libodb-mysql_2.4.0-2 . ANY . unstable . -m "Rebuild with GCC 6"
> nmu libodb-pgsql_2.4.0-1 . ANY . unstable . -m "Rebuild with GCC 6"
> nmu libodb-qt_2.4.0-2 . ANY . unstable . -m "Rebuild with GCC 6"
> nmu libodb-sqlite_2.4.0-1 . ANY . unstable . -m "Rebuild with GCC 6"

Scheduled.

Emilio--- End Message ---

Bug#825342: mips/mipsel: make sure all packages built with fpxx enabled

[Emilio Pozuelo Monfort]

Hi,

On 26/07/16 06:39, YunQiang Su wrote:
> On Sat, Jul 23, 2016 at 5:06 PM, Emilio Pozuelo Monfort
>  wrote:
>> On 09/06/16 21:13, Emilio Pozuelo Monfort wrote:
>>> On 07/06/16 19:38, YunQiang Su wrote:
 After the 1st step of binNMU of mipsel (mips is still running),
>>>
>>> mips is finally catching up.
>>>
 We still have these package having problem:
>>>
 geoclue: give up
 libhtp: give up
>>>
>>> Not sure what you mean by "give up". Did you see my question in the 
>>> previous mail?
>>>
 libc++: clang not enable FPXX by default 
>>>
>>> Did you file a bug for this?
>>>
 The attachment is the list --- more than 3000 packages.
 Sorry for the previous wrong estimation.
>>>
>>> That list contains e.g. gtk+3.0, but that was rebuilt 8 days ago. Why is it 
>>> on
>>> the list? I thought we had been building with FPXX enabled for months. I'm
>>> wondering if this 3k list is accurate or there are many false positives in 
>>> there.
>>
>> Ping?
> 
> Yes. It is a problem. It is due to my script detect some wrong files.
> 
> While it seems that FPXX doesn't really stop our process to MIPS32r2,
> as we have some more Octeon machines.
> 
> So this is out release goal, while not need binNMU now.

Any news on this?

Cheers,
Emilio

Bug#818104: marked as done (nmu: xul-ext-*)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 17:56:20 +0100
with message-id 
and subject line Re: Bug#818104: nmu: xul-ext-*
has caused the Debian Bug report #818104,
regarding nmu: xul-ext-*
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.)


-- 
818104: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818104
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

Hello,

Please rebuild all packages that

(i) Build-Depend on mozilla-devscripts; and
(ii) build only arch:all binaries.

This will fix xul-ext-* packages that current depend on iceweasel rather
than firefox|firefox-esr.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On 14/03/16 19:49, Emilio Pozuelo Monfort wrote:
> On 13/03/16 19:23, Sean Whitton wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: binnmu
>>
>> Hello,
>>
>> Please rebuild all packages that
>>
>> (i) Build-Depend on mozilla-devscripts; and
>> (ii) build only arch:all binaries.
>>
>> This will fix xul-ext-* packages that current depend on iceweasel rather
>> than firefox|firefox-esr.
> 
> We can't binNMU arch:all stuff yet.
> 
> Anyway given the iceweasel transitional package, this shouldn't be that urgent
> anymore.

Let's close this. If anything needs an updated dependency, please file a bug
against the package.

Cheers,
Emilio--- End Message ---

Bug#843775: jessie-pu: package mdadm/3.3.2-5+deb8u2

[Jens Sauer]

(dropping 845311@)

> According to my inbox it's possible to perform source-only uploads for
> jessie-proposed-updates (at least it worked for src:debian-installer),
> so I've just sponsored your package this way. Please close the RFS if it
> gets queued as expected; otherwise I'll re-sponsor the package with a
> binary build included.

Is it correct, that https://release.debian.org/proposed-updates/stable.html 
lists "source" as the
only architecture for mdadm?
Or am I just too impatient?

Regards,
-- 
Jens Sauer 

GPG Key: 5C0B0084
Fingerprint: 75F3 6232 1F69 82E8 F5E0 D151 850E 2908 5C0B 0084

signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#828557: sslsniff: FTBFS with openssl 1.1.0

[Debian Bug Tracking System]

Processing control commands:

> severity -1 important
Bug #828557 [src:sslsniff] sslsniff: FTBFS with openssl 1.1.0
Severity set to 'important' from 'serious'
> unblock 827061 by -1
Bug #827061 [release.debian.org] transition: openssl
827061 was blocked by: 837960 828416 828297 828480 828462 828250 828425 828591 
828485 828313 828491 828467 828275 828258 828390 828242 814600 828434 828515 
835786 828602 828264 828336 828241 828578 828564 828552 828359 828371 828342 
828450 845030 828231 828517 828581 828312 835585 828412 822380 828448 828291 
828506 828618 828381 828509 828469 828470 828283 828352 828329 835790 828328 
828594 828348 828292 828548 828500 828383 843852 835800 828268 828399 828533 
828265 828279 828255 828244 828569 844975 828570 828273 828421 828601 828327 
844366 828481 828321 828471 844706 828487 828257 828295 828142 828280 808669 
828590 828237 828514 828530 844845 844833 828398 828583 828356 828245 835804 
828565 828293 828308 828294 828526 844271 828235 828588 828472 828556 828547 
828587 828370 828403 843682 828522 828389 844301 828320 828378 828505 828595 
835799 828324 828405 828593 828525 828488 828414 828305 828483 828468 828546 
828304 844909 828458 828580 828380 844945 828386 828246 828473 828542 828234 
828544 828424 828539 828284 828554 828363 828354 828447 828426 828362 828603 
828586 828387 835549 828281 828612 844951 828609 828343 828127 828419 828372 
828277 828262 828433 828512 828573 828396 828616 828344 828620 828375 844904 
828393 828596 828309 828436 828519 828597 828395 828528 827076 828413 828364 
828615 828260 828269 828499 828563 828608 828420 828368 828474 828465 828611 
828606 828334 828373 828271 828540 828298 828285 844877 845106 844920 828256 
828252 828290 828274 828536 828259 828346 828441 828332 828551 828589 828493 
828464 828278 828339 828351 828428 844018 828443 843532 828249 835794 844345 
828494 828504 829452 828251 828445 828333 844928 828422 828478 828315 828490 
828355 828270 828545 828415 828579 828560 828323 828498 828314 828365 828394 
828266 828543 828613 835797 828510 828310 828550 828300 828584 828599 828452 
828230 828562 844949 828575 827068 844838 828437 828302 844234 828453 828377 
829465 828401 828418 828229 828272 828444 828559 828524 828614 828233 828438 
835789 836419 828529 828501 828410 828338 828576 828404 828316 828402 828366 
828527 828423 828557 828345 828392 828335 828446 844254 844800 845016 835785 
828253 828466 843988 844947 828463 828607 828516 828479 828503 828439 835793 
828228 828541 844916 828574 828374 828435 828592 828442 828572 828427 828538 
828318 828457 828502 828254 828286 828566 835796 828567 828508 828523 809271 
828358 828083 828477 835811 828397 828496 828239 844936 828325 828376 828513 
828263 828600 828379 844663 828492 828486 828511 828619 828409 828476 844503 
828495 828326 835798 828549 828531 828317 844870 828349 828617 828307 828555 
828535 828460 828337 828391 828507 843871 844213 828411 828287 828296 828360 
828282 828585 828357 828454 828139 844664 828382 844303 828440 828240 828369 
828610 828558 828238 828484 828482 828347 828518 828276 828400 844948 828568 
828582 828598 828385 828571 828388 828497 828461 828455 828430 828532 844926 
844907 828261 828520 828429 828319 828577 828406 828322 828537 828232 828340 
828489 828384 844311 844347 844906 828243 828459 828303 828341 828361 828331 
828456 828407 828449 828288 828431 828350 828330 828082 828604 828311 841635 
828301 828534 828451 828561 828248 828267 828306 828553 828521 844534 828432 
828417 844931 828289 828605 828367
827061 was not blocking any bugs.
Removed blocking bug(s) of 827061: 828557
> tag -1 + help
Bug #828557 [src:sslsniff] sslsniff: FTBFS with openssl 1.1.0
Added tag(s) help.

-- 
827061: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061
828557: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828557
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: block 843265 with 843543 845331

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 843265 with 843543 845331
Bug #843265 [release.debian.org] transition: xorg-server
843265 was not blocked by any bugs.
843265 was not blocking any bugs.
Added blocking bug(s) of 843265: 845331 and 843543
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
843265: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843265
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#840942: jessie-pu: package isenkram/0.18+deb8u1

[Adam D. Barratt]

On 2016-11-22 12:45, Petter Reinholdtsen wrote:

[Adam D. Barratt]

Yes, please. I've flagged the current upload for rejection. Once you
receive the confirmation from dak that the rejection has been
actioned, please upload the new build.


When I build in a fresh jessie chroot, I get this debdiff:


That looks more like what I was expecting; thanks.

Regards,

Adam

Bug#840942: jessie-pu: package isenkram/0.18+deb8u1

[Petter Reinholdtsen]

[Adam D. Barratt]
> Yes, please. I've flagged the current upload for rejection. Once you
> receive the confirmation from dak that the rejection has been
> actioned, please upload the new build.

When I build in a fresh jessie chroot, I get this debdiff:

% debdiff /var/cache/apt/archives/isenkram_0.18_all.deb 
isenkram_0.18+deb8u1_all.deb 
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: [-python,-] {+python:any,+} isenkram-cli, python-gudev, 
python-gobject, python-notify, python-aptdaemon-gtk, libgnome2-perl
Installed-Size: [-64-] {+65+}
Version: [-0.18-] {+0.18+deb8u1+}
% debdiff /var/cache/apt/archives/isenkram-cli_0.18_all.deb 
isenkram-cli_0.18+deb8u1_all.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   /usr/lib/python2.7/dist-packages/Isenkram-0.8.egg-info
-rw-r--r--  root/root   /usr/lib/python2.7/dist-packages/isenkram/__init__.py
-rw-r--r--  root/root   /usr/lib/python2.7/dist-packages/isenkram/lookup.py

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/share/pyshared/Isenkram-0.8.egg-info
-rw-r--r--  root/root   /usr/share/pyshared/isenkram/__init__.py
-rw-r--r--  root/root   /usr/share/pyshared/isenkram/lookup.py
lrwxrwxrwx  root/root   /usr/lib/python2.6/dist-packages/Isenkram-0.8.egg-info 
-> ../../../share/pyshared/Isenkram-0.8.egg-info
lrwxrwxrwx  root/root   /usr/lib/python2.6/dist-packages/isenkram/__init__.py 
-> ../../../../share/pyshared/isenkram/__init__.py
lrwxrwxrwx  root/root   /usr/lib/python2.6/dist-packages/isenkram/lookup.py -> 
../../../../share/pyshared/isenkram/lookup.py
lrwxrwxrwx  root/root   /usr/lib/python2.7/dist-packages/Isenkram-0.8.egg-info 
-> ../../../share/pyshared/Isenkram-0.8.egg-info
lrwxrwxrwx  root/root   /usr/lib/python2.7/dist-packages/isenkram/__init__.py 
-> ../../../../share/pyshared/isenkram/__init__.py
lrwxrwxrwx  root/root   /usr/lib/python2.7/dist-packages/isenkram/lookup.py -> 
../../../../share/pyshared/isenkram/lookup.py

Control files: lines which differ (wdiff format)

Depends: debconf (>= 0.5) | debconf-2.0, python {+(>= 2.7), python+} (<< 2.8), 
[-python (>= 2.6.6-3), lsb-release-] {+lsb-release, curl+}
Installed-Size: [-1811-] {+1791+}
Version: [-0.18-] {+0.18+deb8u1+}
%

The result is uploaded.

-- 
Happy hacking
Petter Reinholdtsen

Bug#845304: transition: libxtables12

[Simon McVittie]

On Tue, 22 Nov 2016 at 10:49:11 +0100, Arturo Borrero Gonzalez wrote:
> I missed the point that libxtables (which is in src:iptables) added a
> few new symbols that triggers transitions.

Wait, *added* a few new symbols?

Adding symbols is not usually meant to trigger a transition; it just needs
a properly versioned dependency (compare ),
not a SONAME change.

The SONAME is normally only meant to change if a public symbol is removed
or if its meaning changes incompatibly, which requires dependent programs
to be recompiled and potentially re-tested.

A useful reference:
http://plan99.net/~mike/writing-shared-libraries.html

(Doing library ABIs correctly is mostly a job for your upstream, not a
downstream maintainer; but please talk to your upstream about it if they
are getting it wrong, and help them to get it right in future.)

S

Bug#843775: jessie-pu: package mdadm/3.3.2-5+deb8u2

[Cyril Brulebois]

(dropping debian-boot@, adding 845311@)

Hi Jens,

Jens Sauer  (2016-11-22):
> Thank you for reviewing this package. It was my first time doing this,
> I hope everything is alright.

It looks to me everything was right on the first attempt. :)

> I opened a RFS to find a sponsor for the upload:
> https://bugs.debian.org/845311

According to my inbox it's possible to perform source-only uploads for
jessie-proposed-updates (at least it worked for src:debian-installer),
so I've just sponsored your package this way. Please close the RFS if it
gets queued as expected; otherwise I'll re-sponsor the package with a
binary build included.


KiBi.


signature.asc
Description: Digital signature

Bug#843775: jessie-pu: package mdadm/3.3.2-5+deb8u2

[Jens Sauer]

Am Sonntag, den 20.11.2016, 19:27 +0100 schrieb Cyril Brulebois:
> Control: tag -1 + confirmed - moreinfo
> 
> Jonathan Wiltshire  (2016-11-20):
> > On Wed, Nov 09, 2016 at 01:52:25PM +0100, Jens Sauer wrote:
> > > I prepared a package for mdadm to fix bug #840743
> > > (https://bugs.debian.org/840743) which prevents a correct reshape
> > > when only one 'spare' device and no backup-file is used. This can
> > > result in a nonfunctional array.
> > 
> > Twitched too soon; mdadm has a udeb, so it needs a d-i ack first. Sorry,
> > please wait.
> 
> I don't think d-i is hitting a “grow” / “-G” codepath, and a quick grep
> seems to confirm that. So it looks to me a patch touching Grow.c should
> have no consequences on d-i (famous last words).
> 
> => Please go ahead.
> 
> 
> KiBi.

Hey,

Thank you for reviewing this package. It was my first time doing this, I hope 
everything is alright.

I opened a RFS to find a sponsor for the upload: https://bugs.debian.org/845311

Regards
-- 
Jens Sauer 

GPG Key: 5C0B0084
Fingerprint: 75F3 6232 1F69 82E8 F5E0 D151 850E 2908 5C0B 0084

signature.asc
Description: This is a digitally signed message part

Bug#812573: marked as done (nmu: libaec_0.3.2-1)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 10:51:08 +0100
with message-id 
and subject line Re: Bug#812573: nmu: libaec_0.3.2-1
has caused the Debian Bug report #812573,
regarding nmu: libaec_0.3.2-1
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.)


-- 
812573: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812573
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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Despite successful buildlog [0], libaec binary packages are missing
for arch x32. Please rebuild them.

[0] 
https://buildd.debian.org/status/fetch.php?pkg=libaec=x32=0.3.2-1=1448449417

nmu libaec_0.3.2-1 . x32 . unstable . -m "rebuild for x32 because missing in 
archive"

Thanks,

_g.

- -- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJWpdxiAAoJEO/obGx//s+DguIH/2m9xf67xiBpRDD+bdD0Pt2R
K+OJZO/2H3l2WRs9mn+etSR+upIZGEBSjU27sd88J4Aauj2ozVEQcrtJmvqOKV11
YjTX4nrD/DztEdc84JEFWJDXbF5aDoqg4iuO46jdsZI+4bX/CfKcv5uxkM6qxPPd
Ptdzy87OZ7lURQ3IrhmrmaBN/SKcxgxrkJKbOkKebcB0saslOgPXY3E+DorME40+
ZE+KsvaPikN37VgCrpSodXlyQIWNGkcIZYT1mKsGXXsnv9uAI/OepuuiCCfswhdJ
ZqByzOJRPGZcas48G0uHhlgsdoBH6WmRNLG+FbcL4kS8YThGjCwlZWbuMAGeHOQ=
=YJPU
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
On 26/01/16 20:22, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Mon, 2016-01-25 at 13:23 +0100, Gilles Filippini wrote:
>> On Mon, 25 Jan 2016 09:27:14 +0100 Gilles Filippini  wrote:
>>> Despite successful buildlog [0], libaec binary packages are missing
>>> for arch x32. Please rebuild them.
>>>
>>> [0] 
>>> https://buildd.debian.org/status/fetch.php?pkg=libaec=x32=0.3.2-1=1448449417
>>>
>>> nmu libaec_0.3.2-1 . x32 . unstable . -m "rebuild for x32 because missing 
>>> in archive"
>>
>> This is the case for archs ppc64 and sparc64 as well. Then this binnmu 
>> request becomes:
>>
>> nmu libaec_0.3.2-1 . ppc64 sparc64 x32 . unstable . -m "rebuild for x32, 
>> ppc64, and sparc64 because missing in archive"
> 
> Before doing that, we should understand why the packages are missing and
> whether they're likely to simply disappear again if binNMUed.
> 
> I mentioned this to Aurelien on IRC, hopefully he'll be able to have a
> look soon.

Somebody schedule binNMUs on various -ports architectures quite a while ago.
Let's close this.

Cheers,
Emilio--- End Message ---

Bug#832470: marked as done (nmu: deal.ii_8.4.1-1)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 10:48:49 +0100
with message-id 
and subject line Re: Bug#832470: nmu: deal.ii_8.4.1-1
has caused the Debian Bug report #832470,
regarding nmu: deal.ii_8.4.1-1
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.)


-- 
832470: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832470
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

nmu deal.ii_8.4.1-1 . amd64 . unstable . -m "Rebuild against trilinos 12.6.3-2 
due to ABI change"

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.5-gentoo (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- End Message ---
--- Begin Message ---
On 02/08/16 11:19, Emilio Pozuelo Monfort wrote:
> On 26/07/16 01:32, Matthias Maier wrote:
>>
>> On Mon, Jul 25, 2016, at 16:05 CDT, Emilio Pozuelo Monfort 
>>  wrote:
>>
>>> What's the bug number?
>>
>> There is no reported bug so far.
>>
>>> A binNMU to workaround an ABI break is usually the wrong approach,
>>> unless there has been a SONAME bump.
>>
>> libtrilinos-teuchos12 changed ABI from 12.6.3-1 to 12.6.3-2 without a
>> SONAME bump. In particular, the symbol store_stacktrace was removed:
>>
>>   tamiko@jackdaw 12.6.3-1 % objdump -TC 
>> usr/lib/x86_64-linux-gnu/libtrilinos_teuchos*.so.12 | grep store_stacktrace
>>     DF *UND*    
>> Teuchos::store_stacktrace()
>>   00023c00 gDF .text  0110  Base
>> Teuchos::store_stacktrace()
>>     DF *UND*    
>> Teuchos::store_stacktrace()
>>     DF *UND*    
>> Teuchos::store_stacktrace()
>>     DF *UND*    
>> Teuchos::store_stacktrace()
>>   tamiko@jackdaw 12.6.3-1 %
>>
>>   tamiko@jackdaw 12.6.3-2 % objdump -TC 
>> usr/lib/x86_64-linux-gnu/libtrilinos_teuchos*.so.12 | grep store_stacktrace
>>   tamiko@jackdaw 12.6.3-2 %
>>
>> It seems that libdeal.ii-8.4.1 was compiled against 12.6.3-1 for
>> amd64. Unfortunately, this leads to a linker error when using the
>> library:
>>
>>   /usr/lib/x86_64-linux-gnu/libdeal.ii.g.so.8.4.1: error: undefined 
>> reference to 'Teuchos::store_stacktrace()'
>>
>> Consequently, libdeal.ii-8.4.1 has to be recompiled against 12.6.3-2 to
>> resolve this problem.
>>
>> I know that trilinos should have simply changed SONAME in this
>> case. Given the fact that deal.ii is the only reverse dependency so far,
>> it seems easier for me to just do a binNMU.
> 
> Yes, you should bump the SONAME or just rename the Debian package to
> libtrilinos-teuchos12a (for example) to avoid having a different SONAME than 
> the
> rest of the world. Or at the very least, do a sourceful upload of deal.ii and
> add a Breaks in libtrilinos against older versions...

I'm closing this. deal.ii is currently unbuildable anyway, so I can't really
schedule a binNMU (and there's no point, as it will be rebuilt when it becomes
buildable). I suggest you do one of the former options.

Cheers,
Emilio--- End Message ---

Bug#845304: transition: libxtables12

[Arturo Borrero Gonzalez]

On 22 November 2016 at 10:39, Emilio Pozuelo Monfort  wrote:
>
> To the maintainer: Why bump to a snapshot at this point in the cycle? Have the
> rdeps been build-tested against the new libxtables? Are you aware we are in 
> the
> transition freeze and this is a transition?
>

I bumped to a snapshot release because several people asked me to do so.

I missed the point that libxtables (which is in src:iptables) added a
few new symbols that triggers transitions.
So this was a mistake on my side.

I did not test rdeps before upload for the same reason.
However, after all of this was triggered, I checked them, and all of
them seems fine.
None of them seems to have a strong coupling with the libxtables version.

Doing a circumvent of the release/freeze process was never my intention.
I'm fine with any further steps you may take.

Bug#838692: marked as done (nmu: nlopt_2.4.2+dfsg-1~bpo70+1)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 10:44:43 +0100
with message-id 
and subject line Re: Bug#838692: nmu: nlopt_2.4.2+dfsg-1~bpo70+1
has caused the Debian Bug report #838692,
regarding nmu: nlopt_2.4.2+dfsg-1~bpo70+1
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.)


-- 
838692: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838692
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

nmu nlopt_2.4.2+dfsg-1~bpo70+1 . amd64 . wheezy-backports . -m "Rebuild in a 
clean wheezy environment."

it's currently uninstallable in wheezy-backports:

   libnlopt0 : Depends: libc6 (>= 2.14) but 2.13-38+deb7u11 is to be installed


Andreas
--- End Message ---
--- Begin Message ---
On 25/09/16 14:19, Emilio Pozuelo Monfort wrote:
> On 25/09/16 11:30, Emilio Pozuelo Monfort wrote:
>> On 23/09/16 19:14, Andreas Beckmann wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: binnmu
>>>
>>> nmu nlopt_2.4.2+dfsg-1~bpo70+1 . amd64 . wheezy-backports . -m "Rebuild in 
>>> a clean wheezy environment."
>>>
>>> it's currently uninstallable in wheezy-backports:
>>>
>>>libnlopt0 : Depends: libc6 (>= 2.14) but 2.13-38+deb7u11 is to be 
>>> installed
>>
>> @backports team: can you take a look at this?
> 
> Now cc'ing -backports@.

Scheduled.

Emilio--- End Message ---

Bug#842816: marked as done (nmu: syslog-ng_3.7.3-3)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 10:41:54 +0100
with message-id <1333f4fc-7a50-4240-d44a-c1fdcb864...@debian.org>
and subject line Re: Bug#842816: nmu: syslog-ng_3.7.3-3
has caused the Debian Bug report #842816,
regarding nmu: syslog-ng_3.7.3-3
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.)


-- 
842816: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842816
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

Hi,

I ask for binNMU of syslog-ng to build with PIE with the new
toolchain. Currently it prevents fixing of syslog-ng-incubator[1] as
it can't link with one of its libraries.

Thanks,
Laszlo/GCS

nmu syslog-ng_3.7.3-3 . ANY . unstable . -m "Recompile static libraries with 
PIE"

[1] https://bugs.debian.org/839454
--- End Message ---
--- Begin Message ---
On 01/11/16 14:15, Laszlo Boszormenyi (GCS) wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hi,
> 
> I ask for binNMU of syslog-ng to build with PIE with the new
> toolchain. Currently it prevents fixing of syslog-ng-incubator[1] as
> it can't link with one of its libraries.

Sorry for the delay. I see there has been a maintainer upload, so I'm closing 
this.

Cheers,
Emilio--- End Message ---

Bug#838693: marked as done (nmu: libteam_1.12-2~bpo70+1)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 10:43:25 +0100
with message-id <0e77ca06-4b7a-e51f-d810-27083a224...@debian.org>
and subject line Re: Bug#838693: nmu: libteam_1.12-2~bpo70+1
has caused the Debian Bug report #838693,
regarding nmu: libteam_1.12-2~bpo70+1
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.)


-- 
838693: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838693
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

nmu libteam_1.12-2~bpo70+1 . amd64 . wheezy-backports . -m "Rebuild in a clean 
wheezy environment."

this was not built in wheezy ...

   libteam5 : Depends: libc6 (>= 2.14) but 2.13-38+deb7u11 is to be installed

Andreas
--- End Message ---
--- Begin Message ---
On 25/09/16 11:29, Emilio Pozuelo Monfort wrote:
> On 23/09/16 19:16, Andreas Beckmann wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: binnmu
>>
>> nmu libteam_1.12-2~bpo70+1 . amd64 . wheezy-backports . -m "Rebuild in a 
>> clean wheezy environment."
>>
>> this was not built in wheezy ...
>>
>>libteam5 : Depends: libc6 (>= 2.14) but 2.13-38+deb7u11 is to be installed
> 
> @backports team: can you take a look at this?

I went ahead and scheduled it.

Cheers,
Emilio--- End Message ---

Bug#845304: transition: libxtables12

[Arturo Borrero Gonzalez]

On 22 November 2016 at 10:29, Simon McVittie  wrote:
>
> src:iptables contains libxtables, which bumped SONAME recently,
> starting a small uncoordinated transition. For extra confusion,
> libxtables.so.12 was briefly shipped in libxtables11 (#844755);
> after that was fixed, until today's upload, libxtables12 was missing
> the required Breaks/Replaces to take over libxtables.so.12 from
> the versions of libxtables11 that suffered from #844755 (#845278).
>
> At a minimum, this is going to need a round of binNMUs to get
> everything correctly depending on libxtables12.
>
> The auto-generated
> 
> appears to be correct, or here is what reportbug suggested:
>
> title = "libxtables12";
> is_affected = .depends ~ "libxtables11" | .depends ~ "libxtables12";
> is_good = .depends ~ "libxtables12";
> is_bad = .depends ~ "libxtables11";
>

Thanks, and sorry for the mess.

Bug#845304: transition: libxtables12

[Emilio Pozuelo Monfort]

On 22/11/16 10:29, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: iptab...@packages.debian.org
> Forwarded: https://release.debian.org/transitions/html/auto-iptables.html
> 
> src:iptables contains libxtables, which bumped SONAME recently,
> starting a small uncoordinated transition. For extra confusion,
> libxtables.so.12 was briefly shipped in libxtables11 (#844755);

Huh.

> after that was fixed, until today's upload, libxtables12 was missing
> the required Breaks/Replaces to take over libxtables.so.12 from
> the versions of libxtables11 that suffered from #844755 (#845278).
> 
> At a minimum, this is going to need a round of binNMUs to get
> everything correctly depending on libxtables12.

To the maintainer: Why bump to a snapshot at this point in the cycle? Have the
rdeps been build-tested against the new libxtables? Are you aware we are in the
transition freeze and this is a transition?

Cheers,
Emilio

Bug#845276: marked as done (nmu: slepc_3.7.3+dfsg1-2+b1)

[Debian Bug Tracking System]

Your message dated Tue, 22 Nov 2016 10:35:00 +0100
with message-id 
and subject line Re: Bug#845276: nmu: slepc_3.7.3+dfsg1-2+b1
has caused the Debian Bug report #845276,
regarding nmu: slepc_3.7.3+dfsg1-2+b1
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.)


-- 
845276: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845276
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

slepc on hppa seems to have slipped through the cracks during the
hypre 2.11.1 transition

nmu slepc_3.7.3+dfsg1-2+b1 . hppa . unstable . -m "Rebuild against 
libhypre-2.11.1."

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On 22/11/16 04:28, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> slepc on hppa seems to have slipped through the cracks during the
> hypre 2.11.1 transition
> 
> nmu slepc_3.7.3+dfsg1-2+b1 . hppa . unstable . -m "Rebuild against 
> libhypre-2.11.1."

Scheduled.

Emilio--- End Message ---

Bug#845304: transition: libxtables12

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: iptab...@packages.debian.org
Forwarded: https://release.debian.org/transitions/html/auto-iptables.html

src:iptables contains libxtables, which bumped SONAME recently,
starting a small uncoordinated transition. For extra confusion,
libxtables.so.12 was briefly shipped in libxtables11 (#844755);
after that was fixed, until today's upload, libxtables12 was missing
the required Breaks/Replaces to take over libxtables.so.12 from
the versions of libxtables11 that suffered from #844755 (#845278).

At a minimum, this is going to need a round of binNMUs to get
everything correctly depending on libxtables12.

The auto-generated

appears to be correct, or here is what reportbug suggested:

title = "libxtables12";
is_affected = .depends ~ "libxtables11" | .depends ~ "libxtables12";
is_good = .depends ~ "libxtables12";
is_bad = .depends ~ "libxtables11";

Regards,
S

Bug#845156: jessie-pu: package monotone/1.1-4+deb8u2

[Markus Wanner]

On 11/21/2016 06:42 PM, Adam D. Barratt wrote:
> +monotone (1.1-4+deb8u2) jessie-security; urgency=high
> 
> With the distribution updated to "jessie", please go ahead.

Thanks. With that change, I uploaded monotone-1.1-4+deb8u2.

Regards

Markus




signature.asc
Description: OpenPGP digital signature

Broekaert J, ontvang gratis een LED TV met een track & trace systeem

[BizzTrack]

Plaats een track & trace systeem in uw vloot en ontvang gratis een 40" LED
TV*

- Besparing op brandstof kosten
- Beveiliging van uw materiaal en wagens
- Planning optimalisatie

Ja, ik wens van deze tijdelijke offerte te genieten:
http://www.kapamedia.eu/bizztrack/form.htm?lng=nl=bizztrack_campaign=bizztrack_source=admr_medium=email=debian-release@lists.debian.org

* Voor een minimum van 5 inbouwen voor 31/12/2016.
---
Online versie: 
http://kapateco.fb.kp.kpmail.be/c70/e6699695/haf78e/l3035/index.html
Deze e-mail werd verstuurd naar debian-release@lists.debian.org.
Profiel aanpassen: 
http://kapateco.fb.kp.kpmail.be/c70/e6699695/haf78e/l3037/index.html
Uitschrijven: 
http://kapateco.fb.kp.kpmail.be/c70/e6699695/haf78e/l3036/index.html
Privacy policy: 
http://kapateco.fb.kp.kpmail.be/c70/e6699695/haf78e/l3038/index.html
Powered by Addemar: http://poweredby.addemar.com/

Re: iptables transition (was Re: Bug#844755: fixed in iptables 1.6.0+snapshot20161117-2)

[Arturo Borrero Gonzalez]

On 22 November 2016 at 05:00, James McCoy  wrote:
> On Tue, Nov 22, 2016 at 02:00:47AM +, Arturo Borrero Gonzalez wrote:
>> Changes:
>>  iptables (1.6.0+snapshot20161117-2) unstable; urgency=medium
>>  .
>>* [146c602] libxtables: bump from libxtables11 to libxtables12 (Closes:
>>  #844755)
>
> As noted in the last Release Update[0], November 5th was the close for
> library transitions.  Not only is this a late transition, but it seems
> to be uncoordinated with the release team.
>
> This may need to be reverted.
>
> [0]: https://lists.debian.org/debian-devel-announce/2016/11/msg2.html
>

Dear release team,

I kindly ask for advice in how to address this situation.

Problems:
 * I updated libxtables to an upstream snapshot release
 * I missed the update triggers a transition
 * Therefore, I missed the transition freeze deadline
 * Bugs happened.

In the meantime, my plan is to upload a fix for #844755.