Bug#861182: ITP: python-ete3 -- Python toolkit for phylogenetic tree manipulation and visualisation.

[Andreas Tille]

Hi again Alba,

is there any news about python-ete3?  Did you decided about a team you want
to maintain the package in?

Kind regards

Andreas.

On Thu, Apr 27, 2017 at 01:55:06PM +0200, Andreas Tille wrote:
> Hi Alba,
> 
> On Thu, Apr 27, 2017 at 11:58:11AM +0100, Alba Crespi wrote:
> > I haven't decided yet whether I want it to be maintaining it personally, to
> > be part of DebianPython or DebianMed. So please, don't assume anything yet.
> 
> OK, I'm fine with both teams.  I'd volunteer to sponsor from any team as
> long as it is in some VCS @ debian.org.
> 
> Please note that currently Debian Python VCS is not yet monitored for
> the web sentinel.  Please let me know in case you decide for Debian
> Python and I'll consider adding this team to make sure we get up to date
> information about the package status.
> 
> Thanks for the clarification and sorry for my to fast assumtion
> 
>  Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#868372: Build failed for the sane-backends transition

[Jörg Frings-Fürst]

Package: libimage-sane-perl
Version: 0.09-1
Severity: important
Usertags: sane-backends-transiton



Hello,

for the sane-backends transition I test the build and I got an error:

> ok 135 - get_option
> ok 136 - get_option_descriptor
> ok 137 - get_option_descriptor
> ok 138 # skip Pressing buttons produces too much output
> ok 139 - set_option button
> 1..139
> ok
> t/pod.t  skipped: Test::Pod 1.00 required for testing POD
> 
> Test Summary Report
> ---
> t/81_scanimage-perl.t (Wstat: 768 Tests: 6 Failed: 3)
>   Failed tests:  4-6
>   Non-zero exit status: 3
> Files=10, Tests=324,  9 wallclock secs ( 0.10 usr  0.02 sys +  1.21 cusr  
> 0.37 csys =  1.70 CPU)
> Result: FAIL
> Failed 1/10 test programs. 3/324 subtests failed.
> Makefile:1004: recipe for target 'test_dynamic' failed
> make[1]: *** [test_dynamic] Error 255
> make[1]: Leaving directory '/build/libimage-sane-perl-0.09'
> dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2
> debian/rules:4: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> I: copying local configuration
> E: Failed autobuilding of package

The buildlog is attached.


CU
Jörg



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

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

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

Threema: SYR8SJXB
Wire: @joergfringsfuerst

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

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


libimage-sane-perl_0.09-1_amd64.build
Description: Binary data


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

Bug#865678: [Pkg-dns-devel] Bug#865678: knot: Improper TSIG validity period check can allow TSIG forgery

[Ondřej Surý]

Thanks for the upload. I didn't give it a very high priority as there was 
an easy fix using ACLs and I had a rough plan to fix it during next week.


Cheers, Ondřej


On 14 July 2017 22:12:11 Yves-Alexis Perez  wrote:


On Fri, 2017-06-23 at 19:01 +0200, Salvatore Bonaccorso wrote:

Source: knot
Version: 2.4.3-1
Severity: grave
Tags: security upstream patch
Control: found -1 2.5.1-1

Hi

See
https://lists.nic.cz/pipermail/knot-dns-users/2017-June/001144.html
and
http://www.synacktiv.ninja/ressources/Knot_DNS_TSIG_Signature_Forgery.pdf
and filling a bug in BTS to have a reference, afaik there is no CVE
yet assigned.

[16:19] < KGB-1> Yves-Alexis Perez 52846  /data/CVE/list add temporary entry
for knot
[16:21] < Corsac> ondrej: I guess you know about it?


I went ahead and uploaded fixes to jessie and stretch. I've also pushed my
branches to https://anonscm.debian.org/cgit/users/corsac/security/knot.git/ in
case you want to reimport them.

Regards,
--
Yves-Alexis


--
___
pkg-dns-devel mailing list
pkg-dns-de...@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel

Bug#868371: RFS: live-wrapper/0.6+nmu2

[Phil Wyett]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for an update to the package "live-
wrapper":

* Package name: live-wrapper
   Version: 0.6+nmu2
   Upstream Author : Debian Live - debian-l...@lists.debian.org
* URL: https://debian-live.alioth.debian.org/live-wrapper/
* License: BSD, GPLv3

This update addresses:

* Remove incorrect instance of converting to UTF-8.
* Eliminate 'pyversions' warnings at build time.
* Add 'python-requests' build dependency. Fixes docs build.
* Add 'squashfs-tools' dependency. (Closes: #867282).

Last entry relates to RC bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867282

Source can be obtained from:

https://kathenas.org/debian/package_uploads/

Signing key:

https://keyserver.ubuntu.com/pks/lookup?op=vindex=philwyett%40k
athenas.org=on

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

Twitter: kathenasorg

Instagram: kathenasorg
-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

Twitter: kathenasorg

Instagram: kathenasorg

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

Bug#867701: Radeon HD 6450, black screen, cursor, no console

[Michel Dänzer]

On 15/07/17 07:10 AM, Ivan Sergio Borgonovo wrote:
> On 07/10/2017 04:03 AM, Michel Dänzer wrote:
>> On 09/07/17 03:06 AM, Ivan Sergio Borgonovo wrote:
>>> Package: xserver-xorg-video-radeon
>>> Version: 1:7.9.0-1
>>> Severity: grave
> 
>> I doubt this severity is justified.
> 
> Why?
> X doesn't start so it "makes the package in question unusable", not to
> mention that it makes all packages requiring X unusable.

The bug severities are defined in the context of all users, not just
some individual users. "Makes the package in question unusable" means
the package cannot be used on any system, which isn't the case here (or
there would have been many more reports about it, but there hasn't been
any other report).


>> Is there more information in the Xorg stderr output? Maybe try setting
>> the environment variable EGL_LOG_LEVEL=debug as well for that.
> 
> See atachments.

[...]

> libEGL debug: EGL search path is /usr/lib/x86_64-linux-gnu/egl

Please provide the output of the following:

apt-cache policy libegl1-mesa

ldconfig -p|grep libEGL


>> Does the same problem happen with 1:7.8.0-1+b1 with
>>
>> Option "AccelMethod" "glamor"
>>
>> in /etc/X11/xorg.conf ?
> 
> Older xserver-xorg-video-radeon with that option DOESN'T WORK.
> Black screen, text cursor at the top right corner ( _ ).

Right, as expected the problem is specific to glamor, which is the
default for your GPU in 7.9.0 but wasn't yet in 7.8.0. This means in the
worst case you can work around the problem with

Option  "AccelMethod" "EXA"

in /etc/X11/xorg.conf.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#866641: guitarix: depends on libwebkitgtk-1.0-0 which is deprecated

[Hermann Meyer]

And a new release is out, 0.35.4, which dropping the dependency to 
libwebkitgtk  at all.


https://sourceforge.net/projects/guitarix/

Bug#868179: xserver-xorg-video-radeon: SEGV when starting X11

[Michel Dänzer]

On 15/07/17 03:57 AM, bartek 'basz' szurgot wrote:
> On 07/14/2017 04:04 AM, Michel Dänzer wrote:
>> Indeed, my bad. The corresponding radeon commit is
>> https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=4c91f36d3058180b5a2d6a23e9b82f5c933d8716
> 
> ok - thanks. :) knowing the exact conditions under which SEGV occurs
> (i.e. rotated screen in xorg.conf), i agree it is not a "grave" bug.

It's even more specific than that: The crash only happens if xorg.conf
contains rotation and a Virtual stanza (which BTW is probably useless in
this case anyway).


> when the fix is expected to arrive to the xserver-xorg-video-radeon
> package in Debian-testing?

I have to defer to the Debian packagers on that. Upstream it'll likely
only be in the 7.10.0 release.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature

Bug#868369: haskell-hs-bibutils: FTBFS against bibutils 6.0 (experimental)

[Clint Adams]

On Fri, Jul 14, 2017 at 10:28:59PM -0300, David Bremner wrote:
> I ran
> 
> % sbuild -d experimental --build-dep-resolver=aptitude 
> --add-depends="libbibutils-dev (>=6.0)" haskell-hs-bibutils_5.5-5.dsc
> 
> The build doesn't get very far
> 
> ,
> | Running debian/hlibrary.setup build --builddir=dist-ghc
> | Building hs-bibutils-5.5...
> | Preprocessing library hs-bibutils-5.5...
> | Bibutils.hsc:406:32: fatal error: bibutils/bibtexout.h: No such file or 
> directory
> | compilation terminated.
> | compiling dist-ghc/build/Text/Bibutils_hsc_make.c failed (exit code 1)
> | command was: /usr/bin/gcc -c dist-ghc/build/Text/Bibutils_hsc_make.c -o 
> dist-ghc/build/Text/Bibutils_hsc_make.o -fno-stack-protector 
> -fno-stack-protector -D__GLASGOW_HASKELL__=800 -Dlinux_BUILD_OS=1 
> -Dx86_64_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Dx86_64_HOST_ARCH=1 
> -Idist-ghc/build/autogen -include dist-ghc/build/autogen/cabal_macros.h 
> -I/usr/lib/ghc/base-4.9.1.0/include 
> -I/usr/lib/ghc/integer-gmp-1.0.0.1/include -I/usr/lib/ghc/include 
> -I/usr/lib/ghc/include/
> `
> 
> It turns out bibtexout.h is not longer included in the package since version 
> 5.11
> 
> At some point before buster releases, but ideally in the next couple
> months, I'd like to transition from the old 4.12 version of bibutils
> to 6.0. AFAIK, hs-bibutils and it's rdeps are the only consumers of
> the bibutils library in the archive.

Is this something the pandoc-citeproc authors are aware of?

Bug#868369: haskell-hs-bibutils: FTBFS against bibutils 6.0 (experimental)

[David Bremner]

Source: haskell-hs-bibutils
Version: 5.5-5
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I ran

% sbuild -d experimental --build-dep-resolver=aptitude 
--add-depends="libbibutils-dev (>=6.0)" haskell-hs-bibutils_5.5-5.dsc

The build doesn't get very far

,
| Running debian/hlibrary.setup build --builddir=dist-ghc
| Building hs-bibutils-5.5...
| Preprocessing library hs-bibutils-5.5...
| Bibutils.hsc:406:32: fatal error: bibutils/bibtexout.h: No such file or 
directory
| compilation terminated.
| compiling dist-ghc/build/Text/Bibutils_hsc_make.c failed (exit code 1)
| command was: /usr/bin/gcc -c dist-ghc/build/Text/Bibutils_hsc_make.c -o 
dist-ghc/build/Text/Bibutils_hsc_make.o -fno-stack-protector 
-fno-stack-protector -D__GLASGOW_HASKELL__=800 -Dlinux_BUILD_OS=1 
-Dx86_64_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Dx86_64_HOST_ARCH=1 
-Idist-ghc/build/autogen -include dist-ghc/build/autogen/cabal_macros.h 
-I/usr/lib/ghc/base-4.9.1.0/include -I/usr/lib/ghc/integer-gmp-1.0.0.1/include 
-I/usr/lib/ghc/include -I/usr/lib/ghc/include/
`

It turns out bibtexout.h is not longer included in the package since version 
5.11

At some point before buster releases, but ideally in the next couple
months, I'd like to transition from the old 4.12 version of bibutils
to 6.0. AFAIK, hs-bibutils and it's rdeps are the only consumers of
the bibutils library in the archive.

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

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

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAllpb74ACgkQ8gKXHaSn
nixCXQv/XUAXiRPJvv6Mxn3fo4QE99g+TXtAAJab0W++c5+GeAFeXodIHEkk2h2T
D1xU83bcz4aPJaVR7mSwd4P1AXPUxh913WdwHeJS35Q1LoY2ciFiwzC7bftNDiTA
1WSnIlCkhcPch0pXjTOs0RYxwAnVy7Lnj2MzvO6xcQ4Lr+WLbOV3Qd1jAvN4qNOz
YMZOfQvnkTCrgZ1WffYpe/99Oy6Shl2ZmiOe4jHF6hX2J9XckEwzKoBPplAGzslm
E34coEvuEt3s6NPhQgqnp4+Ez+0N2guqxUXPXpOeH1KQ1k3ZWKbOqbOzsMywKQsv
oggMwSqqBHoBVm7hD4WMl8OgIHyYt+dfH6Z48Y7PKe7wb5TDqX05nX25G0iJUVoR
vXKs970vlxpAQLxAI13+m6em2O6vFJz/9wz1RI4MMlS6epNVsiZqS6m9pxXiAJdT
vitr7UAt/4a+8dIgw4X+s2Bt/xsHwMahZJwcrwnlViLC17wjP8KFxnozETYo+5Tv
lvBb/YQS
=bEJn
-END PGP SIGNATURE-

Bug#868370: python3-btrfs: Exception: Unsupported machine type aarch64

[Adam Borowski]

Package: python3-btrfs
Version: 7-1
Severity: normal

Hi!
On arm64, both the Debian and kernel architecture name is "arm64", yet
Python's platform.machine() returns autotoolsey "aarch64".  The latter
name is not on btrfs/ioctl.py's list.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 4.11.0-rc6-iceconfig-00048-gb18024f35bbb (SMP w/4 CPU cores; 
PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python3-btrfs depends on:
ii  python3  3.5.3-3

python3-btrfs recommends no packages.

python3-btrfs suggests no packages.

-- no debconf information

Bug#678607: debian-policy: "original authors" in 12.5 is unclear

[Russ Allbery]

Sean Whitton  writes:

> I'm not sure why Jonathan thinks his patch is a strawman.  It addresses
> the main issue of this bug.  I don't think the explanation of what an
> upstream contact is needs to be relegated to a footnote.  So I am
> seeking seconds for the following patch, which uses Jonathan's wording:

> diff --git a/policy.xml b/policy.xml
> index ce5960b..725a951 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -11777,8 +11777,12 @@ END-INFO-DIR-ENTRY
>
>
>  In addition, the copyright file must say where the upstream
> -sources (if any) were obtained, and should name the original
> -authors.
> +sources (if any) were obtained, and should include a name or
> +contact address for the upstream authors.  This can be the
> +name of an individual or an organization, an email address, a
> +web forum or bugtracker, or any other means to unambiguously
> +identify who to contact to participate in the development of
> +the upstream source code.
>
>
>  Packages in the contrib or

Seconded.  This looks good to me.

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

Bug#868368: opendnssec: fails to start on unstable

[Julien Lesaint]

Package: opendnssec
Version: 1:2.0.4-3
Severity: important

Hello,

