date:20160126

> Tobias Frost  (2016-01-25):
>> Dear release-team,
>>
>> Now that all NMUs are in DELAYED for all fixables.
>> I think we are ready to throw the switch. 
>
> You haven't answered <20160106232316.ga28...@mraw.org>.
>
> Mraw,
> KiBi.
>

Nobuhiro, Anibal,

this is a question for you:

https://lists.debian.org/debian-devel/2016/01/msg00248.html

{quote}
Speaking of this particular udeb, I've just spotted libpng16-16-udeb has
a Conflicts against libpng12-0-udeb. I'm not sure why, and the changelog
doesn't seem to explain either. libpng16-16 and libpng12-0 seems to be
co-installable, so I'm not sure why their respective udebs shouldn't be.
{/quote}

Re: [Summary] Request for release team decision on MySQL and MariaDB

2016-01-26 Thread Stephan Seitz


On Tue, Jan 26, 2016 at 12:48:23AM +, Steven Chamberlain wrote:

Assuming MariaDB is affected by the same issues, I may not be in a
technically better situation if I switched to using that.  (Although, it


But as far as I understand it there is no guarantee that MySQL and 
MariaDB will stay compatible in the future.


So what are you doing if MySQL is removed and other programs (e.g. cacti) 
are not working with MariaDB anymore?


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


signature.asc
Description: PGP signature

Re: libpng is ready for transtion

2016-01-26 Thread Cyril Brulebois

Tobias Frost  (2016-01-25):
> Dear release-team,
> 
> Now that all NMUs are in DELAYED for all fixables.
> I think we are ready to throw the switch. 

You haven't answered <20160106232316.ga28...@mraw.org>.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#812731: RM: mate-system-tools -- RoM; abandoned upstream

2016-01-26 Thread Mike Gabriel


Hi Adam,

On  Di 26 Jan 2016 10:58:41 CET, Adam D. Barratt wrote:


On 2016-01-26 8:25, Mike Gabriel wrote:

Package: release.debian.org
X-Debbugs-Cc: pkg-mate-t...@lists.alioth.debian.org

Dear release team,

please remove mate-system-tools from Debian testing (aka stretch). It
is not continued upstream anymore. A removal request has also been
sent to the ftpmasters for the package version found in unstable.


In that case there's no need for an explicit removal from testing.  
Once the unstable removal is processed it will automatically become  
a candidate for removal from testing.


Regards,

Adam


ah, ok. Then probably it is required to update the section "Removals  
from testing, stable and oldstable" on this [1] wiki page.


There it currently says:

"""
Removals from the oldstable, stable and testing distributions should  
be requested by e-mailing the (Stable) Release Managers  
debian-release@lists.debian.org or filing a bug against the  
release.debian.org pseudo-package (using the same format described in  
this document; additionally, you should be nice by usertagging your  
bugs with usertag rm and user release.debian@packages.debian.org).

"""

Whereas this may be true during the freeze phase, it doesn't seem to  
apply to non-freeze phases of Debian testing, right?


Greets,
Mike

[1] https://wiki.debian.org/ftpmaster_Removals
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de


pgpdJFPSnyEan.pgp
Description: Digitale PGP-Signatur

NEW changes in stable-new

Processing changes file: giflib_4.1.6-11+deb8u1_amd64.changes
  ACCEPT
Processing changes file: giflib_4.1.6-11+deb8u1_arm64.changes
  ACCEPT
Processing changes file: giflib_4.1.6-11+deb8u1_armel.changes
  ACCEPT
Processing changes file: giflib_4.1.6-11+deb8u1_armhf.changes
  ACCEPT
Processing changes file: giflib_4.1.6-11+deb8u1_i386.changes
  ACCEPT
Processing changes file: giflib_4.1.6-11+deb8u1_mipsel.changes
  ACCEPT
Processing changes file: giflib_4.1.6-11+deb8u1_powerpc.changes
  ACCEPT
Processing changes file: giflib_4.1.6-11+deb8u1_ppc64el.changes
  ACCEPT
Processing changes file: giflib_4.1.6-11+deb8u1_s390x.changes
  ACCEPT

NEW changes in oldstable-new

Processing changes file: giflib_4.1.6-10+deb7u1_armel.changes
  ACCEPT
Processing changes file: giflib_4.1.6-10+deb7u1_armhf.changes
  ACCEPT
Processing changes file: giflib_4.1.6-10+deb7u1_i386.changes
  ACCEPT
Processing changes file: giflib_4.1.6-10+deb7u1_ia64.changes
  ACCEPT
Processing changes file: giflib_4.1.6-10+deb7u1_kfreebsd-amd64.changes
  ACCEPT
Processing changes file: giflib_4.1.6-10+deb7u1_kfreebsd-i386.changes
  ACCEPT
Processing changes file: giflib_4.1.6-10+deb7u1_mipsel.changes
  ACCEPT
Processing changes file: giflib_4.1.6-10+deb7u1_powerpc.changes
  ACCEPT
Processing changes file: giflib_4.1.6-10+deb7u1_s390.changes
  ACCEPT
Processing changes file: giflib_4.1.6-10+deb7u1_s390x.changes
  ACCEPT
Processing changes file: giflib_4.1.6-10+deb7u1_sparc.changes
  ACCEPT

Bug#812821: nmu: pam_1.1.8-3.1+deb8u1

Control: tags -1 + jessie

On Tue, 2016-01-26 at 15:28 -0800, Tianon Gravi wrote:
> Due to some kind of mistake in my amd64 build environment (details being
> tracked down in #812566) the amd64 build of pam_1.1.8-3.1+deb8u1 is the
> only one that got the intended man page update, but this causes
> co-installability issues (as detailed in #812566).  Getting a binNMU of
> amd64 in the meantime would be great so that at least the packages line
> up properly while we figure out what happened. :(
> 
> nmu pam_1.1.8-3.1+deb8u1 . amd64 . jessie . -m "Rebuild with correct build 
> environment"

libpam0g is "Multi-Arch: same" so this will need to be binNMUed on all
architectures (at least both of i386 and amd64) or we'll just end up
with a different set of installability issues.

Regards,

Adam

Processed: Re: Bug#812821: nmu: pam_1.1.8-3.1+deb8u1

Processing control commands:

> tags -1 + jessie
Bug #812821 [release.debian.org] nmu: pam_1.1.8-3.1+deb8u1
Added tag(s) jessie.

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

Bug#812821: nmu: pam_1.1.8-3.1+deb8u1

On Wed, 2016-01-27 at 05:48 +, Adam D. Barratt wrote:
> Control: tags -1 + jessie
> 
> On Tue, 2016-01-26 at 15:28 -0800, Tianon Gravi wrote:
> > Due to some kind of mistake in my amd64 build environment (details being
> > tracked down in #812566) the amd64 build of pam_1.1.8-3.1+deb8u1 is the
> > only one that got the intended man page update, but this causes
> > co-installability issues (as detailed in #812566).  Getting a binNMU of
> > amd64 in the meantime would be great so that at least the packages line
> > up properly while we figure out what happened. :(
> > 
> > nmu pam_1.1.8-3.1+deb8u1 . amd64 . jessie . -m "Rebuild with correct build 
> > environment"
> 
> libpam0g is "Multi-Arch: same" so this will need to be binNMUed on all
> architectures (at least both of i386 and amd64) or we'll just end up
> with a different set of installability issues.

Is it just the manpage that's the issue? i.e. do the packages published
as part of the point release include the actual security fix?

Regards,

Adam

Re: Bug#650601: libpng is ready for transition

Am Dienstag, den 26.01.2016, 22:25 + schrieb Gianfranco Costamagna:
> Hi Tobias
> 
> > +libpng1.6 (1.6.20-1.2)
> > unstable; urgency=medium
> 
> Do you want to go on unstable or it is a typo?
> 
> Gianfranco

Typo

Bug#807654: jessie-pu: package python-django/1.7.11-1

2016-01-26 Thread Raphael Hertzog

Hello dear release team,

On Fri, 11 Dec 2015, Raphael Hertzog wrote:
> I would like to update python-django in jessie to the latest upstream bug
> fix release in the 1.7.x branch, aka 1.7.11. It should also be the last
> upstream release in that branch since it's now unsupported upstream.

So I got no response in the 1.5 months between my submission and the
last point release. I hope that my request will be first in line for the
next round.

Thank you!
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

2016-01-26 Thread Pedretti Fabio

> * Summary of options and selection status
>
> My original request for a decision proposed one of the following
> options, which I think we all agree are the only options available:
>
> 1) We carry and ship both, which I believe is the preference of the
> Debian MySQL Maintainers team by default since we do not agree to any
> other option. We have representatives from both sides who are working
> together and putting in the work to make this work technically.
>
> 2a) We carry both in unstable, but only MySQL in testing.
>
> 2b) We carry both in unstable, but only MariaDB in testing.
>
> 3a) We drop MariaDB completely, keeping only MySQL in unstable and
> testing.
>
> 3b) We drop MySQL completely, keeping only MariaDB in unstable and
> testing.

Another possible alternative (no idea how feasible it is, however) is
1) + having mariadb as a default provider for mysql-server.

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

2016-01-26 Thread Lars Tangvald

- Original Message -
From: spam...@debian.org
To: ste...@pyro.eu.org
Cc: robie.ba...@ubuntu.com, t...@security.debian.org, 
debian-release@lists.debian.org, pkg-mysql-ma...@lists.alioth.debian.org
Sent: Tuesday, January 26, 2016 8:15:26 AM GMT +01:00 Amsterdam / Berlin / Bern 
/ Rome / Stockholm / Vienna
Subject: Re: [debian-mysql] [Summary] Request for release team decision on 
MySQL and MariaDB
...
>> I was wondering why after the 2016-01-19 announcement, there is still no
>> patched mysql-5.5 in jessie or wheezy;  and also why mariadb was only
>> just patched today.  Debian is typically much faster than this at
>> getting out patches.  Is it to do with complexity, available manpower,
>> or other things?

...
>Regarding the speed of patching: MySQL is massive. It takes several
>hours to build and fully test on a good quality machine. Because the
>patched version came out before the CVE's and CPU's attached to it, some
>of this was already done. But a final set of binaries must be prepared,
>tested, and uploaded. I think it is understandable that this might take
>more than 5 days. But it should be completed soon.

Hi,

I only have a comment on this specific question, as I only work on the 
technical side:
One of the criticisms by the security team has been that Oracle hasn't done 
anything to prepare the security updates. We've agreed that it makes sense for 
us to do this, and for the 2016-01-19 we've been working on preparing the 
patch, but it's been slow going because of unfamiliarity with the security 
patching process. We can definitely do this significantly faster, it's just the 
handover process for this update that's taking time.

--
Lars

Bug#812731: RM: mate-system-tools -- RoM; abandoned upstream

2016-01-26 Thread Mike Gabriel


Package: release.debian.org
X-Debbugs-Cc: pkg-mate-t...@lists.alioth.debian.org

Dear release team,

please remove mate-system-tools from Debian testing (aka stretch). It  
is not continued upstream anymore. A removal request has also been  
sent to the ftpmasters for the package version found in unstable.


Thanks,
Mike (on behalf of the Debian MATE Packaging Team)

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de


pgp7LrLS3WEgZ.pgp
Description: Digitale PGP-Signatur

Processed: Re: Bug#808735: transition: xorg-server

Processing control commands:

> tags -1 confirmed
Bug #808735 [release.debian.org] transition: xorg-server
Added tag(s) confirmed.

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

Bug#808735: transition: xorg-server

Control: tags -1 confirmed

On 22/12/15 12:39, Emilio Pozuelo Monfort wrote:
> We have a new xserver in experimental.

Let's do this.

Emilio

Bug#812601: marked as done (nmu: cdo_1.7.0+dfsg.1-2~bpo8+1)

Your message dated Tue, 26 Jan 2016 17:06:47 +0100
with message-id <56a79997.8000...@debian.org>
and subject line Re: Bug#812601: nmu: cdo_1.7.0+dfsg.1-2~bpo8+1
has caused the Debian Bug report #812601,
regarding nmu: cdo_1.7.0+dfsg.1-2~bpo8+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.)

