Bug#842011: [debian-mysql] Bug#842011: Bug#842011: Bug#842011: default-mysql-client forces removal of mysql-server* and mysql-client*

[Clint Byrum]

Excerpts from Craig Sanders's message of 2016-10-26 15:22:27 +1100:
> On Wed, Oct 26, 2016 at 04:43:53AM +0200, Clint Byrum wrote:
> > > [ using /dev/tcp in bash ]
> >
> > That seems like a gross oversimplification of what works extremely well
> > today. mysqladmin actually understands mysql's protocol, and can verify
> > that it is up and fully functional. Listening doesn't mean responding,
> > or ready for clients.
> 
> wow. you spotted that a grossly simple substitute was a gross
> over-simplification. nobody can accuse you of being unobservant.
> 
> > One would hope mariadb's client package provides a similar thing, and
> > maybe we could just depend on the virtual package.
> 
> if mariadb's client can serve in place of mysql's then of course
> it makes sense to use whichever one is available.
> 
> 
> did you have anything actually useful - and preferably not completely
> obvious - to add, or are you just mouthing off because you can?

Thanks for reminding me that the internet is full of useless people.

Good luck getting help.

Bug#841850: linux-image-4.7.0-1-686_4.7.8-1_i386.deb does not boot on Thinkpad T41

[Salvatore Bonaccorso]

Hi Ben, hi Petra,

On Mon, Oct 24, 2016 at 02:35:07PM +0100, Ben Hutchings wrote:
> On Mon, 2016-10-24 at 11:49 +0200, Petra Ruebe-Pugliese wrote:
> [...]
> >  Okay.  So I've sacrificed the less important of the two
> >  notebooks again and repeated the "apt-get dist-upgrade"
> >  so that the current kernel got installed again.
> > 
> >  In doing so, two messages appeared that looked approximately
> >  like this:
> > 
> >   /etc/kernel-img.conf:4: ignoring unknown parameter relative_links
> >   /etc/kernel-img.conf:6: ignoring unknown parameter do_bootfloppy
> >
> >  The second of these lines reminds me of the fact that with
> >  previous kernel versions the boot process used to stop in the
> >  same place for quite some (disquieting!) time and then continued
> >  with some message about a read error on /dev/fd
> 
> I don't know what 'do_bootfloppy' used to do, but I think it's unrelated to 
> loading of the floppy driver.  It sounds like you have quite an old 
> installation that might also have some obsolete scripts left in the boot 
> process.  Also, note that the /dev/fd directory is unrelated to floppy drives.
> 
> >  This was the case on all my computers, although these two
> >  thinkpads no longer have a floppy drive.
> > 
> >  Now to the photo.  I've tried to make one.
> >  With these new boot parameters there is a lot of output rushing
> >  through which I could not catch.  So I'm sending only what was
> >  to be seen when it stopped.  Maybe that's enough to put you on
> >  the right track.  If not, please tell me what else I can do
> >  to bring some light into the matter.
> 
> OK, this is the same crash that someone else reported and I think I
> know which change triggered it (though not why).

There seem to be an upstream fix now for this issue:

https://git.kernel.org/linus/ff8560512b8d4b7ca3ef4fd69166634ac30b2525

Can you by chance confirm that this works as well for you?

Regards,
Salvatore