opendnssec fails to start on my Debian unstable. I'm not using systemd
and I have an initialized HSM store (to rule out that I would be hitting
#859419).

Thank you in advance.
Julien

Install log:

The following NEW packages will be installed:
  libhsm-bin opendnssec opendnssec-common opendnssec-enforcer
opendnssec-enforcer-sqlite3 opendnssec-signer
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/602 kB of archives.
After this operation, 1,922 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Preconfiguring packages ...
(Reading database ... 57802 files and directories currently installed.)
Preparing to unpack .../0-opendnssec-common_1%3a2.0.4-3_all.deb ...
Unpacking opendnssec-common (1:2.0.4-3) ...
Preparing to unpack .../1-libhsm-bin_1%3a2.0.4-3_amd64.deb ...
Unpacking libhsm-bin (1:2.0.4-3) ...
Preparing to unpack
.../2-opendnssec-enforcer-sqlite3_1%3a2.0.4-3_amd64.deb ...
Unpacking opendnssec-enforcer-sqlite3 (1:2.0.4-3) ...
Preparing to unpack .../3-opendnssec-enforcer_1%3a2.0.4-3_all.deb ...
Unpacking opendnssec-enforcer (1:2.0.4-3) ...
Preparing to unpack .../4-opendnssec-signer_1%3a2.0.4-3_amd64.deb ...
Unpacking opendnssec-signer (1:2.0.4-3) ...
Preparing to unpack .../5-opendnssec_1%3a2.0.4-3_all.deb ...
Unpacking opendnssec (1:2.0.4-3) ...
Setting up opendnssec-common (1:2.0.4-3) ...

Creating config file /etc/opendnssec/addns.xml with new version

Creating config file /etc/opendnssec/conf.xml with new version

Creating config file /etc/opendnssec/kasp.xml with new version

Creating config file /etc/opendnssec/zonelist.xml with new version
Setting up libhsm-bin (1:2.0.4-3) ...
Processing triggers for systemd (234-1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up opendnssec-enforcer-sqlite3 (1:2.0.4-3) ...
Setting up opendnssec-signer (1:2.0.4-3) ...
Created symlink
/etc/systemd/system/multi-user.target.wants/opendnssec-signer.service →
/lib/systemd/system/opendnssec-signer.service.
chown: invalid group: ‘opendnssec:opendnssec - -’
[] Starting OpenDNSSEC Signer: opendnsec-signerstart-stop-daemon:
warning: this system is not able to track process names
longer than 15 characters, please use --exec instead of --name.
start-stop-daemon: warning: this system is not able to track process
names
longer than 15 characters, please use --exec instead of --name.
OpenDNSSEC signer engine version 2.0.4
. ok 
Setting up opendnssec-enforcer (1:2.0.4-3) ...
Created symlink
/etc/systemd/system/multi-user.target.wants/opendnssec-enforcer.service
→ /lib/systemd/system/opendnssec-enforcer.service.
chown: invalid group: ‘opendnssec:opendnssec - -’
[] Starting OpenDNSSEC Enforcer:
opendnssec-enforcerstart-stop-daemon: warning: this system is not able
to track process names
longer than 15 characters, please use --exec instead of --name.
start-stop-daemon: warning: this system is not able to track process
names
longer than 15 characters, please use --exec instead of --name.
OpenDNSSEC key and signing policy enforcer version 2.0.4
enforcerd stopped with exitcode 3
 failed!
Setting up opendnssec (1:2.0.4-3) ...
Processing triggers for systemd (234-1) ...
Do you want to erase any previously downloaded .deb files? [Y/n] n





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

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages opendnssec depends on:
ii  libhsm-bin   1:2.0.4-3
ii  opendnssec-enforcer  1:2.0.4-3
ii  opendnssec-signer1:2.0.4-3

Versions of packages opendnssec recommends:
ii  softhsm2  2.2.0-3

Versions of packages opendnssec suggests:
pn  opendnssec-doc  

-- debconf-show failed

Bug#851937: RFS: farbfeld/2.20170109-1 ITP

[Sean Whitton]

control: tag -1 +moreinfo

On Wed, Jul 12, 2017 at 02:58:48PM +0200, Paride Legovini wrote:
> Following up from the brief discussion we had on #debian-devel, here is
> a tentative package:
> 
> https://anonscm.debian.org/cgit/users/paride-guest/farbfeld.git/

Thanks again for your help with this RFS.  Here is a review of 534d41f:

- I think we should list Dmitry in the Uploaders: field, which would
  indicate that he may upload new versions of the package without it
  counting as an NMU

- your git history does not really give credit to Dmitry for his work.
  I'd like to suggest starting again, and doing it like this:

  + clone Dmitry's repo
  + `git merge 3` to get the new upstream version
  + revert the convert commit (but see below)
  + apply your other changes

- I also think it would be good to state in debian/changelog that most
  of the Debianisation is due to Dmitry

- your changes to the patch header do not make sense: the '3..' will not
  yield "the changes made by the Debian maintainer in the first upload
  of upstream version 3".  Please take another look at the template.

- I disagree with you about Dmitry's `convert` patch.  It just doesn't
  seem likely to me that there would be difficult merge conflicts with
  new upstream versions, and it is indeed useful to inform the user that
  convert is not available.  But I will defer to your judgement -- if
  you're sure about dropping the patch, maybe imagemagick should be
  moved to a hard dependency?

If you're able to address the issues I've raised in this message, please
remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
to refresh the changelog timestamp.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#868367: postgresql-common: standby cannot start with "recovery.conf file found in config directory"

[Sergey Burladyan]

Package: postgresql-common
Version: 183.pgdg80+1
Severity: important

Dear Maintainer,

I update postgresql-common and restart standby. Now my standby cannot
start with message: "recovery.conf file found in config directory".

Yes, I have recovery.conf in /etc, this is intentional. I symlink it
from data dir.

-- System Information:  
Debian Release: 8.8
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/56 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 postgresql-common depends on:
ii  adduser   3.113+nmu3
ii  debconf [debconf-2.0] 1.5.56
ii  init-system-helpers   1.22
ii  lsb-base  4.1+Debian13+nmu1
ii  postgresql-client-common  183.pgdg80+1
ii  procps2:3.3.9-9
ii  ssl-cert  1.0.35
ii  ucf   3.0030

Versions of packages postgresql-common recommends:
ii  logrotate  3.8.7-1+b1

Versions of packages postgresql-common suggests:
ii  libjson-perl  2.61-1

-- debconf information excluded

-- 
Sergey Burladyan

Bug#678607: debian-policy: "original authors" in 12.5 is unclear

[Sean Whitton]

I would like to see this bug fixed because there can be no doubt that
the 'original' in "original authors" is ambiguous.

On Wed, Jun 27, 2012 at 07:50:41PM -0500, Jonathan Nieder wrote:
> Here's a strawman illustrating what I think the sentence meant to say.
> [...]

I'm not sure why Jonathan thinks his patch is a strawman.  It addresses
the main issue of this bug.  I don't think the explanation of what an
upstream contact is needs to be relegated to a footnote.  So I am
seeking seconds for the following patch, which uses Jonathan's wording:

diff --git a/policy.xml b/policy.xml
index ce5960b..725a951 100644
--- a/policy.xml
+++ b/policy.xml
@@ -11777,8 +11777,12 @@ END-INFO-DIR-ENTRY
   
   
 In addition, the copyright file must say where the upstream
-sources (if any) were obtained, and should name the original
-authors.
+sources (if any) were obtained, and should include a name or
+contact address for the upstream authors.  This can be the
+name of an individual or an organization, an email address, a
+web forum or bugtracker, or any other means to unambiguously
+identify who to contact to participate in the development of
+the upstream source code.
   
   
 Packages in the contrib or

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#866055: linux-image-4.9.0-3-amd64: Broadwell laptop hangs during light usage since upgrading to stretch

[Lennert Van Alboom]

Bug confirmed to still be around in 4.9.30-2+deb9u2. Took longer to hit than I 
expected (and I already hoped it was gone), but same symptoms.


signature.asc
Description: Digital signature

Bug#853868: (no subject)

[Sergey Burladyan]

>  Myon: I wonder if pg_ctlcluster should error out if it finds a 
> recovery.conf in /etc
>  possibly, yes
>  I see this mistake all the time, and it's a 100% natural mistake 
> to make

Thank you, guys. Now all of my standbys cannot start with "recovery.conf
file found in config directory".

Is it joke? This is not funny.

I deploy recovery.conf by puppet into /etc and symlink it from data dir.
Why do you think what this is wrong? Why I cannot do this?

This approach work perfectly for five years and now you broke it.

I think you must fix it back.

-- 
Sergey Burladyan

Bug#798476: debian-policy: don't require Uploaders

[Sean Whitton]

On Fri, Jul 08, 2016 at 05:36:22PM +0200, Christian Hofstaedtler wrote:
> I also want to see this. It makes lots of sense, especially for
> teams maintaining very large numbers of packages. Honestly, the
> individual package does not carry heavy weight in some of those
> teams. At the same time, many packages carry old Uploaders,
> including names of people that have long been known to be MIA, and
> are kept there only to avoid setting an empty Uploaders field.

Let me add the experience of the Debian Haskell Group.  We have a
wrapper around debchange(1) which allows us to do team uploads without
having "Team upload." be the first line of the changelog.  We select new
upstream versions based on snapshots compiled by an outside group.[1]
We upgrade tens of packages to new upstream releases at a time, and
upload them all together (for some time, Clint Adams has done these mass
uploads).  For us, having some random names in the Uploaders: field can
do nothing other than confuse newcomers to the team.

I suspect that we cannot get consensus on this bug.  Many people share
Iain's sentiment, but the issue continues to arise in many contributor's
Debian work.  So it might be advisable to refer to tech-ctte.

Before doing that, at the risk of achieving nothing, I'd like to suggest
another wording:

... if the Maintainer control field names a group of people and a
shared email address, the Uploaders field must be present and must
contain at least one human with their personal email address.  An
exception is made for packaging teams which state clearly on their
homepage, documentation or team policy that all packages are taken
care of by every team member collectively.

Possibly too bureaucratic, but might allay some of the concerns that
Tobi raised: barely-established teams aren't likely to have a team
homepage/documentation/policy document.

[1]  https://www.stackage.org/

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#868362: transition: libofx7

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 14/07/17 23:18, Dylan Aïssi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> Please schedule a transition for libofx.
> The 5 reverse build-deps (gnucash, grisbi, homebank, kmymoney,
> skrooge) currently build fine with the new version.

Go ahead.

Emilio

Bug#867046: gwhois: diff for NMU version 20120626-1.1

[gregor herrmann]

Control: tags 867046 + patch
Control: tags 867046 + pending

Dear maintainer,

I've prepared an NMU for gwhois (versioned as 20120626-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Die Quote: So far
diff -Nru gwhois-20120626/debian/changelog gwhois-20120626/debian/changelog
--- gwhois-20120626/debian/changelog	2015-04-17 23:32:57.0 +0200
+++ gwhois-20120626/debian/changelog	2017-07-15 01:12:47.0 +0200
@@ -1,3 +1,13 @@
+gwhois (20120626-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "fails with perl 5.26: The encoding pragma is no longer
+supported at /usr/bin/gwhois line 80.":
+drop 'use encoding' statement.
+(Closes: #867046)
+
+ -- gregor herrmann   Sat, 15 Jul 2017 01:12:47 +0200
+
 gwhois (20120626-1) unstable; urgency=medium
 
   * Documentation fixes.
diff -Nru gwhois-20120626/gwhois gwhois-20120626/gwhois
--- gwhois-20120626/gwhois	2015-04-17 23:30:06.0 +0200
+++ gwhois-20120626/gwhois	2017-07-15 01:07:54.0 +0200
@@ -77,7 +77,6 @@
 #
 
 use LWP::Simple;
-use encoding ':locale';
 use Net::LibIDN;
 
 $ENV{'HOME'}='/var/home/whois' unless defined $ENV{'HOME'};


signature.asc
Description: Digital Signature

Bug#740782: Bug#866317: html2ps: relies on deprecated Perl syntax/features, breaks with 5.26

[gregor herrmann]

Control: tag 740782 + patch
Control: tag 866317 + patch

On Wed, 28 Jun 2017 23:10:58 +0300, Niko Tyni wrote:

> In addition to the $[ deprecation (#740782), this package also relies
> on other deprecated Perl features. These will become fatal in
> Perl 5.26, currently in experimental.
> 
>  % html2ps /dev/null >/dev/null
>  Use of assignment to $[ is deprecated at /usr/bin/html2ps line 3409.
>  Unescaped left brace in regex is deprecated, passed through in regex; marked 
> by <-- HERE in m//DH { <-- HERE / at /usr/bin/html2ps line 3834.
>  Unescaped left brace in regex is deprecated, passed through in regex; marked 
> by <-- HERE in m/\\patterns{ <-- HERE .*/ at /usr/bin/html2ps line 4085.
>  Calling POSIX::tmpnam() is deprecated at /usr/bin/html2ps line 497.

I'm attaching a patch for these issues. With it, I don't get any more
warnings or errors which are perl related.

(The usage of File::Temp's POSIX features is not really elegant but
it's minimal-invasive and I don't really grok what the code does with
the tempfile/dir ...)

Reviews welcome.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: The Doors: Lover Her Madly
diff -Nru html2ps-1.0b7/debian/changelog html2ps-1.0b7/debian/changelog
--- html2ps-1.0b7/debian/changelog	2011-08-14 20:42:57.0 +0200
+++ html2ps-1.0b7/debian/changelog	2017-07-15 00:29:53.0 +0200
@@ -1,3 +1,13 @@
+html2ps (1.0b7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "relies on deprecated Perl syntax/features, breaks with 5.26" and
+"Use of assignment to $[ is deprecated":
+add patch perl-deprecations.patch
+(Closes: #866317, #740782)
+
+ -- gregor herrmann   Sat, 15 Jul 2017 00:29:53 +0200
+
 html2ps (1.0b7-1) unstable; urgency=low
 
   * New maintainer. (Closes: #407652)
diff -Nru html2ps-1.0b7/debian/patches/perl-deprecations.patch html2ps-1.0b7/debian/patches/perl-deprecations.patch
--- html2ps-1.0b7/debian/patches/perl-deprecations.patch	1970-01-01 01:00:00.0 +0100
+++ html2ps-1.0b7/debian/patches/perl-deprecations.patch	2017-07-15 00:29:53.0 +0200
@@ -0,0 +1,55 @@
+Description: fix various deprecations which became fatal in perl 5.26
+ - escape { in regexps
+ - replace POSIX::tmpnam() with File::Temp's backward compatibility equivalent
+ - additionally drop assignment to $[
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/866317
+ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740782
+Author: gregor herrmann 
+Last-Update: 2017-07-15
+
+--- a/html2ps
 b/html2ps
+@@ -355,6 +355,7 @@
+ 
+ use POSIX;
+ $posix = 1;
++use File::Temp qw/ :POSIX /;
+ 
+ %extend=('quote',1, 'font',1, 'colour',1, 'hyphenation',1);
+ %fal=("serif","times", "sans_serif","helvetica", "monospace","courier");
+@@ -494,7 +495,7 @@
+  if($opt_D && !$package{'Ghostscript'});
+ die "Ghostscript is required to generate cross references\n"
+  if($opt_R && !$package{'Ghostscript'});
+-$tmpname=$posix?POSIX::tmpnam():"h2p_$$";
++$tmpname=$posix?tmpnam():"h2p_$$";
+ sysopen TMP, $tmpname, O_RDWR|O_CREAT|O_EXCL, 0600 or die "$!";
+ close TMP;
+ ($scr=$tmpname)=~/\w+$/;
+@@ -3406,7 +3407,6 @@
+   local($optlist)=@_;
+   local(@args,$_,$opt,$opts,$rest,$olist,$plist,$found,@popts);
+   local($errs)=0;
+-  local($[)=0;
+   @args=split( /\|/, $optlist );
+   for $opt (@args) {
+ if(substr($opt,-1,1) ne ':') {$olist.=$opt}
+@@ -3831,7 +3831,7 @@
+   $temp=$'=~/\/P\d+_?\d* \{/?$`:$rest;
+   ($eps{$pid})=$temp=~/([\w\W]*)} D/;
+ }
+-if(/\/DH {/) {
++if(/\/DH \{/) {
+   $'=~/%EndDH/;
+   $ph="/DH {$`";
+ }
+@@ -4082,7 +4082,7 @@
+   }
+   if(open(HYPH,"<$hyfile")) {
+ ("Reading hyphenation patterns from $hyfile\n") if($opt_d);
+-=~/\\patterns{.*/;
++=~/\\patterns\{.*/;
+ close HYPH;
+ $def=$`;
+ ($patterns=$')=~s/\^\^($X$X)/chr hex $1/eg;
diff -Nru html2ps-1.0b7/debian/patches/series html2ps-1.0b7/debian/patches/series
--- html2ps-1.0b7/debian/patches/series	2011-08-06 21:09:19.0 +0200
+++ html2ps-1.0b7/debian/patches/series	2017-07-15 00:29:53.0 +0200
@@ -12,3 +12,4 @@
 fix_ps.patch
 checker_warning.patch
 upstream_changelog.patch
+perl-deprecations.patch


signature.asc
Description: Digital Signature

Bug#841733: Transition Opencv 3.1

[Mattia Rizzolo]

On Fri, Jul 14, 2017 at 11:16:23AM +0200, Mattia Rizzolo wrote:
> But in the meantime OpenCV 3.2 went out, so we'd like to go for that.
> It has been accepted into experimental a few days ago, and afaik nobody
> test rebuilt things with it.

Indeed my test rebuilds highlighted new failures…

In particular of libkf5kface (already patched with what worked for 3.1),
openimageio, ros-opencv-apps.  I haven't investigated them yet, but if
anybody wants to try and fail/fix things where needed it would be nice.

-- 
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#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution

[brian m. carlson]

On Fri, Jul 14, 2017 at 06:42:34PM -0300, Till Kamppeter wrote:
> It seems that the printer answers the wrong resolution (firmware bug). Under
> the printer's attributes I have found:
> 
> > DEBUG2: Attr: pwg-raster-document-resolution-supported
> > DEBUG2: Value: 600x2dpi

I have just updated the firmware to the latest version, thinking that
might be the problem.  The results are exactly the same as with the old
firmware.

> Please run the following command:
> 
> ipptool -tv ipp://copper.local:631/ipp/print get-printer-attributes.test >
> ipp-attrs.txt
> 
> and attach the file ipp-attrs.txt to your answer to this bug report. Thanks.

Attached.

> To be able to print for the time being, please edit your PPD file as
> follows:
> 
> Replace
> 
> --
> *DefaultResolution: 600x2dpi
> *OpenUI *cupsPrintQuality/Print Quality: PickOne
> *OrderDependency: 10 AnySetup *cupsPrintQuality
> *DefaultcupsPrintQuality: Normal
> *cupsPrintQuality Normal/Normal: "<>setpagedevice"
> *cupsPrintQuality High/High: "<>setpagedevice"
> *CloseUI: *cupsPrintQuality
> --
> 
> by
> 
> --
> *DefaultResolution: 600x600dpi
> *OpenUI *cupsPrintQuality/Print Quality: PickOne
> *OrderDependency: 10 AnySetup *cupsPrintQuality
> *DefaultcupsPrintQuality: Normal
> *cupsPrintQuality Normal/Normal: "<>setpagedevice"
> *cupsPrintQuality High/High: "<>setpagedevice"
> *CloseUI: *cupsPrintQuality
> --
> 
> Do not forget to restart CUPS after editing or replacing your PPD file.
> 
> Please tell whether this change fixes your problem.

This does fix the problem.  Since this printer supports PCL, I can also
use the hpijs-pcl5c driver in the mean time.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
"/usr/share/cups/ipptool/get-printer-attributes.test":
Get-Printer-Attributes:
attributes-charset (charset) = utf-8
attributes-natural-language (naturalLanguage) = en
printer-uri (uri) = ipp://copper.local:631/ipp/print
Get printer attributes using Get-Printer-Attributes  [PASS]
RECEIVED: 4472 bytes in response
status-code = successful-ok (successful-ok)
attributes-charset (charset) = utf-8
attributes-natural-language (naturalLanguage) = en
copies-default (integer) = 1
finishings-default (enum) = none
media-default (keyword) = na_letter_8.5x11in
media-col-default (collection) = {media-type=stationery 
media-size={x-dimension=21590 y-dimension=27940} media-bottom-margin=432 
media-left-margin=432 media-right-margin=432 media-top-margin=432 
media-source=auto}
orientation-requested-default (enum) = portrait
output-bin-default (keyword) = face-down
output-mode-default (keyword) = color
print-quality-default (enum) = normal
printer-resolution-default (resolution) = 600dpi
sides-default (keyword) = one-sided
print-color-mode-default (keyword) = color
copies-supported (rangeOfInteger) = 1-1
finishings-supported (enum) = none
media-supported (1setOf keyword) = 
iso_a4_210x297mm,na_letter_8.5x11in,na_legal_8.5x14in,na_executive_7.25x10.5in,iso_a5_148x210mm,iso_a6_105x148mm,iso_b5_176x250mm,jis_b5_182x257mm,na_number-10_4.125x9.5in,iso_dl_110x220mm,iso_c5_162x229mm,na_monarch_3.875x7.5in,na_index-3x5_3x5in,om_folio_210x330mm,custom_min_76.2x127mm,custom_max_215.9x355.6mm
media-col-supported (1setOf keyword) = 
media-type,media-size,media-top-margin,media-left-margin,media-right-margin,media-bottom-margin,media-source
orientation-requested-supported (1setOf enum) = portrait,landscape
output-bin-supported (keyword) = face-down
output-mode-supported (1setOf keyword) = color,auto,monochrome
print-quality-supported (1setOf enum) = normal,high
printer-resolution-supported (1setOf resolution) = 600dpi,2400x600dpi
sides-supported (1setOf keyword) = 
one-sided,two-sided-long-edge,two-sided-short-edge
print-color-mode-supported (1setOf keyword) = auto,color,monochrome
generated-natural-language-supported (1setOf naturalLanguage) = en,fr
printer-uri-supported (uri) = ipp://copper.local./ipp/print
uri-security-supported (keyword) = none
uri-authentication-supported (keyword) = none
printer-name (nameWithoutLanguage) = copper
printer-location (textWithoutLanguage) = 
printer-info (textWithoutLanguage) = Brother MFC-9340CDW
printer-make-and-model (textWithoutLanguage) = Brother MFC-9340CDW
printer-state (enum) = idle
printer-state-reasons (keyword) = none
ipp-versions-supported (1setOf keyword) = 1.0,1.1,2.0
operations-supported (1setOf enum) = 
Print-Job,Validate-Job,Cancel-Job,Get-Job-Attributes,Get-Jobs,Get-Printer-Attributes
multiple-document-jobs-supported (boolean) = false

Bug#473227: less: Prints UTF-8 Byte order mark

[Paul Hardy]

Control: tags 473227 + fixed-upstream

The "less" upstream maintainer, Mark Nudelman, has just emailed me
saying that he believes he has fixed this bug in less version 504,
just released.  See

http://greenwoodsoftware.com/less/less-504.tar.gz

Russ: if this upstream release is uploaded to Debian, would you be
amenable to starting Debian UTF-8 documents with the UTF-8 signature?
Then they would appear correctly in web browsers no matter what
Content or Meta tags say.

This same issue applies to other Debian documents of course (such as
the txt versions of maint-guide).

Thanks,


Paul Hardy

Bug#868366: python2.7: Exports `md5_init', causing conflicts with extension modules

[Mark Wooding]

Package: python2.7
Version: 2.7.13-2
Severity: normal

[stratocaster ~]nm --dynamic /usr/bin/python2.7 | grep md5
00091732 T init_md5
001d6890 T md5_append
001d67d0 T md5_finish
000919f3 T md5_init
[stratocaster ~]

This causes trouble when trying to use bindings to a crypto library
which also wants to define `md5_init', because they disagree about how
the hashing state ought to be arranged: the outcome is a wrong answer on
amd64, and a segfault on i386.  While it can certainly be argued that
neither Python nor the other library has especially good taste in
naming, `md5_init' is at least a proper, documented part of the
library's public interface, directly relevant to its purpose (and has
been since 1999), though the same can't be argued for Python:

[stratocaster ~]grep -ri md5 /usr/include/python2.7/
[stratocaster ~]

Indeed, it seems that the Python package has leaked its MD5 symbols
before: see bug #440272.

I'm deploying an awful hack involving `RTLD_DEEPBIND' in the meantime,
but it would be nice to get this fixed properly.

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-3-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python2.7 depends on:
ii  libpython2.7-stdlib  2.7.13-2
ii  mime-support 3.60
ii  python2.7-minimal2.7.13-2

python2.7 recommends no packages.

Versions of packages python2.7 suggests:
ii  binutils   2.28-5
ii  python2.7-doc  2.7.13-2

-- no debconf information

Bug#866934: Pending fixes for bugs in the libhttp-oai-perl package

[pkg-perl-maintainers]

tag 866934 + pending
thanks

Some bugs in the libhttp-oai-perl package are closed in revision
325e9b10ddff75d3f578bb6e2816a524a38e696e in branch 'master' by gregor
herrmann

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

Commit message:

Add patch to remove "use encoding" which is gone in perl 5.26.

Closes: #866934

Bug#867192: [Pkg-dns-devel] Bug#867192: let systemd know about the pid file

[Robert Edmonds]

Simon Deziel wrote:
> When unbound is stopped, its PID file is left behind causing subsequent
> service starts to complain like that:
> 
>  unbound[178]: [178:0] warning: did not exit gracefully last time (124)
> 
> Please find a patch that tells systemd where the PID is so that it can
> delete it once unbound is stopped.

Hi, Simon:

Are you sure about this? When I "systemctl stop unbound", "systemctl
start unbound", I get the following output in the journal:

Jul 14 18:12:52 chase systemd[1]: Stopping Unbound DNS server...
Jul 14 18:12:52 chase unbound[26190]: [26190:0] info: service stopped (unbound 
1.6.4).
Jul 14 18:12:52 chase unbound[26190]: [26190:0] info: server stats for thread 
0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip 
ratelimiting
Jul 14 18:12:52 chase unbound[26190]: [26190:0] info: server stats for thread 
0: requestlist max 0 avg 0 exceeded 0 jostled 0
Jul 14 18:12:52 chase systemd[1]: Stopped Unbound DNS server.
Jul 14 18:13:00 chase systemd[1]: Starting Unbound DNS server...
Jul 14 18:13:00 chase package-helper[26343]: /var/lib/unbound/root.key has 
content
Jul 14 18:13:00 chase package-helper[26343]: success: the anchor is ok
Jul 14 18:13:00 chase unbound[26347]: [26347:0] notice: init module 0: validator
Jul 14 18:13:00 chase unbound[26347]: [26347:0] notice: init module 1: iterator
Jul 14 18:13:00 chase unbound[26347]: [26347:0] info: start of service (unbound 
1.6.4).
Jul 14 18:13:00 chase systemd[1]: Started Unbound DNS server.

It also looks like unbound truncates the pidfile when it shuts down?

-- 
Robert Edmonds
edmo...@debian.org

Bug#867701: Radeon HD 6450, black screen, cursor, no console

[Ivan Sergio Borgonovo]

On 07/10/2017 04:03 AM, Michel Dänzer wrote:

Sorry for the delay.


On 09/07/17 03:06 AM, Ivan Sergio Borgonovo wrote:

Package: xserver-xorg-video-radeon
Version: 1:7.9.0-1
Severity: grave



I doubt this severity is justified.


Why?
X doesn't start so it "makes the package in question unusable", not to 
mention that it makes all packages requiring X unusable.


I don't want to ‎polemicize but before assigning the severity I read the 
guidelines and grave seemed to fit.
I think "grave" is the less serious severity level that will block 
upgrade if you have apt-listbugs installed.

You're welcome to correct me so I'll do a better work in next bug reports.


Upgrading from 1:7.8.0-1+b1 to 1:7.9.0-1, PC boot but I get a black
screen with cursor on the top left, I can't switch to console, xorg log
just say



[28.383] (II) glamor: OpenGL accelerated X.org driver based.
[28.441] (EE)
[28.441] (EE) Backtrace:



Please attach the full Xorg log file and output of dmesg corresponding
to the problem.


dmesg doesn't report any error, only difference between the working box 
is different way to load fb since one box doesn't use grub efi and a 
slightly different video board.
All software is at the same version level, the motherboard is the same 
and the CPU are nearly identical (AMD FX(tm)-6300 vs 6100).



Is there more information in the Xorg stderr output? Maybe try setting
the environment variable EGL_LOG_LEVEL=debug as well for that.


See atachments.


Does the same problem happen with 1:7.8.0-1+b1 with

Option "AccelMethod" "glamor"

in /etc/X11/xorg.conf ?


Older xserver-xorg-video-radeon with that option DOESN'T WORK.
Black screen, text cursor at the top right corner ( _ ).

Newer xserver-xorg-video-radeon with that option DOESN'T WORK.
But I can't see the text cursor (_) anymore. Just black screen.

X log is the same.

Recent upgrade to 4.11.0-1 kernel didn't improve the situation.

Downgrading xserver-xorg-video-radeon and removing that option makes X work.

Thanks.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it http://www.borgonovo.net

[0.00] Linux version 4.11.0-1-amd64 (debian-ker...@lists.debian.org) 
(gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.11.6-1 
(2017-06-19)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.11.0-1-amd64 
root=UUID=dcd7e032-24f6-4b6c-bd4a-0f2fd179a15e ro quiet splash
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xba9c7fff] usable
[0.00] BIOS-e820: [mem 0xba9c8000-0xbab4bfff] reserved
[0.00] BIOS-e820: [mem 0xbab4c000-0xbab5bfff] ACPI data
[0.00] BIOS-e820: [mem 0xbab5c000-0xbb95cfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbb95d000-0xbca39fff] reserved
[0.00] BIOS-e820: [mem 0xbca3a000-0xbca3afff] usable
[0.00] BIOS-e820: [mem 0xbca3b000-0xbcc40fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbcc41000-0xbd082fff] usable
[0.00] BIOS-e820: [mem 0xbd083000-0xbd7f3fff] reserved
[0.00] BIOS-e820: [mem 0xbd7f4000-0xbd7f] usable
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfec2-0xfec20fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed61000-0xfed70fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfef0-0x] reserved
[0.00] BIOS-e820: [mem 0x00011000-0x00023eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE 
R2.0, BIOS 2103 11/06/2013
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 

Bug#867192: [Pkg-dns-devel] Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: let systemd know about the pid file

[Robert Edmonds]

Daniel Kahn Gillmor wrote:
> On Fri 2017-07-14 16:25:26 -0400, Robert Edmonds wrote:
> > Well, we would append the "-p /run/unbound.pid" bit to DAEMON_OPTS in
> > the sysvinit script unconditionally, something like:
> >
> > [...]
> > # Override this variable by editing or creating /etc/default/unbound.
> > DAEMON_OPTS=""
> >
> > if [ -f /etc/default/unbound ]; then
> > . /etc/default/unbound
> > fi
> >
> > DAEMON_OPTS="$DAEMON_OPTS -p $PIDFILE"
> > [...]
> >
> > No changes to the interface/contract. In fact this seems less broken to
> > me, because we hardcode the path to the pidfile in the sysvinit script.
> > Currently, if you set 'pidfile' yourself to some other value in the
> > Unbound config then start-stop-daemon looks in the wrong place for the
> > pidfile.
> 
> I understand what you're saying from the point of view of debian, though
> it still makes it a little bit strange because then anyone who manually
> puts DAEMON_OPTS="-p /foo/bar" in /etc/default/unbound has it get
> overridden.

I guess we could override the variable like:

DAEMON_OPTS="-p ... $DAEMON_OPTS"

so that if DAEMON_OPTS="-p ..." appears in /etc/default/unbound, the
setting in /etc/default/unbound would take precedence. But if you're
trying to override the pidfile path, this has never actually worked
without editing the sysvinit script, so I don't care too much about this
use case.

> But i was thinking about the issue from upstream -- they have to
> coordinate their daemon changes with everyone using unbound, and the
> semantics of running "unbound -c foo.conf" will now change if we change
> the default, since the default path for the pidfile itself is currently
> compiled in (if you don't specify pidfile in the config file it'll still
> create a pidfile, i think).
> 
> One way to make your approach more feasible (without changing upstream's
> expected contracts generically) would be to something like (untested):
> 
> ./configure --with-pidfile=
> 
> (that is, the empty pidfile).  Then anyone on a debian system without a
> pidfile directive in the .conf just wouldn't get a pidfile (since
> daemon/unbound.c tests pidfile[0]).  if we did that, then adding your
> proposed implementation to the init script would make sense -- because
> there'd be no public expectation that -p is something you'd manually
> supply in DAEMON_OPTS.  I guess we're saying that "-p /foo/bar" should
> take precedence over 'pidfile: "/baz/qux"' in the config file, right?

Yeah, exactly.

-- 
Robert Edmonds
edmo...@debian.org

Bug#868365: gcc-7: Please enable gnat-7 on m68k

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7.1.0-9
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

After fixing gnat in gcc-7 with the small patch provided in
#862927 [1], I have successfully bootstrapped gnat-7 for
m68k and uploaded the packages to unstable so that gnat-7
can be used as a build dependency for gcc-7.

Thus, please enable gnat in gcc-7 on m68k by dropping "m68k"
from "ada_no_cpus" in debian/rules.defs after adding the
patch provided in #862927 [1] and adding "gnat-7 [m68k]"
to Build-Depends in debian/control.

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862927

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#764486: lintian: allow using suppress-tags or dont-check-part from .lintianrc

[Chris Lamb]

tags 764486 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=0e6bbd7ed5022a89fa99f248de2cef1932fa3acc


Regards,

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

Bug#865093: stretch-pu review: package mariadb-10.1/10.1.24-0+deb9u1

[Ian Jackson]

I looked at this request.

tl/dr: it contains undiscussed upstream changes and I think it should
be referred back to the submitter for more information.


I had some difficulty figuring out what was going on because the pu
bug didn't contain an explanation of the changes in the upstream parts
of the package.  To clarify: the proposal is to upgrade from
10.1_10.1.23-9+deb9u1 to this 10.1.24-0+deb9u1.

I wasn't able to find the upstream changelog in the source package.
Admittedly I didn't look very hard - I eyeballed the source package.
There doesn't seem to be any discussion from the proponent to explain
what the upstream changes are and why (or whether) they are desirable.


Thanks,
Ian.


-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#770265: gir1.2-ibus-1.0: fails to install in multiarch setting: dpkg-query --listfiles called with ambiguous package name

[Jose M Calhariz]

On 14/07/17 22:41, Jose M Calhariz wrote:
> Package: dh-python
> Version: 2.20170125
> Followup-For: Bug #770265
>
>
> This problem prevents a full cross-grade of gnome from i386 to amd64,
> leaving a broken gnome.  The list of packages pending configure
> because of this problem are:
>
> gir1.2-ibus-1.0:amd64
> gnome-shell
> gnome-shell-extensions
> gnome-core
> chrome-gnome-shell
> gnome-session
> gnome
> network-manager-gnome
> gdm3
>
> A workaround is to hack the postinst by hand.

Just found about DPKG_MAINTSCRIPT_ARCH environment .  So the generated
code should be:

# Automatically added by dh_python3:
if which py3compile >/dev/null 2>&1; then
py3compile -p gir1.2-ibus-1.0:$DPKG_MAINTSCRIPT_ARCH
fi

Kind regards

Jose M Calhariz





signature.asc
Description: OpenPGP digital signature

Bug#867192: [Pkg-dns-devel] Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: let systemd know about the pid file

[Daniel Kahn Gillmor]

On Fri 2017-07-14 16:25:26 -0400, Robert Edmonds wrote:
> Well, we would append the "-p /run/unbound.pid" bit to DAEMON_OPTS in
> the sysvinit script unconditionally, something like:
>
> [...]
> # Override this variable by editing or creating /etc/default/unbound.
> DAEMON_OPTS=""
>
> if [ -f /etc/default/unbound ]; then
> . /etc/default/unbound
> fi
>
> DAEMON_OPTS="$DAEMON_OPTS -p $PIDFILE"
> [...]
>
> No changes to the interface/contract. In fact this seems less broken to
> me, because we hardcode the path to the pidfile in the sysvinit script.
> Currently, if you set 'pidfile' yourself to some other value in the
> Unbound config then start-stop-daemon looks in the wrong place for the
> pidfile.

I understand what you're saying from the point of view of debian, though
it still makes it a little bit strange because then anyone who manually
puts DAEMON_OPTS="-p /foo/bar" in /etc/default/unbound has it get
overridden.

But i was thinking about the issue from upstream -- they have to
coordinate their daemon changes with everyone using unbound, and the
semantics of running "unbound -c foo.conf" will now change if we change
the default, since the default path for the pidfile itself is currently
compiled in (if you don't specify pidfile in the config file it'll still
create a pidfile, i think).

One way to make your approach more feasible (without changing upstream's
expected contracts generically) would be to something like (untested):

./configure --with-pidfile=

(that is, the empty pidfile).  Then anyone on a debian system without a
pidfile directive in the .conf just wouldn't get a pidfile (since
daemon/unbound.c tests pidfile[0]).  if we did that, then adding your
proposed implementation to the init script would make sense -- because
there'd be no public expectation that -p is something you'd manually
supply in DAEMON_OPTS.  I guess we're saying that "-p /foo/bar" should
take precedence over 'pidfile: "/baz/qux"' in the config file, right?

 --dkg

Bug#868359: libpam-systemd should maybe not fire on non-login users

[Michael Biebl]

Hi Don

Am 14.07.2017 um 23:04 schrieb Don Armstrong:
> It seems reasonable that non-login users should not have per-user
> sessions by default. Using pam_succeed_if to skip creation for users
> with /bin/false or /usr/sbin/nologin shells seems reasonable.
> 
> IE, the following (currently untested):
> 
> Name: Register user sessions in the systemd control group hierarchy
> Default: yes
> Priority: 0
> Session-Interactive-Only: yes

This was supposed to ensure that pam_systemd is only included for
interactive sessions.
Wouldn't it be better if non-login users use
/etc/pam.d/common-session-noninteractive?
Where exactly did you see pam_systemd used where it shouldn't have been?

> Session-Type: Additional
> Session:
> [success=2 default=ignore] pam_succeed_if quiet shell = /bin/false
> [success=1 default=ignore] pam_succeed_if quiet shell = 
> /usr/sbin/nologin
> optionalpam_systemd.so
> 

Didn't know that PAM could do that.
That's interesting and scary at the same time :-)


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#770265: gir1.2-ibus-1.0: fails to install in multiarch setting: dpkg-query --listfiles called with ambiguous package name

[Jose M Calhariz]

Package: dh-python
Version: 2.20170125
Followup-For: Bug #770265


This problem prevents a full cross-grade of gnome from i386 to amd64,
leaving a broken gnome.  The list of packages pending configure
because of this problem are:

gir1.2-ibus-1.0:amd64
gnome-shell
gnome-shell-extensions
gnome-core
chrome-gnome-shell
gnome-session
gnome
network-manager-gnome
gdm3
 
A workaround is to hack the postinst by hand.

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_GB.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-python depends on:
ii  python3  3.5.3-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
pn  libdpkg-perl  

-- no debconf information

Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution

[Till Kamppeter]

It seems that the printer answers the wrong resolution (firmware bug). 
Under the printer's attributes I have found:



DEBUG2: Attr: pwg-raster-document-resolution-supported
DEBUG2: Value: 600x2dpi


Please run the following command:

ipptool -tv ipp://copper.local:631/ipp/print get-printer-attributes.test 
> ipp-attrs.txt


and attach the file ipp-attrs.txt to your answer to this bug report. Thanks.

To be able to print for the time being, please edit your PPD file as 
follows:


Replace

--
*DefaultResolution: 600x2dpi
*OpenUI *cupsPrintQuality/Print Quality: PickOne
*OrderDependency: 10 AnySetup *cupsPrintQuality
*DefaultcupsPrintQuality: Normal
*cupsPrintQuality Normal/Normal: "<>setpagedevice"
*cupsPrintQuality High/High: "<>setpagedevice"
*CloseUI: *cupsPrintQuality
--

by

--
*DefaultResolution: 600x600dpi
*OpenUI *cupsPrintQuality/Print Quality: PickOne
*OrderDependency: 10 AnySetup *cupsPrintQuality
*DefaultcupsPrintQuality: Normal
*cupsPrintQuality Normal/Normal: "<>setpagedevice"
*cupsPrintQuality High/High: "<>setpagedevice"
*CloseUI: *cupsPrintQuality
--

Do not forget to restart CUPS after editing or replacing your PPD file.

Please tell whether this change fixes your problem.

   Till

Bug#868364: python-ase: Exporting png image file fails

[Jonathan Sutton]

Subject: python-ase: Exporting png image file fails
Package: python-ase
Version: 3.12.0-2
Tags: patch
Severity: normal

Dear Maintainer,

Attempting to save a png file results in a fatal exception due to an
incompatibility between the ASE code and a call to the matplotlib routine
actually responsible for saving the image file.

This bug has been fixed upstream and in testing, but a patch needs to be
applied
to the version in stable. To correct the bug, line 39 in ase/io/png.py
should be
changed from

  except (TypeError, ValueError):

The image quality is very bad, but that's a separate issue I haven't looked
into. It may be fixed upstream as well.

Jonathan Sutton

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

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

Versions of packages python-ase depends on:
ii  python2.7.13-2
ii  python-numpy  1:1.12.1-3
ii  python-scipy  0.18.1-2

Versions of packages python-ase recommends:
ii  python-gtk22.24.0-5.1
ii  python-matplotlib  2.0.0+dfsg1-2

Versions of packages python-ase suggests:
pn  python-ase-doc  

-- no debconf information

Bug#826473: #826473: kdesrc-build: Unescaped left brace in regex is deprecated

[gregor herrmann]

On Thu, 22 Jun 2017 12:36:15 +0200, Maximiliano Curia wrote:

¡Hola Maxy!

> El 2017-06-21 a las 20:16 +, Damyan Ivanov escribió:
> > This deprecation warning becomes a fatal error with perl 5.26, currently
> > in experimental. Bumping severity accordingly.
> > At some time perl 5.26 will enter unstable and this bug will become
> > serious.

This happened today as the transition is imminent.
 
> The fix seems to be simple enough, even for a perl illiterate as myself,
> but, as mentioned via irc, I'm wondering if it's really worth to keep
> kdesrc-build around.
> 
> It seems that the current recommended way of using it is to checkout
> upstream's git head, and releases are intentionally being discourage. While
> the current version is Debian has been around since wheezy, so I guess it
> won't work very well with kf5, plasma 5 and friends.
> 
> So I'm sending a ping to Pino Toscano, as he was the last one to work on
> this package, about this.

I'm fine either way :)
Please try to get this sorted out in the next days.

I'm happy to help with a patch and/or an NMU in case this would be
helpful.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Red Hot Chili Peppers: Universally Speaking


signature.asc
Description: Digital Signature

Bug#826505: swissknife: diff for NMU version 1.67-1.2

[gregor herrmann]

Control: tags 826505 + pending

Dear maintainer,

I've prepared an NMU for swissknife (versioned as 1.67-1.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: trio infernal: mercy mercy
diff -u swissknife-1.67/debian/changelog swissknife-1.67/debian/changelog
--- swissknife-1.67/debian/changelog
+++ swissknife-1.67/debian/changelog
@@ -1,3 +1,12 @@
+swissknife (1.67-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS with perl 5.26: Unescaped left brace in regex":
+apply patches from Niko Tyni which fix regexp quantifiers and regexp
+quoting. (Closes: #826505)
+
+ -- gregor herrmann   Fri, 14 Jul 2017 23:24:18 +0200
+
 swissknife (1.67-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- swissknife-1.67.orig/lib/SWISS/BaseClass.pm
+++ swissknife-1.67/lib/SWISS/BaseClass.pm
@@ -168,7 +168,7 @@
 sub addEvidenceTag {
   my $self = shift;
   my $tag = shift;
-  unless ($self->{'evidenceTags'} =~ /[\{\,]$tag[\}\,]/) {
+  unless ($self->{'evidenceTags'} =~ /[\{\,]\Q$tag\E[\}\,]/) {
 if ($self->{'evidenceTags'} eq '{}') {
   $self->{'evidenceTags'} = '{' . $tag . '}';
 } else {
only in patch2:
unchanged:
--- swissknife-1.67.orig/lib/SWISS/TextFunc.pm
+++ swissknife-1.67/lib/SWISS/TextFunc.pm
@@ -193,7 +193,7 @@
   # of length 1 ($sepLength = 1)
   my $sepLength = 1;
   my $w1 = $cutPos - $sepLength;
-  if ($postMatch =~ /^(\S{0,$w1}$separators[$j])/) {
+  if ($w1 >= 0 and $postMatch =~ /^(\S{0,$w1}$separators[$j])/) {
 $cutPos = length($1);
 last;
   }


signature.asc
Description: Digital Signature

Bug#868362: transition: libofx7

[Dylan Aïssi]

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

Dear Release Team,

Please schedule a transition for libofx.
The 5 reverse build-deps (gnucash, grisbi, homebank, kmymoney,
skrooge) currently build fine with the new version.

Thanks,
Dylan



Ben file:

title = "libofx";
is_affected = .depends ~ "libofx6" | .depends ~ "libofx7";
is_good = .depends ~ "libofx7";
is_bad = .depends ~ "libofx6";

Bug#864028: stretch-pu: package flatpak, maybe want debdiff against security?

[Ian Jackson]

tl/dr: I started reviewing this request, but didn't finish.


The biggest thing I tripped over was that the debdiff is against
current stretch, not against stretch-security.  So I found myself
seeing changes in the diff which had already been made on stretch
installations, in practice.

Is this normal ?  IMO a debdiff against the most recent update,
including any security update, would be much more useful.

I stopped when I noticed this, so my review was incomplete.

But, I found, while reading the diff, that the extra code to fix the
permissions code is large and complicated.  OTOH I'm not sure we can
afford not to have it.


OTOH most of the changes described in the changelog sound like ones we
would want to take for stretch-updates.  The only one I'm a bit wary
of is this one

+- Let KDE apps bind-mount ~/.config/kdeglobals into the sandbox:

whose security implications I don't feel I understand.  Is there any
more discussion of that ?


Thanks,
Ian.


-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#865380: Pending fixes for bugs in the libtest-unixsock-perl package

[pkg-perl-maintainers]

tag 865380 + pending
thanks

Some bugs in the libtest-unixsock-perl package are closed in revision
87a0d4577fe4b670266d2fa84b784f5717c12f17 in branch 'master' by gregor
herrmann

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

Commit message:

debian/control: drop the Build-Conflicts-Indep on newer Test::More.

Not needed with the new patch.

Closes: #865380

Bug#868342: (no subject)

[Gianfranco Costamagna]

control: forcemerge -1 868290

G.



signature.asc
Description: OpenPGP digital signature

Bug#865380: libtest-unixsock-perl: Build-Conflicts-Indep: libtest-simple-perl (>= 1.3), including Perl 5.26

[gregor herrmann]

Control: clone -1 -2
Control: severity -2 normal
Control: retitle -2 libtest-unixsock-perl: occasional failures of 
t/15_oo_unix.t with Test::More >= 1.3

On Wed, 21 Jun 2017 00:11:58 +0200, gregor herrmann wrote:

> My not very elegant proposal for libtest-unixsock-perl would be to
> - drop the Build-Conflicts-Indep, and
> - to skip t/15_oo_unix.t

Currently the package doesn't FTBFS as the versioned provides in
perl are reverted but we'll have this issue again soon (hopefully),
and even without, the Build-Conflicts-Indep can lead to troubles when
a newer libtest-simple-perl is (to be) installed for other reasons.

So I went ahead, dropped the Build-Conflicts-Indep and added a patch
to conditionally skip t/15_oo_unix.t if Test::More >= 1.3.

Closing the original bug in the upload, but cloning the bug to keep a
record of the workaround and underlying problem.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: The Beatles: Come Together


signature.asc
Description: Digital Signature

Bug#868361: stretch-pu: package socat/1.7.3.1-2+deb9u1

[GCS]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi SRMs,

There's a chance that on some signals (including, but not limited to
SIGSEGV) socat goes to an infinite loop and consume all CPU cycles.
Upstream patched it[1] for 1.7.3.2 release, which is in Sid. Basically
set 'diag_immediate_exit' in the signal handling function to let it
exit. Full debdiff is attached.

Thanks for considering,
Laszlo/GCS
[1] 
http://repo.or.cz/socat.git/commitdiff/6b596b8852d8fad2675894e3ceb18a04801eaf23?hp=d34493c18df0a4d0c4fdb5bda74a155ce13e4ccf
diff -Nru socat-1.7.3.1/debian/changelog socat-1.7.3.1/debian/changelog
--- socat-1.7.3.1/debian/changelog	2016-11-24 22:47:30.0 +
+++ socat-1.7.3.1/debian/changelog	2017-07-14 13:52:03.0 +
@@ -1,3 +1,10 @@
+socat (1.7.3.1-2+deb9u1) stretch; urgency=medium
+
+  * Backport upstream fix for SIGSEGV and other signals could lead to a
+100% CPU loop.
+
+ -- Laszlo Boszormenyi (GCS)   Fri, 14 Jul 2017 13:52:03 +
+
 socat (1.7.3.1-2) unstable; urgency=low
 
   * Backport upstream fix to build with OpenSSL 1.1.0 (closes: #828550).
diff -Nru socat-1.7.3.1/debian/patches/08-signals_could_lead_CPU_loop.patch socat-1.7.3.1/debian/patches/08-signals_could_lead_CPU_loop.patch
--- socat-1.7.3.1/debian/patches/08-signals_could_lead_CPU_loop.patch	1970-01-01 00:00:00.0 +
+++ socat-1.7.3.1/debian/patches/08-signals_could_lead_CPU_loop.patch	2017-07-14 13:52:03.0 +
@@ -0,0 +1,43 @@
+From 6b596b8852d8fad2675894e3ceb18a04801eaf23 Mon Sep 17 00:00:00 2001
+From: Gerhard Rieger 
+Date: Wed, 11 May 2016 20:34:33 +0200
+Subject: [PATCH 1/1] SIGSEGV and other signals could lead to a 100% CPU loop
+
+---
+ CHANGES | 3 +++
+ socat.c | 3 ++-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/CHANGES b/CHANGES
+index ee15bd0..1e1bc5d 100644
+--- a/CHANGES
 b/CHANGES
+@@ -1,3 +1,6 @@
++corrections:
++	SIGSEGV and other signals could lead to a 100% CPU loop
++
+ porting:
+ 	Changes to make socat compile with OpenSSL 1.1. 
+ 	Thanks to Sebastian Andrzej Siewior e.a. from the Debian team for
+diff --git a/socat.c b/socat.c
+index 09039ff..ace006d 100644
+--- a/socat.c
 b/socat.c
+@@ -1422,12 +1422,13 @@ void socat_signal(int signum) {
+diag_in_handler = 1;
+Notice1("socat_signal(): handling signal %d", signum);
+switch (signum) {
+-   case SIGQUIT:
+case SIGILL:
+case SIGABRT:
+case SIGBUS:
+case SIGFPE:
+case SIGSEGV:
++  diag_immediate_exit = 1;
++   case SIGQUIT:
+case SIGPIPE:
+   diag_set_int('x', 128+signum);	/* in case Error exits for us */
+   Error1("exiting on signal %d", signum);
+-- 
+2.7.4.GIT
+
diff -Nru socat-1.7.3.1/debian/patches/series socat-1.7.3.1/debian/patches/series
--- socat-1.7.3.1/debian/patches/series	2016-11-24 22:47:30.0 +
+++ socat-1.7.3.1/debian/patches/series	2017-07-14 13:52:03.0 +
@@ -6,3 +6,4 @@
 05-xio-ip.patch
 06-socat.1.patch
 07-openssl-1.1.patch
+08-signals_could_lead_CPU_loop.patch

Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution

[brian m. carlson]

Package: cups-filters-core-drivers
Version: 1.14.1-1
Severity: normal

I have a Brother MFC-9340CDW printer on the local LAN.  When using the
driverless configuration, the resolution is set to 600x2 dpi, resulting
in the printer printing literally two lines on the page.  The resolution
of the printer is either 600x600 or 600x2400 dpi.

The output of the command is below.  You can see that it recognizes the
correct resolution, but emits the incorrect one in the PPD.  I suspect
something is getting truncated somewhere.

genre ok % /usr/lib/cups/driver/driverless cat ipp://copper.local:631/ipp/print
DEBUG2: Attr: attributes-charset
DEBUG2: Value: utf-8
DEBUG2: Keyword: utf-8
DEBUG2: Attr: attributes-natural-language
DEBUG2: Value: en-us
DEBUG2: Keyword: en-us
DEBUG2: Attr: copies-default
DEBUG2: Value: 1
DEBUG2: Keyword: (null)
DEBUG2: Attr: finishings-default
DEBUG2: Value: none
DEBUG2: Keyword: (null)
DEBUG2: Attr: media-default
DEBUG2: Value: na_letter_8.5x11in
DEBUG2: Keyword: na_letter_8.5x11in
DEBUG2: Attr: media-col-default
DEBUG2: Value: {media-type=stationery media-size={x-dimension=21590 
y-dimension=27940} media-bottom-margin=432 media-left-margin=432 
media-right-margin=432 media-top-margin=432 media-source=auto}
DEBUG2: Keyword: (null)
DEBUG2: Attr: orientation-requested-default
DEBUG2: Value: portrait
DEBUG2: Keyword: (null)
DEBUG2: Attr: output-bin-default
DEBUG2: Value: face-down
DEBUG2: Keyword: face-down
DEBUG2: Attr: output-mode-default
DEBUG2: Value: color
DEBUG2: Keyword: color
DEBUG2: Attr: print-quality-default
DEBUG2: Value: normal
DEBUG2: Keyword: (null)
DEBUG2: Attr: printer-resolution-default
DEBUG2: Value: 600dpi
DEBUG2: Keyword: (null)
DEBUG2: Attr: sides-default
DEBUG2: Value: one-sided
DEBUG2: Keyword: one-sided
DEBUG2: Attr: print-color-mode-default
DEBUG2: Value: color
DEBUG2: Keyword: color
DEBUG2: Attr: copies-supported
DEBUG2: Value: 1-1
DEBUG2: Keyword: (null)
DEBUG2: Attr: finishings-supported
DEBUG2: Value: none
DEBUG2: Keyword: (null)
DEBUG2: Attr: media-supported
DEBUG2: Value: 
iso_a4_210x297mm,na_letter_8.5x11in,na_legal_8.5x14in,na_executive_7.25x10.5in,iso_a5_148x210mm,iso_a6_105x148mm,iso_b5_176x250mm,jis_b5_182x257mm,na_number-10_4.125x9.5in,iso_dl_110x220mm,iso_c5_162x229mm,na_monarch_3.875x7.5in,na_index-3x5_3x5in,om_folio_210x330mm,custom_min_76.2x127mm,custom_max_215.9x355.6mm
DEBUG2: Keyword: iso_a4_210x297mm
DEBUG2: Keyword: na_letter_8.5x11in
DEBUG2: Keyword: na_legal_8.5x14in
DEBUG2: Keyword: na_executive_7.25x10.5in
DEBUG2: Keyword: iso_a5_148x210mm
DEBUG2: Keyword: iso_a6_105x148mm
DEBUG2: Keyword: iso_b5_176x250mm
DEBUG2: Keyword: jis_b5_182x257mm
DEBUG2: Keyword: na_number-10_4.125x9.5in
DEBUG2: Keyword: iso_dl_110x220mm
DEBUG2: Keyword: iso_c5_162x229mm
DEBUG2: Keyword: na_monarch_3.875x7.5in
DEBUG2: Keyword: na_index-3x5_3x5in
DEBUG2: Keyword: om_folio_210x330mm
DEBUG2: Keyword: custom_min_76.2x127mm
DEBUG2: Keyword: custom_max_215.9x355.6mm
DEBUG2: Attr: media-col-supported
DEBUG2: Value: 
media-type,media-size,media-top-margin,media-left-margin,media-right-margin,media-bottom-margin,media-source
DEBUG2: Keyword: media-type
DEBUG2: Keyword: media-size
DEBUG2: Keyword: media-top-margin
DEBUG2: Keyword: media-left-margin
DEBUG2: Keyword: media-right-margin
DEBUG2: Keyword: media-bottom-margin
DEBUG2: Keyword: media-source
DEBUG2: Attr: orientation-requested-supported
DEBUG2: Value: portrait,landscape
DEBUG2: Keyword: (null)
DEBUG2: Keyword: (null)
DEBUG2: Attr: output-bin-supported
DEBUG2: Value: face-down
DEBUG2: Keyword: face-down
DEBUG2: Attr: output-mode-supported
DEBUG2: Value: color,auto,monochrome
DEBUG2: Keyword: color
DEBUG2: Keyword: auto
DEBUG2: Keyword: monochrome
DEBUG2: Attr: print-quality-supported
DEBUG2: Value: normal,high
DEBUG2: Keyword: (null)
DEBUG2: Keyword: (null)
DEBUG2: Attr: printer-resolution-supported
DEBUG2: Value: 600dpi,2400x600dpi
DEBUG2: Keyword: (null)
DEBUG2: Keyword: (null)
DEBUG2: Attr: sides-supported
DEBUG2: Value: one-sided,two-sided-long-edge,two-sided-short-edge
DEBUG2: Keyword: one-sided
DEBUG2: Keyword: two-sided-long-edge
DEBUG2: Keyword: two-sided-short-edge
DEBUG2: Attr: print-color-mode-supported
DEBUG2: Value: auto,color,monochrome
DEBUG2: Keyword: auto
DEBUG2: Keyword: color
DEBUG2: Keyword: monochrome
DEBUG2: Attr: generated-natural-language-supported
DEBUG2: Value: en,fr
DEBUG2: Keyword: en
DEBUG2: Keyword: fr
DEBUG2: Attr: printer-uri-supported
DEBUG2: Value: ipp://copper.local./ipp/print
DEBUG2: Keyword: ipp://copper.local./ipp/print
DEBUG2: Attr: uri-security-supported
DEBUG2: Value: none
DEBUG2: Keyword: none
DEBUG2: Attr: uri-authentication-supported
DEBUG2: Value: none
DEBUG2: Keyword: none
DEBUG2: Attr: printer-name
DEBUG2: Value: copper[en]
DEBUG2: Keyword: copper
DEBUG2: Attr: printer-location
DEBUG2: Value: [en]
DEBUG2: Keyword:
DEBUG2: Attr: printer-info
DEBUG2: Value: Brother MFC-9340CDW[en]
DEBUG2: Keyword: Brother MFC-9340CDW
DEBUG2: Attr: printer-make-and-model
DEBUG2: Value: Brother 

Bug#868042: poedit: Texts become right-aligned after upgrade onto poedit2

[Olly Betts]

On Fri, Jul 14, 2017 at 07:14:54AM +, Gianfranco Costamagna wrote:
> anyway, with all the bugfixes in 3.0.3 less defer the (eventual) transition
> for 3.1, right?

Sorry, I'm failing to understand quite what you're asking.

But anyway we can't transition to 3.1, as it's not ABI stable - we need to wait
for upstream to release 3.2 to do that actual transition.  We can try to
get wider testing with 3.1, and perhaps upload a version to experimental,
but even for that, waiting for 3.1.1 is probably sensible as 3.1.0 is quite
old now, and packaging a snapshot makes forwarding bugs upstream more complex.

Meanwhile I think uploading 3.0.3.1 makes sense - there have been a lot of
fixes since 3.0.2, and it allows dropping 3 patches we're carrying.  Also there
are a few debian-specific bugs that we can deal with.

Cheers,
Olly

Bug#868202: Remove build-depends and depends on python3-trollius

[Iain R. Learmonth]

Hi,

Please go ahead and remove trollius, will update qtile shortly.

Thanks,
Iain.

On 07/13/2017 03:32 AM, Michael Hudson-Doyle wrote:

Source: qtile
Severity: normal
User: debian-pyt...@lists.debian.org 


Usertags: python3.6 no-more-python3-trollius

Hi,

I want to remove the python3-trollius package from Debian, and qtile
only imports trollius if asyncio is not found, and asyncio is part of all
supported versions of Python 3 in Debian, so the build-depends and depends
on python3-trollius can simply be dropped.

Cheers,
mwh

Bug#868359: libpam-systemd should maybe not fire on non-login users

[Don Armstrong]

Package: libpam-systemd
Version: 232-25
Severity: minor

It seems reasonable that non-login users should not have per-user
sessions by default. Using pam_succeed_if to skip creation for users
with /bin/false or /usr/sbin/nologin shells seems reasonable.

IE, the following (currently untested):

Name: Register user sessions in the systemd control group hierarchy
Default: yes
Priority: 0
Session-Interactive-Only: yes
Session-Type: Additional
Session:
[success=2 default=ignore] pam_succeed_if quiet shell = /bin/false
[success=1 default=ignore] pam_succeed_if quiet shell = 
/usr/sbin/nologin
optionalpam_systemd.so


Alternatively, documenting this workaround in README.Debian might be
good enough.

-- 
Don Armstrong  https://www.donarmstrong.com

Love is... a complex sequence of neurochemical reactions that makes
people behave like idiots. It's similar to intoxication, but the
hangover's even worse.
 -- J. Jacques _Questionable Content_ #1039
http://www.questionablecontent.net/view.php?comic=1039

Bug#868358: mate-screensaver no longer blanks or shows any screensaver.

[shirish शिरीष]

Package: mate-screensaver
Version: 1.16.1-1
Severity: normal

Dear Maintainer,

Thank you for maintaining mate-screensaver. For last couple of days,
neither is it functioning not is any anergy being saved. Please fix
it.



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

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

Versions of packages mate-screensaver depends on:
ii  dbus-x11  1.10.20-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-12
ii  libcairo-gobject2 1.14.10-1
ii  libcairo2 1.14.10-1
ii  libdbus-1-3   1.10.20-1
ii  libdbus-glib-1-2  0.108-2
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglib2.0-0  2.52.3-1
ii  libgtk-3-03.22.16-1
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.16.2-2
ii  libmate-menu2 1.16.0-2
ii  libmatekbd4   1.16.0-2
ii  libnotify40.7.7-2
ii  libpam0g  1.1.8-3.6
ii  libpango-1.0-01.40.6-1
ii  libpangocairo-1.0-0   1.40.6-1
ii  libsm62:1.2.2-1+b3
ii  libstartup-notification0  0.12-4+b2
ii  libsystemd0   233-10
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxklavier16 5.4-2
ii  libxss1   1:1.2.2-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  mate-desktop-common   1.16.2-2
ii  mate-screensaver-common   1.16.1-1
ii  mate-session-manager  1.16.1-1

Versions of packages mate-screensaver recommends:
ii  mate-power-manager  1.16.2-1

Versions of packages mate-screensaver suggests:
ii  rss-glx0.9.1-6.1
ii  xscreensaver-data  5.36-1

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#868146: transition: alglib

[Anton Gladky]

2017-07-14 9:16 GMT+02:00 Emilio Pozuelo Monfort :
> Go ahead now.

Uploaded.

Anton

Bug#868357: installation-guide: get rid of "not up to date for " warnings

[Holger Wansing]

Package: installation-guide
Severity: wishlist

On (for example)
http://d-i.alioth.debian.org/manual/en.arm64/index.html
the installation guide has warning messages like

"Although this installation guide for amd64 is mostly up-to-date, 
we plan to make some changes and reorganize parts of the manual 
after the official release of buster."

or

"This installation guide is based on an earlier manual written for the 
old Debian installation system (the “boot-floppies”), and has been updated 
to document the new Debian installer. However, for arm64, the manual has 
not been fully updated and fact checked for the new installer. There may 
remain parts of the manual that are incomplete or outdated or that still 
document the boot-floppies installer."

depending on the architecture.

Those warnings are there since Woody or Sarge, and I think they are no
longer true.
We should remove them.

Comments welcome.


Holger



-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#865888: nagios-plugin-check-multi: diff for NMU version 0.26-3.1

[gregor herrmann]

Control: tags 865888 + pending

Dear maintainer,

I've prepared an NMU for nagios-plugin-check-multi (versioned as 0.26-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bjørn Berge: One Believer
diff -Nru nagios-plugin-check-multi-0.26/debian/changelog nagios-plugin-check-multi-0.26/debian/changelog
--- nagios-plugin-check-multi-0.26/debian/changelog	2016-12-24 14:24:12.0 +0100
+++ nagios-plugin-check-multi-0.26/debian/changelog	2017-07-14 22:42:46.0 +0200
@@ -1,3 +1,12 @@
+nagios-plugin-check-multi (0.26-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS with Perl 5.26: Unescaped left brace in regex is
+deprecated here": update unescaped-left-brace-in-regex.patch to escape one
+more '{'. (Closes: #865888)
+
+ -- gregor herrmann   Fri, 14 Jul 2017 22:42:46 +0200
+
 nagios-plugin-check-multi (0.26-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru nagios-plugin-check-multi-0.26/debian/patches/unescaped-left-brace-in-regex.patch nagios-plugin-check-multi-0.26/debian/patches/unescaped-left-brace-in-regex.patch
--- nagios-plugin-check-multi-0.26/debian/patches/unescaped-left-brace-in-regex.patch	2016-12-24 13:32:25.0 +0100
+++ nagios-plugin-check-multi-0.26/debian/patches/unescaped-left-brace-in-regex.patch	2017-06-30 01:10:34.0 +0200
@@ -26,3 +26,12 @@
  			$type="$1";
  			$typelist{$type}++;
  			$objectcount++;
+@@ -3217,7 +3217,7 @@ sub report_all {
+ 
+ 	#--- some debugging first
+ 	DEBUG4("MULTI Environment (sorted):\n\t".join("\n\t",get_env_vars('^MULTI')));
+-	DEBUG4("${NAGIOS} Environment (sorted):\n\t".join("\n\t",get_env_vars('^${NAGIOS}')));
++	DEBUG4("${NAGIOS} Environment (sorted):\n\t".join("\n\t",get_env_vars('^$\{NAGIOS}')));
+ 
+ 	#--- construction site for persistence
+ 	if ($opt{set}{test} && $opt{set}{persistent}) {


signature.asc
Description: Digital Signature

Bug#868356: dpkg: integer overflow in deb_version_parse()

[Jakub Wilk]

Source: dpkg
Version: 1.18.24
Severity: minor

The attached crafted package triggers signed integer overflow in 
deb_version_parse(). This is undefined behavior.


--
Jakub Wilk


intoverflow.deb
Description: application/vnd.debian.binary-package

Bug#852330: dia: dia --export to svg adds junk to end

[Tomas Pospisek]

Hello Lars,

you write:


I have a .dia file that I need to convert to SVG which I do from the
command line:

dia --export=/dev/stdout --filter=svg auth.dia

This adds the following line to the end of the output:

auth.dia --> /dev/stdout

This breaks using the output in many SVG-capable programs. I can
easily filter it out but it'd be nice to not have to.


The line "auth.dia --> /dev/stdout" goes to STDERR though. So if you do:

dia --export=/dev/stdout --filter=svg auth.dia > outfile.svg

then everything works as it should.

To me this is not a bug but works as intended:

* the converted output goes to STDOUT, which enables you to continue
  processing it through a pipe or just redirect it into a file
* some info about the processing of the file for the user goes to STDERR

I think this ticket should be closed as "not a bug", let's see if I am 
able to convince you -


Let's say that there would be a warning during processing of the dia file 
(say, "The default font of Dia is FooFont however SVG's default is 
FooFont - the result might not be perfect".


Such a processing would produce a valid file when used as:

dia --export=/dev/stdout --filter=svg auth.dia > outfile.svg

however you'd see the warning on STDERR. I think that'd be perfectly 
correct and in line with Unix conventions. From that follows that 
outputing something for the user of severity "info" on STDERR should also 
be ok.


Can you agree with me? Can we close this bug?

Thanks,
*t

Bug#867192: [Pkg-dns-devel] Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: let systemd know about the pid file

[Robert Edmonds]

Daniel Kahn Gillmor wrote:
> On Fri 2017-07-14 14:19:01 -0400, Robert Edmonds wrote:
> > Hm, that could work (but then we have to carry around "-p" in the
> > service unit forever). I was thinking of a command-line parameter that
> > takes an argument to the pidfile path (like "-p /run/unbound.pid") that
> > takes precedence over the 'pidfile' value from the config file and the
> > compiled in 'pidfile' default value. And then we set the default value
> > for 'pidfile' to "" so that Unbound doesn't make a pidfile by default,
> > and append "-p /run/unbound.pid" to $DAEMON_OPTS in /etc/init.d/unbound.
> 
> I figured if we went that way we'd get complaints about changing the
> expected interface/contract with existing users of unbound -- you
> upgrade the main binary on a system that *doesn't* have a
> sensible/modern process manager, and then all of a sudden you don't get
> the pidfile protections by default!

Well, we would append the "-p /run/unbound.pid" bit to DAEMON_OPTS in
the sysvinit script unconditionally, something like:

[...]
# Override this variable by editing or creating /etc/default/unbound.
DAEMON_OPTS=""

if [ -f /etc/default/unbound ]; then
. /etc/default/unbound
fi

DAEMON_OPTS="$DAEMON_OPTS -p $PIDFILE"
[...]

No changes to the interface/contract. In fact this seems less broken to
me, because we hardcode the path to the pidfile in the sysvinit script.
Currently, if you set 'pidfile' yourself to some other value in the
Unbound config then start-stop-daemon looks in the wrong place for the
pidfile.

-- 
Robert Edmonds
edmo...@debian.org

Bug#868002: udev: README.Debian interface naming improvements

[Christoph Anton Mitterer]

On Fri, 2017-07-14 at 08:22 +0200, Martin Pitt wrote:
> Eeek, indeed! Thanks for spotting.

Thanks for improving and your other Debian work :-)

smime.p7s
Description: S/MIME cryptographic signature

Bug#864027: stretch-pu: review, package swift/2.10.2-1

[Ian Jackson]

I have reviewed this request.  tl/dr: I recommend approval.


I have looked at the debdiff and the changes seem to be as described
in the bug report.  Almost all of the things described sound very much
like important bugfixes.  I'm not entirely sure about "Improvements in
key parts of the consistency engine" but the approach taken by
upstream seem reassuring and if I were the maintainer I think I would
choose to take that change too rather than trying to drop it.

I did notice that the debdiff contains a fair few test suite changes,
including notably what looks like new tests.  I am comfortable with
that, even though this was not called out in the bug or the
changelog.  I guess that's just upstream practice.

The risk of accepting is course is that there is some bug in these
changes - perhaps even a data loss bug.  But the fact that this code
has been in the upstream stable branch for a month mitigates against
that, and the known problems described seem worse than the cure.

I did not do a code review in context, and I'm not familiar with the
codebase, so I'm not sure that the changes are indeed right.  Such a
detailed code review exercise seems beyond our realistic capabilities
for a stable update.

I'm not an ftpmaster and have no formal status.  I'm just hoping to be
helpful.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#865678: knot: Improper TSIG validity period check can allow TSIG forgery

[Yves-Alexis Perez]

On Fri, 2017-06-23 at 19:01 +0200, Salvatore Bonaccorso wrote:
> Source: knot
> Version: 2.4.3-1
> Severity: grave
> Tags: security upstream patch
> Control: found -1 2.5.1-1
> 
> Hi
> 
> See
> https://lists.nic.cz/pipermail/knot-dns-users/2017-June/001144.html
> and
> http://www.synacktiv.ninja/ressources/Knot_DNS_TSIG_Signature_Forgery.pdf
> and filling a bug in BTS to have a reference, afaik there is no CVE
> yet assigned.
> 
> [16:19] < KGB-1> Yves-Alexis Perez 52846  /data/CVE/list add temporary entry
> for knot
> [16:21] < Corsac> ondrej: I guess you know about it?

I went ahead and uploaded fixes to jessie and stretch. I've also pushed my
branches to https://anonscm.debian.org/cgit/users/corsac/security/knot.git/ in
case you want to reimport them.

Regards,
-- 
Yves-Alexis

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

Bug#868024: [packages] Processed: Re: Bug#868024: maintainer address broken

[Debian/GNU]

please keep the debian bug-report in the CC. the address is
868...@bugs.debian.org

On 07/14/2017 04:01 PM, Benoit Mortier wrote:
> Hello,
> 
> the message are comming correctly into the mailing list as we receive it
> and you can see it here
> 
> https://lists.fusiondirectory.org/wws/arc/packages/2017-07/msg4.html

hmm, well. then please downgrade the severity.

in any case, if i get an automated reply from a bug report saying that
"Your message [...] was rejected", then i must conclude that bugreport
was rejected.
after all, this is the only information i have.

(sorry: you cannot expect some bug reporter to check whether the email
shows up on some "random mailinglist archive". for all purposes, the
reporter doesn't even know that they are posting to a mailinglist).

gmadsr
IOhannes



signature.asc
Description: OpenPGP digital signature

Bug#866130: Missing sunxi_wdt.ko for cubietruck

[Cyril Brulebois]

Karsten Merker  (2017-07-13):
> If sunxi is the sole "odd" platform here, I suppose the best solution
> would be to integrate the sunxi_wdt module directly into the
> kernel-image--armmp-di udeb.  Probably we will need to
> include it for arm64 as well, as AFAIK the 64bit Allwinner SoCs A64
> and H5 use the same watchdog logic as the older 32bit SoCs.  Proper
> support for A64 and H5 will be available in kernel 4.13, so those will
> become target platforms for d-i in the nearer future.

Yeah, even if I didn't mention it in my previous mail, the kernel-image
package looks like a safe bet since there doesn't seem to be a more
suitable -modules udeb. Will work fine for stretch as well (no new
binary needed).


KiBi.


signature.asc
Description: Digital signature

Bug#867192: [Pkg-dns-devel] Bug#867192: Bug#867192: Bug#867192: Bug#867192: let systemd know about the pid file

[Daniel Kahn Gillmor]

On Fri 2017-07-14 14:19:01 -0400, Robert Edmonds wrote:
> Hm, that could work (but then we have to carry around "-p" in the
> service unit forever). I was thinking of a command-line parameter that
> takes an argument to the pidfile path (like "-p /run/unbound.pid") that
> takes precedence over the 'pidfile' value from the config file and the
> compiled in 'pidfile' default value. And then we set the default value
> for 'pidfile' to "" so that Unbound doesn't make a pidfile by default,
> and append "-p /run/unbound.pid" to $DAEMON_OPTS in /etc/init.d/unbound.

I figured if we went that way we'd get complaints about changing the
expected interface/contract with existing users of unbound -- you
upgrade the main binary on a system that *doesn't* have a
sensible/modern process manager, and then all of a sudden you don't get
the pidfile protections by default!

But i'd be fine with the change you propose, personally :)

> BTW, I don't think upstream really monitors that GitHub repository, it's
> a git-svn mirror. Posting patches to the mailing list or bugzilla seems
> to be their thing.

ok, fine:

https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1349

feel free to submit an alternate patch there that implements the variant
you prefer.

Regards,

--dkg

Bug#866389: transition: perl 5.26

[Niko Tyni]

On Fri, Jul 14, 2017 at 10:50:16AM +0200, Emilio Pozuelo Monfort wrote:
> On 02/07/17 19:04, Dominic Hargreaves wrote:
> > On Sun, Jul 02, 2017 at 05:01:20PM +0200, gregor herrmann wrote:
> >> On Fri, 30 Jun 2017 12:39:09 +0200, Emilio Pozuelo Monfort wrote:
> >>
> >>> We need to distinguish among blockers and non-blockers in that list. E.g.,
> >>> "fails to run with perl 5.26" is a blocker, but "uses a deprecated 
> >>> feature" is
> >>> not. 
> >>
> >> Just for clarification, most of the bugs which have "deprecated" in
> >> the title will fail to run with 5.26; IOW: the warnings are from
> >> 5.24, and in 5.26 the issues become fatal.
> > 
> > I've retitled those bugs would could be confusing in this regard. I
> > believe that all the bugs which severity: important are the ones which
> > would become RC when we decide we want to start soon.
> > 
> > Noting for completeness that Niko has added the other lockers on
> > architecture: all related FTBFS bugs as requested by Emilio.
> 
> Thanks. Please go ahead and bump them to severity:serious as we are close to
> doing this.

Thanks, done.
-- 
Niko

Bug#868328: libtinfo5: ABI break: _nc_read_entry symbol dropped

[Sven Joachim]

On 2017-07-14 18:57 +0200, Sven Joachim wrote:

> On 2017-07-14 16:13 +0200, Sven Joachim wrote:
>
>> The symbol _nc_read_entry got inadvertently dropped in favor of
>> _nc_read_entry2, and this breaks reverse dependencies (ncurses-bin
>> before 6.0+20170701-1 and tack):
>
> This happened because _nc_read_entry is only compiled in if
> NCURSES_EXT_NUMBERS is #defined and not 0.  There's probably a good reason
> for this, since when I take out this condition infocmp from stretch
> segfaults.
>
> Bringing back the previous implementation of _nc_read_entry instead
> seems to work, as in the attached patch.  While this might to be good
> enough for Debian, upstream likely want a better solution that works
> with other configure flags as well.

Another point interesting for upstream here, although it does not affect
the current Debian package: even when building --with-abi-version=6
(i.e. the default), _nc_read_entry is still missing from the tinfo
library unless --enable-widec is also given.

That happens because NCURSES_EXT_NUMBERS is only #defined as 1 in
curses.priv.h if NCURSES_EXT_COLORS is also not 0, but for the non-wide
build it will be 0.

Sven

Bug#866692: stretch-pu: package linux-latest/80+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2017-07-13 at 11:58 +0100, Adam D. Barratt wrote:
> On 2017-07-13 11:56, Ben Hutchings wrote:
> > On Thu, 2017-07-13 at 07:42 +0100, Adam D. Barratt wrote:
> [...]
> >> If this is going to make it into 9.1, it needs to be uploaded _and
> >> through NEW_ by the weekend.
> > 
> > I can upload straight away if you're satisfied by the answers I just
> > sent.
> 
> Yes, thanks.

It's now out of NEW and built on all architectures.

Regards,

Adam

Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3

[Jochen Sprickerhof]

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

Hi,

please rebuild Ceres against the current Eigen3 version, as it encodes the
version in the CeresConfig.cmake and makes Google Cartographer to file in cmake
with:

CMake Error at /usr/lib/cmake/ceres/CeresConfig.cmake:88 (message):
  Failed to find Ceres - Found Eigen dependency, but the version of Eigen
  found (3.3.4) does not exactly match the version of Eigen Ceres was
  compiled with (3.3.2).  This can cause subtle bugs by triggering violations
  of the One Definition Rule.  See the Wikipedia article
  http://en.wikipedia.org/wiki/One_Definition_Rule for more details

Thanks!

Jochen

nmu ceres-solver_1.12.0+dfsg0-1+b3 . ANY . unstable . -m "Rebuild against new 
libeigen3-dev"

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#868268: initramfs-tools: Please add raid1 to the module added when MODULES=most

[Ben Hutchings]

Control: reassign -1 lvm2

On Fri, 2017-07-14 at 21:09 +0200, Jean-Yves LENHOF wrote:
> Le 14/07/2017 à 15:01, Ben Hutchings a écrit :
[...]
> > Is dmraid installed on this system, or only dmsetup and lvm2?  I'm a
> > bit puzzled as to how raid1 is being set up.
> > 
> > Ben.
> 
> Hi,
> 
> Only dmsetup and lvm2
> I've created the server just for the test with virt-manager
> Just after being installed I did transform the logical volume to have it
> mirrored with this command :
> lvconvert -m 1 --type raid1 /dev/VGroot/LVslash
[...]
> I think the hook script which need to be changed to add raid1 module is
> /usr/share/initramfs-tools/hooks/lvm2 (in the 3 last lines)
[...]

Yes, something like that.  Reassigning this to lvm2.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.



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

Bug#846009: look for FIX_MEs in control and copyright created by npm2deb

[Chris Lamb]

Hi Bastien,

> >   
> > https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=7319953bad3ae5e0e15f778a7ed19dd20241b77c
> 
> Did you consider to use the sliding windows algo ?

Thanks for your review. Whilst I am aware of such algorithms, could you
elaborate on what you mean in concrete terms here?


Regards,

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

Bug#868354: fresh upstream (2.7.4) is out and fixes a number of issues we need resolved

[Yaroslav Halchenko]

oh -- since package is now under DPMT, I guess I will just take care
about updating it

Cheers,

On Fri, 14 Jul 2017, Yaroslav Halchenko wrote:

> Source: python-whoosh
> Version: 2.7.0-2
> Severity: normal

> Thanks for packaging/maintaining whoosh!

> We decided to use it for the datalad project (already in debian) but version 
> in
> Debian currently lacks some fixes we need.  Would be appreciated to get up to
> date release in.

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#868342: (no subject)

[Gianfranco Costamagna]

forcemerge 868342 868290
thanks



signature.asc
Description: OpenPGP digital signature

Bug#864736: [Pkg-shadow-devel] Bug#864736: shadow: [INTL:nl] Dutch po file for the shadow package

[Serge E. Hallyn]

Thanks, I see it went through some review at 

https://lists.debian.org/debian-l10n-dutch/2017/06/msg00055.html

so happy to take it in the upstream package.  Would you like to
post a pull request at github.com/shadow-maint/shadow, or would
you prefer that I post the file for you?

Bug#868268: initramfs-tools: Please add raid1 to the module added when MODULES=most

[Jean-Yves LENHOF]

Le 14/07/2017 à 15:01, Ben Hutchings a écrit :
> Control: tag -1 moreinfo
>
> On Thu, 2017-07-13 at 23:57 +0200, Jean-Yves LENHOF wrote:
>> Package: initramfs-tools
>> Version: 0.130
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> When using raid1 lvm root, the raid1 module is not added to the initrd
>> built (raid456 module is in).
>> This will make the system unbootable and goind to the initramfs debug mode
>> Please add raid1 in when selecting MODULES=most
> [...]
>
> initramfs-tools doesn't add layered device drivers itself, because it
> requires special tools to set them up.  The packages containing those
> tools should install hooks that add both drivers and tools to the
> initramfs.
>
> Is dmraid installed on this system, or only dmsetup and lvm2?  I'm a
> bit puzzled as to how raid1 is being set up.
>
> Ben.

Hi,

Only dmsetup and lvm2
I've created the server just for the test with virt-manager
Just after being installed I did transform the logical volume to have it
mirrored with this command :
lvconvert -m 1 --type raid1 /dev/VGroot/LVslash
After wait for the copy to be made in background. (Watching with the
command lvs the progress)
When the copy is made reboot.
The system is unbootable and go to initramfs shell

I did not know for hooks, and I think in fact you were right
Perhaps this bug should be reaffected to the lvm2 package
I think the hook script which need to be changed to add raid1 module is
/usr/share/initramfs-tools/hooks/lvm2 (in the 3 last lines)

Regards,

JYL

Bug#868353: samba-libs dependencies broken in jessie debian-security repo

[Kay]

I have the problem after apt-get upgrade samba is removed and reinstall is not possible!

 

sources.list


deb http://security.debian.org/debian-security jessie/updates main contrib non-free
deb-src http://security.debian.org/debian-security jessie/updates main contrib non-free

deb http://ftp.debian.org/debian/ jessie main contrib non-free
deb-src http://ftp.debian.org/debian/ jessie main contrib non-free


cat debian_version

8.8

 


apt-get install samba
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 samba : Hängt ab von: python-samba soll aber nicht installiert werden
 Hängt ab von: samba-common-bin (= 2:4.2.14+dfsg-0+deb8u7) soll aber nicht installiert werden
 Hängt ab von: samba-dsdb-modules soll aber nicht installiert werden
 Hängt ab von: samba-libs (= 2:4.2.14+dfsg-0+deb8u7) soll aber nicht installiert werden
 Empfiehlt: samba-vfs-modules soll aber nicht installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.



 


apt-cache policy samba
samba:
  Installiert:   (keine)
  Installationskandidat: 2:4.2.14+dfsg-0+deb8u7
  Versionstabelle:
 2:4.2.14+dfsg-0+deb8u7 0
500 http://security.debian.org/debian-security/ jessie/updates/main amd64 Packages
 2:4.2.14+dfsg-0+deb8u6 0
100 /var/lib/dpkg/status
 2:4.2.14+dfsg-0+deb8u5 0
500 http://ftp.debian.org/debian/ jessie/main amd64 Packages

 

 

 

Bug#868290: (no subject)

[Gianfranco Costamagna]

control: forcemerge -1 868290
thanks



signature.asc
Description: OpenPGP digital signature

Bug#868354: fresh upstream (2.7.4) is out and fixes a number of issues we need resolved

[Yaroslav Halchenko]

Source: python-whoosh
Version: 2.7.0-2
Severity: normal

Thanks for packaging/maintaining whoosh!

We decided to use it for the datalad project (already in debian) but version in
Debian currently lacks some fixes we need.  Would be appreciated to get up to
date release in.

Thanks in advance

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-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#868179: xserver-xorg-video-radeon: SEGV when starting X11

[bartek 'basz' szurgot]

On 07/14/2017 04:04 AM, Michel Dänzer wrote:
> Indeed, my bad. The corresponding radeon commit is
> https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=4c91f36d3058180b5a2d6a23e9b82f5c933d8716


ok - thanks. :) knowing the exact conditions under which SEGV occurs
(i.e. rotated screen in xorg.conf), i agree it is not a "grave" bug.

when the fix is expected to arrive to the xserver-xorg-video-radeon
package in Debian-testing?

-- 
pozdrawiam serdecznie / best regards,
bartek 'basz' szurgot
/* https://www.baszerr.eu */
/* https://www.baszerr.eu/lib/exe/fetch.php/about_me/basz_pub_key.txt */




signature.asc
Description: OpenPGP digital signature

Bug#862961: jessie-pu: package libembperl-perl/2.5.0-4+deb8u1

[gregor herrmann]

On Thu, 13 Jul 2017 13:05:31 +0200, Axel Beckert wrote:

> Cyril Brulebois wrote:
> > gregor herrmann  (2017-06-28):

> > > #v+
> > > --- a/debian/zembperl.load.in
> > > +++ b/debian/zembperl.load.in
> > > @@ -1,6 +1,6 @@
> > >  # The sucky "zembperl" name is so we load after perl
> > > 
> > > -# Depends: perl
> > > +# Recommends: perl
> > > 
> > >  
> > >LoadModule embperl_module @ARCHLIB@/auto/Embperl/Embperl.so
> > > #v-
> > > 
> > > 
> > > I've now tentatively changed d/changelog to say
> > > 
> > > #v+
> > >   * Change hard dependency on mod_perl in zembperl.load to Recommends.
> > > mod_perl is not required, and is enabled by default anyway if it is
> > > installed.
> > > This change matches the package dependencies and fixes an installation
> > > failure when libapache2-mod-perl2 is not installed.
> > > (Closes: #810655)
> > > #v-
> > > 
> > > 
> > > Does this make sense?
> > 
> > I think the situation is clearer with your explanations above, and the
> > changes+changelog look in sync and reasonable.
> 
> *nod* Looks fine to me, too.

Thanks Axel for checking and confirming!
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Frank Zappa: Theme from RUN HOME SLOW


signature.asc
Description: Digital Signature

Bug#868353: smaba-libs dependencies broken in jessie debian-security repo

[Moritz Schneider]

Package: samba-libs
Version: 2:4.2.14+dfsg-0+deb8u7
Severity: critical

Hi,

the last added pacakage of the samba-libs in the debian-security repo for
jessie depends on libgnutls30, which isn't available in jessie (see here: 
https://packages.debian.org/jessie/samba-libs).
This can lead to situations where user can't login to their machines.


Kind regards
Moritz Schneider

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

Bug#851130: [debhelper-devel] Bug#851130: Bug#851130: debhelper: dh runs dh_quilt_patch after dh_autoreconf in compat 10

[gregor herrmann]

On Thu, 16 Mar 2017 20:40:59 +0100, Sven Joachim wrote:

> > On Thu, Jan 12, 2017 at 06:11:00PM +, Niels Thykier wrote:
> >> Control: reassign -1 quilt
> >> Control: retitle -1 quilt: Update dh-sequence module
> >> 
> >> Hi Martin and Ryan,
> >> 
> >> Please update your debhelper sequence (quilt.pm) to use:
> >> 
> >> """
> >> insert_before("dh_update_autotools_config", "dh_quilt_patch");
> >> """
>  
> >> This requires a dependency on debhelper (>= 9.20160114)
> 
> I don't see why this is necessary, because insert_before just seems to
> be a no-op if the first argument is not present in the sequence, 

I think, and Niels just confirmed on IRC, that he meant to _replace_
 insert_before("dh_auto_configure", "dh_quilt_patch");
with
 insert_before("dh_update_autotools_config", "dh_quilt_patch");
instead of adding the latter, and then the dependency would be
required on the first debhelper version which has
dh_update_autotools_config.

> but I
> must admit that I haven't tested with Jessie's debhelper version.

Just tried: jessie chroot, /usr/share/perl5/Debian/Debhelper/Sequence/quilt.pm
with your patch:

# dh $@ --with quilt --no-act build  
   dh_testdir
   dh_quilt_patch
   dh_auto_configure
   dh_auto_build
   dh_auto_test

The same in stretch:

# dh $@ --with quilt --no-act build
dh: Compatibility levels before 9 are deprecated (level 7 in use)
   dh_testdir
   dh_quilt_patch
   dh_update_autotools_config
   dh_auto_configure
   dh_auto_build
   dh_auto_test
   create-stamp debian/debhelper-build-stamp

So it looks like the patch works indeed with "old" and "new
debhelper. In that case we don't need the dependency.

(I'd probably add a comment to the code why there are now 2
insert_before; a pointer to this bug e.g. :))


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Johnny Cash: In My Life


signature.asc
Description: Digital Signature

Bug#868351: RFA: classic-theme-restorer -- customize the new Firefox interface

[Sean Whitton]

Package: wnpp
Severity: normal

I request an adopter for the classic-theme-restorer package.

Upstream has a tendency to include new image files without indicating
the source, and in the latest upstream release I believe that at least
one of the files is non-free.  I no longer have time to do the work
needed to reconcile d/copyright with each new upstream release.

This is a team-maintained package, so it would be best if the adoptor
replaced me in Uploaders:, but they could also take the package out of
the team's hands.

It is also worth noting that upstream believes it will never be possible
to port this addon to the new WebExtensions API.  If Mozilla goes ahead
with its plans, this addon will not be usable with any version of
Firefox in Debian before the end of stretch's non-LTS support cycle.

The package description is:
 Classic Theme Restorer allows restoration of squared tabs,
 tabs-not-on-top, the app menu, the add-on bar, small button view and
 more.
 .
 Such elements were removed in Mozilla's Australis redesign of Firefox.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#868352: linux: Please enable USB_SERIAL_CONSOLE

[Sascha Silbe]

Source: linux
Version: 4.11.6-1
Severity: normal

Dear Maintainer,

on some amd64 systems no native or PCI(e) serial ports are available
resp. possible. USB serial adapters are the only option to get a
serial console for debugging boot problems in this case. Unfortunately
the Debian amd64 kernels are built with USB_SERIAL_CONSOLE unset
(because USB_SERIAL is not built-in) so even that option isn't
available. When the BIOS text mode isn't working (e.g. high-res
monitor with a BIOS that only supports up to FullHD) one is left
without any working console device.

So please enable USB_SERIAL_CONSOLE (requires USB_SERIAL=y) for future
kernels and consider setting one of the USB serial adapter drivers to
built-in as well so that it's available before module loading. But
even just USB_SERIAL_CONSOLE alone (with all USB serial drivers as
modules) is likely better than the current situation; AFAICT the USB
serial console should get activated as soon the the USB serial driver
is loaded (haven't tested it, though).

Sascha

-- System Information:
Debian Release: 8.8
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'oldstable-updates'), (100, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#868311: Missing documentation

[Francesco P. Lovergine]

I know that, that's just for meno 

Il 14 luglio 2017 17:43:36 CEST, Sebastiaan Couwenberg  ha 
scritto:
>Control: tags -1 pending
>
>Hi Francesco,
>
>On 07/14/2017 01:35 PM, Francesco Paolo Lovergine wrote:
>> The GDAL Perl bindnig is missing the full doxygen documentation
>available
>> here: http://arijolma.org/Geo-GDAL/2.2/index.html. That should be
>integrated
>> into the package to allow developers being independent on the online
>doc.
>
>You're still listed among the Uploaders, you were most welcome to
>contribute these changes yourself.
>
>I've updated the package to also build & install the Doxygen docs and
>include them in libgdal-perl.
>
>Kind Regards,
>
>Bas
>
>-- 
> GPG Key ID: 4096R/6750F10AE88D4AF1
>Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
Francesco P. Lovergine

Bug#868350: xserver-xorg-core: X server segfaults on startup after upgrade to xserver-xorg-core 2:1.16.4-1+deb8u1

[Joe Dennigan]

Package: xserver-xorg-core
Version: 2:1.16.4-1+deb8u1
Severity: important

Dear Maintainer,

* What led up to the situation?
  Upgraded xserver-xorg-core (and xserver-common) from 2:1.16.4-1 to
  2:1.16.4-1+deb8u1

* What exactly did you do (or not do) that was effective (or
  ineffective)?
  Downgraded xserver-xorg-core (xserver-common) from 2:1.16.4-1+deb8u1
  back to 2:1.16.4-1
  
* What was the outcome of this action?
  I now have a working X server again.

As reportbug has appended the latest Xorg.0.log from a working
installation, here are the last few lines (the only relevant
differences that I can see) from the log of the last crashed X session
before I downgraded the packages:

[46.392] (II) intel(0): Allocated new frame buffer 1920x1848 stride 7680, 
tiled
[52.301] (EE) 
[52.301] (EE) Backtrace:
[52.332] (EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x5648f4d11b46]
[52.332] (EE) 1: /usr/bin/X (0x5648f4b59000+0x1bcd29) [0x5648f4d15d29]
[52.333] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7ffb5974+0x350e0) 
[0x7ffb597750e0]
[52.333] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (0x7ffb5974+0x91d8a) 
[0x7ffb597d1d8a]
[52.333] (EE) 4: /usr/bin/X (0x5648f4b59000+0xc1a38) [0x5648f4c1aa38]
[52.333] (EE) 5: /lib/x86_64-linux-gnu/libdbus-1.so.3 
(dbus_connection_dispatch+0x3f1) [0x7ffb5b83a1d1]
[52.333] (EE) 6: /lib/x86_64-linux-gnu/libdbus-1.so.3 
(0x7ffb5b82a000+0x10425) [0x7ffb5b83a425]
[52.333] (EE) 7: /usr/bin/X (0x5648f4b59000+0xbb619) [0x5648f4c14619]
[52.333] (EE) 8: /usr/bin/X (WakeupHandler+0x6b) [0x5648f4bb57fb]
[52.333] (EE) 9: /usr/bin/X (WaitForSomething+0x1c3) [0x5648f4d0edf3]
[52.333] (EE) 10: /usr/bin/X (0x5648f4b59000+0x57931) [0x5648f4bb0931]
[52.333] (EE) 11: /usr/bin/X (0x5648f4b59000+0x5bcb6) [0x5648f4bb4cb6]
[52.333] (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) 
[0x7ffb59761b45]
[52.333] (EE) 13: /usr/bin/X (0x5648f4b59000+0x4602e) [0x5648f4b9f02e]
[52.333] (EE) 
[52.333] (EE) Segmentation fault at address 0x0
[52.334] (EE) 
Fatal server error:
[52.334] (EE) Caught signal 11 (Segmentation fault). Server aborting
[52.334] (EE) 
[52.334] (EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
[52.334] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.
[52.334] (EE) 
[52.334] (II) AIGLX: Suspending AIGLX clients for VT switch
[52.875] (EE) systemd-logind: ReleaseControl failed: Did not receive a 
reply. Possible causes include: the remote application did not send a reply, 
the message bus security policy blocked the reply, the reply timeout expired, 
or the network connection was broken.
[52.875] (EE) Server terminated with error (1). Closing log file.

Do you want/need a bug report for the complementary package
xserver-common?  All the details are the same, only the name changes.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Jan  5  2017 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2401376 Feb 11  2015 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 

Bug#868336: scummvm: crash during a game

[Stephen Kitt]

Control: forcemerge 864892 868336

On Fri, 14 Jul 2017 17:24:05 +0200, Francesco
 wrote:
> As soon as a game is run, the program crash without a reason.

Could you provide a little more detail? Which games have you tried? If you
run scummvm from a terminal window, does it provide any more information?

Regards,

Stephen


pgpnKlOaMb7Br.pgp
Description: OpenPGP digital signature

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Istvan Kuklin]

Hello there,



I'm affected with this as well. I've just run into this issue with a testing 
virtual machine. It looks like to me that it is also the cause of mate-panel 
not starting up along with dconf not being able to create a database in case of 
a user with AFS home directory. Speaking of it, it does not sound that good to 
allow anyone to look up the directory tree of this user because of that symlink 
to that service. If it helps maybe I can keep that vm to collect some logs, 
debug things, etc. I'm happy to hear about a better solution if there will be 
any :)



István

Bug#867192: [Pkg-dns-devel] Bug#867192: Bug#867192: Bug#867192: Bug#867192: let systemd know about the pid file

[Robert Edmonds]

Daniel Kahn Gillmor wrote:
> On Fri 2017-07-14 12:32:57 -0400, Robert Edmonds wrote:
> > So we either need to configure systemd to delete Unbound's pidfile, or
> > we could develop and contribute a patch upstream that allows overriding
> > the pidfile via the command-line.
> 
> ok, how about something like this:
> 
> https://github.com/NLnetLabs/unbound/pull/1

Hm, that could work (but then we have to carry around "-p" in the
service unit forever). I was thinking of a command-line parameter that
takes an argument to the pidfile path (like "-p /run/unbound.pid") that
takes precedence over the 'pidfile' value from the config file and the
compiled in 'pidfile' default value. And then we set the default value
for 'pidfile' to "" so that Unbound doesn't make a pidfile by default,
and append "-p /run/unbound.pid" to $DAEMON_OPTS in /etc/init.d/unbound.

BTW, I don't think upstream really monitors that GitHub repository, it's
a git-svn mirror. Posting patches to the mailing list or bugzilla seems
to be their thing.

-- 
Robert Edmonds
edmo...@debian.org

Bug#861174: RFP: elpa-elpy -- Emacs Python Development Environment

[Antoine Beaupré]

On 2017-07-12 11:14:40, Nicholas Steeves wrote:
> On 26 April 2017 at 21:55, Antoine Beaupré  wrote:
>> On 2017-04-26 21:26:33, Nicholas Steeves wrote:
>>> By the way, what kind of a timeline do you have in mind?
>>
>> I'm away for a month, so no rush. :)
>
> Hi Antoine,
>
> If you have time could you please sponsor #863216, which is indirectly
> blocking #861242, which is blocking this bug?  I've been waiting for
> sponsorship for almost a month and would like to resume progress
> towards fulfilling the prerequisites for your RFPs.

No time right now, unfortunately. But maybe we could review this during
the debcamp early august! :)

a.

-- 
No animal has more liberty than the cat; but it buries the mess it
makes. The cat is the best anarchist. Until they learn that from the cat
I cannot respect them.
- For whom the bell tolls, Ernest Hemingway

Bug#866643: jessie-pu: package init-select/1.20140921+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2017-07-10 at 01:59 +0200, Andreas Beckmann wrote:
> Control: tag -1 - moreinfo
> 
> On 2017-07-01 02:32, Cyril Brulebois wrote:
> > Andreas Beckmann  (2017-06-30):
> >> init-select contains a grub config snippet that unconditionally runs a
> >> command, which will cause failures (in update-grub and friends) if
> >> init-select was removed but not purged.
> >> This was noticed on jessie->stretch upgrades of coreboot where
> >> init-select was installed in jessie (but gets removed during the upgrade
> >> to stretch).
> 
> > I accidentally noticed a thread on debian-ctte@ about this. It would be
> > helpful to have a summary of what was agreed on there, and to make sure
> > grub people are in the loop.
> 
> Discussion over there has ceased.
> To summarize it in one sentence:
>   grub is encouraged to claim ownership of that conffile and take the
>   neccessary measures to fix this bug on upgrades to stretch.
> 
> I havent heard of any progress on the grub side ...
> but since it is also reproducible in plain jessie (the neccessary
> sequence is just not covered by the default piuparts tests), let's fix
> init-select in jessie, too.

That seems a reasonable idea from my reading of the TC discussion.

Regards,

Adam

Bug#868169: [debhelper-devel] Bug#868169: debhelper regression: virtualbox-dkms: Fail to build (kernel 4.1.42)

[Niels Thykier]

clone 868169 -1
retitle -1 virtualbox: Needs rebuild against debhelper/10.6.4
reassign -1 virtualbox-dkms
found -1 5.1.22-dfsg-3
severity -1 grave
blocked -1 by 868169
thanks


On Thu, 13 Jul 2017 22:01:40 + (UTC) Gianfranco Costamagna
 wrote:
> Hello Niels,
> 
> >I believe this will be fixed by [50366a30], which I have to pushed to
> >master.  I would be happy if you can confirm this.
> 
> 
> 
> find . -name hm_vmx.h
> ./out/bin/src/vboxdrv/include/VBox/vmm/hm_vmx.h
> ./include/VBox/vmm/hm_vmx.h
> ./debian/virtualbox-dkms/usr/src/virtualbox-5.1.22/include/VBox/vmm/hm_vmx.h
> 
> I would say yes, this fixed the issue!
> 
> thanks a lot!
> 
> G.
> 
> 

Excellent, I have uploaded debhelper/10.6.4, which should fix this.

Unfortunately, virtualbox-dkms/5.1.22-dfsg-3 is arch:all and therefore
cannot be binNMU'ed, so you will need to do an upload of virtualbox to
rebuild virtualbox-dkms.  Please B-D on dehelper/10.6.4 to ensure that
you get the proper version if you use source-only uploads.

Thanks,
~Niels

Bug#867935: Done upstream

[Dominique Dumont]

This change has been done upstream. A new version of Pan should been released 
soon(-ish).

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#868348: unresolved dependencies of packet samba-common-bin in Debian Jessie

[Christian Kuhn]

Package: samba-common-bin

Version:   2:4.2.14+dfsg-

 

 

Hello,

 

since few minutes and after an ,apt-get update' I cannot longer install
samba (Debian Jessie) with aptitude over network installation from a Debian
mirror, because I get an error about unresolved dependencies of packet
,samba-common-bin':

 

+ samba-common-bin depends from libncurses(>= 6)
[NOT AVAILABLE]

+ samba-common-bin depends from libreadline7   (>= 6.0)
[NOT AVAILABLE]

+ samba-common-bin depends from libtinfo5(>= 6)
[NOT AVAILABLE]

 

This error occurs since few minutes after an ,apt-get update' execution over
network in Debian Jessie.

 

 

Best regards,

Christian

 

Bug#867192: [Pkg-dns-devel] Bug#867192: Bug#867192: Bug#867192: let systemd know about the pid file

[Daniel Kahn Gillmor]

On Fri 2017-07-14 12:32:57 -0400, Robert Edmonds wrote:
> Unfortunately, we have to continue supporting the sysvinit script (the
> only plausible "compelling reason" to remove the sysvinit script per
> #746715 I can think of would be the removal of sysvinit itself from the
> archive), and the only way to configure Unbound's 'pidfile' parameter is
> via the config.

ah, i see. :(

> So we either need to configure systemd to delete Unbound's pidfile, or
> we could develop and contribute a patch upstream that allows overriding
> the pidfile via the command-line.

ok, how about something like this:

https://github.com/NLnetLabs/unbound/pull/1

--dkg

Bug#868347: sagemath-common: /usr/share/sagemath/bin/sage-native-execute: firefox:elinks:w3m: not found

[Rogério Brito]

Package: sagemath-common
Version: 7.6-2
Severity: important
File: /usr/share/sagemath/bin/sage-native-execute


Hi,

It seems that sage-native-execute doesn't respect the way that the BROWSER
variable is set according to the sensible-browser way of working with
colon-delimited values.

This breaks the notebook() function of the interpreter of sage.


Thanks,

Rogério.


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

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

Versions of packages sagemath-common depends on:
ii  python 2.7.13-2
ii  python2.7  2.7.13-2

sagemath-common recommends no packages.

sagemath-common suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#868282: virtualbox-dkms: kernel modules fail to build due to missing files

[GM]

I can also confirm. It should be mark as critical.


--
Regards
Gregory

Bug#868344: stretch-pu: package gnome-settings-daemon/3.22.2-2+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2017-07-14 at 19:00 +0200, Laurent Bigonville wrote:
> When a new user is login-in for the first time, g-s-d will add by
> default the machine keyboard layout but also the US one.
> 
> The problem is that on the 1st login, for some reason the layout will be
> set on US and not on the machine one. This is bug #859268.
> 
> A patch that is only adding the US layout if the system configured one
> cannot be determined has been merged upstream.
> 
> This should probably be fixed in stable as well.

Yes, please.

(Bearing in mind that the upload window for 9.1 closes this weekend.)

Regards,

Adam

Bug#868338: DVD Install

[Charles Chambers]

It's older - an Optiplex GX620 Midtower.  I think it boots only with BIOS.

On Fri, Jul 14, 2017 at 8:54 AM, Steve McIntyre  wrote:

> Hi Charles,
>
> On Fri, Jul 14, 2017 at 08:49:54AM -0700, Charles Chambers wrote:
> >
> >
> >Package: installation-reports
> >
> >Boot method: 
> >Image version: Debian-9.0.0-amd64-DVD-1
> >Date: <7/3/17 @ 06:00>
> >
> >Machine: 
> >Processor:  Dual Pentium 3.00 ghz
> >Memory: 2gb
> >Partitions: 
> >Base System Installation Checklist:
> >[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> >
> >
> >Initial boot:   [ E]
> >
> >I'm still attempting an offline installation.  I'm connecting up a //
> Gear Head
> >8X DVD Mobile Slim External Drive 8XDVDEXT // to an installed system,
> cycling
> >the drive to insert the first DVD, and then connecting the USB DVD drive
> to the
> >target computer and attempting to boot the computer to the USB Device.
> >
> >It worked fine on the earlier versions of Debian 8.x.  Now, the drive
> reads the
> >DVD, but doesn't recognize it as bootable media.  The computer doesn't
> give me
> >the option to boot to USB Device.
>
> Is your computer set up to boot via BIOS or UEFI? If the latter, have
> you disabled Secure Boot?
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> "... the premise [is] that privacy is about hiding a wrong. It's not.
>  Privacy is an inherent human right, and a requirement for maintaining
>  the human condition with dignity and respect."
>   -- Bruce Schneier
>
>


-- 
Charlie
ccha...@gmail.com

Bug#868346: python-pocketsphinx: Python doesn't recognize that a version of pocketsphinx is installed

[Ethan Ward]

Package: python-pocketsphinx
Version: 0.8+5prealpha-2
Severity: important

When I install python-pocketsphinx, python doesn't recognize that a version of 
pocketsphinx is installed.
Although the package still works - I can import and use pocketsphinx fine - it 
causes issues when other python libraries
depend on the package, as it tries to find the package but won't run because it 
doesn't recognize the package as installed.
I think that this is related to not having a, for example, 
pocketsphinx-0.8.egg_info/ directory with a PKG-INFO file
and other related informational files. However, I'm not entirely sure.

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

Kernel: Linux 2.6.32-5-686 (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

Bug#868345: Progress should be shown when using apt-transport-https

[Jason Self]

Package: apt-transport-https
Version: 1.0.1
Severity: minor

I've noticed that visible download progress is not shown in apt (sudo apt 
full-upgrade for example) when using a repository over HTTPS (after 
installing apt-transport-https.)

The download is successful but the indicator remains at 0% (or at 
whatever percent it was when it started downloading from the HTTPS repo, 
in cases where the upgrade process had first downloaded packages from 
other repos before moving on to the HTTPS one.)

The usual things like rate of speed and time remaining do not get 
displayed, resulting in the appearance that it's hung. Examining activity 
does show it's indeed downloading though, just not displaying anything.

To reproduce it:
Install apt-transport-https.
Configure the package manager to use a repo over HTTPS.
Install a package.
Watch as no progress is shown but it is downloaded successfully and the 
normal installation process happens.
Later, remove the package & do apt-get clean so that .deb so that it has 
to be downloaded again.
Edit sources.list and replace https with http and install the package 
again.
Notice that things like rate of speed and time remaining are displayed, 
while they were not previously. The only difference being the use of http 
vs https.

Bug#258096: "hi"

[Col. Geoff Woods]

My name is Col. Woods of US army and i have a confidential matter of financial 
mutual benefit to discuss with you, please reply if you are interested

Col. Geoff Woods