-- 
812601: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812601
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,
Due to a broken pbuild environment, the following backports were built
against sid rather than jessie, and need to be rebuilt:

nmu cdo_1.7.0+dfsg.1-2~bpo8+1 . ALL . -m "Rebuild against jessie-backports"
nmu libaec_0.3.2-1~bpo8+1 . ALL -m "Rebuild against jessie-backports"
nmu ncl_6.3.0-4~bpo8+1 . ALL-m "Rebuild against jessie-backports"
thanks

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On 25/01/16 14:58, Alastair McKinstry wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hi,
> Due to a broken pbuild environment, the following backports were built
> against sid rather than jessie, and need to be rebuilt:
> 
> nmu cdo_1.7.0+dfsg.1-2~bpo8+1 . ALL . -m "Rebuild against jessie-backports"
> nmu libaec_0.3.2-1~bpo8+1 . ALL -m "Rebuild against jessie-backports"
> nmu ncl_6.3.0-4~bpo8+1 . ALL  -m "Rebuild against jessie-backports"

Sounds like something you'd want to ask to the backports team. Closing the bug
and Cc'ing them so they can take appropriate measures.

Emilio--- End Message ---

Bug#812389: marked as done (nmu: gst-plugins-good1.0_1.7.1-1)

Your message dated Tue, 26 Jan 2016 17:07:43 +0100
with message-id <56a799cf.60...@debian.org>
and subject line Re: Bug#812389: nmu: gst-plugins-good1.0_1.7.1-1
has caused the Debian Bug report #812389,
regarding nmu: gst-plugins-good1.0_1.7.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.)

-- 
812389: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812389
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 gst-plugins-good1.0_1.7.1-1 . ANY . experimental . -m "Rebuild against 
libvpx3."

There was recently a libvpx2 -> libvpx3 transition in sid.

Andreas
--- End Message ---
--- Begin Message ---
On 23/01/16 06:35, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu gst-plugins-good1.0_1.7.1-1 . ANY . experimental . -m "Rebuild against 
> libvpx3."
> 
> There was recently a libvpx2 -> libvpx3 transition in sid.

Scheduled.

Thanks,
Emilio--- End Message ---

Bug#812536: marked as done (nmu: suitesparse transition)

Your message dated Tue, 26 Jan 2016 17:10:12 +0100
with message-id <56a79a64.5070...@debian.org>
and subject line Re: Bug#812536: nmu: suitesparse transition
has caused the Debian Bug report #812536,
regarding nmu: suitesparse transition
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.)

-- 
812536: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812536
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
X-Debbugs-Cc: pkg-julia-de...@lists.alioth.debian.org

Dear Release Team,

