Bug#846556: RFS: h5py/2.6.0-2

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

* Package name: h5py
  Version : 2.6.0-2
  Upstream Author : Andrew Colette
* URL : http://www.h5py.org/
* License : BSD
  Section : python

It builds those binary packages:

  python-h5py - general-purpose Python interface to hdf5 (Python 2)
  python-h5py-dbg - debug extension for h5py (Python 2)
  python-h5py-doc - h5py documentation
  python3-h5py - general-purpose Python interface to hdf5 (Python 3)
  python3-h5py-dbg - debug extension for h5py (Python 3)

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/h5py/h5py_2.6.0-2.dsc


Changes since the last upload:

  * Cherry-pick upstream patch fixing HDF5 detection.
- New patch Package-Config-Fix-Detection.patch.
Thanks to Iain Lane for reporting (Closes: #846351)
  * Bump standards version to 3.9.8, no changes required.
  * Use HTTPS for the copyright Format URI.
  * Drop superfluous Testsuite field.
  * Mark -doc package Multi-Arch: foreign.
  * Suggest install of -doc package.
  * Call dh_numpy{,3} in dh_python{2,3} overrides.
  * Enable hardening.
  * Cosmetic fixups in rules file.
  * Update gbp.conf with current repository layout.
  * Simplify the packaging testsuite.

Regards,
Ghislain Vaillant

Bug#846539: ITP: gwcs -- Tools for managing the World Coordinate System of astronomical data

[Ole Streicher]

Dear Miguel,

would you mind to put the packaging under Debian Astro team maintenance?
This would make contributions of others easier, and we would also help
you with questions and finally sponsor the package when it is ready.

On 01.12.2016 23:56, Miguel de Val-Borro wrote:
> * Package name: gwcs
>   Version : 0.5.1
>   Upstream Author : Nadia Dencheva 
> * URL : https://github.com/spacetelescope/gwcs
> * License : BSD-3-Clause
>   Programming Lang: Python
>   Description : Tools for managing the World Coordinate System of 
> astronomical data
> 
> GWCS supports a data model which includes the entire transformation pipeline
> from input coordinates to world coordinates.  The goal of the package is to
> provide a flexible toolkit which is easily extendible by adding new transforms
> and frames.
> 
> The package will be maintained using a git repository on alioth.

The Debian Astro web page is https://blends.debian.org/astro

I am forwarding this to our mailing list as well:

https://lists.debian.org/debian-astro

Best regards

Ole

Bug#846190: RFS: openldap/2.4.44+dfsg-2 [RC]

[Arturo Borrero Gonzalez]

On 2 December 2016 at 05:52, Ryan Tandy  wrote:
> I updated the package on mentors to add one more fix:
>
> +  * Fix slapd-smbk5pwd failing to upgrade when there are no instances of
> the
> +overlay configured.
>
> affecting jessie-to-stretch upgrades when the slapd-smbk5pwd package is
> installed, but not used anywhere in the slapd configuration.
>

Something is wrong with the mentors upload:

dget 
https://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.44+dfsg-2.dsc
dget: retrieving
https://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.44+dfsg-2.dsc
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  2918  100  29180 0   5469  0 --:--:-- --:--:-- --:--:--  5474
dget: retrieving
https://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.44+dfsg.orig.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found
dget: curl openldap_2.4.44+dfsg.orig.tar.gz
https://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.44+dfsg.orig.tar.gz
failed


https://mentors.debian.net/debian/pool/main/o/openldap/ seems to contains only:

openldap_2.4.23.orig.tar.gz18-Apr-2015 02:334.3M
openldap_2.4.31.orig.tar.gz26-Mar-2016 01:364.5M
openldap_2.4.40+dfsg.orig.tar.gz29-Jun-2015 04:074.6M
openldap_2.4.40.orig.tar.gz21-Oct-2014 17:004.6M
openldap_2.4.44+dfsg-2.debian.tar.xz02-Dec-2016 04:36153K
openldap_2.4.44+dfsg-2.dsc02-Dec-2016 04:362.8K


Please, re-upload.

Bug#846554: monkeysphere-authentication add-id-certifier fails even when given an unambiguous full fingerprint

[Daniel Kahn Gillmor]

Package: monkeysphere
Version: 0.40-2
Severity: important
Control: affects -1 gnupg
Control: tags -1 upstream

Modern versions of GnuPG print out the fingerprints of all subkeys in
addition to the primary key, especially when doing --list-colons.

This causes m-a c+ to fail due to a perceived ambiguity:

0 root@tester:~# monkeysphere-authentication c+ 
0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
More than one fingerprint found:
0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
C7898678D456E06B968D50D3125868EA4BFA08E4
6639DB0BBB61AB268BF7D5F9DC104C4E0CA757FB
D568EF3E553B8E24FB07A561C61BD3EC21484CFF
EB9691287A7ADDE3757D911EA52401B11BFDFA5C
139C1D8C5E58B42FFE7FA04C3714729214D5DA70
EDB2E74F56FCF2B67297B73524ECFF5AFF68370A
B29F4E9BEE4BFC4C75A2936EA70A96E1439EA852
Please use a more specific key ID.
255 root@tester:~#

This should be fixed by doing better filtering in the fingerprint
selection step, probably by limiting the selection to the first fpr:
record after a pub: record.

   --dkg

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

Kernel: Linux 4.8.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 monkeysphere depends on:
ii  adduser   3.115
ii  gnupg 2.1.16-2
ii  libcrypt-openssl-rsa-perl 0.28-3+b1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc3-3
ii  lockfile-progs0.1.17

Versions of packages monkeysphere recommends:
ii  agent-transfer   0.40-2
ii  cron 3.0pl1-128
ii  netcat-openbsd [netcat]  1.105-7
ii  netcat-traditional [netcat]  1.10-41
ii  openssh-client   1:7.3p1-3+b1
ii  socat1.7.3.1-2
ii  ssh-askpass  1:1.2.4.1-9

Versions of packages monkeysphere suggests:
ii  msva-perl [monkeysphere-validation-agent]  0.9.2-1

-- Configuration Files:
/etc/monkeysphere/monkeysphere-authentication.conf changed [not included]

-- no debconf information

Bug#846555: casacore: FTBFS on mipsel: tConvert test fails

[Emilio Pozuelo Monfort]

Source: casacore
Version: 2.1.0-3
Severity: serious

Your package failed to build on mipsel, but it built in the past:

99% tests passed, 1 tests failed out of 447

Total Test time (real) = 350.07 sec

The following tests FAILED:
447 - tConvert (Failed)
Errors while running CTest

Full logs at:

https://buildd.debian.org/status/fetch.php?pkg=casacore=mipsel=2.1.0-3%2Bb3=1480526690

Emilio

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

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)

Bug#843108: [PKG-Openstack-devel] Bug#843108: python-django-horizon: not compatible with Django 1.10 or JQuery 3.1.1-1

[Goirand Thomas (aka zigo)]

I uploaded a new python-xstatic-jquery with jquery 1 so it will work now.

On Dec 2, 2016 7:03 AM, Daniel Baumann 
 wrote:

severity 843108 serious
thanks

Hi,

using sid of today with jquery 3.x the dashboard is basically not usable
since most of the menues are not clickable and thus defeating the
purpose of having a webfrontend in the first place, bumping the severity
of the bug accordingly.

Regards,
Daniel

___
Openstack-devel mailing list
openstack-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/openstack-devel

Bug#831322: dep11 - Xenial

[Poil]

Hi,

We have the same issue when mirroring Xenial repository since 2 or 3 
weeks; we refresh our repository all hours, on odd hour it's working, on 
even hour it's not working


Cleanup mirror.
unlink 
.temp/dists/xenial-updates/multiverse/dep11/.nfs0022867c0dd4: 
Device or resource busy at /data/mirrors/env/usr/bin/debmirror line 2704.
releasing 1 pending lock... at 
/usr/share/perl5/vendor_perl/LockFile/Simple.pm line 206.

Build step 'Execute shell' marked build as failure

Best regards

Bug#837516: icedove: open in browser fails

[Carsten Schoenert]

Hello Jens,

