Bug#841863: transition: nvidia-cuda-toolkit

2016-10-23 Thread Emilio Pozuelo Monfort 
On 23/10/16 23:54, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> NVIDIA released the CUDA toolkit 8.0 earlier this month. I'd like to see
> this version in the non-free part of stretch.
> This will bump the SOVERSION of all the libraries from 7.5 to 8.0.
> New packages targetting experimental are currently sitting in NEW.
> The transition has been done for Ubuntu 16.10 right before its release,
> therefore I do not expect problems rebuilding the reverse dependencies.
> They will need maintainer uploads (or manual binNMUs) anyway, since it
> involves B-D from non-free. I'll take care of NMUs if needed.
> 
> Rdepends as I remember them (coccia is currently missing dak due to the
> ongoing ftp-master move):
> 
> eztrace-contrib
> hwloc-contrib
> starpu-contrib
> pycuda

Do they build fine with CUDA 8.0?

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

No need for that indeed, thanks to the auto-transitioner.

Cheers,
Emilio

Bug#841863: transition: nvidia-cuda-toolkit

2016-10-23 Thread Andreas Beckmann 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

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

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

eztrace-contrib
hwloc-contrib
starpu-contrib
pycuda

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


Andreas

Bug#841203: marked as done (nmu: flex_2.6.1-1)

2016-10-23 Thread Debian Bug Tracking System 
Your message dated Sun, 23 Oct 2016 22:45:55 +0300
with message-id <20161023194555.re6fd7wrrpbxu...@bunk.spdns.de>
and subject line libfl_pic.a needs more than a binNMU
has caused the Debian Bug report #841203,
regarding nmu: flex_2.6.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.)


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

nmu flex_2.6.1-1 . ANY . unstable . -m "rebuild with default fPIC flag  (cfr: 
#837658)"


please add an additional build dependency on gcc6_6.2.0-7 to be sure it picks up
the flags, thanks!

G.
--- End Message ---
--- Begin Message ---
Control: retitle 837658 libfl_pic.a is not compiled with -fPIC

#837658 is different from many other PIE issues:

This is a _pic.a library that includes the non-PIC objects instead of 
the PIC objects it should contain.

A binNMU with -fPIE would not fix the root cause that this library is 
supposed to contain PIC code.

See the flex README.Debian for background.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed--- End Message ---

Processed: nmu: kannel-dev_1.4.4-3

2016-10-23 Thread Debian Bug Tracking System 
Processing control commands:

> block 837663 by -1
Bug #837663 [kannel-dev] kannel-dev: Please build libgwlib.a with -fPIC
837663 was not blocked by any bugs.
837663 was not blocking any bugs.
Added blocking bug(s) of 837663: 841839

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

Bug#841839: nmu: kannel-dev_1.4.4-3

2016-10-23 Thread Adrian Bunk 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 837663 by -1

nmu kannel-dev_1.4.4-3 . ANY . unstable . -m "MySQL 5.7 recompile (removes 
-lmysqlclient_r from "gw-config --libs")"

Please close #837663 when the binNMUs are in the archive.

Bug#841767: jessie-pu: package ebook-speaker/2.8.1-1

2016-10-23 Thread Adam D. Barratt 
Control: tags -1 + confirmed

On Sun, 2016-10-23 at 19:45 +0200, Samuel Thibault wrote:
> Control: tags -1 - confirmed
> 
> > On Sun, 2016-10-23 at 15:10 +0200, Samuel Thibault wrote:
> > > Hello,
> > > 
> > > Samuel Thibault, on Sun 23 Oct 2016 12:47:37 +0200, wrote:
> > > > As reported in #841714, a user couldn't use ebook-speaker to read a
> > > > .html file, because ebook-speaker was requesting the user to install
> > > > "the xml2 package" to be able to achieve this, and the user had it
> > > > installed already. ebook-speaker actually needed the html2text package.
> > > > In the changes proposed here, I just fixed the text of the hint (and
> > > > fixed the translations accordingly), is it OK for a Jessie upload?
> > > 
> > > I forgot to mention that this bug doesn't affect the Stretch version,
> > > which doesn't use html2text any more.
> > 
> > It does, however, still have a Suggests for the package and mention it
> > as being required in the readme.
> 
> Oh, that makes me realize that we should actually add the suggest in
> Jessie (and we can drop it from the Stretch version). So that'd add the
> attached change, is it OK?

Sure (as the Suggests has no practical impact on dependency chains
etc.).

Regards,

Adam

Processed: Re: Bug#841767: jessie-pu: package ebook-speaker/2.8.1-1

2016-10-23 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 + confirmed
Bug #841767 [release.debian.org] jessie-pu: package ebook-speaker/2.8.1-1
Added tag(s) confirmed.

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