Please schedule binNMUs for the ongoing suitesparse transition
(https://release.debian.org/transitions/html/auto-suitesparse.html).

Since this is a small transition, involving only a couple of leaf packages, I
did not request a transition slot (hopefully this is ok)

nmu ceres-solver_1.11.0~dfsg0-2 dolfin_1.6.0-1 julia_0.4.3-1 . ANY . unstable . 
-m "Rebuild against suitesparse 1:4.4.6-1."

Cheers,

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594

signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On 24/01/16 20:41, Sébastien Villemot wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> X-Debbugs-Cc: pkg-julia-de...@lists.alioth.debian.org
> 
> Dear Release Team,
> 
> Please schedule binNMUs for the ongoing suitesparse transition
> (https://release.debian.org/transitions/html/auto-suitesparse.html).
> 
> Since this is a small transition, involving only a couple of leaf packages, I
> did not request a transition slot (hopefully this is ok)
> 
> nmu ceres-solver_1.11.0~dfsg0-2 dolfin_1.6.0-1 julia_0.4.3-1 . ANY . unstable 
> . -m "Rebuild against suitesparse 1:4.4.6-1."

Scheduled.

Cheers,
Emilio--- End Message ---

Bug#812605: RM: ruby-distribution/0.7.3+dfsg-1

2016-01-26 Thread Christian Hofstaedtler

* Emilio Pozuelo Monfort  [160126 17:04]:
> On 25/01/16 15:56, Christian Hofstaedtler wrote:
> > ruby-distribution Build-Depends on ruby-gsl, which is not in testing.
> > (Also nobody seems to be working on fixing ruby-gsl for it to reenter
> > testing.)
> 
> Without an RC bug on the package, the package is going to re-enter testing on
> the next britney run...

I had hoped that britney would consider Build-Depends, at least when
migrating packages to testing.

I've now cloned the RM bug to the package.

> Likewise for #812606.

Ditto.

Thanks,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#812605: RM: ruby-distribution/0.7.3+dfsg-1

On 25/01/16 15:56, Christian Hofstaedtler wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> Hi,
> 
> ruby-distribution Build-Depends on ruby-gsl, which is not in testing.
> (Also nobody seems to be working on fixing ruby-gsl for it to reenter
> testing.)

Without an RC bug on the package, the package is going to re-enter testing on
the next britney run...

Likewise for #812606.

Cheers,
Emilio

Bug#812338: marked as done (nmu: staden_2.0.0+b10-1.1)

Your message dated Tue, 26 Jan 2016 17:12:36 +0100
with message-id <56a79af4.2040...@debian.org>
and subject line Re: Bug#812338: nmu: staden_2.0.0+b10-1.1
has caused the Debian Bug report #812338,
regarding nmu: staden_2.0.0+b10-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.)

-- 
812338: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812338
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 staden_2.0.0+b10-1.1 . ANY . unstable . -m "Rebuild against 
libstaden-read11"

src:staden-io-lib started a mini-transition (affecting 2 rdepends) from
libstaden-read1 to libstaden-read11 quite some time ago.
Now let's finally rebuild the forgotten rdepends: staden (which is only
in sid). (The other one, libbio-scf-perl, already got rebuilt for the
perl transition.)

Andreas
--- End Message ---
--- Begin Message ---
On 22/01/16 15:22, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu staden_2.0.0+b10-1.1 . ANY . unstable . -m "Rebuild against 
> libstaden-read11"
> 
> src:staden-io-lib started a mini-transition (affecting 2 rdepends) from
> libstaden-read1 to libstaden-read11 quite some time ago.
> Now let's finally rebuild the forgotten rdepends: staden (which is only
> in sid). (The other one, libbio-scf-perl, already got rebuilt for the
> perl transition.)

Scheduled.

Emilio--- End Message ---

Processed: cloning 812606, reassign -1 to ruby-integration, severity of -1 is serious ...

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

> clone 812606 -1
Bug #812606 [release.debian.org] RM: ruby-integration/0.1.0-1
Bug 812606 cloned as bug 812794
> reassign -1 ruby-integration
Bug #812794 [release.debian.org] RM: ruby-integration/0.1.0-1
Bug reassigned from package 'release.debian.org' to 'ruby-integration'.
Ignoring request to alter found versions of bug #812794 to the same values 
previously set
Ignoring request to alter fixed versions of bug #812794 to the same values 
previously set
> severity -1 serious
Bug #812794 [ruby-integration] RM: ruby-integration/0.1.0-1
Severity set to 'serious' from 'normal'
> retitle -1 Build-Depends not installable in testing
Bug #812794 [ruby-integration] RM: ruby-integration/0.1.0-1
Changed Bug title to 'Build-Depends not installable in testing' from 'RM: 
ruby-integration/0.1.0-1'
> thanks
Stopping processing here.

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

Re: Bug#650601: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1

Hi,

On 22/01/16 14:59, Tobias Frost wrote:
> Hi Emilio and release team
> (sorry for the previous mail and thanks for the untag, I fixed the uploa
> d)
> 
> as you have noticed yesterday and today I NMUed the remaining "please
> switch from libpng-{3,12,12-0}-dev to libpng-dev" bugs.
> (around ~30 NMUs that will hit unstable hopefully in 7 days)
> 
> there are a couple of packages with a build-dependency on
> libpng-dev | libpng12-dev but I didn't NMU them because I don't think
> they are going to give troubles in the transition context.
> 
> Now, we should be left with ~50 packages currently FTBFS, but I think
> for most of them we could easily have patches from Fedora or upstream
> new versions (many of them already have patches on BTS)
> 
> This is a list of packages, according to the bug blocking this one.
> pngnq: patch, but should wait for the transition to start
> libtheora: patch
> openmsx: patch (should wait the transition to start)
> calligra: no patch, out of testing, arch linux has the latest version
> and seems to build against libpng16
> libcoyotl: has an RC bug (license issue), no patch
> xcftools: testsuite failure fedora has the latest, maybe they have a pat
> ch
> neverball: patch, but should wait for the transition to start
> openjfx: no patch, but new upstream release
> tucnak: no patch, but new upstream release
> xemacs21: FTBFS against gcc-5
> openlayer: mailed the bug report with a patch (not sure if enough)
> armagetronad: patch? I think it is a matter of changing the configure
> script
> aseprite: should be a matter of a define (new upstream release)
> libpgplot-perl: patch, fixed in git
> mathgl: patch from fedora?
> https://lists.fedoraproject.org/pipermail/scm-commits/2011-December/6932
> 05.html
> abiword: patch, fixed, but failing for another reason now
> nagios3: not in testing, RC buggy
> celestia: RM ROM Dead upstream
> warzone2100: new upstream release: according to google fedora builds
> it fine with new libpng
> netpbm-free: ZLIB_VERSION undeclared, should be trivial to fix
> (missing include), if it isn't still not fixed (mailed the bug report)
> exult: no patch, but new upstream release (snapshot)
> fw4spl: double RC buggy
> rbdoom3bfg: no patch
> exrtools: patch
> libapache2-mod-qos: missing b-d patch
> ifeffit: seems to be failing because of missing b-d, and needs
> probably rebuilds of other build-dependencies, RC buggy
> matplotlib: should be fine now
> pcsx2: probably needs some rebuilds to make build-dependencies installab
> le
> root-system: FTBFS for unrelated reasons? RC buggy
> ctsim: needs some rebuilds to be fixed (e.g. libgdk-pixbuf2.0-dev)
>should be easy to patch
> wine-development: I think no issue, unrelated build failure
> scorched3d: FTBFS, but should be trivial to fix (pointer change)
> libtk-img: FTBFS but fedora has patches
> https://pkgs.fedoraproject.org/cgit/rpms/tkimg.git/tree/
> 
> 
> so, basically the ~50 FTBFS are now down to 31 (some of them have been
> NMUed while writing this email), and the "no patch" bugs are currently
> only 6, and I suspect some of them even will rebuild fine (probably
> transition related issues).
> 
> So, if we exclude the RC buggy packages we are down to really a couple
> of packages, but I think we should start the transition and fix them
> later, specially because the build failures logs are from libpng15 in
> some cases, and it isn't worth the effort to double check them.
> 
> Can we have a transition slot if possible, or should we fix something
> more?
> 
> Please note: all the NMUs will need 6/7 days to go in unstable.
> 
> (there is also a bug against texlive-base to stop using the embedded
> libpng version, but obviously it can't be fixed until the transition
> starts)
>>
> 
> Many thanks Gianfranco for the summary!
> 
> Regarding the packages requiring libpng-config, I proposed to the maintainers
> do another libng16 upload, so that that tool will be pulled in as depdenceny
> (Otherwise we'll have the soversion hardcoded again in some B-D; I'd like to
> avoid that.)
> 
> Please, Anibal & Nobuhiro shout STOP if you do not like this otherwise I'll
> NMU my proposal tomorrow evening to experimental..
> 
> The packages affected by this are (list might be incomplete):
> armagetronad
> pngnq
> openmsx (probably)
> neverball
> 
> 
> I'm continuing to rebuild packages on my server and will also NMU a few
> packages on the weekend to get the number of real libpng16 caused FTBFSs
> minimized. (atm most of the FAIL marked packages are caused by tricky B-D
> chains or broken B-Ds. My list has currently 16 packages needing an patch &
> NMU)
> 
> I think we are quite close to throw the switch...
> Release-Team: Ready?