Bug#842127: ITP: node-spdx-license-ids -- A list of SPDX license identifiers

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-spdx-license-ids
  Version : 1.2.2
  Upstream Author : Shinnosuke Watanabe (https://github.com/shinnn)
* URL : https://github.com/shinnn/spdx-license-ids#readme
* License : Unlicense
  Programming Lang: JavaScript
  Description : A list of SPDX license identifiers. The SPDX License
List is a list of commonly found licenses and exceptions used for open
source and other collaborative software.

Bug#842126: taglib: Please fix symbols file for compatibility with -O3 optimization

[Steve Langasek]

Package: taglib
Version: 1.11.1-0.1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Hi Modestas,

The NMU of taglib 1.11.1 to unstable has included updates to the symbols
file.  The changes that were made are incompatible with building with -O3
optimization, as we do for the ppc64el port in Ubuntu.

The attached patch fixes this by marking a number of template symbols, which
are not part of taglib's ABI, as 'optional'.

This is not a complete list of all symbols which are possibly-optional
template instances, just those that need to be flagged as optional for
compatibility with -O3 on ppc64el.

Please consider applying this patch in Debian.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru taglib-1.11.1/debian/libtag1v5-vanilla.symbols taglib-1.11.1/debian/libtag1v5-vanilla.symbols
--- taglib-1.11.1/debian/libtag1v5-vanilla.symbols	2016-10-24 11:10:29.0 -0700
+++ taglib-1.11.1/debian/libtag1v5-vanilla.symbols	2016-10-25 22:19:37.0 -0700
@@ -2221,53 +2221,53 @@
  (arch-bits=64)_ZNSt6vectorIcSaIcEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPcS1_EEmRKc@Base 1.9.1-2.2~
  (arch-bits=32)_ZNSt6vectorIcSaIcEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPcS1_EEjRKc@Base 1.9.1-2.2~
  _ZNSt7__cxx1110_List_baseIN6TagLib10ByteVectorESaIS2_EE8_M_clearEv@Base 1.9.1-2.2~
- _ZNSt7__cxx1110_List_baseIN6TagLib3ASF9AttributeESaIS3_EE8_M_clearEv@Base 1.9.1-2.2~
- _ZNSt7__cxx1110_List_baseIN6TagLib3MP48CoverArtESaIS3_EE8_M_clearEv@Base 1.9.1-2.2~
- _ZNSt7__cxx1110_List_baseIN6TagLib5ID3v223SynchronizedLyricsFrame11SynchedTextESaIS4_EE8_M_clearEv@Base 1.11
+ (optional=templinst)_ZNSt7__cxx1110_List_baseIN6TagLib3ASF9AttributeESaIS3_EE8_M_clearEv@Base 1.9.1-2.2~
+ (optional=templinst)_ZNSt7__cxx1110_List_baseIN6TagLib3MP48CoverArtESaIS3_EE8_M_clearEv@Base 1.9.1-2.2~
+ (optional=templinst)_ZNSt7__cxx1110_List_baseIN6TagLib5ID3v223SynchronizedLyricsFrame11SynchedTextESaIS4_EE8_M_clearEv@Base 1.11
  _ZNSt7__cxx1110_List_baseIN6TagLib6StringESaIS2_EE8_M_clearEv@Base 1.9.1-2.2~
- _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPwEEvT_S7_St20forward_iterator_tag@Base 1.9.1-2.2~
- (arch=amd64 arm64 mips64el ppc64el kfreebsd-amd64 sparc64 hppa m68k x32)_ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE11equal_rangeERS2_@Base 1.11
+ (optional=templinst)_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructIPwEEvT_S7_St20forward_iterator_tag@Base 1.9.1-2.2~
+ (optional=templinst)_ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE11equal_rangeERS2_@Base 1.11
  _ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE22_M_emplace_hint_uniqueIJRKSt21piecewise_construct_tSt5tupleIJRS2_EESH_IJESt17_Rb_tree_iteratorIS6_ESt23_Rb_tree_const_iteratorIS6_EDpOT_@Base 1.9.1-2.2~
- _ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE24_M_get_insert_unique_posERS2_@Base 1.9.1-2.2~
- (arch=amd64 arm64 mips64el ppc64el kfreebsd-amd64 sparc64 hppa m68k x32)_ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS6_ERS2_@Base 1.9.1-2.2~
- _ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE4findERS2_@Base 1.9.1-2.2~
+ (optional=templinst)_ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE24_M_get_insert_unique_posERS2_@Base 1.9.1-2.2~
+ (optional=templinst)_ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS6_ERS2_@Base 1.9.1-2.2~
+ (optional=templinst)_ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE4findERS2_@Base 1.9.1-2.2~
  _ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE7_M_copyINSC_11_Alloc_nodeEEEPSt13_Rb_tree_nodeIS6_EPKSG_PSt18_Rb_tree_node_baseRT_@Base 1.9.1-2.2~
  _ZNSt8_Rb_treeIKN6TagLib6StringESt4pairIS2_NS0_3APE4ItemEESt10_Select1stIS6_ESt4lessIS2_ESaIS6_EE8_M_eraseEPSt13_Rb_tree_nodeIS6_E@Base 1.9.1-2.2~
- (arch=amd64 arm64 mips64el ppc64el kfreebsd-amd64 sparc64 hppa m68k x32)_ZNSt8_Rb_treeIN6TagLib10ByteVectorESt4pairIKS1_NS0_6StringEESt10_Select1stIS5_ESt4lessIS1_ESaIS5_EE11equal_rangeERS3_@Base 1.11
+ (optional=templinst)_ZNSt8_Rb_treeIN6TagLib10ByteVectorESt4pairIKS1_NS0_6StringEESt10_Select1stIS5_ESt4lessIS1_ESaIS5_EE11equal_rangeERS3_@Base 1.11
  

Bug#842011: [debian-mysql] Bug#842011: Bug#842011: Bug#842011: default-mysql-client forces removal of mysql-server* and mysql-client*

[Clint Byrum]

Excerpts from Craig Sanders's message of 2016-10-26 15:31:58 +1100:
> On Wed, Oct 26, 2016 at 04:52:38AM +0200, Clint Byrum wrote:
> > The point of the stable release is security updates with minimal impact.
> 
> well, no.  that's ONE of its points, not THE point.
> 
> Another point is to refrain from breaking existing systems - that's at
> least as important as security updates, even if for no other reason than
> that you should be able to trust your distro to not arbitrarily break
> your system on upgrade either due to carelessness or for some misguided
> and just-plain-wrong claim that breaking your system is for your own good.
> 

Sorry, that was the 'minimal impact' part of my reply. But there are
times where the behavior is insecure and the distro must "break" things
by securing things. A user that disagrees with that policy should
disable automatic security updates.

Also I think we can agree that "thou shalt not break" is a rule for
updating packages in a stable release. Upgrades from release to release
are allowed to break stuff, as long as the user is adequately informed.

> > > [ re: dump to text and restore ]
> >
> > You can definitely do that as a user. But automating it just isn't
> > something anybody has had time to do and feel good about it, given
> > that we're talking about peoples' data.
> 
> yet allowing mariadb to use the same data directory as mysql (even
> though it's not completely RW compatible with mysql) is somehow
> acceptable?
> 

I've never liked it, and I actually think it's part of MariaDB's
strategy to be a one-way street. I don't know why it's being allowed to
persist.

> automated export and import is safe. blindly using incompatible binary
> data files is not.
> 

Safe in all cases?

Also this is asking to keep 3 copies of every database around for a
time (export file, new database, old database). That's fine for little
ones, but what about a 2TB data warehouse that might take a week to
export and import?

> 
> the postgresql packages manage to successfully - flawlessly - upgrade
> even through binary-incompatible major releases and have done so for
> many years. any mysql -> mariadb transition should be handled at least
> as well as that.  it's not impossible, it's not even "too hard".
> 

That's a project that is in control of both ends of the upgrade. MariaDB
is a one way street, and MySQL truly does not care if they can't
re-import an export from MariaDB. Also, in the case of stretch, there's
no MySQL to go back to.. so there's no point in automating that path for
the sole purpose of stable update users. Unstable users can and should
be careful when switching.

IMO that's why we should have just left both in. They're not even close to
being the same code base, and the compatibility matrix is getting smaller
and smaller. There are plenty of maintainers and the response time on
those security updates has been adequate from all maintainers. But,
the security team disagrees, and thus, we have this situation.

Bug#842120: tf5: TLSv1.1/1.2 cipher suites not functioning

[Russ Allbery]

Justin Coffman  writes:

> I tried my hand at generating a patch, but the patched version didn't
> exhibit behavior any different than current. I guess my GnuTLS-fu is not
> strong enough.

> The gotcha (I think) is in the way GnuTLS shims the SSLv23_client_method
> in its OpenSSL compatibility layer. The only other available shim is
> TLSv1_client_method, which seems to behave exactly the same way as it
> does currently.

Yeah, I took a quick look, and indeed, this is a mess.  All of the ways of
initializing the context in the compatibility layer enable at most TLS 1.0
and the SSL_CTX_set_cipher_list() function is stubbed out completely
(since GnuTLS uses a different syntax for cipher strings).

I suspect this would require fully porting tf5 to GnuTLS.  :(  Or fixing
the compat layer to not be as stupid about ciphers.

-- 
Russ Allbery (r...@debian.org)   

Bug#639910: ITP: simple-build-tool -- for scala and java projects

[Marko Dimjašević]

Control: retitle -1 ITP: simple-build-tool -- for scala and java
projects
Control: owner -1 !

Dear all,

In accordance with the Debian Java team (predominantly Emmanuel Bourg),
I started working on packaging SBT. As suggested before, I'll use a
strategy that involves the non-free archive because SBT build-depends on
itself.


-- 
Regards,
Marko Dimjašević 
https://dimjasevic.net/marko  PGP key ID: 1503F0AA
Learn email self-defense! https://emailselfdefense.fsf.org


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

Bug#610979: 6tunnel: IPV4 option (-4) should warn if both addresses are already IPV4

[Jari Aalto]

retitle 610979 6tunnel: IPV4 option (-4) should warn if both addresses are 
already IPV4
thanks

[Note to previous message] the commit to 1:0.12-1
debian/chnagelog where fix is recorded is:

https://anonscm.debian.org/cgit/collab-maint/6tunnel.git/commit/?id=bd77d3ca9a331198f9ade4773b80a8b363c669e5

Bug#814923: tasksel: Please add task-lxqt-desktop to tasksel

[Christian PERRIER]

Quoting Roger Shimizu (rogershim...@gmail.com):
> Dear Changzhuo,
> 
> On Tue, Oct 25, 2016 at 7:46 PM, ChangZhuo Chen  wrote:
> > On Sun, Mar 20, 2016 at 01:24:16AM +0800, ChangZhuo Chen (陳昌倬) wrote:
> >> Any progress for this patch?
> >
> > Could you help to review the patch in tasksel for LXQt desktop? We, the
> > LXQt packaging team, needs this to make LXQt available in Stretch.
> 
> AFAIK. The D-I team is preparing a release [0], I'm not sure whether
> your patch can be merged before that release.


But we waited for much too long time, sorry for this. Tasksel sadly
needs a lot of love and more active maintenance.

I don't think this chance is too invasive, so I'll include it
ASAP. Sorry again for the delay.



signature.asc
Description: PGP signature

Bug#842120: tf5: TLSv1.1/1.2 cipher suites not functioning

[Justin Coffman]

>> Justin Coffman  writes:
>>
>> Package: tf5
>> Version: 5.0beta8-5+b1
>> Severity: important
>>
>> TinyFugue, when compiled from upstream source against OpenSSL, is 
>> capable of the full set of expected ciphersuites (up to and including 
>> TLSv1.2), such as those utilizing AES-GCM and EC Diffie-Hellman. The 
>> version packaged in Debian, compiled against GnuTLS, is only capable 
>> of
>> SSLv3/TLSv1 negotiation, and only then with servers that do not 
>> require (EC)DH negotiation. This could render the client unusable for 
>> servers that enforce more modern security policies.
>>
>> TinyFugue when compiled against OpenSSL:
>> % Connected to (unnamed1) using cipher ECDHE-RSA-AES128-GCM-SHA256.
>>
>> TinyFugue when compiled against GnuTLS, same site:
>> % Connected to (unnamed1) using cipher RSA_AES_128_CBC_SHA1.

> Unfortunately, it can't be compiled against OpenSSL and included in Debian 
> since the licenses conflict.  (Which is why it's built against
> GnuTLS.)  It's GPL without any license exception, so such a package would be 
> rejected by Debian ftpmaster.
>
> Sadly, upstream was contacted about this in the past and doesn't feel the 
> problem warrants the effort required to correct this, so there's basically no 
> chance that an OpenSSL build will be possible in Debian.
>
> Presumably there's some way to make GnuTLS negotiate the correct ciphers, but 
> unfortunately I don't know what it is off-hand, and probably won't have time 
> in the near future to do the necessary research.  Patches welcome!
>
> -- 
> Russ Allbery (r...@debian.org)   >

I tried my hand at generating a patch, but the patched version didn't exhibit 
behavior any different than current. I guess my GnuTLS-fu is not strong enough.

The gotcha (I think) is in the way GnuTLS shims the SSLv23_client_method in its 
OpenSSL compatibility layer. The only other available shim is 
TLSv1_client_method, which seems to behave exactly the same way as it does 
currently.

Bug#842125: ITP: node-currently-unhandled -- Track the list of currently unhandled promise rejections

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-currently-unhandled
  Version : 0.4.1
  Upstream Author : James Talmage 
(github.com/jamestalmage)
* URL :
https://github.com/jamestalmage/currently-unhandled#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Track the list of currently unhandled promise
rejections.



signature.asc
Description: OpenPGP digital signature

Bug#842124: ITP: ruby-test-unit-notify -- test result notify extension for Ruby Test::Unit

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: wishlist
Owner: "HIGUCHI Daisuke (VDR dai)" 

* Package name: ruby-test-unit-notify
  Version : 1.0.4
  Upstream Author : Kouhei Sutou 
* URL : https://github.com/test-unit/test-unit-notify
* License : LGPL-2.1+
  Programming Lang: Ruby
  Description : test result notify extension for Ruby Test::Unit

This library provides test result notification support for Ruby Test::Unit.

X Window System based environment such ad GNOME, Xfce, KDE and so on
"notify-send" command is used for notifying test result.

Also, this is required by new version of ruby-cairo.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#842123: ITP: node-is-builtin-module -- Check if a string matches the name of a Node.js builtin module

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-is-builtin-module
  Version : 1.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/is-builtin-module
* License : Expat
  Programming Lang: JavaScript
  Description : Check if a string matches the name of a Node.js
builtin module

Bug#842120: tf5: TLSv1.1/1.2 cipher suites not functioning

[Russ Allbery]

Control: tags -1 help

Justin Coffman  writes:

> Package: tf5
> Version: 5.0beta8-5+b1
> Severity: important

> TinyFugue, when compiled from upstream source against OpenSSL, is
> capable of the full set of expected ciphersuites (up to and including
> TLSv1.2), such as those utilizing AES-GCM and EC Diffie-Hellman. The
> version packaged in Debian, compiled against GnuTLS, is only capable of
> SSLv3/TLSv1 negotiation, and only then with servers that do not require
> (EC)DH negotiation. This could render the client unusable for servers
> that enforce more modern security policies.

> TinyFugue when compiled against OpenSSL:
> % Connected to (unnamed1) using cipher ECDHE-RSA-AES128-GCM-SHA256.

> TinyFugue when compiled against GnuTLS, same site:
> % Connected to (unnamed1) using cipher RSA_AES_128_CBC_SHA1.

Unfortunately, it can't be compiled against OpenSSL and included in
Debian since the licenses conflict.  (Which is why it's built against
GnuTLS.)  It's GPL without any license exception, so such a package would
be rejected by Debian ftpmaster.

Sadly, upstream was contacted about this in the past and doesn't feel the
problem warrants the effort required to correct this, so there's basically
no chance that an OpenSSL build will be possible in Debian.

Presumably there's some way to make GnuTLS negotiate the correct ciphers,
but unfortunately I don't know what it is off-hand, and probably won't
have time in the near future to do the necessary research.  Patches
welcome!

-- 
Russ Allbery (r...@debian.org)   

Bug#841850: linux-image-4.7.0-1-686_4.7.8-1_i386.deb does not boot on Thinkpad T41

[Petra Ruebe-Pugliese]

On Monday, 24 October 2016, at 14:35 Ben Hutchings (b...@decadent.org.uk) wrote:
[...]
> 
> OK, this is the same crash that someone else reported and I think I
> know which change triggered it (though not why).
> 
> Does the attached patch fix the crash?  (Instructions for rebuilding
> the package are at
> .)
> 
> Ben.

 The third attempt to generate that patched kernel finally
 succeeded (doing the compilation overnight, with a large
 external harddisk as additional storage medium).

 I installed the resulting
   35M Oct 26 03:44 linux-image-4.7.0-1-686-unsigned_4.7.8-1a~test_i386.deb
 on one of the affected notebooks, and it booted flawlessly  :-)

 Petra

Bug#842011: [debian-mysql] Bug#842011: Bug#842011: default-mysql-client forces removal of mysql-server* and mysql-client*

[Craig Sanders]

On Wed, Oct 26, 2016 at 04:52:38AM +0200, Clint Byrum wrote:
> The point of the stable release is security updates with minimal impact.

well, no.  that's ONE of its points, not THE point.

Another point is to refrain from breaking existing systems - that's at
least as important as security updates, even if for no other reason than
that you should be able to trust your distro to not arbitrarily break
your system on upgrade either due to carelessness or for some misguided
and just-plain-wrong claim that breaking your system is for your own good.


> > [ re: dump to text and restore ]
>
> You can definitely do that as a user. But automating it just isn't
> something anybody has had time to do and feel good about it, given
> that we're talking about peoples' data.

yet allowing mariadb to use the same data directory as mysql (even
though it's not completely RW compatible with mysql) is somehow
acceptable?

automated export and import is safe. blindly using incompatible binary
data files is not.


the postgresql packages manage to successfully - flawlessly - upgrade
even through binary-incompatible major releases and have done so for
many years. any mysql -> mariadb transition should be handled at least
as well as that.  it's not impossible, it's not even "too hard".


craig

--
craig sanders 

Bug#842121: 389-ds-base: CVE-2016-5405: Password verification vulnerable to timing attack

[Salvatore Bonaccorso]

Source: 389-ds-base
Version: 1.3.5.13-1
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for 389-ds-base. The
information though is very scarce, can you try to find more out about
upstream report and/or fix?

CVE-2016-5405[0]:
Password verification vulnerable to timing attack

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-5405
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1358865

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#842120: tf5: TLSv1.1/1.2 cipher suites not functioning

[Justin Coffman]

Package: tf5
Version: 5.0beta8-5+b1
Severity: important

TinyFugue, when compiled from upstream source against OpenSSL, is capable of 
the full set of expected 
ciphersuites (up to and including TLSv1.2), such as those utilizing AES-GCM and 
EC Diffie-Hellman. The 
version packaged in Debian, compiled against GnuTLS, is only capable of 
SSLv3/TLSv1 negotiation, and only 
then with servers that do not require (EC)DH negotiation. This could render the 
client unusable for servers 
that enforce more modern security policies.

TinyFugue when compiled against OpenSSL:
% Connected to (unnamed1) using cipher ECDHE-RSA-AES128-GCM-SHA256.

TinyFugue when compiled against GnuTLS, same site:
% Connected to (unnamed1) using cipher RSA_AES_128_CBC_SHA1.

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

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

Versions of packages tf5 depends on:
ii  libc62.19-18+deb8u6
ii  libgnutls-openssl27  3.3.8-6+deb8u3
ii  libpcre3 2:8.35-3.3+deb8u4
ii  libtinfo55.9+20140913-1+b1
ii  zlib1g   1:1.2.8.dfsg-2+b1

tf5 recommends no packages.

Versions of packages tf5 suggests:
pn  spell  

-- no debconf information

Bug#842011: [debian-mysql] Bug#842011: Bug#842011: default-mysql-client forces removal of mysql-server* and mysql-client*

[Craig Sanders]

On Wed, Oct 26, 2016 at 04:43:53AM +0200, Clint Byrum wrote:
> > [ using /dev/tcp in bash ]
>
> That seems like a gross oversimplification of what works extremely well
> today. mysqladmin actually understands mysql's protocol, and can verify
> that it is up and fully functional. Listening doesn't mean responding,
> or ready for clients.

wow. you spotted that a grossly simple substitute was a gross
over-simplification. nobody can accuse you of being unobservant.


> One would hope mariadb's client package provides a similar thing, and
> maybe we could just depend on the virtual package.

if mariadb's client can serve in place of mysql's then of course
it makes sense to use whichever one is available.


did you have anything actually useful - and preferably not completely
obvious - to add, or are you just mouthing off because you can?

craig

--
craig sanders 

Bug#842119: how-can-i-help: option to list all problems sorted by popcon of the associated package

[Paul Wise]

Package: how-can-i-help
Severity: wishlist

I would like to be able to list all issues that apply to my local
system in descending order of how much I care about them. The best
proxy of how much I care is probably how recently I used them.

For packages, this can be found in the popcon information for my
system. On my system the popcon data is in the following two files.
The first one is encrypted to the Debian popcon key and the second is
unencrypted. For earlier versions of popcon the first is unencrypted
and the second doesn't exist. So the code should read the first line of
the file to detect if it is a popcon file or is encrypted.

/var/log/popularity-contest
/var/log/popularity-contest.new

For pseudo-packages, my browser history probably provides the best
information about how recently I used the services. Unfortunately this
is really hard to query in a general way across all browsers, so there
should probably be a way for me to specify usage times to influence the
 sorting. This could also be used to override the package sorting too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#842089: Pending fixes for bugs in the libembperl-perl package

[pkg-perl-maintainers]

tag 842089 + pending
thanks

Some bugs in the libembperl-perl package are closed in revision
c54ff411fa580fd106b04f5d018fa2ccc858c9f4 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libembperl-perl.git/commit/?id=c54ff41

Commit message:

autopkgtest: skip smoke tests.

They would need more setup in the autopkgtest environment than what the
pkg-perl-autopkgtest easily provides.

Closes: #842089

Bug#835149: dpkg: please adapt setting the default pie hardening flag to gcc's new defaults

[Guillem Jover]

Hi!

On Wed, 2016-10-26 at 05:08:52 +0200, Guillem Jover wrote:
> On Wed, 2016-09-07 at 00:48:17 +0200, Bálint Réczey wrote:
> > 2016-09-04 3:03 GMT+02:00 Balint Reczey :
> > > Many packages fail to build due to gcc ... -shared -no-pie ... failing.
> > > I have reported the issue to GCC but they don't seem to fix that:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464
> > >
> > > The proposed workarounds don't seem to be viable in Debian thus I
> > > propose making the -pie dpkg hardening flag a noop instead of passing
> > > -no-pie and friends as compiler/ flags like in the proposed patch.
> > > This is not symmetric but consistent with Ubuntu's way of enabling PIE.
> 
> Wow, that sucks, and we circle back at the situation of enabling PIE by
> default and shared libraries failing, but in the inverse. :)
> 
> > I'm rebuilding all packages failed with the original patch and a good share
> > does compile with the following additional patches.
> > 
> > I would have preferred only the original patch, but apparently this is
> > our best chance for enabling PIE for the archive.
> 
> I think this is very unfortunate, and would make disabling PIE a PITA,
> which I'd rather not inflict onto maintainers.
> 
> > I'll start filing bugs for for the packages still failing to build.
> 
> If it's to start adding -pie then sure, otherwise I'd ask if you could
> hold off, as I've started to combine the patch in
> 
> with
> 
> to use the specs file trick but to disable instead of enable the
> option, which should in principle work. It's really late here, and I'm
> going to sleep, but I'd appreciate some testing once I've got it ready
> tomorrow or so.

Ok, I ended up finishing this up now, but I've not tested the results,
the commit is:

  


Thanks,
Guillem

Bug#842118: RFS: ucommon/7.0.0-7~exp4 [RC]

[Peter Colberg]

Package: sponsorship-requests
Severity: important

Dear mentors,

Following #841876, I am looking for a sponsor for the package "ucommon":

  gbp clone https://anonscm.debian.org/git/pkg-voip/ucommon.git

For verification, these are the current branch heads:

  git show-ref --heads
  48abd035fefb6dd2821b678ab2e57bcb5a3ea894 refs/heads/master
  7a96f5b8ac83e705eab78d5b8e3f6a36ad03fe39 refs/heads/pristine-tar
  d80ef16d8a9371675a4aaacd84bfefe4ad278bd8 refs/heads/upstream

Changes since the last upload:

ucommon (7.0.0-7~exp4) experimental; urgency=medium

  * Use arch-bits symbol tag instead of non-standard subst tag
  * Restore arch-specific symbols for variadic functions
  * Fix mismatching symbols on x32
  * Fix mismatching symbols on hurd-i386
  * Build with all hardening flags
  * Link with -Wl,--as-needed to avoid useless library dependencies
  * Always fail in case of mismatching symbols

 -- Peter Colberg   Tue, 25 Oct 2016 23:06:24 -0400

If you decide to sponsor this package, please upload the source only
so that buildd logs are available for all archs. I will push a release
tag to the git repository after the package has been uploaded.

Regards,
Peter

Bug#840980: Pending fixes for bugs in the libperinci-sub-normalize-perl package

[pkg-perl-maintainers]

tag 840980 + pending
thanks

Some bugs in the libperinci-sub-normalize-perl package are closed in
revision 0517f58fcb21a2775d5a1697539c6f61f533671c in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libperinci-sub-normalize-perl.git/commit/?id=0517f58

Commit message:

Add (build) dependency on libsah-schemas-rinci-perl.

Closes: #840980

Bug#842117: file: detect MacWrite II documents

[Paul Wise]

Package: file
Severity: wishlist

Please detect MacWrite II documents:

Name: MacWrite II document
Sample: https://www.w3.org/History/1989/proposal
Info: http://fileformats.archiveteam.org/wiki/MacWrite

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#837478: "PIE by default" transition is underway -- wiki needs updating

[Guillem Jover]

Hi!

On Wed, 2016-10-26 at 00:37:18 +0200, Andreas Cadhalpun wrote:
> On 25.10.2016 13:55, Guillem Jover wrote:
> > I don't think the reasoning there is sound (as I've mentioned
> > elsewhere), and the policy bug should be closed.
> > 
> > Switching from no-PIE to PIE by default preserves our current behavior
> > WRT static libraries vs shared libraries.
> 
> The current policy says:
> "As to the static libraries, the common case is not to have relocatable code"
> 
> As of gcc-6 version 6.2.0-7 this is factually wrong, because the compiler
> enables PIE by default, which means it produces relocatable code.
> This should definitely be updated to reflect reality.

Right, that should be updated, but the bug was not about that. :)