Processed: Re: Bug#841767: jessie-pu: package ebook-speaker/2.8.1-1

2016-10-23 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 - confirmed
Bug #841767 [release.debian.org] jessie-pu: package ebook-speaker/2.8.1-1
Removed tag(s) confirmed.

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

Bug#841767: jessie-pu: package ebook-speaker/2.8.1-1

2016-10-23 Thread Samuel Thibault 
Control: tags -1 - confirmed

> On Sun, 2016-10-23 at 15:10 +0200, Samuel Thibault wrote:
> > Hello,
> > 
> > Samuel Thibault, on Sun 23 Oct 2016 12:47:37 +0200, wrote:
> > > As reported in #841714, a user couldn't use ebook-speaker to read a
> > > .html file, because ebook-speaker was requesting the user to install
> > > "the xml2 package" to be able to achieve this, and the user had it
> > > installed already. ebook-speaker actually needed the html2text package.
> > > In the changes proposed here, I just fixed the text of the hint (and
> > > fixed the translations accordingly), is it OK for a Jessie upload?
> > 
> > I forgot to mention that this bug doesn't affect the Stretch version,
> > which doesn't use html2text any more.
> 
> It does, however, still have a Suggests for the package and mention it
> as being required in the readme.

Oh, that makes me realize that we should actually add the suggest in
Jessie (and we can drop it from the Stretch version). So that'd add the
attached change, is it OK?

Samuel
diff --git a/debian/control b/debian/control
index c4cdf53..e2e1045 100644
--- a/debian/control
+++ b/debian/control
@@ -32,6 +32,7 @@ Depends: espeak,
  ${shlibs:Depends}
 Suggests: calibre,
   ghostscript,
+  html2text,
   libreoffice-writer,
   man2html-base,
   tesseract-ocr,

Processed: Re: Bug#841767: jessie-pu: package ebook-speaker/2.8.1-1

2016-10-23 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 + confirmed
Bug #841767 [release.debian.org] jessie-pu: package ebook-speaker/2.8.1-1
Added tag(s) confirmed.

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

Bug#841767: jessie-pu: package ebook-speaker/2.8.1-1

2016-10-23 Thread Adam D. Barratt 
Control: tags -1 + confirmed

On Sun, 2016-10-23 at 15:10 +0200, Samuel Thibault wrote:
> Hello,
> 
> Samuel Thibault, on Sun 23 Oct 2016 12:47:37 +0200, wrote:
> > As reported in #841714, a user couldn't use ebook-speaker to read a
> > .html file, because ebook-speaker was requesting the user to install
> > "the xml2 package" to be able to achieve this, and the user had it
> > installed already. ebook-speaker actually needed the html2text package.
> > In the changes proposed here, I just fixed the text of the hint (and
> > fixed the translations accordingly), is it OK for a Jessie upload?
> 
> I forgot to mention that this bug doesn't affect the Stretch version,
> which doesn't use html2text any more.

It does, however, still have a Suggests for the package and mention it
as being required in the readme.

Please go ahead.

Regards,

Adam

Bug#840851: [Debian-science-sagemath] fpylll: dependency or dependencee of Sage ?: fplll 5.0.3

2016-10-23 Thread Ximin Luo 
Gianfranco  told me that he uploaded sollya 6 already (built 
against 5.0.2), so we will have to binNMU the amd64 build of it again after 
5.0.3 is processed. (The ftp queue is stuck atm because the host machine is 
being moved.)

X

Ximin Luo:
> I've just uploaded fplll 5.0.3 to unstable. This includes some fixes that 
> would help us package SageMath, which we think we have a good chance of 
> completing in time for stretch.
> 
> I hope this is OK for the release team, I just wanted to save some 
> round-trips. Jerome who, maintains both reverse dependencies, has already 
> prepared releases that work against this new version 5.0.3.
> 
> X
> 
> Jerome BENOIT:
>> Hi,
>>
>> On 20/10/16 03:57, Tobias Hansen wrote:
>>> As I just said in the last mail, let's upload fplll 5.0.3 first.
>>
>> Ok. Sorry, I thought it was more important to have them both in Sid first.
>>
>> Can you upload fplll 5.0.3 soon  ?
>>
>> Thanks,
>> Jerome
>>
>>
>>> Best,
>>> Tobias
>>
>>> On 10/20/2016 03:54 AM, Jerome BENOIT wrote:


 On 19/10/16 20:41, Tobias Hansen wrote:
> Jerome, could you make shure gap-float and sollya work with fplll 5.0.3?

 I have just checked, they work well.

 I am on my way to upload them to Sid.

 Jerome


> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Re: Static libraries - PIC or PIE?

2016-10-23 Thread Adrian Bunk 
On Sun, Oct 23, 2016 at 03:17:06PM +0200, Bálint Réczey wrote:
> Hi Adrian,
> 
> 2016-10-23 13:26 GMT+02:00 Adrian Bunk :
> > On Sun, Oct 23, 2016 at 12:29:42PM +0200, Bálint Réczey wrote:
> >> Hi Ardian,
> >
> > Hi Bláint, ;-)
> 
> I'm sorry. :-)

No problem. :-)

>...
> >> This in many cases also simplify debian/rules.
> >
> > No, it would actually make building static libraries a real pain.
> 
> Could you please show an example?
> I went trough many packages and adding -fPIC was really
> straight-forward every time. OTOH packages providing both
> shared and static libraries build some parts twice like in antlr's
> case:

Usually building everything twice is done by the build system of the 
package, and debian/rules just calls $(MAKE)

> build-stamp:
> dh_testdir
> uudecode -o debian/antlr.snk debian/antlr.snk.uue
> $(MAKE) -f debian/Makefile.debian compile build_antlr
> $(MAKE) -C lib/cpp CXXFLAGS="+ -fPIC -DPIC"
> mv -f lib/cpp/src/libantlr.a debian/libantlr-pic.a
> $(MAKE) -C lib/cpp clean
> $(MAKE) -C lib/cpp
> touch build-stamp

That's a good example why this is a real pain.

You really don't want to force maintainers to dissect the build of their 
packages, especially in the normal case where just calling $(MAKE) was
working without your proposed requirement.

Just passing normal CFLAGS from dpkg-buildflags through the package 
build to the compiler is still not working in a huge number of packages 
after years, and this would be worse by several orders of magnitude.

> > Think of a normal source package building shared libraries,
> > static libraries and some programs.
> >
> > How do you want to tell the build system of the package that it should
> > build the static libraries with -fPIC, but not the programs?
> 
> It is usually already done by upstream or at least in packaging
> since we require -fPIC for shared libs.

You are completely wrong on that.

-fPIC is required and used for shared libraries.
Static libraries compiled with -fPIC are *very* rare.

Compiling with -fPIC for the shared library and without -fPIC for the 
static library is the one and (usually) only reason why all objects
are compiled twice when building libraries.

>...
> I assume non-PIC static library used in a PIC shared library is the
> specific case mentioned in the original text, which still does not
> work on any architecture.

Why do you want to forvce maintainers to go through great pain to get 
that working?

It is usually a bug when you end up linking a static library into a 
shared library, and in addition to a performance penalty you would
lose the benefit of getting a build failure for such bugs.

There are some rare cases of packages not building shared libraries. 
There might be other exotic situations where linking a static library 
into a shared library makes sense.
Requiring discussion of these on a case-by-case basis on debian-devel
as policy requires sounds pretty appropriate to me.

> >> > My current understanding is that a binNMU would recompile the the static
> >> > library with PIE (not PIC), and that this is sufficient.
> >>
> >> In most of the cases this would be sufficient, but at the time I filed the
> >> bugs the default was -no-pie, thus it was not an option.
> >
> > It is clear that the binNMUs have to happen after the change.
> 
> Yes, it was expected, but I think the changes would still be
> useful on architectures not enabling PIE because they allow
> enabling pie in reverse dependencies selectively.

Is there actually a good reason why PIE was only enabled on the release
architectures?

In any case, this would not provide any kind of reason for requiring 
to build static libraries with PIC.

>...
> Cheers,
> Balint

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#840851: [Debian-science-sagemath] fpylll: dependency or dependencee of Sage ?: fplll 5.0.3

2016-10-23 Thread Ximin Luo 
I've just uploaded fplll 5.0.3 to unstable. This includes some fixes that would 
help us package SageMath, which we think we have a good chance of completing in 
time for stretch.

I hope this is OK for the release team, I just wanted to save some round-trips. 
Jerome who, maintains both reverse dependencies, has already prepared releases 
that work against this new version 5.0.3.

X

Jerome BENOIT:
> Hi,
> 
> On 20/10/16 03:57, Tobias Hansen wrote:
>> As I just said in the last mail, let's upload fplll 5.0.3 first.
> 
> Ok. Sorry, I thought it was more important to have them both in Sid first.
> 
> Can you upload fplll 5.0.3 soon  ?
> 
> Thanks,
> Jerome
> 
> 
>> Best,
>> Tobias
> 
>> On 10/20/2016 03:54 AM, Jerome BENOIT wrote:
>>>
>>>
>>> On 19/10/16 20:41, Tobias Hansen wrote:
 Jerome, could you make shure gap-float and sollya work with fplll 5.0.3?