Thank you all for your work on this.

Can send another summary with your proposed plan here? Currently libpng12-dev
provides libpng-dev but libpng16-dev doesn't. Are you going to switch that? Or
do you plan to build a libpng-dev package from src:libpng1.6?

Another thing I want to confirm before

Bug#650601: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1

2016-01-26 Thread Gianfranco Costamagna

Hi Emilio!


>Can send another summary with your proposed plan here? Currently libpng12-dev
>provides libpng-dev but libpng16-dev doesn't. Are you going to switch that? Or
>do you plan to build a libpng-dev package from src:libpng1.6?


sure, the only reason that libpng-dev wasn't provided has been to avoid people 
building accidentally
with libpng16 when uploading on experimental.

IIRC the plan is to upload on unstable with the Provides: libpng-dev line 
enabled
(it is already there, just commented),
and the change for the udeb file conflict (ongoing test right now).

I think libpng12-dev will stop providing the libpng-dev at the same time, but 
I'm not sure

>Another thing I want to confirm before starting this transition is what Cyril
>asked earlier today in another mail. What happens if libpng12.so and 
>libpng16.so
>are both loaded into a process? Does that work properly, because of versioned
>symbols et al? E.g.
>
>gimp depends on libpng12-0.
>
>gimp also depends on libgtk2.0-0, which depends on libgdk-pixbuf2.0-0, which in
>turn depends on libpng12-0.
>
>If one of gimp or libgdk-pixbufs2.0-0 get rebuilt, but the other doesn't, when
>gimp runs then both libpng12.so and libpng16.so will get loaded. Is that 
>supported?


the problem here I think should be solved by *removing* the old libpng 
providing libpng-dev
and rebuilding everything against the new libpng16.

I don't think anybody will keep the old 12 around, specially when ~10 packages 
needs porting.

My plan (that is *my* plan), is to switch everything to the new one, and do the 
rebuilds
accordingly (dep-wait or similar, not sure how to manage the gdk dependency 
problem)

>Assuming that works fine, this is looking good and should be ready to start 
>soon.



in 2-3 days most of the NMUs will reach unstable, and in 10 dayes the remaining 
NMUs will go too.
(assuming we don't speed them up :) )

BTW you might want to start in a future reply from this message
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601#691
that has a more complete point of view of the transition

seems that only RC buggy packages are left to, but there is no way to fix them 
if we can't even build with the old
libpng (even to test if they would build fine or not).

cheers,

Gianfranco

Re: Bug#650601: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1

2016-01-26 Thread Cyril Brulebois

Gianfranco Costamagna  (2016-01-26):
> >Another thing I want to confirm before starting this transition is what Cyril
> >asked earlier today in another mail. What happens if libpng12.so and 
> >libpng16.so
> >are both loaded into a process? Does that work properly, because of versioned
> >symbols et al? E.g.
> >
> >gimp depends on libpng12-0.
> >
> >gimp also depends on libgtk2.0-0, which depends on libgdk-pixbuf2.0-0, which 
> >in
> >turn depends on libpng12-0.
> >
> >If one of gimp or libgdk-pixbufs2.0-0 get rebuilt, but the other doesn't, 
> >when
> >gimp runs then both libpng12.so and libpng16.so will get loaded. Is that 
> >supported?
> 
> 
> the problem here I think should be solved by *removing* the old libpng
> providing libpng-dev and rebuilding everything against the new
> libpng16.
> 
> I don't think anybody will keep the old 12 around, specially when ~10
> packages needs porting.
> 
> My plan (that is *my* plan), is to switch everything to the new one,
> and do the rebuilds accordingly (dep-wait or similar, not sure how to
> manage the gdk dependency problem)

This is not a plan… You don't get to ignore partial upgrades. Scheduling
binNMUs to build all packages against a newer libpng doesn't mean that
testing, or end users, are going to receive all rebuilt packages in
lockstep.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Processed: cloning 812606, reassign -1 to ruby-integration, severity of -1 is serious ...

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

> clone 812606 -1
Bug #812606 [release.debian.org] RM: ruby-integration/0.1.0-1
Bug 812606 cloned as bug 812801
> reassign -1 ruby-integration
Bug #812801 [release.debian.org] RM: ruby-integration/0.1.0-1
Bug reassigned from package 'release.debian.org' to 'ruby-integration'.
Ignoring request to alter found versions of bug #812801 to the same values 
previously set
Ignoring request to alter fixed versions of bug #812801 to the same values 
previously set
> severity -1 serious
Bug #812801 [ruby-integration] RM: ruby-integration/0.1.0-1
Severity set to 'serious' from 'normal'
> retitle -1 Build-Depends not installable in testing
Bug #812801 [ruby-integration] RM: ruby-integration/0.1.0-1
Changed Bug title to 'Build-Depends not installable in testing' from 'RM: 
ruby-integration/0.1.0-1'
> thanks
Stopping processing here.

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

Bug#650601: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1

On 26/01/16 17:54, Gianfranco Costamagna wrote:
> Hi Emilio!
> 
> 
>> Can send another summary with your proposed plan here? Currently libpng12-dev
>> provides libpng-dev but libpng16-dev doesn't. Are you going to switch that? 
>> Or
>> do you plan to build a libpng-dev package from src:libpng1.6?
> 
> 
> sure, the only reason that libpng-dev wasn't provided has been to avoid 
> people building accidentally
> with libpng16 when uploading on experimental.
> 
> IIRC the plan is to upload on unstable with the Provides: libpng-dev line 
> enabled
> (it is already there, just commented),
> and the change for the udeb file conflict (ongoing test right now).
> 
> I think libpng12-dev will stop providing the libpng-dev at the same time, but 
> I'm not sure

Either that needs to happen, or a real libpng-dev package needs to be built.
Otherwise if we have libpng12-dev and libpng16-dev providing libpng-dev, things
won't be deterministic.

> 
>> Another thing I want to confirm before starting this transition is what Cyril
>> asked earlier today in another mail. What happens if libpng12.so and 
>> libpng16.so
>> are both loaded into a process? Does that work properly, because of versioned
>> symbols et al? E.g.
>>
>> gimp depends on libpng12-0.
>>
>> gimp also depends on libgtk2.0-0, which depends on libgdk-pixbuf2.0-0, which 
>> in
>> turn depends on libpng12-0.
>>
>> If one of gimp or libgdk-pixbufs2.0-0 get rebuilt, but the other doesn't, 
>> when
>> gimp runs then both libpng12.so and libpng16.so will get loaded. Is that 
>> supported?
> 
> 
> the problem here I think should be solved by *removing* the old libpng 
> providing libpng-dev
> and rebuilding everything against the new libpng16.

No, that doesn't solve the problem. Rebuilding everything takes time, packages
will fail to build, and we will have processes that load both shared libraries.
That needs to work. And it needs to be tested and verified.

If that didn't work, then libpng16-16 would probably have to conflict against
libpng12-0, making this transition way harder. So please check what I asked and
let's go the other route.

Cheers,
Emilio

Bug#650601: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1

2016-01-26 Thread Gianfranco Costamagna

Hi Emilio and Cyril,

thanks to you both for the help!

>No, that doesn't solve the problem. Rebuilding everything takes time, packages

>will fail to build, and we will have processes that load both shared libraries.
>That needs to work. And it needs to be tested and verified.
>
>If that didn't work, then libpng16-16 would probably have to conflict against
>libpng12-0, making this transition way harder. So please check what I asked and
>let's go the other route.


This is what I did:

sid/experimental virtual machine (up to date)

apt-get install -t unstable gimp
ldd /usr/bin/gimp |grep png
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7f493e0d8000)