My point was that, yes we have changed to generating relocatable code
but that is still targetted for executables only, which preserves the
current behavior, sorry if the wording was confusing.

> > For many static libraries,
> > making them embeddable into other shared libraries is really not
> > desirable. And those should be using the shared libraries instead.
> 
> If that's the reason why it shouldn't be done, policy should mention it.
> The current policy does not list this as reason not to use -fPIC, merely:
> "since there is no benefit"

I don't think it's "the reason", but personally I think it's one
important reason.

Embedding static libraries into shared libraries can be very
problematic if the shared libraries do not take precautions, such as
explicit symbol visibility or symbol versioning, etc. Which most
shared libraries do not do. And even then it's still prone to symbol
conflicts, etc, even inside the shared library being linked itself in
case of namespace issues, if the static library is sloppy.

So I think this should be in general discouraged.

> > I still think the current policy is fine, and if someone wants to build
> > a static library with PIC it should be brought up here.
> 
> The current ffmpeg packages builds shared and static libraries, the
> latter because they are used in the test suite. Both are built from
> the same object files compiled with -fPIC.
> Do you really think those static libraries should not be included
> in the binary lib*-dev packages just because they are not incompatible
> with including in other shared libraries?

Well, I guess depends on how "clean" they are, what's the intended
usage, etc. But given that in this case the usage is inside the same
project, that seems pretty safe! I'd personally probably not ship them,
and would instead provide non-PIC ones there. Or at most ship them in
addition as _pic.a libraries, to require explicit invocation.

Thanks,
Guillem

Bug#842053: dos2unix: FTBFS in almost all architectures

[Jari Aalto]

On 2016-10-25 19:28, Simon McVittie wrote:
| On Tue, 25 Oct 2016 at 12:28:26 -0200, Joao Eriberto Mota Filho wrote:
| > Your package, recently uploaded to unstable, fails to build from source in
| > several architectures[1].
| > 
| > The fail is being caused by some tests (in dh_auto_test target).
| 
| buildds don't typically have any locales except for C and C.UTF-8. If you
| want a UTF-8 locale during build, please use LC_ALL=C.UTF-8, which all
| Debian systems have available.

Hi Simon,

Thanks for the analysis!
Now working with upstream to take this into acount.

Jari

Bug#842112: digikam: Export menu does not open

[Steve M. Robbins]

Control: tags + moreinfo

On Wednesday, October 26, 2016 12:12:05 AM CDT you wrote:
> Package: digikam
> Version: 4:5.2.0-2
> Severity: normal
> 
> In the top menubar the Export dropbdown menu does not open. It gets selected
> as all the other menus, but nothing is shown. This also happens on a clean
> install (no configuration). This is also present in 5.1.0-1, but was not
> present in 5.1.0-2 and is not present when compiling digikam from source,
> so I assume (!) this is packaging related.

I'm not able to replicate this.  On the first attempt, I had to wait a bit 
because Digikam was busy scanning my photo folders.  But eventually it was 
responsive.  On subsequent executions, the Export menu popped up immediately.

-Steve


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

Bug#835149: dpkg: please adapt setting the default pie hardening flag to gcc's new defaults

[Guillem Jover]

Hi!

On Wed, 2016-09-07 at 00:48:17 +0200, Bálint Réczey wrote:
> 2016-09-04 3:03 GMT+02:00 Balint Reczey :
> > Many packages fail to build due to gcc ... -shared -no-pie ... failing.
> > I have reported the issue to GCC but they don't seem to fix that:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464
> >
> > The proposed workarounds don't seem to be viable in Debian thus I
> > propose making the -pie dpkg hardening flag a noop instead of passing
> > -no-pie and friends as compiler/ flags like in the proposed patch.
> > This is not symmetric but consistent with Ubuntu's way of enabling PIE.

Wow, that sucks, and we circle back at the situation of enabling PIE by
default and shared libraries failing, but in the inverse. :)

> I'm rebuilding all packages failed with the original patch and a good share
> does compile with the following additional patches.
> 
> I would have preferred only the original patch, but apparently this is
> our best chance for enabling PIE for the archive.

I think this is very unfortunate, and would make disabling PIE a PITA,
which I'd rather not inflict onto maintainers.

> I'll start filing bugs for for the packages still failing to build.

If it's to start adding -pie then sure, otherwise I'd ask if you could
hold off, as I've started to combine the patch in

with

to use the specs file trick but to disable instead of enable the
option, which should in principle work. It's really late here, and I'm
going to sleep, but I'd appreciate some testing once I've got it ready
tomorrow or so.

Thanks,
Guillem

Bug#835146: dpkg: please enable bindow hardening flag by default

[Guillem Jover]

Hi!

On Thu, 2016-10-20 at 03:20:59 +0200, Bálint Réczey wrote:
> For the record gcc-6/6.2.0-7 enabled bindnow for the architectures where
> PIE is enabled by default. I think enabling bindnow from dpkg would be
> better through the hardening flags because packages could disable it
> in a nicer and already established way.

