Bug#813237: transition: ruby2.3

2016-03-02 Thread Antonio Terceiro 
On Wed, Mar 02, 2016 at 05:10:54PM +0100, Emilio Pozuelo Monfort wrote:
> On 02/03/16 13:25, Christian Hofstaedtler wrote:
> > Emilio,
> > 
> > I think we're quite close to be able to drop 2.2 - it's already in
> > experimental, we're quite confident it works, etc.
> > 
> > Right now we know that uwsgi and weechat will need manual fixing and
> > there are open bugs against them (#816315, #816312).
> > 
> > When do you think it would be ok for us to drop 2.2? We'll need
> > another round of binNMUs for all the packages listed on the tracker.
> > (We're running another test rebuild of those right now.)
> 
> You can go ahead.

So I have uploaded ruby-defaults making the switch on unstable earlier
today. Please binNMU the following packages:

broccoli-ruby
geos
graphviz
marisa
ngraph-gtk
notmuch
qtruby
redland-bindings
ruby-standalone
rubyluabridge
subversion
treil
vim
vim-command-t
libguestfs

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature

Re: Bug#814589: otrs2: source-less files; undocumented copyrights/licenses; abuse of lintian-overrides; systematic DFSG violations

2016-03-02 Thread Dmitry Smirnov 
Dear Patrick,

On Wed, 2 Mar 2016 12:36:46 PM Patrick Matthäi wrote:
> Am 15.02.2016 um 14:14 schrieb Dmitry Smirnov:
> > And this is why I provided some hints how you can address those problems
> > in my bug report. This is why I wrote to you after when I stabilised
> > "ckeditor" so you could use it.
> 
> I can use it, until ckeditor OR otrs upstreams broke it again, like with
> jquery.

Thank you for checking. I think using bundled ckeditor is not an option 
because it is source-less and shipped as minified blobs.
jQuery is a lot easier to handle because it is just one file.


> Also it would prevent backports of otrs to jessie.

I'm already working on that. "ckbuilder" is in backports/NEW and once 
accepted I'll upload "ckeditor" (which I need in backports for one of my 
packages as well).


> >> and mostly it is not possible to replace the
> >> libjs thirdparty foo with the packages from Debian, mostly because of
> >> version missmatches.

As I've said, you don't have to replace all bundled JS libraries with system 
ones as it might make package needlessly fragile and difficult to backport.

What you have to do is to find original/uncompressed JS files and ship them 
in "debian/missing-sources" ideally replacing minified files as well.
It is easy to do and safe and it will help your package to comply with DFSG 
requirements. 


> You reported a very general bug about the whole javascript mess.
> Replacing ckeditor will not solve the other problems or all those
> minified files and so on.

You have to start somewhere don't you? I'm not even Otrs2 user (let alone 
maintainer) so why do expect more from me?


> Investing work in removing those files will not realy help and just
> burden the whole packaging and eat time to fix realy serious issues -
> like embedded libs.

I think DFSG compliance is not optional in Debian.
Shipping missing sources in "debian/missing-sources" shouldn't take too much 
effort... Did you consider this option?

-- 
Regards,
 Dmitry Smirnov.

---

Odious ideas are not entitled to hide from criticism behind the human
shield of their believers' feelings.
-- Richard Stallman


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

Bug#814930: marked as done (jessie-pu: package hplip/3.15.11+repack0-1)

2016-03-02 Thread Debian Bug Tracking System 
Your message dated Wed, 2 Mar 2016 12:51:26 -0800
with message-id <20160302205126.ga13...@smetana.kardiogramm.net>
and subject line Re: Bug#814930: jessie-pu: package hplip/3.15.11+repack0-1
has caused the Debian Bug report #814930,
regarding jessie-pu: package hplip/3.15.11+repack0-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.)


-- 
814930: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814930
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

I asked the printing people how they felt about an backport of hplip,
and OdyX suggested [0]:

> As far as I remember (but could never take the time to actively
> check), the Debian Stable Managers were open to update packages in
> Stable for hardware support (and "new HP Printer" would qualify). I
> haven't checked the hplip code to see whether a full new upstream
> release would make sense over backporting specific parts though.

> tl;dr: I'd check with the SRMs first.

How would you feel about a wholesale backport of hplip, to stable?

No debdiff attached, because it's scary huge. Not even a diffstat,
because:

> 4362 files changed, 1703256 insertions(+), 17230 deletions(-)

[0]: https://lists.debian.org/3588455.xzku8qg...@odyx.org

SR
--- End Message ---
--- Begin Message ---
Hi Julien (2016.02.23_10:54:10_-0800)
> This was mostly putting a feeler out, as Didier thought you may be interested
> in a stable update, that supported new hardware. It seems to not be the
> case, so maybe I should just do a backport.

We did that. jak is uploading a backport.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272--- End Message ---