ldd /usr/bin/gimp |grep gdk
libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 
(0x7f811a13e000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 
(0x7f8118c2f000)


ldd /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 |grep png
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7f7d1e5f3000)


(open gimp, play with some tools, save an image as xcf and export as png)


and then the experiment:

apt-get install -t experimental gdk-pixbuf (doesn't work, the amd64 package in 
experimental, seems to be missing)
no change rebuild of that package here
http://debomatic-amd64.debian.net/distribution#experimental/gdk-pixbuf/2.32.3-1.1/buildlog
dpkg -i libgdk-pixbuf2.0-0_2.32.3-1.1_amd64.deb 
gir1.2-gdkpixbuf-2.0_2.32.3-1.1_amd64.deb 
libgdk-pixbuf2.0-common_2.32.3-1.1_all.deb 
libgdk-pixbuf2.0-dev_2.32.3-1.1_amd64.deb

(ok, I don't need the -dev package, but I wrongly copy-pasted)

apt-get -f install

The following additional packages will be installed:
libpng16-16 libpng16-dev libpng16-tools


ldd /usr/bin/gimp |grep png
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x7feb6c05c000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7feb6b588000)

ldd /usr/bin/gimp |grep gdk
libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 
(0x7f5c6709c000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 
(0x7f5c65b8d000)


ldd /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 |grep png
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x7fc681ee5000)

I did the same testing, create a new xcf file, save it as png and so on, and 
everything was good.

I opened the newly created png files and they were looking the same as the ones 
I created, and no sign of
crash.

please let me know if you have better testing than mine, or some better 
packages to look at.

cheers,

Gianfranco

Bug#650601: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1

On 26/01/16 19:26, Gianfranco Costamagna wrote:
> Hi Emilio and Cyril,
> 
> thanks to you both for the help!
> 
>> No, that doesn't solve the problem. Rebuilding everything takes time, 
>> packages
> 
>> will fail to build, and we will have processes that load both shared 
>> libraries.
>> That needs to work. And it needs to be tested and verified.
>>
>> If that didn't work, then libpng16-16 would probably have to conflict against
>> libpng12-0, making this transition way harder. So please check what I asked 
>> and
>> let's go the other route.
> 
> 
> This is what I did:
> 
> sid/experimental virtual machine (up to date)
> 
> apt-get install -t unstable gimp
> ldd /usr/bin/gimp |grep png
> libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7f493e0d8000)
> 
> 
> ldd /usr/bin/gimp |grep gdk
> libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 
> (0x7f811a13e000)
> libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 
> (0x7f8118c2f000)
> 
> 
> ldd /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 |grep png
> libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7f7d1e5f3000)
> 
> 
> (open gimp, play with some tools, save an image as xcf and export as png)
> 
> 
> and then the experiment:
> 
> apt-get install -t experimental gdk-pixbuf (doesn't work, the amd64 package 
> in experimental, seems to be missing)
> no change rebuild of that package here
> http://debomatic-amd64.debian.net/distribution#experimental/gdk-pixbuf/2.32.3-1.1/buildlog
> dpkg -i libgdk-pixbuf2.0-0_2.32.3-1.1_amd64.deb 
> gir1.2-gdkpixbuf-2.0_2.32.3-1.1_amd64.deb 
> libgdk-pixbuf2.0-common_2.32.3-1.1_all.deb 
> libgdk-pixbuf2.0-dev_2.32.3-1.1_amd64.deb
> 
> (ok, I don't need the -dev package, but I wrongly copy-pasted)
> 
> apt-get -f install
> 
> The following additional packages will be installed:
> libpng16-16 libpng16-dev libpng16-tools
> 
> 
> ldd /usr/bin/gimp |grep png
> libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x7feb6c05c000)
> libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7feb6b588000)
> 
> ldd /usr/bin/gimp |grep gdk
> libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 
> (0x7f5c6709c000)
> libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 
> (0x7f5c65b8d000)
> 
> 
> ldd /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 |grep png
> libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x7fc681ee5000)
> 
> I did the same testing, create a new xcf file, save it as png and so on, and 
> everything was good.
> 
> I opened the newly created png files and they were looking the same as the 
> ones I created, and no sign of
> crash.
> 
> please let me know if you have better testing than mine, or some better 
> packages to look at.

That's good. Thanks for checking.

Emilio

Bug#650601: libpng1.6 transistin (Was: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1)

Am Dienstag, den 26.01.2016, 18:07 +0100 schrieb Emilio Pozuelo
Monfort:
> On 26/01/16 17:54, Gianfranco Costamagna wrote:
> > Hi Emilio!
> > 
> > 
> > > Can send another summary with your proposed plan here? Currently
> > > libpng12-dev
> > > provides libpng-dev but libpng16-dev doesn't. Are you going to
> > > switch that? Or
> > > do you plan to build a libpng-dev package from src:libpng1.6?
> > 
> > 
> > sure, the only reason that libpng-dev wasn't provided has been to
> > avoid people building accidentally
> > with libpng16 when uploading on experimental.
> > 
> > IIRC the plan is to upload on unstable with the Provides: libpng-
> > dev line enabled
> > (it is already there, just commented),
> > and the change for the udeb file conflict (ongoing test right now).
> > 
> > I think libpng12-dev will stop providing the libpng-dev at the same
> > time, but I'm not sure
> 
> Either that needs to happen, or a real libpng-dev package needs to be
> built.
> Otherwise if we have libpng12-dev and libpng16-dev providing libpng-
> dev, things
> won't be deterministic.

> > 

(My*) plan'd be to upload (1) libpng12 WITHOUT providing libpng-dev and
(2) libpng16 WITH providing it. 

I'm not sure whats better: if that should happen at the very same time,
or if we should delay (2) until e.g the -12 package arrived at all
archs, to ensure that there will be no point of time where libpng-dev
is provided by two packages or solve any races by delaying the start of
the binnmus until we can ensure that all archs are getting the right
one.

A real libpng-dev package would be actually my* favorite, but this
requires going through NEW and I fear that that would destroy the
momentum we experience now to push this forward. Also, a real libpng-
dev Package could still be introduced later.

-- 
tobi

* Nobuhiro / Anibal should give the definitive direction how the want
to manage their package...

Bug#812573: nmu: libaec_0.3.2-1

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.

Regards,

Adam

Processed: Re: Bug#812573: nmu: libaec_0.3.2-1

Processing control commands:

> tags -1 + moreinfo
Bug #812573 [release.debian.org] nmu: libaec_0.3.2-1
Added tag(s) moreinfo.

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

Bug#765639: Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version

2016-01-26 Thread Kurt Roeckx