>>>
>>> I have just checked, they work well.
>>>
>>> I am on my way to upload them to Sid.
>>>
>>> Jerome
>>>
>>>

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Re: Static libraries - PIC or PIE?

2016-10-23 Thread Bálint Réczey 
Hi Adrian,

2016-10-23 13:26 GMT+02:00 Adrian Bunk :
> On Sun, Oct 23, 2016 at 12:29:42PM +0200, Bálint Réczey wrote:
>> Hi Ardian,
>
> Hi Bláint, ;-)

I'm sorry. :-)

>
>> 2016-10-23 10:18 GMT+02:00 Adrian Bunk :
>> > Hi Bálint,
>> >
>> > there is some confusion regarding how static libraries should be
>> > compiled now.
>> >
>> > Your bugs (e.g. #837350) say "Please build libfoo.a with -fPIC".
>> >
>> > Why do these say -fPIC and not -fPIE?
>>
>> I suggest using -fPIC, because then the shared libraries would be
>> usable in shared (PIC) libraries libraries, too.
>
> you have created a lot of confusion by mixing two separate issues.

I'm sorry for creating confusion, I had absolutely no intent to cause
any. As you can see I attempted discussing every change, while in
many cases I got no response.

We also discussed the tradeoffs of using PIE or PIC in debian-devel.

>
> One of the worst examples:
> #837658 libfl-dev: Please build libfl_pic.a with -fPIC
> #841203 nmu: flex_2.6.1-1

I did not file the second one.

>
> A _pic.a library compiled without -fPIC sounds like a clear bug,
> and a binNMU that will recompile it with -fPIE won't fix that bug.

This was the single case I found with non-PIC _pic-postfixed static
library thus I see this something unique, rather than an example
of many bad cases. Recompiling would fix the FTBFS but not the
misleading prefix, indeed.

I also hoped getting response from the maintainer.

>
>> This in many cases also simplify debian/rules.
>
> No, it would actually make building static libraries a real pain.

Could you please show an example?
I went trough many packages and adding -fPIC was really
straight-forward every time. OTOH packages providing both
shared and static libraries build some parts twice like in antlr's
case:

build-stamp:
dh_testdir
uudecode -o debian/antlr.snk debian/antlr.snk.uue
$(MAKE) -f debian/Makefile.debian compile build_antlr
$(MAKE) -C lib/cpp CXXFLAGS="+ -fPIC -DPIC"
mv -f lib/cpp/src/libantlr.a debian/libantlr-pic.a
$(MAKE) -C lib/cpp clean
$(MAKE) -C lib/cpp
touch build-stamp


>
> Think of a normal source package building shared libraries,
> static libraries and some programs.
>
> How do you want to tell the build system of the package that it should
> build the static libraries with -fPIC, but not the programs?

It is usually already done by upstream or at least in packaging
since we require -fPIC for shared libs.

>
>> I also suggested changing the policy #837478.
>
> Unless I misunderstand something, current policy is perfectly fine
> for the PIE change, and your claims in #837478 that building static
> libraries with -fPIC would be required for PIE binaries are not
> correct.

True, I stated more than I intended to. This was my original wording:
...
> ---
> 10.2 Libraries
> ... (paragraph about shared libs)
> 
> As to the static libraries, the common case is not to have relocatable
> code, since there is no benefit, unless in specific cases; therefore the
> static version must not be compiled with the -fPIC flag. Any exception
> to this rule should be discussed on the mailing list
> debian-de...@lists.debian.org, and the reasons for compiling with the
> -fPIC flag must be recorded in the file README.Debian. [86]
> 
> In other words, if both a shared and a static library is being built,
> each source unit (*.c, for example, for C files) will need to be
> compiled twice, for the normal case.
> 
> ---
> 
> I think with the spreading of PIE binaries the "... since there is no
> benefit ..." claim does not stand anymore. Non-PIC static libraries
> can't be linked to PIE binaries thus they are less useful for code
> sharing among packages.
> 
> There is also a plan to use a specially configured GCC on several
> architectures which builds PIE binaries by default and that needs PIC
> static libraries for not statically linked binaries. [1]
...

Let me correct myself then:
...
I think with the spreading of PIE binaries the "... since there is no
benefit ..." claim does not stand anymore. Static binaries built
without either of PIC or PIE flags can't be linked to PIE binaries
nor to (PIC) shared libraries thus they are less useful for code
sharing among packages.

GCC is configured to build PIE binaries by default [1] on most
architectures and on those architectures static libraries are built
with PIE enabled. On the rest of the architectures static libraries are
still built without PIE thus the problem described in the previous
paragraph still stands.

I assume non-PIC static library used in a PIC shared library is the
specific case mentioned in the original text, which still does not
work on any architecture.

...

>
>> > My current understanding is that a binNMU would recompile the the static
>> > library with PIE (not PIC), and that this is sufficient.
>>
>> In most of the cases this would be sufficient, but at the time I filed the
>> bugs the default was -no-pie, thus it was not

Bug#841767: jessie-pu: package ebook-speaker/2.8.1-1

2016-10-23 Thread Samuel Thibault 
Hello,

Samuel Thibault, on Sun 23 Oct 2016 12:47:37 +0200, wrote:
> As reported in #841714, a user couldn't use ebook-speaker to read a
> .html file, because ebook-speaker was requesting the user to install
> "the xml2 package" to be able to achieve this, and the user had it
> installed already. ebook-speaker actually needed the html2text package.
> In the changes proposed here, I just fixed the text of the hint (and
> fixed the translations accordingly), is it OK for a Jessie upload?

I forgot to mention that this bug doesn't affect the Stretch version,
which doesn't use html2text any more.

Samuel

Bug#830538: marked as done (RM: ruby-bdb/0.6.6-2)

2016-10-23 Thread Debian Bug Tracking System 
Your message dated Sun, 23 Oct 2016 16:10:55 +0300
with message-id <20161023131055.fkzlivdx74uew...@bunk.spdns.de>
and subject line ruby-bdb was removed from testing more than 2 months ago
has caused the Debian Bug report #830538,
regarding RM: ruby-bdb/0.6.6-2
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.)


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