Hmm, I don't get why bindnow was enabled by default in gcc, while
relro (I'd assume) is not enabled by default, or is that enabled by
default now too?

IMO either relro + bindnow should be enabled in gcc, or neither
should. I'm fine either way, but I find having a hardened compiler is
actually good, because it gives also hardened output for non-packaged
builds!

Thanks,
Guillem

Bug#842011: [debian-mysql] Bug#842011: Bug#842011: default-mysql-client forces removal of mysql-server* and mysql-client*

[Clint Byrum]

Excerpts from Craig Sanders's message of 2016-10-26 12:10:49 +1100:
> On Tue, Oct 25, 2016 at 01:09:23PM +0100, Robie Basak wrote:
> > I agree with you, but the release team have made their decision against our
> > wishes. There's no point arguing with us. We know.
> 
> since when does the release team tell maintainers what they're allowed
> to package?  or what solutions they're allowed to come up with for
> easily-forseeable problems?
> 

The point of the stable release is security updates with minimal impact.
The security team has decided MySQL makes that exceedingly difficult
because of the CVE's reported against it without full disclosure. They
are ultimately responsible for those updates (though maintainers from
Oracle have helped quite a bit) and they do not want to carry the burden
anymore. They also seem to think our users don't like those CVE's,
though I never saw any real evidence of that.

> > > if this is the plan then there really needs to be a foolproof, automated,
> > > thorougly tested migration script. and even then it should still be easy
> > > to back out and revert to mysql.
> >
> > This does not exist, and currently nobody has the time to work on this.  I
> > believe MySQL->MariaDB works right now, but the reverse direction certainly
> > doesn't. Users should take backups before upgrading.
> 
> the problem is binary db-file compatibility, so the obvious method would be to
> dump to text from mysql, possibly do some minor fixups to the text dump with
> sed or pœrl if required, restore into mariadb.
> 
> and the reverse for converting from mariadb to mysql.
> 

You can definitely do that as a user. But automating it just isn't
something anybody has had time to do and feel good about it, given that
we're talking about peoples' data.

Bug#842011: [debian-mysql] Bug#842011: Bug#842011: default-mysql-client forces removal of mysql-server* and mysql-client*

[Clint Byrum]

Excerpts from Craig Sanders's message of 2016-10-26 12:56:43 +1100:
> On Tue, Oct 25, 2016 at 06:42:11AM -0700, Lars Tangvald wrote:
> 
> > SysV and upstart scripts use mysqladmin (which is in the client) to verify
> > that the server is running. 5.7 has some inbuilt support for systemd, so for
> > systemd at least it's not needed.
> 
> pgrep (or even telnet to port 3306) would probably be better.
> 
> but neither of those are Essential, and neither is netstat, so to avoid
> another dependency, using bash's /dev/tcp built-in would probably be better.
> mysql's init.d script is already bash rather than sh, and this is a bash
> feature which has existed since version 2.04 (although it was disabled in
> debian until around 2009 IIRC)
> 
> some google results on the topic:
> 
> http://hacktux.com/bash/socket
> http://www.linuxjournal.com/content/more-using-bashs-built-devtcp-file-tcpip
> 
> probably don't need to get a meaningfule result, just check to see there's
> something listening on port 3306 (or whatever's defined in my.cnf)
> 
> #! /bin/bash
> 
> ( exec 3<>/dev/tcp/localhost/3306 ) >& /dev/null
> echo $?
> 
> wrapped in a subshell to avoid spamming stderr if nothing's listening.

That seems like a gross oversimplification of what works extremely well
today. mysqladmin actually understands mysql's protocol, and can verify
that it is up and fully functional. Listening doesn't mean responding,
or ready for clients.

One would hope mariadb's client package provides a similar thing, and
maybe we could just depend on the virtual package.

Bug#841499: uscan: support searching in multiple directories for matching files

[Paul Wise]

On Tue, 2016-10-25 at 22:39 +0900, Osamu Aoki wrote:

> I was thinking to bunch up all possible URL results by scanning all
> directory from low version to the high version.  But you have a point.
> Scan from high version and pick page which has matching URL.
> 
> This makes sense and not as bad situation as I thought. 
> 
> Just push down all the directories.  Scan from the latest one.

I'm glad you agree. I had trouble understanding the code, otherwise I
would have just committed this myself.

> Yes.  I meant HTTP site which looks like old FTP site in terms of its
> directory and page structure.

Ah, ok.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#842011: [debian-mysql] Bug#842011: default-mysql-client forces removal of mysql-server* and mysql-client*

[Craig Sanders]

On Tue, Oct 25, 2016 at 06:42:11AM -0700, Lars Tangvald wrote:

> SysV and upstart scripts use mysqladmin (which is in the client) to verify
> that the server is running. 5.7 has some inbuilt support for systemd, so for
> systemd at least it's not needed.

pgrep (or even telnet to port 3306) would probably be better.

but neither of those are Essential, and neither is netstat, so to avoid
another dependency, using bash's /dev/tcp built-in would probably be better.
mysql's init.d script is already bash rather than sh, and this is a bash
feature which has existed since version 2.04 (although it was disabled in
debian until around 2009 IIRC)

some google results on the topic:

http://hacktux.com/bash/socket
http://www.linuxjournal.com/content/more-using-bashs-built-devtcp-file-tcpip

probably don't need to get a meaningfule result, just check to see there's
something listening on port 3306 (or whatever's defined in my.cnf)

#! /bin/bash

( exec 3<>/dev/tcp/localhost/3306 ) >& /dev/null
echo $?

wrapped in a subshell to avoid spamming stderr if nothing's listening.


craig

--
craig sanders 

Bug#841831: people.debian.org: provide psql command for UDD users

[Paul Wise]

On Sun, 23 Oct 2016 14:28:03 -0200 Joao Eriberto Mota Filho wrote:

> I have some UDD reports[1]
> [1] https://people.debian.org/~eriberto/udd/

Why not put these reports onto udd.d.o?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#842039: shadowsocks-libev: Please move README.Debian from dev package to main package

[Boyuan Yang]

Hi Roger,

2016-10-26 8:09 GMT+08:00 Roger Shimizu :
> I'll fix this on next release.
> or you can fix it by yourself.

That determines on whether I could have access to collab-maint.

There are also some lintian errors, don't forget to get rid of them :p

> BTW. Have you get collab-maint access?

Not really. My new package is stuck in NEW [1] and it would make sense
to ask for a collab-maint access after the initial package is uploaded and
installed into Debian main.

In fact it would be quicker if you could advocate for me as described in
[2], but that is up to you. My alioth account is hosiet-guest.

[1] https://qa.debian.org/developer.php?email=073p...@gmail.com
[2] https://wiki.debian.org/Alioth/PackagingProject


Sincerely,
Boyuan Yang

Bug#842011: [debian-mysql] Bug#842011: default-mysql-client forces removal of mysql-server* and mysql-client*

[Craig Sanders]

On Tue, Oct 25, 2016 at 01:09:23PM +0100, Robie Basak wrote:
> On Tue, Oct 25, 2016 at 10:00:32PM +1100, Craig Sanders wrote:
> > it still seems very surprising to me that a package called
> > default-MYSQL-client would force the removal of mysql-client* and
> > mysql-server*
>
> I agree this is confusing. Unfortunately we don't have a common
> name that describes both MariaDB and MySQL. "MySQL-like"
> is perhaps the best we can do. The package name would be
> default--client. What do you suggest that 
> should be?

i would suggest that solving that problem is a job for the mysql team or at
least for someone who knows and cares more about mysql/mariadb, not a stick to
use for not-very-subtly telling random individual bug-reporters to shut up and
go away.


> > IMO іf it can't be sorted out with alternatives, then it should be a
> > completely separate package. and other packages that need a mysql-like db
> > should depend on mysql or mariadb or either with 'mysql | mariadb'.
>
> It is a completely separate package that conflicts with the MySQL packages
> as appropriate.

however, it uses that same data directory even though it's not 100% RW
compatible with the data files.

IMO, that's a serious bug.

> Packages that need a mysql-like db should depend on "default-mysql-server
> | virtual-mysql-server". In other words, this already works from the
> MySQL/MariaDB packaging end.

yes.  btw, this has been fixed with mythtv-common now.  a new package
has been built already after my report on the dmo-discuss list.


> I agree with you, but the release team have made their decision against our
> wishes. There's no point arguing with us. We know.

since when does the release team tell maintainers what they're allowed
to package?  or what solutions they're allowed to come up with for
easily-forseeable problems?


> > if this is the plan then there really needs to be a foolproof, automated,
> > thorougly tested migration script. and even then it should still be easy
> > to back out and revert to mysql.
>
> This does not exist, and currently nobody has the time to work on this.  I
> believe MySQL->MariaDB works right now, but the reverse direction certainly
> doesn't. Users should take backups before upgrading.

the problem is binary db-file compatibility, so the obvious method would be to
dump to text from mysql, possibly do some minor fixups to the text dump with
sed or pœrl if required, restore into mariadb.

and the reverse for converting from mariadb to mysql.


craig

--
craig sanders 

Bug#841709: [uscan] missing package parameter at call of debian/repack.sh

[Jörg Frings-Fürst]

Hello Osamu,

here my watch file:

[quote]
version=4

#opts="dversionmangle=s/\+repack\d+$//" 
http://www.argyllcms.com/downloadsrc.html Argyll_V(.*)_src\.zip
opts=dversionmangle=s/\+repack(.*)// \
http://www.argyllcms.com/downloadsrc.html Argyll_V(.*)_src\.zip debian 
debian/repack.sh

[/quote]

The way to reproduce:

-> run "uscan --verbose -ddd"


CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#839767: ncmpcpp fails to start due to undefined symbol in binary

[Matteo Cypriani]

Hi Simon,

Le mardi 25 octobre 2016 18:55:39 EDT, vous avez écrit :
> So while this seems to have migrated into unstable, when building in the
> Zesty proposed pocket, it failed to build.
> 
> This FTBFS is only on ppc64el and seems to be caused by symbols
> problems. You can take a look for yourself here:
>  - https://launchpad.net/ubuntu/+source/taglib/1.11.1-0.1
>  -
> https://launchpadlibrarian.net/290827635/buildlog_ubuntu-zesty-ppc64el.tagli
> b_1.11.1-0.1_BUILDING.txt.gz
> 
> Is this something Ubuntu-specific (in which case I'll fix this) or is it
> something you guys missed?

This is unrelated to the ncmpcpp problem; in this case it seems to be 
architecture-dependent symbols not existing on this architecture. The fix would 
be to tag the symbols in question (e.g. arch=!ppc64el).

The odd thing is, taglib 1.11.1-0.1 has been built successfully on ppc64el on 
Debian [1], so I'm not sure what is happening here. I don't think it would be 
right to disable the symbols in Debian, because it would likely break the 
package on that architecture for us. Please keep me posted on your findings (by 
private email or on a new bug report, since #839767 is not concerned).

Cheers,
  Matteo

[1] https://buildd.debian.org/status/fetch.php?
pkg=taglib=ppc64el=1.11.1-0.1=1477391033

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

Bug#834226: atop: prevents clean and fast shutdown

[Vincent Lefevre]

On 2016-10-25 10:44:01 +0200, Marc Haber wrote:
> I have uploaded 2.2.4-1~exp1 to experimental. That version is a
> debugging release which has better logging. Can you please try to
> reproduce this issue?

I tried to upgrade, but it failed:

root@cventin:/home/vlefevre# apt install atop/experimental
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Selected version '2.2.4-1~exp1' (Debian:experimental [amd64]) for 'atop'
The following package was automatically installed and is no longer required:
  linux-image-4.5.0-2-amd64
Use 'apt autoremove' to remove it.
The following packages will be upgraded:
  atop
1 upgraded, 0 newly installed, 0 to remove and 96 not upgraded.
Need to get 138 kB of archives.
After this operation, 32.8 kB of additional disk space will be used.
Get:1 http://ftp.de.debian.org/debian experimental/main amd64 atop amd64 
2.2.4-1~exp1 [138 kB]
Fetched 138 kB in 0s (1063 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
apt-listchanges: Do you want to continue? [Y/n] 
(Reading database ... 508278 files and directories currently installed.)
Preparing to unpack .../atop_2.2.4-1~exp1_amd64.deb ...
Unpacking atop (2.2.4-1~exp1) over (2.2.3-1~exp1) ...
Setting up atop (2.2.4-1~exp1) ...
Installing new version of config file /etc/cron.d/atop ...
Installing new version of config file /etc/init.d/atop ...
Installing new version of config file /etc/init.d/atopacct ...
Installing new version of config file /etc/logrotate.d/psaccs_atop ...
Installing new version of config file /etc/logrotate.d/psaccu_atop ...
Job for atopacct.service failed because of unavailable resources or another 
system error.
See "systemctl status atopacct.service" and "journalctl -xe" for details.
invoke-rc.d: initscript atopacct, action "start" failed.
● atopacct.service - Atop process accounting daemon
   Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: resources) since Wed 2016-10-26 02:15:36 CEST; 8ms 
ago
 Docs: man:atopacctd(8)
  Process: 7849 ExecStart=/usr/sbin/atopacctd (code=exited, status=0/SUCCESS)
 Main PID: 946 (code=killed, signal=KILL)

Oct 26 02:15:36 cventin systemd[1]: Starting Atop process accounting daemon...
Oct 26 02:15:36 cventin atopacctd[7849]: /run/pacct_shadow.d: File exists
Oct 26 02:15:36 cventin systemd[1]: atopacct.service: PID file /run/atopacc...ry
Oct 26 02:15:36 cventin systemd[1]: Failed to start Atop process accounting...n.
Oct 26 02:15:36 cventin systemd[1]: atopacct.service: Unit entered failed state.
Oct 26 02:15:36 cventin systemd[1]: atopacct.service: Failed with result 'r...'.
Hint: Some lines were ellipsized, use -l to show in full.
dpkg: error processing package atop (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for systemd (231-9) ...
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 atop
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

-  Show old opportunities as well as new ones: how-can-i-help --old  -
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#842039: shadowsocks-libev: Please move README.Debian from dev package to main package

[Roger Shimizu]

On Tue, Oct 25, 2016 at 9:58 PM, Boyuan Yang <073p...@gmail.com> wrote:
>
> Currently the README.Debian file is packaged along with `libshadowsocks-libev-
> dev', which is not correct. This README file is meant to be read by the users
> of main package, `shadowsocks-libev'.

I got to know the reason.
Manpage of dh_installdocs writes:

   debian/README.Debian
   debian/TODO
   These files are installed into the first binary package
listed in debian/control.

Remember the patch you changed the package order in d/control? ;-P

I'll fix this on next release.
or you can fix it by yourself.

BTW. Have you get collab-maint access?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#842116: lxqt-common: Upgrading the package sets the config to dpi=96

[Nick Coleman]

Package: lxqt-common
Version: 0.11.0-3
Severity: normal

'apt ugrade' upgraded this package today and it reported that the existing
/etc/xdg/lxqt/session.conf was different to the new version.

One change was an additional line:
dpi=96

My screen resolution is not 96, rather about 128 and that is set in
xorg's config files.

Perhaps lxqt needs a dummy dpi number, which may explain why this new
figure of 96 is included, but I don't want my resulting screen
resolution affected by this change, hence the bug report just in case.


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

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

Versions of packages lxqt-common depends on:
ii  x11-utils  7.7+3

Versions of packages lxqt-common recommends:
ii  oxygen-icon-theme  5:5.27.0-1

lxqt-common suggests no packages.

-- no debconf information

Bug#839617: linux 4.6 - 4.7.5: intel hd graphics 5500 crash after power save; workaround

[Daniel]

Package: src:linux
Version: 4.7.8-1~bpo8+1
Followup-For: Bug #839617

Dear Maintainer,

meanwhile I have found the following workaround:
booting with
i915.enable_psr=0
avoids the crashes.

Perhaps panel self refresh (psr) could be deactivated for intel broadwell until
upstream fixes this issue?

(see also https://bugs.freedesktop.org/show_bug.cgi?id=97602)

Cheers,
Daniel



-- Package-specific info:
** Version:
Linux version 4.7.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.7.8-1~bpo8+1 (2016-10-19)

** Command line:
BOOT_IMAGE=/vmlinuz-4.7.0-0.bpo.1-amd64 
root=UUID=606e51f3-fe5c-4fe2-b595-6157070b1c9a ro apparmor=1 security=apparmor 
i915.enable_psr=0 quiet

** Tainted: PUOE (12353)
 * Proprietary module has been loaded.
 * Userspace-defined naughtiness.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[   10.054258] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[   10.072807] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3263: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   10.072813] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   10.072816] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[   10.072818] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[   10.072820] snd_hda_codec_realtek hdaudioC1D0:inputs:
[   10.072823] snd_hda_codec_realtek hdaudioC1D0:  Headset Mic=0x18
[   10.072825] snd_hda_codec_realtek hdaudioC1D0:  Headphone Mic=0x1a
[   10.072827] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
[   10.078320] [drm] Memory usable by graphics device = 4096M
[   10.078324] [drm] Replacing VGA console driver
[   10.078970] Console: switching to colour dummy device 80x25
[   10.079348] [drm] ACPI BIOS requests an excessive sleep of 25000 ms, using 
1500 ms instead
[   10.085509] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   10.085513] [drm] Driver supports precise vblank timestamp query.
[   10.087857] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   10.089477] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card1/input8
[   10.089687] input: HDA Intel PCH Headphone Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input9
[   10.105063] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   10.109507] wl: module license 'MIXED/Proprietary' taints kernel.
[   10.109510] Disabling lock debugging due to kernel taint
[   10.115867] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10
[   10.142971] dcdbas dcdbas: Dell Systems Management Base Driver (version 
5.6.0-3.2)
[   10.147887] wlan0: Broadcom BCM43b1 802.11 Hybrid Wireless Controller 
6.30.223.271 (r587334)
[   10.153559] Adding 8298492k swap on /dev/mapper/sda2_crypt.  Priority:-1 
extents:1 across:8298492k SSFS
[   10.154021] input: DLL0665:01 06CB:76AD Touchpad as 
/devices/pci:00/INT3433:00/i2c-1/i2c-DLL0665:01/0018:06CB:76AD.0001/input/input11
[   10.154174] hid-multitouch 0018:06CB:76AD.0001: input,hidraw0: I2C HID v1.00 
Mouse [DLL0665:01 06CB:76AD] on i2c-DLL0665:01
[   10.161524] intel_rapl: Found RAPL domain package
[   10.161528] intel_rapl: Found RAPL domain core
[   10.161531] intel_rapl: Found RAPL domain uncore
[   10.161533] intel_rapl: Found RAPL domain dram
[   10.161537] intel_rapl: RAPL package 0 domain package locked by BIOS
[   10.161541] intel_rapl: RAPL package 0 domain dram locked by BIOS
[   10.165744] iTCO_vendor_support: vendor-support=0
[   10.11] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   10.166710] iTCO_wdt: Found a Wildcat Point_LP TCO device (Version=2, 
TCOBASE=0x1860)
[   10.166925] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   10.214325] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[   10.283060] fbcon: inteldrmfb (fb0) is primary device
[   10.410352] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   10.410357] [drm] Initialized i915 1.6.0 20160425 for :00:02.0 on minor 0
[   11.034037] Bluetooth: Core ver 2.21
[   11.034051] NET: Registered protocol family 31
[   11.034052] Bluetooth: HCI device and connection manager initialized
[   11.034054] Bluetooth: HCI socket layer initialized
[   11.034056] Bluetooth: L2CAP socket layer initialized
[   11.034060] Bluetooth: SCO socket layer initialized
[   11.037299] usbcore: registered new interface driver btusb
[   11.042181] Bluetooth: hci0: BCM: chip id 63
[   11.042931] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input13
[   11.043800] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input14
[   11.043874] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input15
[   11.057371] media: Linux media interface: 

Bug#842015: [pkg-gnupg-maint] Bug#842015: gnupg: gpg --no-tty freezes when there is no X display

[Vincent Lefevre]

On 2016-10-25 17:40:03 -0400, Daniel Kahn Gillmor wrote:
> since each user has a single gpg-agent (thanks to the standard-socket),
> I see a few choices here:
> 
>  a) use pinentry-emacs where possible (this won't currently work within
> debian since none of our pinentry implementations are configured to
> support emacs, though this could change)
> 
>  b) emacs could use "--pinentry-mode loopback" and directly handle the
> user's passphrase
> 
>  c) emacs could pass its controlling tty to the gpg process and rely on
> pinentry-curses or pinentry-tty (or any comparable fallback
> mechanism) to handle the situation.
> 
> I've opened the uptsream bug report
> https://bugs.gnupg.org/gnupg/issue2818 to try to track this problem, as
> i'm not sure the best way to solve it.

This is not specific to Emacs. There's the same problem with
"gpg -d file.gpg" instead of "emacs file.gpg".

I suppose that if gpg communicates its $DISPLAY and $GPG_TTY to
gpg-agent, gpg-agent should be able to know what to do.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#839767: ncmpcpp fails to start due to undefined symbol in binary

[Simon Quigley]

So while this seems to have migrated into unstable, when building in the
Zesty proposed pocket, it failed to build.

This FTBFS is only on ppc64el and seems to be caused by symbols
problems. You can take a look for yourself here:
 - https://launchpad.net/ubuntu/+source/taglib/1.11.1-0.1
 -
https://launchpadlibrarian.net/290827635/buildlog_ubuntu-zesty-ppc64el.taglib_1.11.1-0.1_BUILDING.txt.gz