On Tue, Jan 26, 2016 at 06:38:31AM +, Adam D. Barratt wrote:
> On Thu, 2015-12-17 at 23:38 +, Adam D. Barratt wrote:
> > However 1.0.1q hasn't been in stable at all, which is presumably what
> > you'd be proposing introducing to oldstable at this juncture. (and which
> > we'd therefore need to introduce to stable first, if we were to agree to
> > follow that path.)
> 
> Picking this up again (I hadn't realised the above was so many weeks
> ago :-|), updating OpenSSL in Wheezy to anything newer than 1.0.1k
> really needs a newer upstream version to be in Jessie first. We also
> likely only have two opportunities to get a package in to "Wheezy
> proper" before it moves to LTS status - likely a point release in March
> and then a "mop up" after the EOL of the base suite.
> 
> > Admittedly, the description of the changes between 1.0.1k and 1.0.1q,
> > according to NEWS/CHANGES don't immediately look crazy.
> 
> Comparing those against the package changelog and Security Tracker and
> ignoring changes which are apparently only relevant if SSLv2 is enabled
> leaves us with:
> 
>   *) dhparam: generate 2048-bit parameters by default.
>  [Kurt Roeckx and Emilia Kasper]
> 
>   *) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs.
>  This changes the decoding behaviour for some invalid messages,
>  though the change is mostly in the more lenient direction, and
>  legacy behaviour is preserved as much as possible.
>  [Emilia Käsper]
> 
>   *) In DSA_generate_parameters_ex, if the provided seed is too short,
>  return an error
>  [Rich Salz and Ismo Puustinen ]
> 
>   *) Build fixes for the Windows and OpenVMS platforms
>  [Matt Caswell and Richard Levitte]
> 
> The last of those is obviously irrelevant. Have there been any reports
> of issues related to the other fixes listed?

I can't remember any report about one of the above changes, nor
can I find any.

The base64 change is that it did weird things when receiving
invalid base64, which you shouldn't get in practice, and now at
least acts sane.

The DSA entry in CHANGES is actually wrong, that's how it was
changed in the master branch.  It was merged to the stable
branches and then reverted without reverting the CHANGES, and then
fixed to instead do what was previously documented and uses a
random seed if the seed is too short.  I'll see about getting that
CHANGES entry fixed.  We reverted that because we think it wasn't
an acceptable change in behaviour in the stable branches.

The dhparam thing is really about a default that if you generate
DH parameters that it defaults to 2048 instead of 1024.  This
shouldn't break anything itself, nor do I know of any other
software that would get broken by this.  You can always override
this default when generating them.

The most reports about breakage we get actually have to do with
the security fixes themself, like enforcing the minimum size of 768
bit when using DH and then finding out that there is software that
uses 512 bit DH.  (The upcomming release will actually change that
to 1024, as announced.)

Kurt

Processed: Re: Bug#812362: jessie-pu: package giflib/4.1.6-11+deb8u1

Processing control commands:

> tags -1 + pending
Bug #812362 [release.debian.org] jessie-pu: package giflib/4.1.6-11+deb8u1
Added tag(s) pending.

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

Bug#812363: wheezy-pu: package giflib/4.1.6-10+deb7u1

Control: tags -1 + pending

On Mon, 2016-01-25 at 08:16 +0100, Guido Günther wrote:
> On Sun, Jan 24, 2016 at 07:27:47PM +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Fri, 2016-01-22 at 19:50 +0100, Guido Günther wrote:
> > > I'd like to fix CVE-2015-7555 via wheezy-pu since the bug is fixed in
> > > Squeeze LTS and we try to not introduce new security issues when people
> > > upgrade (the Debian security team marked this CVE as no-dsa).
> > 
> > Please go ahead, with "wheezy" in the changelog rather than
> > "oldstable-security".
> 
> Uploaded now. Thanks!

Flagged for acceptance.

Regards,

Adam

Processed: Re: Bug#812363: wheezy-pu: package giflib/4.1.6-10+deb7u1

Processing control commands:

> tags -1 + pending
Bug #812363 [release.debian.org] wheezy-pu: package giflib/4.1.6-10+deb7u1
Added tag(s) pending.

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

Bug#812362: jessie-pu: package giflib/4.1.6-11+deb8u1

Control: tags -1 + pending

On Mon, 2016-01-25 at 07:33 +0100, Guido Günther wrote:
> On Sun, Jan 24, 2016 at 07:28:39PM +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Fri, 2016-01-22 at 19:49 +0100, Guido Günther wrote:
> > > I'd like to fix CVE-2015-7555 via jessie-pu since the bug is fixed in
> > > Squeeze LTS and we try to not introduce new security issues when people
> > > upgrade (the Debian security team marked this CVE as no-dsa).
> > 
> > Please go ahead.
> 
> Uploaded. Thanks a lot!

Flagged for acceptance, thanks.

Regards,

Adam

Bug#650601: libpng is ready for transtion

Hallo KiBi,

On Tue, 26 Jan 2016 10:51:11 +0100 Cyril Brulebois 
wrote:

> Has anyone tested a debian installer build where some packages were
> built against libpng12-0-udeb and some other against libpng16-16-
udeb?
> Does that work? Or are we looking at a giant transition where
everything
> must switch to libpng16 at once?
> 
> Mraw,
> KiBi.

As requested, I performed those build of the d-i, version 20160106: 

Testmatrix

A libcairo2-udeb_1.14.6-1.1~libpng16_amd64.udeb
B libdirectfb-1.2-9-udeb_1.2.10.0-5.2~libpng16_amd64.udeb 
C libfreetype6-udeb_2.6.1-0.2~libpng16_amd64.udeb
D libgdk-pixbuf2.0-0-udeb_2.32.3-1.1~libpng16_amd64.udeb
E libpng16-16-udeb_1.6.20-1.2~libpng16+patched+1_amd64.udeb
F matchbox-keyboard-udeb_0.1+svn20080916-10.1~libpng16_amd64.udeb

Two more udeb packages where generated during the mass rebuild on my
server, bu removed from test-matrix, as they do not Depend: on libpng:
libslang2, libdirectfb-bin

Key x -> libpng16-version used
. -> standard version used

   A B C D E F   result   (comment)
1  . . . . . .   builds   "control group"
2  x . x . x .   builds 
3  . x x . x .   builds
4  . . . x x .   builds
5  . x . x x x   builds   
6  x x x x x x   builds   "target version" 