Dear Release Team,

please remove ruby-bdb from testing. It's a maintenance burden
and as such should go. There's an open RC bug against it, but
autoremoval is not picking it up so far.

Thanks,
Chris
--- End Message ---
--- Begin Message ---
ruby-bdb was removed from testing more than 2 months ago.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed--- End Message ---

Bug#840426: marked as done (jessie-pu: package asterisk/1:11.13.1~dfsg-2+b1)

2016-10-23 Thread Debian Bug Tracking System 
Your message dated Sun, 23 Oct 2016 13:19:02 +0100
with message-id <1477225142.32722.31.ca...@adam-barratt.org.uk>
and subject line Re: Bug#840426: jessie-pu: package asterisk/1:11.13.1~dfsg-2+b1
has caused the Debian Bug report #840426,
regarding jessie-pu: package asterisk/1:11.13.1~dfsg-2+b1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


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

Hi,

I have asked the security team whether we could piggyback a fix for 
Bug#776080 on the upcoming DSA for Asterisk. They are fine with it
as long as a stable release manager acks it.

The patch will be this one

https://anonscm.debian.org/cgit/pkg-voip/asterisk.git/commit/?h=jessie=9f8ffeafcb27ecf602bd2c937c11391f50f166a7

(also attached). Please don't mind the jessie branch in git, it does
not reflect the changes that will be in the security upload.

You may just close the bug with ACK or NACK. In the first case I will
include the fix into the debdiff sent to the security team, in the
second case I won't and might come back for the next point release.