Is this something Ubuntu-specific (in which case I'll fix this) or is it
something you guys missed?

-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4

Bug#842012: emacs24-lucid: On gpg file, Emacs starts gpg --no-tty even when there is no X display

[Vincent Lefevre]

On 2016-10-25 13:02:10 -0400, Daniel Kahn Gillmor wrote:
> It is not inherently a bug to run "gpg --no-tty" with no X display.

This is documented as:

  Make sure that the TTY (terminal) is never used for any output.

But in my case (SSH without X forwarding), the tty was the *only* way
to provide the passphrase. Even if this doesn't imply anything for
input (to get the passphrase), it still has to display the prompt on
the tty.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#146306: fetchmail: so called "bouncing" of mail is braindead

[Liam Morland]

Silently bouncing messages mean messages can get lost. For example, when I 
fetch manually, I can see this:

fetchmail: SMTP error: 550 maximum allowed line length is 998 octets, got 1006
fetchmail: mail from MAILER-DAEMON@ bounced to 
fetchmail: SMTP listener refused delivery

If fetchmail is running as daemon like it usually is, I get no indication that 
I missed a message. At the very least, in failures like this, fetchmail should 
send its error messages through as an email, including the subject and sender, 
so that the user knows they missed a message and can investigate.

Bug#815352: New mailing list for RISC-V port(s)

[Paul van der Vlis]

I support the creation of the debian-riscv mailing list.

With regards,
Paul van der Vlis.


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Bug#828801: Legitimate mail can contain long lines

[Liam Morland]

Why is there a limitation at all? Bytes are just bytes; why does there have to 
be a newline character every so often? I have lost mail because of this rule. 
Please fix.

Bug#841406: Fixed, verification in progress

[Roelof Berg]

Fixed. Next steps would be:

adt-run --unbuilt-tree=limereg --- null
git tag -s -a debian/1.4.1-1 -m "Release 1.4.1-1"
git push --all
git push --tag

But I have a: WARNING: 'automake-1.15' is missing on your system, so I 
cannot verify before creating the tag. Will move my development PC to 
SID, maybe there automake is more recent, would be cleaner anyway.

Bug#842115: partclone: FTBFS: Compiling: fail-mbr.S -> fail-mbr.o -> fail-mbr.image -> /usr/bin/ld: attempted static link of dynamic object `fail-mbr.o'

[Chris Lamb]

Source: partclone
Version: 0.2.88-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

partclone fails to build from source in unstable/amd64:

  […]

  gcc -DHAVE_CONFIG_H -I. -I..  -DLOCALEDIR=\"/usr/share/locale\" 
-D_FILE_OFFSET_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -DMINIX -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wall -c -o 
partclone_minix-partclone.o `test -f 'partclone.c' || echo './'`partclone.c
  gcc -DHAVE_CONFIG_H -I. -I..  -DLOCALEDIR=\"/usr/share/locale\" 
-D_FILE_OFFSET_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -DMINIX -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wall -c -o 
partclone_minix-progress.o `test -f 'progress.c' || echo './'`progress.c
  gcc -DHAVE_CONFIG_H -I. -I..  -DLOCALEDIR=\"/usr/share/locale\" 
-D_FILE_OFFSET_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -DMINIX -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wall -c -o 
partclone_minix-minixclone.o `test -f 'minixclone.c' || echo './'`minixclone.c
  gcc -DMINIX -g -O2 
-fdebug-prefix-map=/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wall  -Wl,-z,relro 
-o partclone.minix partclone_minix-main.o partclone_minix-partclone.o 
partclone_minix-progress.o partclone_minix-minixclone.o  -lncursesw -lpthread  
-ltinfo
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88/src'
  Making all in docs
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88/docs'
  make[3]: Nothing to be done for 'all'.
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88/docs'
  Making all in tests
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88/tests'
  make[3]: Nothing to be done for 'all'.
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88/tests'
  Making all in fail-mbr
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88/fail-mbr'
  sh compile-mbr.sh
  Compiling: fail-mbr.S -> fail-mbr.o -> fail-mbr.image -> /usr/bin/ld: 
attempted static link of dynamic object `fail-mbr.o'
  collect2: error: ld returned 1 exit status
  fail-mbr.bin [Done]. 
  objcopy: 'fail-mbr.image': No such file
  Checking the file:
  objdump: 'fail-mbr.bin': No such file
  files fail-mbr.bin and fail-mbr.bin.orig differ significantly:
  diff: f1.obj: No such file or directory
  diff: f2.obj: No such file or directory
  Makefile:501: recipe for target 'fail-mbr.bin' failed
  make[3]: *** [fail-mbr.bin] Error 1
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88/fail-mbr'
  Makefile:400: recipe for target 'all-recursive' failed
  make[2]: *** [all-recursive] Error 1
  make[2]: Leaving directory 
'/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88'
  Makefile:341: recipe for target 'all' failed
  make[1]: *** [all] Error 2
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20161025234343.N57us6zz7w.db.partclone/partclone-0.2.88'
  dh_auto_build: make -j1 returned exit code 2
  debian/rules:13: recipe for target 'build' failed
  make: *** [build] Error 2

  […]

The full build log is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


partclone.0.2.88-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#841368: gcc-6 6.2.0-7 breaks kernel build if stack protection is enabled

[Konstantin Demin]

>> But does this generate the same output as without -enable-default-pie?
>> Some parts of the kernel do use -fpic or -fPIC. Which directive prevails?

If you call gcc with "-O3 -O0 -O1", only "-O1" option is make sence.
See attachments from recent build log (roughly speaking, Linux 4.8.4,
"make V=1" with gcc 6.2.0-9, but actually it's heavily customized
Debian src:linux with 3rd pty patches and custom configs).

>> I'm currently looking for correct way to do this trick.
Patch is available and (at least) works for me on amd64 and i386, ref msg #51

-- 
SY,
Konstantin Demin
gcc-6
-Wp,-MD,arch/x86/entry/vdso/.vdso-image-64.o.d
-nostdinc
-isystem
/usr/lib/gcc/x86_64-linux-gnu/6/include
-I/<>/arch/x86/include
-I./arch/x86/include/generated/uapi
-I./arch/x86/include/generated
-I/<>/include
-I./include
-I/<>/arch/x86/include/uapi
-I/<>/include/uapi
-I./include/generated/uapi
-include /<>/include/linux/kconfig.h
-I/<>/arch/x86/entry/vdso
-Iarch/x86/entry/vdso
-D__KERNEL__
-Wall
-Wundef
-Wstrict-prototypes
-Wno-trigraphs
-fno-strict-aliasing
-fno-common
-Werror-implicit-function-declaration
-Wno-format-security
-std=gnu89
-mno-sse
-mno-mmx
-mno-sse2
-mno-3dnow
-mno-avx
-m64
-falign-jumps=1
-falign-loops=1
-mno-80387
-mno-fp-ret-in-387
-mpreferred-stack-boundary=3
-mskip-rax-setup
-mtune=generic
-mno-red-zone
-mcmodel=kernel
-DCONFIG_X86_X32_ABI
-DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1
-DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1
-DCONFIG_AS_SSSE3=1
-DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1
-DCONFIG_AS_AVX2=1
-DCONFIG_AS_SHA1_NI=1
-DCONFIG_AS_SHA256_NI=1
-pipe
-Wno-sign-compare
-fno-asynchronous-unwind-tables
-O2
-fplugin=./scripts/gcc-plugins/cyc_complexity_plugin.so
-fomit-frame-pointer
-DCC_HAVE_ASM_GOTO
-fno-PIC
-fno-PIE
-DKBUILD_BASENAME='"vdso_image_64"'
-DKBUILD_MODNAME='"vdso_image_64"'
-c
-o arch/x86/entry/vdso/.tmp_vdso-image-64.o
arch/x86/entry/vdso/vdso-image-64.cgcc-6
-Wp,-MD,arch/x86/entry/vdso/.vclock_gettime.o.d
-nostdinc
-isystem
/usr/lib/gcc/x86_64-linux-gnu/6/include
-I/<>/arch/x86/include
-I./arch/x86/include/generated/uapi
-I./arch/x86/include/generated
-I/<>/include
-I./include
-I/<>/arch/x86/include/uapi
-I/<>/include/uapi
-I./include/generated/uapi
-include /<>/include/linux/kconfig.h
-I/<>/arch/x86/entry/vdso
-Iarch/x86/entry/vdso
-D__KERNEL__
-Wall
-Wundef
-Wstrict-prototypes
-Wno-trigraphs
-fno-strict-aliasing
-fno-common
-Werror-implicit-function-declaration
-Wno-format-security
-std=gnu89
-mno-sse
-mno-mmx
-mno-sse2
-mno-3dnow
-mno-avx
-m64
-falign-jumps=1
-falign-loops=1
-mno-80387
-mno-fp-ret-in-387
-mpreferred-stack-boundary=3
-mskip-rax-setup
-mtune=generic
-mno-red-zone
-mcmodel=kernel
-DCONFIG_X86_X32_ABI
-DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1
-DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1
-DCONFIG_AS_SSSE3=1
-DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1
-DCONFIG_AS_AVX2=1
-DCONFIG_AS_SHA1_NI=1
-DCONFIG_AS_SHA256_NI=1
-pipe
-Wno-sign-compare
-fno-asynchronous-unwind-tables
-O2
-fomit-frame-pointer
-DCC_HAVE_ASM_GOTO
-fno-PIC
-fno-PIE
-mcmodel=small
-fPIC
-O2
-fasynchronous-unwind-tables
-m64
-fno-stack-protector
-fno-omit-frame-pointer
-foptimize-sibling-calls
-DDISABLE_BRANCH_PROFILING
-DBUILD_VDSO
-DKBUILD_BASENAME='"vclock_gettime"'
-DKBUILD_MODNAME='"vclock_gettime"'
-c
-o arch/x86/entry/vdso/.tmp_vclock_gettime.o
/<>/arch/x86/entry/vdso/vclock_gettime.c

Bug#837478: "PIE by default" transition is underway -- wiki needs updating

[Andreas Cadhalpun]

Hi,

On 25.10.2016 13:55, Guillem Jover wrote:
> I don't think the reasoning there is sound (as I've mentioned
> elsewhere), and the policy bug should be closed.
> 
> Switching from no-PIE to PIE by default preserves our current behavior
> WRT static libraries vs shared libraries.

The current policy says:
"As to the static libraries, the common case is not to have relocatable code"

As of gcc-6 version 6.2.0-7 this is factually wrong, because the compiler
enables PIE by default, which means it produces relocatable code.
This should definitely be updated to reflect reality.

> For many static libraries,
> making them embeddable into other shared libraries is really not
> desirable. And those should be using the shared libraries instead.

If that's the reason why it shouldn't be done, policy should mention it.
The current policy does not list this as reason not to use -fPIC, merely:
"since there is no benefit"

> I still think the current policy is fine, and if someone wants to build
> a static library with PIC it should be brought up here.

The current ffmpeg packages builds shared and static libraries, the
latter because they are used in the test suite. Both are built from
the same object files compiled with -fPIC.
Do you really think those static libraries should not be included
in the binary lib*-dev packages just because they are not incompatible
with including in other shared libraries?

Best regards,
Andreas

Bug#842114: ITP: arblib -- Arb is a C library for arbitrary-precision interval arithmetic, using a midpoint-radius representation (“ball arithmetic”). It supports real and complex numbers, polynomials

[Stephen Crowley]

Package: wnpp
Severity: wishlist
Owner: Stephen Crowley 

* Package name: arblib
  Version : 2.8.1
  Upstream Author : Fredrik Johansson 
* URL : http://arblib.org/
* License : GNU Lesser General Public License (LGPL), version 2.1 or 
later
  Programming Lang: C
  Description : Arb is a C library for arbitrary-precision interval 
arithmetic, using a midpoint-radius representation (“ball arithmetic”). It 
supports real and complex numbers, polynomials, power series, matrices, and 
evaluation of many transcendental functions. All operations are done with 
automatic, rigorous error bounds. The code is thread-safe, portable, and 
extensively tested.

Arb is a C library for arbitrary-precision interval arithmetic, using
a midpoint-radius representation (“ball arithmetic”). It supports real
and complex numbers, polynomials, power series, matrices, and
evaluation of many transcendental functions. All operations are done
with automatic, rigorous error bounds. The code is thread-safe,
portable, and extensively tested.

Arb is free software distributed under the GNU Lesser General Public
License (LGPL), version 2.1 or later (see License).

The git repository is https://github.com/fredrik-johansson/arb/

Arb is developed by Fredrik Johansson (fredrik.johans...@gmail.com),
with help from many contributors (see Credits and references).
Questions and discussion about Arb are welcome on the flint-devel
mailing list.


p.s.

I was a full-fledged Debian developer circa 1999 or so, but I need a
sponsor I suppose

Bug#842113: ITP: dynomite -- A generic dynamo implementation for different k-v storage engines (memcache and redis)

[Raphael Enrici]

Package: wnpp
Severity: wishlist
Owner: Raphael Enrici 

* Package name: dynomite
  Version : 0.5.8
  Upstream Author : Netflix 
* URL : https://github.com/Netflix/dynomite
* License : Apache License, version 2.0
  Programming Lang: C
  Description : A generic dynamo implementation for different k-v storage 
engines (memcache and redis)

Dynomite is a thin, distributed dynamo layer for different storage engines and
protocols. Currently these include Redis and Memcached. Dynomite supports
multi-datacenter replication and is designed for high availability.

This package would be useful to people looking to implement high-availability
and cross-datacenter replication of redis or memcached instances.

I plan to package it because I definitely need it and am looking for a sponsor
and/or co-maintainer. 

Bug#842080: [pkg-lxqt-devel] Bug#842080: Bug#842080: additional information

[Jape Person]

On 10/25/2016 04:26 PM, Alf Gaida wrote:

On Tue, 25 Oct 2016 15:53:48 -0400
Jape Person  wrote:

Do you suppose that my slightly odd system configuration could
be at fault? I do not have any of the regular desktop

No, not relly - that was my fault


Please let me know if there's anything I might do from a testing
standpoint. I might try grabbing libfm-qt3 from sid to see if

The sid package will fix it, there are 10 new symbols in the new
lib, but it seems that they are not called directly so dh had no
chance to calculate the dependencies right. Have to learn about it.

I do like pcmanfm-qt. Like the rest of the lxqt stuff it's very
fast and responsive. It has required me to adjust some habits. I
had figured out how to use thunar in the Xfce desktop
environment without ever touching the mouse, and I don't seem
able to do that with pcmanfm. Then again, I haven't had a lot of
time to explore it.

Glad you like it. If there are missed functions or things we can
improve we will be glad if you write a request here:
https://github.com/lxde/pcmanfm-qt/issues

Cheers Alf


Okay, I'll grab the libfm-qt3 version from sid.

Thank you for your work on FOSS, and for your helpfulness in 
this matter.


Folks like you are treasures to the world community. That's not 
an exaggeration. Throughout history, the people who fashion 
tools have made it possible for all of us to have better lives.


Regards,
JP

Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper

[Mattia Rizzolo]

On Tue, Oct 25, 2016 at 11:35:42PM +0200, Hilmar Preuße wrote:
> > 3) configure done by dh_auto_configure
> > 
> I'd simply replace
> 
> ./configure $(shell dpkg-buildflags --export=configure) $(CONF_ARGS)
> --with-shared=$(DSOMODS1)$(DSOMODS2)$(DSOMODS3)$(DSOMODS4)
> 
> by
> 
> dh_auto_configure -- $(shell dpkg-buildflags --export=configure)
> $(CONF_ARGS) --with-shared=$(DSOMODS1)$(DSOMODS2)$(DSOMODS3)$(DSOMODS4)
> 
> Is that correct? This will give me a lot of duplicate parameters e.g.
> --prefix=/usr will be specified twice in the configure call. This can be
> cleaned up later on.

That, and remove some options from CONF_ARGS that are already passed by
dh_auto_configure.
Also the change at point 4 should allow you to drop that $(shell
dpkg-buildpackage ..), and if not that can be considered some bad habit
from the the build system.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#842112: digikam: Export menu does not open

[Simon Frei]

Package: digikam
Version: 4:5.2.0-2
Severity: normal

In the top menubar the Export dropbdown menu does not open. It gets selected as 
all the other menus, but nothing is shown. This also happens on a clean install 
(no configuration). This is also present in 5.1.0-1, but was not present in 
5.1.0-2 and is not present when compiling digikam from source, so I assume (!) 
this is packaging related.

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

Kernel: Linux 4.7.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/dash
Init: systemd (via /run/systemd/system)

Versions of packages digikam depends on:
ii  digikam-data  4:5.2.0-2
ii  digikam-private-libs  4:5.2.0-2
ii  libc6 2.24-5
ii  libgcc1   1:6.2.0-6
ii  libkf5configcore5 5.27.0-1
ii  libkf5coreaddons5 5.27.0-1
ii  libkf5filemetadata3   5.27.0-1
ii  libkf5i18n5   5.27.0-1
ii  libqt5core5a  5.6.1+dfsg-3+b1
ii  libqt5gui55.6.1+dfsg-3+b1
ii  libqt5sql55.6.1+dfsg-3+b1
ii  libqt5sql5-mysql  5.6.1+dfsg-3+b1
ii  libqt5sql5-sqlite 5.6.1+dfsg-3+b1
ii  libqt5widgets55.6.1+dfsg-3+b1
ii  libstdc++66.2.0-6
pn  perl:any  

Versions of packages digikam recommends:
ii  chromium [www-browser]  53.0.2785.143-1
ii  ffmpegthumbs4:16.08.0-1
ii  firefox [www-browser]   46.0.1-1+b1
ii  w3m [www-browser]   0.5.3-31

Versions of packages digikam suggests:
pn  digikam-doc 
pn  systemsettings  

-- no debconf information

Bug#782294: Is #782294 a duplicate of #777177?

[Anders Kaseorg]

On Fri, 26 Aug 2016, Joseph Herlant wrote:
> Should we consider this one as a duplicate of #777177 as they both try 
> to solve the reproducibility issues of asciidoc?

I think not: #777177 is about reproducibility of asciidoc itself, while 
#782294 is about reproducibility of any packages using asciidoc during the 
build process.

Anders

Bug#405016: export to gallery interface could be better

[Simon Frei]

The export functionality has been reshaped a lot in version 5. You can
choose the pictures to export in the main window, so all filtering
options (e.g. tags) can be used to display and select the desired items.



signature.asc
Description: OpenPGP digital signature

Bug#841222: Acknowledgement (RFS: patat)

[Félix Sipma]

OK, I've added:
- a manpage
- patat to DHG's package-plan

I hope everything is good now...


signature.asc
Description: PGP signature

Bug#842111: ITP: jigsaw-generator -- Mathematical jigsaw creation software

[Julian Gilbey]

Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 

* Package name: jigsaw-generator
  Version : 0.2.1
  Upstream Author : Julian Gilbey 
* URL : https://github.com/juliangilbey/jigsaw-generator.git
* License : GPL
  Programming Lang: Python
  Description : Mathematical jigsaw creation software

This software is designed to create Tarsia Formulator type
mathematical jigsaws using LaTeX.  The puzzle data is stored in a YAML
file, and the software turns it into a printable jigsaw.  This
software makes it reasonably straightforward to create multiple
jigsaw-style puzzles.

I am the upstream author; I presented it at a TUG Conference a couple
of years ago, but have not yet packaged it for Debian.  It is now
mature enough to release.  There is no Linux package like it that I am
aware of.

Bug#842016: brotli: New version available upstream

[Tomasz Buchert]

On 25/10/16 11:28, Sebastien Delafond wrote:
> Source: brotli
> Version: 0.4.0+dfsg-1
> Severity: minor
> 
> Hello,
> 
> python-brotli version 0.6.0 is available upstream, and it turns out that
> "brotlipy<0.7,>=0.5.1" is a requirement for the new mitmproxy 0.18.1
> that I'm packaging up.
> 
> Is there any chance you could package 0.6.0 in sid ?
> 
> Cheers,
> 
> --Seb

Hmm, where did you find the version 0.6.0? I see only 0.5.2 which I've
just uploaded and which should be good enough for you. Let me know if
you have problems.

Tomasz


signature.asc
Description: PGP signature

Bug#842015: [pkg-gnupg-maint] Bug#842015: gnupg: gpg --no-tty freezes when there is no X display

[Daniel Kahn Gillmor]

Control: tags 842015 - unreproducible moreinfo
Control: tags 842015 + upstream
Control: forwarded 842015 https://bugs.gnupg.org/gnupg/issue2818

Hi Vincent--

I think your analysis is correct:

On Tue 2016-10-25 14:35:49 -0400, Vincent Lefevre wrote:
> This happened when I was at my lab and connected to my machine
> at home, and I've just gone back home and was surprised to see
> the dialog boxes (pinentry?) to type my passphrase.
>
> I think that what happened is the following:
>
> 1. Start an X session locally on machine A.
>I suppose that this starts gpg-agent automatically (otherwise
>maybe an "emacs file.gpg" is needed too).

It is intended behavior that gpg-agent should start automatically from
your graphical session.  Since we use the standard socket location, each
user account on a given machine uses the same gpg-agent.

> 2. From machine B, do "ssh A" (without X forwarding).
>
> 3. From this ssh session, do "emacs file.gpg".

since each user has a single gpg-agent (thanks to the standard-socket),
I see a few choices here:

 a) use pinentry-emacs where possible (this won't currently work within
debian since none of our pinentry implementations are configured to
support emacs, though this could change)

 b) emacs could use "--pinentry-mode loopback" and directly handle the
user's passphrase

 c) emacs could pass its controlling tty to the gpg process and rely on
pinentry-curses or pinentry-tty (or any comparable fallback
mechanism) to handle the situation.

I've opened the uptsream bug report
https://bugs.gnupg.org/gnupg/issue2818 to try to track this problem, as
i'm not sure the best way to solve it.

> It seems that gpg connects to gpg-agent, which thinks that the
> current screen is the one that corresponds to the X session,
> which is obviously wrong. At least, gpg and gpg-agent shouldn't
> assume that they have the same $DISPLAY in their environment.
>
> Before I do anything else, can you reproduce the problem with
> something like that?

yep, thanks, this is the info we needed.  I've dropped the
unreproducible and moreinfo tags.

 --dkg


signature.asc
Description: PGP signature

Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper

[Hilmar Preuße]

On 06.10.2016 22:20, Mattia Rizzolo wrote:

Hi,

> I can sponsor the upload if you want, but before I'd like to see more
> changes done, meaning:
> 

> 
> 3) configure done by dh_auto_configure
> 
I'd simply replace

./configure $(shell dpkg-buildflags --export=configure) $(CONF_ARGS)
--with-shared=$(DSOMODS1)$(DSOMODS2)$(DSOMODS3)$(DSOMODS4)

by

dh_auto_configure -- $(shell dpkg-buildflags --export=configure)
$(CONF_ARGS) --with-shared=$(DSOMODS1)$(DSOMODS2)$(DSOMODS3)$(DSOMODS4)

Is that correct? This will give me a lot of duplicate parameters e.g.
--prefix=/usr will be specified twice in the configure call. This can be
cleaned up later on.

Hilmar
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#842109: Please revert the change to build static libraries with -fPIC

[Adrian Bunk]

Source: bglibs
Version: 1.106-2.1
Severity: normal

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#842110: cmake: could you backport cmake

[picca]

Source: cmake
Version: 3.0.2-1+deb8u1
Severity: wishlist

Dear Maintainer,

It woud be great if you could backport cmake from unstable into 
jessie-backports.
A bunch of projects I am using required cmake > 3.1. but jessie has only 3.0.2

Thanks for considering.

Frederic


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

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

Bug#841954: HDF5 1.10

[Sebastian Wouters]

Hi Graham,

The new chemps2 version is released:
https://github.com/SebWouters/CheMPS2/releases/tag/v1.8.1

I'll try do to the debian repo tomorrow. I have to reinstall a couple of
things to test. If you want to merge the new release earlier based on the
github release, that's also fine with me.

Best wishes,
Sebastian

Bug#842108: Please revert the change to build static libraries with -fPIC

[Adrian Bunk]

Source: libctl
Version: 3.2.2-3
Severity: normal

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#841843: printer-driver-escpr: backend can't find PPD file

[Brian Potkin]

On Mon 24 Oct 2016 at 22:58:06 +0100, Brian Potkin wrote:

> My print queue was set up (all on one line) with
> 
>   lpadmin -p wf2530 -v file:/home/brian/wf2530 -E 
> -m 
> escpr:/0/cups/model/epson-inkjet-printer-escpr/Epsom-WF-2530_Series-epson-escpr-en-ppd
> 
> and I printed with
> 
>   lp -d wf2530 /etc/nsswitch.conf
> 
> You could try this to see whether it gets printing going for you.

I don't know whether you tried this but another request: please post
your PPD file for us to see.

Cheers,

Brian.

Bug#842094: digikam: libgphoto2 support missing

[Simon Frei]

The problem according to your log is not libgphoto2 (it was before, but
is fixed since some releases), now it is a missing command: "gphoto2".
This command is part of a package with the same name "gphoto2". This
should probably be added as a manual dependency in control as shlib does
not seem to pick it up.


On 25/10/16 22:40, Andreas Schneider wrote:
> Package: digikam
> Version: 4:5.2.0-2
> Severity: important
>
> Dear Maintainer,
>
> digikam can't access my camera anymore, after upgrading to version 5.2.0-2. 
> The
> reason is that libgphoto2 support is missing in that version whereas it was
> available in 5.1.0-2. This, or a similar problem, had occured a number of 
> times
> before (#785492 and #821178) and disappeared subsequently.
>
> Comparing the build logs for 5.1.0-2:
> https://buildd.debian.org/status/fetch.php?pkg=digikam=amd64=4%3A5.1.0-2=1471129203
> and 5.2.0-2:
> https://buildd.debian.org/status/fetch.php?pkg=digikam=amd64=4%3A5.2.0-2=1477261520
> yields:
>
> 5.1:
> [...]
> -- libgphoto2 execurables check...
> -- Found gphoto2: -lgphoto2_port;-lgphoto2 -lgphoto2_port -lm
> -- libgphoto2 found: TRUE
> -- Found LibUSB1: /usr/lib/x86_64-linux-gnu/libusb-1.0.so
> -- LibUSB1_FOUND= TRUE
> -- LibUSB1_INCLUDE_DIRS = /usr/include/libusb-1.0
> -- LibUSB1_LIBRARIES= /usr/lib/x86_64-linux-gnu/libusb-1.0.so
> -- libusb1 found: TRUE
> -- Libgphoto2 and libusb1 have been found.
> -- libgphoto2 API version >= 2.5
> -- libgphoto2 API version found:  2.5.10
> [...]
> --  libgphoto2 found. YES (optional)
> [...]
>
> 5.2:
> [...]
> -- Found gphoto2: /usr/lib/x86_64-linux-gnu/libgphoto2.so;/usr/lib/x86_64
> -linux-gnu/libgphoto2_port.so
> -- libgphoto2 found: TRUE
> -- Found LibUSB1: /usr/lib/x86_64-linux-gnu/libusb-1.0.so
> -- LibUSB1_FOUND= TRUE
> -- LibUSB1_INCLUDE_DIRS = /usr/include/libusb-1.0
> -- LibUSB1_LIBRARIES= /usr/lib/x86_64-linux-gnu/libusb-1.0.so
> -- libusb1 found: TRUE
> -- Libgphoto2 and libusb1 have been found.
> -- Command gphoto2 not found. Cannot identify GPhoto2 API version.
> [...]
> --  libgphoto2 found. NO  (optional)
> --  digiKam will be compiled without GPhoto2 camera drivers support.
> --  Please install the libgphoto2 (version >= 2.4.0) development package.
> --
> [...]
>
> I hope that helps.
> Best regards,
>
> Andreas
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages digikam depends on:
> ii  digikam-data  4:5.2.0-2
> ii  digikam-private-libs  4:5.2.0-2
> ii  libc6 2.24-5
> ii  libgcc1   1:6.2.0-9
> ii  libkf5configcore5 5.27.0-1
> ii  libkf5coreaddons5 5.27.0-1
> ii  libkf5filemetadata3   5.27.0-1
> ii  libkf5i18n5   5.27.0-2
> ii  libqt5core5a  5.6.1+dfsg-3+b1
> ii  libqt5gui55.6.1+dfsg-3+b1
> ii  libqt5sql55.6.1+dfsg-3+b1
> ii  libqt5sql5-mysql  5.6.1+dfsg-3+b1
> ii  libqt5sql5-sqlite 5.6.1+dfsg-3+b1
> ii  libqt5widgets55.6.1+dfsg-3+b1
> ii  libstdc++66.2.0-9
> pn  perl:any  
>
> Versions of packages digikam recommends:
> ii  chromium [www-browser]  53.0.2785.143-1
> ii  ffmpegthumbs4:16.08.0-1
> ii  firefox [www-browser]   49.0-4
> ii  google-chrome-stable [www-browser]  54.0.2840.71-1
> ii  konqueror [www-browser] 4:16.08.2-1
> ii  w3m [www-browser]   0.5.3-31
>
> Versions of packages digikam suggests:
> pn  digikam-doc 
> ii  systemsettings  4:5.8.2-1
>
> -- no debconf information
>




signature.asc
Description: OpenPGP digital signature

Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed

[Simon McVittie]

On Tue, 25 Oct 2016 at 15:39:46 -0300, Ben Armstrong wrote:
> #5  0x557569f9 in gui_position_components (total_width=1) at 
> gui.c:1355
> #6  0x5575982c in gui_resize_shell (pixel_width=, 
> pixel_height=pixel_height@entry=1) at gui.c:1470

Well, that looks like bad news: you presumably wanted every widget to be
more than 1x1 pixels.

Sorry, I don't have any insights into why this would be happening or
whether it's vim or Gtk that regressed.

> And then I flipped back to the editor window and it was scuttled in the same
> way as my original bug report. Would you like any more backtraces (e.g. at the
> points where I did 'continue' above? If so, which ones, just the last, or each
> one?)

If in doubt, more information is better than less information. Hopefully
it's always the GUI thread that's interesting (as it looks as though it
was on the one you quoted), so "bt" rather than "thread apply all bt"
would be sufficient.

S

Bug#842107: ITP: ableton-link -- synchronizes musical beat, tempo, and phase across multiple applications running on one or more devices

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: ableton-link
  Version : 1.0.0
  Upstream Author : Ableton AG, Berlin
* URL : https://www.ableton.com/en/link/
* License : GPL
  Programming Lang: C++
  Description : synchronizes musical beat, tempo, and phase across multiple 
applications running on one or more devices

 Ableton Link, a technology that synchronizes musical beat, tempo, and phase
 across multiple applications running on one or more devices. Applications on
 devices connected to a local network discover each other automatically and form
 a musical session in which each participant can perform independently: anyone
 can start or stop while still staying in time. Anyone can change the tempo, the
 others will follow. Anyone can join or leave without disrupting the session.

I intend to maintain this under the pkg-multimedia-team umbrella.
It is a B-D of pd-abl-link~ which i would also like to package.

Bug#839580: [request-tracker-maintainers] Bug#839580: request-tracker4: FTBFS in testing (failed tests)

[Dominic Hargreaves]

On Tue, Oct 11, 2016 at 10:44:28PM +0200, gregor herrmann wrote:
> On Mon, 10 Oct 2016 23:10:30 +0300, Niko Tyni wrote:
> 
> > Help untangling this mess would be very welcome, as both Dominic and I
> > are rather short on time. Tagging and copying possible candidates :)
> 
> Good news: I got the package to build.
> Bad news: Only by forcing gpg1 even harder in the test suite.
> 
> For gpg2 I guess we'd need a fake pinentry and maybe also changes to
> the secret key layout etc. -- Material for dkg maybe :)
> lib/RT/Test/GnuPG.pm looks interesting for setting the gpg config,
> lib/RT/Test.pm has import_gnupg_key.
> 
> What I don't know is if RT4 in the current state now works with
> gpg2 when the test suite passes with gpg1 ...
> Maybe forcing it to gpg1 (in etc/RT_Config.pm.in and debian/control)
> would buy some time. But in general I guess we want gpg2 both at
> buildtime and runtime.
> 
> 
> Before getting that far, I had to make some other changes to reduce
> the build failures to the gpg related ones.
> 
> After the package built I also fixed some lintian errors :)
> 
> Additionally I noted that the build tried to connect to IP addresses
> beyond localhost (my DNS server and my gateway).
> 
> Attached is a patch series.

Hi gregor et al,

Thanks so much for preparing this patch series and tidying up some
non-related issues with the package while I've been unavailable! I
applied your patch series to master and will upload it shortly.

Thanks also to Daniel for looking at some of the root causes and
possible solutions. It would be great to get this all unravelled with
the gpg1 to gpg2 transition. I wonder if at this stage it's safest
to keep RT using gpg1 for stretch, although of course if it's possible
to get it working in time that'd be even better.

Cheers,
Dominic.

Bug#837658: The main problem is still not fixed

[Adrian Bunk]

Control: reopen -1
Control: affects -1 =
Control: severity -1 important

The main problem that libfl_pic.a is not compiled with -fPIC is still 
not fixed.

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#842106: Please revert the change to build static libraries with -fPIC

[Adrian Bunk]

Source: publib
Version: 0.40-3
Severity: normal

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#842105: Please revert the change to build static libraries with -fPIC

[Adrian Bunk]

Source: cpputest
Version: 3.8-4
Severity: normal

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#842102: Please revert the change to build static libraries with -fPIC

[Adrian Bunk]

Source: ctn
Version: 3.2.0~dfsg-3.1
Severity: normal

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#841958: teamviewer is not DFSG compliant

[Hugo Lefeuvre]

Hi,

IMO teamviewer is not DFSG[0] compliant.

DFSG:

 * The license of a Debian component may not restrict any party from
   selling or giving away the software as a component of an aggregate
   software distribution containing programs from several different
   sources. *The license may not require a royalty or other fee for such
   sale*.

 * The license must not restrict anyone from making use of the program
   in a specific field of endeavor. For example, it may not restrict the
   program from *being used in a business*, or from being used for genetic
   research.

Teamspeak's license:

 * TeamViewer is FREE for personal/*non-commercial* use

 * As private use we understand any use of TeamViewer for *purposes that
   are neither directly nor indirectly paid*. It is not about whether the
   service itself is paid but whether the service is rendered within the
   context of the creation of an added value with some kind of financial
   compensation.

Regards,
 Hugo

[0] https://www.debian.org/social_contract#guidelines

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Bug#842101: Please revert the change to build static libraries with -fPIC

[Adrian Bunk]

Source: portaudio19
Version: 19+svn20140130-1.1
Severity: normal

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#842104: Please revert the change to build static libraries with -fPIC

[Adrian Bunk]

Source: i2util
Version: 1.6-1
Severity: normal

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#842103: ITP: pd-lib-builder -- common build system for Pure Data externals

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-lib-builder
  Version : 0.2.7
  Upstream Author : Katja Vetter
* URL : https://github.com/pure-data/pd-lib-builder
* License : Public Domain
  Programming Lang: Make
  Description : common build system for Pure Data externals

 Makefile based build-system for Pure Data external libraries, with the
 following characteristics:
 - defines build settings based on autodetected OS and architecture
 - defines rules to build Pd class- or lib executables from C or C++ sources
 - defines rules for libdir installation
 - defines convenience targets for developer and user
 - evaluates implicit dependencies for non-clean builds

I intend to maintain this package under the pkg-multimedia-maintainers umbrella
as part of the pd-* externals packaging effort.

Bug#842100: Please revert the change to build static libraries with -fPIC

[Adrian Bunk]

Source: binpac
Version: 0.44-2
Severity: normal

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#842099: Please revert the change to build static libraries with -fPIC

[Adrian Bunk]

Source: orbit2
Version: 1:2.14.19-2
Severity: normal

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#842029: haskell-devscripts-minimal: Extra operand in 'ln' command

[Clint Adams]

On Tue, Oct 25, 2016 at 03:03:59PM +0300, Ilias Tsitsimpis wrote:
> | Running ln -rs -T 
> debian/libghc-shake-doc/usr/share/doc/libghc-shake-doc/html/CHANGES.txt 
> debian/libghc-shake-doc/usr/share/doc/libghc-shake-doc/html/shake.txt 
> debian/libghc-shake-doc/usr/lib/ghc-doc/hoogle/libghc-shake-doc.txt
> | ln: extra operand 
> 'debian/libghc-shake-doc/usr/lib/ghc-doc/hoogle/libghc-shake-doc.txt'
> | Try 'ln --help' for more information.

In this particular case we want to exclude CHANGES.txt, but how do
we generalize that?

Bug#842098: Please revert the change to build static libraries with -fPIC

[Adrian Bunk]

Source: unicon
Version: 3.0.4-15
Severity: important

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#842097: Please revert the change to build static libraries with PIC

[Adrian Bunk]

Source: gadap
Version: 2.0-7
Severity: important

PIE by default in gcc was enabled in unstable a week ago.

There has recently been some confusion regarding the changes required
for using PIE by default.

Static libraries do not have to be compiled with -fPIC for this change,
-fPIE is sufficient and now the default when no flags are given.
Any upload (including binNMU) would have been enough to fix this.

Compiling static libraries with -fPIC is usually wrong (policy section 10.2).

Please revert the change to build static libraries with -fPIC.

Bug#842092: dh-r: Please provide variables known from cdbs helper for R packages

[Andreas Tille]

Hi,

I worked around the missing variables in the r-bioc-biocparallel
code by adding

debRreposname   := $(shell dpkg-parsechangelog | awk '/^Source:/ {print $$2}' | 
sed 's/r-\([a-z]\+\)-.*/\1/')
awkString   := "'/^(Package|Bundle):/ {print $$2 }'"
cranNameOrig:= $(shell awk "$(awkString)" DESCRIPTION)
cranName:= $(shell echo "$(cranNameOrig)" | tr A-Z a-z)
package := r-$(debRreposname)-$(cranName)
debRdir := usr/lib/R/site-library
debRlib := $(CURDIR)/debian/$(package)/$(debRdir)

to debian/rules.  Please note that the calculation of debRreposname
would be an enhancement over r-cran.mk since formerly you needed to
specify debRreposname if it was different from the default cran.

Please also note that I skipped some "if-else" statements to simplify
things - it would be safer to copy the code from r-cran.mk (and add
debRreposname code if you agree that this is more elegant).

BTW, I could even imagine that this kind of dh_fixperms becomes
unneeded at all since it makes probably sense to chmod -x all *.R
files in the package.  What do you think?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#837420: #837420 - dietlibc: FTBFS with bindnow and PIE enabled

[Thorsten Glaser]

Christian Seiler dixit:

>Yes, I fully intend to fix that - which is why I tagged the bug
>report "confirmed" when it was first reported, even while it
>was still of lower severity. I just had a lot of other stuff
>come up and didn't get to it yet. I had actually planned to
>take some time on Sunday for this, even before the severity of
>this bug was bumped.

Just please do so before I _have_ to take action because a
package of mine can be threatened to be removed from testing
when a dependency of it (namely dietlibc) has an RC bug.

The original response of mine was, indeed, too quick/jerky,
my apologies. (Maybe because I used to maintain dietlibc.
Since I’m back now, if you wish I can still help out.)

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"

Bug#842095: RFS: qspeakers/1.0-1 [ITP] -- new package of a loudspeaker design software

[Benoît Rouits]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

 I am looking for a sponsor for my package "qspeakers"

 * Package name: qspeakers
   Version : 1.0-1
   Upstream Author : Benoît Rouits
 * URL : http://brouits.free.fr/qspeakers/
 * License : GPL-3+
   Section : misc

  It builds those binary packages:

qspeakers  - loudspeaker design software

  To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/qspeakers


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/q/qspeakers/qspeakers_1.0-1.dsc


More information: This package closes #842087 (wnpp).

 QSpeakers is a simple graphical program that
 simulates common acoustical enclosures behaviour
 to help designing loudspeaker systems, based on
 the loudspeaker driver's Thiele / Small parameters
 and the chosen enclosure type.
 .
 This software is mostly useful for do-it-yourself
 loudspeaker enthusiasts, acoustics teaching, and
 to a lesser extent, for loudspeaker engineering.

I am also the upstream author of this program. There is no similar 
software in Debian, yet. But there are similar software on other 
operating systems (think of WinISD). This software depends on Qt5 
(widgets) and Qwt6 (frequency response plot).


I got a positive return from debian-science mailing-list on the idea of 
packaging that software for Debian. I hope the package is well done.

Thank you for your review and possible sponsorship !

Regards,
Benoît

Bug#842096: Buggy magic: Many files are dis-detected as Algol68

[Christoph Biedl]

Package: file
Version: 1:5.29-1
Severity: normal
Tags: upstream

Starting from 1:5.29-1 on, many text files get mis-detected as
"Algol 68 source text". I plan to fix this soon; if all else
fails by disabling the entire algol68 magic.

Christoph

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

Kernel: Linux 4.8.2 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: unable to detect

Versions of packages file depends on:
ii  libc6  2.24-3
ii  libmagic1  1:5.29-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

file recommends no packages.

file suggests no packages.

-- no debconf information



signature.asc
Description: Digital signature

Bug#842094: digikam: libgphoto2 support missing

[Andreas Schneider]

Package: digikam
Version: 4:5.2.0-2
Severity: important

Dear Maintainer,

digikam can't access my camera anymore, after upgrading to version 5.2.0-2. The
reason is that libgphoto2 support is missing in that version whereas it was
available in 5.1.0-2. This, or a similar problem, had occured a number of times
before (#785492 and #821178) and disappeared subsequently.

Comparing the build logs for 5.1.0-2:
https://buildd.debian.org/status/fetch.php?pkg=digikam=amd64=4%3A5.1.0-2=1471129203
and 5.2.0-2:
https://buildd.debian.org/status/fetch.php?pkg=digikam=amd64=4%3A5.2.0-2=1477261520
yields:

5.1:
[...]
-- libgphoto2 execurables check...
-- Found gphoto2: -lgphoto2_port;-lgphoto2 -lgphoto2_port -lm
-- libgphoto2 found: TRUE
-- Found LibUSB1: /usr/lib/x86_64-linux-gnu/libusb-1.0.so
-- LibUSB1_FOUND= TRUE
-- LibUSB1_INCLUDE_DIRS = /usr/include/libusb-1.0
-- LibUSB1_LIBRARIES= /usr/lib/x86_64-linux-gnu/libusb-1.0.so
-- libusb1 found: TRUE
-- Libgphoto2 and libusb1 have been found.
-- libgphoto2 API version >= 2.5
-- libgphoto2 API version found:  2.5.10
[...]
--  libgphoto2 found. YES (optional)
[...]

5.2:
[...]
-- Found gphoto2: /usr/lib/x86_64-linux-gnu/libgphoto2.so;/usr/lib/x86_64
-linux-gnu/libgphoto2_port.so
-- libgphoto2 found: TRUE
-- Found LibUSB1: /usr/lib/x86_64-linux-gnu/libusb-1.0.so
-- LibUSB1_FOUND= TRUE
-- LibUSB1_INCLUDE_DIRS = /usr/include/libusb-1.0
-- LibUSB1_LIBRARIES= /usr/lib/x86_64-linux-gnu/libusb-1.0.so
-- libusb1 found: TRUE
-- Libgphoto2 and libusb1 have been found.
-- Command gphoto2 not found. Cannot identify GPhoto2 API version.
[...]
--  libgphoto2 found. NO  (optional)
--  digiKam will be compiled without GPhoto2 camera drivers support.
--  Please install the libgphoto2 (version >= 2.4.0) development package.
--
[...]

I hope that helps.
Best regards,

Andreas



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

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

Versions of packages digikam depends on:
ii  digikam-data  4:5.2.0-2
ii  digikam-private-libs  4:5.2.0-2
ii  libc6 2.24-5
ii  libgcc1   1:6.2.0-9
ii  libkf5configcore5 5.27.0-1
ii  libkf5coreaddons5 5.27.0-1
ii  libkf5filemetadata3   5.27.0-1
ii  libkf5i18n5   5.27.0-2
ii  libqt5core5a  5.6.1+dfsg-3+b1
ii  libqt5gui55.6.1+dfsg-3+b1
ii  libqt5sql55.6.1+dfsg-3+b1
ii  libqt5sql5-mysql  5.6.1+dfsg-3+b1
ii  libqt5sql5-sqlite 5.6.1+dfsg-3+b1
ii  libqt5widgets55.6.1+dfsg-3+b1
ii  libstdc++66.2.0-9
pn  perl:any  

Versions of packages digikam recommends:
ii  chromium [www-browser]  53.0.2785.143-1
ii  ffmpegthumbs4:16.08.0-1
ii  firefox [www-browser]   49.0-4
ii  google-chrome-stable [www-browser]  54.0.2840.71-1
ii  konqueror [www-browser] 4:16.08.2-1
ii  w3m [www-browser]   0.5.3-31

Versions of packages digikam suggests:
pn  digikam-doc 
ii  systemsettings  4:5.8.2-1

-- no debconf information

Bug#841222: Acknowledgement (RFS: patat)

[Félix Sipma]

On 2016-10-23 11:51-0700, Sean Whitton wrote:
> You should use "Forwarded: not-needed" (see DEP-3).

This does not seem to work with gbp-pq (see #785274), I propose to add this as
soon as gbp-pq supports DEP-3.

>>> 2. You can fix all of these Lintian tags, except possibly
>>> hardening-no-fortify-functions.  You should definitely deal with the
>>> warnings.
>>> 
>>> W: patat-dbgsym: debug-file-with-no-debug-symbols
>> 
>> I've updated debian/rules to something matching
>> stylish-haskell.
> 
> Okay.  I'll take a proper look soon.

Thanks!

>>> I: patat: spelling-error-in-binary usr/bin/patat Nam Name
>>> I: patat: spelling-error-in-binary usr/bin/patat isn't isn't
>>> I: patat: spelling-error-in-binary usr/bin/patat forward forward
>>> I: patat: spelling-error-in-binary usr/bin/patat upto up to
>>> I: patat: spelling-error-in-binary usr/bin/patat discontigous discontiguous
>>> I: patat: spelling-error-in-binary usr/bin/patat uncomplete incomplete
>>> I: patat: spelling-error-in-binary usr/bin/patat The The
>> 
>> Not sure about this one... Is "patat" too generic for lintian? I've
>> added this to debian/lintian-overrides.
> 
> I don't understand.  It is pointing out misspellings, such as
> 'uncomplete', somewhere in the upstream source.  You can add a quilt
> patch to fix them, and forward it upstream.

As I didn't found anything matching these errors in the source, I thought it
was a generic error message concerning the binary name.

Now, that I understood the purpose of this check, I can only found these
mistakes in the binary itself, so I guess these are in the dependencies...

>>> I: patat: hardening-no-bindnow usr/bin/patat I: patat:
>>> hardening-no-pie usr/bin/patat
>>> 
>>> I think that in order to pass hardening options to gcc, if you're
>>> willing to work on that, you'll need to abandon the CDBS build system
>>> you're using at present.  See the Makefile for keysafe[1] (not yet in
>>> Debian) to see how to pass the options, and the rules file for the
>>> stylish-haskell package to see how to do without CDBS.
>> 
>> After reading this Makefile, I'm not sure how keysafe avoids
>> hardening-no-bindnow and hardening-no-pie... Do you have any clue?
> 
> The Makefile propagates LDFLAGS, CFLAGS and CPPFLAGS through to ghc.
> Then you enable all hardening in your d/rules,[1] and the right flags
> get set by debhelper.
> 
> [1] https://wiki.debian.org/Hardening

I would like to wait a little before adding this: the default flags added to
gcc seems quite new, so I propose to have a look again when things stabilize.

>>> 3. Please run upstream's test suite during the package build.
>> 
>> Should be done now, I'm not sure about how I run tests... See
>> debian/rules override_dh_auto_test
> 
> Okay, I'll look later.

Thanks.

>> Concerning the last lintian warning (binary-without-manpage), I'm not
>> sure it will add anything to "--help", and it is going to add an
>> overhead to maintain the package... If it's not required I would
>> prefer not to do anything with this.
> 
> Adding manpages is one of the things that Debian does to standardise and
> bring together the different programs that are part of the Debian
> system.  I'd strongly encourage you to be part of this QA effort.
> 
> With regard to maintenance, hopefully you can persuade upstream to adopt
> your manpage, so there wouldn't be any overhead.
> 
> In the meantime, you can use help2man to generate the manpage.  Note
> that you shouldn't run help2man during the package build, as it's a
> notorious source of FTBFS bugs.  Instead, add a target to d/rules to
> generate the manpage.  See the ocrmypdf source package's d/rules.
> 
> If help2man is insufficient, see again stylish-haskell where I use
> asciidoctor.

I'll try to add a manpage using help2man.


Concerning DHG's package-plan, I can't run the tests myself, ghc seems to be
broken in my chroot due to hardening flag -pie (see #712228). So I propose to
add patat later, when things calm down.


signature.asc
Description: PGP signature

Bug#842052: [Pkg-freeradius-maintainers] Bug#842052: freeradius-ldap: LDAP-Group escapes UserDN twice somehow and get no useful result then

[Michael Stapelberg]

control: tags -1 severity normal
control: tags -1 tags + help

On Tue, Oct 25, 2016 at 4:17 PM, Markus Wigge  wrote:

> Package: freeradius-ldap
> Version: 2.2.5+dfsg-0.2
> Severity: important
> Tags: upstream
>
> Dear Maintainer,
>
> I encountered severe problems trying to match users to their LDAP Groups.
>
> Within the inner-tunnel config I check the group ACL for a given user like
>  this:
>
> if (LDAP-Group == "NET_eduroam") {
> noop
> }
> else {
> reject
> }
>
> Unfortunately the groups are nested so that I need to query the LDAP server
> (Active Directory) like this:
>
> groupmembership_filter = "(&(objectClass=group)(member:
> 1.2.840.113556.1.4.1941:=%{control:Ldap-UserDn}))"
>
> That query is working fine with ldapsearch and well tested.
>
> The rlm_ldap module needs to find the UserDN first to put it in this
> filter.
>
> Here I guess lies some kind of bug. Some debug output:
> 
> [ldap] performing search in dc=XXX,dc=YY, with filter
> (sAMAccountName=foobar)
> 
> expand: (&(objectClass=group)(member:1.2.840.113556.1.4.1941:=%{
> control:Ldap-UserDn}))
> -> (&(objectClass=group)(member:1.2.840.113556.1.4.1941:=CN\3dBar\5c\5c\2c
> Foo\2cOU\3dAccounts\2cDC\3dXXX\2cDC\3dYY))
>
> rlm_ldap finds the correct user object and reads its DN. Then it places the
> DN inside the group filter and escapes the whole string. But as it appears
> to
> me the DN was already escaped beforehand and is now scaped twice.
> See the "\5c\5c" part.
>
> The CN of the User in the directory has the form:
> CN: , 
>
> Then DN is according to that
> DN: CN=Bar\, Foo,OU=
>
> The very same request is working fine with "ldapsearch" when I remove the
> second "\5c" occurance.
>
>
> I assume this bug is important because it might lead to very unexpected
> results.
>

Please see https://www.debian.org/Bugs/Developer#severities for how the
Debian bug severities are to be interpreted. “important” is explained as “a
bug which has a major effect on the usability of a package […]”, for which
I don’t see any evidence here — there seems to be a problem with an
individual setup in an individual module. Hence, downgrading to “normal”.


>
> On a second system I tried a backported version for freeradius 3.0.12 and
> cannot reproduce the error. So I think this was fixed with the rewrite
> of the rlm_ldap module.
>

I can’t spend any time on this issue. I’m focusing on getting version 3
into Debian. By the way, if you’re using the 3.0.12+dfsg-1 package, please
respond to my question in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797181#69

You might want to try reporting this issue upstream at
https://github.com/FreeRADIUS/freeradius-server/


>
> Hopefully some of you are better in C and are able to produce a small
> patch to fix this issue.
>
>
> Regards,
> Markus
>
>
> -- System Information:
> Debian Release: 8.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages freeradius-ldap depends on:
> ii  libc6  2.19-18+deb8u6
> ii  libldap-2.4-2  2.4.40+dfsg-1+deb8u2
> ii  freeradius 2.2.5+dfsg-0.2
> ii  freeradius-common  2.2.5+dfsg-0.2
> ii  freeradius-krb52.2.5+dfsg-0.2
> ii  freeradius-ldap2.2.5+dfsg-0.2
> ii  freeradius-utils   2.2.5+dfsg-0.2
> ii  libfreeradius2 2.2.5+dfsg-0.2
>
>
>
> freeradius-ldap recommends no packages.
>
> freeradius-ldap suggests no packages.
>
> ___
> Pkg-freeradius-maintainers mailing list
> pkg-freeradius-maintain...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-
> freeradius-maintainers
>



-- 
Best regards,
Michael

Bug#842093: libupnp: CVE-2016-8863

[Salvatore Bonaccorso]

Source: libupnp
Version: 1:1.6.19+git20141001-1
Severity: grave
Tags: security upstream

Hi,

the following vulnerability was published for libupnp. The issue is
reproducible easily if libupnp compiled with ASAN and following the
reproducing steps in the upstream bugreport.

CVE-2016-8863[0]:
Buffer overflow in create_url_list

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-8863
[1] https://sourceforge.net/p/pupnp/bugs/133/

Regards,
Salvatore

Bug#840348: cinnamon: On a HiDPI screen unlock screen hardly usable

[john . kirk]

 Quoting john.k...@vfemail.net:


Quoting Margarita Manterola :


Hola John Kirk!


Package: cinnamon
Version: 3.0.7-1
Followup-For: Bug #840348


If possible, it would be nice if you could just reply to the emails you
get, so
that they show up as part of the same conversation for us. When you do
the
"Followup-For" they create new conversations and make it hard to follow
which
mails belong to which issues.


Cinnamon-screensaver is 3.0.1-1
New user is created and screenshot is attached. Still unusable - half
of window
at bottom left.


That screenshot is confusing, is that all that was on the screen? Or
did it
somehow get cut?

Could you take a screenshot (for this same dummy user) that shows the
Display
tool?

Also, can you attach the output of xrandr?

Finally, is HiDPI getting selected automatically or have you selected
manually?

--
Thanks,Marga



Hello,

The follow-ups have been done by the report bug tool. Probably a bug is
here since i used the reply button.

The screenshot was cut for reducing the size. It shows the full bottom
left corner of the screen (second screenshot from this bug report).

Now i can't take a screenshot from Debian testing (removed), but the
config is the same so there are 2 screenshots from Debian stable +
backported Cinnamon. I think they are actual since the bug is also here
(1 screenshot from this bug report).

HiDPI works from installation so it is selected automatically. User
interface scaling option is set to Auto.

I also ask you to consider this bug :
https://lists.debian.org/debian-backports/2016/09/msg00026.html

Best wishes,
John

 
 


Hello,

I can confirm that the bug is still in testing (as of today). Screenshot 2.
Looks like it thinks that the display is 4 times bigger and shows only
1/4. 

Best wishes, 
John


-
75% of Americans don't like Clinton or Trump.
Don't waste your vote, say 'No' to the US Oligarchy and give it to Gary Johnson.
(paid for by VFEMail)

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!

Commercial and Bulk Mail Options!  

Bug#842080: [pkg-lxqt-devel] Bug#842080: Bug#842080: additional information

[Alf Gaida]

On Tue, 25 Oct 2016 15:53:48 -0400
Jape Person  wrote:
> Do you suppose that my slightly odd system configuration could 
> be at fault? I do not have any of the regular desktop 
No, not relly - that was my fault

> Please let me know if there's anything I might do from a testing 
> standpoint. I might try grabbing libfm-qt3 from sid to see if 
The sid package will fix it, there are 10 new symbols in the new
lib, but it seems that they are not called directly so dh had no
chance to calculate the dependencies right. Have to learn about it.
> I do like pcmanfm-qt. Like the rest of the lxqt stuff it's very 
> fast and responsive. It has required me to adjust some habits. I 
> had figured out how to use thunar in the Xfce desktop 
> environment without ever touching the mouse, and I don't seem 
> able to do that with pcmanfm. Then again, I haven't had a lot of 
> time to explore it.
Glad you like it. If there are missed functions or things we can
improve we will be glad if you write a request here:
https://github.com/lxde/pcmanfm-qt/issues

Cheers Alf

Bug#842092: dh-r: Please provide variables known from cdbs helper for R packages

[Andreas Tille]

Package: dh-r
Severity: wishlist

Hi,

I'm starting to convert some of my R packages from cdbs helper to dh-r.
When converting r-bioc-biocparallel I wanted to turn the code to fix the
permissions of a file into

override_dh_fixperms:
dh_fixperms
chmod -x $(debRlib)/$(cranNameOrig)/snow/RMPInode.R

Unfortunately the variables known from cdbs helper do not exist in dh-r.
I think it would increase the acceptance of dh-r if these would be
available and could be used in the manner above.

Kind regards and thanks for the great dh-r tool

 Andreas.


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

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

Bug#842091: autopkgtest-virt-qemu: better support for read-only rootfs

[Simon McVittie]

Package: autopkgtest
Version: 4.1
Severity: wishlist
Tags: patch

A project I'm currently working on uses a read-only root filesystem
under normal circumstances, mounting it rw only when an upgrade is
desired. This makes autopkgtest fail horribly when testing our disk
images, which is (at least mostly) addressed by the patches I've
attached here. Please consider.

Thanks,
S

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.3.1
ii  libdpkg-perl1.18.10
ii  procps  2:3.3.12-2
ii  python3 3.5.1-4
ii  python3-debian  0.1.29

Versions of packages autopkgtest recommends:
ii  autodep8  0.8

Versions of packages autopkgtest suggests:
pn  lxc  
pn  lxd-client   
ii  qemu-system  1:2.7+dfsg-1
ii  qemu-utils   1:2.7+dfsg-1
ii  schroot  1.6.10-2+b1

-- no debconf information
>From 686bc470ce39630c37fd7e3436ba3bc706a8f040 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 25 Oct 2016 19:34:24 +0100
Subject: [PATCH 1/6] VirtSubproc: open arbitrary files in binary mode

It doesn't actually matter when we only use their fileno(), but it's
better to be consistent.

Signed-off-by: Simon McVittie 
---
 lib/VirtSubproc.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/VirtSubproc.py b/lib/VirtSubproc.py
index ba87740..1aeb673 100644
--- a/lib/VirtSubproc.py
+++ b/lib/VirtSubproc.py
@@ -38,7 +38,7 @@ import shutil
 import adtlog
 
 progname = ""
-devnull_read = open('/dev/null', 'r')
+devnull_read = open('/dev/null', 'rb')
 caller = __main__
 copy_timeout = int(os.getenv('AUTOPKGTEST_VIRT_COPY_TIMEOUT', '300'))
 
@@ -512,9 +512,9 @@ def copyupdown_internal(wh, sd, upp):
 if not dirsp:
 rune = 'cat %s%s' % ('><'[upp], remfileq)
 if upp:
-deststdout = open(sd[idst], 'w')
+deststdout = open(sd[idst], 'wb')
 else:
-srcstdin = open(sd[isrc], 'r')
+srcstdin = open(sd[isrc], 'rb')
 status = os.fstat(srcstdin.fileno())
 if status.st_mode & 0o111:
 rune += '; chmod +x -- %s' % (remfileq)
-- 
2.10.1

>From e46a2dff9d4c93a3d5a99849b3c741e76084 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 25 Oct 2016 19:35:03 +0100
Subject: [PATCH 2/6] VirtSubproc: if check_exec status is nonzero, include
 stderr in message

If a command fails, it's usually interesting to know why.

Signed-off-by: Simon McVittie 
---
 lib/VirtSubproc.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/VirtSubproc.py b/lib/VirtSubproc.py
index 1aeb673..a20c337 100644
--- a/lib/VirtSubproc.py
+++ b/lib/VirtSubproc.py
@@ -183,8 +183,8 @@ def check_exec(argv, downp=False, outp=False, timeout=0):
  stdout=stdout, stderr=subprocess.PIPE)
 
 if status:
-bomb("%s%s failed (exit status %d)" %
- ((downp and "(down) " or ""), argv, status))
+bomb("%s%s failed (exit status %d, stderr %r)" %
+ ((downp and "(down) " or ""), argv, status, err))
 if err:
 bomb("%s unexpectedly produced stderr output `%s'" %
  (argv, err))