Procedure:
- debuld in debian-installer directory.
- examination of created debian-installer-images tarball, especially
the MANIFEST.udebs file for installed udebs (if matches expectations,
if both libpngs are present


Let me know if you want to see other combinations tested too (and
which)

Thanks
-- 
tobi

Re: Bug#650601: libpng is ready for transtion

Am Dienstag, den 26.01.2016, 20:45 +1100 schrieb Aníbal Monsalve
Salazar:
> On Tue, 2016-01-26 10:23:13 +0100, Tobias Frost wrote:
> > > Tobias Frost  (2016-01-25):
> > > > Dear release-team,
> > > > 
> > > > Now that all NMUs are in DELAYED for all fixables.
> > > > I think we are ready to throw the switch.
> > > 
> > > You haven't answered <20160106232316.ga28...@mraw.org>.
> > > 
> > > Mraw,
> > > KiBi.
> > > 
> > 
> > Nobuhiro, Anibal,
> > 
> > this is a question for you:
> > 
> > https://lists.debian.org/debian-devel/2016/01/msg00248.html
> > 
> > {quote}
> > Speaking of this particular udeb, I've just spotted libpng16-16-
> > udeb has
> > a Conflicts against libpng12-0-udeb. I'm not sure why, and the
> > changelog
> > doesn't seem to explain either. libpng16-16 and libpng12-0 seems to
> > be
> > co-installable, so I'm not sure why their respective udebs
> > shouldn't be.
> > {/quote}
> 
> The Conflicts against libpng12-0-udeb can be removed.

Hi Anibal,

OK to NMU that or do you want to do the upload yourself?

diff -Nru libpng1.6-1.6.20/debian/changelog libpng1.6-
1.6.20/debian/changelog
--- libpng1.6-1.6.20/debian/changelog   2016-01-24 11:26:12.0
+0100
+++ libpng1.6-1.6.20/debian/changelog   2016-01-26 22:28:29.0
+0100
@@ -1,3 +1,10 @@
+libpng1.6 (1.6.20-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * libpng16-16-udeb should not Conflicts: libpng-12-0
+
+ -- Tobias Frost   Tue, 26 Jan 2016 22:27:21 +0100
+
 libpng1.6 (1.6.20-1.1) experimental; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libpng1.6-1.6.20/debian/control libpng1.6-
1.6.20/debian/control
--- libpng1.6-1.6.20/debian/control 2016-01-24 11:29:17.0
+0100
+++ libpng1.6-1.6.20/debian/control 2016-01-26 22:28:22.0
+0100
@@ -71,7 +71,6 @@
 Priority: extra
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Conflicts: libpng12-0-udeb
 Description: PNG library - minimal runtime library (version 1.6)
  libpng is a library implementing an interface for reading and writing
  PNG (Portable Network Graphics) format files.

NEW changes in stable-new

Processing changes file: giflib_4.1.6-11+deb8u1_source.changes
  ACCEPT

NEW changes in oldstable-new

Processing changes file: giflib_4.1.6-10+deb7u1_amd64.changes
  ACCEPT

Bug#650601: libpng is ready for transition

2016-01-26 Thread Gianfranco Costamagna

Hi Tobias

>+libpng1.6 (1.6.20-1.2)
> unstable; urgency=medium

Do you want to go on unstable or it is a typo?

Gianfranco

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

2016-01-26 Thread Otto Kekäläinen

Hello!

As the principal maintainer of MariaDB server packaging in Debian I
should probably also chip in here.

First of all I'd like to thank Robie for the summary. Robie is correct
in pointing out that the release and security team's arguments are
somewhat based on disgust for Oracle and less on technical merits of
MySQL packages in Debian.

It is not very nice of Oracle to keep the CVE details hidden even to
the extent that they don't give out the details on a pkg-mysql-maint
mailing list when asked, not even when the questions were regarding
several months old CVEs that Oracle has had fixed in their releases
for some time, and disclosure could not generate much harm anymore.
Not nice indeed, but however not against the Debian policy, as
commenters in this thread rightfully point out. Has any other project
ever been kicked out from Debian due to too much security by
obscurity?

Oracle also has other things freedom and openness loving debianists
don't like, for example non-public bug tracker, non-public source code
development repository, no external committers, all development
discussions are done in in-house meetings and outside participation
via mailing lists or irc is practically impossible, online
documentation is no longer available on a free license, even man pages
have been removed from project source code etc. MariaDB is a much
nicer choice in this regard. Oracle MySQL basically does code dumping
instead of real free and open source software. But so does many other
companies too and their software is included in Debian. DFSG does not
forbid the code dumping style as long as the code dump is actually
released using a real free/open license.

Also the comparisons to OpenOffice vs LibreOffice, Hudson vs Jenkins
etc are not fair. For Oracle the MySQL project has a special role and
they keep developing it, so it is not a good argument to bluntly
punish Oracle MySQL for mismanagement in other projects.

The release and security teams should present, as Robie points out,
concrete and actionable lists on things that are wrong, and the
"wrongness" should preferably be based on Debian policy or something
else predictable and not on newly invented rules.

Presenting ethical arguments is OK if they are based on Debian core
documents. I am of course not against using ethics in the decision
making process, but the people who put a lot of time and effort in
MySQL packaging in Debian need fair treatment, and more objective
technical arguments are therefore preferred.

Presenting technical arguments should be based on a comparison of e.g.
https://tracker.debian.org/pkg/mysql-5.5
https://tracker.debian.org/pkg/mysql-5.6
https://tracker.debian.org/pkg/mariadb-5.5
https://tracker.debian.org/pkg/mariadb-10.0

Examples of technical arguments I'd prefer to use instead of general
disgust of Oracle arguments:

- Quality: mysql-5.6 has 135 open bugs despite never being part of a
Debian release and thus having exposure to the big Debian user masses.
Some of them are even RC. The package mariadb-10.0 has only 10 bugs,
which of 5 were filed by myself as TODO items with priority wishlist,
and it actually ships in Jessie for big audience.

- Quality: mysql-5.6 ships the same version number
libmysqlclient.so.18 as 5.5 but the ABI is different and according to
investigations by Robie Basak going back September 2014 [1] the
upgrade might break something, and while it is now partially remedied,
the ABI bump has never been done, the symbols file to track this all
is missing from the packaging, and there is a Lintian override to keep
Lintian quiet about the lack of a symbols file [2]

- Quality: mysql-5.6 only runs ~600 tests as part of their Debian
build, while MariaDB has 4000+ tests, making MySQL test coverage much
smaller than the MariaDB one, thus catching less issues on many of the
Debian platforms as Oracle MySQL probalby don't test those at all
in-house.

 - Activity: Since the beginning of 2015 mysql-5.6 packaging master
branch in Debian unstable has had 118 commits by 12 authors, while the
mariadb-10.0 master branch in Debian has had in the same time 231
commits by 14 authors (authors don't include patch submissions and
translators). I would claim MariaDB is more actively maintained. Note
that uploads are done by Robie and me for mysql-5.6 and mariadb-10.0,
who both are DMs. The team does not have any really active DDs at the
moment, which is a problem for both packages.

[1] 
http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007015.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812812
[3] git log --since='2015-01-01' --oneline | wc -l
[4] git log --since='2015-01-01' | grep Author | sort -u | cut -c -20
| sort -u | wc -l


Then a few words about the decision:

2016-01-26 0:14 GMT+02:00 Robie Basak :
> My original request for a decision proposed one of the following
> options, which I think we all agree are the only options available:
>
> 1) We carry and ship

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

2016-01-26 Thread Otto Kekäläinen

Hello!

2016-01-26 2:48 GMT+02:00 Steven Chamberlain :
> I was wondering why after the 2016-01-19 announcement, there is still no
> patched mysql-5.5 in jessie or wheezy;  and also why mariadb was only
> just patched today.  Debian is typically much faster than this at
> getting out patches.  Is it to do with complexity, available manpower,
> or other things?

Technically I could have uploaded MariaDB 10.0.23 earlier, but I
cannot convince the stable release team or security team to upload it
to Jessie before it has officially been announced as a security update
with CVE identifiers and all.

I Ubuntu there is the Micro Release Exception, so in could have got
5.5.47 uploaded to Ubuntu 14.04 even without explicit security update
motivation. In fact I did prepare the upload and file
https://bugs.launchpad.net/ubuntu/+source/mariadb-5.5/+bug/1524704 on
December 10th, but as it as not a known security update at that time
nobody got interested enough to upload it.. Maybe tomorrow somebody
will as Ubuntu announced the MySQL security notice today, and Ubuntu
people usually accept my security updates in 1-2 days.

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

2016-01-26 Thread Otto Kekäläinen

2016-01-26 10:49 GMT+02:00 Stephan Seitz :
> On Tue, Jan 26, 2016 at 12:48:23AM +, Steven Chamberlain wrote:
>>
>> Assuming MariaDB is affected by the same issues, I may not be in a
>> technically better situation if I switched to using that.  (Although, it
>
>
> But as far as I understand it there is no guarantee that MySQL and MariaDB
> will stay compatible in the future.
>
> So what are you doing if MySQL is removed and other programs (e.g. cacti)
> are not working with MariaDB anymore?

Oracle people can fill in if I have the wrong info, but I think that
it is mostly Oracle MySQL that does not track MariaDB changes, while
the other way happens and at least MariaDB will be compatible with
MySQL for the forseeable future and migrating from MySQL to MariaDB
will work.

Also, I've read that Oracle has dropped some of the older code
(probably mostly a well justified clean-up) and therefore for example
5.6 and 5.7 are not fully backwards compatible, and some apps might
need to change to accomodate for changes. So Oracle MySQL is in this
sense not always "compatible" with itself either.

This compatiblity discussion is not very practical, its just corner
cases. For example for all Cacti or WordPress users any version fo
MySQL and MariaDB will most likely work just fine in the foreseeable
future.

Bug#812821: nmu: pam_1.1.8-3.1+deb8u1

2016-01-26 Thread Tianon Gravi

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

Due to some kind of mistake in my amd64 build environment (details being
tracked down in #812566) the amd64 build of pam_1.1.8-3.1+deb8u1 is the
only one that got the intended man page update, but this causes
co-installability issues (as detailed in #812566).  Getting a binNMU of
amd64 in the meantime would be great so that at least the packages line
up properly while we figure out what happened. :(

nmu pam_1.1.8-3.1+deb8u1 . amd64 . jessie . -m "Rebuild with correct build 
environment"

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

2016-01-26 Thread Niels Thykier

Pedretti Fabio:
>> * Summary of options and selection status
>>

Hi Robie,

I appreciate your intention.  However, I felt it was way too long for a
summary and at this point it still TL;DR for me and I fear I won't have
time to read and digest it all.

However, I can certainly understand that you wanted to include all of
that.  Personally, I can see several points for improvements on the
Debian release team's side.

>> My original request for a decision proposed one of the following
>> options, which I think we all agree are the only options available:
>>
> [...]
> 

I do not feel the listed options accurately reflect the issues /
concerns in play.  As *I see it*, these are the options:

  1) Default to MySQL with MariaDB also available /!\

  2) Default to MariaDB with MySQL also available

  3) Only MySQL available, MariaDB removed from testing /!\

  4) Only MariaDB available, MySQL removed from testing.

  5) Further discussion / delayed decision

