Bug#879629: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2017c

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2017-10-23 at 19:39 +0200, gregor herrmann wrote:
> I've prepared an update for libdatetime-timezone-perl in stretch
> which
> incorporates the changes from the Olson db 2017c release.
> The changes are in a quilt patch and touch only the data files in
> lib/DateTime/TimeZone.
> 
> 2017c contains recent changes to a couple of timezones, the first
> change happening this weekend (2017-10-29) in North Cyprus, so this
> might be material for stretch-updates before a next point release.
> Cf. https://mm.icann.org/pipermail/tz-announce/2017-October/47.ht
> ml
> 

Please go ahead.

We'll look at -updates later in the week, most likely once it's clearer
what's happening with tzdata uploads for the new version.

Regards,

Adam

Bug#879630: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2017c

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2017-10-23 at 19:39 +0200, gregor herrmann wrote:
> I've prepared an update for libdatetime-timezone-perl in jessie which
> incorporates the changes from the Olson db 2017c release.
> The changes are in a quilt patch and touch only the data files in
> lib/DateTime/TimeZone.
> 
> 2017c contains recent changes to a couple of timezones, the first
> change happening this weekend (2017-10-29) in North Cyprus, so this
> might be material for jessie-updates before a next point release.
> Cf. https://mm.icann.org/pipermail/tz-announce/2017-October/47.ht
> ml
> 

Please go ahead.

We'll look at -updates later in the week, most likely once it's clearer
what's happening with tzdata uploads for the new version.

Regards,

Adam

Bug#879662: apt: debian-installer FTBFS: E: Method copy has died unexpectedly!

[Cyril Brulebois]

Package: apt
Version: 1.4.8
Severity: serious
Tags: d-i
Justification: FTBFS

[ Please keep both debian-boot@ and me in copy. ]

It seems the “most secure file downloading on the planet” can no longer
copy files around:
| get-packages udeb  
| make[5]: 'sources.list.udeb' is up to date.
| Ign:1 copy:/home/kibi/debian-installer/installer/build localudebs/ InRelease
| Ign:2 copy:/home/kibi/debian-installer/installer/build localudebs/ Release
| Ign:3 copy:/home/kibi/debian-installer/installer/build localudebs/ Packages
| Ign:4 copy:/home/kibi/debian-installer/installer/build localudebs/ 
Translation-en
| Ign:5 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(deb)
| Ign:6 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(deb)
| Ign:7 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(udeb)
| Get:8 http://localhost/debian unstable InRelease [235 kB]
| Ign:9 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(udeb)
| Ign:3 copy:/home/kibi/debian-installer/installer/build localudebs/ Packages
| Ign:4 copy:/home/kibi/debian-installer/installer/build localudebs/ 
Translation-en
| Ign:5 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(deb)
| Ign:6 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(deb)
| Ign:7 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(udeb)
| Ign:9 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(udeb)
| Ign:3 copy:/home/kibi/debian-installer/installer/build localudebs/ Packages
| Ign:4 copy:/home/kibi/debian-installer/installer/build localudebs/ 
Translation-en
| Ign:5 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(deb)
| Ign:6 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(deb)
| Ign:7 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(udeb)
| Ign:9 copy:/home/kibi/debian-installer/installer/build localudebs/ Contents 
(udeb)
| Reading package lists...
| E: Method copy has died unexpectedly!
| E: Sub-process copy received signal 31.