Thanks,
Bernhard
>From 9f8ffeafcb27ecf602bd2c937c11391f50f166a7 Mon Sep 17 00:00:00 2001
From: Tzafrir Cohen 
Date: Fri, 30 Jan 2015 00:05:28 +0200
Subject: Add a placeholder conf in manager.c (#776080)

Our custom manager.conf was invalid as there was no manager.d/*.conf .

As of roughly 1.6.0 Asterisk started considering includes of
non-existing files as configuration error rather than ignoring them.
---
 debian/ast_config/manager.d/README.conf | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 debian/ast_config/manager.d/README.conf

diff --git a/debian/ast_config/manager.d/README.conf b/debian/ast_config/manager.d/README.conf
new file mode 100644
index 000..a8173aa
--- /dev/null
+++ b/debian/ast_config/manager.d/README.conf
@@ -0,0 +1,3 @@
+; Empty placeholder by the Debian packaging.
+; You can add manager users by dropping files with a .conf extension in
+; this directory.
-- 
cgit v0.12

--- End Message ---
--- Begin Message ---
On Tue, 2016-10-11 at 15:44 +0200, Bernhard Schmidt wrote:
> I have asked the security team whether we could piggyback a fix for 
> Bug#776080 on the upcoming DSA for Asterisk. They are fine with it
> as long as a stable release manager acks it.
> 
> The patch will be this one
> 
> https://anonscm.debian.org/cgit/pkg-voip/asterisk.git/commit/?h=jessie=9f8ffeafcb27ecf602bd2c937c11391f50f166a7
> 
> (also attached). Please don't mind the jessie branch in git, it does
> not reflect the changes that will be in the security upload.

That looks fine.

Regards,

Adam--- End Message ---

Re: Static libraries - PIC or PIE?

2016-10-23 Thread Adrian Bunk 
On Sun, Oct 23, 2016 at 12:29:42PM +0200, Bálint Réczey wrote:
> Hi Ardian,

Hi Bláint, ;-)

> 2016-10-23 10:18 GMT+02:00 Adrian Bunk :
> > Hi Bálint,
> >
> > there is some confusion regarding how static libraries should be
> > compiled now.
> >
> > Your bugs (e.g. #837350) say "Please build libfoo.a with -fPIC".
> >
> > Why do these say -fPIC and not -fPIE?
> 
> I suggest using -fPIC, because then the shared libraries would be
> usable in shared (PIC) libraries libraries, too.

you have created a lot of confusion by mixing two separate issues.

One of the worst examples:
#837658 libfl-dev: Please build libfl_pic.a with -fPIC
#841203 nmu: flex_2.6.1-1

A _pic.a library compiled without -fPIC sounds like a clear bug,
and a binNMU that will recompile it with -fPIE won't fix that bug.

> This in many cases also simplify debian/rules.

No, it would actually make building static libraries a real pain.

Think of a normal source package building shared libraries,
static libraries and some programs.

How do you want to tell the build system of the package that it should 
build the static libraries with -fPIC, but not the programs?

> I also suggested changing the policy #837478.

Unless I misunderstand something, current policy is perfectly fine
for the PIE change, and your claims in #837478 that building static 
libraries with -fPIC would be required for PIE binaries are not
correct.

> > My current understanding is that a binNMU would recompile the the static
> > library with PIE (not PIC), and that this is sufficient.
> 
> In most of the cases this would be sufficient, but at the time I filed the
> bugs the default was -no-pie, thus it was not an option.

It is clear that the binNMUs have to happen after the change.

It would have created less confusion to not file bugs in cases where no 
maintainer action is required, ask the release team to schedule binNMUs 
for the static libraries known to need them immediately after the 
compiler change, and announce on debian-devel-announce that some 
transient build failures might be observed immediately after the 
compiler change until the binNMUs are done.

I'll sort out what binNMUs are required later today.

> I'm OK with performing binnmu-s and decreasing the severity of the 'solved'
> bugs to wishlist.

With the exception of special cases like #837658 a binNMU will 
completely solve it, and there is no point in having wishlist
bugs for something not really permitted by policy.

> Cheers,
> Balint

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Next d-i release

2016-10-23 Thread Samuel Thibault 
Hello,

Cyril Brulebois, on Wed 19 Oct 2016 15:33:03 +0200, wrote:
> Feel free to mention packages you want to see in testing,

We have the newer brltty release, 5.4, which provides support for some
more devices, and fixes various issues. It has been tested for some time
in experimental and sid now, so I feel quite safe about it, but it'd be
probably useful to have it for testing in d-i sooner than later.

Samuel

Bug#841767: jessie-pu: package ebook-speaker/2.8.1-1

2016-10-23 Thread Samuel Thibault 
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hello,

As reported in #841714, a user couldn't use ebook-speaker to read a
.html file, because ebook-speaker was requesting the user to install
"the xml2 package" to be able to achieve this, and the user had it
installed already. ebook-speaker actually needed the html2text package.
In the changes proposed here, I just fixed the text of the hint (and
fixed the translations accordingly), is it OK for a Jessie upload?

Thanks,
Samuel

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

Kernel: Linux 4.8.0 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index 5011a55..8e692d6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+ebook-speaker (2.8.1-1+deb8u1) jessie; urgency=medium
+
+  * Team upload.
+  * Fix hint about installing html2text to read html files
+(Closes: #841714).
+
+ -- Samuel Thibault   Sun, 23 Oct 2016 12:10:26 +0200
+
 ebook-speaker (2.8.1-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/patches/html2text b/debian/patches/html2text
new file mode 100644
index 000..4c70593
--- /dev/null
+++ b/debian/patches/html2text
@@ -0,0 +1,89 @@
+--- a/po/de.po
 b/po/de.po
+@@ -346,8 +346,8 @@ msgid "eBook-speaker needs the man2html
+ msgstr "eBook-speaker benödigt die man2html Paket."
+ 
+ #: src/eBook-speaker.c:2202
+-msgid "eBook-speaker needs the xml2 package."
+-msgstr "eBook-speaker benödigt die xml2 Paket."
++msgid "eBook-speaker needs the html2text package."
++msgstr "eBook-speaker benödigt die html2text Paket."
+ 
+ #: src/eBook-speaker.c:2257
+ msgid "eBook-speaker needs the calibre package."
+--- a/po/e...@boldquot.po
 b/po/e...@boldquot.po
+@@ -357,8 +357,8 @@ msgid "eBook-speaker needs the man2html
+ msgstr "eBook-speaker needs the man2html program."
+ 
+ #: src/eBook-speaker.c:2202
+-msgid "eBook-speaker needs the xml2 package."
+-msgstr "eBook-speaker needs the xml2 package."
++msgid "eBook-speaker needs the html2text package."
++msgstr "eBook-speaker needs the html2text package."
+ 
+ #: src/eBook-speaker.c:2257
+ msgid "eBook-speaker needs the calibre package."
+--- a/po/e...@quot.po
 b/po/e...@quot.po
+@@ -354,8 +354,8 @@ msgid "eBook-speaker needs the man2html
+ msgstr "eBook-speaker needs the man2html program."
+ 
+ #: src/eBook-speaker.c:2202
+-msgid "eBook-speaker needs the xml2 package."
+-msgstr "eBook-speaker needs the xml2 package."
++msgid "eBook-speaker needs the html2text package."
++msgstr "eBook-speaker needs the html2text package."
+ 
+ #: src/eBook-speaker.c:2257
+ msgid "eBook-speaker needs the calibre package."
+--- a/po/es.po
 b/po/es.po
+@@ -341,8 +341,8 @@ msgid "eBook-speaker needs the man2html
+ msgstr "eBook-speaker se necesita el man2html paquete."
+ 
+ #: src/eBook-speaker.c:2202
+-msgid "eBook-speaker needs the xml2 package."
+-msgstr "eBook-speaker se necesita el xml2 paquete."
++msgid "eBook-speaker needs the html2text package."
++msgstr "eBook-speaker se necesita el html2text paquete."
+ 
+ #: src/eBook-speaker.c:2257
+ msgid "eBook-speaker needs the calibre package."
+--- a/po/fr.po
 b/po/fr.po
+@@ -344,8 +344,8 @@ msgid "eBook-speaker needs the man2html
+ msgstr "eBook-speaker requiert le paquet man2html. "
+ 
+ #: src/eBook-speaker.c:2202
+-msgid "eBook-speaker needs the xml2 package."
+-msgstr "eBook-speaker requiert le paquet xml2. "
++msgid "eBook-speaker needs the html2text package."
++msgstr "eBook-speaker requiert le paquet html2text. "
+ 
+ #: src/eBook-speaker.c:2257
+ msgid "eBook-speaker needs the calibre package."
+--- a/po/nl.po
 b/po/nl.po
+@@ -331,8 +331,8 @@ msgid "eBook-speaker needs the man2html
+ msgstr "eBook-speaker heeft het man2html pakket nodig."
+ 
+ #: src/eBook-speaker.c:2202
+-msgid "eBook-speaker needs the xml2 package."
+-msgstr "eBook-speaker heeft het xml2 pakket nodig."
++msgid "eBook-speaker needs the html2text package."
++msgstr "eBook-speaker heeft het html2text pakket nodig."
+ 
+ #: src/eBook-speaker.c:2257
+ msgid "eBook-speaker needs the calibre package."
+--- a/src/eBook-speaker.c
 b/src/eBook-speaker.c
+@@ -2199,7 +2199,7 @@ BEGIN:
+   default:
+  endwin ();
+  beep ();
+- puts (gettext ("eBook-speaker needs the xml2 package."));
++ puts (gettext ("eBook-speaker needs the html2text package."));
+  fflush (stdout);
+  _exit (1);
+   } // switch
diff --git

Bug#841693: marked as done (nmu: digikam_4:5.2.0-1 and libkf5kgeomap_16.08.0-1)

2016-10-23 Thread Debian Bug Tracking System 
Your message dated Sun, 23 Oct 2016 12:59:30 +0200
with message-id 
and subject line Re: Bug#841693: nmu: digikam_4:5.2.0-1 and 
libkf5kgeomap_16.08.0-1
has caused the Debian Bug report #841693,
regarding nmu: digikam_4:5.2.0-1 and libkf5kgeomap_16.08.0-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


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

The new version of marble bumped it's libs soversion, requiring a rebuild of 
the packages that build depend on it's libs. Please trigger the following 
rebuilds.

nmu digikam_4:5.2.0-1 . ANY . unstable . -m "Rebuild against new marblewidget 
version (Closes: 840841)"
nmu libkf5kgeomap_16.08.0-1 . ANY . unstable . -m "Rebuild against new 
marblewidget version"

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
Hi Maxi,

On 22/10/16 14:40, Maximiliano Curia wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hi,
> 
> The new version of marble bumped it's libs soversion, requiring a rebuild of 
> the packages that build depend on it's libs. Please trigger the following 
> rebuilds.
> 
> nmu digikam_4:5.2.0-1 . ANY . unstable . -m "Rebuild against new marblewidget 
> version (Closes: 840841)"
> nmu libkf5kgeomap_16.08.0-1 . ANY . unstable . -m "Rebuild against new 
> marblewidget version"

Scheduled. Note that binNMUs can't close bugs, so you will have to close that
one manually.

Cheers,
Emilio--- End Message ---

Re: Static libraries - PIC or PIE?

2016-10-23 Thread Bálint Réczey 
Hi Ardian,

2016-10-23 10:18 GMT+02:00 Adrian Bunk :
> Hi Bálint,
>
> there is some confusion regarding how static libraries should be
> compiled now.
>
> Your bugs (e.g. #837350) say "Please build libfoo.a with -fPIC".
>
> Why do these say -fPIC and not -fPIE?

I suggest using -fPIC, because then the shared libraries would be
usable in shared (PIC) libraries libraries, too.

This in many cases also simplify debian/rules. I also suggested
changing the policy #837478.

>
> My current understanding is that a binNMU would recompile the the static
> library with PIE (not PIC), and that this is sufficient.

In most of the cases this would be sufficient, but at the time I filed the
bugs the default was -no-pie, thus it was not an option.

I'm OK with performing binnmu-s and decreasing the severity of the 'solved'
bugs to wishlist.

Cheers,
Balint

Bug#841504: transition: gammu

2016-10-23 Thread Emilio Pozuelo Monfort 
Control: tags -1 confirmed

On 22/10/16 21:23, Michal Čihař wrote:
> Hi
> 
> Emilio Pozuelo Monfort píše v So 22. 10. 2016 v 13:02 +0200:
>> On 21/10/16 10:54, Michal Čihař wrote:
>>>
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>>
>>> Hi
>>>
>>> I've uploaded new Gammu version to experimental and it increases
>>> soversion. I'd like to upload new version together with new python-
>>> gammu
>>> (the only reverse dependency) to unstable in few weeks (let's say
>>> first
>>> half of November). Is there anything blocking this?
>>
>> The transition freeze is the 5th of November... Can you do this
>> before then?
> 
> I can probably upload it tomorrow or on Monday as well (at least I
> don't see any blockers right now).

Sounds good.

Cheers,
Emilio

Processed: Re: Bug#841504: transition: gammu

2016-10-23 Thread Debian Bug Tracking System 
Processing control commands:

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

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

Static libraries - PIC or PIE?

2016-10-23 Thread Adrian Bunk 
Hi Bálint,

there is some confusion regarding how static libraries should be 
compiled now.

Your bugs (e.g. #837350) say "Please build libfoo.a with -fPIC".

Why do these say -fPIC and not -fPIE?

My current understanding is that a binNMU would recompile the the static 
library with PIE (not PIC), and that this is sufficient.

Thanks
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#841638: transition: libcrypto++

2016-10-23 Thread Julien Cristau 
On Sat, Oct 22, 2016 at 14:43:08 +0200, László Böszörményi wrote:

> Hi Emilio,
> 
> On Sat, Oct 22, 2016 at 1:06 PM, Emilio Pozuelo Monfort
>  wrote:
> > On 21/10/16 18:20, Laszlo Boszormenyi (GCS) wrote:
> >> I'd like to update libcrypto++ from 5.6.4 to 5.6.5; which is a
> >> semi-transition. Packages I've tried works with both version,
> >> however without binNMUs those will print this:
> >> Symbol `_ZTVN8CryptoPP23FilterWithBufferedInputE' has different size in 
> >> shared object, consider re-linking
> >> Symbol `_ZTVN8CryptoPP10HexEncoderE' has different size in shared object, 
> >> consider re-linking
> >> Symbol `_ZTVN8CryptoPP11ProxyFilterE' has different size in shared object, 
> >> consider re-linking
> >>
> >> This matches upstream recommendation[1]:
> >> "maintenance release, recompile of programs recommended"
> >
> > Does this bump the SONAME, or is it an ABI break without a SONAME bump?
>  No, the SONAME is the same. ABI should be the same, but I've found
> one (more may exist) case where one (probably internal) symbol can't
> be found anymore:
> Generating secure encryption key. This might take some time..done
> cryfs: symbol lookup error: cryfs: undefined symbol:
> _ZN8CryptoPP10RandomPool34GenerateIntoBufferedTransformationERNS_22BufferedTransformationERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEy
> 
If it causes programs built against the older version to no longer work,
then it's not internal, it is an ABI break and needs SONAME bump and
package name change.

Cheers,
Julien