The options marked with /!\ are de facto *no-go* for me if/given the
security team is unwilling to provide security support for MySQL[2].

In summary (again, *from my PoV*):

 * None of the currently available "reasonable options" include status
   quo (excl. 5).
   - Ergo, I see it as a transition of the default.

 * This is a transition I want early rather than rushed earlier.
   - It can trivially end up taking 6 months of calender time before it
 is complete.  This is uncomfortably close to the transition
 deadline

 * For me, 1, 3 and 5 seems too unreliable / too unlikely that I am
   convinced we should accept the risks involved in it.
   - While I consider 2 unlikely, it has lower "risk" for me.  Notably
 going from "2" to "4" (and vice versa) is vastly easier than from
 "1" to "2".

Beyond this, I can certainly appreciate your desire to resolve the
situation between the security team and MySQL upstream on CVE
disclosures etc.

Thanks,
~Niels

PS: Re: 3)+4) I think it is largely irrelevant for the release team and
the security team whether the removal *also* includes unstable. At the
very least, it is a secondary concern, so I have decided to omit this
distinction.

[1]
https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#limited-security-support

[2] Rationale: Missing security support would certainly have to go in
the Stretch variant of [1]. That makes for a very bad release to have a
default implementation being *without* official security support.
Whether the MySQL team can deliver something comparable is a separate
debate.





signature.asc
Description: OpenPGP digital signature

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

2016-01-26 Thread Niels Thykier

Otto Kekäläinen:
> Hello!
> 
> As the principal maintainer of MariaDB server packaging in Debian I
> should probably also chip in here.
> 

Hi,

Thanks for your input.

 * Re: Meeting time - I have noted 19:00 UTC tomorrow in my calender.
 * I will cut this very short as I am out of time.

> [... Suggestions / Information / etc. ...]

Don't claim to have read and fully digested all of it.  But certainly
appreciate the different angles and technical merits of MariaDB and MySQL.

> 
> If you want to see an increased shift towards MariaDB we could mass
> file bugs against packages that have "Depends: mysql-server |
> virtual-mysql-server" to switch to "Depends: mariadb-server |
> virtual-mysql-server" so that the "Debian default" would be MariaDB

From my PoV, this would be very helpful if the default was changed.

> [...]

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

2016-01-26 Thread Colin Charles

Hi!

First off, I thank Robie for the excellent summary, and think this is a healthy 
discussion to have, so kudos to all participants

I feel I can’t make any comments on this thread as I’m employed to work on 
MariaDB Server, but will just make one point as below

> On 27 Jan 2016, at 06:45, Otto Kekäläinen  wrote:
> 
> commenters in this thread rightfully point out. Has any other project
> ever been kicked out from Debian due to too much security by
> obscurity?

I think elasticsearch might fit the bill:
https://lists.debian.org/debian-security-announce/2015/msg00290.html

cheers,
-colin

--
Colin Charles, http://bytebot.net/blog/
twitter: @bytebot | skype: colincharles
"First they ignore you, then they laugh at you, then they fight you, then you 
win." -- Mohandas Gandhi



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Bug#650601: libpng is ready for transtion

2016-01-26 Thread Cyril Brulebois

Aníbal Monsalve Salazar  (2016-01-26):
> On Tue, 2016-01-26 10:23:13 +0100, Tobias Frost wrote:
> > this is a question for you:
> >
> > https://lists.debian.org/debian-devel/2016/01/msg00248.html
> >
> > {quote}
> > Speaking of this particular udeb, I've just spotted libpng16-16-udeb has
> > a Conflicts against libpng12-0-udeb. I'm not sure why, and the changelog
> > doesn't seem to explain either. libpng16-16 and libpng12-0 seems to be
> > co-installable, so I'm not sure why their respective udebs shouldn't be.
> > {/quote}
> 
> The Conflicts against libpng12-0-udeb can be removed.

Looks fair on principle, thanks.

Has anyone tested a debian installer build where some packages were
built against libpng12-0-udeb and some other against libpng16-16-udeb?
Does that work? Or are we looking at a giant transition where everything
must switch to libpng16 at once?

Mraw,
KiBi.

signature.asc
Description: Digital signature

Bug#812731: marked as done (RM: mate-system-tools -- RoM; abandoned upstream)

Your message dated Tue, 26 Jan 2016 09:58:41 +
with message-id <8b5bb3375fc82dbbb43a9abd33c82...@mail.adam-barratt.org.uk>
and subject line Re: Bug#812731: RM: mate-system-tools -- RoM; abandoned
upstream
has caused the Debian Bug report #812731,
regarding RM: mate-system-tools -- RoM; abandoned upstream
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.)

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

Package: release.debian.org
X-Debbugs-Cc: pkg-mate-t...@lists.alioth.debian.org

Dear release team,

please remove mate-system-tools from Debian testing (aka stretch). It
is not continued upstream anymore. A removal request has also been
sent to the ftpmasters for the package version found in unstable.

Thanks,
Mike (on behalf of the Debian MATE Packaging Team)

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de

pgpHO9bQ53P09.pgp
Description: Digitale PGP-Signatur
--- End Message ---
--- Begin Message ---

On 2016-01-26 8:25, Mike Gabriel wrote:

Package: release.debian.org
X-Debbugs-Cc: pkg-mate-t...@lists.alioth.debian.org

Dear release team,

In that case there's no need for an explicit removal from testing. Once
the unstable removal is processed it will automatically become a
candidate for removal from testing.

Regards,

Adam--- End Message ---

Bug#812731: RM: mate-system-tools -- RoM; abandoned upstream