Error reporting is a bit underwhelming. :(

This happens with this sources.list file:
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer/build$ cat 
sources.list.udeb 
| # This file is automatically generated, edit sources.list.udeb.local instead.
| deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/ 
localudebs/
| deb http://localhost/debian unstable main/debian-installer

This can be reproduced on all archs by triggering a daily build in the
debian-installer directory, in a sid chroot:
| cd build && ./daily-build build-only


KiBi.

Bug#879661: lintian: Fail to process ser-player due to invalid XML

[Niels Thykier]

Package: lintian
Version: 2.5.55
Severity: important

Spotted on lindsay.d.o:

"""
N: 
N: Processing binary package ser-player (version 1.7.0-2, arch amd64) ...
/srv/lintian.debian.org/scratch/temp-lintian-lab-x6W9jEpWMx/pool/s/ser-player/ser-player_1.7.0-2_amd64_binary/unpacked/usr/share/metainfo/com.google.sites.ser-player.appdata.xml:23:
 parser error : Opening and ending tag mismatch: screenshots line 13 and 
component

^
/srv/lintian.debian.org/scratch/temp-lintian-lab-x6W9jEpWMx/pool/s/ser-player/ser-player_1.7.0-2_amd64_binary/unpacked/usr/share/metainfo/com.google.sites.ser-player.appdata.xml:24:
 parser error : Premature end of data in tag component line 2

^
XML::Simple called at 
/srv/lintian.debian.org/lintian/checks/appstream-metadata.pm line 91.
internal error: cannot run appstream-metadata check on package 
binary:ser-player/1.7.0-2/amd64
warning: skipping check of binary:ser-player/1.7.0-2/amd64
N: 
"""

Looks like the appstream-metadata check is missing a guard for
handling invalid XML.

Thanks,
~Niels

Bug#879660: ITP: rabbitmq-java-client -- RabbitMQ Java client

[Christopher Hoskin]

Package: wnpp
Severity: wishlist
Owner: Christopher Hoskin 

* Package name: rabbitmq-java-client
  Version : 5.0.0
  Upstream Author : Pivotal Software, Inc. 
* URL : https://www.rabbitmq.com/java-client.html
* License : MPL-1.1, GPL-2+, Apache-2
  Programming Lang: Java
  Description : RabbitMQ Java client

The RabbitMQ Java client library allows Java code to interface with RabbitMQ.

The binary package will be named librabbitmq-client-java.

I plan to maintain it within the pkg-java team.

Christopher Hoskin

Bug#879659: installation-reports : Failed Installtion of debian-tesing

[Mayank Suman]

Package: installation-reports

Boot method: usb drive
Image version: 
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/debian-testing-amd64-DVD-1.iso
Date: 23 Oct, 2017

Machine: Dell Vostro 5459
Processor: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
Memory: 8GB
Partitions:
/dev/mapper/root_swap-root_wo_home btrfs137224192 4354704 131102864   4% /
/dev/sda2  ext4299192   39269239955  15% 
/boot
/dev/sda1  vfat315776 132315644   1% 
/boot/efi


Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM 
Registers [8086:1904] (rev 08)
Subsystem: Dell Skylake Host Bridge/DRAM Registers [1028:070b]
Kernel driver in use: skl_uncore
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 520 
[8086:1916] (rev 07)
Subsystem: Dell HD Graphics 520 [1028:070b]
Kernel driver in use: i915
Kernel modules: i915
00:04.0 Signal processing controller [1180]: Intel Corporation Skylake 
Processor Thermal Subsystem [8086:1903] (rev 08)
Subsystem: Dell Skylake Processor Thermal Subsystem [1028:070b]
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device
00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller [8086:9d2f] (rev 21)
Subsystem: Dell Sunrise Point-LP USB 3.0 xHCI Controller [1028:070b]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP 
Thermal subsystem [8086:9d31] (rev 21)
Subsystem: Dell Sunrise Point-LP Thermal subsystem [1028:070b]
Kernel driver in use: intel_pch_thermal
Kernel modules: intel_pch_thermal
00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP 
Serial IO I2C Controller #0 [8086:9d60] (rev 21)
Subsystem: Dell Sunrise Point-LP Serial IO I2C Controller [1028:070b]
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP 
CSME HECI #1 [8086:9d3a] (rev 21)
Subsystem: Dell Sunrise Point-LP CSME HECI [1028:070b]
Kernel driver in use: mei_me
Kernel modules: mei_me
00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-LP SATA 
Controller [AHCI mode] [8086:9d03] (rev 21)
Subsystem: Dell Sunrise Point-LP SATA Controller [AHCI mode] [1028:070b]
Kernel driver in use: ahci
Kernel modules: ahci
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.5 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root 
Port #6 [8086:9d15] (rev f1)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root 
Port #9 [8086:9d18] (rev f1)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-LP LPC Controller 
[8086:9d48] (rev 21)
Subsystem: Dell Sunrise Point-LP LPC Controller [1028:070b]
00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-LP PMC 
[8086:9d21] (rev 21)
Subsystem: Dell Sunrise Point-LP PMC [1028:070b]
00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio 
[8086:9d70] (rev 21)
Subsystem: Dell Sunrise Point-LP HD Audio [1028:070b]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel, snd_soc_skl
00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus [8086:9d23] (rev 
21)
Subsystem: Dell Sunrise Point-LP SMBus [1028:070b]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
01:00.0 3D controller [0302]: NVIDIA Corporation GM108M [GeForce 930M] 
[10de:1346] (rev a2)
Subsystem: Dell GM108M [GeForce 930M] [1028:070b]
Kernel driver in use: nouveau
Kernel modules: nouveau
02:00.0 Network controller [0280]: Intel Corporation Wireless 3165 [8086:3165] 
(rev 79)
Subsystem: Intel Corporation Wireless 3165 [8086:4410]
Kernel modules: iwlwifi
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit 
Ethernet controller [10ec:8168]
Kernel driver in use: r8169
Kernel modules: r8169

 Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[E]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:
initramfs-tool 0.130 failed to 

Bug#879658: debhelper's meson build system deletes the crossfile too early

[Helmut Grohne]

Package: debhelper
Version: 10.10.3
User: helm...@debian.org
Usertags: rebootstrap
Owner: ni...@thykier.net

Hi Niels,

this is the friendly reminder and summary following our irc discussion.
It turned out that debhelper's meson build system does not yet work for
cross compilation as can be seen when cross compiling systemd in
unstable at the moment.

dh_auto_build calls ninja, which calls "meson --internal regenerate",
which fails with "File not found: /tmp/meson-cross-file.0Cl4.conf." It
seems to expect the presence of the cross file during dh_auto_build (and
likely also dh_auto_install). In my poc patch for systemd[1], I simply
dumped the crossfile to the debian directory and never deleted it. That
worked.

Thank you for handling the issue.

Helmut

[1] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=859177;filename=systemd_234-2.1.debdiff;msg=42

Bug#879657: RFS: calamaris/2.99.4.5-2

[Daniel Echeverry]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: calamaris
   Version : 2.99.4.5-2
   Upstream Author : Cord Beermann
 * URL : http://www.Cord.de/~cord/tools/squid/calamaris/
 * License : GPL-2.0+
   Section : utils

It builds those binary packages:

calamaris  - log analyzer for Squid or Oops proxy log files

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/c/calamaris/calamaris_2.99.4.5-2.dsc

More information about calamaris can be obtained from
http://www.Cord.de/~cord/tools/squid/calamaris/

  Changes since the last upload:

* debian/patches
+ Add fix_negative_argument.diff
  + Fix negative argument to length. (Closes: #879600)
+ Add fix_manpage.diff
  + Fix a typo in manpage.
  * debian/control
+ Rename squid in Suggests field. (Closes: #817137)
+ Bump Standards-Version 4.1.1.
  + Use HTTPS in Link to copyright format.
+ Change debhelper to 10 in B-D.
  * debian/compat
+ Switch compat level 9 to 10.
  * debian/copyright
+ Extend debian copyright holder years.
  * debian/watch
+ Use secure uri.

Regards,


-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#844268: libboost1.62-doc doesn't contain the actual documentation

[Steve M. Robbins]

On Sun, Apr 23, 2017 at 11:55:15AM +0200, Klaus-J. Wolf wrote:
> Package: libboost1.62-doc
> Version: 1.62.0+dfsg-4
> Followup-For: Bug #844268
> 
> Dear Maintainer,
> 
> I have observed that the actual documentation is completely missing in
> this documentation package.  In duplicate bug report #850795 somebody
> explained that this has to do with Debian project's Javascript policy.
> I can only explain that I was incapable of finding any script elements
> in the original docs.

OK, it wasn't only javascript; also some basic HTML.

If I re-enable the doc packages and build, lintian spews dozens of
errors of three kinds: privacy-breach-logo, privacy-breach-generic,
privacy-breach-uses-embedded-file.

E: libboost1.65-doc: privacy-breach-logo 
usr/share/doc/libboost1.65-doc/HTML/doc/html/quickbook/syntax/block.html 
(http://sourceforge.net/sflogo.php?group_id=28447type=1)
W: libboost1.65-doc: privacy-breach-generic 
usr/share/doc/libboost1.65-doc/HTML/libs/assert/doc/html/assert.html 
(https://fonts.googleapis.com/css?family=open+sans:300,300italic,400,400italic,600,600italic%7cnoto+serif:400,400italic,700,700italic%7cdroid+sans+mono:400,700)
E: libboost1.65-doc: privacy-breach-uses-embedded-file 
usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/accessors_8hpp.html You 
may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: libboost1.65-doc: privacy-breach-uses-embedded-file 
usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/adapt__adt_8hpp.html You 
may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: libboost1.65-doc: privacy-breach-uses-embedded-file 
usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/adapt__struct_8hpp.html 
You may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: libboost1.65-doc: privacy-breach-uses-embedded-file 
usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/adjust_8hpp.html You may 
use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)

 etc.

-Steve


signature.asc
Description: PGP signature

Bug#879203: RFP: redisearch -- search engine on top of Redis

[Chris Lamb]

Hi Piotr,

Am happy to package this, and probably makes sense as the Redis
maintainer anyway.

> I chose redis-modulename as binary package name

So, "redis-redisearch". The only problem is that this *somewhat* collides with 
other packages in this namespace, such as redis-sentinel and redis-tools (which 
are not modules). So, one alternative might be "redis-module-redisearch" or 
"redis-modules-redisearch" but I find them to be a little too ugly.

> /usr/lib/redis/ but maybe /usr/lib/redis/modules/ is a better idea.

/usr/lib/redis/modules/ wfm. (We don't need to gnu-triplet-these for
multiarch do we?)

> so support for /etc/redis/conf.d/ or autoloading modules from given dir

Hm, do we even *want* autoloading modules? I'm not 100% sure we do. I guess
it does not block the packaging anyway...


Regards,

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

Bug#848198: fonts-noto-color-emoji

[Jeremy Bicha]

On Sun, Aug 20, 2017 at 1:11 AM, Medical Wei  wrote:
> I am recently (1-2 weeks ago) into some ITP and RFPs of some Python
> libraries to build fonts from source, like ufolib, defcon, and henrich is
> going to update fonttools. This can lead towards to packaging nototools to
> build this package from source.

This is a priority for me for Ubuntu 18.04 LTS. Please let me know if
I can help in any way.

It looks like there are several more packages that you need to build
nototools, some don't even have ITPs yet (like pyclipper).

Do you intend to maintain these packages yourself or with a team?

Do you have git repos for your work so far?

Have you been able to build nototools or the noto-color-emoji font locally yet?

I am usually in Debian IRC in #debian-gnome. Feel free to ping me.

Thanks,
Jeremy Bicha

Bug#879656: RFS: libkal/0.9.0-2

[Ahmed El-Mahmoudy]

Package: sponsorship-requests
Severity: normal

Hello,

I am looking for a sponsor for the updated package libkal/0.9.0-2. Also please 
grant me upload
rights for the package (I am a DM).

* Package name: libkal
  Version : 0.9.0-2
  Upstream Author : Petr Tomasek 
* URL : http://www.etf.cuni.cz/~tomasek/pub/my/
* License : LGPL-2+
  Section : libs

It builds those binary packages:

  libkal-dev - library for converting dates between various calendar systems

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/libkal

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/libk/libkal/libkal_0.9.0-2.dsc

The package can be found on Git:
ssh://git.debian.org/git/collab-maint/libkal.git


Changes since the last upload:

libkal (0.9.0-2) unstable; urgency=low

  * debian/rules: simplify rules file
  * Removed debian/libkal-dev.{dirs|install}
  * Add Depends: ${misc:Depends} to libkal-dev
  * Update my email address
  * Bump compat level to 10
  * Update standards version to 4.1.1
  * Changed Vcs-* fields to secure canonical URLs
  * Changed priority to optional
  * Update copyright format & years
  * Switch to 3.0 (quilt) source format
  * Fix spelling errors in package description.
Thanks to Jakub Wilk  (Closes: #801235)


As required, I tested the package against unstable's version of lintian and it
is lintian clean.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: Digital signature

Bug#879655: debci: please document how to use an alternative mirror

[Chris Lamb]

Source: debci
Version: 1.7.1
Severity: wishlist
Tags: patch

Hi,

I have a full local mirror on my laptop but it took a little while
to find the right voodoo to override the default mirror.

Patch attached to MAINTAINERS.md that makes this clearer to someone
getting started. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/docs/MAINTAINERS.md b/docs/MAINTAINERS.md
index aa8817e..afbf6b6 100644
--- a/docs/MAINTAINERS.md
+++ b/docs/MAINTAINERS.md
@@ -70,6 +70,12 @@ $ sudo debci setup
 This might take a few minutes since it will create a fresh container from
 scratch.
 
+You can use an alternative mirror using, for example:
+
+```
+$ sudo env MIRROR=http://my.local.mirror/debian debci setup
+```
+
 Now to actually run tests, we'll use `autopkgtest` directly. The following
 examples assume your architecture is amd64, replace it by your actual
 architecture if that is not the case.

Bug#879654: debci: Please use deb.debian.org over http.debian.net

[Chris Lamb]

Source: debci
Version: 1.7.1
Severity: wishlist
Tags: patch

Hi,

Please use deb.debian.org over http.debian.net. Whilst they may be some kind
of alias to each other, we should try and be consistent!

Patch attached.


Regards,

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

Bug#879653: mpv: Streaming mp3s fail after variable amount of play time

[J. Reis]

Package: mpv
Version: 0.23.0-2+b2
Severity: normal

Dear Maintainer,

Reproduction steps:
Initiate play of steaming mp3 via m3u file, wait 1-10min for audio to 
stop playing.

Expected behavior:
As far as I know, mpv should be able to play this kind of stream 
without interruption under normal network conditions.

Actual behavior:
Audio stops after a variable period of time. log shows "Cache is not 
responding - slow/stuck network connection?". Network in use is a fairly 
standard home setup and performs normally for other tasks. In this particular 
case, the web player for the same stream works fine.

Log file:
http://sprunge.us/AHUh

Sample files:
kwmu.m3u available from http://www.kwmu.org/listen.php
wpr-ideas-mp3-64.m3u available from https://www.wpr.org/listen-live

note: I'm new to "participating" by reporting bugs, feedback regarding
any mis-steps on my part is always appreciated.

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/8 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 mpv depends on:
ii  libasound2  1.1.3-5
ii  libass5 1:0.13.4-2
ii  libavcodec577:3.2.8-1~deb9u1
ii  libavdevice57   7:3.2.8-1~deb9u1
ii  libavfilter67:3.2.8-1~deb9u1
ii  libavformat57   7:3.2.8-1~deb9u1
ii  libavutil55 7:3.2.8-1~deb9u1
ii  libbluray1  1:0.9.3-3
ii  libc6   2.24-11+deb9u1
ii  libcdio-cdda1   0.83-4.3+b1
ii  libcdio-paranoia1   0.83-4.3+b1
ii  libcdio13   0.83-4.3+b1
ii  libdrm2 2.4.74-1
ii  libdvdnav4  5.0.3-3
ii  libdvdread4 5.0.3-2
ii  libegl1-mesa [libegl1-x11]  13.0.6-1+b2
ii  libgbm1 13.0.6-1+b2
ii  libgl1-mesa-glx [libgl1]13.0.6-1+b2
ii  libjack-jackd2-0 [libjack-0.125]1.9.10+20150825git1ed50c92~dfsg-5
ii  libjpeg62-turbo 1:1.5.1-2
ii  liblcms2-2  2.8-4
ii  liblua5.2-0 5.2.4-1.1+b2
ii  libpulse0   10.0-1+deb9u1
ii  librubberband2  1.8.1-7
ii  libsdl2-2.0-0   2.0.5+dfsg1-2
ii  libsmbclient2:4.5.12+dfsg-2
ii  libsndio6.1 1.1.0-3
ii  libswresample2  7:3.2.8-1~deb9u1
ii  libswscale4 7:3.2.8-1~deb9u1
ii  libv4l-01.12.3-1
ii  libva-drm1  1.7.3-2
ii  libva-wayland1  1.7.3-2
ii  libva-x11-1 1.7.3-2
ii  libva1  1.7.3-2
ii  libvdpau1   1.1.1-6
ii  libwayland-client0  1.12.0-1
ii  libwayland-cursor0  1.12.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]  13.0.6-1+b2
ii  libx11-62:1.6.4-3
ii  libxext62:1.3.3-1+b2
ii  libxinerama12:1.1.3-1+b3
ii  libxkbcommon0   0.7.1-1
ii  libxrandr2  2:1.5.1-1
ii  libxss1 1:1.2.2-1
ii  libxv1  2:1.0.11-1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages mpv recommends:
ii  xdg-utils   1.1.1-1
ii  youtube-dl  2017.05.18.1-1

mpv suggests no packages.

-- no debconf information

Bug#879298: Correcting statement about fabo

[Steve Robbins]

Hi Tobias,

Thanks for the correction!

On Tuesday, October 24, 2017 12:08:02 AM CDT you wrote:
> Hallo,
> 
> When I filed the bugs in respect of the maintainer status of Fathi I used
> the wrong switch in the script. I'd like to correct that.
> 
> Fathi has NOT retired, so the sentcne Fathi having retired is wrong.
> 
> it should have read
> 
> Fathi Boudra  has not been working on the $PKG package for
> quite some time.
> 
> I'm sorry for the inconvenience.

No problem.  Is it still the case that you recommend Fathi be removed from the 
uploaders list?

Thanks,
-Steve


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

Bug#878967: debian-policy: clarify purpose of debian/changelog

[Sean Whitton]

control: reassign -1 developers-reference
control: retitle -1 State intended audience of debian/changelog

Hello Ross,

On Sun, Oct 22 2017, Ross Vandegrift wrote:

> I have, it does, and that's a reasonable reluctance.  But I don't see
> anything there that would tell a new contributor about the intended
> audience(s) of debian/changelog.
>
> It could be that this bug would be better filed against Developer's
> Reference, if that would be a better location.

Done.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#879652: rpl has a python3 shebang but fails with NameError raw_input

[luke]

Package: rpl
Version: 1.5.7-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

using rpl with the `--prompt` option causes rpl to fail with the
following backtrace:

$ rpl --prompt foo bar test_file
Replacing "foo" with "bar" (case sensitive) (partial words matched)
.
Save 'test_file' ? ([Y]/N) Traceback (most recent call last):
  File "/usr/bin/rpl", line 314, in 
main()
  File "/usr/bin/rpl", line 269, in main
line = raw_input()
NameError: name 'raw_input' is not defined

It appears that Debian is using a hardcoded `/usr/bin/python3` shebang, whereas
the script is using python2 features (`raw_input`). Patching to use the
python3-equivalent `input` function where necessary ` appears to fix the issue:

diff --git rpl usr/bin/rpl
index 14754c3..fe2ff7c 100755
--- rpl
+++ usr/bin/rpl
@@ -5,12 +5,6 @@ try: import readline
 except ImportError: pass
 from stat import *
 
-try:
-raw_input
-except NameError:
-raw_input = input
-
-
 def show_license(*eat):
 print ("""rpl - replace strings in files
 Copyright (C) 2004-2005 Goran Weinholt 


Thanks

Luke

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

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

Versions of packages rpl depends on:
ii  python3  3.6.3-1

rpl recommends no packages.

rpl suggests no packages.

-- no debconf information

*** rpl.patch
diff --git rpl usr/bin/rpl
index 14754c3..fe2ff7c 100755
--- rpl
+++ usr/bin/rpl
@@ -5,12 +5,6 @@ try: import readline
 except ImportError: pass
 from stat import *
 
-try:
-raw_input
-except NameError:
-raw_input = input
-
-
 def show_license(*eat):
 print ("""rpl - replace strings in files
 Copyright (C) 2004-2005 Goran Weinholt 

Bug#762715: updates to dch --lts

[Antoine Beaupré]

On 2017-10-23 16:52:01, Mattia Rizzolo wrote:
> Hi!
>
> On Mon, Oct 23, 2017 at 10:33:58AM -0400, Antoine Beaupré wrote:
>> I figured I would do *some* refactoring while I was there to avoid
>> further code duplication.
>
> YES!  Please refactor it all :D
>
>> I haven't tested all scenarios (and the test suite is limited inthat
>> regard) but this mostly works in my tests locally.
>
> I'd be very happy if you could expand the testsuite some more: that's
> one reason why refactoring that thing is so unappealing, breakages are
> very easy to miss.  I'd actually take that patch before the others.
>
>
> (I haven't reviewed the patches just yet, but from a quick look they
> seem sane at least)

There was at least this bit missing to get the first changelog right...

-- 
A patriot must always be ready to defend his country
against his government.
- Edward Abbey
>From 4cad5da523ce6fca51ceb5f5cd2b19286b738c22 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Mon, 23 Oct 2017 17:01:47 -0400
Subject: [PATCH 3/3] add missing changelog line template for --lts

---
 scripts/debchange.pl | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/debchange.pl b/scripts/debchange.pl
index d01ca9a8..27915460 100755
--- a/scripts/debchange.pl
+++ b/scripts/debchange.pl
@@ -1273,6 +1273,9 @@ ()
 		print O "  * Non-maintainer upload by the Security Team.\n";
 	}
 	$line = 1;
+} elsif ($opt_lts && ! $opt_news) {
+print O "  * Non-maintainer upload by the LTS Security Team.\n";
+$line = 1;
 	} elsif ($opt_team && ! $opt_news) {
 	print O "  * Team upload.\n";
 	$line = 1;
-- 
2.11.0

Bug#879651: RFS: passwordsafe/1.03+dfsg-1

[Bill Blough]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor and/or someone to grant me upload permissions
  (I am a DM) for my package "passwordsafe".

 * Package name: passwordsafe
   Version : 1.03+dfsg-1
   Upstream Author : Rony Shapiro 
 * URL : https://pwsafe.org
 * License : Artistic-2.0
   Section : utils

  It builds those binary packages:

passwordsafe - Simple & Secure Password Management
passwordsafe-common - architecture independent files for Password Safe

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/passwordsafe/passwordsafe_1.03+dfsg-1.dsc

  More information about passwordsafe can be obtained from https://pwsafe.org

  Changes since the last upload:

  * Update upstream signing key
  * New upstream version
  * Refresh quilt patches
  * Update standards version to 4.1.1
- change copyright format URL to HTTPS
  * Lintian fixes
- Override false positive spelling error
- Enable hardening flags


  Regards,
   Bill Blough



signature.asc
Description: PGP signature

Bug#879566: Half-maximized terminal windows not edge-to-edge, size changes with zoom or tab bar

[Simon McVittie]

On Sun, 22 Oct 2017 at 14:18:12 -0700, Josh Triplett wrote:
> when zooming, or showing or hiding the tab bar
> or menu bar, the window size changes, often pushing part of it
> off-screen

This part (which I personally found the most annoying) is fixed in
gnome-terminal/3.26.1-2.

> when half-maximizing a terminal window, it resizes to an integral
> number of character cells, leaving a distracting border on the bottom
> and the right side

This part is unsolved, which surprises me, because the change
that upstream applied is one that I thought should have fixed this
too. gnome-terminal is meant to disable this behaviour when half-maximized
(or "tiled" as the APIs call it), but that doesn't seem to work: possibly
it's told about its new size (and resizes itself to be slightly smaller
than that due to the character cell granularity) before it's told that it
has been tiled?

> For that matter, opening two terminal windows, half-maximizing both, and
> dragging the border between them produces various buggy behavior with
> window borders jumping around and separating. I think the whole
> mechanism doesn't work well with windows that have resize increments
> other than one pixel.

Not yet fixed either.

smcv

Bug#879629: upload to stretch-updates?

[Martin Zobel-Helas]

Hi,

tbh, for me this would even warrant a upload to stretch-updates.

Anyone from the release team disagree?

Cheers,
Martin
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 

Bug#737658: some notes on util-linux takeover of eject

[Michael Biebl]

Hi KiBi,

thanks for your reply.

I've pushed a wip branch to
https://anonscm.debian.org/cgit/collab-maint/pkg-util-linux.git/log/?h=wip/eject

The resulting binary packages look fine afaics, especially the udeb:

$ dpkg --info eject-udeb_2.30.2-0.1_amd64.udeb
 new Debian package, version 2.0.
 size 21764 bytes: control archive=2368 bytes.
 325 Byte,11 Zeilen  control
  58 Byte, 7 Zeilen   *  postinst #!/bin/sh
4389 Byte,69 Zeilen  templates
 Package: eject-udeb
 Source: util-linux
 Version: 2.30.2-0.1
 Architecture: amd64
 Installer-Menu-Item: 96000
 Maintainer: LaMont Jones 
 Installed-Size: 61
 Depends: libc6-udeb (>= 2.24), libmount1-udeb (>= 2.29~), cdebconf-udeb
 Section: debian-installer
 Priority: required
 Description: ejects CDs from d-i menu



It's actually smaller then the old eject-udeb as I didn't include the
gettext translations.


But there is one complication: I noticed that eject in util-linux
currently linux only.

If we made the udeb linux-any, how would this affect the installer?

KiBi, is this a blocker in your opinion?

Michael



-- 
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#878685: stretch-pu: package udftools/1.3-2

[Martin Zobel-Helas]

Hi, 

On Sun Oct 15, 2017 at 21:58:16 +0200, Pali Rohár wrote:
> diff -Nru udftools-1.3/debian/changelog udftools-1.3/debian/changelog
> --- udftools-1.3/debian/changelog 2017-01-24 00:28:05.0 +0100
> +++ udftools-1.3/debian/changelog 2017-10-03 21:41:57.0 +0200
> @@ -1,3 +1,9 @@
> +udftools (1.3-2) unstable; urgency=low
> +
> +  * Fix path to pktsetup in udftools init script
> +
> + -- Pali Rohár   Tue, 03 Oct 2017 21:41:57 +0200
> +
>  udftools (1.3-1) unstable; urgency=low
>  
>* New upstream release
> diff -Nru udftools-1.3/debian/udftools.init udftools-1.3/debian/udftools.init
> --- udftools-1.3/debian/udftools.init 2017-01-24 00:26:46.0 +0100
> +++ udftools-1.3/debian/udftools.init 2017-10-03 21:40:26.0 +0200
> @@ -30,7 +30,7 @@
>  
>  PATH=/sbin:/bin:/usr/sbin:/usr/bin
>  DESC="udftools packet writing"
> -PKTSETUP=/usr/bin/pktsetup
> +PKTSETUP=/usr/sbin/pktsetup
>  DEFAULTFILE=/etc/default/udftools
>  DEVICES=""
>  NEWINTNAMES="0 1 2 3"

LGTM, beside that for the upload to stable you want a different version
number and suite changed.

Cheers,
Martin
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 

Bug#824229:

[Otto Kekäläinen]

I've reported this upstream at https://github.com/schani/metapixel/issues/10

Bug#878268: RFS: streamlink/0.8.1-3 [ITP]

[Alexis Murzeau]

retitle 878268 RFS: streamlink/0.8.1-3 [ITP]
thanks

Hi,

I uploaded a new package version to reflect an email address change.
I was using outlook SMTP server but got long delivery delays of mails to
Debian lists (above one day).
This new version only change references to the outlook email address to
the gmail one (while keeping old changelogs as-is).

The package is available using this dget command:
  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.8.1-3.dsc

Changes:
 streamlink (0.8.1-3) unstable; urgency=low

   * Change mail address to gmail

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#879644: transition: libzip

[Emilio Pozuelo Monfort]

Control: tags -1 moreinfo

On 23/10/17 22:00, Stefan Schoerghofer wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi release team,
> 
> libzip needs a transistion - I've uploaded the new version to
> experimental, will have to go trough NEW first, though.
> 
> I don't expect any breakages for binNMUs and will test the build of all
> reverse-depends.
> 
> Please let me know when I can upload it to unstable.

Let us know whether the rdeps build fine and when the package goes through NEW.

Cheers,
Emilio

Bug#879590: apparmor: Decide how we enable AppArmor by default

[Ben Hutchings]

On Mon, 2017-10-23 at 10:06 +0200, intrig...@debian.org wrote:
> Package: apparmor
> Version: 2.11.0-11
> Severity: normal
> X-Debbugs-Cc: Ben Hutchings 
> 
> Hi,
> 
> we're discussing whether to enable AppArmor by default during the
> Buster cycle, but we have no actual plan wrt. how to do it.
> There are several options:
> 
> A. Make AppArmor the default LSM in the kernel
> 
>i.e. set CONFIG_DEFAULT_SECURITY="apparmor"
>and CONFIG_DEFAULT_SECURITY_APPARMOR=y.
[...]
> B. Configure bootloaders to enable AppArmor by default
>
>On https://bugs.debian.org/702030 a nice & flexible solution was
>designed; let's call it B.1.
[...]
>A short-term simpler option would be to drop a file in
>/etc/default/grub.d/ [...] Let's call this option B.2.
[...]
> C. Anything else?
> 
> My personal preference is A > B.1. Ben & others, what do you think?

I agree.

We really should have a common way to append things to the kernel
command line, which would allow a more general B.2, but this shouldn't
have to wait for that.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow
Lindberg



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

Bug#879282: Correcting statement about fabo

[Tobias Frost]

Hallo,

When I filed the bugs in respect of the maintainer status of Fathi I used the 
wrong switch in the
script. I'd like to correct that.

Fathi has NOT retired, so the sentcne Fathi having retired is wrong.

it should have read

Fathi Boudra  has not been working on the $PKG package for
quite some time.

I'm sorry for the inconvenience.

--
tobi



signature.asc
Description: PGP signature

Bug#879650: ITP: arctica-greeter -- LightDM Arctica Greeter

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: arctica-greeter
  Version : 0.99.0.1
  Upstream Author : Mike Gabriel 
* URL : https://github.com/ArcticaProject/arctica-greeter
* License : GPL-3
  Programming Lang: Vala
  Description : LightDM Arctica Greeter

 A greeter shell for the LightDM login manager. Arctica Greeter can be
 used as local display manager as well as thin client login manager.
 .
 With the bin:package arctica-greeter-remote-logon installed, you can
 use the greeter as a remote logon manager (currently supported: RDP
 sessions, X2Go sessions). This requires an X2Go Session Broker on the
 other end.
 .
 The arctica-greeter-guest-session bin:package will add guest session
 support to the greeter.
 .
 A special theme for Debian will also be provided.

Bug#871657: dch: please add --sru option

[Antoine Beaupré]

On 2017-10-23 22:31:43, Chris Lamb wrote:
> Hi Antoine et al.,
>
>> Those two chunks, in particular, probably do not yield the warning you
>> would have expected:
> […]
>> ... because they do not actually change the conditionnals!
>
> Can you clarify and/or provide an updated patch? I think I'm being
> blind or am over/under-caffeinated..
>
> Would be great to have both --sru and --lts merged! :)

Something like this maybe?

diff --git a/scripts/debchange.pl b/scripts/debchange.pl
index 27915460..57db5606 100755
--- a/scripts/debchange.pl
+++ b/scripts/debchange.pl
@@ -437,7 +437,7 @@ ()
 
 # Only allow at most one non-help option
 fatal "Only one of -a, -i, -e, -r, -v, -d, -n/--nmu, --bin-nmu, -q/--qa, 
-R/--rebuild, -s/--security, --lts, --team, --bpo, --stable, -l/--local is 
allowed;\ntry $progname --help for more help"
-if ($opt_i?1:0) + ($opt_a?1:0) + ($opt_e?1:0) + ($opt_r?1:0) + 
($opt_v?1:0) + ($opt_d?1:0) + ($opt_n?1:0) + ($opt_bn?1:0) + ($opt_qa?1:0) + 
($opt_R?1:0) + ($opt_s?1:0) + ($opt_lts?1:0) + ($opt_team?1:0) + ($opt_bpo?1:0) 
+ ($opt_l?1:0) > 1;
+if ($opt_i?1:0) + ($opt_a?1:0) + ($opt_e?1:0) + ($opt_r?1:0) + 
($opt_v?1:0) + ($opt_d?1:0) + ($opt_n?1:0) + ($opt_bn?1:0) + ($opt_qa?1:0) + 
($opt_R?1:0) + ($opt_s?1:0) + ($opt_lts?1:0) + ($opt_team?1:0) + ($opt_bpo?1:0) 
+ ($opt_l?1:0) + ($opt_stable?1:0)> 1;
 
 if ($opt_s) {
 $opt_u = "high";
@@ -547,7 +547,7 @@ ()
 if ($opt_create) {
 if ($opt_a || $opt_i || $opt_e || $opt_r || $opt_b || $opt_n || $opt_bn ||
$opt_qa || $opt_R || $opt_s || $opt_team || $opt_lts || $opt_bpo || 
$opt_l ||
-   $opt_allow_lower) {
+   $opt_allow_lower || $opt_stable) {
warn "$progname warning: ignoring 
-a/-i/-e/-r/-b/--allow-lower-version/-n/--bin-nmu/-q/--qa/-R/-s/--lts/--team/--bpo/--stable,-l
 options with --create\n";
$warnings++;
 }



-- 
Power is always dangerous.
Power attracts the worst and corrupts the best.
- Edward Abbey

Bug#871657: dch: please add --sru option

[Chris Lamb]

Hi Antoine et al.,

> Those two chunks, in particular, probably do not yield the warning you
> would have expected:
[…]
> ... because they do not actually change the conditionnals!

Can you clarify and/or provide an updated patch? I think I'm being
blind or am over/under-caffeinated..

Would be great to have both --sru and --lts merged! :)


Regards,

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

Bug#872378: fenrir.deb: No speech after enabling fenrir to start inconcial.

[Samuel Thibault]

Hello,

Matthew Dyer, on mar. 29 août 2017 10:55:33 -0400, wrote:
> Downgrading still gives me no speech.  I have speech with orca how ever. 
> Espeakup also works though not at the same time.  I have espeakup disabled at
> the moment.

Ok.

I have found issues in upstream packages, could you try installing the
version I have uploaded? (1.06-2)

Alternatively, you can modify /lib/systemd/system/fenrir.service

ExecStart=/usr/bin/fenrir-daemon

should actually read as

ExecStart=/usr/bin/fenrir

and make sure that you have the python3-dbus package installed.

If it still doesn't work, please send us your /var/log/fenrir.log

Samuel

Bug#878911: avahi FTBFS with debhelper 10.9.2

[Felipe Sateler]

On Sat, Oct 21, 2017 at 3:44 AM, Niels Thykier  wrote:
> Control: reassign -1 debhelper 10.9.2
>
> Michael Biebl:
>> On Tue, 17 Oct 2017 19:45:11 +0300 Adrian Bunk  wrote:
>>> Source: avahi
>>> Version: 0.7-3
>>> Severity: serious
>>>
>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/avahi.html
>>>
>>> ...
>>>dh_systemd_start
>>> dh_systemd_start: Could not find "avahi-daemon.socket" in the 
>>> /lib/systemd/system directory of avahi-dnsconfd. This could be a typo, or 
>>> using Also= with a service file from another package. Please check 
>>> carefully that this message is harmless.
>>> dh_systemd_start: Cannot open(avahi-daemon.socket) for extracting the Also= 
>>> line(s)
>>> debian/rules:4: recipe for target 'binary' failed
>>> make: *** [binary] Error 2
>>>
>>>
>>> 19:35 < nthykier> bunk: Ideally, avahi would fix this on their end.  
>>> Without the fail-on-error, debhelper will silently "not do things"
>>>   when the file is unreadable (even if only temporarily).  
>>> I.e. a "fail-to-fail"-case
>>>
>>
>
> Hi,
>
>> avahi-daemon.socket is provided by avahi-daemon, a binary package which
>> is built from the same source package and avahi-dnsconfd depends on
>> avahi-daemon.
>
> Ok, when I spoke with Adrian about this, I had a different understanding
> of what happened and why it broke.
>
>> Niels, can you be a bit more specific why this fails now and what you
>> think is the proper fix?
>
> I can explain why it fails; dh_systemd_start basically reads the Also=
> line and pretends it was a part of the services listed on the cmdline/in
> the package.  As it is now mandatory for us to be able to read the
> service files, this will fail as the service is not where we expect to
> find it.
>
> The comment related to that part of the code reads:
>
> """
> # Handle all unit files specified via Also= explicitly.
> # This is not necessary for enabling, but for disabling, as we
> # cannot read the unit file when disabling (it was already
> # deleted).
> """
>
> @biebl/@fsateler: when a unit has an Also= that points to a unit in a
> different package can we then just ignore the relation?  I assume that
> we should not disable/stop services from another package on removal.

I think that in this case, the correct fix is to drop the Also= line.

1. We don't want to stop avahi-daemon socket if dnsconfd is removed
2. It appears the Also line is being treated as some form of
dependency manager (ie, to ensure that the avahi-daemon is started
when dnsconfd is started), but it is not necessary, because
avahi-daemon.socket is already Required.

So, I think we have not yet found a compelling case for dropping the
debhelper error. The Also line is not needed, and can be safely
dropped from the avahi-dnsconfd unit.

-- 

Saludos,
Felipe Sateler

Bug#816872: wmbattery: memory leak in wmbattery

[David Johnson]

With the patch provided to remove the extra up_client_new() calls, I
still see these 3 leaks from within up_client_get_devices().

Neither g_ptr_array_free() or g_ptr_array_unref() are cleaning them
up.

I'm assuming a more comprehensive fix would be to remove
up_client_get_devices() from upower_read() since it seems to be
internally leaking in libupower-glib and save the data from the call
in upower_supported() for each polling cycle instead of discarding it
each time.


==17098== 
==17098== 5,968 bytes in 746 blocks are possibly lost in loss record 1,557 of 
1,606
==17098==at 0x4238A0E: g_type_create_instance (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x421A9D5: g_object_new_internal (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x421C4A5: g_object_newv (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x421CACC: g_object_new (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x41EDB06: up_device_new (in 
/usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0)
==17098==by 0x41E8FC6: up_client_get_devices (in 
/usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0)
==17098==by 0x804BE5A: upower_read (upower.c:89)
==17098==by 0x804A996: alarmhandler (wmbattery.c:711)
==17098==by 0x43BD3F7: ??? (in /lib/i386-linux-gnu/i686/cmov/libc-2.19.so)
==17098== 
==17098== 14,920 bytes in 746 blocks are possibly lost in loss record 1,566 of 
1,606
==17098==at 0x42389C2: g_type_create_instance (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x421A9D5: g_object_new_internal (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x421C4A5: g_object_newv (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x421CACC: g_object_new (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x41EDB06: up_device_new (in 
/usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0)
==17098==by 0x41E8FC6: up_client_get_devices (in 
/usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0)
==17098==by 0x804BE5A: upower_read (upower.c:89)
==17098==by 0x804A996: alarmhandler (wmbattery.c:711)
==17098==by 0x43BD3F7: ??? (in /lib/i386-linux-gnu/i686/cmov/libc-2.19.so)
==17098== 
==17098== 26,856 bytes in 746 blocks are possibly lost in loss record 1,584 of 
1,606
==17098==at 0x402C0D5: calloc (vg_replace_malloc.c:623)
==17098==by 0x42B3745: g_malloc0 (in 
/lib/i386-linux-gnu/libglib-2.0.so.0.4200.1)
==17098==by 0x42148C4: g_closure_new_simple (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x4215C28: g_cclosure_new (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x422DF1C: g_signal_connect_data (in 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4200.1)
==17098==by 0x41ECAB2: up_device_set_object_path_sync (in 
/usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0)
==17098==by 0x41E8FD3: up_client_get_devices (in 
/usr/lib/i386-linux-gnu/libupower-glib.so.3.0.0)
==17098==by 0x804BE5A: upower_read (upower.c:89)
==17098==by 0x804A996: alarmhandler (wmbattery.c:711)
==17098==by 0x43BD3F7: ??? (in /lib/i386-linux-gnu/i686/cmov/libc-2.19.so)
==17098== 


-- 
David Johnson
Principal Engineer

Bug#871657: dch: please add --sru option

[Antoine Beaupre]

After reviewing this patch for inspiration in implementing a --lts
option (#762715), I believe I have found it to be slightly incomplete.

Those two chunks, in particular, probably do not yield the warning you
would have expected:

@@ -430,7 +433,7 @@ if (defined $opt_level) {
 if (defined $opt_regex) { $check_dirname_regex = $opt_regex; }
 
 # Only allow at most one non-help option
-fatal "Only one of -a, -i, -e, -r, -v, -d, -n/--nmu, --bin-nmu, -q/--qa, 
-R/--rebuild, -s/--security, --team, --bpo, -l/--local is allowed;\ntry 
$progname --help for more help"
+fatal "Only one of -a, -i, -e, -r, -v, -d, -n/--nmu, --bin-nmu, -q/--qa, 
-R/--rebuild, -s/--security, --team, --bpo, --stable, -l/--local is 
allowed;\ntry $progname --help for more help"
 if ($opt_i?1:0) + ($opt_a?1:0) + ($opt_e?1:0) + ($opt_r?1:0) + 
($opt_v?1:0) + ($opt_d?1:0) + ($opt_n?1:0) + ($opt_bn?1:0) + ($opt_qa?1:0) + 
($opt_R?1:0) + ($opt_s?1:0) + ($opt_team?1:0) + ($opt_bpo?1:0) + ($opt_l?1:0) > 
1;
 
 if ($opt_s) {
@@ -542,7 +545,7 @@ if ($opt_create) {
 if ($opt_a || $opt_i || $opt_e || $opt_r || $opt_b || $opt_n || $opt_bn ||
$opt_qa || $opt_R || $opt_s || $opt_team || $opt_bpo || $opt_l ||
$opt_allow_lower) {
-   warn "$progname warning: ignoring 
-a/-i/-e/-r/-b/--allow-lower-version/-n/--bin-nmu/-q/--qa/-R/-s/--team/--bpo/-l 
options with --create\n";
+   warn "$progname warning: ignoring 
-a/-i/-e/-r/-b/--allow-lower-version/-n/--bin-nmu/-q/--qa/-R/-s/--team/--bpo/--stable,-l
 options with --create\n";
$warnings++;
 }
 if ($opt_package && $opt_d) {


... because they do not actually change the conditionnals!

I think the patch in #762715 does the right thing and could be used for
inspiration...

A.

On Wed, Oct 04, 2017 at 09:53:30PM +0100, Chris Lamb wrote:
> tags 871657 + patch
> thanks
> 
> Hi,
> 
> > dch: please add --sru option
> 
> Patch attached:
> 
>   commit f425b69cab7401f89e5891a8aeb903d6400de2d2
>   Author: Chris Lamb 
>   Date:   Wed Oct 4 21:51:16 2017 +0100
>   
>   Add support for preparing upload to stable.
>   
>scripts/debchange.1   |  4 +++
>scripts/debchange.bash_completion |  2 +-
>scripts/debchange.pl  | 56 
> +--
>test/test_debchange   |  3 +++
>4 files changed, 50 insertions(+), 15 deletions(-)
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

> >From f425b69cab7401f89e5891a8aeb903d6400de2d2 Mon Sep 17 00:00:00 2001
> From: Chris Lamb 
> Date: Wed, 4 Oct 2017 21:51:16 +0100
> Subject: [PATCH] Add support for preparing upload to stable.
> 
> ---
>  scripts/debchange.1   |  4 +++
>  scripts/debchange.bash_completion |  2 +-
>  scripts/debchange.pl  | 56 
> +--
>  test/test_debchange   |  3 +++
>  4 files changed, 50 insertions(+), 15 deletions(-)
> 
> diff --git a/scripts/debchange.1 b/scripts/debchange.1
> index 14cb6a67..98058fd7 100644
> --- a/scripts/debchange.1
> +++ b/scripts/debchange.1
> @@ -258,6 +258,10 @@ distribution. Increment the Debian version.
>  Increment the Debian release number for an upload to jessie-backports,
>  and add a backport upload changelog comment.
>  .TP
> +.B \-\-stable
> +Increment the Debian release number for an upload to the current stable
> +release.
> +.TP
>  .BR \-\-local ", " \-l \fIsuffix\fR
>   Add a suffix to the Debian version number for a local build.
>  .TP
> diff --git a/scripts/debchange.bash_completion 
> b/scripts/debchange.bash_completion
> index 7726e920..85df2820 100644
> --- a/scripts/debchange.bash_completion
> +++ b/scripts/debchange.bash_completion
> @@ -13,7 +13,7 @@ _debchange()
>   -r --release --force-save-on-release --no-force-save-on-release\
>   --create --empty --package --auto-nmu --no-auto-nmu -n --nmu\
>   --bin-nmu -q --qa -R --rebuild -s --security --team -U 
> --upstream\
> - --bpo -l --local -b --force-bad-version --allow-lower-version\
> + --bpo --stable -l --local -b --force-bad-version 
> --allow-lower-version\
>   --force-distribution --closes --noquery --query -d 
> --fromdirname\
>   -p --preserve --no-preserve --vendor -D --distribution\
>   -u --urgency -c --changelog --news --nomultimaint --multimaint\
> diff --git a/scripts/debchange.pl b/scripts/debchange.pl
> index d1f115e5..e6c979a0 100755
> --- a/scripts/debchange.pl
> +++ b/scripts/debchange.pl
> @@ -162,6 +162,8 @@ Options:
>--bpo
>   Increment the Debian release number for a backports upload
>   to "stretch-backports"
> +  --stable
> + Increment the Debian release number for a stable upload.
>-l, --local 
>   Add a suffix to the Debian version number for a local build
>-b, 

Bug#879486: Please support "gbp import-dsc" of the downloaded source

[Guido Günther]

Hi,
On Mon, Oct 23, 2017 at 10:00:49PM +0200, Michael Stapelberg wrote:
> control: tags -1 + pending
> 
> On Mon, Oct 23, 2017 at 9:38 PM, Guido Günther  wrote:
> > Hi,
> > On Sun, Oct 22, 2017 at 12:42:29PM +0200, Michael Stapelberg wrote:
> >> On Sun, Oct 22, 2017 at 12:28 PM, Guido Günther  wrote:
> >> > Hi,
> >> > On Sun, Oct 22, 2017 at 11:15:20AM +0200, Michael Stapelberg wrote:
> >> >> Thanks for filing this.
> >> >>
> >> >> On Sun, Oct 22, 2017 at 9:21 AM, Guido Günther  wrote:
> >> >> > Package: pk4
> >> >> > Version: 2
> >> >> > Severity: wishlist
> >> >> >
> >> >> > Hi,
> >> >> > it would be nice if pk4 would allow to use "gbp import-dsc" to unpack
> >> >> > the donwloaded sources in downloadDSCAndUnpack so users:
> >> >> >
> >> >> >- get a git archive right away
> >> >> >- can reuise their gbp configuration such as the configured 
> >> >> > builder,
> >> >> >- pristine-tar, ... right away
> >> >>
> >> >> I think we could introduce a hook which would replace the default
> >> >> behavior of dpkg-source -x, taking as arguments the path to the DSC
> >> >> and the destination directory.
> >> >
> >> > Sounds good.
> >> >
> >> >>
> >> >> I wonder whether the gbp hook should live in the git-buildpackage
> >> >> Debian package, though? That way, you could maintain it directly. If
> >> >
> >> > Sure. It would be nice if setup for users would the be as simple as
> >> >
> >> >   ln -s /usr/share/doc/git-buildpackage/examples/pk4 
> >> > ~/pk4/pk4.deb822.d/gbp
> >>
> >> Almost:
> >>
> >> mkdir -p ~/.config/pk4/hooks-enabled/unpack/
> >> ln -s /usr/share/pk4/hooks-available/unpack/gbp \
> >> ~/.config/pk4/hooks-enabled/unpack/
> >>
> >> Regarding the symlink target, could we ship
> >> /usr/share/pk4/hooks-available/unpack/gbp in git-buildpackage? That
> >> way, all hooks would be in the same directory. This is similar to how
> >> shell tab completion files are shipped.
> >
> > Shipped now with the next gbp version:
> >
> > https://github.com/agx/git-buildpackage/blob/master/debian/pk4
> 
> Neat!
> 
> I just committed
> https://github.com/Debian/pk4/commit/797dc0b887abbc482a7a095d687b710509a80816,
> upload to Debian follows in a second.
> 
> One thing I noticed: the resulting branches are master, pk4 and
> upstream, which the currently checked out branch being master.
> Shouldn’t the only two branches be pk4 and upstream?

Yes, that's:


https://github.com/agx/git-buildpackage/commit/01da1e61b003aa7cb576fbe5755a665a12c3f2ba

which I should have fixed long ago.
Cheers,
 -- Guido

> 
> >
> >> >> you think that’s not a good idea, could you suggest how the hook
> >> >> should be implemented? I’m envisioning something like this (untested):
> >> >>
> >> >> #!/bin/sh
> >> >> set -e
> >> >> mkdir -p "$2"
> >> >> cd "$2"
> >> >> git init
> >> >> gbp import-dsc "$1"
> >> >
> >> > #!/bin/sh
> >> > set -e
> >> > gbp import-dsc "$1" "$2"
> >> >
> >> > is enough (gbp will do the rest). That way we could also support
> >> > incremental imports (that is if the directory is already there we simply
> >> > import the new version on top of it so the use can diff between the old
> >> > an new version.
> >>
> >> Note that the pk4 output directories contain the version number, so I
> >> think incremental imports wouldn’t work well.
> >>
> >> >
> >> >> Side note: I think we should be fairly clear about the difference
> >> >> between a gbp-from-dsc repo and a gbp-from-gbp-clone repo, to not
> >> >> confuse our users.
> >> >
> >> > Yeah. I was thinking of putting a .git/gbp.conf into the repo that sets
> >> >
> >> >   [DEFAULT]
> >> >   upstream-branch = upstream
> >> >   debian-branch = pk4
> >> >
> >> > This would
> >> >
> >> >  - make sure we override settings any branch settings in debian/gbp.conf
> >> >which we don't care about (since we're not cloning from Vcs-Git:
> >> >  - Having the default branch named pk4 would make it obvious that this
> >> >is s.th. special.
> >> >
> >> > What do you think? In this case it would rather be more like your script
> >> > above:
> >>
> >> Sounds good to me.
> >>
> >> >
> >> > #!/bin/sh
> >> > set -e
> >> >
> >> > if [ ! -d $2 ]; then
> >>
> >> nit: use "$2" here as well
> >>
> >> >
> >> >   git init "$2"
> >> >
> >> >   cat < "$2"/.git/gbp.conf
> >>
> >> I suggest to add as a comment what you wrote above for the benefit of
> >> readers of the hook :).
> >>
> >> >   [DEFAULT]
> >> >   upstream-branch = upstream
> >> >   debian-branch = pk4
> >> >   EOF
> >> > fi
> >> >
> >> > cd "$2"
> >> > gbp import-dsc "$1"
> >> >
> >> >
> >> > Does this sound reasonable? I would then also provide a script that can
> >> > be used with pk4-replace.
> >>
> >> I don’t quite follow. What sort of script is required for that?
> >
> > Probably not even a script but a post-build hook that cats the name of
> > the generated changes file to /proc/self/fd/3.
> 
> Ah, I see.
> 
> > Cheers,
> >  -- Guido
> 
> 
> 
> -- 
> Best regards,
> 

Bug#816872: wmbattery: memory leak in wmbattery

[David Johnson]

Doug,

When I first filed this bug I did some digging with valgrind trying to
find the leaks.

I found several issues with the upower module (the older methonds were
less leaky).  valgrind found lots of leaks, but they were hard to
trace, except that most/all were in the upower area.  I suspect that
some of the leaks are in libupower not wmbattery, however it wasn't
clear to me if it was wmbattery's usage of libupower or libupower
itself.

I did find the following improved the leaks, however it was still
leaking, just not as bad.

Also the rate of leaks is directly linked to the "-w" option, the
faster the refresh the faster the leaking.


Hope this helps:

diff -Nuar wmbattery-2.50.orig/upower.c wmbattery-2.50/upower.c
--- wmbattery-2.50.orig/upower.c2015-08-30 19:58:13.0 -0400
+++ wmbattery-2.50/upower.c 2016-03-20 16:08:57.177709309 -0400
@@ -78,8 +78,6 @@
GPtrArray *devices = NULL;
static int retries = 0;
 
-   up = up_client_new();
-
if (!up)
return -1;
 
@@ -143,6 +141,6 @@
info->battery_status = BATTERY_STATUS_ABSENT;
}
 
-   g_ptr_array_free(devices, TRUE);
+   g_ptr_array_unref(devices);
return 0;
 }




-- 
David Johnson
Principal Engineer

Bug#879649: O: ccrypt -- secure encryption and decryption of files and streams

[Tobias Frost]

Package: wnpp

The current maintainer of ccrypt, Chris Vanden Berghe ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: ccrypt
Binary: ccrypt
Version: 1.10-4
Maintainer: Chris Vanden Berghe 
Build-Depends: debhelper (>= 9), autotools-dev
Architecture: any
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 508770c72c5d1b047229009038c87517 1656 ccrypt_1.10-4.dsc
 44ddd763465c254df83f5d38851d04d7 669491 ccrypt_1.10.orig.tar.gz
 689eaf239ccc8b1d94568992d7409477 4372 ccrypt_1.10-4.debian.tar.xz
Checksums-Sha256:
 4dd9e1a2c696ae9453f92453b606482e65955027194ea5f99ae912639c8ce063 1656 
ccrypt_1.10-4.dsc
 87d66da2170facabf6f2fc073586ae2c7320d4689980cfca415c74688e499ba0 669491 
ccrypt_1.10.orig.tar.gz
 f475722703ce3b795fd4bc7540c5ec28275492fee5a567afeed2af032d319456 4372 
ccrypt_1.10-4.debian.tar.xz
Package-List: 
 ccrypt deb utils optional
Directory: pool/main/c/ccrypt
Priority: source
Section: utils

Package: ccrypt
Source: ccrypt (1.10-4)
Version: 1.10-4+b1
Installed-Size: 218
Maintainer: Chris Vanden Berghe 
Architecture: amd64
Depends: libc6 (>= 2.14)
Description-en: secure encryption and decryption of files and streams
 ccrypt is a utility for encrypting and decrypting files and streams. It was
 designed as a replacement for the standard unix crypt utility, which is
 notorious for using a very weak encryption algorithm. ccrypt is based on the
 Rijndael cipher, which is the U.S. government's chosen candidate for the
 Advanced Encryption Standard (AES, see http://www.nist.gov/aes). This cipher is
 believed to provide very strong security.
Description-md5: da31f4a0f5044cdae29a94198cd0810c
Tag: interface::commandline, role::program, scope::utility,
 security::cryptography
Section: utils
Priority: optional
Filename: pool/main/c/ccrypt/ccrypt_1.10-4+b1_amd64.deb
Size: 72630
MD5sum: 1854c4ae5777aa8ddc08aafafe53e709
SHA256: 904388c53f8df33e9f32f7e9d44f51066fba92dad686a3b86cbd365363054878



signature.asc
Description: PGP signature

Bug#879648: O: metapixel -- generator for photomosaics

[Tobias Frost]

Package: wnpp

The current maintainer of metapixel, Chris Vanden Berghe ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: metapixel
Binary: metapixel
Version: 1.0.2-7.4
Maintainer: Chris Vanden Berghe 
Build-Depends: debhelper (>= 5.0.0), libpng-dev, libjpeg-dev, xsltproc, 
docbook-xsl, docbook-xml, libgif-dev
Architecture: any
Standards-Version: 3.9.1
Format: 1.0
Files:
 a675370010f7faa90589b761dcef 1727 metapixel_1.0.2-7.4.dsc
 af5d77d38826756af213a08e3ada9941 63197 metapixel_1.0.2.orig.tar.gz
 8a13fd665f167172e36db5f8a4a66649 16640 metapixel_1.0.2-7.4.diff.gz
Checksums-Sha256:
 f8b6156d2c2520c4b86a72bbf8eb9a178d21e9bbf309a3113bcbccf4dba80a0e 1727 
metapixel_1.0.2-7.4.dsc
 8d77810978da397c070b9b4e228ae6204e9f5c524518ad1a4fcab9462171f55b 63197 
metapixel_1.0.2.orig.tar.gz
 f619314b7f8a375218cc2eba66f7bdb91912f43b4c94a618935c729e289d7ece 16640 
metapixel_1.0.2-7.4.diff.gz
Package-List: 
 metapixel deb graphics optional arch=any
Directory: pool/main/m/metapixel
Priority: source
Section: graphics

Package: metapixel
Source: metapixel (1.0.2-7.4)
Version: 1.0.2-7.4+b1
Installed-Size: 124
Maintainer: Chris Vanden Berghe 
Architecture: amd64
Depends: libc6 (>= 2.14), libgif7 (>= 5.1), libjpeg62-turbo (>= 1.3.1), 
libpng16-16 (>= 1.6.2-1), zlib1g (>= 1:1.1.4)
Description-en: generator for photomosaics
 Metapixel is a program for generating photomosaics. It can generate
 classical photomosaics, in which the source image is viewed as a matrix
 of equally sized rectangles for each of which a matching image is
 substitued, as well as collage-style photomosaics, in which rectangular
 parts of the source image at arbitrary positions (i.e. not aligned to a
 matrix) are substituted by matching images.
Description-md5: e21789994eab123d697c18d19185099c
Tag: interface::commandline, role::program, scope::application,
 works-with-format::jpg, works-with-format::png, works-with::image,
 works-with::image:raster
Section: graphics
Priority: optional
Filename: pool/main/m/metapixel/metapixel_1.0.2-7.4+b1_amd64.deb
Size: 46470
MD5sum: d576f3e7f154b3bd150c435e723b14af
SHA256: 3afecdc61141ae191c320f8426957f78ae56169e124c3615d3723dbe31cb5983



signature.asc
Description: PGP signature

Bug#878948:

[Javi Legido]

I can confirm the issue and the fix, installing libglvnd0 package.

Cheers.

Javier

Bug#873088: git-annex CVE-2017-12976 wheezy backport

[Antoine Beaupré]

Hi all,

I've undertaken the work to backport the patch for CVE-2017-12976 to
wheezy, that is 3.20120629 (!). First off, the Ddar and Gcrypt remote
were missing, so that reduced the work. It also seems that the assistant
didn't need to be patched because it didn't use ssh host primitives as
much.

At least this is what I found. The debdiff is attached and I have
uploaded a test build on my usual repository:

https://people.debian.org/~anarcat/debian/wheezy-lts/

Test seems to pass, both at build time and during some basic smoke tests
in a wheezy VM. I also can't reproduce the issue with the new package,
so the fix seems to work. I am assuming Haskell's type checking take
care of the rest.

Any review would be greatly appreciated, I plan on uploading this to
wheezy by the end of the week.

Note that the stretch upload should be fairly trivial with the provided
patch: just apply, fix the change and upload. Jessie should be fairly
easy to patch with the two examples...

Thanks especially to Joeyh for his quick response!

A.

-- 
I would defend the liberty of consenting adult creationists to practice
whatever intellectual perversions they like in the privacy of their own
homes; but it is also necessary to protect the young and innocent.
- Arthur C. Clarke
>From 05903f52f614243421451836c4431e3b63de53ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Mon, 23 Oct 2017 16:50:56 -0400
Subject: [PATCH] (oldstable) fix dashed ssh hostname issue CVE-2017-12976
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Security fix: Disallow hostname starting with a dash, which would get
passed to ssh and be treated an option. This could be used by an attacker
who provides a crafted ssh url (for eg a git remote) to execute arbitrary
code via ssh -oProxyCommand.

The same class of security hole recently affected git itself,
CVE-2017-1000117.

Method: Identified all places where ssh is run, by git grep '"ssh"'
Converted them all to use a SshHost, if they did not already, for
specifying the hostname.

SshHost was made a data type with a smart constructor, which rejects
hostnames starting with '-'.

Note that git-annex already contains extensive use of Utility.SafeCommand,
which fixes a similar class of problem where a filename starting with a
dash gets passed to a program which treats it as an option.

This was backported by Antoine Beaupré, from the upstream stable patch
provided by Joey Hess.
---
 Annex/Ssh.hs | 22 --
 Remote/Helper/Ssh.hs |  7 ++-
 Utility/SshHost.hs   | 29 +
 debian/changelog | 10 ++
 4 files changed, 57 insertions(+), 11 deletions(-)
 create mode 100644 Utility/SshHost.hs

diff --git a/Annex/Ssh.hs b/Annex/Ssh.hs
index 8bd4fe33a..63c2324a3 100644
--- a/Annex/Ssh.hs
+++ b/Annex/Ssh.hs
@@ -18,10 +18,11 @@ import qualified Git.Config
 import Config
 import qualified Build.SysConfig as SysConfig
 import Annex.Perms
+import Utility.SshHost
 
 {- Generates parameters to ssh to a given host (or user@host) on a given
  - port, with connection caching. -}
-sshParams :: (String, Maybe Integer) -> [CommandParam] -> Annex [CommandParam]
+sshParams :: (SshHost, Maybe Integer) -> [CommandParam] -> Annex [CommandParam]
 sshParams (host, port) opts = go =<< sshInfo (host, port)
 	where
 		go (Nothing, params) = ret params
@@ -30,14 +31,14 @@ sshParams (host, port) opts = go =<< sshInfo (host, port)
 			liftIO $ createDirectoryIfMissing True $ parentDir socketfile
 			lockFile $ socket2lock socketfile
 			ret params
-		ret ps = return $ ps ++ opts ++ portParams port ++ [Param host]
+		ret ps = return $ ps ++ opts ++ portParams port ++ [Param (fromSshHost host)]
 		-- If the lock pool is empty, this is the first ssh of this
 		-- run. There could be stale ssh connections hanging around
 		-- from a previous git-annex run that was interrupted.
 		cleanstale = whenM (not . any isLock . M.keys <$> getPool) $
 			sshCleanup
 
-sshInfo :: (String, Maybe Integer) -> Annex (Maybe FilePath, [CommandParam])
+sshInfo :: (SshHost, Maybe Integer) -> Annex (Maybe FilePath, [CommandParam])
 sshInfo (host, port) = ifM caching
 	( do
 		dir <- fromRepo gitAnnexSshDir
@@ -91,7 +92,7 @@ sshCleanup = do
 -- "ssh -O stop" is noisy on stderr even with -q
 let cmd = unwords $ toCommand $
 	[ Params "-O stop"
-	] ++ params ++ [Param host]
+	] ++ params ++ [Param (fromSshHost host)]
 boolSystem "sh"
 	[ Param "-c"
 	, Param $ "ssh " ++ cmd ++ " >/dev/null 2>/dev/null"
@@ -99,16 +100,17 @@ sshCleanup = do
 -- Cannot remove the lock file; other processes may
 -- be waiting on our exclusive lock to use it.
 
-hostport2socket :: String -> Maybe Integer -> FilePath
-hostport2socket host Nothing = host
-hostport2socket host (Just port) = host ++ "!" ++ show port
+hostport2socket :: SshHost -> Maybe Integer -> FilePath
+hostport2socket 

Bug#879647: Updating the audacious-plugins Uploaders list

[Tobias Frost]

Source: audacious-plugins
Version: 3.9-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Bilal Akhtar  wishes no longer to be uploader of 
audacious-plugins.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#879646: Updating the audacious Uploaders list

[Tobias Frost]

Source: audacious
Version: 3.9-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Bilal Akhtar  wishes no longer to be uploader of 
audacious.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#879643: debhelper: dh_usrlocal tries to chown to root:group which fails because group is not valid

[Paul Gevers]

control: notfound -1 10.9.1

I just checked and the current version of cacti in sid/buster was build
with debhelper 10.9.1, which resulted in the correct values.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#879264: cannot enter the desktop environment

[Luca Boccassi]

On Sat, 21 Oct 2017 12:34:31 +0200 Michael Biebl 
wrote:
> Control: reassign -1 liglvnd0-nvidia
> Control: forcemerge 878851 -1
> 
> Hi Lu Wang
> 
> Am 21.10.2017 um 12:10 schrieb Lu Wang:
> > Oct 21 16:58:56 lenovo /usr/lib/gdm3/gdm-x-session[16569]: Couldn't
open libGL.so.1: /usr/lib/x86_64-linux-gnu/libGL.so.1: undefined
symbol: _glapi_tls_Current
> > 
> 
> While you see gdm3 failing to start, your underlying problem is a
> botched OpenGL installation coming from the NVIDIA driver. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878851
> 
> I'm reassigning the bug report accordingly.
> 
> Afaics, you should ge able to get back to a usable system by
installing
> liglvnd0 (which will replace libglvnd0-nvidia)
> 
> Regards,
> Michael

Andreas,

Shall we remove the provides? It looks like, for whatever reasons, not
all the symbols are exported by nvidia. Perhaps the bundled glvnd
libraries are too old?

libGLdispatch.so.0 in libglvnd0 exports that symbol.

Kind regards,
Luca Boccassi

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

Bug#814074: taskcoach: It fails to launch (dependence or miscofiguration related to zope.interface)

[Nicolas Boulenguez]

Package: taskcoach
Followup-For: Bug #814074

Hello.
I cannot reproduce this problem, but it is most probably a duplicate
of [1] which is fixed by last upload.
Are you able to reproduce it with taskcoach/1.4.3-5?

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

Bug#877711: firmware-atheros: Wifi connection becomes unreliable after upgrade to 20170823-1

[Brian Tarricone]

I'm seeing the same symptoms (with a "Qualcomm Atheros QCA6174 802.11ac
Wireless Network Adapter (rev 32)"), but it started with me on buster after
upgrading linux-image from 2.11.x to 2.12.x (2.13.x also has the same
issue).  It looks like 2.12 bumped the firmware API version used for this
chipset from 5 to 6, and there's a new firmware-6.bin (& board-2.bin)
available upstream (
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
).

I grabbed the ath10k/QCA6174 directory (commit 4ebfab3 is the latest change
there) and that fixed the issue for me.  Looks like those were last updated
on 20170918, which is newer than the firmware-nonfree/firmware-atheros
package.

 -brian

Bug#879645: wx._core.PyDeadObjectError: in balloontip.py

[Nicolas Boulenguez]

Package: taskcoach
Severity: normal

Hello.
When launching taskcoach from a terminal then moving the main window,
I get lots of message similar to the one described at
https://stackoverflow.com/questions/18198413/wxpython-pydeadobjecterror#18210539
except that the error lies in taskcoachlib/widgets/balloontip.py.

Bug#879644: transition: libzip

[Stefan Schoerghofer]

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

Hi release team,

libzip needs a transistion - I've uploaded the new version to
experimental, will have to go trough NEW first, though.

I don't expect any breakages for binNMUs and will test the build of all
reverse-depends.

Please let me know when I can upload it to unstable.


Cheers,
Stefan


Ben file:

title = "libzip";
is_affected = .depends ~ "libzip4" | .depends ~ "libzip5";
is_good = .depends ~ "libzip5";
is_bad = .depends ~ "libzip4";


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

Bug#879030: 375.82-5: glxgears segmentation fault in glXCreateContext

[Luca Boccassi]

On Sun, 2017-10-22 at 18:32 +0300, Vincas Dargis wrote:
> I managed to fix the crash, somehow.
> 
> I believe it's problem with primus package, as after purging and
> reinstalling nvidia/bumblebee/primus stuff, I got 
> glxgears working, BUT without primus.
> 
> If I try to install primus, apt attempts to remove stuff:
> 
> ```
> The following additional packages will be installed:
>    libgl1-nvidia-glx primus-libs primus-libs-ia32:i386
> The following packages will be REMOVED:
>    libgl1-nvidia-glvnd-glx libgl1-nvidia-glvnd-glx:i386 nvidia-driver 
> nvidia-driver-libs nvidia-driver-libs:i386 
> nvidia-driver-libs-i386:i386
>    nvidia-vulkan-common nvidia-vulkan-icd nvidia-vulkan-icd:i386
> The following NEW packages will be installed:
>    libgl1-nvidia-glx primus primus-libs primus-libs-ia32:i386
> ```

Yes that's intended, Primus cannot work with libglvnd-ized libraries.
If you allow apt to do that it should all work (hopefully).

Kind regards,
Luca Boccassi

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

Bug#879643: debhelper: dh_usrlocal tries to chown to root:group which fails because group is not valid

[Paul Gevers]

Package: debhelper
Version: 10.10.2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

dh_usrlocal adds the following to my maintainerscript for cacti:
# Automatically added by dh_usrlocal/10.10.2
if [ "$1" = configure ]; then
(
while read line; do
set -- $line
dir="$1"; mode="$2"; user="$3"; group="$4"
if [ ! -e "$dir" ]; then
if mkdir "$dir" 2>/dev/null; then
chown "$user":"$group" "$dir"
chmod "$mode" "$dir"
fi
fi
done
) << DATA
/usr/local/share 02775 root group
/usr/local/share/cacti 02775 root group
/usr/local/share/cacti/resource 02775 root group
/usr/local/share/cacti/resource/script_queries 02775 root group
/usr/local/share/cacti/resource/script_server 02775 root group
/usr/local/share/cacti/resource/snmp_queries 02775 root group
/usr/local/share/cacti/scripts 02775 root group
DATA

which is wrong, because group doesn't exist on my system. As a result, the
generated package fails to install (hence the severity). The manual says it
should be saying staff instead. The directories are created by a debian/dirs
file, so they are not created by me with the wrong group during build time
(anyways, also in my build env, that group doesn't exist).

Paul

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlnuR+kACgkQnFyZ6wW9
dQpdEQf/WPcOalD1VZanGIqEYl0H+OaB0gzfmJqfbKcKM5ZOEBeMvtEG1GjlDaG4
PaXUKhlW+NGHwrzN44BrXT76KXkS64eaMYn/H8eZX8TQ+RBKvOmpHHoXTJazCPsY
MW51x+lc77BYANsrfk7Bjvsje69WP4S+rxRCL2NJR01rKJXeqnTfSTqClL8b6KQO
X1rwvYx1N1NYd7P6m/LD2PWniiiYBGKmKV8Ij95T99Hxtg3vyJPm4bWjwNTpSq4R
hkEpxJRH4zVqLBzx1bzACKYoag32uDCFR1lGHQ2qIg1ghHvayCYgyDSNNJjbtdp+
9YdKxJ58qdyRUcMGwlSM4kB7vBMoqg==
=UPbC
-END PGP SIGNATURE-

Bug#879486: Please support "gbp import-dsc" of the downloaded source

[Michael Stapelberg]

control: tags -1 + pending

On Mon, Oct 23, 2017 at 9:38 PM, Guido Günther  wrote:
> Hi,
> On Sun, Oct 22, 2017 at 12:42:29PM +0200, Michael Stapelberg wrote:
>> On Sun, Oct 22, 2017 at 12:28 PM, Guido Günther  wrote:
>> > Hi,
>> > On Sun, Oct 22, 2017 at 11:15:20AM +0200, Michael Stapelberg wrote:
>> >> Thanks for filing this.
>> >>
>> >> On Sun, Oct 22, 2017 at 9:21 AM, Guido Günther  wrote:
>> >> > Package: pk4
>> >> > Version: 2
>> >> > Severity: wishlist
>> >> >
>> >> > Hi,
>> >> > it would be nice if pk4 would allow to use "gbp import-dsc" to unpack
>> >> > the donwloaded sources in downloadDSCAndUnpack so users:
>> >> >
>> >> >- get a git archive right away
>> >> >- can reuise their gbp configuration such as the configured builder,
>> >> >- pristine-tar, ... right away
>> >>
>> >> I think we could introduce a hook which would replace the default
>> >> behavior of dpkg-source -x, taking as arguments the path to the DSC
>> >> and the destination directory.
>> >
>> > Sounds good.
>> >
>> >>
>> >> I wonder whether the gbp hook should live in the git-buildpackage
>> >> Debian package, though? That way, you could maintain it directly. If
>> >
>> > Sure. It would be nice if setup for users would the be as simple as
>> >
>> >   ln -s /usr/share/doc/git-buildpackage/examples/pk4 ~/pk4/pk4.deb822.d/gbp
>>
>> Almost:
>>
>> mkdir -p ~/.config/pk4/hooks-enabled/unpack/
>> ln -s /usr/share/pk4/hooks-available/unpack/gbp \
>> ~/.config/pk4/hooks-enabled/unpack/
>>
>> Regarding the symlink target, could we ship
>> /usr/share/pk4/hooks-available/unpack/gbp in git-buildpackage? That
>> way, all hooks would be in the same directory. This is similar to how
>> shell tab completion files are shipped.
>
> Shipped now with the next gbp version:
>
> https://github.com/agx/git-buildpackage/blob/master/debian/pk4

Neat!

I just committed
https://github.com/Debian/pk4/commit/797dc0b887abbc482a7a095d687b710509a80816,
upload to Debian follows in a second.

One thing I noticed: the resulting branches are master, pk4 and
upstream, which the currently checked out branch being master.
Shouldn’t the only two branches be pk4 and upstream?

>
>> >> you think that’s not a good idea, could you suggest how the hook
>> >> should be implemented? I’m envisioning something like this (untested):
>> >>
>> >> #!/bin/sh
>> >> set -e
>> >> mkdir -p "$2"
>> >> cd "$2"
>> >> git init
>> >> gbp import-dsc "$1"
>> >
>> > #!/bin/sh
>> > set -e
>> > gbp import-dsc "$1" "$2"
>> >
>> > is enough (gbp will do the rest). That way we could also support
>> > incremental imports (that is if the directory is already there we simply
>> > import the new version on top of it so the use can diff between the old
>> > an new version.
>>
>> Note that the pk4 output directories contain the version number, so I
>> think incremental imports wouldn’t work well.
>>
>> >
>> >> Side note: I think we should be fairly clear about the difference
>> >> between a gbp-from-dsc repo and a gbp-from-gbp-clone repo, to not
>> >> confuse our users.
>> >
>> > Yeah. I was thinking of putting a .git/gbp.conf into the repo that sets
>> >
>> >   [DEFAULT]
>> >   upstream-branch = upstream
>> >   debian-branch = pk4
>> >
>> > This would
>> >
>> >  - make sure we override settings any branch settings in debian/gbp.conf
>> >which we don't care about (since we're not cloning from Vcs-Git:
>> >  - Having the default branch named pk4 would make it obvious that this
>> >is s.th. special.
>> >
>> > What do you think? In this case it would rather be more like your script
>> > above:
>>
>> Sounds good to me.
>>
>> >
>> > #!/bin/sh
>> > set -e
>> >
>> > if [ ! -d $2 ]; then
>>
>> nit: use "$2" here as well
>>
>> >
>> >   git init "$2"
>> >
>> >   cat < "$2"/.git/gbp.conf
>>
>> I suggest to add as a comment what you wrote above for the benefit of
>> readers of the hook :).
>>
>> >   [DEFAULT]
>> >   upstream-branch = upstream
>> >   debian-branch = pk4
>> >   EOF
>> > fi
>> >
>> > cd "$2"
>> > gbp import-dsc "$1"
>> >
>> >
>> > Does this sound reasonable? I would then also provide a script that can
>> > be used with pk4-replace.
>>
>> I don’t quite follow. What sort of script is required for that?
>
> Probably not even a script but a post-build hook that cats the name of
> the generated changes file to /proc/self/fd/3.

Ah, I see.

> Cheers,
>  -- Guido



-- 
Best regards,
Michael

Bug#879197: autopkgtest: Please support @testdeps@ i.e. subset of @builddeps@ marked with

[Martin Pitt]

Hello Ximin, all,

Ximin Luo [2017-10-20 12:23 +0200]:
> These days one is able to mark build-dependencies that are needed to run tests
> by annotating the Build-Depends with .
> 
> It would be nice to support a @testdeps@ syntax for Depends: in autopkgtest 
> as a
> convenience alias for all of the Build-Depends that are marked with 
> .
> This helps to avoid duplication and makes it easier to maintain.

 is rather fuzzy.  There is neither a policy nor a reason to require
that *all* test-only dependencies must be marked that way, and this can never
work as some test dependencies are often *also* "real" build dependencies.
Also, these are by no means exhaustive - it's not uncommon to only mark the
"expensive" dependencies with that and let some subset of tests run with the
remaining available packages.

Also, this term is already being used for the package's actual (autopkg)test
dependencies.

As a compromise, I could live with calling this @!nocheck@. This makes it much
clearer what it actually means, and avoids potential confusion. But for the
first reason above I still don't like this much, to be honest.

OOI, is that for an individual package, or a whole group of packages? In the
latter case, using autodep8 might be a better solution?

Thanks,

Martin

Bug#809305: Region & Language "Formats" "United States (English)" uses Metric and A4

[Josh Triplett]

On Mon, Oct 23, 2017 at 11:58:48AM +0200, Laurent Bigonville wrote:
> On Tue, 29 Dec 2015 00:05:43 -0800 Josh Triplett  
> wrote:
> > In the Region & Language dialog, "Formats" says "United States
> > (English)", yet if I click on it to see the details, it shows
> > "Measurement Metric" and "Paper A4". Either the dialog's label of
> > "United States (English)" is incorrect, or what that label maps to is
> > incorrect.
> 
> Could you please try again with a recent version of GNOME?
> 
> I quickly checked with gnome-control-center 3.26.1 and it says US
> Legal/imperial when selecting US English

Still present with 1:3.26.1-2

Screenshot attached.

Note that I use C.UTF-8 as my locale.

- Josh Triplett

Bug#879486: Please support "gbp import-dsc" of the downloaded source

[Guido Günther]

Hi,
On Sun, Oct 22, 2017 at 12:42:29PM +0200, Michael Stapelberg wrote:
> On Sun, Oct 22, 2017 at 12:28 PM, Guido Günther  wrote:
> > Hi,
> > On Sun, Oct 22, 2017 at 11:15:20AM +0200, Michael Stapelberg wrote:
> >> Thanks for filing this.
> >>
> >> On Sun, Oct 22, 2017 at 9:21 AM, Guido Günther  wrote:
> >> > Package: pk4
> >> > Version: 2
> >> > Severity: wishlist
> >> >
> >> > Hi,
> >> > it would be nice if pk4 would allow to use "gbp import-dsc" to unpack
> >> > the donwloaded sources in downloadDSCAndUnpack so users:
> >> >
> >> >- get a git archive right away
> >> >- can reuise their gbp configuration such as the configured builder,
> >> >- pristine-tar, ... right away
> >>
> >> I think we could introduce a hook which would replace the default
> >> behavior of dpkg-source -x, taking as arguments the path to the DSC
> >> and the destination directory.
> >
> > Sounds good.
> >
> >>
> >> I wonder whether the gbp hook should live in the git-buildpackage
> >> Debian package, though? That way, you could maintain it directly. If
> >
> > Sure. It would be nice if setup for users would the be as simple as
> >
> >   ln -s /usr/share/doc/git-buildpackage/examples/pk4 ~/pk4/pk4.deb822.d/gbp
> 
> Almost:
> 
> mkdir -p ~/.config/pk4/hooks-enabled/unpack/
> ln -s /usr/share/pk4/hooks-available/unpack/gbp \
> ~/.config/pk4/hooks-enabled/unpack/
> 
> Regarding the symlink target, could we ship
> /usr/share/pk4/hooks-available/unpack/gbp in git-buildpackage? That
> way, all hooks would be in the same directory. This is similar to how
> shell tab completion files are shipped.

Shipped now with the next gbp version:

https://github.com/agx/git-buildpackage/blob/master/debian/pk4

> >> you think that’s not a good idea, could you suggest how the hook
> >> should be implemented? I’m envisioning something like this (untested):
> >>
> >> #!/bin/sh
> >> set -e
> >> mkdir -p "$2"
> >> cd "$2"
> >> git init
> >> gbp import-dsc "$1"
> >
> > #!/bin/sh
> > set -e
> > gbp import-dsc "$1" "$2"
> >
> > is enough (gbp will do the rest). That way we could also support
> > incremental imports (that is if the directory is already there we simply
> > import the new version on top of it so the use can diff between the old
> > an new version.
> 
> Note that the pk4 output directories contain the version number, so I
> think incremental imports wouldn’t work well.
> 
> >
> >> Side note: I think we should be fairly clear about the difference
> >> between a gbp-from-dsc repo and a gbp-from-gbp-clone repo, to not
> >> confuse our users.
> >
> > Yeah. I was thinking of putting a .git/gbp.conf into the repo that sets
> >
> >   [DEFAULT]
> >   upstream-branch = upstream
> >   debian-branch = pk4
> >
> > This would
> >
> >  - make sure we override settings any branch settings in debian/gbp.conf
> >which we don't care about (since we're not cloning from Vcs-Git:
> >  - Having the default branch named pk4 would make it obvious that this
> >is s.th. special.
> >
> > What do you think? In this case it would rather be more like your script
> > above:
> 
> Sounds good to me.
> 
> >
> > #!/bin/sh
> > set -e
> >
> > if [ ! -d $2 ]; then
> 
> nit: use "$2" here as well
> 
> >
> >   git init "$2"
> >
> >   cat < "$2"/.git/gbp.conf
> 
> I suggest to add as a comment what you wrote above for the benefit of
> readers of the hook :).
> 
> >   [DEFAULT]
> >   upstream-branch = upstream
> >   debian-branch = pk4
> >   EOF
> > fi
> >
> > cd "$2"
> > gbp import-dsc "$1"
> >
> >
> > Does this sound reasonable? I would then also provide a script that can
> > be used with pk4-replace.
> 
> I don’t quite follow. What sort of script is required for that?

Probably not even a script but a post-build hook that cats the name of
the generated changes file to /proc/self/fd/3.
Cheers,
 -- Guido

Bug#750962: [git-buildpackage/master] import-dsc: make sure we don't create 'master' if not needed

[Guido Günther]

tag 750962 pending
thanks

Date:   Mon Oct 23 21:18:18 2017 +0200
Author: Guido Günther 
Commit ID: 01da1e61b003aa7cb576fbe5755a665a12c3f2ba
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=01da1e61b003aa7cb576fbe5755a665a12c3f2ba
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=01da1e61b003aa7cb576fbe5755a665a12c3f2ba

import-dsc: make sure we don't create 'master' if not needed

This way we only get the debian- and upstream-branch in empty repos and
not a pointless 'master' if debian-branch is not set to master.

It also makes sure we don't need --create-missing-branches on empty
repos where it is pointless.

Closes: #750962

  

Bug#879640: chicken: Please update to debhelper short format / enable parallel build

[Tobias Frost]

Source: chicken
Severity: wishlist
Tags: patch

Dear Davide,

in preparation for the NMU I saw that chicken has problems when built parallel 
and did
not build twice in a row. It could have use in an upgrade to a recent 
debhelper/compat
level...

The attached rules files should be in the right direction, however I did not 
check
if I catched everything, but it should be a starting point...

I hope it is of use for you ;-)

Regards,
tobi

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

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
#!/usr/bin/make -f

export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic -fPIC
export DEB_CXXFLAGS_MAINT_APPEND  = -Wall -pedantic -fPIC
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

export PLATFORM=linux
export PREFIX=/usr
export VARDIR=/var/lib
export DEBUGBUILD=1

%:
dh $@ #--no-parallel


override_dh_auto_clean:
dh_auto_clean
grep -l 'Generated from .*\.scm by the CHICKEN compiler' * | xargs rm 
-f || /bin/true
find . -name '*.so' -delete
rm -rf tests/a.out tests/empty-file tests/fft1  tests/fft2 
tests/find-files-test-dir/dir-link-target/bar \
tests/find-files-test-dir/dir-link-target/foo \
tests/find-files-test-dir/file1 tests/find-files-test-dir/file2 
\
tests/rev-app-2/libchicken.so.8 tests/rev-app-2/rev-app 
tests/tmp/xxx \
tests/find-files-test-dir/dir-link-name feathers buildid 
buildtag.h \
tests/scrutiny-2.expected tests/scrutiny-2.out \
tests/scrutiny.out tests/specialization.out 
test-repository/types.db \
tests/test-repository/types.db \
tests/dwindtst.out tests/ec.import.scm tests/m3.import.scm \
tests/num.import.scm tests/r4rstest.log 
tests/reexport-m1.import.scm \
tests/reexport-m3.import.scm tests/reexport-m4.import.scm \
tests/reexport-m5.import.scm tests/reexport-m6.import.scm \
tests/rev-app-2/reverser.setup-info 
tests/reverser/tags/1.0/reverser.import.scm \
tests/reverser/tags/1.1/reverser.import.scm 
tests/square-functor.import.scm \
tests/test-repository/reverser.setup-info tests/tmp.c 
tests/tmp1 tests/tmp2 \
tests/tmp3

override_dh_auto_install:
dh_auto_install -- -j1
chrpath -d $(CURDIR)/debian/tmp/var/lib/chicken/8/*.so

Bug#879641: please consider removing the experimental tag from --three-way

[Marc Haber]

Package: ucf
Version: 3.0036
Severity: wishlist

Hi,

the --three-way option has been in place and documented for fourteen
years. Out of 128 maintainer scripts matching the regexp 'ucf[^rq]', 49
also match "--three-way". And the 128 includes the scripts that only
mention ucf in a comment.

I would like to suggest that the feature has had enough testing. Please
consider removing the warnings.

Greetings
Marc

Bug#879628: bzflag-server: systemd service ignores /etc/default/bzflag

[green]

Markus Koschany wrote at 2017-10-23 13:58 -0500:

Sure. It is now on the todo list for the next update of bzflag.


Excellent, thank you!

Bug#879639: squid takes 30 seconds to restart, should be < 1 second

[Daniel Kahn Gillmor]

Package: squid
Version: 3.5.23-5
Severity: normal

The squid service takes significantly longer to restart than other
network services.  I think it's doing some kind of unnecessary
30-second wait.  Here's a demonstration:

0 root@host:~# time systemctl restart ssh

real0m0.039s
user0m0.013s
sys 0m0.005s
0 root@host:~# time systemctl restart squid

real0m32.192s
user0m0.011s
sys 0m0.005s
0 root@host:~# journalctl -u squid --since '2 minutes ago'
-- Logs begin at Sat 2014-10-11 10:16:57 EDT, end at Mon 2017-10-23 15:13:51 
EDT. --
Oct 23 15:12:31 host systemd[1]: Stopping LSB: Squid HTTP Proxy version 3.x...
Oct 23 15:13:03 host squid[13538]: Squid Parent: (squid-1) process 13540 exited 
with status 0
Oct 23 15:13:03 host squid[13657]: Stopping Squid HTTP Proxy: squid 
Waiting.done.
Oct 23 15:13:03 host squid[13657]: .
Oct 23 15:13:03 host systemd[1]: squid.service: Killing process 13540 (n/a) 
with signal SIGKILL.
Oct 23 15:13:03 host systemd[1]: squid.service: Killing process 13540 (n/a) 
with signal SIGKILL.
Oct 23 15:13:03 host systemd[1]: Stopped LSB: Squid HTTP Proxy version 3.x.
Oct 23 15:13:03 host systemd[1]: Starting LSB: Squid HTTP Proxy version 3.x...
Oct 23 15:13:03 host squid[13723]: Squid Parent: will start 1 kids
Oct 23 15:13:03 host squid[13723]: Squid Parent: (squid-1) process 13725 started
Oct 23 15:13:03 host squid[13685]: Starting Squid HTTP Proxy: squid.
Oct 23 15:13:03 host systemd[1]: squid.service: PID file /var/run/squid.pid not 
readable (yet?) after start: No such file or directory
Oct 23 15:13:03 host systemd[1]: squid.service: Supervising process 13725 which 
is not our child. We'll most likely not notice when it exits.
Oct 23 15:13:03 host systemd[1]: Started LSB: Squid HTTP Proxy version 3.x.
0 root@host:~# grep '^[^#]' /etc/squid/squid.conf 
acl SSL_ports port 443
acl Safe_ports port 80  # http
acl Safe_ports port 21  # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70  # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny all
http_port 3128
coredump_dir /var/spool/squid
refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
refresh_pattern .   0   20% 4320
0 root@host:~# df -h /var/spool/squid/
Filesystem Size  Used Avail Use% Mounted on
/dev/mapper/vg_host0-var  5.4G  4.1G 1009M  81% /var
0 root@host:~#

There is no additional CPU or disk or network activity during the
shutdown that i can see.  So this looks like a deliberate 30 second
delay, and systemd is issuing a SIGKILL.  This doesn't seem
like a good idea.

If there is any debugging information you want from me, i'm happy to
try to provide it.

Thanks for maintaining squid in debian!

   --dkg

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 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 squid depends on:
ii  adduser  3.116
ii  libc62.24-17
ii  libcap2  1:2.25-1.1
ii  libcomerr2   1.43.7-1
ii  libdb5.3 5.3.28-13.1
ii  libdbi-perl  1.637-1
ii  libecap3 1.0.1-3.2
ii  libexpat12.2.3-1
ii  libgcc1  1:7.2.0-11
ii  libgssapi-krb5-2 1.15.1-2
ii  libkrb5-31.15.1-2
ii  libldap-2.4-22.4.45+dfsg-1
ii  libltdl7 2.4.6-2
ii  libnetfilter-conntrack3  1.0.6-2
ii  libnettle6   3.3-2
ii  libpam0g 1.1.8-3.6
ii  libsasl2-2   2.1.27~101-g0780600+dfsg-3
ii  libstdc++6   7.2.0-11
ii  libxml2  2.9.4+dfsg1-5
ii  logrotate3.11.0-0.1
ii  lsb-base 9.20170808
ii  netbase  5.4
ii  squid-common 3.5.23-5

Versions of packages squid recommends:
ii  libcap2-bin  1:2.25-1.1

Versions of packages squid suggests:
pn  resolvconf   
ii  smbclient2:4.6.7+dfsg-2
pn  squid-cgi
pn  squid-purge  
pn  squidclient  
pn  ufw  
pn  winbindd 

Bug#879529: transition: perl 5.26.1

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

Hi Niko,

On 22/10/17 17:36, Niko Tyni wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> perl 5.26.1-1 is in experimental. It is binary compatible with 5.26.0
> and therefore Provides both perlapi-5.26.0 and perlapi-5.26.1. However,
> four binNMUs will be needed once it enters unstable due to their strict
> versioned dependencies on the current perl version:
> 
>  libpar-packer-perl
>  libdevel-cover-perl
>  libclass-xsaccessor-perl
>  libcommon-sense-perl
> 
> Please let us know if/when it's OK to upload.

Please go ahead.

> Given the tiny scope of this transition, I wasn't quite sure whether I
> should file a bug, or just upload and ask for binNMUs later. Please let me
> know if you'd like to see similar cases handled differently in the future.

Either way is fine with me.

Cheers,
Emilio

Bug#879519: transition: rtaudio

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 23/10/17 12:58, Jaromír Mikeš wrote:
> Od: Jaromír Mikeš 
> 
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> new upstream rtaudio bumps SONAME, so we need to transition.
> 
> Direct reverse dependencies are:
> 
> stk
> jacktrip
> mlt
> soapyaudio
> cubicsdr 
> 
> 
> 
>   Hi,
> 
> 
> I tested all packages to build against librtaudio-dev 5.0.0 and they build 
> fine 
> without any patch needed.

Go ahead.

Emilio

Bug#879520: transition: rtmidi

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 23/10/17 12:56, Jaromír Mikeš wrote:
> 
> Od: Jaromír Mikeš 
> 
> 
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> new upstream rtmidi bumps SONAME, so we need transition.
> 
> Direct reverse dependencies are:
> 
> stk
> giada
> midisnoop
> milkytracker
> python3-rtmidi 
> 
> 
>   Hi,
> 
> 
> I tested all packages (except giada ) to build against librtmidi-dev 3.0.0 
> and 
> they build fine without any patch needed.
> 
> giada doesn't built  with current gcc version which I hope will be soon fixed 
> by 
> upstream. I assume giada will build fine with new rtmidi too as other 
> packages.

giada is not in testing, so not a problem.

Go ahead.

Emilio

Bug#879638: pygobject: Update to 3.26

[Jeremy Bicha]

Source: pygobject
Version: 3.24.1-3
Severity: wishlist

pygobject 3.26 has been released. It requires pycairo to be updated.

https://git.gnome.org/browse/pygobject/tree/NEWS?h=pygobject-3-26

Thanks,
Jeremy Bicha

Bug#879628: bzflag-server: systemd service ignores /etc/default/bzflag

[green]

Markus Koschany wrote at 2017-10-23 12:43 -0500:

This is documented in README.Debian. The /etc/default/bzflag is
deprecated and only valid if you use the old sysV-init system.


Okay. Could this be mentioned in the /etc/default/bzflag file?

Bug#879628: bzflag-server: systemd service ignores /etc/default/bzflag

[Markus Koschany]

Am 23.10.2017 um 20:56 schrieb green:
> Markus Koschany wrote at 2017-10-23 12:43 -0500:
>> This is documented in README.Debian. The /etc/default/bzflag is
>> deprecated and only valid if you use the old sysV-init system.
> 
> Okay. Could this be mentioned in the /etc/default/bzflag file?

Sure. It is now on the todo list for the next update of bzflag.



signature.asc
Description: OpenPGP digital signature

Bug#878203: AA breaks libvirt when running with kernel 4.13

[Guido Günther]

control: severity -1 minor
control: retitle -1 apparmor logs /proc//cmdline denials on vm shutdown

Hi,
On Mon, Oct 23, 2017 at 06:41:04PM +0200, Michael Biebl wrote:
> Am 23.10.2017 um 18:28 schrieb Guido Günther:
> > Hi,
> > On Mon, Oct 23, 2017 at 06:22:10PM +0200, Michael Biebl wrote:
> >> Am 23.10.2017 um 17:49 schrieb Guido Günther:
> 
> >> This is what I get when I *shut down* a VM in virt-manager:
> >> $ journalctl -f | grep DENIED
> >> Okt 23 18:20:31 pluto audit[8603]: AVC apparmor="DENIED"
> >> operation="open" profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> >> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
> >> requested_mask="r" denied_mask="r" fsuid=114 ouid=0
> >> Okt 23 18:20:31 pluto kernel: audit: type=1400 audit(1508775631.299:55):
> >> apparmor="DENIED" operation="open"
> >> profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> >> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
> >> requested_mask="r" denied_mask="r" fsuid=114 ouid=0
> > 
> > I can produce this msg on shutdown (I assumed it to be on VM start) but
> > what does break?
> 
> No idea. I don't see any immediate breakage related to those denials.

Ahh...I didn't see your comment in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878203#25

and intrigeri's

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878203#30

and the bug title sounded alarming. It's harmless but should be fixed
though.

Cheers,
 -- Guido

Bug#879637: mariadb-10.1: FTBFS on mips64el due to test failures

[Bas Couwenberg]

Source: mariadb-10.1
Version: 10.1.28-1
Severity: serious
Justification: makes the package in question unusable or mostly so
Control: affects -1 src:gdal

Dear Maintainer,

mariadb-10.1 (10.1.28-1) FTBFS on mips64el, and the missing binaries are
blocking testing migration of mariadb-10.1 and its reverse dependencies.

For the full build logs, see:

 
https://buildd.debian.org/status/logs.php?arch=mips64el=mariadb-10.1=10.1.28-1

Please fix this ASAP or consider ignoring the test failure.

Kind Regards,

Bas

Bug#879635: gobby: build against libinfinity-0.7-dev

[Emilio Pozuelo Monfort]

Package: gobby
Version: 0.5.0-8.1
Severity: serious

libinfinity bumped to 0.7. Please build against the new version.

Emilio

Bug#879636: openvdb: FTBFS on mips(el): virtual memory exhausted: Cannot allocate memory

[Emilio Pozuelo Monfort]

Source: openvdb
Version: 4.0.2-1
Severity: serious

Your package failed to build on mips(el):

g++ -c -g -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-fvisibility=hidden -fvisibility-inlines-hidden -O1 -std=c++11 -pthread -g -I . 
-I .. -I /usr/include -I /usr/include/OpenEXR -I /usr/include -I /usr/include 
-I /usr/include -DOPENVDB_USE_BLOSC -DOPENVDB_USE_LOG4CPLUS 
-DOPENVDB_USE_GLFW_3 -I /usr/include -fPIC -o unittest/TestUtil.o 
unittest/TestUtil.cc
virtual memory exhausted: Cannot allocate memory
Makefile:861: recipe for target 'unittest/TestTools.o' failed

sh4 also seems affected by this.

Full logs at https://buildd.debian.org/status/package.php?p=openvdb

Emilio

Bug#879634: FTBFS without bumped apr/apr-utils build-depends on stretch

[Daniel Baumann]

Package: apache2
Version: 2.4.29-1
Severity: wishlist

Hi,

apache2 now FTBFS without apr/apr-utils >= 1.6 on stretch (I'm doing
local backports), it would be nice if you could bump build-depends
accordingly to document that.

Regards,
Daniel

Bug#879584: apparmor: Pin the AppArmor feature set to Linux 4.12's or 4.13's until our policy has been updated for Linux 4.14

[John Johansen]

On 10/23/2017 10:30 AM, intrigeri wrote:
> Hi,
> 
> (John, there's a question for you below and I'll like you to
> double-check my testing procedure :)
> 
> intrigeri:
>>> 1. in testing/sid, ship a conffile (in a package built from
>>>src:apparmor) that pins the most recent feature set fully supported
>>>by our policy, i.e. Linux 4.12's or 4.13's (depending on whether
>>>we've fixed all the regressions brought by 4.13 yet); this should
>>>make the transition to Linux 4.14 smooth;
> 
> Implemented locally.
> 
> All test results below look good to me so I'll wait for John's answer
> and will then upload to id.
> 
> Sadly, that this is not fully effective in the specific case of
> 4.14-rcN up to 4.14-rc6 due to a kernel bug with pinned older feature
> sets, that will likely be fixed in Linux 4.14-rc7. For example, with
> Linux 4.14-rc5 some network (e.g. unix, inet, inet6) operations are
> denied despite the fact this pinned feature does not enable network
> mediation support. For details, see:
> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1721278
> A fix is being tested and will hopefully be sent to Linus today.
> 
Testing so far has been good, I have a volunteer who has been encountering
this issue testing as well.

>> I'll need to test what happens when upgrading the feature set file +
>> Linux in lockstep, when the new feature set includes features brought
>> by the Linux upgrade and not supported by the running kernel.
>> This will happens when upgrading to the next Debian stable, or on
>> a rarely upgraded testing/sid system. It'll be solved on reboot but
>> I want to ensure the package upgrade succeeds.
> 
> It seems to work just fine. Here's how I tested it:
> 
> 1. boot sid with Linux 4.14-rc5 from experimental
> 2. save the 4.14-rc5 feature set:
>cp /etc/apparmor.d/cache/.features /etc/apparmor/features-4.14
this step is likely not needed as apparmor will detect the feature
set doesn't match and update the features as it recompiles to the
new feature set. That is unless you have not enabled writing cache
files during init, in which case apparmor will just not update the
cache file and basically you won't get cache hits except for on
kernels that match those of the feature file.

> 3. boot sid with Linux 4.13 from sid
might want to test that the features file was updated, a timestamp
since boot should be all you need to check

> 4. save the 4.13 feature set to /etc/apparmor/features:
>cp /etc/apparmor.d/cache/.features /etc/apparmor/features
> 5. add features-file=/etc/apparmor/features to /etc/apparmor/parser.conf
> 6. reboot on Linux 4.13 again
> 7. cp /etc/apparmor/features{-4.14,}
this step is not needed

> 8. systemctl restart apparmor
this step is not needed either, but if you want to get the service
message without digging it shouldn't hurt either.

> 9. look at what happened:
>- apparmor.service was successfully restarted
>- the restart logs say 'apparmor="STATUS"
>  operation="profile_replace" info="same as current profile,
>  skipping"'
>- the policy has been successfully reloaded (actually not as said
>  above, but that's fine)
>- the output of aa-status is what I would expect
> 
looks good

> I'm kinda surprised that apparmor_parser does not complain about being
> explicitly told to enable features that the kernel does not support,

Well it can, you can use
--warn=rule-downgraded

which means some enforcement of the rule but at a coarser level, eg.
a unix rule to network unix,

and
--warn=rule-not-enforced

which means no enforcement

you can enable them by default by setting them in /etc/apparmor/parser.conf

# enable rule downgrade warnings by default
warn=rule-not-enforced
warn=rule-downgraded

see
apparmor_parser --help=warn for all supported options in a given parser

what currently isn't supported is failing the compile based on enforcement
being downgraded or not enforced.

btw that trick works for Optimize and Dump
apparmor_parser --help=O
apparmor_parser --help=D



> but OTOH its --help says "--features-file n Use only features in file
> n" that I understand as the features file is only used to exclude
> features not listed in there, and the parser actually uses the
> intersection of the features specified in that file and the features
> actually supported by the kernel. John, did I guess right?
> 
nope, but the result is the same.

It will compile it to the given feature set. If the kernel supports
that given abi it will then do the other half providing the intersection.

This is done to allow policies from different versions to be loaded and
used simultaneously. Think of a buster host running an lxd stretch
guest, sharing the same kernel but enforcing different version of
policy.

>> A special case of this general problem is when one intentionally runs
>> an older kernel than the one whose feature set we've pinned. I did not
>> test this yet. My understanding is that the worst that can happens is
>> that one gets 

Bug#879633: knot secondary fails to transfer zone from primary

[Jens Meißner]

Source: knot
Version: 2.4.0-3+deb9u1
Severity: normal

Hi,

we are using knot as secondary name server with powerdns as primary.

With the version of knot shipped with stretch the zone transfer always fails
with the following error message:

Oct 23 18:42:02 ns1 knotd[7587]: info: [example.org.] refresh, outgoing,
192.0.2.53@53: remote serial 2017102301, zone is outdated
Oct 23 18:42:02 ns1 knotd[7587]: info: [example.org.] IXFR, incoming,
192.0.2.53@53: starting
Oct 23 18:42:02 ns1 knotd[7587]: warning: [example.org.] IXFR, incoming,
192.0.2.53@53: failed (malformed data)
Oct 23 18:42:02 ns1 knotd[7587]: warning: [example.org.] refresh, outgoing,
192.0.2.53@53: fallback to AXFR
Oct 23 18:42:02 ns1 knotd[7587]: warning: [example.org.] refresh, remote
'master' not usable
Oct 23 18:42:02 ns1 knotd[7587]: error: [example.org.] refresh, failed (no
usable master)

After several minutes the transfer is retried and fails again with the same
error.

The bug is fixed upstream already. The corresponding commit is:
https://gitlab.labs.nic.cz/knot/knot-
dns/commit/b4ff623a1fbe410e1ab2eaa3413f38f613190b8a
More information about this bug can be found on the knot mailing list:
https://lists.nic.cz/pipermail/knot-dns-users/2017-January/001043.html

An adapted patch for the knot version in stretch is attached to this message.

Regards,
Jens
diff -rNu a/src/knot/events/handlers/refresh.c 
b/src/knot/events/handlers/refresh.c
--- a/src/knot/events/handlers/refresh.c2017-01-18 16:35:39.0 
+0100
+++ b/src/knot/events/handlers/refresh.c2017-10-23 19:15:30.125334866 
+0200
@@ -748,6 +748,7 @@
REFRESH_LOG(LOG_WARNING, data->zone->name, data->remote,
"fallback to AXFR");
ixfr_cleanup(data);
+   layer->flags |= KNOT_RQ_LAYER_CLOSE;
data->is_ixfr = false;
return KNOT_STATE_RESET;
}
diff -rNu a/src/knot/query/layer.h b/src/knot/query/layer.h
--- a/src/knot/query/layer.h2017-01-18 16:35:39.0 +0100
+++ b/src/knot/query/layer.h2017-10-23 19:15:30.125334866 +0200
@@ -48,6 +48,7 @@
void *data;   //!< Module specific.
const struct knot_layer_api *api;
tsig_ctx_t *tsig; //!< TODO: remove
+   unsigned flags;   //!< Custom flags.
 };
 
 /*! \brief Packet processing module API. */
diff -rNu a/src/knot/query/requestor.c b/src/knot/query/requestor.c
--- a/src/knot/query/requestor.c2017-01-18 16:35:39.0 +0100
+++ b/src/knot/query/requestor.c2017-10-23 19:15:30.125334866 +0200
@@ -197,6 +197,14 @@
knot_layer_reset(>layer);
tsig_reset(>tsig);
 
+   if (req->layer.flags & KNOT_RQ_LAYER_CLOSE) {
+   req->layer.flags &= ~KNOT_RQ_LAYER_CLOSE;
+   if (last->fd >= 0) {
+   close(last->fd);
+   last->fd = -1;
+   }
+   }
+
if (req->layer.state == KNOT_STATE_RESET) {
return KNOT_LAYER_ERROR;
}
diff -rNu a/src/knot/query/requestor.h b/src/knot/query/requestor.h
--- a/src/knot/query/requestor.h2017-01-18 16:35:39.0 +0100
+++ b/src/knot/query/requestor.h2017-10-23 19:15:30.125334866 +0200
@@ -31,6 +31,10 @@
KNOT_RQ_UDP = 1 << 0  /* Use UDP for requests. */
 };
 
+enum {
+   KNOT_RQ_LAYER_CLOSE = 1 << 0
+};
+
 /*! \brief Requestor structure.
  *
  *  Requestor holds a FIFO of pending queries.
@@ -48,7 +52,6 @@
knot_pkt_t *query;
knot_pkt_t *resp;
tsig_ctx_t tsig;
-   knot_layer_t layer;
 
knot_sign_context_t sign; /* TODO: Remove. Used in updates only, should
 be part of the zone update context. */

Bug#879632: Add support non standard CPER section and ARM events

[dann frazier]

Source: rasdaemon
Version: 0.5.8-1
Severity: important

rasdaemon 0.6.0 contains some useful updates for ARM, specifically:
  
http://git.infradead.org/users/mchehab/rasdaemon.git/commitdiff/624d8a1d99a2f3bd06cbc537aff3cc30201ba7c2
  
http://git.infradead.org/users/mchehab/rasdaemon.git/commitdiff/0df707235f0573e5686742a77c4b141205a6b0ca
  
http://git.infradead.org/users/mchehab/rasdaemon.git/commitdiff/5662e5376adcc45da43d7818c8ac1882883c18ac
  
http://git.infradead.org/users/mchehab/rasdaemon.git/commitdiff/982899ef7ea87dd273b597ae0db4f862f573af46

Happy to supply an NMU at the mantainer's request :) (Either a bump to
0.6.0, or selective backports).

  -dann

Bug#879631: python3-flask-socketio: missing dependency

[astian]

Package: python3-flask-socketio
Version: 2.9.0-1
Severity: serious

Dear Maintainer,

This package lacks a dependency on the upstream "python-socketio" [0],
which provides a "socketio" module.  Please do not confuse it with the
Debian package of the same name, which also provides a "socketio": that
package is actually "gevent-socketio" [1] and incompatible with
python3-flask-socketio [2].

  0: https://github.com/miguelgrinberg/python-socketio/
  1: https://github.com/abourget/gevent-socketio
  2: From flask_socketio/__init__.py:
   if gevent_socketio_found:
   print('The gevent-socketio package is incompatible with this version 
of '
 'the Flask-SocketIO extension. Please uninstall it, and then '
 'install the latest version of python-socketio in its place.')
   sys.exit(1)

It seems that the required package is not currently packaged in Debian,
unfortunately.  As is, python3-flask-socketio is useless.  Further
justification for "serious" severity: Debian policy manual section 3.5
[3].

  3: https://www.debian.org/doc/debian-policy/#dependencies

Cheers.

PS: The package tracker at  says:

  action needed
  Problems while searching for a new upstream version


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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 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: systemd (via /run/systemd/system)

Versions of packages python3-flask-socketio depends on:
ii  python3   3.6.3-1
ii  python3-engineio  1.6.1-1
ii  python3-flask 0.12.2-2

python3-flask-socketio recommends no packages.

python3-flask-socketio suggests no packages.

-- no debconf information

Bug#879628: bzflag-server: systemd service ignores /etc/default/bzflag

[Markus Koschany]

Am 23.10.2017 um 19:31 schrieb Owen Heisler:
> Package: bzflag-server
> Version: 2.4.8-1
> Severity: normal
> 
> The default /etc/default/bzflag includes the line `RUN_AT_STARTUP="no"`,
> but the bzfs process still starts. The systemd service file at
> /lib/systemd/system/bzflag.service ignores /etc/default/bzflag entirely,
> using fixed values instead.
> 
> The expected behavior is that bzfs will *not* start when RUN_AT_STARTUP=no.

This is documented in README.Debian. The /etc/default/bzflag is
deprecated and only valid if you use the old sysV-init system. With
systemd you can disable the server with the command

systemctl disable bzflag.service

It would be possible to modify the service file and take the value of
RUN_AT_STARTUP into account but this seems like a duplication of
available systemd functionality in this case. Sometime in the future
/etc/default/bzflag will be completely removed from this package.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#879630: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2017c

[gregor herrmann]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've prepared an update for libdatetime-timezone-perl in jessie which
incorporates the changes from the Olson db 2017c release.
The changes are in a quilt patch and touch only the data files in
lib/DateTime/TimeZone.

2017c contains recent changes to a couple of timezones, the first
change happening this weekend (2017-10-29) in North Cyprus, so this
might be material for jessie-updates before a next point release.
Cf. https://mm.icann.org/pipermail/tz-announce/2017-October/47.html

A manually stripped down debdiff is attached.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlnuKTxfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaJQw/9HvCfmTSa3DP1Cmezxsw68+ot9CHjzYO3+3zk53NiB8wECj3TT5Ot8RNq
q49w0gxMj+ACmW44GYwHbT9+IUkkvtWMLWG2z304Ko0ykOJEB1UdLC4Ev4/HE5Dp
NUMWq1ZVWG7HskuKSoD1yrmJUnsutMbFAMvLwWmuxkP7RBThmNrdv8Yo5GrFWc1f
yIOLI5tD4y9k7eR89EB0iiTib7mE1hJZxkIf6DKhPur+uq+us4M0eW60HG4TV63P
MLK0jBdQ+AJZyvsBdtd0y1LBWujvHjAj0+YTf39mBUetRPpdTHYp5w4D65i/k08C
gS71acqF2hDBsbJ2v2kX19Lo87RNdVNyt1ie05VzVmpwXSQ2lPXLSlv1BoTqP+Ii
ke/kLsoJfdKJbEQIw6ROzOQ/PsFrIlAPQIhUsHp0qERrmQ3hAFd3zffBmgUR6R1R
JIIe0iwFUOkcayQkdBSJ642Xme3jiJixTA3TBEC97Z0+9csJc2HqHxXMVq7WMO8j
jr+453kued5QL4PK7dNdAMIkRftEG+WLdCvpdlSH5z6OZfpJyFgjUkHAzDfhhMHt
FTH9IPLCYxfP7J9KdUz7l/+DoRoLIQQdAftBEIy6XOE8eiDYrOWXLJZIGlSyifPd
ZD2N8drZ6gE0tcOeMBORdYUxZDa9XTS0l5/XRIbaUiKH/3PB2cg=
=UfK7
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-1.75/debian/changelog 
libdatetime-timezone-perl-1.75/debian/changelog
--- libdatetime-timezone-perl-1.75/debian/changelog 2017-04-02 
22:32:45.0 +0200
+++ libdatetime-timezone-perl-1.75/debian/changelog 2017-10-23 
19:10:12.0 +0200
@@ -1,3 +1,11 @@
+libdatetime-timezone-perl (1:1.75-2+2017c) UNRELEASED; urgency=medium
+
+  * Update to Olson database version 2017c.
+This update contains contemporary changes for Northern Cyprus, Fiji,
+Namibia, Sudan, Tonga, and Turks & Caicos.
+
+ -- gregor herrmann   Mon, 23 Oct 2017 19:10:12 +0200
+
 libdatetime-timezone-perl (1:1.75-2+2017b) jessie; urgency=medium
 
   * Update to Olson database version 2017b.
diff -Nru libdatetime-timezone-perl-1.75/debian/patches/olson-2017c 
libdatetime-timezone-perl-1.75/debian/patches/olson-2017c
--- libdatetime-timezone-perl-1.75/debian/patches/olson-2017c   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-1.75/debian/patches/olson-2017c   2017-10-23 
19:10:12.0 +0200
@@ -0,0 +1,11569 @@
+Description: update to olson db 2017c
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2017-10-23
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2017b
++# Generated from debian/tzdata/africa.  Olson data version 2017c
+ #
+ # Do not edit this file directly.
+ #
+@@ -39,7 +39,7 @@
+ ],
+ ];
+ 
+-sub olson_version { '2017b' }
++sub olson_version { '2017c' }
+ 
+ sub has_dst_changes { 0 }
+ 
+--- a/lib/DateTime/TimeZone/Asia/Famagusta.pm
 b/lib/DateTime/TimeZone/Asia/Famagusta.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/asia.  Olson data version 2017b
++# Generated from debian/tzdata/asia.  Olson data version 2017c
+ #
+ # Do not edit this file directly.
+ #
+@@ -795,18 +795,216 @@
+ ],
+ [
+ 63608965200, #utc_start 2016-09-07 21:00:00 (Wed)
+-DateTime::TimeZone::INFINITY, #  utc_end
++63644922000, #  utc_end 2017-10-29 01:00:00 (Sun)
+ 63608976000, #  local_start 2016-09-08 00:00:00 (Thu)
+-DateTime::TimeZone::INFINITY, #local_end
++63644932800, #local_end 2017-10-29 04:00:00 (Sun)
+ 10800,
+ 0,
+ '+03',
+ ],
++[
++63644922000, #utc_start 2017-10-29 01:00:00 (Sun)
++63657622800, #  utc_end 2018-03-25 01:00:00 (Sun)
++63644929200, #  local_start 2017-10-29 03:00:00 (Sun)
++6365763, #local_end 2018-03-25 03:00:00 (Sun)
++7200,
++0,
++'EET',
++],
++[
++63657622800, #utc_start 2018-03-25 01:00:00 (Sun)
++63676371600, #  utc_end 2018-10-28 01:00:00 (Sun)
++63657633600, #  local_start 2018-03-25 04:00:00 (Sun)
++63676382400, #local_end 2018-10-28 04:00:00 (Sun)
++10800,
++1,
++'EEST',
++],
++[
++63676371600, #utc_start 2018-10-28 01:00:00 (Sun)
++63689677200, #  utc_end 2019-03-31 01:00:00 (Sun)
++63676378800, #  local_start 2018-10-28 03:00:00 (Sun)
++63689684400, #local_end 2019-03-31 03:00:00 (Sun)
++7200,
++0,
++'EET',
++],
++[
++63689677200, #utc_start 2019-03-31 01:00:00 

Bug#879629: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2017c

[gregor herrmann]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've prepared an update for libdatetime-timezone-perl in stretch which
incorporates the changes from the Olson db 2017c release.
The changes are in a quilt patch and touch only the data files in
lib/DateTime/TimeZone.

2017c contains recent changes to a couple of timezones, the first
change happening this weekend (2017-10-29) in North Cyprus, so this
might be material for stretch-updates before a next point release.
Cf. https://mm.icann.org/pipermail/tz-announce/2017-October/47.html

A manually stripped down debdiff is attached.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlnuKTpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYFHQ/9GnSly2C/fEM9MeXIOhI4TPUiO9VvYRiCj1LeKglDjkEW0CkvVrcM7ZRX
THyMwXHcHsvKQy55Qsu4pZM8/zO0whuOplaeDS+WahWr770tKCTS3tZvVjNdzYdo
cTK70/zryhXy6Ycdd91UuYu1yE39eBR9iVbLQLZcG2vMMWo5yXZX7UyuAtZFKHxx
bZmxDwnCVYgnfQJXqY09dmIyfoY7UuOo8Z8bKeWGrSuwaG10u7J9mMqlNYEPMH6G
9MZ5i6+OSn+mCLaU+/o78UshGMxFoWI6shFHyXg3LBN2XFzlU66cnqb2zXA4PHaA
gj17aooxGGxW+T0vwY8Pw3VrNZlnDENA8XJCOkqdNqBJVfFuhffExsb8YbiL2O4O
iIQMjC9tWnskyWpz+BY6I8W1M1OYI3cxmG1QG5S6YvAeIM4F8AdgF/UHX6tcvJ9H
MuQZe9mB8mMmfIypwxodU/YRmmLBCl72kQfVTOZOmM/yXy2b3YK77byDIdpveq6l
/CJRMguTZpDa4UG+ZL66ViayLoiL6jfFrmNq6rqRwiDA9hiwHhawqlN6vfIr1Qp3
wIll1weOiEg+c7POpsM0AHUDxHJa0tclL0FcERF8e3tzAlLv6qKqe4DwqRLtcTv8
6KW8sQib7dMCrk/X0Zln3Zn/694oqj1IvKL4AWLLCmdynvDvedA=
=l9J2
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.09/debian/changelog 
libdatetime-timezone-perl-2.09/debian/changelog
--- libdatetime-timezone-perl-2.09/debian/changelog 2017-03-24 
20:02:23.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/changelog 2017-10-23 
19:24:29.0 +0200
@@ -1,3 +1,11 @@
+libdatetime-timezone-perl (1:2.09-1+2017c) UNRELEASED; urgency=medium
+
+  * Update to Olson database version 2017c.
+This update contains contemporary changes for Northern Cyprus, Fiji,
+Namibia, Sudan, Tonga, and Turks & Caicos.
+
+ -- gregor herrmann   Mon, 23 Oct 2017 19:24:29 +0200
+
 libdatetime-timezone-perl (1:2.09-1+2017b) unstable; urgency=medium
 
   * Update to Olson database version 2017b.
diff -Nru libdatetime-timezone-perl-2.09/debian/patches/olson-2017c 
libdatetime-timezone-perl-2.09/debian/patches/olson-2017c
--- libdatetime-timezone-perl-2.09/debian/patches/olson-2017c   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/patches/olson-2017c   2017-10-23 
19:24:29.0 +0200
@@ -0,0 +1,11512 @@
+Description: update to olson db 2017c
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2017-10-23
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2017b
++# Generated from debian/tzdata/africa.  Olson data version 2017c
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2017b'}
++sub olson_version {'2017c'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/Asia/Famagusta.pm
 b/lib/DateTime/TimeZone/Asia/Famagusta.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/asia.  Olson data version 2017b
++# Generated from debian/tzdata/asia.  Olson data version 2017c
+ #
+ # Do not edit this file directly.
+ #
+@@ -799,18 +799,216 @@
+ ],
+ [
+ 63608965200, #utc_start 2016-09-07 21:00:00 (Wed)
+-DateTime::TimeZone::INFINITY, #  utc_end
++63644922000, #  utc_end 2017-10-29 01:00:00 (Sun)
+ 63608976000, #  local_start 2016-09-08 00:00:00 (Thu)
+-DateTime::TimeZone::INFINITY, #local_end
++63644932800, #local_end 2017-10-29 04:00:00 (Sun)
+ 10800,
+ 0,
+ '+03',
+ ],
++[
++63644922000, #utc_start 2017-10-29 01:00:00 (Sun)
++63657622800, #  utc_end 2018-03-25 01:00:00 (Sun)
++63644929200, #  local_start 2017-10-29 03:00:00 (Sun)
++6365763, #local_end 2018-03-25 03:00:00 (Sun)
++7200,
++0,
++'EET',
++],
++[
++63657622800, #utc_start 2018-03-25 01:00:00 (Sun)
++63676371600, #  utc_end 2018-10-28 01:00:00 (Sun)
++63657633600, #  local_start 2018-03-25 04:00:00 (Sun)
++63676382400, #local_end 2018-10-28 04:00:00 (Sun)
++10800,
++1,
++'EEST',
++],
++[
++63676371600, #utc_start 2018-10-28 01:00:00 (Sun)
++63689677200, #  utc_end 2019-03-31 01:00:00 (Sun)
++63676378800, #  local_start 2018-10-28 03:00:00 (Sun)
++63689684400, #local_end 2019-03-31 03:00:00 (Sun)
++7200,
++0,
++'EET',
++],
++[
++63689677200, #utc_start 2019-03-31 01:00:00 

Bug#879628: bzflag-server: systemd service ignores /etc/default/bzflag

[Owen Heisler]

Package: bzflag-server
Version: 2.4.8-1
Severity: normal

The default /etc/default/bzflag includes the line 
`RUN_AT_STARTUP="no"`, but the bzfs process still starts. The systemd 
service file at /lib/systemd/system/bzflag.service ignores 
/etc/default/bzflag entirely, using fixed values instead.


The expected behavior is that bzfs will *not* start when 
RUN_AT_STARTUP=no.


-- System Information:
Debian Release: 9.2
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/8 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 bzflag-server depends on:
ii  init-system-helpers  1.48
ii  libc-ares2   1.12.0-1+deb9u1
ii  libc62.24-11+deb9u1
ii  libcurl3-gnutls  7.52.1-5+deb9u1
ii  libgcc1  1:6.3.0-18
ii  libncurses5  6.0+20161126-1+deb9u1
ii  libstdc++6   6.3.0-18
ii  libtinfo56.0+20161126-1+deb9u1
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-5

bzflag-server recommends no packages.

bzflag-server suggests no packages.

-- debconf-show failed


signature.asc
Description: PGP signature

Bug#879584: apparmor: Pin the AppArmor feature set to Linux 4.12's or 4.13's until our policy has been updated for Linux 4.14

[intrigeri]

Hi,

(John, there's a question for you below and I'll like you to
double-check my testing procedure :)

intrigeri:
>> 1. in testing/sid, ship a conffile (in a package built from
>>src:apparmor) that pins the most recent feature set fully supported
>>by our policy, i.e. Linux 4.12's or 4.13's (depending on whether
>>we've fixed all the regressions brought by 4.13 yet); this should
>>make the transition to Linux 4.14 smooth;

Implemented locally.

All test results below look good to me so I'll wait for John's answer
and will then upload to id.

Sadly, that this is not fully effective in the specific case of
4.14-rcN up to 4.14-rc6 due to a kernel bug with pinned older feature
sets, that will likely be fixed in Linux 4.14-rc7. For example, with
Linux 4.14-rc5 some network (e.g. unix, inet, inet6) operations are
denied despite the fact this pinned feature does not enable network
mediation support. For details, see:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1721278
A fix is being tested and will hopefully be sent to Linus today.

> I'll need to test what happens when upgrading the feature set file +
> Linux in lockstep, when the new feature set includes features brought
> by the Linux upgrade and not supported by the running kernel.
> This will happens when upgrading to the next Debian stable, or on
> a rarely upgraded testing/sid system. It'll be solved on reboot but
> I want to ensure the package upgrade succeeds.

It seems to work just fine. Here's how I tested it:

1. boot sid with Linux 4.14-rc5 from experimental
2. save the 4.14-rc5 feature set:
   cp /etc/apparmor.d/cache/.features /etc/apparmor/features-4.14
3. boot sid with Linux 4.13 from sid
4. save the 4.13 feature set to /etc/apparmor/features:
   cp /etc/apparmor.d/cache/.features /etc/apparmor/features
5. add features-file=/etc/apparmor/features to /etc/apparmor/parser.conf
6. reboot on Linux 4.13 again
7. cp /etc/apparmor/features{-4.14,}
8. systemctl restart apparmor
9. look at what happened:
   - apparmor.service was successfully restarted
   - the restart logs say 'apparmor="STATUS"
 operation="profile_replace" info="same as current profile,
 skipping"'
   - the policy has been successfully reloaded (actually not as said
 above, but that's fine)
   - the output of aa-status is what I would expect

I'm kinda surprised that apparmor_parser does not complain about being
explicitly told to enable features that the kernel does not support,
but OTOH its --help says "--features-file n Use only features in file
n" that I understand as the features file is only used to exclude
features not listed in there, and the parser actually uses the
intersection of the features specified in that file and the features
actually supported by the kernel. John, did I guess right?

> A special case of this general problem is when one intentionally runs
> an older kernel than the one whose feature set we've pinned. I did not
> test this yet. My understanding is that the worst that can happens is
> that one gets no AppArmor confinement at all, which is not exactly
> a regression compared to what Debian has been doing so far, and it's
> a corner case so I won't treat this as a blocker.

It seems to work just fine too. Here's how I tested this:

1. boot sid with Linux 4.14-rc5 from experimental
2. save the 4.14-rc5 feature set to /etc/apparmor/features:
   cp /etc/apparmor.d/cache/.features /etc/apparmor/features
3. add features-file=/etc/apparmor/features to /etc/apparmor/parser.conf
4. reboot on Linux 4.13 from sid and look at what happened:
   - the policy has been successfully loaded
   - apparmor.service was successfully started
   - the output of aa-status is what I would expect

Cheers,
-- 
intrigeri

Bug#783653: pymol: Segmentation fault immediately after loading pdb

[Alois Schloegl]

I confirm that this bug occurs under some specific conditions.
For testing I used this file
  http://www.pdb.org/pdb/files/1bl8.pdb
which works fine on a local installation of pymol (Debian/Stretch).

It works also when connecting to OSX (through xquartz 2.7.12 with "ssh
-Y " to a Debian/Jessie server with Pymol installed.

However, when I try to connect from my Debian/Stretch Laptop through
"ssh -X  " to the same Debian/Jessie server, and I try to open the same
file on the server, pymol crashes with the following error message:


>  PyMOL(TM) Molecular Graphics System, Version 1.8.4.0.
>  Copyright (c) Schrodinger, LLC.
>  All Rights Reserved.
>  
> Created by Warren L. DeLano, Ph.D. 
>  
> PyMOL is user-supported open-source software.  Although some versions
> are freely available, PyMOL is not in the public domain.
>  
> If PyMOL is helpful in your work or study, then please volunteer 
> support for our ongoing efforts to create open and affordable scientific
> software by purchasing a PyMOL Maintenance and/or Support subscription.
> 
> More information can be found at "http://www.pymol.org;.
>  
> Enter "help" for a list of commands.
> Enter "help " for information on a specific command.
> 
>  Hit ESC anytime to toggle between text and graphics.
> 
>  Detected OpenGL version 2.0 or greater. Shaders available.
>  Detected GLSL version 1.30.
>  OpenGL graphics engine:
>   GL_VENDOR:   VMware, Inc.
>   GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.8, 256 bits)
>   GL_VERSION:  3.0 Mesa 13.0.6
>  Detected 32 CPU cores.  Enabled multithreaded rendering.
> HEADERMEMBRANE PROTEIN23-JUL-98   1BL8
> TITLE POTASSIUM CHANNEL (KCSA) FROM STREPTOMYCES LIVIDANS
> COMPNDMOL_ID: 1;
> COMPND   2 MOLECULE: PROTEIN (POTASSIUM CHANNEL PROTEIN);
> COMPND   3 CHAIN: A, B, C, D;
> COMPND   4 ENGINEERED: YES;
> COMPND   5 MUTATION: YES
>  ObjectMolecule: Read secondary structure assignments.
>  ObjectMolecule: Read crystal symmetry information.
>  CmdLoad: "1bl8.pdb" loaded as "1bl8".
> Segmentation fault


I tried also with some other Debian machines, and it seems a
contributing factor is whether the GL_RENDERER is 128 or 256 bits.

>   GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.8, 256 bits)


It crashes in case of 256 bits, but does not crash when 128 bit renderer
is reported.

Maybe someone else can make use of this information ?



Cheers,
   Alois

Bug#878203: [pkg-apparmor] Bug#878203: Bug#878203: Bug#878203: AA breaks libvirt when running with kernel 4.13

[Christian Boltz]

Hello,

Am Montag, 23. Oktober 2017, 09:14:52 CEST schrieb intrigeri:
>> 2017-10-11T14:43:54.683220+02:00 pluto kernel: [  355.112941] audit:
> > type=1400 audit(1507725834.681:55): apparmor="DENIED"
> > operation="open"
> > profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> > name="/proc/684/cmdline" pid=3154 comm="qemu-system-x86"
> > requested_mask="r" denied_mask="r" fsuid=114 ouid=0

> Shall we silence the denial or allow it

No idea about that, but...

> (possibly prefixed with "owner" to avoid increasing the attack
> surface too much)?

Have a look at the denial again - fsuid != ouid, so you can't use an 
owner rule.

Also, the pid is not the same as in the /proc/*/cmdline name, so please 
use @{pids}, not the (planned-to-be-restricted-to-own-pid) @{pid} 
variable.


Regards,

Christian Boltz
-- 
Ein Killfile ist der natürliche Lebensraum von Trollen und Elchen.  Wenn
sich jemand zu ihnen gesellt, entstehen lustige Geräusche, wie PLONK.
Manchmal machts auch PLATSCH, wenn der Lebensraum bereits überbevölkert
ist. [David Dahlberg]


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

Bug#878447: fai-nfsroot: RESOLVED

[Eli Taft]

Package: fai-nfsroot
Version: 5.3.6
Followup-For: Bug #878447

Dear Maintainer,

This issue is resolved as of this commit:

https://github.com/faiproject/fai/commit/f3cf8cd34f85c879f820d67c2a9211afd94f674d

It has not yet been released in an official version, but the commit was
done on Oct 14th 2017, so look for a release after that date and it will
probably contain the fix.

Releases:

https://github.com/faiproject/fai/releases




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

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

Versions of packages fai-nfsroot depends on:
pn  fai-client 
pn  fai-setup-storage  
ii  syslinux-common3:6.03+dfsg-14.1

fai-nfsroot recommends no packages.

fai-nfsroot suggests no packages.

Bug#874430: CVE-2016-10504 / CVE-2017-14151

[Mathieu Malaterre]

Control: notfound -1 2.1.0-2+deb8u2

I have been trying to track those related CVE and it appears that this
commit should avoid this kind of issue:

https://github.com/uclouvain/openjpeg/commit/3a80b72ac

(I had actually forgotten I authored this back then).

I think the issue was introducated later:

https://github.com/uclouvain/openjpeg/commit/e05d2901e

So I will not include the related patch.

Cheers

Bug#879627: Both Firefox and Thunderbird lost their scrollbar arrows; other gtk3 apps did not

[Anthony DeRobertis]

Package: firefox
Version: 56.0-2
Severity: normal

Both Firefox and Thunderbird have lost their scrollbar arrows. Other
gtk3 apps (such as Evince) continue to have them, I'm using the
TraditionalOk theme which has them.

I tried Thunderbird in safe mode and same problem.

-- Package-specific info:

-- Extensions information
Name: A Web Browser Renaissance theme
Status: user-disabled

Name: Activity Stream
Location: ${PROFILE_EXTENSIONS}/activity-str...@mozilla.org.xpi
Status: enabled

Name: Add-on Compatibility Reporter
Location: ${PROFILE_EXTENSIONS}/compatibil...@addons.mozilla.org.xpi
Status: enabled

Name: Application Update Service Helper
Location: ${PROFILE_EXTENSIONS}/aushel...@mozilla.org.xpi
Status: enabled

Name: Banish large print edition userstyle
Status: user-disabled

Name: Bigger bodies, colors userstyle
Status: user-disabled

Name: Bugzilla - Show the whole g userstyle
Status: user-disabled

Name: Click-to-Play staged rollout
Location: ${PROFILE_EXTENSIONS}/clicktoplay-roll...@mozilla.org.xpi
Status: enabled

Name: Compact Dark theme
Status: user-disabled

Name: Compact Light theme
Status: user-disabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: DOM Inspector
Location: /usr/share/xul-ext/dom-inspector
Package: xul-ext-dom-inspector
Status: user-disabled

Name: Firefox Screenshots
Location: ${PROFILE_EXTENSIONS}/screensh...@mozilla.org.xpi
Status: enabled

Name: Fix Google Reader userstyle
Status: user-disabled

Name: Fix Washpost userstyle
Status: enabled

Name: Follow-on Search Telemetry
Location: ${PROFILE_EXTENSIONS}/followonsea...@mozilla.com.xpi
Status: enabled

Name: Form Autofill
Location: ${PROFILE_EXTENSIONS}/formautof...@mozilla.org.xpi
Status: enabled

Name: Greasemonkey
Location: ${PROFILE_EXTENSIONS}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}.xpi
Status: enabled

Name: HN Utility Suite
Location: ${PROFILE_EXTENSIONS}/jid0-rhgamphpt2ngrv7gjxnbeerd...@jetpack.xpi
Status: enabled

Name: HTTPS Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywhere-...@eff.org.xpi
Status: enabled

Name: IdentFavIcon
Location: ${PROFILE_EXTENSIONS}/identfavi...@david.hanak.hu.xpi
Status: enabled

Name: It's All Text!
Location: ${PROFILE_EXTENSIONS}/itsallt...@docwhat.gerf.org
Status: enabled

Name: Larger Font userstyle
Status: enabled

Name: Larger fonts userstyle
Status: enabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: MusicBrainz: Make table columns sortable greasemonkey-user-script
Status: enabled

Name: MusicBrainz: Show acoustids greasemonkey-user-script
Status: enabled

Name: MusicBrainz: Show stats from AcousticBrainz greasemonkey-user-script
Status: enabled

Name: my stars design for userstyles.org  userstyle
Status: enabled

Name: NYTimes Font Sizes userstyle
Status: enabled

Name: Open in Browser
Location: ${PROFILE_EXTENSIONS}/openinbrow...@www.spasche.net.xpi
Status: enabled

Name: Photon onboarding
Location: ${PROFILE_EXTENSIONS}/onboard...@mozilla.org.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: RECAP
Location: ${PROFILE_EXTENSIONS}/i...@recapthelaw.org.xpi
Status: enabled

Name: SE Chat Modifications greasemonkey-user-script
Status: user-disabled

Name: SE Topbar userstyle
Status: enabled

Name: SE-Keyboard-Shortcuts greasemonkey-user-script
Status: enabled

Name: Shield Recipe Client
Location: ${PROFILE_EXTENSIONS}/shield-recipe-cli...@mozilla.org.xpi
Status: enabled

Name: So Do Me greasemonkey-user-script
Status: user-disabled

Name: Soft Aqua theme
Status: user-disabled

Name: StackExchange Fonts userstyle
Status: enabled

Name: Stylish
Location: ${PROFILE_EXTENSIONS}/{46551EC9-40F0-4e47-8E18-8E5CF550CFB8}.xpi
Status: enabled

Name: Tab Groups
Location: ${PROFILE_EXTENSIONS}/tabgro...@quicksaver.xpi
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: Use a Readable Font userstyle
Status: enabled

Name: Use Helvetica userstyle
Status: enabled

Name: Use normal sans-serif font userstyle
Status: enabled

Name: ViewAbout
Location: ${PROFILE_EXTENSIONS}/viewab...@rumblingedge.com.xpi
Status: enabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

Name: Web Developer
Location: ${PROFILE_EXTENSIONS}/{c45c406e-ab73-11d8-be73-000a95be3b12}.xpi
Status: enabled

-- Plugins information
Name: Google Talk Plugin
Location: /opt/google/talkplugin/libnpgoogletalk.so
Package: google-talkplugin
Status: enabled

Name: Google Talk Plugin Video Renderer
Location: /opt/google/talkplugin/libnpo1d.so
Package: google-talkplugin
Status: enabled

Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3.1))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled

Name: LastPass 

Bug#879625: ITP: node-vue-template-es2015-compiler -- Post compiler for Vue template render functions to support ES2015+

[Pirate Praveen]

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

* Package name: node-vue-template-es2015-compiler
  Version : 1.6.0
  Upstream Author : Evan You
* URL : https://npmjs.com/package/vue-template-es2015-compiler
* License : Expat
  Programming Lang: JavaScript
  Description : Post compiler for Vue template render functions to
support ES2015+

 This is an internal package used by `vue-loader` and `vueify`. It processes
 the raw render functions generated by `vue-template-compiler` to:
 .
  1. add support to ES2015 features in template expressions via Buble.
  2. remove the `with` block inside render functions to make it strict-mode
 compliant. This is performed only at build time so that the base template
 compiler can be extremely small and lightweight.
 .
 Node.js is an event-based server-side JavaScript engine.

In dependency chain for gitlab 9.5



signature.asc
Description: OpenPGP digital signature

Bug#879626: ITP: node-webpack-stats-plugin -- Webpack stats plugin

[Pirate Praveen]

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

* Package name: node-webpack-stats-plugin
  Version : 0.1.5
  Upstream Author : Ryan Roemer 
* URL :
https://github.com/FormidableLabs/webpack-stats-plugin#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Webpack stats plugin

 This plugin will ingest the webpack stats object, process / transform the
 object and write out to a file for further consumption.
 .
 The most common use case is building a hashed bundle and wanting to
 programmatically refer to the correct bundle path in your Node.js server.
 .
 Node.js is an event-based server-side JavaScript engine.

Dependency of gitlab 9.5



signature.asc
Description: OpenPGP digital signature

Bug#878203: AA breaks libvirt when running with kernel 4.13

[Michael Biebl]

Am 23.10.2017 um 18:28 schrieb Guido Günther:
> Hi,
> On Mon, Oct 23, 2017 at 06:22:10PM +0200, Michael Biebl wrote:
>> Am 23.10.2017 um 17:49 schrieb Guido Günther:

>> This is what I get when I *shut down* a VM in virt-manager:
>> $ journalctl -f | grep DENIED
>> Okt 23 18:20:31 pluto audit[8603]: AVC apparmor="DENIED"
>> operation="open" profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
>> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
>> requested_mask="r" denied_mask="r" fsuid=114 ouid=0
>> Okt 23 18:20:31 pluto kernel: audit: type=1400 audit(1508775631.299:55):
>> apparmor="DENIED" operation="open"
>> profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
>> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
>> requested_mask="r" denied_mask="r" fsuid=114 ouid=0
> 
> I can produce this msg on shutdown (I assumed it to be on VM start) but
> what does break?

No idea. I don't see any immediate breakage related to those denials.


-- 
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#818065: console-setup is not read correctly at boottime and must be started manually

[Rupert Perry]

Hi Anton,

> > > This happened to me as well, check if a slight change to the systemd
> > > unit file helps:
> > > /lib/systemd/system/console-setup.service
> > > RequiresMountsFor=/usr /tmp
> > 
> > I have this same problem and I tried this solution and it didn't fix 
> > the problem for me.
> 
> I suppose this fixes the problem with the upgrades of console-setup. But I
> don't like this solution because even if it fixes the problem (does it?),
> it is not the right solution.  I don't think console-setup 
> needs /tmp for its work.  This solution works only because requiring 
> /tmp to be mounted means some other dependency will be satisfied as 
> well.  But who knows what this other dependency is...

Just to be clear - I tried adding /tmp to the unit file and it did NOT fix the 
problem.  I had to re-generate the cache files to resolve the issue and I 
restored the system unit file to not require a mount for /tmp as before.  

The bug is that there was a reference to a non-existent file in /tmp in the 
previous version of /etc/console-setup/cached_setup_keyboard.sh which 
disappeared when it was re-generated.  I imagine the /tmp file was there when 
it was originally generated, but it was of course not there on a subsequent 
reboot.  When I regenerated the cache files 
/etc/console-setup/cached_setup_keyboard.sh changed as follows:

-loadkeys '/tmp/tmpkbd.iDWdSi' > '/dev/null'
+loadkeys '/etc/console-setup/cached_UTF-8_del.kmap.gz' > '/dev/null'

Rupert.

Bug#879566: Half-maximized terminal windows not edge-to-edge, size changes with zoom or tab bar

[Simon McVittie]

Control: reassign 879566 gnome-terminal,libgtk-3-0
Control: found 879566 gnome-terminal/3.26.1-1
Control: found 879566 libgtk-3-0/3.22.24-1
Control: forwarded 879566 https://bugzilla.gnome.org/show_bug.cgi?id=789356

On Sun, 22 Oct 2017 at 14:18:12 -0700, Josh Triplett wrote:
> I don't know whether this bug lies with gnome-shell or with mutter

I think this is actually a behaviour change in GTK+ 3.22.23
() to which
gnome-terminal has not adjusted
(). There is also a
new protocol between Mutter and GTK+, but that wouldn't be a problem if
GTK+ hadn't changed its app-visible behaviour while adding support for
that protocol.

I think the most robust solution would be to fix both gnome-terminal
(to make use of the non-deprecated protocol) and GTK+ (to restore
compatibility with the deprecated protocol). I'll try to do some patches
later.

smcv

Bug#879512: paperkey: Unable to parse algorithm 22 (ed25519)

[Peter Palfrader]

On Mon, 23 Oct 2017, David Shaw wrote:

> Hi Peter,
> 
> I've added support for EdDSA to paperkey (it's a one-line fix - EdDSA and 
> ECDSA have the same representation), so that's simple enough.
> 
> The segfault is more troubling though - not supporting an algorithm
> (yet) is one thing, but paperkey should never segfault.
> Unfortunately, I can't reproduce the segfault with various ed25519
> keys, both as themselves and in combinations like RSA primary and
> ed25519 subkey.  Can you send me a test key that reproduces the issue
> for you?

Sure, attached.

| weasel@orinoco:~/gpghome2$ gpg --import ~/fuse/sarek/test2.asc
| gpg: WARNING: unsafe permissions on homedir '/home/weasel/gpghome2'
| gpg: /home/weasel/gpghome2/trustdb.gpg: trustdb created
| gpg: key 42FA0478A3CC80F1: public key "test2" imported
| gpg: Total number processed: 1
| gpg:   imported: 1
| weasel@orinoco:~/gpghome2$ gpg --import ~/fuse/sarek/test2-secret.asc
| gpg: WARNING: unsafe permissions on homedir '/home/weasel/gpghome2'
| gpg: key 42FA0478A3CC80F1: "test2" not changed
| gpg: key 42FA0478A3CC80F1: secret key imported
| gpg: Total number processed: 1
| gpg:  unchanged: 1
| gpg:   secret keys read: 1
| gpg:   secret keys imported: 1
| weasel@orinoco:~/gpghome2$ gpg --list-key
| gpg: WARNING: unsafe permissions on homedir '/home/weasel/gpghome2'
| /home/weasel/gpghome2/pubring.kbx
| -
| pub   rsa2048 2017-10-22 [SC] [expires: 2019-10-22]
|   ABBC80F0A6340158E0E4559B42FA0478A3CC80F1
| uid   [ unknown] test2
| sub   ed25519 2017-10-22 [S] [expires: 2017-10-29]
| 
| weasel@orinoco:~/gpghome2$ gpg --list-secret-keys
| gpg: WARNING: unsafe permissions on homedir '/home/weasel/gpghome2'
| /home/weasel/gpghome2/pubring.kbx
| -
| sec   rsa2048 2017-10-22 [SC] [expires: 2019-10-22]
|   ABBC80F0A6340158E0E4559B42FA0478A3CC80F1
| uid   [ unknown] test2
| ssb   ed25519 2017-10-22 [S] [expires: 2017-10-29]
| 
| weasel@orinoco:~/gpghome2$ gpg --export-secret-keys test2 | paperkey
| gpg: WARNING: unsafe permissions on homedir '/home/weasel/gpghome2'
| # Secret portions of key ABBC80F0A6340158E0E4559B42FA0478A3CC80F1
| # Base16 data extracted Mon Oct 23 18:26:07 2017
| # Created with paperkey 1.3 by David Shaw
| #
| # File format:
| # a) 1 octet:  Version of the paperkey format (currently 0).
| # b) 1 octet:  OpenPGP key or subkey version (currently 4)
| # c) n octets: Key fingerprint (20 octets for a version 4 key or subkey)
| # d) 2 octets: 16-bit big endian length of the following secret data
| # e) n octets: Secret data: a partial OpenPGP secret key or subkey packet as
| #  specified in RFC 4880, starting with the string-to-key usage
| #  octet and continuing until the end of the packet.
| # Repeat fields b through e as needed to cover all subkeys.
| # 
| # To recover a secret key without using the paperkey program, use the
| # key fingerprint to match an existing public key packet with the
| # corresponding secret data from the paper key.  Next, append this secret
| # data to the public key packet.  Finally, switch the public key packet tag
| # from 6 to 5 (14 to 7 for subkeys).  This will recreate the original secret
| # key or secret subkey packet.  Repeat as needed for all public key or subkey
| # packets in the public key.  All other packets (user IDs, signatures, etc.)
| # may simply be copied from the public key.
| #
| # Each base16 line ends with a CRC-24 of that line.
| # The entire block of data ends with a CRC-24 of the entire block of data.
| 
|   1: 00 04 AB BC 80 F0 A6 34 01 58 E0 E4 55 9B 42 FA 04 78 A3 CC 80 F1 8166A9
|   2: 02 8B 00 07 FC 0A 7F BF 22 0C 10 40 69 73 B6 03 55 D2 13 D0 87 9A 8522D9
|   3: DA 7F A0 8B 60 0B 03 77 ED 4B 55 CC B4 1E 78 5E A1 CF DB BF C9 CF 935E07
|   4: 87 9F 0B 05 07 5F EF 6F 08 75 E5 2A 86 7F 52 2A E2 2A 57 80 DD 76 026AF3
|   5: D6 82 7D 1E 90 67 17 FF DB 66 00 1B 68 AF 2F CF F2 D2 2A B4 C8 7C 54E93F
|   6: D6 68 D8 23 59 53 F0 E7 E0 FF 7D B0 E6 08 48 2D DC D9 8E A6 4C 5C 75F7B8
|   7: 8C F2 75 BB EF 62 15 34 A5 C5 51 44 33 F2 1D E5 03 38 41 9C E4 2A 0DE30F
|   8: D4 C4 2D AA 6F 1A A3 7B 46 7C 9F 1D D6 D8 7F 94 DD DC AD 82 33 34 6C95CF
|   9: 9E 4F A3 34 11 4D D4 88 01 EE 87 7F F3 79 F9 09 C0 C9 4F 2A D9 F1 A99829
|  10: D2 8D 19 5F BF CF D8 5D E4 E4 B5 6F FE 37 3F 10 70 39 27 92 72 57 093A0C
|  11: CB 52 F4 A3 71 83 73 8C B6 A0 31 EA 24 F6 85 9B 97 05 3B AB A6 65 756771
|  12: 12 3D 1D 14 DF 7D C1 4A D1 A2 C1 87 23 4B 16 71 3F 01 71 A6 99 1F CF90C3
|  13: 89 9A B9 3D E5 16 74 D7 DA F8 38 01 63 40 D5 2C 0E 2F 81 04 00 D1 8DD22C
|  14: 94 CD BE CF 9A FD 7E 79 66 2C 0C E1 90 3E DB DD 18 82 95 79 8D B8 A54036
|  15: FC 23 B9 F4 83 C9 CE 9A 57 18 58 E9 42 71 39 C2 8C 7E B1 0A E1 4A 6B80DA
|  16: A9 CC C1 F7 9B AA 9E 33 EC B1 8A E8 14 77 BA 54 76 EA EC 55 99 7A 36AE0D
|  17: 23 1A 91 47 AF 02 BF B0 CB AB 0E C1 DE AF 68 EC FC DA C0 CB 49 19 253DEB
|  18: B9 A9 D1 C1 

Bug#878203: AA breaks libvirt when running with kernel 4.13

[Guido Günther]

Hi,
On Mon, Oct 23, 2017 at 06:22:10PM +0200, Michael Biebl wrote:
> Am 23.10.2017 um 17:49 schrieb Guido Günther:
> 
> > I can't reproduce this here with 4.13.0-1-amd64 and
> > libvirt-daemon-system 3.8.0-3.
> >  -- Guido
> > 
> linux-image-4.13.0-1-amd64 4.13.4-2
> libvirt-daemon-system 3.8.0-3
> 
> This is what I get when I *shut down* a VM in virt-manager:
> $ journalctl -f | grep DENIED
> Okt 23 18:20:31 pluto audit[8603]: AVC apparmor="DENIED"
> operation="open" profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
> requested_mask="r" denied_mask="r" fsuid=114 ouid=0
> Okt 23 18:20:31 pluto kernel: audit: type=1400 audit(1508775631.299:55):
> apparmor="DENIED" operation="open"
> profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
> requested_mask="r" denied_mask="r" fsuid=114 ouid=0

I can produce this msg on shutdown (I assumed it to be on VM start) but
what does break?
 -- Guido

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

Bug#878203: AA breaks libvirt when running with kernel 4.13

[Michael Biebl]

Am 23.10.2017 um 17:49 schrieb Guido Günther:

> I can't reproduce this here with 4.13.0-1-amd64 and
> libvirt-daemon-system 3.8.0-3.
>  -- Guido
> 
linux-image-4.13.0-1-amd64 4.13.4-2
libvirt-daemon-system 3.8.0-3

This is what I get when I *shut down* a VM in virt-manager:
$ journalctl -f | grep DENIED
Okt 23 18:20:31 pluto audit[8603]: AVC apparmor="DENIED"
operation="open" profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
requested_mask="r" denied_mask="r" fsuid=114 ouid=0
Okt 23 18:20:31 pluto kernel: audit: type=1400 audit(1508775631.299:55):
apparmor="DENIED" operation="open"
profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
requested_mask="r" denied_mask="r" fsuid=114 ouid=0


-- 
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#877884: FYI: unicode cldr (core) data

[Osamu Aoki]

Hi,

I just uploaded unicode-cldr-core.  Instead of closing
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877973
the change log was closing this bug.
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877884

Osamu

Bug#818065: console-setup is not read correctly at boottime and must be started manually

[Anton Zinoviev]

On Mon, Oct 23, 2017 at 02:55:58PM +, Rupert Perry wrote:
> 
> > This happened to me as well, check if a slight change to the systemd
> > unit file helps:
> > /lib/systemd/system/console-setup.service
> > RequiresMountsFor=/usr /tmp
> 
> I have this same problem and I tried this solution and it didn't fix 
> the problem for me.

I suppose this fixes the problem with the upgrades of console-setup. But I
don't like this solution because even if it fixes the problem (does it?),
it is not the right solution.  I don't think console-setup 
needs /tmp for its work.  This solution works only because requiring 
/tmp to be mounted means some other dependency will be satisfied as 
well.  But who knows what this other dependency is...

Anton Zinoviev

Bug#768542: Bug#770512: mutter: Tiled windows using client side decoration have no borders

[Simon McVittie]

Control: reassign 770512 libgtk-3-0
Control: forcemerge 768542 770512

On Fri, 21 Nov 2014 at 16:17:12 -0500, Martin Tang wrote:
> Over the last few GNOME releases, more and more applications have started 
> using
> client side decoration. When these applications are quick tiled to the left or
> to the right, they lack any borders, and it can be hard to see where one 
> window
> ends and another begins. Previously, tiled applications had a thin 1 pixel 
> border
> (and a drop shadow if only one visible window is tiled).

Mutter is not going to solve this, because the distinguishing factor
of windows with client-side decorations is that they are decorated
client-side :-) As such, if the decorations are not what they should be,
it is up to the client (or its library stack) to fix this.

On Sat, 22 Nov 2014 at 14:08:16 +0100, Todor Tsankov wrote:
> This is the same bug as #768542 that I reported against the package
> libgtk-3-0. I am curious to know if there is any progress on that.

The upstream bug was closed during the GNOME 3.16 cycle, and I see drop
shadows for half-maximized windows with GNOME 3.26 (tested with gedit).

smcv

Bug#878203: AA breaks libvirt when running with kernel 4.13

[Guido Günther]

Hi,
On Wed, Oct 11, 2017 at 02:10:01AM +0200, Michael Biebl wrote:
> Package: apparmor
> Version: 2.11.0-11
> Severity: serious
> 
> After the kernel upgrade from 4.12 to 4.13 my KVM/libvirt instances
> failed to start:
> Okt 10 19:24:44 pluto libvirtd[673]: 2017-10-10 17:24:44.404+: 797: error 
> : virProcessRunInMountNamespace:1159 : internal error: child reported: Kernel 
> does not provide mount namespace: Permission denied
> 
> Disabling AppArmor made libvirt work again.
> There seems to be an incompatibility between the 4.13 kernel and
> AppArmor. Please reassign if you think this is a bug in the kernel.
> 
> I've decided to mark this as RC, as breaking KVM is a rather severe
> regression which needs to be fixed for buster.
> 
> A quick internet search turns up
> https://forums.opensuse.org/showthread.php/527394-KVM-guest-will-not-start-with-latest-version-of-kernel
> and following that
> https://www.redhat.com/archives/libvir-list/2017-September/msg00546.html

I can't reproduce this here with 4.13.0-1-amd64 and
libvirt-daemon-system 3.8.0-3.
 -- Guido

Bug#879570: pk4: systemd-specific code in /etc/apt/apt.conf.d/50pk4.conf fails on systems where the init system is not systemd

[Michael Stapelberg]

control: tags -1 + pending

Sounds good. Added the Depends for now:
https://github.com/Debian/pk4/commit/a7f965271ef5616147e34a23552ad828a2ef3498

On Mon, Oct 23, 2017 at 5:18 PM, Axel Beckert  wrote:
> Hi Michael,
>
> Michael Stapelberg wrote:
>> What the apt hook does is start pk4-generate-index in the background,
>> see https://github.com/Debian/pk4/blob/master/pk4-generate-index.service.
>>
>> What the dpkg hook does is start pk4-generate-index in the background
>> after 60s (timeout is reset on a subsequent dpkg hook run).
>
> Thanks for the explanations.
>
>> If you are interested in using pk4 on non-systemd machines, could you
>> supply a tested patch for the apt and dpkg hooks adding fallbacks
>> please? I’m not sure how to achieve the same functionality without
>> systemd.
>
> With classic Unix tools and some sh glue of course. "at" and "sleep"
> come to my mind.
>
> Will have a look. I imagine something like "Depends: systemd-sysv |
> at" for the final variant.
>
>> I’d also be happy to add a Depends: systemd-sysv for now, which I
>> believe should result in systemd being present and init.
>
> Yes. This is an unsatisfying but correct solution which IMHO should be
> deployed in short-term.
>
> I don't think this issue is RC since the symptoms can be easily
> avoided by editing conffiles and it doesn't affect default
> installations. But nevertheless it helps to avoid broken
> configurations after installation.
>
> I suggest to mention, but not close this bug report with that change
> and then downgrade it to wishlist. Or alternatively clone the bug
> accordingly and close one of them with the change.
>
> Regards, Axel
> --
>  ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
> : :' :  |  Debian Developer, ftp.ch.debian.org Admin
> `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
>   `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



-- 
Best regards,
Michael

Bug#879512: paperkey: Unable to parse algorithm 22 (ed25519)

[David Shaw]

Hi Peter,

I've added support for EdDSA to paperkey (it's a one-line fix - EdDSA and ECDSA 
have the same representation), so that's simple enough.

The segfault is more troubling though - not supporting an algorithm (yet) is 
one thing, but paperkey should never segfault.  Unfortunately, I can't 
reproduce the segfault with various ed25519 keys, both as themselves and in 
combinations like RSA primary and ed25519 subkey.  Can you send me a test key 
that reproduces the issue for you?

David

> On Oct 22, 2017, at 10:05 AM, Peter Palfrader  wrote:
> 
> Hi David!
> 
> The following issue has been reported against the Debian package of
> paperkey (1.3) at https://bugs.debian.org/879512 -- paperkey 1.4 is
> also affected.
> 
> It seems paperkey is unable to deal with ed25519 keys:
> 
> | weasel@orinoco:~/gnupghome$ gpg --list-key
> | /home/weasel/gnupghome/pubring.kbx
> | --
> | pub   ed25519 2017-10-22 [SC] [expires: 2019-10-22]
> |   83EE1EE4EAA6BA37A4786292C66129D09E62C462
> | uid   [ultimate] test1
> | 
> | pub   rsa2048 2017-10-22 [SC] [expires: 2019-10-22]
> |   ABBC80F0A6340158E0E4559B42FA0478A3CC80F1
> | uid   [ultimate] test2
> | 
> | weasel@orinoco:~/gnupghome$ gpg --export-secret-keys test1 | paperkey
> | Unable to parse algorithm 22
> | e1:weasel@orinoco:~/gnupghome$ 
> 
> With an ed25519 master key, no segfault happens.  With an rsa master and
> an ed25519 subkey, I have observed segfaults, as also reported by Osamu
> Aoki.
> 
> Cheers,
> 
> - Forwarded message from Osamu Aoki  -
> } 
> } Problem: paperkey causes "Segmentation fault" with ed25519 subkey.
> } 
> }  $ gpg --export-secret-key 1DD8D791 |paperkey >paper-secret-1DD8D791.txt
> }  Unable to parse algorithm 22
> }  Segmentation fault
> } 
> } (paperkey works fine with my old rsa1024 key w/o ed25519 subkey)
> } 
> } How to reproduce:
> }  * Add a ed25519 subkey with "gpg --expert".
> }  * Execute paperkey as above (1DD8D791 is my key) 
> } 
> } FYI:
> }  $ gpg --list-keys 1DD8D791
> }  pub   rsa4096 2010-09-23 [SC]
> }3133724D6207881579E95D621E1356881DD8D791
> }  uid   [ultimate] Osamu Aoki 
> }  sub   rsa4096 2010-09-23 [E]
> }  sub   ed25519 2017-10-17 [A]
> }  $ gpg --edit-key 1DD8D791
> }  gpg (GnuPG) 2.2.1; Copyright (C) 2017 Free Software Foundation, Inc.
> }  This is free software: you are free to change and redistribute it.
> }  There is NO WARRANTY, to the extent permitted by law.
> }  
> }  Secret key is available.
> }  
> }  sec  rsa4096/1E1356881DD8D791
> }   created: 2010-09-23  expires: never   usage: SC  
> }   card-no: FFFE 67240842
> }   trust: ultimate  validity: ultimate
> }  ssb  rsa4096/A04CBCEEF08BEFAD
> }   created: 2010-09-23  expires: never   usage: E   
> }   card-no: FFFE 67240842
> }  ssb  ed25519/56F8269DCA1C3AD3
> }   created: 2017-10-17  expires: never   usage: A   
> }   card-no: FFFE 67240842
> }  [ultimate] (1). Osamu Aoki 
> }  
> }  gpg> q
> } 
> } Background:
> }  At Debconf17 gNiibe-san tempted me to use "Modern GPG" and ...  I now
> }  have a subkey using algorithm 22 (ed25519) and Gnuk.  That's why I have
> }  card-no in the above example and ed25519.
> } 
> - End forwarded message -
> 
> -- 
>|  .''`.   ** Debian **
>  Peter Palfrader   | : :' :  The  universal
> https://www.palfrader.org/ | `. `'  Operating System
>|   `-https://www.debian.org/
>