-- 
2.10.1

>From 815b8fdcceb9259ef186a35698cc41d25cf7ff56 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 25 Oct 2016 19:38:02 +0100
Subject: [PATCH 3/6] qemu: put the shared directory in /run

If the virtual machine's root filesystem is read-only, we won't
be able to create /autopkgtest.

Signed-off-by: Simon McVittie 
---
 virt/autopkgtest-virt-qemu | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/virt/autopkgtest-virt-qemu b/virt/autopkgtest-virt-qemu
index cdae1de..d9c59a2 100755
--- a/virt/autopkgtest-virt-qemu
+++ b/virt/autopkgtest-virt-qemu
@@ -218,10 +218,10 @@ def setup_shared(shared_dir):
 
 term = VirtSubproc.get_unix_socket(os.path.join(workdir, 'ttyS1'))
 
-term.send(b'''mkdir -p -m 1777 /autopkgtest
-mount -t 9p -o trans=virtio,access=any autopkgtest /autopkgtest
-chmod 1777 /autopkgtest
-touch /autopkgtest/done_shared
+term.send(b'''mkdir -p -m 1777 /run/autopkgtest/shared
+mount -t 9p -o trans=virtio,access=any autopkgtest /run/autopkgtest/shared
+chmod 1777 /run/autopkgtest/shared
+touch /run/autopkgtest/shared/done_shared
 ''')
 
 with VirtSubproc.timeout(10, 'timed out on client shared 

Bug#842083: fai-client: fails to upgrade from 'jessie' - trying to overwrite /usr/lib/fai/mount2dir

[Thomas Lange]

I've only moved the mount2dir executable from the fai-nfsroot package
to the fai-client package. The fai-client does not replace
fai-nfsroot.

To fix this bug is it only possible by defining a breaks or replaces?
Which breaks do I have to define then?

BTW, fai-nfsroot is never installed on a normal system. It will only
be installed inside a nfsroot.
-- 
regards Thomas