Re: Opinion about linux-grsec in a stable release

2016-03-02 Thread Yves-Alexis Perez 
On mer., 2016-03-02 at 20:06 +0100, Moritz Muehlenhoff wrote:
> Before considering that, did anyone approch grsecurity whether we can get
> access to the grsecurity stable patches? We would most definitely have Debian
> funds to become grsecurity sponsors to obtain access to stable patches.

I think that'd be something nice anyway, but…
> 
> Whether that's possible/desirable by grsecurity is the question, though:
> Having the stable patches in Debian would make them available to the
> general public (including those sleazy embedded companies which made them
> change their distribution scheme).

Indeed, I didn't even bother to ask because when you gain access to the stable
patches, you commit yourself to not make them available publicly, which is
obviously exactly what we would do.

Regards,
-- 
Yves-Alexis



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

Re: Opinion about linux-grsec in a stable release

2016-03-02 Thread Moritz Muehlenhoff 
On Wed, Mar 02, 2016 at 10:09:47AM +0100, Yves-Alexis Perez wrote:
> Hi teams,
> 
> [first of all, I'm writing this with my linux-grsec hat, not my Debian
> security team member hat, obviously]
> 
> As you may know, src:linux-grsec was accepted in unstable earlier this year.
> As a quick summary, this is a source linux package (forked from and
> periodically rebased against src:linux) which generates a linux kernel with
> the grsecurity hardening patch (the patch is mostly about fighting memory
> corruptions bugs, but not only, I won't enter into details here to keep it
> short, but more information can be found in the ITP bug #605090).
> 
> When the package was accepted to unstable, I filed #810506 with severity
> serious in order to prevent it to migrate to testing, because I wasn't really
> sure it'd be fit for stable.
> 
> There are two main aspects for this:
> 
> - it's a new Linux kernel source package, next to the existing src:linux, so
> that means code duplication
> - due to the grsecurity release model, it's likely that it won't be possible
> to stick with a major kernel version (4.3 right now, 4.4 upcoming), we would
> have to upgrade to the latest major release (using stable uploads)

Before considering that, did anyone approch grsecurity whether we can get
access to the grsecurity stable patches? We would most definitely have Debian
funds to become grsecurity sponsors to obtain access to stable patches.

Whether that's possible/desirable by grsecurity is the question, though:
Having the stable patches in Debian would make them available to the
general public (including those sleazy embedded companies which made them
change their distribution scheme).

(However a determined, GPL violating embedded company who wants access to
the stable patches would likely find a way anyway)

Cheers,
Moritz

Re: Bug#816500: linux-tools: should not migrate to testing before the corresponding src:linux

2016-03-02 Thread Ben Hutchings 
Control: tag -1 wontfix

On Wed, 2016-03-02 at 17:47 +, Adam D. Barratt wrote:
[...]
> > Does that mean there was manual intervention?  Or is that automatic
> > behaviour?  Does it ignore all->any dependencies on !x86?
> 
> It was all automatic. britney only requires that arch:all packages are 
> installable on i386 and amd64. At the end of the britney run during 
> which linux-tools migrated, the old binary packages from each of the 
> other architectures were removed as doing so did not create any new 
> uninstallability so far as britney was concerned.

I conclude that this "bug" is harmless to x86, and the broken state of
!x86 is down to britney policy and not something to be overridden at
package level.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

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

Bug#816428: nmu: hugin_2015.0.0+dfsg-1

2016-03-02 Thread Andreas Metzler 
On 2016-03-01 Emilio Pozuelo Monfort  wrote:
> On 01/03/16 20:25, Andreas Metzler wrote:
>> nmu hugin_2015.0.0+dfsg-1 . ANY . unstable . -m "Rebuild against 
>> libvigraimpex6"
>> nmu enblend-enfuse_4.1.4+dfsg-5 . ANY . unstable . -m "Rebuild against 
>> libvigraimpex6"
 
>> both hugin and enblend-enfuse were built (or binmued) against a broken
>> version of libvigraimpex which shipped libvigraimpex.so.6 in a package
>> still named libvigraimpex5v5. (#813415)

> I haven't scheduled the appropriate binNMUs yet because libvigraimpex isn't
> built everywhere.

Hello,

I am aware of the transition, which is why I have waited two weeks
before requesting the binNMU. However hugin and enblend-enfuse are only
broken on the archs where libvigraimpex does build.

So a straight rebuild would fix this serious bug, at the imho small cost
that a later followup binNMU might be needed when libvigraimpex is
ready.

Thanks in advance for considering,
cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Bug#816500: linux-tools: should not migrate to testing before the corresponding src:linux

2016-03-02 Thread Adam D. Barratt 

On 2016-03-02 17:22, Ben Hutchings wrote:

On Wed, 2016-03-02 at 17:21 +0100, Emilio Pozuelo Monfort wrote:

On 02/03/16 13:24, Ben Hutchings wrote:
> On Wed, 2016-03-02 at 12:31 +0100, Andreas Beckmann wrote:
> > Source: linux-tools
> > Version: 4.4-4
> > Severity: important
> >
> > Hi,
> >
> > new major upstream releases (e.g. 4.4) of src:linux and src:linux-tools 
> > should migrate together to testing. Right now src:linux-tools 4.4-4 is
> > already in testing, which doesn't look too useful to me without
> > src:linux 4.4.x-y.
>
> This should have been prevented by the fact that it makes linux-perf
> uninstallable in testing (it depends on linux-perf-4.3).  Cc'ing the
> release team to comment on why it happened anyway.

Because linux-perf-4.3 is still in testing.


Yet only on two architectures!


Yes, because...


It was smooth-updated. Not sure if that was expected, given the
package is in section devel and not (old)libs.


Actually, I'm not sure that it was. The excuses for the run during which 
it migrated has:


old binaries left on href="http://buildd.debian.org/status/logs.php?arch=amd64=linux-tools=4.4-4; 
target="_blank">amd64: liblockdep4.3, linux-kbuild-4.3, 
linux-perf-4.3 (from href="http://buildd.debian.org/status/logs.php?arch=amd64=linux-tools=4.3.1-2; 
target="_blank">4.3.1-2) (but ignoring cruft, so nevermind)
old binaries left on href="http://buildd.debian.org/status/logs.php?arch=i386=linux-tools=4.4-4; 
target="_blank">i386: liblockdep4.3, linux-kbuild-4.3, 
linux-perf-4.3 (from href="http://buildd.debian.org/status/logs.php?arch=i386=linux-tools=4.3.1-2; 
target="_blank">4.3.1-2) (but ignoring cruft, so nevermind)
old binaries left on href="http://buildd.debian.org/status/logs.php?arch=arm64=linux-tools=4.4-4; 
target="_blank">arm64: liblockdep4.3, linux-kbuild-4.3, 
linux-perf-4.3 (from href="http://buildd.debian.org/status/logs.php?arch=arm64=linux-tools=4.3.1-2; 
target="_blank">4.3.1-2) (but ignoring cruft, so nevermind)


and so on. So the new version was migrated at the start of the run, and 
then she tried to remove the cruft at the end (and is still trying, in 
fact).



Does that mean there was manual intervention?  Or is that automatic
behaviour?  Does it ignore all->any dependencies on !x86?


It was all automatic. britney only requires that arch:all packages are 
installable on i386 and amd64. At the end of the britney run during 
which linux-tools migrated, the old binary packages from each of the 
other architectures were removed as doing so did not create any new 
uninstallability so far as britney was concerned.


Regards,

Adam

Re: Bug#816500: linux-tools: should not migrate to testing before the corresponding src:linux

2016-03-02 Thread Ben Hutchings 
On Wed, 2016-03-02 at 17:21 +0100, Emilio Pozuelo Monfort wrote:
> On 02/03/16 13:24, Ben Hutchings wrote:
> > On Wed, 2016-03-02 at 12:31 +0100, Andreas Beckmann wrote:
> > > Source: linux-tools
> > > Version: 4.4-4
> > > Severity: important
> > > 
> > > Hi,
> > > 
> > > new major upstream releases (e.g. 4.4) of src:linux and src:linux-tools 
> > > should migrate together to testing. Right now src:linux-tools 4.4-4 is
> > > already in testing, which doesn't look too useful to me without
> > > src:linux 4.4.x-y.
> > 
> > This should have been prevented by the fact that it makes linux-perf
> > uninstallable in testing (it depends on linux-perf-4.3).  Cc'ing the
> > release team to comment on why it happened anyway.
> 
> Because linux-perf-4.3 is still in testing.

Yet only on two architectures!

> It was smooth-updated. Not sure if that was expected, given the
> package is in section devel and not (old)libs.
> 

Does that mean there was manual intervention?  Or is that automatic
behaviour?  Does it ignore all->any dependencies on !x86?

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

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

Bug#813916: transition: gdal

2016-03-02 Thread Emilio Pozuelo Monfort 
On 01/03/16 20:18, Sebastiaan Couwenberg wrote:
> Thanks. I'll upload gdal (2.0.2+dfsg-1) to unstable shortly.

binNMUs scheduled.

Emilio

Re: Bug#816500: linux-tools: should not migrate to testing before the corresponding src:linux

2016-03-02 Thread Emilio Pozuelo Monfort 
On 02/03/16 13:24, Ben Hutchings wrote:
> On Wed, 2016-03-02 at 12:31 +0100, Andreas Beckmann wrote:
>> Source: linux-tools
>> Version: 4.4-4
>> Severity: important
>>
>> Hi,
>>
>> new major upstream releases (e.g. 4.4) of src:linux and src:linux-tools 
>> should migrate together to testing. Right now src:linux-tools 4.4-4 is
>> already in testing, which doesn't look too useful to me without
>> src:linux 4.4.x-y.
> 
> This should have been prevented by the fact that it makes linux-perf
> uninstallable in testing (it depends on linux-perf-4.3).  Cc'ing the
> release team to comment on why it happened anyway.

Because linux-perf-4.3 is still in testing. It was smooth-updated. Not sure if
that was expected, given the package is in section devel and not (old)libs.

Emilio

Bug#816499: marked as done (nmu: votca-csg_1.2.4-2.1)

2016-03-02 Thread Debian Bug Tracking System 
Your message dated Wed, 2 Mar 2016 17:15:52 +0100
with message-id <56d711b8.6010...@debian.org>
and subject line Re: Bug#816499: nmu: votca-csg_1.2.4-2.1
has caused the Debian Bug report #816499,
regarding nmu: votca-csg_1.2.4-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.)


-- 
816499: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816499
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 votca-csg_1.2.4-2.1 . ANY . unstable . -m "Rebuild against votca-tools 
1.3.0"

The last votca-tools upload started an (uncoordinated) mini-transition from
libvotca-tools2 to libvotca-tools3, only votca-csg is affected by this.
The new votca-tools is already in testing.


Andreas
--- End Message ---
--- Begin Message ---
On 02/03/16 12:18, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu votca-csg_1.2.4-2.1 . ANY . unstable . -m "Rebuild against votca-tools 
> 1.3.0"
> 
> The last votca-tools upload started an (uncoordinated) mini-transition from
> libvotca-tools2 to libvotca-tools3, only votca-csg is affected by this.
> The new votca-tools is already in testing.

I missed that one. Scheduled.

Thanks,
Emilio--- End Message ---

Bug#813237: transition: ruby2.3

2016-03-02 Thread Emilio Pozuelo Monfort 
On 02/03/16 13:25, Christian Hofstaedtler wrote:
> Emilio,
> 
> I think we're quite close to be able to drop 2.2 - it's already in
> experimental, we're quite confident it works, etc.
> 
> Right now we know that uwsgi and weechat will need manual fixing and
> there are open bugs against them (#816315, #816312).
> 
> When do you think it would be ok for us to drop 2.2? We'll need
> another round of binNMUs for all the packages listed on the tracker.
> (We're running another test rebuild of those right now.)

You can go ahead.

> In the meantime, please binNMU ruby-mysql too :-)

Scheduled.

Cheers,
Emilio

Re: Debian Jessie - Incorrect permissions on /bin directory

2016-03-02 Thread Emilio Pozuelo Monfort 
On 02/03/16 12:46, Yves-Alexis Perez wrote:
> On mer., 2016-02-03 at 14:37 +0100, Cyril Brulebois wrote:
>> [Context: packages shipping /bin with “funny” permissions, seen in stable.]
>>
>> Yves-Alexis Perez  (2016-02-03):
>>>
>>> On mar., 2016-02-02 at 17:16 +0100, Cyril Brulebois wrote:

 I didn't check the whole archive, but doing so might be interesting.
>>> I did a quick check on a local mirror (which might be incomplete), and
>>> found
>>> three packages with errors:
>>>
>>> dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$
>>> drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
>>> dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$ 
>>> drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/
>>> dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep
>>> bin/$
>>> drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/
>>>
>>> Note that lintian complains a lot about them:
>>>
>>> lintian sed_4.2.2-4+b1_amd64.deb
>>> W: sed: syntax-error-in-debian-changelog line 1 "unknown key-value key
>>> Binary-only - copying to XS-Binary-only"
>>> W: sed: latest-debian-changelog-entry-without-new-date
>>> E: sed: control-file-has-bad-permissions md5sums 0664 != 0644
>>> W: sed: description-synopsis-starts-with-article
>>> W: sed: non-standard-dir-perm bin/ 0775 != 0755
>>> W: sed: package-contains-timestamped-gzip
>>> usr/share/doc/sed/changelog.Debian.gz
>>> W: sed: non-standard-dir-perm usr/share/info/ 0775 != 0755
>>> W: sed: package-contains-timestamped-gzip usr/share/info/sed.info.gz
>>> W: sed: non-standard-dir-perm usr/share/locale/ 0775 != 0755
>>> W: sed: non-standard-dir-perm ... use --no-tag-display-limit to see all
>>> (or pipe to a file/program)
>>> W: sed: package-contains-timestamped-gzip usr/share/man/man1/sed.1.gz
>>>
>>> It looks like an umask problem at package build time. Right now it doesn't
>>> seem to have obvious security issues (like world writable /bin) but I'm
>>> not
>>> too sure there are not other stuff hidden.
>>>
>>> I guess it'd make sense to do an archive-wide lintian run to look for that
>>> kind of mistakes, and then ask for stable binNMUs of the relevant
>>> packages.
>> It seems to me that lintian looks at testing/unstable (at least looking
>> at https://lintian.debian.org/full/cl...@debian.org.html#sed_4.2.2-6),
>> so I'm not sure this would help for stable.
>>>
>>>
>>> What do you think?
>> I think debian-release@ needs to be in the loop, doing so.
>>
> Hey,
> 
> so as far as I can tell there was no reaction from -release (although I can
> understand noone's really sure what to do here). Is it at least possible to
> schedule binNMUs in stable for those affected packages so future installs
> don't end up with bad permissions like these?

Would it make sense to start autorejecting packages that have this tag?

Emilio

Re: Debian Jessie - Incorrect permissions on /bin directory

2016-03-02 Thread Jakub Wilk 

* Yves-Alexis Perez , 2016-03-02, 12:46:
I did a quick check on a local mirror (which might be incomplete), 
and found three packages with errors:


dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$
drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$ 
drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/
dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep
bin/$
drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/

[...]
It looks like an umask problem at package build time. Right now it 
doesn't seem to have obvious security issues (like world writable 
/bin) but I'm not too sure there are not other stuff hidden.


I guess it'd make sense to do an archive-wide lintian run to look for 
that kind of mistakes, and then ask for stable binNMUs of the 
relevant packages.
It seems to me that lintian looks at testing/unstable (at least 
looking at 
https://lintian.debian.org/full/cl...@debian.org.html#sed_4.2.2-6), so 
I'm not sure this would help for stable.


Yup, lintian.d.o only checks unstable. For sed, this is #774347, which 
is already fixed there.


so as far as I can tell there was no reaction from -release (although I 
can understand noone's really sure what to do here). Is it at least 
possible to schedule binNMUs in stable for those affected packages so 
future installs don't end up with bad permissions like these?


I believe sbuild uses umask 002, so binNMUs probably won't help. In 
fact, the stable version of sed was already built on buildds.


--
Jakub Wilk

Bug#813237: transition: ruby2.3

2016-03-02 Thread Christian Hofstaedtler 
* Christian Hofstaedtler  [160302 13:25]:
> When do you think it would be ok for us to drop 2.2? We'll need
> another round of binNMUs for all the packages listed on the tracker.
> (We're running another test rebuild of those right now.)

>From our test rebuild, those packages failed:

Packages we already knew about:
- uwsgi
- weechat
- zeroc-ice (B-D on packages not in unstable)

And then there's remctl, which fails on our test rebuild VM but
works fine when building on our local sbuilds, so I expect that to
just work on the buildds, too.


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

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

2016-03-02 Thread Gianfranco Costamagna 
Hi Emilio,

> > (My*) plan'd be to upload (1) libpng12 WITHOUT providing libpng-dev and
> > (2) libpng16 WITH providing it. 
> This hasn't been answered yet. That should be dealt with and a package should 
> be
> uploaded to experimental with the necessary changes.

my opinion is: remove libpng-dev from libpng12 and upload.
start providing it from libpng16 and upload on unstable.

start binNMUs as soon as both are built everywhere.
(can we upload on experimental by providing libpng-dev? this means we
could have some partial transitions there, not sure if it is something
we will like).

cheers,

G.



signature.asc
Description: OpenPGP digital signature

Bug#813237: transition: ruby2.3

2016-03-02 Thread Christian Hofstaedtler 
Emilio,

I think we're quite close to be able to drop 2.2 - it's already in
experimental, we're quite confident it works, etc.

Right now we know that uwsgi and weechat will need manual fixing and
there are open bugs against them (#816315, #816312).

When do you think it would be ok for us to drop 2.2? We'll need
another round of binNMUs for all the packages listed on the tracker.
(We're running another test rebuild of those right now.)

In the meantime, please binNMU ruby-mysql too :-)

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

Re: Bug#816500: linux-tools: should not migrate to testing before the corresponding src:linux

2016-03-02 Thread Ben Hutchings 
On Wed, 2016-03-02 at 12:31 +0100, Andreas Beckmann wrote:
> Source: linux-tools
> Version: 4.4-4
> Severity: important
> 
> Hi,
> 
> new major upstream releases (e.g. 4.4) of src:linux and src:linux-tools 
> should migrate together to testing. Right now src:linux-tools 4.4-4 is
> already in testing, which doesn't look too useful to me without
> src:linux 4.4.x-y.

This should have been prevented by the fact that it makes linux-perf
uninstallable in testing (it depends on linux-perf-4.3).  Cc'ing the
release team to comment on why it happened anyway.

> Does any of the binary packages built from linux-tools have a dependency
> on something from src:linux that could be made versioned?
> Or add a linux-tools-dummy package which Depends: linux-source-X.Y

The existing dependencies between binaries generated by linux-latest,
linux and linux-tools have always seemed sufficient to prevent this
happening in the past.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

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

Re: Debian Jessie - Incorrect permissions on /bin directory

2016-03-02 Thread Yves-Alexis Perez 
On mer., 2016-02-03 at 14:37 +0100, Cyril Brulebois wrote:
> [Context: packages shipping /bin with “funny” permissions, seen in stable.]
> 
> Yves-Alexis Perez  (2016-02-03):
> > 
> > On mar., 2016-02-02 at 17:16 +0100, Cyril Brulebois wrote:
> > > 
> > > I didn't check the whole archive, but doing so might be interesting.
> > I did a quick check on a local mirror (which might be incomplete), and
> > found
> > three packages with errors:
> > 
> > dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$
> > drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
> > dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$ 
> > drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/
> > dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep
> > bin/$
> > drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/
> > 
> > Note that lintian complains a lot about them:
> > 
> > lintian sed_4.2.2-4+b1_amd64.deb
> > W: sed: syntax-error-in-debian-changelog line 1 "unknown key-value key
> > Binary-only - copying to XS-Binary-only"
> > W: sed: latest-debian-changelog-entry-without-new-date
> > E: sed: control-file-has-bad-permissions md5sums 0664 != 0644
> > W: sed: description-synopsis-starts-with-article
> > W: sed: non-standard-dir-perm bin/ 0775 != 0755
> > W: sed: package-contains-timestamped-gzip
> > usr/share/doc/sed/changelog.Debian.gz
> > W: sed: non-standard-dir-perm usr/share/info/ 0775 != 0755
> > W: sed: package-contains-timestamped-gzip usr/share/info/sed.info.gz
> > W: sed: non-standard-dir-perm usr/share/locale/ 0775 != 0755
> > W: sed: non-standard-dir-perm ... use --no-tag-display-limit to see all
> > (or pipe to a file/program)
> > W: sed: package-contains-timestamped-gzip usr/share/man/man1/sed.1.gz
> > 
> > It looks like an umask problem at package build time. Right now it doesn't
> > seem to have obvious security issues (like world writable /bin) but I'm
> > not
> > too sure there are not other stuff hidden.
> > 
> > I guess it'd make sense to do an archive-wide lintian run to look for that
> > kind of mistakes, and then ask for stable binNMUs of the relevant
> > packages.
> It seems to me that lintian looks at testing/unstable (at least looking
> at https://lintian.debian.org/full/cl...@debian.org.html#sed_4.2.2-6),
> so I'm not sure this would help for stable.
> > 
> > 
> > What do you think?
> I think debian-release@ needs to be in the loop, doing so.
> 
Hey,

so as far as I can tell there was no reaction from -release (although I can
understand noone's really sure what to do here). Is it at least possible to
schedule binNMUs in stable for those affected packages so future installs
don't end up with bad permissions like these?

Regards,
-- 
Yves-Alexis



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

Re: Bug#814589: otrs2: source-less files; undocumented copyrights/licenses; abuse of lintian-overrides; systematic DFSG violations

2016-03-02 Thread Patrick Matthäi 



Am 15.02.2016 um 14:14 schrieb Dmitry Smirnov:

I am aware of those issues, that is
also why the embedded-code-copies bug is marked as "need help".

And this is why I provided some hints how you can address those problems in
my bug report. This is why I wrote to you after when I stabilised "ckeditor"
so you could use it.
I can use it, until ckeditor OR otrs upstreams broke it again, like with 
jquery.

Also it would prevent backports of otrs to jessie.


and mostly it is not possible to replace the
libjs thirdparty foo with the packages from Debian, mostly because of
version missmatches.

Hold on, you are answering the least important concern. There are cases when
replacing bundled library with system one could be fragile or not suitable.
But you can't ship and use untrusted pre-minified upstream files with who-
knows-what...


You reported a very general bug about the whole javascript mess. 
Replacing ckeditor will not solve the other problems or all those 
minified files and so on.






Nobody is willed (or in my case able) to fix those
JS issues, which appear here and then with different versions in
different places (ugly JS sh..).

At least I gave you "ckeditor" didn't I? That's one less problem to deal
with...


See above.




If everything is simple for you and just replacements have to be done
(which is not the case) then I would be happy to welcome you on the
otrs-packaging board.

It is simple enough. Although some system libraries should be safe to use you
do not have to use only system libraries. But you have to get rid of non-DFSG
precompiled binaries.
I appreciate your invitation but unfortunately I have no time for otrs.


IMO minified files are not as evil as the embedded libs, which should be 
addressed first.






Just a short example:
With 5.0.1-2 I had to drop (and inform the security team) about removing
again the use of the libjs-jquery* packages from Debian, because of #802938

I agree that using "libjs-jquery-ui" package of different version than
bundled one is fragile.
Though with "libjs-jquery" you'd probably be safe as long as you do not cross
1.9.0 boundary. However you must not use pre-minified "jquery-ui.js" as it is
shipped in orig.tar. As very minimum you have to replace it with original
uncompressed version that you have to ship in "debian/missing-sources" and
ideally report pre-built binaries as bug to upstream. If you believe in
minification then you can minify on build time. You can not trust source-
less, unreadable, unmodifiable pre-built binaries. I suppose lintian already
warned you long before I did.

I wrote the following wiki page that I use when I make upstream bug reports
about minified binaries -- I hope you might find it useful:

 https://wiki.debian.org/onlyjob/no-minification



Investing work in removing those files will not realy help and just 
burden the whole packaging and eat time to fix realy serious issues - 
like embedded libs.


@Debian release team:
I would like to request a strech ignore for this bug. I am aware of 
these problems, but I am not able to fix them nor did anyone ever 
offered me help with this JS foo. If it would not be possible I had to 
resign otrs packaging in Debian.


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Re: [Decision] Kernel version for stretch

2016-03-02 Thread Ben Hutchings 
I read this last week just before slipping into a fever in which I had
recurring dreams about the relations of unnameable abstract entities
that seemed later to correspond to software components.

On recovering from the flu, I was pleased to find that I hadn't
imagined that Niels Thykier wrote:
> Hi,
> 
> On the Release Team's IRC meeting today we concluded the following[1]:
> 
>  * We expect to release Stretch with the LTS release based on Linux 4.10
>  * We intend to delay the freeze (all milestone dates) by 2 months to
>    accommodate the above.
>    - Note that the expected release date of Linux 4.10 will then fall
>  between the "new" freeze and the "deep" freeze.

Thank you very much for accommodating this request!

>  * The linux 4.10 release will be entitled to a freeze exception if it
>    misses "deep freeze" by 5th of Feb.
>    - This exception only applies to linux.
>  * We would like to encourage the Linux kernel maintainers to upload
>    release candidates of Linux 4.10 in sid.
>    - The sooner we can spot regressions/problems in reverse
>  dependencies, the better.

Given the recent changes in linux packaging made to support easy
derivation of source packages such as linux-grsec, it should be easy to
upload a temporary linux-4.10 source package in parallel with linux.

This would allow rollback from 4.10 to 4.9 simply by changing which
version the linux-latest package refers to - no fake version or epoch
would be needed to make the 4.9 packages look newer.

> This decision is based on assumptions about the current release schedule
> of the Linux kernel.  Should the expected release date for the LTS
> change considerably, we may have to revise the decision.
[...]

And of course I'll let you know if the kernel release cycle deviates
significantly from expected.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

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

Bug#816499: nmu: votca-csg_1.2.4-2.1

2016-03-02 Thread Andreas Beckmann 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu votca-csg_1.2.4-2.1 . ANY . unstable . -m "Rebuild against votca-tools 
1.3.0"

The last votca-tools upload started an (uncoordinated) mini-transition from
libvotca-tools2 to libvotca-tools3, only votca-csg is affected by this.
The new votca-tools is already in testing.


Andreas

Opinion about linux-grsec in a stable release

2016-03-02 Thread Yves-Alexis Perez 
Hi teams,

[first of all, I'm writing this with my linux-grsec hat, not my Debian
security team member hat, obviously]

As you may know, src:linux-grsec was accepted in unstable earlier this year.
As a quick summary, this is a source linux package (forked from and
periodically rebased against src:linux) which generates a linux kernel with
the grsecurity hardening patch (the patch is mostly about fighting memory
corruptions bugs, but not only, I won't enter into details here to keep it
short, but more information can be found in the ITP bug #605090).

When the package was accepted to unstable, I filed #810506 with severity
serious in order to prevent it to migrate to testing, because I wasn't really
sure it'd be fit for stable.

There are two main aspects for this:

- it's a new Linux kernel source package, next to the existing src:linux, so
that means code duplication
- due to the grsecurity release model, it's likely that it won't be possible
to stick with a major kernel version (4.3 right now, 4.4 upcoming), we would
have to upgrade to the latest major release (using stable uploads)

Even with this caveat, it seems that there is still interest from people
(including me) to have src:linux-grsec included in a stable release. I asked
the backport team about this [1], and they were not thrilled about this
because backports are for packages to be included in the next Debian release
(although the discussion isn't really over at that point).

So I'm asking the security team and release team their opinion about this, in
order to have a somehow formal answer which can get archived here.

Do you think it'd be possible to have src:linux-grsec included in Stretch,
with the two main points above?

The answer doesn't need to be right now, in case you'd prefer seeing how
things evolve in unstable for some time.

Thank in advance,

[1] https://lists.debian.org/debian-backports/2016/01/msg00027.html
-- 
Yves-Alexis



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

Bug#815720: transition: python3.5-only

2016-03-02 Thread Emilio Pozuelo Monfort 
On 02/03/16 08:19, Simon McVittie wrote:
> On Wed, 24 Feb 2016 at 01:49:08 +0100, Matthias Klose wrote:
>> python3-defaults now no longer depends on python3.4, making python3.5 the
>> only supported python3 version.  python3.4 should be removed before stretch
>> is released (mostly by binNMUing, and then removing python3.4).
> 
> Packages that build for a single version of Python, and were last uploaded
> when 3.4 was default, are currently broken. This mostly means applications
> rather than libraries.
> 
> The specific example I'm aware of is that onboard depends on python3-dbus,
> onboard runs under python3.4, and recent uploads of python3-dbus don't
> build libraries for python3.4 any more (because it was removed from the
> list of supported versions just over a week ago) so onboard fails to
> import dbus. 
> 
> Was there meant to be a round of binNMUs before removing the old supported
> version? I would have assumed that the transition would go like this:
> 
> * make python3.5 the default
> * binNMU everything that depends on python3.4 but not python3.5
>   (e.g. onboard on all architectures except sh4,
>   )
> * remove python3.4 as supported
> * (eventually) binNMU everything that depends on python3.4, libpython3.4
>   or python (>= 3.4)

That is what happened. See #810136.

> Or is there something wrong in onboard's dependencies such that it was
> missed in a previous round of binNMUs? Perhaps it should have received
> a python (>= 3.4), python (<< 3.5) dependency which would have
> resulted in it being detected as uninstallable and binNMU'd?

Looks like this package was binNMUed when python3.5 was added a as a supported
version, but not when it was made the default:

Changes:
 onboard (1.1.2-1+b1) sid; urgency=low, binary-only=yes
 .
   * Binary-only non-maintainer upload for i386; no source changes.
   * Rebuild with python3.5 as a supported python3.

https://buildd.debian.org/status/fetch.php?pkg=onboard=i386=1.1.2-1%2Bb1=1443334431

Probably because the python3.5 tracker had:

is_affected = .depends ~ /python3 \(<

Bug#813916: Retry gdal (2.0.2+dfsg-1) on mips64el

2016-03-02 Thread Emilio Pozuelo Monfort 
On 02/03/16 08:53, Bas Couwenberg wrote:
> Dear wanna-build team,
> 
> gdal (2.0.2+dfsg-1) FTBFS on mips64el due to a compiler segfault:
> 
>  In file included from /usr/include/c++/5/vector:69:0,
>   from sdk/pcidsk_segment.h:34,
>   from sdk/pcidsk_file.h:30,
>   from sdk/pcidsk.h:39,
>   from sdk/segment/vecsegheader.cpp:32:
>  /usr/include/c++/5/bits/vector.tcc: In member function 'void std::vector<_Tp,
> _Alloc>::_M_insert_aux(std::vector<_Tp, _Alloc>::iterator, const _Tp&) [with 
> _Tp
> = PCIDSK::ShapeField; _Alloc =  std::allocator;
> std::vector<_Tp, _Alloc>::iterator =
> __gnu_cxx::__normal_iterator std::vector >; typename
> std::_Vector_base<_Tp,_Alloc>::pointer = PCIDSK::ShapeField*]':
>  /usr/include/c++/5/bits/vector.tcc:401:5: internal compiler error: 
> Segmentation
> fault
>   }
>   ^
>  0x1207741f3 crash_signal
>  ../../src/gcc/toplev.c:383
>  0x1203daa59 df_note_bb_compute
>  ../../src/gcc/df-problems.c:3157
>  0x1203daa59 df_note_compute
>  ../../src/gcc/df-problems.c:3287
>  0x1203d31bf df_analyze_problem(dataflow*, bitmap_head*, int*, int)
>  ../../src/gcc/df-core.c:1205
>  0x1203d330f df_analyze_1
>  ../../src/gcc/df-core.c:1265
>  0x120b18c93 rest_of_handle_combine
>  ../../src/gcc/combine.c:14202
>  0x120b18c93 execute
>  ../../src/gcc/combine.c:14251
>  Please submit a full bug report,
>  with preprocessed source if appropriate.
> 
> https://buildd.debian.org/status/fetch.php?pkg=gdal=mips64el=2.0.2%2Bdfsg-1=1456888746
> 
> 
> Can the build be retried with a give-back?
> 
>  gb gdal . mips64el . -m "Retry build"
> 
> The gdal (2.0.2+dfsg-1~exp1) & gdal (2.0.2+dfsg-1~exp2) in experimental
> succeeded on mips64el after initial failures too, see:
> 
> https://buildd.debian.org/status/logs.php?pkg=gdal=mips64el

Given back.

Emilio