On Sat, Nov 12, 2016 at 04:53:22PM +0100, Jens Reyer wrote:
[...] 
> 
> Possible workarounds (successfully tested):
> ===
> 1. Create a new profile
> 2. Or reinstall the transitional package:
>$ sudo apt install iceweasel
> 3. Or manually create a compatibility link:
>$ sudo ln -s /usr/bin/x-www-browser /usr/bin/iceweasel
> 4. Or fix mimeTypes.rdf (replace all broken "/usr/bin/iceweasel"
>occurrences (requires icedove restart):
>$ for file in $(find .icedove/ -name mimeTypes.rdf); do sed -i 
> "s|/usr/bin/iceweasel|/usr/bin/x-www-browser|g" "$file" ; done
> 
> I went for #4, so this is fixed for me now.

thank you for your analysis of this problem, I was affected by this
problem too while working on the Thunderbird transition.

I also tend to your suggested solution on point 4 as the correct way is
using x-www-browser instead of some specific browser binary in the
mimeTypes.rdf file.
I modified the new prepared starting wrapper script for the thunderbird
transition in this way.

Regards
Carsten

Bug#846553: RFS: dvtm/0.15-2

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: dvtm
  Version : 0.15-2
  Upstream Author : Marc Andre Tanner 
* Url : http://www.brain-dump.org/projects/dvtm
* Licenses: MIT/X
  Section : utils

It builds those binary packages:

  * dvtm

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

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

Alternatively, one can download the package with dget using this command:
dget -x https://mentors.debian.net/debian/pool/main/d/dvtm/dvtm_0.15-2.dsc

More information about dvtm can be obtained from
http://www.brain-dump.org/projects/dvtm

Changes since last upload:

  * debian/patches/restore-signal-handlers.patch: Restore default signal
handlers for child processes. See #841090 for detailed discussion.
+ Thanks: Ian Jackson 
  * patches/highlight-selected-tag.patch: Make selected tag in bar more
contrast.

Regards,
  Dmitry Bogatov

Bug#846531: Re[2]: Bug#846531: lldb-3.8 and lldb-3.9 are completely unusable in stretch (multiply problems); fix them or remove from scretch

[Sylvestre Ledru]

Le 01/12/2016 à 23:24, Askar Safin a écrit :
>> Please report a bug per issue. It is too hard to track otherwise.
> Is this okey if I create several bugs which differ in title and all point to 
> this bug?
> 
yes, sure

S

Bug#846552: hugo: New upstream version available

[Christian von Kietzell]

Package: hugo
Version: 0.16-2
Severity: wishlist

Dear Maintainer,

a new upstream version (0.17) of Hugo has been available for about 2
months now. Could you please package it for Debian? There are a few
version interesting new features available:

* multi-language support
* content expiration

Cheers,
  Chris

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_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 hugo depends on:
ii  libc6  2.24-7

hugo recommends no packages.

hugo suggests no packages.

-- no debconf information

Bug#843351: mutt FTCBFS: compiles build tools with the host architecture compiler

[Antonio Radici]

Control: tag -1 +pending

On Sun, Nov 06, 2016 at 09:31:42AM +0100, Helmut Grohne wrote:
> Source: mutt
> Version: 1.7.1-2
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> mutt fails to cross build from source, because it compiles build tools
> such as makedoc or mutt_md5 using the host architecture compiler. Beyond
> that, configure misdetect the permission for /var/mail causing
> mutt_dotlock to be skipped.
> 
> Using the build architecture compiler for build tools is not entirely
> trivial, because those tools include config.h. It generally contains
> test results for the host architecture, which may be different for the
> host architecture. Thus config.h must not be included when using the
> build architecture compiler. This may be considered a regression for
> native builds and thus unsuitable for upstream. I don't know a proper
> fix here.
> 
> Still the attached patch makes cross builds work on Debian. Please
> consider applying it.
> 

Thanks for the patch. I'll apply it in the next version.

Bug#845067: mutt: Crash when scrolling past the end of a message

[Antonio Radici]

Control: tag -1 +moreinfo

On Sun, Nov 20, 2016 at 01:47:14AM +, Sam Morris wrote:
> Package: mutt
> Version: 1.7.1-3
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I triggered this by pressing space while at the end of a message.
> Backtrace attached...

Hi,
could you check with 1.7.1-5 and verify if it's still reproducible?
Thanks!

Bug#844021: Pending fixes for bugs in the libnative-platform-java package

[pkg-java-maintainers]

tag 844021 + pending
thanks

Some bugs in the libnative-platform-java package are closed in
revision b36b795efd6d814b25541bbd61b514ec0c39bd1c in branch 'master'
by Kai-Chung Yan (殷啟聰)

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/libnative-platform-java.git/commit/?id=b36b795

Commit message:

d/control: Breaks libgradle-core-java (<< 3.1~) (Closes: #844021)

Bug#845227: [Pkg-javascript-devel] Bug#845227: generate sub modules like lodash.isplainobject

[Pirate Praveen]

On തിങ്കള്‍ 21 നവംബര്‍ 2016 10:19 വൈകു, Pirate Praveen wrote:
> Some dependencies for gulp [1] declare dependencies like
> lodash.assignwith which current lodash package is not providing.
> 
> Though this would require updating unglifyjs as current version throws
> and error when trying to generate these.


uglifyjs is updated to 2.7.4. Can someone help with this?

build:main (in package.json) succeeds

nodejs lib/main/build-dist.js

build:main-modules fails:
nodejs lib/main/build-modules.js

 nodejs lib/main/build-modules.js
/home/pravi/forge/debian/git/pkg-javascript/node-lodash/lib/common/util.js:33
throw error;
^

Error: ENOTDIR: not a directory, unlink
'/home/pravi/forge/debian/git/pkg-javascript/node-lodash/lib/main/build-modules.js/core.js'
at Error (native)




signature.asc
Description: OpenPGP digital signature

Bug#846549: packer: New version available (0.12.0)

[Olaf Meeuwissen]

Package: packer
Version: 0.10.2+dfsg-1
Severity: wishlist

Dear Maintainer,

Checking the Packer upstream download page[1], I noticed 0.12.0 is out.
It is tagged[2] in GitHub.  It be nice to see this in Debian soon!

 [1] https://www.packer.io/downloads.html
 [2] https://github.com/mitchellh/packer/releases/tag/v0.12.0

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

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

Versions of packages packer depends on:
ii  libc6  2.24-7

Versions of packages packer recommends:
pn  docker.io  
ii  qemu   1:2.7+dfsg-3+b1

Versions of packages packer suggests:
pn  ansible  
pn  chef 

-- no debconf information

--
Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- EPSON AVASYS CORPORATION
   Free Software Foundation Associate Member since 2004-01-27
Support Free Software  https://my.fsf.org/donate
Join the Free Software Foundationhttps://my.fsf.org/join

Bug#842057: [buildd-tools-devel] Bug#842057: fixed in sbuild 0.72.0-2

[Johannes Schauer]

Hi,

Quoting Gianfranco Costamagna (2016-11-22 15:11:36)
> there still seems to be some regression, because apt can't finish its job
> 
> You can see the execstart fail here 
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/s/sbuild/20161122_123905_6a3eb@/log.gz
> 
> Setting up libsbuild-perl (0.72.0-2ubuntu1) ...
> Setting up sbuild (0.72.0-2ubuntu1) ...
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> Setting up buildd (0.72.0-2ubuntu1) ...
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> Job for buildd.service failed because the control process exited with error 
> code.
> See "systemctl status buildd.service" and "journalctl -xe" for details.
> invoke-rc.d: initscript buildd, action "start" failed.
> ● buildd.service - LSB: Debian package autobuilder daemon
>Loaded: loaded (/etc/init.d/buildd; generated; vendor preset: enabled)
>Active: failed (Result: exit-code) since Tue 2016-11-22 
> 12:38:48 UTC; 12ms ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 4794 ExecStart=/etc/init.d/buildd start (code=exited, 
> status=2)
>   CPU: 301ms
> 
> Nov 22 12:38:40 autopkgtest systemd[1]: Starting LSB: Debian package 
> autobui…...
> Nov 22 12:38:40 autopkgtest buildd[4794]:  * Starting Debian package 
> autobui…ldd
> Nov 22 12:38:48 autopkgtest systemd[1]: buildd.service: Control 
> process exit…s=2
> Nov 22 12:38:48 autopkgtest systemd[1]: Failed to start LSB: Debian 
> package …on.
> Nov 22 12:38:48 autopkgtest systemd[1]: buildd.service: Unit entered 
> failed …te.
> Nov 22 12:38:48 autopkgtest systemd[1]: buildd.service: Failed with 
> result '…e'.
> Hint: Some lines were ellipsized, use -l to show in full.
> dpkg: error processing package buildd (--configure):
>  subprocess installed post-installation script returned error exit status 1
> dpkg: dependency problems prevent configuration of autopkgtest-satdep:
>  autopkgtest-satdep depends on buildd (>= 0~); however:
>   Package buildd is not configured yet.
> 
> dpkg: error processing package autopkgtest-satdep (--configure):
>  dependency problems - leaving unconfigured
> Processing triggers for ureadahead (0.100.0-19) ...
> No apport report written because the error message indicates its a followup 
> error from a previous failure.
> Processing triggers for libc-bin (2.24-3ubuntu1) ...
> Processing triggers for systemd (232-6) ...
> Errors were encountered while processing:
>  buildd
>  autopkgtest-satdep
> E: Sub-process /usr/bin/dpkg returned an error code (1)

to figure out the reason for this problem, could you give me the content of
your /var/lib/buildd/daemon.log?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#846536: python-certbot: Not installable in jessie backports

[Ondřej Surý]

Hi Matthew,

have you tried using apt-get install -t jessie-backports python-certbot ?


On 1 December 2016 11:54:15 p.m. Matthew Gabeler-Lee  
wrote:



Package: python-certbot
Version: 0.9.3-1~bpo8+1
Severity: normal

Trying to install python-certbot (really letsencrypt), running into two
dependency issues, one with python-certbot itself and the other with an
indirect dependency python-acme has.

p-c depends on a newer version of python-cryptography than is available, and
depends on python-acme which depends on a newer version of python-openssl
than is available.

$ sudo apt install python-certbot python-acme
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python-acme : Depends: python-openssl (>= 0.15) but 0.14-1 is to be installed
   Depends: python-cryptography (>= 0.8) but 0.6.1-1 is to be 
installed
   Depends: python-setuptools (>= 11.3~) but 5.5.1-1 is to be 
installed
   Recommends: python-dnspython but it is not going to be installed
 python-certbot : Depends: python-cryptography (>= 0.7) but 0.6.1-1 is to be 
 installed

  Recommends: letsencrypt
  Recommends: python-psutil (>= 2.2.1) but it is not going to 
be installed
E: Unable to correct problems, you have held broken packages.

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 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)

Bug#844021: libnative-platform-java 0.11-4 is not compatible with programs built with 0.10*

[殷啟聰]

Hi Vincent,

Thanks for the patch, I think breaking libgradle-core-java is enough
as this is the very package that uses libnative-platform-java.

I'm uploading it soon.

Bug#843108: python-django-horizon: not compatible with Django 1.10 or JQuery 3.1.1-1

[Daniel Baumann]

severity 843108 serious
thanks

Hi,

using sid of today with jquery 3.x the dashboard is basically not usable
since most of the menues are not clickable and thus defeating the
purpose of having a webfrontend in the first place, bumping the severity
of the bug accordingly.

Regards,
Daniel

Bug#844789: GAP: issue related to compressed manual.six: PATCHES

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello All,

finally I figured out a way to implement compression (gz) with the help
of the zlib library rather than through gzip pipes. So snow Sage no more
emits failures concerning GAP. Please find in attachment a patch that replaces
gzip pipes with zlib high level functions, as well concomitant patches.
I have also attached an updated d/p/series files: note that the patch
d/p/fix-compressed-six-files is no more necessary and that some autoconf
scripts have to be regenerated (I followed the hint given by dpkg-builpackage).

The material could not be deposited at Alioth as there is no GAP repository 
there.
On the other hand, I have just uploaded the source ball, the debian stuff
and the debballs at the Sage repository deb-sci-sage (see the Debain Sage page
[1] for more inrmation); therefore it can be easily tested within a schroot 
environment.

At last, as the main patch, namely fix-zlib-stringfile,  slightly improves
the GAP kernel itself, it must also be applied to the libGAP package:
I will do if it is effectively applied to GAP.

Looking forward for comments.

Thanks,
Jerome



[1] https://wiki.debian.org/DebianScience/Sage
- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYQQkMAAoJED+SGaZ/NsaL/d4gAM9e8EYvCgQjPRKh3nN14vNV
yFCO7NsIvQx9Kl5ptKHZu/HGWF++1Ek7qzFkiESB52O0CrF+ZOtcDpH9TNZ+2IC1
LWL5PZucwfNBGbL243My95ye3oz2Zl19FaFonBlUmQ9PMpc3OLNQbFSFsFm+QzhU
qVmrvUMe04gM/cm2i9iDd9QDkGyC/57Sr/4QNyYO+AEH8EdbEIg67Skbq+zaNqJI
nFOByHH8BpbXvl8nWwSlXO+q8Ac6wnpAWH3xc04g9s3lYWqehpNRQXA0XyYeMxSv
dALK4bEjas8yR+HEkui6zzNZ3KOsvW90Y3Q8SN36teXtO7czz82HYS8hsYLbvb0S
k3ADvZqTJ0/khS3BrIsvApoEFwtVp5Qz5vwUuc31yhb8HlxBPtSHsSdKAzFOgmfL
RtDJIuADOlGgiPgGrh5jsTV+BI9QoNXEvaJG0Mn9BdRyCEqnn4+kcjdoWS8FAOqX
42uI2YrgvL0JBf5HhQkZ+uFG/WDUyGDLJhnQH1kXOVXprEBRzGHoR6snH1+QwYe7
a7YScVGt4M96sO6LY2vPpdigWkCkLx7p57k1V23WTxBG/2xpXkMhuE/xpakTIFhG
ms9d69n9PK3/jvjBRCtXdFqNjJ5LjWpOcw0NkM1OL60RbeEmijAD0ddM9TtUc7Be
6NtIXkMNxLb4fBOeEHbffbsPWPz02E67w+wKyBV/FY5RRWFToE9u3Umse5pk5SM/
2aJ5BDuy5granxQJBe9tDauWzq6T1bRAqxDqF4beugrS4MX3hxKod06P8Ley49CB
BEAw8y6uOsXt7hLiZzVX5ZpaAqnyo2lPudFM5XjusRRVkXlaszxQcGkrK3uAahjF
9MH3c2wBe7NM52L5Mrm61BnC/FuY26t5qxS3Hms8VsMk8vESAnWd94NT+6F7UhYr
I0j5ys+hb5sJZeWKcBfWu+xksY81IsHKoUw0hwRCSjg6nfaVGmsUg+361B2yJ7Tj
lwzM7r0oqgk8sgqvfp84BdA2UfRXGTP5tioy0IcSuS07uyN0DbStQoLaU1fcuczz
i/suxvjxEDxAfuwXmIfoQqiE/Y6aHqlzegc1Q6BrO+QZIekc5CT6KsuFim2jHEUX
AAr2Pi7RqGqtNhlPH8qdUjyrh5N1FXJuA1gED5sK3YndULb7v5IrBNLxXCHy0NDA
fnHH2f/rvRtRCR/E+pr7kp6U4Oydx2xROU9XhgED969FcwUHgyJkE5Q+PWv/8PO4
aTy8BQhRO0c5pinp/Qy24QGq1NLP1zyCboNQg5JalaheS9GlqTNbk5LE2frWsq3z
EB3uBejD+CYdVuSlbJLr7qkBcCyyz+TWn5OLqrnEbnBDw8Yrjwtp19fu5sjiu4s=
=LjqH
-END PGP SIGNATURE-
Description: zlib support
 Uncompressing .gz files on the fly through pipes causes the doctests failures
 related to GAP. This patch suggest to uncompress directly with zlib to avoid
 the underlying EPIPE signal mess that creates `Boken pipes'. The zlib support
 is implemented as custom stream through the GNU cookie facility. Furhtermore,
 besides the .gz compression format, other compression format (e.g., xz) can be
 easily compressed.
Origin: vendor, Debian
Forwarded: not-yet
Author: Jerome Benoit 
Last-Update: 2016-12-02

--- a/configure.in
+++ b/configure.in
@@ -152,6 +152,45 @@
   esac
 fi
 
+AC_ARG_WITH(zlib,
+  AC_HELP_STRING( [--with-zlib],
+[ Use ZLIB library.
+  If the argument you supply is "yes" or , then the version of ZLIB 
bundled with this GAP will be used (default).
+  If the argument is "system" that means the library is reachable with the 
standard search path "/usr" or "/usr/local".
+  Otherwise you give the  to the directory which contains the 
library.
+  If the argument is no, use original piping through gunzip instead of 
ZLIB.
+  [[default=yes]]
+]),
+  [ ],
+  [ with_zlib=yes ]
+)
+
+USE_ZLIB=yes
+case "$with_zlib" in
+  no)
+ZLIB_CFLAGS=""
+ZLIB_LIBS=""
+USE_ZLIB=no
+;;
+  yes)
+PKG_CHECK_MODULES(ZLIB,zlib >= 1.2.8,[],[])
+;;
+  system)
+ZLIB_CFLAGS=""
+ZLIB_LIBS="-lz"
+;;
+  *)
+# user specified directory
+ZLIB_HOME="$with_zlib"
+   if test -f ${ZLIB_HOME}/include/zlib.h && test -f 
${ZLIB_HOME}/lib/libz.a ; then
+  ZLIB_CFLAGS="-I${ZLIB_HOME}/include"
+  ZLIB_LIBS="${ZLIB_HOME}/lib/libz.a"
+else
+  AC_MSG_ERROR([Could not locate ZLIB in the specified location])
+fi;
+;;
+esac
+
 # Enabling/disabling readline is handled by the "inner" configure
 # script in cnf/, so we do nothing here (the command line flag
 # is automatically passed on to the "inner" configure script anyway.
@@ -164,6 +203,9 @@
 AC_SUBST(MAKE_GMP)
 AC_SUBST(USE_GMP)
 AC_SUBST(GMP_VER)
+AC_SUBST(ZLIB_CFLAGS)
+AC_SUBST(ZLIB_LIBS)
+AC_SUBST(USE_ZLIB)
 
 mkdir -p bin
 

Bug#726530: bug still present in Fvwm 2.6.5

[Jim Cline]

thanks for getting back to me about this, but since my system is working 
well with the old version, I don't want to risk breaking it again by 
installing newer ones. --Jim



On Thu, 1 Dec 2016, Jaimos Skriletz wrote:


On Sun, 3 Jul 2016 22:45:45 -0400 (EDT) Jim Cline
 wrote:

further to my previous message, I should have mentioned that I experienced
the crashes using version fvwm/1:2.6.5.ds-4.1.  Downgrading to
version 1.2.5.30.ds-1 seems to solve the problem.



The newest version of fvwm is now available in the Debian archive.
Could you confirm if this bug is still present? I know that between
2.6.5 and 2.6.7 there was various cleanups of memory code in fvwm and
maybe this was fixed.

If you still have a crash can you describe the process (hopefully with
the default config) so I can see if I can reproduce it.

thanks

jaimos

Bug#835049: [/master] New upstream git snapshot (Closes: #835049) (LP: #1633785).

[Andrew Starr-Bochicchio]

tag 835049 pending
thanks

Date: Wed Nov 30 20:20:55 2016 -0500
Author: Andrew Starr-Bochicchio 
Commit ID: 141d130a77a479080a683e33b63e8620af64890f
Commit URL: 
https://anonscm.debian.org/cgit/collab-maint/deluge.git;a=commitdiff;h=141d130a77a479080a683e33b63e8620af64890f
Patch URL: 
https://anonscm.debian.org/cgit/collab-maint/deluge.git;a=commitdiff_plain;h=141d130a77a479080a683e33b63e8620af64890f

New upstream git snapshot (Closes: #835049) (LP: #1633785).

  

Bug#846548: libengine-pkcs11-openssl: Can't load pkcs11 engine into openssl

[micah]

Package: libengine-pkcs11-openssl
Version: 0.4.2-1
Severity: important

Hello,

It seems like when this package is installed, the pkcs11 engine is not
available as it should be:

$ openssl engine pkcs11
140007032747136:error:25066067:DSO support routines:dlfcn_load:could not load 
the shared 
library:crypto/dso/dso_dlfcn.c:113:filename(/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so):
 /usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so: cannot open shared object 
file: No such file or directory
140007032747136:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:crypto/dso/dso_lib.c:161:
140007032747136:error:260B6084:engine routines:dynamic_load:dso not 
found:crypto/engine/eng_dyn.c:414:
140007032747136:error:2606A074:engine routines:ENGINE_by_id:no such 
engine:crypto/engine/eng_list.c:339:id=pkcs11
$

Indeed the pkcs11 engine is not in that path, its actually in:

/usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines/pkcs11.so

You can also see that it is not loaded here:

$ strace -e open -- openssl engine
open("/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libssl.so.1.1", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3
(rdrand) Intel RDRAND engine
(dynamic) Dynamic engine loading support
+++ exited with 0 +++

Thanks!
micah

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

Kernel: Linux 4.6.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)

Bug#846190: RFS: openldap/2.4.44+dfsg-2 [RC]

[Ryan Tandy]

I updated the package on mentors to add one more fix:

+  * Fix slapd-smbk5pwd failing to upgrade when there are no instances of the
+overlay configured.

affecting jessie-to-stretch upgrades when the slapd-smbk5pwd package is 
installed, but not used anywhere in the slapd configuration.

Bug#846547: libfontconfig1: FcNameParse of result of FcNameUnparse can segfault or fail to match

[Lawrence D'Oliveiro]

Package: libfontconfig1
Version: 2.11.0-6.7
Severity: normal

Dear Maintainer,

FcNameUnparse is supposed to turn an FcPattern into a string, while
FcNameParse is supposed to turn a string into an FcPattern. However,
it turns out that FcNameParse cannot correctly handle full pattern
strings produced by FcNameUnparse. The problem specifically occurs
when the pattern contains a value for the “charset” property.

I raised this issue on the Fontconfig list, where you will find a
sample C program that illustrates the bug:
.

(I can repost that same program here if you prefer.)

In reply, Akira Tagoh was kind enough to point me to this reworking
of the parse/unparse code

which you will note was committed over 2 years ago. In short, upgrading
the Debian package to the current Fontconfig 2.12.0 stable release
should fix the problem.

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

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

Versions of packages libfontconfig1 depends on:
ii  fontconfig-config  2.11.0-6.7
ii  libc6  2.24-5
ii  libexpat1  2.2.0-1
ii  libfreetype6   2.6.3-3+b1

libfontconfig1 recommends no packages.

libfontconfig1 suggests no packages.

-- no debconf information

Bug#846546: RFS: ora2pg/17.6-1 [RC] [QA]

[gustavo panizzo]

Package: sponsorship-requests
Severity: important

Hello

I'm looking for an sponsor for my QA upload to ora2pg

it closes an RC bug
I've improved the general shape of the package and moved the packaging
to collab-maint

The changelog follows

ora2pg (17.6-1) unstable; urgency=medium

  * QA upload
  * Set the maintainer to Debian QA Group
  * New upstream release
  * Bump Standards-Version to 3.9.8
- Remove Dm-Upload-Allowed field from debian/control
  * Remove obsolete compression type 'bzip2' from debian/rules (Closes:
#833249)
  * Replace bzip2 by xz on debian/source/options
  * Refresh/Add patches
- refreshed 01_Ora2Pg.pod.diff
- refreshed 02_remove_unnecessary_files.diff
  change the manpage's destination from 3 to 3pm,
  not to modify ora2pg script at install time,
  and to install the config in /etc/ora2pg/ora2pg.conf
- add cf81287191c1560b238fe2967560d8bff33e24b0.patch, reverts 697f09d
  that was breaking encoding with input file (-i)
- Add spelling-fixes.patch
  * Update compat level to 10
  * Build depend on debhelper >=10
  * Moved out from contrib, as ora2pg supports both Oracle and MySQL
  * Change section from extra to database
  * Update long description to mention MySQL support
  * Update copyright years
  * Add Vcs-* fields to debian/control
  * Update README.source
  * Packaging is now maintained on a git repo under collab-maint
  * Add Vcs fields to debian/control
  * Add pristine-tar to the git repo
  * Add gbp.conf

 -- gustavo panizzo   Wed, 30 Nov 2016 17:13:21 +0800


the source can be found at 
https://anonscm.debian.org/git/collab-maint/ora2pg.git
and
https://mentors.debian.net/debian/pool/main/o/ora2pg/ora2pg_17.6-1.dsc

thanks!

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

Kernel: Linux 4.8.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)

Bug#846545: [golang-1.7] Security issues resolved in 1.7.4 (new version)

[Tim Sattarov]

Package: golang-1.7
Version: 1.7.3-1
Severity: important
Tags: security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org

--- Please enter the report below this line. ---
Hello,

There are new versions of Go release, fixing security issues in net/http
package:
1.7.4 and 1.6.4
https://groups.google.com/forum/#!topic/golang-announce/2lP5z9i9ySY

Thank you

--- System information. ---
Architecture:
Kernel: Linux 4.8.0-1-amd64

Debian Release: stretch/sid
500 testing mirror.csclub.uwaterloo.ca
500 testing cloudfront.debian.net
500 stable repository.spotify.com
500 stable repo.skype.com
500 stable dl.google.com
500 stable cloudfront.debian.net
500 stable artifacts.elastic.co
500 sid linux.dropbox.com
500 kubernetes-xenial apt.kubernetes.io
500 jessie packagecloud.io
500 debian-stretch apt.dockerproject.org
100 unstable cloudfront.debian.net
100 experimental cloudfront.debian.net

--- Package information. ---
Depends (Version) | Installed
===-+-=
golang-1.7-doc (>= 1.7.3-1) | 1.7.3-1
golang-1.7-go (>= 1.7.3-1) | 1.7.3-1
golang-1.7-src (>= 1.7.3-1) | 1.7.3-1


Package's Recommends field is empty.

Package's Suggests field is empty.

-- 
Tim, the beardless keeper of keys and grounds @ AgileBits Inc.
~~~
1Password remembers all your passwords for you. It keeps your digital life 
secure and always available, safe behind the one password that only you know.
Create your 1Password account today at https://1password.com




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#823004: gplaycli: sensitive information in config file

[Paul Wise]

On Wed, 2016-11-09 at 12:42 +0800, Paul Wise wrote:

> I suggest this bug report be closed wontfix.

This bug has now caused gplaycli to be removed from Debian stretch.

Is there any progress to report?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#846544: minicoredumper: please provide/conflict/replace core-dump-handler

[Paul Wise]

Package: minicoredumper
Version: 2.0.0-1
Severity: important

Please add these to your package meta-data:

Provides: core-dump-handler
Conflicts: core-dump-handler
Replaces: core-dump-handler

So that it won't be co-installed with other core dump handlers:

$ aptitude search -F %p '?provides(core-dump-handler)'
apport
corekeeper
systemd-coredump

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.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 minicoredumper depends on:
ii  adduser 3.115
ii  libc6   2.24-7
ii  libelf1 0.166-2.2
ii  libjson-c3  0.12.1-1.1
ii  lsb-base9.20161125

minicoredumper recommends no packages.

minicoredumper suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#722736: fvwm: scrolling with the mouse over a button is seen as a (double) click

[Jaimos Skriletz]

On Tue, 26 Nov 2013 10:35:55 +0100 Vincent Lefevre  wrote:
> On 2013-11-26 00:12:09 -0800, Vincent W. Chen wrote:
> > On Sat, Oct 26, 2013 at 4:50 PM, Vincent Lefevre  wrote:
> > > On 2013-10-25 17:42:54 -0700, Vincent W. Chen wrote:
> > >> > No, "Mouse 4" and "Mouse 5" would still be allowed, but "Mouse 0" 
> > >> > should
> > >> > be equivalent to "Mouse 1 or 2 or 3". This makes more sense.
> > >> >
>
> > > Currently the man page is still buggy. Or perhaps the intent of
> > > "Mouse 0" is not to include the scroll up & down events (just like
> > > with mouse navigation in menus).
> > >
> > Would it be sufficient if the manpage is changed to read "Pressing any
> > mouse button (other than buttons 4 and 5) while a menu is open ..."?
>
> The manpage should be changed. But I also think that there should be
> a warning to say that "Mouse 0" will also include mouse wheel events
> in practice and that a user who don't want such events to be take
> into account mustn't use "Mouse 0".
>

I have looked into this a little bit and don't think there is an
inconsistency. The issue I see is there are default bindings for menus
configured in /usr/share/fvwm/ConfigFvwmDefaults. The four lines of
interest are

Mouse 0 MI A MenuSelectItem
Mouse 0 MTS A MenuLeaveSubmenu
Silent Mouse 4  MIT A MenuScroll -1
Silent Mouse 5  MIT A MenuScroll +1

This first defines all mouse buttons via "Mouse 0" do something, then
defines additional bindings to buttons 4 and 5. So it isn't that fvwm
is treating bindings in Menus differently, but the defaults are
configured so the mouse 4 and 5 on a menu act differently than the
other mouse buttons. I was able to remove the two Mouse 4 and Mouse 5
bindings above and then redefine the Mouse 0 bindings in the menu and
was able to trigger menu items from the scroll wheel.

I don't see this as a bug, but working as designed.

I have also found in the manpage under Mouse Navigation talking about
how the mouse wheel is configured to scroll by default. Additionally I
have found under the Mouse description in the manpage that "If Button
is zero then any button performs the specified function." So the
manpage is correctly describing the behavior. Additionally this means
any not just buttons 1-5, it is just those are the only buttons fully
supported. This could also cause the option to be triggered for
buttons > 5, it is just >5 buttons are not always fully supported for
all things in X.

Does this resolve the issue, or do you still think the manpage needs
to be more clear on this behavior?

I do agree that having to write multiple lines to get what you need
configured is not ideal, but current fvwm config syntax won't allow it
and fvwm2 development is mostly ended so we have to use the config
options in its current state.

jaimos

Bug#785157: fvwm: Dialogs "Background Color" and "Font Color" appear only once on newer LibreOffice versions

[Jaimos Skriletz]

On Tue, 12 May 2015 23:06:32 +0200 Marc-Jano Knopp
 wrote:
> Dear Maintainer,

Thanks for submitting the bug

>
> After upgrading from LibreOffice 1:4.3.3-2 (stable) to 1:4.4.2-1
> (testing), the dialogs for "Background Color" and "Font Color" appear
> only once after clicking the appropriate "drop down" arrows. When
> trying to open them a second time, a window outline,i showing part of
> the spreadsheet, is visible for a fraction of a second, then
> disappears.
>
> After exiting and restarting LibreOffice, the dialogs show again (but
> only once).
>

I am not able to reproduce it. Libreoffice version 1:5.2.3~rc1-4 and
fvwm version 1:2.6.7-1 are the versions I'm using, and I'm able to
open the Font color and Highlight color dialog boxes multiple times,
select a color and then they get redrawn again next time I open them.

If you could double check if it is reproducible using updated versions
let me know.

Thank you

jaimos

Bug#689798: fvwm: inaccessible windows outside the desktop bounds

[Jaimos Skriletz]

On Sun, 10 Feb 2013 17:40:02 +0400 "Vladimir B. Savkin"
 wrote:
> On Sat, Feb 02, 2013 at 08:32:19PM -0800, Vincent W. Chen wrote:
> > Hi,
> >
> > Some things for you to try:
> >
> > - The latest version of Fvwm in unstable (2.6.5)
>
> It has the same behaviour.
>
> > - "Style [your browser here] NoUsePPosition, NoUseUSPosition" in your config
>
> I tried:
> Style "Iceape"  NoUsePPosition, NoUseUSPosition
> it didn't seem to change anything. It looks like iceape first appears
> in visible part of the screen and then restores session and moves itself
> out of virtual desktop.
>

If the app is moving itself after it has been mapped this doesn't
sound like a bug in fvwm but in the app. Browsers have a long history
of misbehaving.

The newest version of fvwm in unstable is now 2.6.7, maybe see if this helps.

If this still happens you can recover the browser (lets say it is
firefox) by doing something like

Next (firefox) Move 0 0

to move the window back to the current page.

jaimos

Bug#832062: SuperTuxKart must be uploaded soon for not missing stretch

[henrichsjo...@gmail.com]

Hi all,

I am one of the STK admins. Can you tell us exactly what you need? The 
song was released under CC-BY-SA by the author (as indicated by the 
author's email we received, which we published in the mentioned forum 
thread: http://forum.freegamedev.net/viewtopic.php?f=17=6562#p70981).


Afaik under CC-BY-SA no 'source code' is necessary, but even so the .mod 
file is available in our media repo 
(https://svn.code.sf.net/p/supertuxkart/code/media/trunk/music/mods/).


I am not really sure what else you need - any advise appreciated!

Cheers,
   Joerg (aka hiker)

PS: Is there a way of avoiding publishing email addresses here on the 
web site? It's too late now for me, but maybe for next time ;)

Bug#726530: bug still present in Fvwm 2.6.5

[Jaimos Skriletz]

On Sun, 3 Jul 2016 22:45:45 -0400 (EDT) Jim Cline
 wrote:
> further to my previous message, I should have mentioned that I experienced
> the crashes using version fvwm/1:2.6.5.ds-4.1.  Downgrading to
> version 1.2.5.30.ds-1 seems to solve the problem.
>

The newest version of fvwm is now available in the Debian archive.
Could you confirm if this bug is still present? I know that between
2.6.5 and 2.6.7 there was various cleanups of memory code in fvwm and
maybe this was fixed.

If you still have a crash can you describe the process (hopefully with
the default config) so I can see if I can reproduce it.

thanks

jaimos

Bug#798935: Starting dnsmasq deadlock with /etc/resolvconf/update-libc.d/squid3

[Stefan Monnier]

> On a system with systemd, dnsmasq and resolvconf installed, the
> /etc/resolvconf/update-libc.d/squid3 hook prevents dnsmasq from
> starting. As far as I can see, the problem is caused by a deadlock of
> "systemctl start dnsmasq.service" in conjunction with "systemctl
> reload squid3.service". The latter one is finally called by the
> /etc/resolvconf/update-libc.d/squid3 hook which is invoked by dnsmasq
> on startup.

Indeed, I just bumped into this problem.  I recently decided to move
from Polipo to Squid (on my home router), so I installed Squid.
Everything seemed to be dandy until I rebooted, at which point dnsmasq
failed to start, preventing access to the outside world to all other
machines.

> A possible solution might be, to check if systemd is running in the
> hook and calling
>
> systemctl --no-block reload squid3.service
>
> directly instead of
>
> invoke-rc.d squid3 reload

How 'bout just adding an & at the end of this reload line?
That's the workaround I'm using right now,


Stefan

Bug#840754: Memory leak in libmagic and failure in magic_load

[Christoph Biedl]

Arnaud Quette wrote...

> $ gcc test.c -lmagic
> valgrind ./a.out
(...)
> ==30967== HEAP SUMMARY:
> ==30967== in use at exit: 48 bytes in 3 blocks
> ==30967== total heap usage: 28 allocs, 25 frees, 2,179 bytes allocated
(...)

Hello,

according to my tests this was fixed in file/libmagic 5.29-1 (as in
sid and stretch):

==416629== Memcheck, a memory error detector
==416629== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==416629== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright 
info
==416629== Command: ./a.out
==416629==
==416629==
==416629== HEAP SUMMARY:
==416629== in use at exit: 0 bytes in 0 blocks
==416629==   total heap usage: 16 allocs, 16 frees, 1,123 bytes allocated
==416629==
==416629== All heap blocks were freed -- no leaks are possible
==416629==
==416629== For counts of detected and suppressed errors, rerun with: -v
==416629== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Please confirm, I'll prepare a fix for jessie then (wheezy is
appearently not affected).

Christoph



signature.asc
Description: Digital signature

Bug#842411: ping -- freeze is soon

[Adam Borowski]

Hi!
You've just made an upload, fixing the maintainer address, but did not
do the rather easy change to facilitate upgrades from jessie.  As adding a
dummy package requires NEW, the time to do so would be now.

Thus, could you consider making the following changes?:
For manual upgrades:
* iptraf-ng:
  + symlink /usr/sbin/iptraf -> iptraf-ng (plus the manpage)
  + debian/control: {Conflicts,Provides,Replaces}: iptraf
For apt:
* iptraf:
  + an empty package that Depends: iptraf-ng

-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

Bug#844631: chromium: certificate transparency error on i386

[Adrian Thoroughgood]

Dear Maintainer
This bug is preventing me from accessing amazon at all in Chromium. I get this 
message:
"Your connection is not private
Attackers might be trying to steal your information from www.amazon.co.uk (for 
example, passwords, messages, or credit cards). 
NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
www.amazon.co.uk normally uses encryption to protect your information. When 
Chromium tried to connect to www.amazon.co.uk this time, the website sent back 
unusual and incorrect credentials. This may happen when an attacker is trying 
to pretend to be www.amazon.co.uk, or a Wi-Fi sign-in screen has interrupted 
the connection. Your information is still secure because Chromium stopped the 
connection before any data was exchanged.
You cannot visit www.amazon.co.uk right now because the website uses HSTS. 
Network errors and attacks are usually temporary, so this page will probably 
work later."
I get error messages in other HTTPS websites but this is the only one I've 
found so far that is completely broken.
It has been like this ever since I installed the latest version of chromium 
53.0.2785.143-1~deb8u1Ubuntu have had the fix incorporated into their packages 
for some time. Please can we have it too? I don't know how the severity 
classifications are defined but major websites being completely unusable seems 
pretty important to me.
Thanks

Bug#846315: maybe fixed scapy script in new upload

[Iain R. Learmonth]

Control: tags 846315 + moreinfo

Hi,

I've uploaded 0.19-1 to unstable. When I run your script with the new
version:


root@host$ /tmp/testscript.py
WARNING: No route found for IPv6 destination :: (no default route?). This
affects only IPv6
Begin emission:
Finished to send 1 packets.
*
Received 1 packets, got 1 answers, remaining 0 packets


Can you confirm this new upload works for you too? If so, feel free to close
the bug at the same time, or I can close it.

I'm afraid to close it in the changelog in case I've just failed to
reproduce the issue.

Thanks,
Iain.



signature.asc
Description: PGP signature

Bug#845250: [pkg-apparmor] Bug#845250: apparmor-profiles: can't launch evince when apparmor is enabled

[Steve Beattie]

On Tue, Nov 22, 2016 at 03:04:45PM +0100, intrigeri wrote:
> Félix Sipma:
> > When apparmor is enabled, I can't launch evince. Here is an extract of the
> > logs:
> 
> > [33328.299018] audit: type=1400 audit(1479752613.324:130): apparmor="DENIED"
> > operation="open" profile="/usr/bin/evince" 
> > name="/run/user/1000/X11/Xauthority"
> > pid=14782 comm="evince" requested_mask="r" denied_mask="r" fsuid=1000 
> > ouid=1000
> 
> Thanks! Looks like /etc/apparmor.d/abstractions/X needs an update,
> so I'm reassigning this bug to the package that ships that file.

Upstream apparmor has committed a fix for this that adds

  owner /{,var/}run/user/*/X11/Xauthority r,

to abstractions/X.

Committed in trunk rev 3591, apparmor-2.10 branch rev 3367, and
apparmor-2.9 branch rev 3035.

Thanks for the report!

-- 
Steve Beattie

http://NxNW.org/~steve/


signature.asc
Description: PGP signature

Bug#839853: [Letsencrypt-devel] Bug#839853: Upstream change project name

[Mattia Rizzolo]

On Thu, Oct 06, 2016 at 07:10:32AM +0200, Daniel Beyer wrote:
> Thanks for your report. We are aware of the changed name and I'm already
> working on a renaming. It's a bit delayed right now, but I hope there
> will be some significant progress over the weekend.

I'm not sure of anything you did, but given that the freeze is
approaching very quickly I took some actions:

1) I released just now 0.3.0 - I tested it and seems to work; as you can
   see I even revert that config.sh→config change upstream did to try to
   minimize disruptions in it.
2) I imported 0.3.1 and did an initial rename of everything, this isn't
   tested at all.

https://anonscm.debian.org/git/letsencrypt/dehydrated.git/

Given the freeze, and not wanting to shout our faces on this, I planned
to work on it some more, terminating the rename, do some basic testing
and upload to unstable.  I'd like to have it into testing asap (consider
that there is going to be a NEW delay and now that we're approaching the
freeze the testing migration delay is of 10 days, and new packages will
stop enter testing on 5th of Jannuary), and *then* work on an upgrade
plan from letsencrypt.sh.
At any rate, I'd rather not have both letsencrypt.sh and dehydrated in
stretch, so if we don't manage to get a good enough upgrade migration
from le.sh I'm more tempted to ask to remove dehydrated from stretch and
keep dehydrated for buster and stretch-backports.

What do you think?



Sorry for taking so long myself, had quite some work to do elsewhere :S

-- 
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#846543: citadel: FTBFS (dereferencing pointer to incomplete type)

[Santiago Vila]

Package: src:citadel
Version: 902-2
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with autotools-dev,quilt
   dh_testdir -i
   dh_update_autotools_config -i
   dh_autotools-dev_updateconfig -i
   dh_quilt_patch -i
Applying patch icalerror_errors_are_fatal.patch
patching file modules/calendar/serv_calendar.c
Hunk #1 succeeded at 2580 (offset -6 lines).

Applying patch clean.patch
patching file Makefile.in


[... snipped ...]

modules/calendar/serv_calendar.c:2160:59: warning: passing argument 1 of 
'icaltimezone_get_component' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   zc = icalcomponent_new_clone(icaltimezone_get_component(attached_zones[i]));
   ^~
In file included from modules/calendar/serv_calendar.c:21:0:
/usr/include/libical/ical.h:2775:36: note: expected 'icaltimezone * {aka struct 
_icaltimezone *}' but argument is of type 'const icaltimezone * {aka const 
struct _icaltimezone *}'
 LIBICAL_ICAL_EXPORT icalcomponent *icaltimezone_get_component(icaltimezone 
*zone);
^~
CC modules/checkpoint/serv_checkpoint.c
CC modules/clamav/serv_virus.c
CC modules/crypto/serv_crypto.c
modules/crypto/serv_crypto.c: In function 'init_ssl':
modules/crypto/serv_crypto.c:87:3: warning: implicit declaration of function 
'RAND_egd' [-Wimplicit-function-declaration]
   RAND_egd(EGD_POOL);
   ^~~~
modules/crypto/serv_crypto.c:147:22: error: dereferencing pointer to incomplete 
type 'DH {aka struct dh_st}'
  if (!(BN_hex2bn(&(dh->p), DH_P))) {
  ^~
modules/crypto/serv_crypto.c:173:3: warning: 'RSA_generate_key' is deprecated 
[-Wdeprecated-declarations]
   rsa = RSA_generate_key(1024, /* modulus size */
   ^~~
In file included from /usr/include/openssl/rsa.h:13:0,
 from /usr/include/openssl/x509.h:31,
 from /usr/include/openssl/ssl.h:50,
 from modules/crypto/serv_crypto.c:20:
/usr/include/openssl/rsa.h:193:1: note: declared here
 DEPRECATEDIN_0_9_8(RSA *RSA_generate_key(int bits, unsigned long e, void
 ^
modules/crypto/serv_crypto.c:305:35: error: dereferencing pointer to incomplete 
type 'X509_REQ {aka struct X509_req_st}'
  X509_set_issuer_name(cer, req->req_info->subject);
   ^~
In file included from /usr/include/openssl/ssl.h:48:0,
 from modules/crypto/serv_crypto.c:20:
modules/crypto/serv_crypto.c: In function 'CtdlStartTLS':
modules/crypto/serv_crypto.c:637:23: error: dereferencing pointer to incomplete 
type 'SSL {aka struct ssl_st}'
  BIO_set_close(CC->ssl->rbio, BIO_NOCLOSE);
   ^
At top level:
modules/crypto/serv_crypto.c:61:22: warning: 'id_callback' defined but not used 
[-Wunused-function]
 static unsigned long id_callback(void)
  ^~~
Makefile:145: recipe for target 'modules/crypto/serv_crypto.o' failed
make[1]: *** [modules/crypto/serv_crypto.o] Error 1
make[1]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
debian/rules:105: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


If you need a full build log, just say so, but this should be easy to reproduce,
as the failure also happens here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/citadel.html

While we are at it: Please consider uploading in source-only form, so that
we get official build logs available here even for Arch:all architecture:

https://buildd.debian.org/status/package.php?p=citadel

Thanks.

Bug#845393: Pending fixes for bugs in the tomcat8 package

[paul . szabo]

Dear Emmanuel,

(Yes I had tomcat6, then went to tomcat8, skipping tomcat7; and have
inherited things.)

You seem to say that  /etc/tomcat8/Catalina/localhost  does not need to
be writable by tomcat8, setting it so was useless (thus wrong).
What about the  /etc/tomcat8/Catalina  directory, is there a need to set
it writable? Is there a need to have these owned by group tomcat8, could
they be left as root:root and world-accessible?

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#845393: Pending fixes for bugs in the tomcat8 package

[Emmanuel Bourg]

Le 2/12/2016 à 00:32, Markus Koschany a écrit :

> Just my 2 cents about the "other" packages that install files into
> /etc/tomcat8/Catalina/localhost. In my opinion they should just symlink
> files into this path if at all. You mentioned jspwiki as one possible
> candidate in one of your earlier emails but this one has been broken for
> a long time now. It is probably easier to fix such issues in those
> packages and not in Tomcat itself.

You are absolutely right, I said files but the packages I was referring
to (jspwiki and solr-jetty) install a symlink and not a file.

I know these packages are broken/outdated, but they are the only
examples of how web applications are supposed to be packaged in Debian.

Emmanuel Bourg

Bug#846542: etcd: FTBFS in testing (undefined: grpc.SupportPackageIsVersion3)

[Santiago Vila]

Package: src:etcd
Version: 2.3.7+dfsg-5
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang,systemd --parallel 
--builddirectory=_build
   dh_testdir -i -O--buildsystem=golang -O--parallel -O--builddirectory=_build
   dh_update_autotools_config -i -O--buildsystem=golang -O--parallel 
-O--builddirectory=_build
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/etcd-2.3.7+dfsg'
grep -Pq "syntax\s*=\s*\"proto3\"" etcdserver/etcdserverpb/etcdserver.proto \
|| protoc -I/usr/share/gocode/src/github.com/gogo/protobuf 
-I/usr/include -Ietcdserver/etcdserverpb/ --gogo_out=etcdserver/etcdserverpb/ 
etcdserver/etcdserverpb/etcdserver.proto
perl -pi -E 's{import _ "gogoproto"}{}g;' 
"etcdserver/etcdserverpb/etcdserver.pb.go"
grep -Pq "syntax\s*=\s*\"proto3\"" raft/raftpb/raft.proto \
|| protoc -I/usr/share/gocode/src/github.com/gogo/protobuf 
-I/usr/include -Iraft/raftpb/ --gogo_out=raft/raftpb/ raft/raftpb/raft.proto
perl -pi -E 's{import _ "gogoproto"}{}g;' "raft/raftpb/raft.pb.go"
grep -Pq "syntax\s*=\s*\"proto3\"" wal/walpb/record.proto \
|| protoc -I/usr/share/gocode/src/github.com/gogo/protobuf 
-I/usr/include -Iwal/walpb/ --gogo_out=wal/walpb/ wal/walpb/record.proto
perl -pi -E 's{import _ "gogoproto"}{}g;' "wal/walpb/record.pb.go"
grep -Pq "syntax\s*=\s*\"proto3\"" snap/snappb/snap.proto \
|| protoc -I/usr/share/gocode/src/github.com/gogo/protobuf 
-I/usr/include -Isnap/snappb/ --gogo_out=snap/snappb/ snap/snappb/snap.proto
perl -pi -E 's{import _ "gogoproto"}{}g;' "snap/snappb/snap.pb.go"
dh_auto_configure
for I in $(cat debian/third_party_exclude); do \
printf "Removing third party bundled $I\n" ;\
sed -i "s,github.com/coreos/etcd/Godeps/_workspace/src/,," $(find 
_build -type f -name "*.go") ;\
done
Removing third party bundled github.com/akrennmair/gopcap
Removing third party bundled github.com/bgentry/speakeasy
Removing third party bundled github.com/boltdb/bolt
Removing third party bundled github.com/cheggaaa/pb
Removing third party bundled github.com/codegangsta/cli
Removing third party bundled github.com/coreos/gexpect
Removing third party bundled github.com/coreos/go-etcd
Removing third party bundled github.com/coreos/go-semver/semver
Removing third party bundled github.com/coreos/go-systemd
Removing third party bundled github.com/coreos/pkg
Removing third party bundled github.com/gogo/protobuf
Removing third party bundled github.com/golang/glog
Removing third party bundled github.com/golang/protobuf
Removing third party bundled github.com/google/btree
Removing third party bundled github.com/jonboulle/clockwork
Removing third party bundled github.com/prometheus/client_golang
Removing third party bundled github.com/prometheus/procfs
Removing third party bundled github.com/spacejam/loghisto
Removing third party bundled github.com/spf13/cobra
Removing third party bundled github.com/stretchr/testify
Removing third party bundled github.com/ugorji/go
Removing third party bundled github.com/xiang90/probing
Removing third party bundled golang.org/x/crypto
Removing third party bundled golang.org/x/net
Removing third party bundled google.golang.org/grpc
make[1]: Leaving directory '/<>/etcd-2.3.7+dfsg'
   dh_auto_build -i -O--buildsystem=golang -O--parallel 
-O--builddirectory=_build
go install -v -p 1 github.com/coreos/etcd github.com/coreos/etcd/auth 
github.com/coreos/etcd/client github.com/coreos/etcd/compactor 
github.com/coreos/etcd/discovery github.com/coreos/etcd/error 
github.com/coreos/etcd/etcdctl github.com/coreos/etcd/etcdctl/command 
github.com/coreos/etcd/etcdmain github.com/coreos/etcd/etcdserver 
github.com/coreos/etcd/etcdserver/api/v3rpc 
github.com/coreos/etcd/etcdserver/api/v3rpc/rpctypes 
github.com/coreos/etcd/etcdserver/auth 
github.com/coreos/etcd/etcdserver/etcdhttp 
github.com/coreos/etcd/etcdserver/etcdhttp/httptypes 
github.com/coreos/etcd/etcdserver/etcdserverpb 
github.com/coreos/etcd/etcdserver/stats github.com/coreos/etcd/lease 
github.com/coreos/etcd/lease/leasehttp github.com/coreos/etcd/lease/leasepb 
github.com/coreos/etcd/pkg/adt github.com/coreos/etcd/pkg/contention 
github.com/coreos/etcd/pkg/cors github.com/coreos/etcd/pkg/crc 
github.com/coreos/etcd/pkg/fileutil github.com/coreos/etcd/pkg/flags 
github.com/coreos/etcd/pkg/httputil githu
 b.com/coreos/etcd/pkg/idutil github.com/coreos/etcd/pkg/ioutil 
github.com/coreos/etcd/pkg/logutil github.com/coreos/etcd/pkg/mock/mockstorage 
github.com/coreos/etcd/pkg/mock/mockstore 
github.com/coreos/etcd/pkg/mock/mockwait github.com/coreos/etcd/pkg/netutil 
github.com/coreos/etcd/pkg/osutil github.com/coreos/etcd/pkg/pathutil 

Bug#846541: h5py: FTBFS against hdf5 1.10 - Fail to detect HDF5 install dir

[Gilles Filippini]

Source: h5py
Version: 2.6.0-1
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

h5py FTBFS against hdf5-1.10 with:
==
ERROR: test_force_swmr_mode_off_raises 
(h5py.tests.hl.test_dataset_swmr.TestDatasetSwmrRead)
Switching SWMR write mode off is only possible by closing the file.
- --
Traceback (most recent call last):
  File "h5py/tests/hl/test_dataset_swmr.py", line 58, in setUp
self.f = h5py.File(fname, 'r', swmr=True)
  File "h5py/_hl/files.py", line 272, in __init__
fid = make_fid(name, mode, userblock_size, fapl, swmr=swmr)
  File "h5py/_hl/files.py", line 91, in make_fid
flags |= h5f.ACC_SWMR_READ
AttributeError: 'module' object has no attribute 'ACC_SWMR_READ'
...
- --
Ran 423 tests in 1.568s

FAILED (errors=9, skipped=10, expected failures=7)

Previously in the buildlog there is:

   Summary of the h5py configuration

Path to HDF5: None
HDF5 Version: '1.8.4'
 MPI Enabled: False
Rebuild Required: False



Then I tried with HDF5_DIR=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial and this 
time the build was successful.

Thanks,

_g.


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

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

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYQLRjAAoJEO/obGx//s+DVjYH/i4LAEgv81YkUIXzuL3o4nkY
Szkv9beTJ/05HUPDvetXDNztTP3ECAZ8n9I0OzNEVm1jolVQpAiG9sMXkNag0vXi
/M+RTV0thtYh5nKkcF0tPXVKGnRsEikmgErc9LsVDFfW6HFaW83TK+QMXZQd3sXN
yO20C5editQa/LhFAeFNy+4MS5NEY9vTICTUr4KN6rGF9MQUZ8Gygz4UXZ1jBfhJ
73OFn0TobitVgLtIrc78V674COjhWyQaNL88vYkoV0RkdtQatd60eHSuKwurS9P0
oG6qY+lfBGE1iHQyAmb6Hja98RIhd/nCG6vbQlRKIBY8/NDzMwhJZjMjqWigyyU=
=Z5CO
-END PGP SIGNATURE-

Bug#846540: hplip-gui: hp-toolbox and hp-setup cannot load

[Alejandro Carrazzoni]

Package: hplip-gui
Version: 3.16.10+repack0-1
Severity: grave
Justification: renders package unusable

I installed hplip and hplip-gui from the debian repositories. However, when I
try to run hp-setup I get the following error:

Traceback (most recent call last):
  File "/usr/bin/hp-setup", line 48, in 
from base import device, utils, tui, models, module, services, os_utils
  File "/usr/share/hplip/base/device.py", line 41, in 
from . import status
  File "/usr/share/hplip/base/status.py", line 32, in 
import cupsext
ImportError: libhpipp.so.0: cannot open shared object file: No such file or
directory

When I run hp-check I get this error:

warning: CUPSEXT could not be loaded. Please check HPLIP installation.



-- Package-specific info:

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

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

Versions of packages hplip-gui depends on:
ii  dbus-x11 [dbus-session-bus]  1.10.12-1
ii  gksu 2.0.2-9
ii  hplip3.16.10+repack0-1
ii  python3-dbus.mainloop.pyqt5  5.7+dfsg-2+b1
ii  python3-pyqt55.7+dfsg-2+b1

Versions of packages hplip-gui recommends:
ii  python3-notify2 0.3-3
pn  xsane | simple-scan | skanlite  

hplip-gui suggests no packages.

-- no debconf information

Bug#845393: Pending fixes for bugs in the tomcat8 package

[Markus Koschany]

On 02.12.2016 00:15, Emmanuel Bourg wrote:
> Le 1/12/2016 à 21:49, paul.sz...@sydney.edu.au a écrit :
[...]
>> Maybe /etc/tomcat8/Catalina/localhost is to be "delivered" writable from
>> the DEB package, the ownership only to be fixed in postinst? In the
>> current DEB, that directory is not group-writable.
> 
> This is worth trying. The catch is that other packages also install
> files into /etc/tomcat8/Catalina/localhost, so they all have to set the
> permissions properly. I'll probably go down this path if someone has a
> good argument supporting the use of copyXML=true.

Just my 2 cents about the "other" packages that install files into
/etc/tomcat8/Catalina/localhost. In my opinion they should just symlink
files into this path if at all. You mentioned jspwiki as one possible
candidate in one of your earlier emails but this one has been broken for
a long time now. It is probably easier to fix such issues in those
packages and not in Tomcat itself.

Markus








signature.asc
Description: OpenPGP digital signature

Bug#828371: lastpass-cli openssl 1.1.0 now has PR upstream

[Sebastian Andrzej Siewior]

On 2016-11-02 22:13:04 [+0100], Andreas Henriksson wrote:
> Hello!
Hi,

> 
> I've sent a PR to upstream that fixes building against OpenSSL 1.1.0.
> Same patch should apply cleanly to the packaged version.

could you please address the review comments and update your pull
request?

> Regards,
> Andreas Henriksson

Sebastian

Bug#846539: ITP: gwcs -- Tools for managing the World Coordinate System of astronomical data

[Miguel de Val-Borro]

Package: wnpp
Owner: Miguel de Val-Borro 
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: gwcs
  Version : 0.5.1
  Upstream Author : Nadia Dencheva 
* URL : https://github.com/spacetelescope/gwcs
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Tools for managing the World Coordinate System of 
astronomical data

GWCS supports a data model which includes the entire transformation pipeline
from input coordinates to world coordinates.  The goal of the package is to
provide a flexible toolkit which is easily extendible by adding new transforms
and frames.

The package will be maintained using a git repository on alioth.

Best,
Miguel

Bug#846538: coz-profiler: executable missing

[Aaron M. Ucko]

Package: coz-profiler
Version: 0.0.git.20161130T1802-1
Severity: grave
Justification: renders package unusable

The actual coz executable went missing in the latest build.  Could you
please reinstate it?

Thanks!

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

Kernel: Linux 4.8.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 coz-profiler depends on:
ii  fonts-font-awesome  4.7.0~dfsg-1
ii  libjs-jquery3.1.1-1
ii  python  2.7.11-2

coz-profiler recommends no packages.

coz-profiler suggests no packages.

-- no debconf information

Bug#823659: openssh-server: do not start on boot on systemd: missing privilege separation directory: /var/run/sshd

[Andreas Schamanek]

Dmitry,

> IMHO the best way to fix this problem permanently would be to add 
> "debian/openssh-server.ssh.tmpfile" file with the following content:
> d /var/run/sshd 0755 root root

Isn't that what

$ cat /usr/lib/tmpfiles.d/sshd.conf
d /var/run/sshd 0755 root root

is supposed to do?

BTW, there are 2 similar bug reports:

/run on tmpfs breaks sshd started from inetd
https://bugs.debian.org/645788

systemd service does not automatically create /var/run/sshd
https://bugs.debian.org/760422

-- 
-- Andreas

:-)

Bug#846078: [pycogent/pycogent] Random failures of test suite (#103)

[Andreas Tille]

On Thu, Dec 01, 2016 at 05:58:41PM +0100, Santiago Vila wrote:
> On Thu, 1 Dec 2016, Andreas Tille wrote:
> 
> > Version 1.9-6 is available now.  While it does not build on mips and
> > mips64el I'd like to hear from you before doing something about this
> > which also seems to be pure random since previous upload have built
> > nicely.
> 
> I've built 100 times version 1.9-6 and it failed none.

Thanks for confirming and all you great QA work

 Andreas.

-- 
http://fam-tille.de

Bug#846537: auctex: fails to compile for emacs25

[Julian Gilbey]

Package: auctex
Version: 11.88-1.3
Severity: important

auctex failed to compile for emacs25.  The CompilationLog file (see in
full below) ends with the lines:

In toplevel form:
style/subfigure.el:44:5:Error: missing value for ‘TeX-complete-list’ at end of 
setq

Best wishes,

   Julian

-- Package-specific info:

Content of '/usr/share/emacs/site-lisp/auctex'

d41d8cd98f00b204e9800998ecf8427e  /usr/share/emacs/site-lisp/auctex/.nosearch
fc46c46f400a42af007fd42ce73395be  /usr/share/emacs/site-lisp/auctex/bib-cite.el
5ac2595246062777c61ed4104a93cf61  
/usr/share/emacs/site-lisp/auctex/context-en.el
f5ed983cd477814f04e4a63affd4f323  
/usr/share/emacs/site-lisp/auctex/context-nl.el
aaede47229785ee362c712c6887cc44f  /usr/share/emacs/site-lisp/auctex/context.el
f63e08bcef29eae9f56db5d404a0  
/usr/share/emacs/site-lisp/auctex/font-latex.el
f176261b5a5511cbe1401ee72ffb8947  
/usr/share/emacs/site-lisp/auctex/images/amstex.xpm
d33121019448617a3ad3bcafdeb8db40  
/usr/share/emacs/site-lisp/auctex/images/bibtex.xpm
1a43d6438010bceb374ab0a5f2bd05a8  
/usr/share/emacs/site-lisp/auctex/images/dropdown.xpm
41f1ae0341ae2e307d92a7b8b815f868  
/usr/share/emacs/site-lisp/auctex/images/dvipdf.xpm
2e4b8669b0168f32247411be3f999437  
/usr/share/emacs/site-lisp/auctex/images/dvips.xpm
55f7600cadc3a209e94bacf6bbc42a7c  
/usr/share/emacs/site-lisp/auctex/images/error.xpm
c29ad797273fd27201a40bd939a95fe0  
/usr/share/emacs/site-lisp/auctex/images/exec.xpm
79b958849511c67d6b13ef9f5b3673e8  
/usr/share/emacs/site-lisp/auctex/images/execbibtex.xpm
a8570e26e9f96b6f527cdbe218d6c55f  
/usr/share/emacs/site-lisp/auctex/images/execdvips.xpm
e647bc601aef2dc71b134a989df1adff  
/usr/share/emacs/site-lisp/auctex/images/execerror.xpm
4610ec6133f89ceb441c43dfee077361  
/usr/share/emacs/site-lisp/auctex/images/execpdftex.xpm
c9cd1fc9fe4fd122cbf900fae654a67b  
/usr/share/emacs/site-lisp/auctex/images/exectex.xpm
6a6b9af945d4735f048ea8e475f8d9b8  
/usr/share/emacs/site-lisp/auctex/images/execviewdvi.xpm
466466f6d1867510b058a9c184ffce5d  
/usr/share/emacs/site-lisp/auctex/images/execviewpdf.xpm
39d8ccaffb40b0c118e000f45272db05  
/usr/share/emacs/site-lisp/auctex/images/execviewps.xpm
6767e2583c668dcb47495197b9e8cb65  
/usr/share/emacs/site-lisp/auctex/images/gv.xpm
ff9c61ef5148a0cacd5422d7c0d99396  
/usr/share/emacs/site-lisp/auctex/images/jumpdvi.xpm
ece6608586b591f50f20d17cdb316a1c  
/usr/share/emacs/site-lisp/auctex/images/ltx-symb-turn-off.xpm
b1f10de33dcf1b5ca9ac6155c13683a3  
/usr/share/emacs/site-lisp/auctex/images/ltx-symb-turn-on.xpm
44e35faa18ab34f3c13ac3b0082bcc47  
/usr/share/emacs/site-lisp/auctex/images/pdftex.xpm
84673eb20ac3be7bf0eb4e84e23e828f  
/usr/share/emacs/site-lisp/auctex/images/prverr16.xpm
59e6a0dddb00ab16c4209a2e4c6e283d  
/usr/share/emacs/site-lisp/auctex/images/prverr20.xpm
30dc2ada41625cb24ea459bd62f7386c  
/usr/share/emacs/site-lisp/auctex/images/prverr24.xbm
225929f8131bdd7b9b8207494a59619a  
/usr/share/emacs/site-lisp/auctex/images/prverr24.xpm
0dac3d8eb00c902037cc5fa6a03e53e3  
/usr/share/emacs/site-lisp/auctex/images/prvtex-cap-up.xpm
40feb30f80d3606f32ba54b57ba18af5  
/usr/share/emacs/site-lisp/auctex/images/prvtex12.xbm
e1b3c9d6a6eb6fb6f096736cdfc059cf  
/usr/share/emacs/site-lisp/auctex/images/prvtex12.xpm
32406fc4b893b48d2996c424f61ea238  
/usr/share/emacs/site-lisp/auctex/images/prvtex16.xbm
cc4101ee6a3ab6a1f4e9991b91b3ff0b  
/usr/share/emacs/site-lisp/auctex/images/prvtex16.xpm
d4dbe057a8d3b2facd61cf7583c1e97c  
/usr/share/emacs/site-lisp/auctex/images/prvtex20.xpm
f25ba1b984b095c9c561e5443f3d77a3  
/usr/share/emacs/site-lisp/auctex/images/prvtex24.xbm
28ac0855d853f606dd91e3cfacaa8a14  
/usr/share/emacs/site-lisp/auctex/images/prvtex24.xpm
6ce704103821329336489e990bc6f267  
/usr/share/emacs/site-lisp/auctex/images/prvwrk12.xpm
5607f4e8bc0eb555206e6a3542205f45  
/usr/share/emacs/site-lisp/auctex/images/prvwrk14.xpm
878a72cde3bb6f0ea6d586cff56e619c  
/usr/share/emacs/site-lisp/auctex/images/prvwrk16.xpm
41811748a97673381115957d42a6529b  
/usr/share/emacs/site-lisp/auctex/images/prvwrk20.xpm
254fc07db6a03a8a24f762135a403433  
/usr/share/emacs/site-lisp/auctex/images/prvwrk24.xbm
9690511307f3693e6f28e4db93fdc58c  
/usr/share/emacs/site-lisp/auctex/images/prvwrk24.xpm
e30a80ecb0711ceb42a2ca966ad74bbb  
/usr/share/emacs/site-lisp/auctex/images/pspdf.xpm
5cc696e2c69ae401c0c223d84d013c8e  
/usr/share/emacs/site-lisp/auctex/images/sep.xpm
e975868b87770a0e1a404292a314d246  
/usr/share/emacs/site-lisp/auctex/images/spell.xpm
861fc288565e624ce8b34c1fc42e3496  
/usr/share/emacs/site-lisp/auctex/images/tex.xpm
338158cc358b16daf9b58ee54bd14bad  
/usr/share/emacs/site-lisp/auctex/images/view.xpm
8147722e0061799437edf36d4466e5ab  
/usr/share/emacs/site-lisp/auctex/images/viewdvi.xpm
67d7ed652615a027038610f8370ba172  
/usr/share/emacs/site-lisp/auctex/images/viewpdf.xpm

Bug#845393: Pending fixes for bugs in the tomcat8 package

[Emmanuel Bourg]

Le 1/12/2016 à 21:49, paul.sz...@sydney.edu.au a écrit :

> Sorry for my previous outbursts. I was wrong.

No problem, thanks a lot for the review.


> However... will tomcat still "work"? On my machine, I have one XML file
>   /etc/tomcat8/Catalina/localhost/mapleta.xml
> in there, for the one application(?) that is installed. I guess it was
> tomcat that put it there: then tomcat needs write access to localhost.

That's a good question, and I think it should be ok.

Tomcat copies the META-INF/context.xml file from the web application
into this directory and renames it if the Host element in server.xml has
the copyXML attribute set to true (the default value is false).

When copyXML is true and the directory is read-only an error is
displayed in catalina.out and the web application is not loaded. The
error looks like this:

Error deploying web application directory /var/lib/tomcat8/webapps/foo
java.nio.file.AccessDeniedException: /etc/tomcat8/Catalina/localhost/foo.xml

The copyXML attribute was introduced in Tomcat 7, with Tomcat 6 the
context.xml file was always copied (the behavior was thus equivalent to
copyXML=true in later releases). In your case I guess you either
inherited the mapleta.xml file from a Tomcat 6 installation migrated to
Tomcat 7/8, put the file there manually and forgot about it, or have
copyXML=true in server.xml.

I'm not sure about the use case for copyXML=true. Once the context.xml
file has been copied, the original file is always ignored, even if the
web application is updated with a more recent context descriptor. Thus
the first deployment of the application blocks any subsequent change to
the context descriptor. That's a bit odd and I'd be interested to know
why people are doing this.

The use of context descriptors in /etc/tomcat8/Catalina/localhost is a
valid strategy to override the default configuration of the web
application, but the creation of this file is necessarily a manual
operation, an automatic copy brings nothing useful.

Due to the fact that copyXML defaults to false, and copyXML=true looks
dubious, I think it's ok to keep the localhost directory ready-only for
the tomcat8 user.


> Maybe /etc/tomcat8/Catalina/localhost is to be "delivered" writable from
> the DEB package, the ownership only to be fixed in postinst? In the
> current DEB, that directory is not group-writable.

This is worth trying. The catch is that other packages also install
files into /etc/tomcat8/Catalina/localhost, so they all have to set the
permissions properly. I'll probably go down this path if someone has a
good argument supporting the use of copyXML=true.

Emmanuel Bourg

Bug#828330: canl-c/gridsite: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2016-11-15 20:22:10 [+0100], Stefan Fritsch wrote:
> Hi again,
Hi,

> On Saturday, 12 November 2016 07:51:40 CET Stefan Fritsch wrote:
> > If these two packages cannot transition to openssl 1.1.0 before apache2
> > does, I suggest that you build with openssl 1.0.2 explicitly and then
> > downgrade the bugs and unlink them from the transition bug. I don't have
> > much hope that apache2 will transition in time for stretch release.
> 
> since there is now some discussion about this on debian-devel and debian-
> release, maybe you should wait a bit with any actions.

is there a reason for gridsite not to go for 3.0 (or backport the
change) and libssl-dev? Apache stays 1.0 but does not expose anything
SSL related (unless I read #828236 too quick).

> Cheers,
> Stefan

Sebastian

Bug#846531: Re[2]: Bug#846531: lldb-3.8 and lldb-3.9 are completely unusable in stretch (multiply problems); fix them or remove from scretch

[Askar Safin]

>Please report a bug per issue. It is too hard to track otherwise.
Is this okey if I create several bugs which differ in title and all point to 
this bug?

==
Askar Safin
http://vk.com/safinaskar

Bug#846536: python-certbot: Not installable in jessie backports

[Matthew Gabeler-Lee]

Package: python-certbot
Version: 0.9.3-1~bpo8+1
Severity: normal

Trying to install python-certbot (really letsencrypt), running into two
dependency issues, one with python-certbot itself and the other with an
indirect dependency python-acme has.

p-c depends on a newer version of python-cryptography than is available, and
depends on python-acme which depends on a newer version of python-openssl
than is available.

$ sudo apt install python-certbot python-acme
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming. 
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python-acme : Depends: python-openssl (>= 0.15) but 0.14-1 is to be installed
   Depends: python-cryptography (>= 0.8) but 0.6.1-1 is to be 
installed
   Depends: python-setuptools (>= 11.3~) but 5.5.1-1 is to be 
installed
   Recommends: python-dnspython but it is not going to be installed
 python-certbot : Depends: python-cryptography (>= 0.7) but 0.6.1-1 is to be 
installed
  Recommends: letsencrypt
  Recommends: python-psutil (>= 2.2.1) but it is not going to 
be installed
E: Unable to correct problems, you have held broken packages.

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 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)

Bug#612114: 'greylistd' creates severe disk full situation [was: spams logs]

[Tovar]

Twice, this problem has forced me to reboot my server into single-user mode
to clean out these messages from my log file.  Each time, Debian has done a
large set of updates, which has had 'dpkg/apt' putting lots of .deb files 
into '/var/cache/apt', which shouldn't be a problem by itself.  But if the
disk is a bit low on space and one then suffers a deny-of-service attack, 
Linux can end up filling the partition containing '/var/log' with error
messages.

Ordinarily, disk full from a denial of service attack is something one can
recover from fairly easily as a super-user, as Linux assigns extra space
that ordinary users cannot use.  Alas, it appears that 'greylistd' quickly
fills all of that space with enumerable copies of the same error message:

   greylistd: Cannot write to /var/lib/greylistd/states.4009: No space left on 
device

I can think of a few ways to fix this problem.  First, duplicate error
messages could be suppressed.  One might do this by remembering the time
of the last disk full message at 'program/greylistd:286' and supressing 
messages that have occurred too recently.  Or perhaps these errors could
be counted  and the number observed printed at a later time, say after 
N seconds (or N minutes) or when another error message is generated.  

Or, if the disk is full and the daemon cannot function anyway, it may as
well go to sleep and try again later.  If the sleep time is long enough, 
it won't put enough messages in the log as to make a bad problem worse.

Another possible fix would be also record the time of the last disk-full
error, as above, and to check it at 'do_save()' [program/greylistd:286].  
It would then not bother trying to save anything until enough time has
elapsed to make it worthwhile to try again.

While i know well at least a half-dozen programming languages, 'python'
is not one of them and i regret that i am not submitting a patch at this
time.
 -- Tovar

Bug#844100: transition: ppl

[Emilio Pozuelo Monfort]

On 30/11/16 00:30, Tobias Hansen wrote:
> On 11/12/2016 07:58 PM, Tobias Hansen wrote:
>> On 11/12/2016 02:49 PM, Emilio Pozuelo Monfort wrote:
>>> Control: tags -1 confirmed
>>>
>>> On 12/11/16 15:02, Tobias Hansen wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition

 Hi Release Team,

 I noticed yesterday that ppl has two RC bugs and was removed from
 testing. I would like to take over the package and fix it, but one of
 the RC bugs (#811825) is best fixed by updating to the new upstream
 version, which requires a small library transition. Since the
 debian-devel-announce@l.d.o mail from November 5 said the transition
 freeze is only for "transitions that involve a large number of packages",
 I'd thought I'd ask if we can still do this transition.

 I already created a package of ppl 1.2 that fixes both RC bugs. ppl has
 two reverse dependencies, which were of course both removed from testing
 because of ppl:

 apron
 cloog-ppl

 I checked that they both build without changes against the updated ppl
 package.

 If it's too late for the transition, we'll have to see if we can fix
 #811825 by applying a patch that does not require a transition.
>>>
>>> Since this package is not in testing, and because of the small number of 
>>> rdeps,
>>> there isn't a big risk of regressions wrt current testing... so please go 
>>> ahead.
>>>
>>> Emilio
>>>
>>
>> Thanks a lot for granting this exception! ppl 1.2 is now in NEW.
>>
>> Best,
>> Tobias
>>
> 
> The package is now in unstable. I think the only thing that is missing
> now is a binNMU for apron. cloog-ppl already got an upload to build
> against ppl 1.2.

I scheduled that.

Cheers,
Emilio

Bug#846535: openssl: 1.1.0c cannot decrypt files created by older versions of openssl

[Robbie Harwood]

Package: openssl
Version: 1.1.0c-2
Severity: critical
Justification: causes serious data loss

Dear Maintainer,

After upgrading to a newer version of OpenSSL, I cannot decrypt a file that
was encrypted using the OpenSSL in Stable (and had been decryptable until very
recently).

To reproduce:

root@stable:~# echo "test" > file
root@stable:~# echo "secretes" | openssl enc -aes-256-cbc -in file -out 
file.enc -pass stdin

Then copy the file to a (testing) system and:

rharwood@thriss:/tmp$  echo "secretes" | openssl enc -d -aes-256-cbc -in 
file.enc -out file -pass stdin
bad decrypt
140704872014976:error:06065064:digital envelope 
routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:529:

Thanks!

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

Kernel: Linux 4.8.0-1-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages openssl depends on:
ii  libc6  2.24-7
ii  libssl1.1  1.1.0c-2

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20161102

-- no debconf information

Bug#846502: nvidia-driver: could not install nvidia-driver under sid because of dependence broken

[liang yan]

My fault, it works well again with experimental version.

I used wrong repo address at the first time. Right one should be:

deb http://ftp.de.debian.org/debian experimental main non-free



On Thu, 1 Dec 2016 15:16:34 -0700 liang yan wrote:
> Hello, Luca,
>
> Thanks for replying, but it could not be installed under experimental.
>
> Looks xserver-xorg-core is in a newer version. I tried install a lower
> version xserver-xorg-core to install nvidia-driver, it could finish
> installment, but then freeze on the login window, no response to any
input.
>
>
> Thanks,
>
> Liang
>
>
>
> On Thu, 01 Dec 2016 18:03:43 + Luca Boccassi wrote:
> > Control: reassign -1 nvidia-graphics-drivers
> >
> > On Thu, 2016-12-01 at 10:21 -0700, Liang Yan wrote:
> > > Package: nvidia-driver
> > > Version: 367
> > > Severity: critical
> > > Justification: breaks unrelated software
> > >
> > > Dear Maintainer,
> > >
> > >
> > > When I upgraded my sid system, I found could not install
> nvidia-driver 367 any more, becuase of nvidia-setting or
> xserver-xorg-video-nvidia.
> > >
> > > I think Upload new version nvidia-setting could fix this problem.
> > >
> > > Thanks,
> > > Liang
> >
> > Hi,
> >
> > Install the drivers from experimental until 845638 is sorted:
> >
> > apt-get install -t experimental nvidia-driver
> >
> > Kind regards,
> > Luca Boccassi
>



signature.asc
Description: OpenPGP digital signature

Bug#846520: pcl: enable parallel builds on 32 bit arches

[Emilio Pozuelo Monfort]

On 01/12/16 23:25, Jochen Sprickerhof wrote:
> Hi Emilio,
> 
> * Emilio Pozuelo Monfort  [2016-12-01 22:24]:
>> Why was this disabled? Do the builds run out of memory often? It'd be good
>> to re-enable this, the speedup is huge and it would avoid taking one buildd
>> for a day and a half on some architectures.
> 
> Exactly because it was running out of memory. Quoting from the buildd:
> 
> | cc1plus: out of memory allocating 903468 bytes after a total of 19152896 
> bytes
> 
> I asked in #debian-buildd back then and the consensus was to remove the
> --parallel. Is there any reason to revert this now?

We have more powerful buildds, at least in some architectures. Not sure about
RAM/swap. Also there was one bad build back then, but several good builds. I'm
not sure if this is such an issue, but I think it's worth re-trying. Doesn't
need to happen right now just for the sake of it, it can be uploaded when there
are other worthwhile changes.

If parallel support is re-enabled and some builds fail, we can evaluate whether
it's best to disable parallel support on specific architectures, blacklist pcl
in specific buildds, lower the parallelism without disabling it entirely, or
disabling it altogether in 32-bits architectures again.

Cc'ing debian-wb-team@ to see if anybody disagrees.

Thanks,
Emilio

Bug#846067: RM: glpi -- RoQA; unmaintained; RC-buggy

[Eriberto]

Em quinta-feira, 1 de dezembro de 2016, Scott Kitterman <
deb...@kitterman.com> escreveu:

> On Wed, 30 Nov 2016 16:32:49 -0200 Eriberto Mota  > wrote:
> > Please,
> >
> > Give me 3 days and I will try ressurrect this package as new
> > maintainer. I will go back soon to say my opinion.
>
> Tagged moreinfo to give you a bit of time.
>
> Scott K
>

Thanks Scott.

I am working over this package since yesterday. I will need a bit more
time. I will send news in next week.

Eriberto

Bug#846520: pcl: enable parallel builds on 32 bit arches

[Jochen Sprickerhof]

Hi Emilio,

* Emilio Pozuelo Monfort  [2016-12-01 22:24]:
> Why was this disabled? Do the builds run out of memory often? It'd be good
> to re-enable this, the speedup is huge and it would avoid taking one buildd
> for a day and a half on some architectures.

Exactly because it was running out of memory. Quoting from the buildd:

| cc1plus: out of memory allocating 903468 bytes after a total of 19152896 bytes

I asked in #debian-buildd back then and the consensus was to remove the
--parallel. Is there any reason to revert this now?

Cheers Jochen


signature.asc
Description: PGP signature

Bug#846534: libvirt-daemon-system: VM with usb host device fails to start when apparmor is enabled

[Kjö Hansi Glaz]

Package: libvirt-daemon-system
Version: 2.4.0-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Define a VM with an USB host device:


  


  
  


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Try to start the VM on a system with apparmor enabled

   * What was the outcome of this action?

libvirtError: internal error: qemu unexpectedly closed the monitor: 
2016-12-01T22:30:29.196276Z qemu-system-x86_64: -device 
usb-host,hostbus=3,hostaddr=5,id=hostdev0,bus=usb.0,port=4: failed to find host 
usb device 3:5

The system journal contains apparmor errors, see below.

   * What outcome did you expect instead?

The VM to start.

   * Notes

Please note that there is an ubuntu bug for this issue:

https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1515791

   * System log when starting the VM:

déc. 01 23:34:34 host audit[8338]: AVC apparmor="STATUS" 
operation="profile_replace" name="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
pid=8338 comm="apparmor_parser"
déc. 01 23:34:34 host kernel: audit: type=1400 audit(1480631674.577:394): 
apparmor="STATUS" operation="profile_replace" 
name="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" pid=8338 
comm="apparmor_parser"
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/sys/module/vhost/parameters/max_mem_regions" pid=8340 
comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=117 ouid=0
déc. 01 23:34:34 host kernel: audit: type=1400 audit(1480631674.625:395): 
apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/sys/module/vhost/parameters/max_mem_regions" pid=8340 
comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=117 ouid=0
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/proc/8340/task/8343/comm" pid=8340 comm="qemu-system-x86" 
requested_mask="rw" denied_mask="rw" fsuid=117 ouid=117
déc. 01 23:34:34 host kernel: audit: type=1400 audit(1480631674.625:396): 
apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/proc/8340/task/8343/comm" pid=8340 comm="qemu-system-x86" 
requested_mask="rw" denied_mask="rw" fsuid=117 ouid=117
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/proc/8340/task/8344/comm" pid=8340 comm="qemu-system-x86" 
requested_mask="rw" denied_mask="rw" fsuid=117 ouid=117
déc. 01 23:34:34 host kernel: audit: type=1400 audit(1480631674.625:397): 
apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/proc/8340/task/8344/comm" pid=8340 comm="qemu-system-x86" 
requested_mask="rw" denied_mask="rw" fsuid=117 ouid=117
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/run/udev/data/c189:256" pid=8340 comm="qemu-system-x86" 
requested_mask="r" denied_mask="r" fsuid=117 ouid=0
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/run/udev/data/+usb:2-1:1.0" pid=8340 comm="qemu-system-x86" 
requested_mask="r" denied_mask="r" fsuid=117 ouid=0
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/run/udev/data/c189:129" pid=8340 comm="qemu-system-x86" 
requested_mask="r" denied_mask="r" fsuid=117 ouid=0
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/run/udev/data/c189:0" pid=8340 comm="qemu-system-x86" requested_mask="r" 
denied_mask="r" fsuid=117 ouid=0
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/run/udev/data/+usb:1-1.1:1.1" pid=8340 comm="qemu-system-x86" 
requested_mask="r" denied_mask="r" fsuid=117 ouid=0
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/run/udev/data/+usb:3-0:1.0" pid=8340 comm="qemu-system-x86" 
requested_mask="r" denied_mask="r" fsuid=117 ouid=0
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/run/udev/data/+usb:2-1.8.3:1.1" pid=8340 comm="qemu-system-x86" 
requested_mask="r" denied_mask="r" fsuid=117 ouid=0
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" operation="open" 
profile="libvirt-bd2a0f7a-1637-4dc2-90c4-55b9b1980d86" 
name="/run/udev/data/c189:132" pid=8340 comm="qemu-system-x86" 
requested_mask="r" denied_mask="r" fsuid=117 ouid=0
déc. 01 23:34:34 host audit[8340]: AVC apparmor="DENIED" 

Bug#842690: Please overthink the packaging layout

[dann frazier]

On Mon, Oct 31, 2016 at 12:11:31PM +0100, Alexander Kurtz wrote:
> This becomes even more important if you try to fix #842683 [1], so I
> propose a scheme looking something like this:
> 
>  * There is only one arch:all package called "ovmf" containing the 
>builds for all architectures.
> 
>  * The actual firmware files could be named like this:
> 
>/usr/share/ovmf/$arch.$type
> 
>where $arch would be the UEFI-style architecture name in lower 
>case, i.e. "ia32", "x64", "ia64", "arm", "aa64" [2] and $type
>would be one of "code", "vars", "unified" (for the deprecated 
>variant with code and vars in one file).
> 
>  * Compatibility is ensured by providing a transitional qemu-efi 
>package depending on the ovmf package and the ovmf package
>carrying symlinks for all previously used file paths.
> 
> What do you think?

Alexander,
 Thanks for starting this discussion. I agree that the current scheme
needs improvement. I think package names, file paths, and grouping are
all fairly independent topics, so I'll address each one separately,
starting with package names.

My reasons for choosing "qemu-efi" when adding the aa64 images were
twofold:
 1) "OVMF", in upstream source, refers only to the x86-specific
build. The ARM images have always had a different name - initially
ArmVirtualizationQemu, and currently ArmVirt.
 2) "OVMF" doesn't seem like a keyword users would likely be familiar
with. I'd expect a user to know they want "EFI" or "UEFI" for use
with QEMU. OVMF, IMO, is yet another obscure term in the soup of
names here (edk2, EFI, UEFI, Tianocore, OVMF).

Therefore, if we're going to try for more consistent package naming, I
think I'd rather not consolidate under "ovmf". Since, AFAIK, these
images are only useful for QEMU models, I'd rather go the other way
and use the "qemu-efi" stem instead of "ovmf", e.g.:
  qemu-efi-{aa32,aa64,ia32,x64}-virt

As for file paths, we're currently using the paths that libvirt and
OpenStack nova default to. We could move everything and provide
symlinks for compat, but I'm not convinced this is a big enough
problem to do so - in fact, I think that would only add confusion.
That said, libvirt/OpenStack don't appear to have unique paths defined
for 32-bit variants, so I'm not sure what to do for those.

Finally, regarding package grouping, I do think we want to retain
the ability to install the firmware for each architecture
independently - similar to how it is possible to install
qemu-system- packages independently. I suspect that most users
really just require one of them, and combining them all would make a
very large package (qemu-efi's Installed-Size alone is currently
129M). If there's a good use case for a meta package that installs all
of them, I'd be +1 for that.

  -dann

Bug#846533: apertium-hbs FTBFS in stretch due to missing libhfst45-dev

[Adrian Bunk]

Source: apertium-hbs
Version: 0.5.0~r68212-1
Severity: serious
Tags: stretch sid
Control: block -1 by 827199

apertium-hbs build-depends on libhfst45-dev,
which is not in stretch due to #827199

Bug#846502: nvidia-driver: could not install nvidia-driver under sid because of dependence broken

[liang yan]

Hello, Luca,

Thanks for replying, but it could not be installed under experimental.

Looks xserver-xorg-core is in a newer version. I tried install a lower
version xserver-xorg-core to install nvidia-driver, it could finish
installment, but then freeze on the login window, no response to any input.


Thanks,

Liang



On Thu, 01 Dec 2016 18:03:43 + Luca Boccassi wrote:
> Control: reassign -1 nvidia-graphics-drivers
>
> On Thu, 2016-12-01 at 10:21 -0700, Liang Yan wrote:
> > Package: nvidia-driver
> > Version: 367
> > Severity: critical
> > Justification: breaks unrelated software
> >
> > Dear Maintainer,
> >
> >
> > When I upgraded my sid system, I found could not install
nvidia-driver 367 any more, becuase of nvidia-setting or
xserver-xorg-video-nvidia.
> >
> > I think Upload new version nvidia-setting could fix this problem.
> >
> > Thanks,
> > Liang
>
> Hi,
>
> Install the drivers from experimental until 845638 is sorted:
>
> apt-get install -t experimental nvidia-driver
>
> Kind regards,
> Luca Boccassi



signature.asc
Description: OpenPGP digital signature

Bug#846532: mod-gnutls FTBFS in stretch due to missing monkeysphere

[Adrian Bunk]

Source: mod-gnutls
Version: 0.7.5-2
Severity: serious
Tags: stretch sid
Control: block -1 by 841208 844971

mod-gnutls build-depends on monkeysphere,
which is not in stretch due to #841208, #844971

Bug#846531: lldb-3.8 and lldb-3.9 are completely unusable in stretch (multiply problems); fix them or remove from scretch

[Sylvestre Ledru]

Le 01/12/2016 à 23:04, Askar Safin a écrit :

Package: lldb-3.8
Version: 1:3.8.1-16
Severity: grave
Justification: renders package unusable

Please report a bug per issue. It is too hard to track otherwise.

Thanks for the testing
S

Bug#822055: maria: diff for NMU version 1.3.5-4.1

[Sebastian Ramacher]

Dear maintainer,

I've prepared an NMU for maria (versioned as 1.3.5-4.1). The diff
is attached to this message.

Regards.
-- 
Sebastian Ramacher
diff -Nru maria-1.3.5/debian/changelog maria-1.3.5/debian/changelog
--- maria-1.3.5/debian/changelog	2011-05-13 22:11:51.0 +0200
+++ maria-1.3.5/debian/changelog	2016-12-01 23:06:16.0 +0100
@@ -1,3 +1,12 @@
+maria (1.3.5-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Santiago Vila ]
+  * Add build-arch and build-indep targets. (Closes: #822055)
+
+ -- Sebastian Ramacher   Thu, 01 Dec 2016 23:06:16 +0100
+
 maria (1.3.5-4) unstable; urgency=low
 
   * debian/control:
diff -Nru maria-1.3.5/debian/rules maria-1.3.5/debian/rules
--- maria-1.3.5/debian/rules	2011-05-13 22:11:51.0 +0200
+++ maria-1.3.5/debian/rules	2016-12-01 23:04:47.0 +0100
@@ -14,6 +14,10 @@
   OPTFLAGS = -O0
 endif
 
+build-arch: build
+
+build-indep: build
+
 build: build-stamp
 
 build-stamp:
@@ -87,4 +91,4 @@
 	dh_builddeb -a
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch install-indep install-arch 
+.PHONY: build build-arch build-indep clean binary-indep binary-arch install-indep install-arch


signature.asc
Description: PGP signature

Bug#846507: the D frontend fails to build on sparc64

[Iain Buclaw]

On 1 December 2016 at 19:04, Matthias Klose <d...@debian.org> wrote:
> Package: src:gcc-7
> Version: 7-20161201-1
> Severity: important
>
> See
> https://buildd.debian.org/status/fetch.php?pkg=gcc-7=sparc64=7-20161201-1=1480609625
>
> GDC trunk is a snapshot from 20161113
>
> In file included from ./tm_p.h:4:0,
>  from ../../src/gcc/d/d-target.cc:33:
> ../../src/gcc/config/sparc/sparc-protos.h:50:47: error: use of enum 'memmodel'
> without previous declaration
>  extern void sparc_emit_membar_for_model (enum memmodel, int, int);
>^~~~
> Makefile:1101: recipe for target 'd/d-target.o' failed
> make[5]: *** [d/d-target.o] Error 1
> make[5]: *** Waiting for unfinished jobs
> ../../src/gcc/d/d-glue.cc: In function 'void escapePath(OutBuffer*, const 
> char*)':
> ../../src/gcc/d/d-glue.cc:289:24: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> buf->writeByte('\\');
> ^
> ../../src/gcc/d/d-glue.cc:291:2: note: here
>   default:
>   ^~~

So we need to:

1. Add memmodel.h to d-target.cc, as per trunk@240504.

2. Look at any new warnings and fix them up (if they are irritating enough).

Bug#846531: lldb-3.8 and lldb-3.9 are completely unusable in stretch (multiply problems); fix them or remove from scretch

[Askar Safin]

Package: lldb-3.8
Version: 1:3.8.1-16
Severity: grave
Justification: renders package unusable

lldb 3.8 is unusable is Stretch. Here is list of bugs. Most of them apply to 
lldb 3.9, too. Some of them apply
to lldb 3.7, too, but lldb 3.7 is somewhat usable unlike lldb 3.8 and lldb 3.9.

Steps to reproduce. I installed fresh Debian Stretch amd64 to Qemu/KVM virtual 
machine (for clean experiment)
using Debian Stretch alpha 8 installer
( 
http://cdimage.debian.org/cdimage/stretch_di_alpha8/amd64/iso-cd/debian-stretch-DI-alpha8-amd64-netinst.iso
 ).
During installation I cleared checkbox "Install standard system utilities" to 
catch lldb dependency errors.
After installation I put 'APT::Install-Recommends "false";' to apt.conf for the 
same reason.
Then I performed some misc. configuration and installed some misc. packages 
(for example, openssh-server to
connect to this VM from outside).
Then:

debian:~# apt-get install clang-3.8 lldb-3.8
debian:~# echo 'int main (void) {}' > a.cpp
debian:~# clang-3.8 -g -o a a.cpp  # See below on clang-3.8 and clang++-3.8
debian:~# lldb-3.8 ./a
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named lldb.embedded_interpreter
(lldb) target create "./a"
Current executable set to './a' (x86_64).
(lldb)

Problem 1. "ImportError: No module named lldb.embedded_interpreter".

Then I pressed "r". "\U+96272" appeared instead. This happened in ssh session 
from host in X terminal (KDE's
konsole), TERM is xterm. Same is happenning on linux console in VM (TERM is 
linux).

Problem 2. "\U+96272".

Then:

debian:~# cat | lldb-3.8 ./a
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named lldb.embedded_interpreter
(lldb) target create "./a"
Current executable set to './a' (x86_64).
r
(lldb) r
error: process launch failed: unable to locate lldb-server

Problem 3. "error: process launch failed: unable to locate lldb-server".

Then:

debian:~# ln -s lldb-server-3.8 /usr/bin/lldb-server
debian:~# cat | lldb-3.8 ./a
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named lldb.embedded_interpreter
(lldb) target create "./a"
Current executable set to './a' (x86_64).
r
(lldb) r
^C
^\Quit
debian:~#

And now lldb freezed.

Problem 4. lldb freezes.

And now I don't know what to do and how to fix this. It seems
http://lists.llvm.org/pipermail/lldb-dev/2016-March/009925.html is related.

Then:

debian:~# apt-get install python-lldb-3.8

This fixed that "lldb.embedded_interpreter" problem, but lldb still freezes.

Full log is here: http://paste.debian.net/900115/

Additional notes:
* This bug report is sent from that VM using "bugreport".
* lldb 3.9 has the same bugs except that "lldb.embedded_interpreter" bug.
* lldb 3.7 has some of this bugs, but it is usable. It doesn't freeze, so I 
actually was able
to debug that C++ one-liner (but terminal support is still broken).
* At first I compiled the program so: "clang-3.8 -g -o a a.cpp" and reproduced 
all this bugs.
Then I compiled it so: "clang++-3.8 -g -o a a.cpp" and reproduced all this bugs 
again.

So:
* Fix this bugs in lldb 3.7, lldb 3.8 and lldb 3.9 before Stretch release. Or 
just remove this packages from Scretch.
* Test that they work out-of-the-box. Even if the system doesn't have "standard 
system utilities" and apt configured
not to install recommended packages.


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

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

Versions of packages lldb-3.8 depends on:
ii  libc6 2.24-7
ii  libedit2  3.1-20160903-2
ii  libffi6   3.2.1-6
ii  libgcc1   1:6.2.0-13
ii  liblldb-3.8   1:3.8.1-16
ii  libllvm3.81:3.8.1-16
ii  libncurses5   6.0+20160917-1
ii  libpython2.7  2.7.12-7
ii  libstdc++66.2.0-13
ii  libtinfo5 6.0+20160917-1
ii  llvm-3.8-dev  1:3.8.1-16
ii  zlib1g1:1.2.8.dfsg-2+b3

lldb-3.8 recommends no packages.

Versions of packages lldb-3.8 suggests:
ii  python-lldb-3.8  1:3.8.1-16

-- no debconf information

Bug#846530: g++-6: uint64_t toto=800*16'800'000; // -Woverflow reported

[unrde]

Package: g++-6
Version: 6.2.0-13
Severity: normal

Dear Maintainer,

This program fails:
``` c++
#include 

int main()
{
uint64_t toto = 800*16'800'000; // *should* be 10'080'000'000 
return 0;
}
``` 

when compiled with:

``` make
all:
g++ -Wall -std=c++14 main.cpp -o main.out
``` 

But it does work if I make the calculation myself.
g++ issued a warning (-Woverflow) and there was an overflow.
Expected result is 10'080'000'000 which fits in uint64_t, but got an
overflow instead.

Best regards,

unrde
un...@jetable.fr.nf


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core)
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 g++-6 depends on:
ii  gcc-66.2.0-13
ii  gcc-6-base   6.2.0-13
ii  libc62.24-7
ii  libgmp10 2:6.1.1+dfsg-1
ii  libisl15 0.17.1-1
ii  libmpc3  1.0.3-1
ii  libmpfr4 3.1.5-1
ii  libstdc++-6-dev  6.2.0-13
ii  zlib1g   1:1.2.8.dfsg-2+b3

g++-6 recommends no packages.

Versions of packages g++-6 suggests:
pn  g++-6-multilib
pn  gcc-6-doc 
pn  libstdc++6-6-dbg  

-- no debconf information

Bug#812530: ITP: libglvnd -- Vendor-neutral OpenGL dispatch layer

[Luca Boccassi]

On Thu, 2016-12-01 at 21:25 +0200, Timo Aaltonen wrote:
> On 01.12.2016 15:32, Luca Boccassi wrote:
> > On Sun, 07 Feb 2016 17:33:44 + Luca Boccassi  
> > wrote:
> >> Control: owner -1 tjaal...@debian.org
> >>
> >> On Mon, 2016-01-25 at 09:46 +0200, Timo Aaltonen wrote:
> >>> 24.01.2016, 20:34, Luca Boccassi kirjoitti:
>  * Package name: libglvnd
>    Version : 0~20160122
>    Upstream Author : NVIDIA Corporation
>  * URL : https://github.com/NVIDIA/libglvnd
>  * License : MIT
>    Programming Lang: C
>    Description : Vendor-neutral OpenGL dispatch layer
> 
>  libglvnd is a Vendor-neutral dispatch layer for arbitrating OpenGL API
>  calls between multiple vendors on a per-screen basis.
>  Currently, only the GLX window-system API and OpenGL are supported, but
>  in the future this library may support EGL and OpenGL ES as well.
> 
> 
>  I am one of the pkg-nvidia maintainers, and we would like to use this
>  ITP to start a discussion about packaging libglvnd with the maintainers
>  of Mesa, X and fglrx.
> 
>  As you might have read news about, NVIDIA has been working on an open
>  source (MIT-like license) vendor-neutral dispatch layer for OpenGL. They
>  have now declared it stable, and their proprietary graphics driver
>  started using it in version 361 [1].
> 
>  It has been reported that AMD is interested in supporting this library
>  too [2].
> 
>  Finally, following a discussion on the upstream Mesa mailing list [3],
>  it has been reported that work is in progress in Mesa too to support
>  this library [4].
> 
>  Our proposal would be to wait to upload this package until a version of
>  Mesa that can make use of it is released. Then, as a a possible example,
>  we could upload both to Debian experimental, and at the same time switch
>  the proprietary Nvidia drivers to use it, and see how it works. When
>  fglrx gets there too, we should then be able to stop using
>  glx-alternatives-* packages.
> 
>  My proposal for the packaging itself can be found on pkg-nvidia's git
>  [5]. Given upstream doesn't seem to do release tagging, I'm using the
>  0~ format. I split each .so in an individual binary
>  and -dbg package, called *-glvnd[-dbg], plus a common libglvnd-dev.
>  Figuring out precisely the licensing was the fun part, as the code is a
>  mixture of Expat, MIT-like, BSD 1-clause and 3-clause, GPL3 and
>  GNU-permissive :-)
> 
>  Comments? Opinions? ACKs/NACKs?
> >>>
> >>> packaging available at
> >>>
> >>> git://git.debian.org/pkg-xorg/lib/libglvnd.git
> >>>
> >>> but since it hasn't been of any use there was no ITP filed, so thanks
> >>> for that :)
> >>>
> >>> it's not final of course, tests fail and there are probably other issues
> >>> too..
> > 
> > Hi Timo,
> > 
> > Any news on uploading this to Stretch?
> > 
> > I think upstream Mesa has some initial support merged:
> > 
> > https://lists.freedesktop.org/archives/mesa-dev/2016-May/116346.html
> > https://cgit.freedesktop.org/mesa/mesa/tree/src/glx/glxglvnd.c
> 
> Yes, libglvnd had some packaging issues which I think are now solved in
> git. I'll probably upload it to experimental soon.

Great news, thank you for taking care of it! Once it's up in
experimental we'll work on it from the nvidia-driver side.

Kind regards,
Luca Boccassi


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

Bug#846529: pybit: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: pybit
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#846143: suricata: enable optional Hyperscan support

[Sascha Steinbiss]

Hi Arturo,

[…]
>> Beware that your current branch contains a lot of changes we don't
>> need (ie, cleanups of your own commits).
>> Please, push only the changes we are talking about (may require you to
>> manually merge some commits before pushing to pkg-suricata)
>> If you want, I can myself migrate the changes form your repo to pkg-suricata.
> 
[…]
> Let me just prepare a clean final 'hyperscan' branch in my own repo and
> then we can discuss what to do with it w.r.t. the official pkg-suricata
> repo.

Done, see 
https://anonscm.debian.org/cgit/users/satta/suricata.git/log/?h=hyperscan

Cheers
Sascha

Bug#846528: hyperscan: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: hyperscan
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#846527: openvas-scanner: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: openvas-scanner
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#846498: zeroc-icegridgui: Missing dependencies

[Jose Gutierrez de la Concha]

Hi José,

I will upload a new package with missing dependencies soon.

On Thu, Dec 1, 2016 at 5:46 PM, José Luis Segura Lucas 
wrote:

> Package: zeroc-icegridgui
> Version: 3.6.3-2
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> icegridgui needs two Java graphical libraries to work. The missing
> dependencies
> are:
>
> * libjgoodies-forms-java
> * libjgoodies-looks-java
>
> Best regards
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages zeroc-icegridgui depends on:
> ii  default-jdk   2:1.8-57
> ii  default-jre   2:1.8-57
> ii  libzeroc-ice3.6-java  3.6.3-2
> ii  openjdk-8-jdk 8u111-b14-3
> ii  openjdk-8-jre 8u111-b14-3
>
> zeroc-icegridgui recommends no packages.
>
> zeroc-icegridgui suggests no packages.
>
> -- no debconf information
>



-- 
José Gutiérrez de la Concha
ZeroC, Inc.

Bug#846526: cloud-init: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: cloud-init
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#846523: mate-notification-daemon: bold formatting is not properly displayed

[Ayke van Laethem]

Package: mate-notification-daemon
Version: 1.16.0-1
Severity: normal
Tags: patch

Dear Maintainer,

Notifications that provide bold text (via text), display these
characters literally instead of actually displaying bold text.
This has been fixed upstream:
https://github.com/mate-desktop/mate-notification-daemon/issues/111
https://github.com/mate-desktop/mate-notification-
daemon/commit/d9ed22c64d341914a91eaf16fa1b2c0771dee4af

I'm reporting the bug here as well, as it would be nice to include this fix in
Stretch before the full freeze.



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

Kernel: Linux 4.8.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 mate-notification-daemon depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-7
ii  libcairo-gobject21.14.6-1.1
ii  libcairo21.14.6-1.1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libdbus-1-3  1.10.12-1
ii  libdbus-glib-1-2 0.108-1
ii  libgdk-pixbuf2.0-0   2.36.0-1
iu  libglib2.0-0 2.50.2-2
iu  libgtk-3-0   3.22.4-1
ii  libnotify4   0.7.7-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libwnck-3-0  3.20.1-2
ii  libx11-6 2:1.6.3-1
ii  mate-notification-daemon-common  1.16.0-1

mate-notification-daemon recommends no packages.

mate-notification-daemon suggests no packages.

-- no debconf information

Bug#846524: graphite-carbon: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: graphite-carbon
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#846525: qpid-cpp: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: qpid-cpp
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#846522: nginx: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: nginx
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#846214: gcc-6: wrong code generation in protobuf-c testsuite, adding printf works around

[Matthias Klose]

On 01.12.2016 22:38, Thorsten Glaser wrote:
> On Thu, 1 Dec 2016, Thorsten Glaser wrote:
> 
>> On Thu, 1 Dec 2016, Matthias Klose wrote:
>>
>>>  - please could you reduce the test case to just run the failing test?
>>
>> I’ll try…
> 
> OK. I’ve got it cut down, both regular and preprocessed
> versions are attached.
> 
> If I comment out either bd_empty or bd_random in…
> 
>   DO_TEST (bd_empty, test_required_bytes_empty);
>   DO_TEST (bd_hello, test_required_bytes_hello);
>   DO_TEST (bd_random, test_required_bytes_random);
> 
> … the tests also pass, so this appears to be the minimum,
> despite bd_hello being the aborting one.

cool, thanks! bonus questions:

 - does the test pass with -O1, if yes can you identify
   the -O2 -fno-* flag?
 - do the above with -O0
 - do you get warnings when you run the test with
   the address and undefined sanitizers?

Matthias

Bug#846214: gcc-6: wrong code generation in protobuf-c testsuite, adding printf works around

[Thorsten Glaser]

On Thu, 1 Dec 2016, Thorsten Glaser wrote:

> OK. I’ve got it cut down, both regular and preprocessed
> versions are attached.

Attaching the .s output of the stripped-down version, both
unmodified and with the printf command changed. The diff
between them is not trivial, though.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

x1.s.gz
Description: application/gzip


x2.s.gz
Description: application/gzip

Bug#846521: override: vulture:devel/optional

[Daniel Stender]

Package: ftp.debian.org
Severity: normal

Please change the section for vulture, it has been "python/optional", but I've
switched it to "devel/optional".

That follows the Lintian complaint on "application-in-library-section", "python"
is just for libraries, but Vulture is an application.

Thank you,
Daniel Stender

[1] https://packages.qa.debian.org/v/vulture.html

Bug#845626: sparse: make sparse installable without graphical libraries

[Uwe Kleine-König]

Hello,

On 11/25/2016 11:58 AM, W. Martin Borgert wrote:
> Package: sparse
> Version: 0.5.0-1
> Severity: wishlist
> 
> I'm using sparse on a build server and would like to have it
> without ~55 MiB of GTK+ and GNOME libs. One could either split
> out test-inspect into its own package or only recommend
> libgtk2.0-0 instead of depending on it.

I'm open for a package split. Do you care enough to prepare a patch?

Best regards
Uwe

Bug#846214: gcc-6: wrong code generation in protobuf-c testsuite, adding printf works around

[Thorsten Glaser]

tags 846214 - moreinfo
thanks

On Thu, 1 Dec 2016, Matthias Klose wrote:

>  - please could you reduce the test case to just run the failing test?

I’ll try…

>  - please add the preprocessed source

Attached from the following command:

gcc -DHAVE_CONFIG_H -I.  -include ./config.h -I./protobuf-c -I. -I. -Wdate-time 
-D_FORTIFY_SOURCE=2   -g -O2 -fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -E -o /tmp/x1.i t/generated-code2/test-generated-code2.c

The diff to the working version boils down to:

(pbuild15677)root@tglase:/tmp/buildd/protobuf-c-1.2.1 # diff -u /tmp/x?.i
--- /tmp/x1.i   2016-12-01 21:21:12.804468216 +
+++ /tmp/x2.i   2016-12-01 21:21:46.620862123 +
@@ -6429,7 +6429,7 @@
   if (memcmp (a.data, b.data, a.len) == 0) {
 return 1;
   } else {
-printf("E: memcmp unequal\n");
+printf("E: memcmp len=%zd unequal\n", a.len);
 return 0;
   }
 }

So, nothing changed in the preprocessed output.

>  - does this work with GCC 7?

I fail to see how this is relevant for a bugreport against GCC 6,
but… as it’s in experimental, I can try (7-20161125-1, as today’s
upload is still not built).

Compile commands are:

gcc-7 -DHAVE_CONFIG_H -I.  -include ./config.h -I./protobuf-c -I. -I. 
-Wdate-time -D_FORTIFY_SOURCE=2   -g -O2 
-fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -c -o t/generated-code2/test-generated-code2.o 
t/generated-code2/test-generated-code2.c
gcc-7 -g -O2 -fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -specs=/usr/share/dpkg/pie-link.specs -Wl,-z -Wl,relro 
-o t/generated-code2/.libs/test-generated-code2 
t/generated-code2/test-generated-code2.o t/test-full.pb-c.o 
t/test-optimized.pb-c.o  protobuf-c/.libs/libprotobuf-c.so

Yes, this fails just the same.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

x1.i.gz
Description: application/gzip

Bug#846519: mailman: Broken link in admin webpage

[Uwe Kleine-König]

Package: mailman
Version: 1:2.1.18-2+deb8u1
Severity: normal

Hello,

I have a list with web_page_url = 'http://myvirtualhost/mailman/' while
mm_cfg.DEFAULT_URL_PATTERN = 'https://%s/'. As
HTMLFormatter.GetMailmanFooter calls Utils.ScriptURL('listinfo') without
passing web_page_url the 'Overview of all %(hostname)s mailing lists'
link points to http://myvirtualhost/listinfo instead of
http://myvirtualhost/mailman/listinfo.

I think the right fix is to pass my list's web_page_url to ScriptURL.

Best regards
Uwe

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (800, 'stable'), (700, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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 mailman depends on:
ii  apache2 [httpd]2.4.10-10+deb8u7
ii  cron   3.0pl1-127+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u6
ii  logrotate  3.8.7-1+b1
ii  lsb-base   4.1+Debian13+nmu1
ii  python-dnspython   1.12.0-1
pn  python:any 
ii  ucf3.0030

Versions of packages mailman recommends:
ii  postfix [mail-transport-agent]  2.11.3-1

Versions of packages mailman suggests:
pn  listadmin 
pn  lynx  
ii  spamassassin  3.4.0-6

-- debconf information:
* mailman/create_site_list:
* mailman/used_languages: de en
* mailman/site_languages: en, de
* mailman/default_server_language: en
  mailman/queue_files_present: abort installation

Bug#846520: pcl: enable parallel builds on 32 bit arches

[Emilio Pozuelo Monfort]

Source: pcl
Version: 1.8.0+dfsg1-3
Severity: wishlist

Hi,

In your changelog, I see:

pcl (1.7.2-6) unstable; urgency=medium

  [ Jochen Sprickerhof ]
  * Remove --parallel from dh to fix build on i386 buildd.

 -- Leopold Palomo-Avellaneda   Tue, 02 Dec 2014 08:29:43 
+0100

My guess is that happened because of the build failure on 2014-11-30 in:
https://buildd.debian.org/status/logs.php?pkg=pcl=i386

Note how the builds on i386 take ~5 hours, while on amd64 they take ~1h,
because of the parallel builds. For e.g. mipsel it's at 22h or 1d15h vs.
8h on mips64el.

Why was this disabled? Do the builds run out of memory often? It'd be good
to re-enable this, the speedup is huge and it would avoid taking one buildd
for a day and a half on some architectures.

Thanks,
Emilio

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

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)

Bug#843784: [Openjdk] Bug#843784: openjdk-7-jre: After last security update, icedtea-plugin fails all applets

[Tiago Daitx]

It turns out that  applets are failing because the security update in
S8155973 restricted MD5-based signatures in JAR files. It was
eventually backed out by S8166381 but that one didn't make to the
update.

One easy way to fix is to edit
/etc/java-7-openjdk/security/java.security and remove MD5 from the
list of "jdk.jar.disabledAlgorithms". By default this is a new setting
and should be the last line, just make sure it looks like:

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024



For future reference, once can see when an applet is being affect by
looking for the following log line:
Codebase matches codebase manifest attribute, but application is
unsigned. Continuing.
The browser must be run with icedtea plugin debug enabled as in
"ICEDTEAPLUGIN_DEBUG=true firefox".

Also, please be aware that Oracle is planning to reintroduce the MD5
signature restriction back in January, see section "Restrict JARs
signed with weak algorithms and keys" in
http://www.oracle.com/technetwork/java/javase/8all-relnotes-2226344.html

-thanks

Bug#802661: Git in jessie-backports

[Roman Pavlík]

Hi,

I also need newer Git (>= 2.3) in Debian Jessie. Are there any plans to 
maintain newer version in Jessie backports or do I have to wait for new 
stable release ?



--

Roman

Bug#827061: transition: openssl

[Adrian Bunk]

On Thu, Dec 01, 2016 at 09:15:44PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-12-01 00:52:59 [+0200], Adrian Bunk wrote:
> > Wouldn't "depends on libssl1.0.2 and does not build-depend on libssl1.0-dev"
> > give a reasonably small superset of all packages that need a binNMU?
> 
> Do you mean something like
>  is_affected = .depends ~ /libssl1\.0\.2/ & ! .build-depends ~ 
> /libssl1.0-dev/;
> 
> which results in [0] ? This gives you all packages with a B-D libssl-dev
> and D libssl1.0.2 like [1] but also lists package which do not depend on
> libssl-dev.
>...

Yes, that's what I had in mind.

Note that this is a superset of all packages requiring binNMUs,
and it is not expected to become all-green in stretch.

> Sebastian

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#846508: Segmentation fault

[Павел Банщиков]

I should to add my report another similar bug.
I do "desktop behavior"->"Screen locking"-> ... do something...->all 
settings->SEGMENTATION FAULT (the window closes)
I have 4 variants of wallpapers in "Screen locking": Hunyango, Plain Colour, 
Image, Slideshow. 
But I have SEGMENTATION FAULT (and closing window) only if I do something when 
my chosen wallpaper is Plain Colour, Image or Slideshow or I change wallpaper, 
but not when my chosen wallpaper is Hunyango.

When my chosen wallpaper isn't Hunyango, I have Segmentation fault often, but 
not always.

Console uotput:

chatrapati@Debian:~$ systemsettings5 
Segmentation fault
chatrapati@Debian  :~$ 

And in /var/log/syslog I have:
Dec  1 23:32:42 Debian kernel: [18997.209334] traps: systemsettings5[6181] 
general protection ip:7f7371a31d85 sp:7fff2ec05a60 error:0 in 
libQt5Qml.so.5.7.1[7f7371892000+3dd000]






-- 
Павел Банщиков

Bug#833284: reprotest: please add a "buildpath" variation to reprotest

[Ximin Luo]

Control: retitle -1 add the ability to disable buildpath variations

reprotest actually already builds in /tmp/autopkgtest.*/control vs 
experimental, but I'll add an option to disable this variation. When it is 
disabled, parallel builds would be impossible to make work (with most virtual 
servers), though.

X

On Tue, 02 Aug 2016 10:02:07 -0400 Daniel Kahn Gillmor  
wrote:
> Package: reprotest
> Version: 0.2
> Severity: normal
> 
> The list of variations supported by reprotest doesn't appear to
> include changing the build path.
> 
> We should be able to generate identical output regardless of where in
> the filesystem the build takes place, so supporting this variation
> would be a useful contribution to overall reproducibility.
> 
> thanks for writing reprotest!
> 
>   --dkg
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 
> 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.6.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 reprotest depends on:
> ii  apt-utils   1.3~pre2
> ii  diffoscope  56
> ii  libdpkg-perl1.18.9
> ii  procps  2:3.3.12-2
> ii  python3-debian  0.1.28
> pn  python3:any 
> 
> Versions of packages reprotest recommends:
> pn  autodep8 
> pn  disorderfs   
> pn  locales-all  
> ii  qemu-system  1:2.6+dfsg-3
> ii  qemu-utils   1:2.6+dfsg-3
> pn  schroot  
> 
> reprotest suggests no packages.
> 
> -- no debconf information
> 
> 

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

Bug#845393: Pending fixes for bugs in the tomcat8 package

[paul . szabo]

Dear Emmanuel,

Sorry for my previous outbursts. I was wrong.

Your fix (chmod-ing just Catalina, not localhost) is fine: if you do not
chmod localhost, then there is no issue even if localhost is replaced by
a symlink pointing somewhere.

However... will tomcat still "work"? On my machine, I have one XML file
  /etc/tomcat8/Catalina/localhost/mapleta.xml
in there, for the one application(?) that is installed. I guess it was
tomcat that put it there: then tomcat needs write access to localhost.

Maybe /etc/tomcat8/Catalina/localhost is to be "delivered" writable from
the DEB package, the ownership only to be fixed in postinst? In the
current DEB, that directory is not group-writable.

Could you kindly explain how this all works.

Thanks, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia