Bug#844749: Use overlayfs instead

[Andreas Heinlein]

The kernels from jessie-backports definitely do not contain aufs 
anymore. IIRC, aufs-dkms did not build against the backport kernels.
Aufs was dropped in favour of overlayfs, which should be supported in 
the current unstable release of live-build.

Bug#854660: [live-build] pass LD_PRELOAD to the chroot stage (to enable e.g. libeatmydata)

[Andreas Heinlein]

Package: live-build
Version: 1:20161216
Severity: normal
Tags: patch

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

The script functions/chroot.sh in live-build cleans the environment 
before entering the chroot and so also removes LD_PRELOAD from the 
environment. This prevents the use of eatmydata to speed up the build 
process.


This can either be fixed by giving a value for LD_PRELOAD in 
config/environment.chroot or by changing chroot.sh to pass LD_PRELOAD 
along. I suggest doing the latter since this is a quite common request.


Patch is attached.

--- chroot.sh.orig2017-02-09 08:24:52.995385684 +0100
+++ chroot.sh2017-02-09 08:25:48.623280273 +0100
@@ -26,7 +26,7 @@
 fi
 done

-${_LINUX32} chroot "${CHROOT}" /usr/bin/env -i HOME="/root" 
PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin" 
TERM="${TERM}" DEBIAN_FRONTEND="${LB_DEBCONF_FRONTEND}" 
DEBIAN_PRIORITY="${LB_DEBCONF_PRIORITY}" 
DEBCONF_NONINTERACTIVE_SEEN="true" DEBCONF_NOWARNINGS="true" ${ENV} 
${COMMANDS}
+${_LINUX32} chroot "${CHROOT}" /usr/bin/env -i 
LD_PRELOAD=${LD_PRELOAD} HOME="/root" 
PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin" 
TERM="${TERM}" DEBIAN_FRONTEND="${LB_DEBCONF_FRONTEND}" 
DEBIAN_PRIORITY="${LB_DEBCONF_PRIORITY}" 
DEBCONF_NONINTERACTIVE_SEEN="true" DEBCONF_NOWARNINGS="true" ${ENV} 
${COMMANDS}


 return "${?}"
 }


--- System information. ---
Architecture: amd64
Kernel: Linux 4.8.0-0.bpo.2-amd64

Debian Release: 8.7
500 stable-updates ftp.de.debian.org
500 stable security.debian.org
500 stable ftp.gruen.hm.mlpd.de
500 stable ftp.de.debian.org
500 jessie-local ftp.gruen.hm.mlpd.de
200 jessie-backports mozilla.debian.net
200 jessie-backports ftp.de.debian.org

--- Package information. ---
Depends (Version) | Installed
==-+-===
debootstrap | 1.0.86~bpo8+1


Recommends (Version) | Installed
===-+-===
apt-utils | 1.0.9.8.4
cpio | 2.11+dfsg-4.1+deb8u1
live-boot-doc | 1:20160511~bpo8+1
live-config-doc | 4.0.4-1
live-manual-html | 1:4.0.1-1
OR live-manual |
wget | 1.16-1+deb8u1


Suggests (Version) | Installed
=-+-===
debian-keyring | 2015.04.10
gpgv | 1.4.18-7+deb8u3

Bug#853619: proposed fix

[Ola Lundqvist]

Hi Kir

Thank you. I will test this.

// Ola

On 8 February 2017 at 23:38, Kir Kolyshkin  wrote:

> A fix has been committed to ploop repo:
>
> https://src.openvz.org/projects/OVZL/repos/ploop/commits/d42
> 98fb98245be22ebe9f576e455c7bf9b26
>
> As gcc-7 is still experimental/unreleased, no new ploop release
> is currently planned.
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#854595: [pkg-gnupg-maint] Bug#854595: scdaemon: Yubikey smartcards (maybe others) are not recognized after update from 2.1.17-4 to 2.1.18-4

[NIIBE Yutaka]

Hello,

Thank you for your reporting.

Camille MONCELIER  wrote:
> After updating gnupg2 to 2.1.18-4, I'm unable to use my gpg keys stored on a
> Yubikey.
>
> I can easily reproduce the problem like this:

If you don't need PC/SC service, and when it can be your option, please
try using the internal CCID driver of GnuPG by configuring udev rules.

> 2017-02-08 15:17:24 scdaemon[11764] DBG: chan_5 <- SERIALNO openpgp
> 2017-02-08 15:17:24 scdaemon[11764] DBG: apdu_open_reader: BAI=10901
> 2017-02-08 15:17:24 scdaemon[11764] DBG: apdu_open_reader: new device=10901
> 2017-02-08 15:17:24 scdaemon[11764] ccid open error: skip
> 2017-02-08 15:17:24 scdaemon[11764] DBG: chan_5 -> ERR 100696144 No such
> device
> 

This error is from the internal CCID driver of GnuPG.  It fails to
find a device because you don't have a configuration.

As I explained in:

https://bugs.debian.org/854616

Until we fixed configuration (by adding an entry for Yubikey),
please have a udev rules like:

 /etc/udev/rules.d/yubikey-neo-u2f-ccid.rules
ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0115", MODE="664", GROUP="plugdev"


And please add yourself as a group member of "plugdev".

In my case, I have this line in /etc/group:

plugdev:x:46:gniibe

The idProduct value is my guess.  Please confirm by lsusb command.

In my case:

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 234b:  
Bus 001 Device 008: ID 234b:  
Bus 001 Device 007: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 0489:e056 Foxconn / Hon Hai 
Bus 001 Device 002: ID 1bcf:2c67 Sunplus Innovation Technology Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

234b: (idVendor = 234b, idProduct=) is my Gnuk Tokens.

And please reply back to us again, so that we can add a correct
entry for the configuration.
-- 

Bug#854381: unblock: apt/1.4~rc1

[Niels Thykier]

Control: tags -1 moreinfo

Julian Andres Klode:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package apt
> 
> [...]
> 
> unblock apt/1.4~rc1
> 
> [...]

It seems to introduce a CI regression.

https://ci.debian.net/packages/a/apt/unstable/amd64/

Thanks,
~Niels

Bug#854570: RFS: node-bn.js -- big numbers in pure javascript

[Siddhesh Rane]

node-bn.js is a node module I have packaged. It is a dependency for browserify.
It is lintian clean and dependencies verified with pbuilder. I have
also run dpkg -i

Code uploaded to alioth (git://anonscm.debian.org/pkg-javascript/node-bn.js.git)
ITP bug #854570 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854570)

I request sponsorship for this package
Regards
Siddhesh Rane

Bug#854236: unblock: inkscape 0.92.1

[Niels Thykier]

Control: tags -1 moreinfo

Mattia Rizzolo:
> [ Keeping lot of context as this one email didn't make it to the ML due
> to the big attachment ]
> 
> On Sun, Feb 05, 2017 at 11:05:28AM +0100, Mattia Rizzolo wrote:
>> This is a preapproval request.
>>
>> Currently stretch has inkscape version 0.92.0 + a bunch of patches
>> backported from their stable branch.  I'd like to eventually ship
>> 0.92.1, which is due in about 2 weeks if they keep the current schedule.
>> [...]
>>
>> In particular there is one bugfix which I'm interested, which is causing
>> malformed rendering of text boxes.  This random blog post can give you
>> an idea of the problem (upstream is not good at bug triaging, so there
>> is no real trackable bug…):
>> http://peppercarrot.com/en/article396/new-inkscape-0-92-breaks-your-previous-works-done-with-inkscape
>> [...]
> 
> In the meantime 0.92.1~pre2 happened.  [...]
> 0.92.1 is now totally freezed, and they expect to release it as is with
> just the version changed.
> https://sourceforge.net/p/inkscape/mailman/inkscape-devel/thread/20170208223327.GI24863%40bryceharrington.org/#msg35655759
> 
>> Thank you for considering.
> 
> !
> 

Hi Mattia,

I am ok with this provided:

 * We aim for 0.92.1 once that is released (assuming it is released
   soon)
 * You are ready to react promptly to regressions
 * You are ready to promptly downgrade back to 0.92.0-4 plus minimal
   patches for fixing the text-height issue for the worst case.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#854659: tcsh: fails to configure

[Sven Joachim]

Package: tcsh
Version: 6.20.00-6
Severity: serious

There was a problem when upgrading from 6.20.00-5 (sorry for the German):

,
| (Lese Datenbank ... 218742 Dateien und Verzeichnisse sind derzeit 
installiert.)
| Vorbereitung zum Entpacken von .../tcsh_6.20.00-6_i386.deb ...
| Entpacken von tcsh (6.20.00-6) über (6.20.00-5) ...
| /usr/bin/update-menus
| postrm called with unknown argument `upgrade'
| dpkg: Warnung: Unterprozess altes post-removal-Skript gab den Fehlerwert 1 
zurück
| dpkg: stattdessen wird Skript aus dem neuen Paket probiert ...
| /usr/sbin/remove-shell
| dpkg: ... sieht so aus, als hätte das geklappt.
| Vorbereitung zum Entpacken von .../debootstrap_1.0.88_all.deb ...
| Entpacken von debootstrap (1.0.88) über (1.0.87) ...
| Trigger für menu (2.1.47) werden verarbeitet ...
| tcsh (6.20.00-6) wird eingerichtet ...
| update-alternatives: Fehler: Alternativen-Pfad /bin/tcsh existiert nicht
| dpkg: Fehler beim Bearbeiten des Paketes tcsh (--configure):
|  Unterprozess installiertes post-installation-Skript gab den Fehlerwert 2 
zurück
`

The update-alternatives error happens because the postinst script is
trying to set up the alternative before creating the /bin/tcsh symlink,
AFAICS.


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

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

Versions of packages tcsh depends on:
ii  libc6  2.24-9
ii  libtinfo5  6.0+20161126-1

tcsh recommends no packages.

tcsh suggests no packages.

-- no debconf information

Bug#854651: unblock: debootstrap/1.0.88

[Niels Thykier]

Steve McIntyre:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hey folks,
> 
> Please unblock debootstrap 1.0.88
> 
> We have a tiny fix for #836525, which will allow debootstrap to deal
> with arch-qualified dependencies. It'll be a major PITA if debootstrap
> can't deal with these in stretch. 
> 
> KiBi already knows about this upload and is happy AFAIK. He and I have
> both tested the patch.
> 
> [...]
> 

Unblocked from my PoV.  For good measure, I'll just have KiBi confirm
that it is not going to disturb any test/release planning for d-i atm. :)

Thanks,
~Niels

Bug#854658: unblock pre-approval request for gitlab

[Praveen Arimbrathodiyil]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: block 854617 by -1

I'd like to make gitlab user configurable as requested in
#854617. This will be helpful for people who want to migrate from
manual installation to debian package (which I think would be a
large number of potential gitlab users) or wants use git as
username instead of gitlab (its a user visible change and ssh
urls for projects in a gitlab instance includes username).

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEKnl0ri/BUtd4Z9pKzh+cZ0USwioFAlicDCUACgkQzh+cZ0US
wiqw7A//bek7/ucgCXQKRhNaXfeDOp0yU4/gRiwKqMiqDvDxmQpWzN53592iZdMc
ta+/Sr7UOA/s5SBOftXL7x+sQJgAp/9cjNvJzNjMMPzt6JsbTiZ7D7K+67RXzBPq
bQYHxi/8+AI5A/46GWkNDwSMMqAm4tj+wU12X0IyxdrQjXMr3UbBmpg9W7b/NWit
j5exeqD7vf7JjyR7RmZYuqCWFP6GeA3C12KFMW63RhBscmD9Nai5kwLaLew/Np4k
7boepqfgcpiqgI8OFbUNjYC5iZZkyCLNH+6nMRWfOCrnorwu772YQZokYmgDWdSX
5/vVORnoguPd+xPFlj12nii6Q1qdjvHlMZovaoyJeHn2WvhodC5uTXK9iVEhSQP+
yrRuVwHEVZI2/OJ8IoaeG3k54TEeHV2r7npoNzOJRFyVJTZ8OnBhVGgqzP7DGJKg
sb5A5OGnkHdcqT3DdM2wPB5k0j5YAgDXAZ2g6AYi1zl9HdMNrZYlyolxVKCu3nho
5SLgfbf8kRn69aijUwPwM8lZsrscT+Ou253oX9mT0GpswvrS36LIMSU6GN58VtsU
QlMy6dA6ZQzHTdU6DxsCwTNU9lQ0+XThRCc4R9EOIsysmK3auG5fQqqfl1CX3weJ
6og2+kuLMCeQnqTUBdDY5Jn+I6srNtfVb2UrrqZ5wkot4ovi+YA=
=rmfI
-END PGP SIGNATURE-

Bug#854657: allow users to create the .asc files themselves

[積丹尼 Dan Jacobson]

Package: flashplugin-nonfree
Version: 1:3.7

Can whatever script you are using to create
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.24.0.0.194.sha512.amd64.pgp.asc
etc. be opened up so that users can create the files needed themselves
in case we fail to download.

Bug#854585: Acknowledgement (evilvte: Allows executing (unexpected) commands via mouse-clicks)

[Steve Kemp]

Tags: patch

One approach at solving this problem would be to stop
highlighting the URL at the first "'" character.

This matches what gnome-terminal, and others, do already
even though I don't believe this character _should_ be
escaped.

This can be achieved by updating the regexp:


deagol ~/evilvte/src $ diff --unified macro2.h macro2.h.new 
--- macro2.h2017-02-09 07:40:21.972749915 +0200
+++ macro2.h.new2017-02-09 07:40:38.256749654 +0200
@@ -130,7 +130,7 @@
 #define LABEL_SUBMENU_IME "_Input Methods"
 #endif
 
-#define MATCH_HTTP_DATA "((f|F)|(h|H)(t|T))(t|T)(p|P)(s|S)?://(([^|.< 
\t\r\n\\\"]*([.][^|< \t\r\n\\\"])?[^|.< \t\r\n\\\"]*)*[^< \t\r\n,;|\\\"]*[^|.< 
\t\r\n\\\"])?/*"
+#define MATCH_HTTP_DATA "((f|F)|(h|H)(t|T))(t|T)(p|P)(s|S)?://(([^|.< 
\t\r\n\\\"']*([.][^|< \t\r\n\\\"'])?[^|.< \t\r\n\\\"']*)*[^< 
\t\r\n,;|\\\"']*[^|.< \t\r\n\\\"'])?/*"
 #define MATCH_FILE_DATA "(f|F)(i|I)(l|L)(e|E):///(([^|.< \t\r\n\\\"]*([.][^|< 
\t\r\n\\\"])?[^|.< \t\r\n\\\"]*)*[^< \t\r\n,;|\\\"]*[^|.< \t\r\n\\\"])?/*"
 #define MATCH_MAIL_DATA "(m|M)(a|A)(i|I)(l|L)(t|T)(o|O):(([^|.< 
\t\r\n\\\"]*([.][^|< \t\r\n\\\"])?[^|.< \t\r\n\\\"]*)*@[^< \t\r\n,;|\\\"]*[^|.< 
\t\r\n\\\"])?/*"
 

That probably needs a sanity-check from the maintainer/upstream
somebody else.  I've just added ' everywhere I saw ".

Steve
--

Bug#820168: debian-installer: The Grub installation step in Debian Testing Installer fails on Gigabyte MP30-AR0

[Ronald Maas]

Hi KiBi,

Good news. I was able to successfully install Stretch RC2 on the
Gigabyte MP30-AR0 motherboard. Also the installer was able to
recognize the network properly, so this bug and also bug 820022 can be
closed.

Attached the dmesg output for reference.

A minor issue remaining is that the AST2400 VGA adapter is not
recognized out of the box. Serial console did work and I was also able
to ssh into the machine after installation and reboot. Reason is
CONFIG_DRM_AST is not set in the kernel configuration. Hope Debian
kernel team could consider changing it to compile it as a module.

Thanks for all the hard work.

Kind regards,
Ronald Maas

On Fri, Feb 3, 2017 at 6:38 PM, Cyril Brulebois  wrote:
> Control: tag -1 - d-i
>
> Hi Ronald,
>
> Ronald Maas  (2016-04-05):
>> The Grub installation step in Debian Installer failed on TianoCore
>> UEFI firmware. The /target/boot/efi directory is empty and the
>> following error is displayed:
>>
>> GRUB installation failed
>> The 'grub-efi-arm64' package failed to install into /target/
>>
>> Version-Release number of selected component (if applicable):
>>
>> Debian Testing DVD ISO dated 28-03-2016
>>
>> How reproducible:
>>
>> Every time.
>>
>> Steps to Reproduce:
>>
>> 1. Download 
>> http://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-dvd/debian-testing-arm64-DVD-1.iso
>> 2. Verify checksum
>> 3. Copy to USB drive using Windows Win32DiskImager
>> 4. Insert drive in X-Gene system
>> 5. Boot X-Gene system
>> 6. Navigate to UEFI Shell
>> 7. Enter the following command to start the Fedora installer:
>>FS1:\EFI\BOOT\BOOTAA64.EFI
>> 8. In the Grub boot menu select the first menu option and hit enter
>> 9. Proceed through the remaining steps of the setup procedure. Selecting
>>default options where applicable. Note on the MP30-AR0 the network is not
>>function (see bug report
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820022. So skip this 
>> step
>>to continue
>> 10. After the GRUB installation step fails, continue without bootloader and 
>> reboot
>> 11. System fails to boot Debian Testing and starts the UEFI Shell instead
>>
>> Actual results:
>>
>> No GRUB bootloader is installed. After restarting the system, no 'debian' 
>> menu
>> entry is visible in UEFI and the /boot/efi directory is empty
>>
>> Expected results:
>>
>> To be able to boot Debian Testing after selecting the 'debian' menu entry in
>> UEFI. Also /boot/efi should contain EFI/debian/grubaa64.efi
>>
>> Additional info:
>>
>> Hardware
>> Gigabyte MP30-AR0 motherboard with APM X-Gene 1 processor flashed with 
>> TianoCore UEFI
>> Kingston KVR16LE11S8/4HB 16 GB ECC DDR3 DRAM
>> HGST Deskstar NAS 6 TB hard drive
>> Logitech USB keyboard
>>
>> The standard U-Boot firmware has been replaced by TianoCore UEFI using the 
>> steps described in: 
>> https://rwmj.wordpress.com/2016/03/08/gigabyte-mp30-ar0-flashing-uefi/
>
> Any chance you could give Stretch RC 2 a try? Info/download at:
>   https://www.debian.org/devel/debian-installer/
>
>
> KiBi.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.9.0-1-arm64 (debian-ker...@lists.debian.org) 
(gcc version 6.3.0 20161229 (Debian 6.3.0-2) ) #1 SMP Debian 4.9.2-2 
(2017-01-12)
[0.00] Boot CPU: AArch64 Processor [500f0001]
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.40 by American Megatrends
[0.00] efi:  ACPI 2.0=0x807ff43000  ESRT=0x807e161e18  SMBIOS 
3.0=0x807e161c18 
[0.00] esrt: Reserving ESRT space from 0x00807e161e18 to 
0x00807e161e50.
[0.00] On node 0 totalpages: 4194304
[0.00]   DMA zone: 8192 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 524288 pages, LIFO batch:31
[0.00]   Normal zone: 57344 pages used for memmap
[0.00]   Normal zone: 3670016 pages, LIFO batch:31
[0.00] percpu: Embedded 22 pages/cpu @807fffe93000 s50200 r8192 
d31720 u90112
[0.00] pcpu-alloc: s50200 r8192 d31720 u90112 alloc=22*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 
[0.00] Detected PIPT I-cache on CPU0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 4128768
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-1-arm64 
root=/dev/sda2 ro quiet
[0.00] PID hash table entries: 4096 (order: 3, 32768 bytes)
[0.00] Dentry cache hash table entries: 2097152 (order: 12, 16777216 
bytes)
[0.00] Inode-cache hash table entries: 1048576 (order: 11, 8388608 
bytes)
[0.00] software IO TLB [mem 0xfbfec000-0xfffec000] (64MB) mapped at 
[80007bfec000-80007ffebfff]
[0.00] Memory: 16363176K/16777216K available (6780K kernel code, 1020K 
rwdata, 2164K rodata, 3264K init, 634K bss, 414040K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] modules : 0x - 0x0800   (   128 
MB

Bug#854638: Correct attachment this time.

[Jean-Francois Pirus]

 SignalStop	Print	Pass to program	Description
SIG38 No	Yes	Yes		Real-time event 38
Starting program: /usr/bin/icedove 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe5594700 (LWP 15888)]
[Thread 0x7fffe5594700 (LWP 15888) exited]
[New Thread 0x7fffe5594700 (LWP 15894)]
[New Thread 0x7fffde7ff700 (LWP 15895)]
[New Thread 0x77fed700 (LWP 15896)]
[New Thread 0x7fffddffe700 (LWP 15897)]
[New Thread 0x7fffdd4ff700 (LWP 15898)]
[New Thread 0x7fffdd2fe700 (LWP 15899)]
[New Thread 0x7fffdd0fd700 (LWP 15900)]
[New Thread 0x7fffdcefc700 (LWP 15901)]
[New Thread 0x7fffdccfb700 (LWP 15902)]
[New Thread 0x7fffdcafa700 (LWP 15903)]
[New Thread 0x7fffdc8f9700 (LWP 15904)]
[New Thread 0x7fffdc6f8700 (LWP 15905)]
[New Thread 0x7fffdc4f7700 (LWP 15906)]
[New Thread 0x7fffdc2f6700 (LWP 15907)]
[New Thread 0x7fffdc0f5700 (LWP 15908)]
[New Thread 0x7fffdbef4700 (LWP 15909)]
[New Thread 0x7fffdabff700 (LWP 15910)]
[New Thread 0x7fffd9e07700 (LWP 15911)]
[New Thread 0x7fffd9606700 (LWP 15912)]
[New Thread 0x7fffe4949700 (LWP 15913)]
[New Thread 0x7fffd87ff700 (LWP 15914)]
[New Thread 0x7fffd7469700 (LWP 15915)]
[New Thread 0x7fffd6c68700 (LWP 15916)]
[New Thread 0x7fffd46ff700 (LWP 15922)]
[New Thread 0x7fffd31ff700 (LWP 15923)]
[New Thread 0x7fffd2390700 (LWP 15924)]
[New Thread 0x7fffd0fff700 (LWP 15925)]
[New Thread 0x7fffd07fe700 (LWP 15926)]
[New Thread 0x7fffcfffd700 (LWP 15927)]
[New Thread 0x7fffcf7fc700 (LWP 15928)]
[New Thread 0x7fffceffb700 (LWP 15929)]
[New Thread 0x7fffce7fa700 (LWP 15930)]
[New Thread 0x7fffcdff9700 (LWP 15931)]
[New Thread 0x7fffcd7f8700 (LWP 15932)]
[New Thread 0x7fffccff7700 (LWP 15933)]
[New Thread 0x7fffcc7f6700 (LWP 15934)]
[New Thread 0x7fffcbff5700 (LWP 15935)]
[New Thread 0x7fffcb3ff700 (LWP 15938)]
[New Thread 0x7fffcabfe700 (LWP 15939)]
[New Thread 0x7fffca3fd700 (LWP 15941)]
[New Thread 0x7fffc95ff700 (LWP 15944)]
[New Thread 0x7fffc84ff700 (LWP 15945)]
[New Thread 0x7fffc77ff700 (LWP 15946)]
[New Thread 0x7fffc6cff700 (LWP 15947)]
[New Thread 0x7fffc64fe700 (LWP 15948)]
[Thread 0x7fffd46ff700 (LWP 15922) exited]
[Thread 0x7fffca3fd700 (LWP 15941) exited]
[Thread 0x7fffc77ff700 (LWP 15946) exited]
[New Thread 0x7fffc59ff700 (LWP 15949)]
[New Thread 0x7fffc51fe700 (LWP 15950)]
[Thread 0x7fffc84ff700 (LWP 15945) exited]
[Thread 0x7fffc64fe700 (LWP 15948) exited]
[Thread 0x7fffc6cff700 (LWP 15947) exited]
[Thread 0x7fffc59ff700 (LWP 15949) exited]
[New Thread 0x7fffc3fff700 (LWP 15951)]
[New Thread 0x7fffc59ff700 (LWP 15952)]
[New Thread 0x7fffc6cff700 (LWP 15957)]
[New Thread 0x7fffc64fe700 (LWP 15958)]
[New Thread 0x7fffc84ff700 (LWP 15959)]
[New Thread 0x7fffc3bf8700 (LWP 15960)]
[New Thread 0x7fffc31ff700 (LWP 15961)]
[New Thread 0x7fffc20ff700 (LWP 15962)]
[New Thread 0x7fffc0fff700 (LWP 15965)]
[New Thread 0x7fffbfdff700 (LWP 15966)]
[New Thread 0x7fffbf5fe700 (LWP 15967)]
[Thread 0x7fffc51fe700 (LWP 15950) exited]
[Thread 0x7fffbfdff700 (LWP 15966) exited]
[Thread 0x7fffbf5fe700 (LWP 15967) exited]
[New Thread 0x7fffc51fe700 (LWP 15970)]
[New Thread 0x7fffbf5fe700 (LWP 15973)]
[New Thread 0x7fffbfdff700 (LWP 15975)]
[New Thread 0x7fffba0ff700 (LWP 15976)]
[New Thread 0x7fffb96ff700 (LWP 15977)]
[Thread 0x7fffba0ff700 (LWP 15976) exited]
[New Thread 0x7fffba0ff700 (LWP 15978)]
[New Thread 0x7fffb8afe700 (LWP 15979)]
[Thread 0x7fffb8afe700 (LWP 15979) exited]
[Thread 0x7fffba0ff700 (LWP 15978) exited]
[Thread 0x7fffbfdff700 (LWP 15975) exited]
[New Thread 0x7fffbfdff700 (LWP 16000)]
[New Thread 0x7fffba0ff700 (LWP 16006)]
[New Thread 0x7fffd6467700 (LWP 16007)]
[New Thread 0x7fffb8afe700 (LWP 16013)]
[Thread 0x7fffb8afe700 (LWP 16013) exited]
[New Thread 0x7fffb8afe700 (LWP 16014)]
[New Thread 0x7fffb35e2700 (LWP 16015)]
[New Thread 0x7fffb2de1700 (LWP 16016)]
[New Thread 0x7fffb25e0700 (LWP 16017)]
[Thread 0x7fffb2de1700 (LWP 16016) exited]
[Thread 0x7fffb35e2700 (LWP 16015) exited]
[New Thread 0x7fffb35e2700 (LWP 16018)]
[New Thread 0x7fffb2de1700 (LWP 16019)]
[Thread 0x7fffb2de1700 (LWP 16019) exited]
[Thread 0x7fffb35e2700 (LWP 16018) exited]
[New Thread 0x7fffb35e2700 (LWP 16020)]
[Thread 0x7fffb35e2700 (LWP 16020) exited]
[Thread 0x7fffc3bf8700 (LWP 15960) exited]
[New Thread 0x7fffc3bf8700 (LWP 16021)]
[Thread 0x7fffb25e0700 (LWP 16017) exited]
[New Thread 0x7fffb25e0700 (LWP 16022)]
[Thread 0x7fffb25e0700 (LWP 16022) exited]
[Thread 0x7fffc31ff700 (LWP 15961) exited]
[Thread 0x7fffc3bf8700 (LWP 16021) exited]
[New Thread 0x7fffc3bf8700 (LWP 16161)]
[Thread 0x7fffc3bf8700 (LWP 16161) exited]
[Thread 0x7fffc0fff700 (LWP 15965) exited]
[New Thread 0x7fffc0fff700 (LWP 16837)]
[New Thread 0x7fffc3bf8700 (LWP 16838)]
[New Thread 0x7fffc31ff700 (LWP 16839)]
[New Thread 0x7fffb25e0700 (LWP 16840)]
[New Thread 0x7fffb35e2700 (LWP 16841)]
[New Thread 0x7fffb08ff700 (LWP 16842)]
[New Thread 0x7fffb00fe700 (LWP 16843)]
[New Thread 0x7fffaf0fd700 (LWP 16844)]
[Thread 0x7fffc31ff

Bug#854653: encourage users to generate strong passwords

[Christian PERRIER]

reassign 854653 user-setup
thanks

Quoting Antoine Beaupre (anar...@debian.org):
> Package: debian-installer
> Severity: wishlist
> 
> After reflecting for a few days about password generation and writing
> an [article][1] about it, I was told the debian-installer may be a good
> place to encourage people to set strong passwords. In the d-i, we set
> one or three critically important passwords: the main user account
> and, optionnally, the root account and crypto passphrase. The latter
> password seems especially important to be cryptographically secure.


This is more or less #364526

I don't merge the bugs as they're phrased differently but I think the
spirit is the same.but in 11 years, it seems that nobody stepped
up to implement something..:-)



signature.asc
Description: PGP signature

Bug#851905: openldap: [INTL:ca] Catalan debconf templates translation update

[Ryan Tandy]

Hello,

Thanks for the translation!

I'm wondering about one part:

@@ -411,6 +421,8 @@ msgid ""
"so if slapd is using the default access control rules, these changes can be "
"applied (after starting slapd) by using the command:"
msgstr ""
+"per que si «slald» fa servir les regles d'accés predeterminades, aquests "
+"canvis es poden fer efectius (després d'iniciar «slald») fent servir l'ordre:"

Is "slald" in this message intentional, or a typo? I guess it's a typo 
since you called it "slapd" in the other messages.


Thank you,
Ryan

Bug#854535: uwsgi: dpkg-buildpackage fails due to open with O_TMPFILE

[Nobuhiro Iwamatsu]

Hi, Jonas.

>> This error is caused by updated libc6.
>> The changelog in libc6(2.19-18+deb8u6) says as follows.
>>
>> - Fix open and openat functions with O_TMPFILE.  Closes: #832521.
>>
>> I found a fix to this issue in upstream.
>>
>> https://github.com/unbit/uwsgi/commit/f6e5db93d8344d7f09ee5304394136d6f5cd7a38
>
> Thanks a lot both for reporting this and locating upstream fix for it.
>
> This was fixed in Debian with the release of 2.0.10-1.  Closing
> accordingly.
>
>  - Jonas

Thanks for your work, but we want to fix this bug with *stable*.
Could you fix this bug and upload to stable as 2.0.7-1+deb8u1?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#854652: Never mind, user error

[Linas Vepstas]

Foo. As the above messages carefully document, I was missing
amdgpu/tonga_k_smc.bin
Doing an
```
apt-get install firmware-amd-graphics
```
fixes the issue, and everything works fine in kernel 4.9.

Close this bug, its bogus.

--linas

Bug#854656: RFS: roadfighter/1.0.0-1 [ITP] -- Relive a classic racing game with this remake

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: wishlist


  Dear mentors,

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

 * Package name: roadfighter
   Version : 1.0.0-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://github.com/coringao/roadfighter
 * License : GPL2+
   Section : games

  It builds those binary packages:

roadfighter - Relive a classic racing game with this remake

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/r/roadfighter/roadfighter_1.0.0-1.dsc

  Regards,
   Carlos Donizete Froes

Bug#854655: diffoscope: Missing Recommends for comparators

[Chris Lamb]

tags 854655 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=46d5003dfd3328eb399797b87d2d5b5aff930c42


Regards,

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

Bug#777239: strip-nondeterminism: print log entry when fixing a file

[Andrew Ayer]

On Thu, 9 Feb 2017 03:18:11 +
Daniel Shahaf  wrote:

> Chris Lamb wrote on Wed, Feb 08, 2017 at 22:12:35 +1300:
> > Andrew Ayer wrote:
> > 
> > > print log entry when fixing a file
> > 
> > This should probably be enabled when DH_VERBOSE=1.
> > 
> > Not sure the cleanest way of "poking this through" given we want
> > strip-nondeterminism to be distribution agnostic, etc. Any ideas?
> 
> For starters, we could add a -v/--verbose flag to the
> distribution-agnostic code.  Then we could look into making
> DH_VERBOSE imply that flag in the Debian-specific code.
> 
> I assume it'd be along the lines of: 1) Add a 'verbose' knob to the
> library, 2) Have strip-nondeterminism set that flag when -v, 3) Have
> dh_strip_nondeterminism set that flag when DH_VERBOSE.  (But I'm not
> familiar with how dh invokes strip-nondeterminism.)

+1.  The code was structured to work this way.  Specifically,
dh_strip_nondeterminism should check if $dh{VERBOSE} is set; the
debhelper perl library sets this if verbosity is enabled in debhelper.

Cheers,
Andrew

Bug#854655: diffoscope: Missing Recommends for comparators

[Chris Lamb]

Package: diffoscope
Version: 71
Severity: serious

diffoscope 71 only:

   Recommends: xxd | vim-common, python3-argcomplete,
 python3-debian, python3-guestfs, python3-progressbar,
 python3-rpm: python3-tlsh (>= 3.4.1)

It should have — at least — unzip. For example, I am currently
seeing:

  'zipinfo' not available in path. Falling back to binary comparison.
  Install 'unzip' to get a better output.

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

This appears to be a regression introduced in:

  
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=4cdfa577f090ca942db42127811937357ae7135a


Regards,

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

Bug#777239: strip-nondeterminism: print log entry when fixing a file

[Daniel Shahaf]

Chris Lamb wrote on Wed, Feb 08, 2017 at 22:12:35 +1300:
> Andrew Ayer wrote:
> 
> > print log entry when fixing a file
> 
> This should probably be enabled when DH_VERBOSE=1.
> 
> Not sure the cleanest way of "poking this through" given we want
> strip-nondeterminism to be distribution agnostic, etc. Any ideas?

For starters, we could add a -v/--verbose flag to the distribution-agnostic
code.  Then we could look into making DH_VERBOSE imply that flag in the
Debian-specific code.

I assume it'd be along the lines of: 1) Add a 'verbose' knob to the
library, 2) Have strip-nondeterminism set that flag when -v, 3) Have
dh_strip_nondeterminism set that flag when DH_VERBOSE.  (But I'm not
familiar with how dh invokes strip-nondeterminism.)

Cheers,

Daniel

Bug#852765: Workaround for netcat-opebsd issue

[Hillel Lubman]

Hi.

I encountered this issue recently on Debian testing as well, and found this 
bug. Uninstalling netcat-openbsd didn't sound
like a good idea, so I found this issue opened for it: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849192[1] 

Basically, nc -q behaves differently and can hang now. Replacing it with nc -N 
can work around it. nc is used in
/usr/share/playonlinux/lib/setupwindow.lib

Replace nc -q with nc -N there, and POL will work fine with netcat-openbsd as 
well.

I attach a patch with that fix.

Regards,
Hillel Lubman.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849192
--- setupwindow.lib	2017-02-08 21:55:43.0 -0500
+++ setupwindow.lib_fixed	2017-02-08 21:52:49.0 -0500
@@ -39,7 +39,7 @@
 	if [ "$POL_OS" = "Mac" -o "$(POL_Config_Read FORCE_LEGACY_NETCAT)" = "TRUE" ]; then
 		nc "$@"
 	else
-		nc -q -1 "$@" 2> /dev/null || nc "$@"
+		nc -N -1 "$@" 2> /dev/null || nc "$@"
 		# Differents possibilities
 	fi
 }

Bug#854652: kernel logs for failing and good boot

[Linas Vepstas]

Here are the kernel logs, foist for the failing boot, then a good boot.
The failing 4.9 boot concludes with this:

[8.928400] amdgpu :04:00.0: firmware: failed to load
amdgpu/tonga_k_smc.bin (-2)
[8.928982] amdgpu :04:00.0: Direct firmware load for
amdgpu/tonga_k_smc.bin failed with error -2
[8.929047] [drm:amdgpu_cgs_get_firmware_info [amdgpu]] *ERROR*
Failed to request firmware
[8.931250] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP
block  failed -22
[8.931924] amdgpu :04:00.0: amdgpu_init failed
[9.070724] [drm] amdgpu: ttm finalized
[9.070729] amdgpu :04:00.0: Fatal error during GPU init
[9.071176] [drm] amdgpu: finishing device.
[9.072293] amdgpu: probe of :04:00.0 failed with error -22

The full failing log (cat /var/log/kern.log |grep amdgpu)

[7.796676] [drm] amdgpu kernel modesetting enabled.
[7.796676] [drm] amdgpu kernel modesetting enabled.
[8.088460] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_mc.bin
[8.088479] amdgpu :04:00.0: VRAM: 4096M 0x -
0x (4096M used)
[8.088482] amdgpu :04:00.0: GTT: 64455M 0x0001 -
0x0010BC7B
[8.088514] [drm] amdgpu: 4096M of VRAM memory ready
[8.088515] [drm] amdgpu: 64455M of GTT memory ready.
[8.090690] amdgpu :04:00.0: amdgpu: using MSI.
[8.090733] [drm] amdgpu: irq initialized.
[8.103523] amdgpu: powerplay initialized
[8.088460] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_mc.bin
[8.088479] amdgpu :04:00.0: VRAM: 4096M 0x -
0x (4096M used)
[8.088482] amdgpu :04:00.0: GTT: 64455M 0x0001 -
0x0010BC7B
[8.088514] [drm] amdgpu: 4096M of VRAM memory ready
[8.088515] [drm] amdgpu: 64455M of GTT memory ready.
[8.090690] amdgpu :04:00.0: amdgpu: using MSI.
[8.090733] [drm] amdgpu: irq initialized.
[8.103523] amdgpu: powerplay initialized
[8.227899] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_pfp.bin
[8.232122] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_me.bin
[8.233481] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_ce.bin
[8.236718] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_rlc.bin
[8.243021] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_mec.bin
[8.253097] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_mec2.bin
[8.255167] amdgpu :04:00.0: fence driver on ring 0 use gpu
addr 0x00010008, cpu addr 0x9996e2693008
[8.255733] amdgpu :04:00.0: fence driver on ring 1 use gpu
addr 0x00010018, cpu addr 0x9996e2693018
[8.256248] amdgpu :04:00.0: fence driver on ring 2 use gpu
addr 0x00010028, cpu addr 0x9996e2693028
[8.256511] amdgpu :04:00.0: fence driver on ring 3 use gpu
addr 0x00010038, cpu addr 0x9996e2693038
[8.256772] amdgpu :04:00.0: fence driver on ring 4 use gpu
addr 0x00010048, cpu addr 0x9996e2693048
[8.257009] amdgpu :04:00.0: fence driver on ring 5 use gpu
addr 0x00010058, cpu addr 0x9996e2693058
[8.257272] amdgpu :04:00.0: fence driver on ring 6 use gpu
addr 0x00010068, cpu addr 0x9996e2693068
[8.257537] amdgpu :04:00.0: fence driver on ring 7 use gpu
addr 0x00010078, cpu addr 0x9996e2693078
[8.258034] amdgpu :04:00.0: fence driver on ring 8 use gpu
addr 0x00010088, cpu addr 0x9996e2693088
[8.261506] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_sdma.bin
[8.282969] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_sdma1.bin
[8.283235] amdgpu :04:00.0: fence driver on ring 9 use gpu
addr 0x00010098, cpu addr 0x9996e2693098
[8.283884] amdgpu :04:00.0: fence driver on ring 10 use gpu
addr 0x000100a8, cpu addr 0x9996e26930a8
[8.294951] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_uvd.bin
[8.297786] amdgpu :04:00.0: fence driver on ring 11 use gpu
addr 0x07e747b0, cpu addr 0xb6c4ce24e7b0
[8.298894] amdgpu :04:00.0: firmware: direct-loading firmware
amdgpu/tonga_vce.bin
[8.299152] amdgpu :04:00.0: fence driver on ring 12 use gpu
addr 0x000100c8, cpu addr 0x9996e26930c8
[8.299287] amdgpu :04:00.0: fence driver on ring 13 use gpu
addr 0x000100d8, cpu addr 0x9996e26930d8
[8.928400] amdgpu :04:00.0: firmware: failed to load
amdgpu/tonga_k_smc.bin (-2)
[8.928982] amdgpu :04:00.0: Direct firmware load for
amdgpu/tonga_k_smc.bin failed with error -2
[8.929047] [drm:amdgpu_cgs_get_firmware_info [amdgpu]] *ERROR*
Failed to request firmware
[8.931250] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP
block  failed -22
[8.931

Bug#854654: mk-basefile on stretch makes basefile with 700 perms on /

[Ian Kelling]

Package: fai-doc
Version: 5.3.4

repro steps:
Run recent stretch
mk-basefile -J STRETCH64
dtrx -n STRETCH64.tar.xz
ls -lad STRETCH64

expected:
755 permissions

actual:
700 permissions

Doing a fai install with the 700 basefile results in / having 700
permissions after the install which breaks various things.

As a workaround, I added a line to mk-basefile: "chmod 755 $xtmp" after
$xtmp was created, which seems to work fine. If this fix was used in the
upstream script, it should probably create a directory under the current
$xtmp and make that directory be 755 and have debootstrap target that,
so that it has the same 700 permissions in it's parent while it is being 
created.

Related package versions I'm using:

Package: debootstrap
Version: 1.0.87

Package: tar
Version: 1.29b-1.1

Bug#854540: Please unblock package gitlab

[Pirate Praveen]

Control: tags -1 - moreinfo

Jonathan Wiltshire wrote:
> If I read the diff right (and I'm happy to be corrected), you're patching
> files in debian/ with a patch in debian/patches/ ? Seems an odd way to go
> about things to me.

The previous patch was incomplete and added a regression. Since upstream did 
not promise a timeline for the backport, I did the backport, but that missed 
some changes. This new patch is backported by upstream and tested to make sure 
the regression is gone.

> Not all of your changes have entries in debian/changelog, please be careful
> to document them thoroghly.

only lintian warnings were updated, I will be more thorough in future updates. 

Bug#854468: lprng: diff for NMU version 3.8.B-2.1

[Sandro Tosi]

control: tags -1 + pending

Dear maintainer,

I've prepared an NMU for lprng (versioned as 3.8.B-2.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Sent on behalf of Reiner Herrmann 

Regards.
diff -Nru lprng-3.8.B/debian/changelog lprng-3.8.B/debian/changelog
--- lprng-3.8.B/debian/changelog	2012-06-11 04:07:15.0 -0400
+++ lprng-3.8.B/debian/changelog	2017-02-08 13:06:05.0 -0500
@@ -1,3 +1,11 @@
+lprng (3.8.B-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix silent loss of SSL support by checking against non-deprecated
+symbol (Closes: #854468).
+
+ -- Reiner Herrmann   Wed, 08 Feb 2017 19:06:05 +0100
+
 lprng (3.8.B-2) unstable; urgency=low
 
   * Compilies on hurd-i386 Closes: #671848
diff -Nru lprng-3.8.B/debian/patches/openssl_1.1.patch lprng-3.8.B/debian/patches/openssl_1.1.patch
--- lprng-3.8.B/debian/patches/openssl_1.1.patch	1969-12-31 19:00:00.0 -0500
+++ lprng-3.8.B/debian/patches/openssl_1.1.patch	2017-02-08 13:05:01.0 -0500
@@ -0,0 +1,34 @@
+Author: Reiner Herrmann 
+Description: Fix silent dropping of OpenSSL support
+ With OpenSSL 1.1 SSL_load_error_strings is deprecated.
+ Checking for this causes loss of SSL support, as the link check
+ no longer succeeded. Check instead for OPENSSL_init_ssl.
+Bug-Debian: https://bugs.debian.org/854468
+
+--- a/configure.ac
 b/configure.ac
+@@ -1008,7 +1008,7 @@
+ 			SSL_LDADD="-L$dir $SSL_LDADD"
+ 		fi
+ 		LDFLAGS="$LDFLAGS $SSL_LDADD"
+-		AC_TRY_LINK_FUNC(SSL_load_error_strings,ac_linked_libssl="true",
++		AC_TRY_LINK_FUNC(OPENSSL_init_ssl,ac_linked_libssl="true",
+ 			ac_linked_libssl="false");
+ 		AC_TRY_LINK_FUNC(RC4_set_key,ac_linked_libcrypto="true",
+ 			ac_linked_libcrypto="false");
+--- a/configure
 b/configure
+@@ -10408,11 +10408,11 @@
+ #ifdef __cplusplus
+ extern "C"
+ #endif
+-char SSL_load_error_strings ();
++char OPENSSL_init_ssl ();
+ int
+ main ()
+ {
+-return SSL_load_error_strings ();
++return OPENSSL_init_ssl ();
+   ;
+   return 0;
+ }
diff -Nru lprng-3.8.B/debian/patches/series lprng-3.8.B/debian/patches/series
--- lprng-3.8.B/debian/patches/series	2012-06-11 02:49:05.0 -0400
+++ lprng-3.8.B/debian/patches/series	2017-02-08 13:01:42.0 -0500
@@ -1,3 +1,4 @@
 lpd_conf_manwarnings
 portable_maxpathlen
 string_literals
+openssl_1.1.patch

Bug#854548: xrdp fails to start at boot

[Joel]

On Wed, 8 Feb 2017 11:19:54 -0500 RLFrost  wrote:
> I have this bug on two systems running stretch as well. The problem for
> me is a missing directory /run/xrdp. When I create that directory
> xrdp-sesman can be started functions properly. On reboot, the directory
> is deleted and the service doesn't work again until the directory is
> created and the service restarted. Hope this helps.
>
> RLFrost
>
>

Same issue here, same fix also works.

Bug#854653: encourage users to generate strong passwords

[Antoine Beaupre]

Package: debian-installer
Severity: wishlist

After reflecting for a few days about password generation and writing
an [article][1] about it, I was told the debian-installer may be a good
place to encourage people to set strong passwords. In the d-i, we set
one or three critically important passwords: the main user account
and, optionnally, the root account and crypto passphrase. The latter
password seems especially important to be cryptographically secure.

[1]: https://lwn.net/SubscriberLink/713806/f43f8fca9c10099a/

As things stand, the user is left on his own: there are little
instructions on how to choose a proper password, what to do with it,
how to not forget it...

I would recommend actually generating the password for the user, using
a random sample of words from a word list. This can be done with the
diceware or xkcdpass software, or it could be implemented from scratch
if we do not want the extra dependency.

If entropy is an issue, we can tell the user to enter the results from
actual dice rolls. But after reviewing a [CCC talk about entropy in
the kernel][2], I am actually quite confident that the kernel RNG, in
modern Linux installs, is sufficiently initialized for cryptographic
use.

[2]: https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy)

I understand this is a significant change, but I didn't want that idea
to get lost anywhere. I believe that randomly-generated yet memorable
passphrases could significantly improve the security of Debian
installs.

Thank you for your consideration.

A.

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

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

Bug#854652: linux kernel 4.9 causes xserver to crash

[Linas Vepstas]

Package: linux-image-4.9.0-1-amd64
Version: 4.9.2-2

Xserver, entire desktop works great for kernel 4.8 but crashes hard on
kernel 4.9 Thus I am reporting this as a kernel bug, instead of an
xserver-xorg bug.

Full contents of /var/log/Xorg.0.log at bottom. But first, a manual diff:

the failed version says this (starting at line 221 of the log file):

MULLINS, KAVERI, HAWAII
[29.553] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[29.553] (II) FBDEV: driver for framebuffer: fbdev
[29.553] (II) VESA: driver for VESA chipsets: vesa
[29.665] (II) modeset(G0): using drv /dev/dri/card0
[29.665] (II) Loading sub module "fbdevhw"
[29.665] (II) LoadModule: "fbdevhw"
[29.665] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[29.665] (II) Module fbdevhw: vendor="X.Org Foundation"
[29.665]compiled for 1.19.1, module version = 0.0.2
[29.665]ABI class: X.Org Video Driver, version 23.0
[29.665] (**) FBDEV(0): claimed PCI slot 4@0:0:0
[29.665] (II) FBDEV(0): using default device
[29.665] (WW) Falling back to old probe method for vesa
[29.666] (II) FBDEV(0): Creating default Display subsection in
Screen section
"Default Screen Section" for depth/fbbpp 24/32
[29.666] (==) FBDEV(0): Depth 24, (==) framebuffer bpp 32
[29.666] (==) FBDEV(0): RGB weight 888


The working version says this:

   MULLINS, KAVERI, HAWAII
[  6169.154] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  6169.154] (II) FBDEV: driver for framebuffer: fbdev
[  6169.154] (II) VESA: driver for VESA chipsets: vesa
[  6169.154] (II) [KMS] Kernel modesetting enabled.
[  6169.164] (II) modeset(G0): using drv /dev/dri/card1
[  6169.164] (WW) Falling back to old probe method for fbdev
[  6169.164] (II) Loading sub module "fbdevhw"
[  6169.164] (II) LoadModule: "fbdevhw"
[  6169.164] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[  6169.164] (II) Module fbdevhw: vendor="X.Org Foundation"
[  6169.164]   compiled for 1.19.1, module version = 0.0.2
[  6169.164]   ABI class: X.Org Video Driver, version 23.0
[  6169.165] (WW) Falling back to old probe method for vesa
[  6169.165] (II) AMDGPU(0): Creating default Display subsection in
Screen section
   "Default Screen Section" for depth/fbbpp 24/32
[  6169.165] (==) AMDGPU(0): Depth 24, (--) framebuffer bpp 32
[  6169.165] (II) AMDGPU(0): Pixel depth = 24 bits stored in 4 bytes
(32 bpp pixmaps)
[  6169.165] (==) AMDGPU(0): Default visual is TrueColor
[  6169.165] (==) AMDGPU(0): RGB weight 888

The failing version explores FBDEV for some reason.  The machine hs
*two* graphics cards: some kind of cheap vga welded onto the
motherboard, and a radeon graphics card. These are the nice one:

04:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Tonga PRO [Radeon R9 285/380] (rev f1)

and cheapo welded-on:

01:01.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
Graphics Family (rev 10)

so here's what is weird:  the failing log states:

[29.665] (**) FBDEV(0): claimed PCI slot 4@0:0:0
[29.666] (II) FBDEV(0): hardware: astdrmfb (video memory: 4076kB)

so pci slot 4 is the radeon card -- good.
so why is trying to use the ast (aspeed technologies) driver on it?
especially when it earlier tried and failed to find the ast driver:

[29.547] (==) Matched ast as autoconfigured driver 0
[29.547] (==) Matched ati as autoconfigured driver 1
[29.547] (==) Matched modesetting as autoconfigured driver 2
[29.547] (==) Matched fbdev as autoconfigured driver 3
[29.547] (==) Matched vesa as autoconfigured driver 4
[29.547] (==) Assigned the driver to the xf86ConfigLayout
[29.547] (II) LoadModule: "ast"
[29.547] (WW) Warning, couldn't open module ast
[29.547] (II) UnloadModule: "ast"
[29.547] (II) Unloading ast
[29.547] (EE) Failed to load module "ast" (module does not exist, 0)

Well, but this failure is "normal", because even on the good boot, the
ast module is not found, and that's just fine.  The difference is that
on the bad boot, the radeon graphics card is never seen by the
x-server. whereas on the good one, it is. For comparison, a working
boot looks like this:

[  6169.149] (II) Applying OutputClass "AMDgpu" to /dev/dri/card0
[  6169.149]   loading driver: amdgpu
[  6169.149] (==) Matched amdgpu as autoconfigured driver 0
[  6169.149] (==) Matched ati as autoconfigured driver 1
[  6169.149] (==) Matched ast as autoconfigured driver 2
[  6169.149] (==) Matched ati as autoconfigured driver 3
[  6169.149] (==) Matched modesetting as autoconfigured driver 4
[  6169.149] (==) Matched fbdev as autoconfigured driver 5
[  6169.149] (==) Matched vesa as autoconfigured driver 6
[  6169.150] (==) Assigned the driver to the xf86ConfigLayout
[  6169.150] (II) LoadModule: "amdgpu"
[  6169.150] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so

again, the working boot is with kernel 4.8; but the failing boot, with
kernel 4.9, the xserver never 

Bug#854279: matplotlib: contains fonts without DFSG-compatible licensing

[Sandro Tosi]

> The "base 14" fonts below lib/matplotlib/mpl-data/fonts/pdfcorefonts
> includes a seemingly non-authoritative liense grant which is omitted
> from debian/copyright.
>
> Some of the fonts below lib/matplotlib/mpl-data/fonts/afm also by Adobe
> lack license as well - also already documented in debian/copyright.

l'll add/extend the copyright notices for these 2 blocks

> The fonts lib/matplotlib/mpl-data/fonts/ttf/c*ttf do not include license
> - they seem to be BaKoMa which some sources mention as "free" while e.g.
> http://www.math.utah.edu/~beebe/fonts/bakoma.html describe them as free
> only for non-commercial use.
+
> 0.82-1 seems to confirm by guess that the c*ttf fonst are BaKoMa and
> that they are restricted to non-commercial use: That release contains
> file fonts/BaKoMa-CM.Fonts with the following text:
>
>> The author of this fonts grants to any individual or non-commercial
>> organization the right to use and to make an unlimited number of
>> copies of full package or selected fonts when this is done WITHOUT
>> CHARGE and has attached this file with licence agreement.
>>
>> This fonts cannot be sold or distributed with any commercial product
>> or used in any commercial organization without additional agreement
>> with author. If you want to charge a small fee via distribution these
>> fonts or any derivations from this fonts, you should contact the
>> author.
>>
>> This restriction is also true for only outlines from this fonts. i.e.
>> outlines exported into other font formats, for example TrueType or
>> Type3.
>>
>> This restriction is not intended to apply to connect time charges, or
>> flat rate connection/download fees for electronic bulletin board
>> services.

0.82-1 is way old and cannot be used as reference.

those fonts are the same as provided by fonts-lyx

$ ls -l /usr/share/fonts/truetype/lyx/c*ttf
-rw-r--r-- 1 root root 20688 Jul  2  2016
/usr/share/fonts/truetype/lyx/cmex10.ttf
-rw-r--r-- 1 root root 32036 Jul  2  2016
/usr/share/fonts/truetype/lyx/cmmi10.ttf
-rw-r--r-- 1 root root 26188 Jul  2  2016
/usr/share/fonts/truetype/lyx/cmr10.ttf
-rw-r--r-- 1 root root 28476 Jul  2  2016
/usr/share/fonts/truetype/lyx/cmsy10.ttf

see also 
https://github.com/matplotlib/matplotlib/issues/6976#issuecomment-270002766

i'll include that copyright notice as well

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#854512: ftpcopy: diff for NMU version 0.6.7-3.1

[Sandro Tosi]

Control: tags 854512 + pending

Dear maintainer,

I've prepared an NMU for ftpcopy (versioned as 0.6.7-3.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Sent on behalf of Reiner Herrmann 

Regards.
diff -u ftpcopy-0.6.7/debian/changelog ftpcopy-0.6.7/debian/changelog
--- ftpcopy-0.6.7/debian/changelog
+++ ftpcopy-0.6.7/debian/changelog
@@ -1,3 +1,11 @@
+ftpcopy (0.6.7-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS by calling dpkg-shlibdeps only for binaries and not
+the ftpcp shell script (Closes: #854512).
+
+ -- Reiner Herrmann   Wed, 08 Feb 2017 18:57:50 +0100
+
 ftpcopy (0.6.7-3) unstable; urgency=medium
 
   * debian/diff/disable--html-option.diff: the --html option is no
diff -u ftpcopy-0.6.7/debian/rules ftpcopy-0.6.7/debian/rules
--- ftpcopy-0.6.7/debian/rules
+++ ftpcopy-0.6.7/debian/rules
@@ -69,7 +69,7 @@
 install-indep: deb-checkdir deb-checkuid build-indep-stamp
 
 binary-arch: deb-checkdir deb-checkuid install-arch ftpcopy.deb
-	test '$(DIET)' -ne 0 || dpkg-shlibdeps '$(DIR)'/usr/bin/*
+	test '$(DIET)' -ne 0 || dpkg-shlibdeps '$(DIR)'/usr/bin/ftpcopy '$(DIR)'/usr/bin/ftpls
 	dpkg-gencontrol -isp -pftpcopy -P'$(DIR)' 
 	dpkg -b '$(DIR)' ..
 

Bug#854376: [pkg-gnupg-maint] Bug#854376: Unable to use gpg-agent as ssh-agent

[Daniel Kahn Gillmor]

Hi Punit--

On Mon 2017-02-06 11:35:32 -0500, Punit Agrawal wrote:
> Not sure if it's related but gpg-agent stopped behaving as ssh
> agent after updating the system today. On my machine, I have
>
> % env | grep -i ssh
> SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh
>
> When trying to ssh, I run into
>
> % ssh 
> sign_and_send_pubkey: signing failed: agent refused operation
>
> "ssh-add -L" shows that the key that should be used to log into the remote.
>
> On further digging, I landed at
> /usr/lib/systemd/user/gpg-agent-ssh.socket which doesn't seem to
> be explicitly enabling ssh support. But I'm not familiar with
> systemd units so might've misunderstood what's going on.

modern versions of gpg-agent have ssh support enabled by default.

If you're getting a refusal from the agent to sign the key, please let
me know:

 * what version of the gnupg-agent package?
 
 * what version of pinentry are you using by default? (e.g. the output
   of "readlink -f $(which pinentry)")

 * how are you launching your graphical environment? (e.g. "no graphical
   environment at all", or "startx", or "gdm" or some other display manager)

 * do you have dbus-user-session installed?


As a diagnostic workaround, can you try running the following and then
tell me whether gpg-agent starts working for you?

gpg-connect-agent updatestartuptty /bye

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#852659: le-dico-de-rene-cougnenc: diff for NMU version 1.3-2.3

[Sandro Tosi]

Control: tags 852659 + pending

Dear maintainer,

I've prepared an NMU for le-dico-de-rene-cougnenc (versioned as 1.3-2.3) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Sent on behalf of Bernhard Übelacker 

Regards.
diff -u le-dico-de-rene-cougnenc-1.3/debian/changelog le-dico-de-rene-cougnenc-1.3/debian/changelog
--- le-dico-de-rene-cougnenc-1.3/debian/changelog
+++ le-dico-de-rene-cougnenc-1.3/debian/changelog
@@ -1,3 +1,11 @@
+le-dico-de-rene-cougnenc (1.3-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with debug info to make dbgsym package usable.
+  * Avoid segfault by undefined behaviour. (Closes: #852659)
+
+ -- Bernhard Übelacker   Wed, 08 Feb 2017 22:03:54 +0100
+
 le-dico-de-rene-cougnenc (1.3-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u le-dico-de-rene-cougnenc-1.3/src/dico.c le-dico-de-rene-cougnenc-1.3/src/dico.c
--- le-dico-de-rene-cougnenc-1.3/src/dico.c
+++ le-dico-de-rene-cougnenc-1.3/src/dico.c
@@ -1040,7 +1040,8 @@
  
 while (*str)
 {
-   *str = EquivalTable[ *str++ ] ;
+   *str = EquivalTable[ *str ] ;
+   str++;
 }
 
  return p ;
only in patch2:
unchanged:
--- le-dico-de-rene-cougnenc-1.3.orig/src/Makefile
+++ le-dico-de-rene-cougnenc-1.3/src/Makefile
@@ -2,8 +2,8 @@
 prefix = /usr
 
 dico: dico.c killposte.c
-	gcc dico.c -o dico
-	gcc killposte.c -o killposte
+	gcc -g dico.c -o dico
+	gcc -g killposte.c -o killposte
 
 clean:
 	rm -fr *~ dico killposte *.1 manpage.links manpage.refs

Bug#851707: pinentry-gtk-2 frequently fails to grab the keyboard under awesome

[Daniel Kahn Gillmor]

On Mon 2017-02-06 04:49:44 -0500, Vincent Lefevre wrote:
> On 2017-02-02 19:29:19 +0100, Vincent Bernat wrote:
>> Index: pinentry-1.0.0/gtk+-2/pinentry-gtk-2.c
>> ===
>> --- pinentry-1.0.0.orig/gtk+-2/pinentry-gtk-2.c
>> +++ pinentry-1.0.0/gtk+-2/pinentry-gtk-2.c
> [...]
>> -  while (tries++ < max_tries && err == GDK_GRAB_NOT_VIEWABLE);
>> +  while (tries++ < max_tries && err == GDK_GRAB_NOT_VIEWABLE
>> + && (usleep(1000), TRUE));
> [...]
>>while (tries++ < max_tries && (err == GDK_GRAB_NOT_VIEWABLE
>> - || err == GDK_GRAB_ALREADY_GRABBED));
>> + || err == GDK_GRAB_ALREADY_GRABBED)
>> + && (usleep(1000), TRUE));
>
> I don't know how it has eventually been fixed, but FYI, usleep()
> is obsolete. The usleep(3) man page says:
>
>   CONFORMING TO
>   4.3BSD,  POSIX.1-2001.   POSIX.1-2001  declares this function
>   obsolete; use nanosleep(2) instead.  POSIX.1-2008 removes the
>   specification of usleep().

patches welcome to do the conversion if this matters to anyone. i'm not
going to lose any usleep over this deprecation right now, since i think
we'll have that function available for a long time in debian.

 --dkg


signature.asc
Description: PGP signature

Bug#854423: Does not work on IPv6-only networks

[Steve McIntyre]

On Mon, Feb 06, 2017 at 11:53:41PM +, Steve McIntyre wrote:
>On Tue, Feb 07, 2017 at 12:39:23AM +0100, Axel Beckert wrote:
>>
>>Same question to you as to the other reporter: Have you tried to
>>configure a static IPv4 dummy address as workaround? (Just out of
>>curiosity if that's a workaround which could be recommended until
>>the issue is fixed properly.)
>
>Ah, didn't think of that. That's a possible thing to try,
>yes. As/when/if I get the time to play with this again (maybe on a
>separate test network at home), I'll give that a try.

I've tried this now. It's slightly problematic, as wicd tries to ping
the gateway it's given to validate connectivity. By using the local v4
address as the gateway too, that defeats this check. Then wicd keeps
the network interface up. Beyond that, I can't say much - I'm not
getting much useful networking beyond that but that's possibly my
network setup... :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back

Bug#854359: [pkg-gnupg-maint] Bug#854359: gnupg: always fails when --recv-keys

[Roger Shimizu]

Control: tag -1 -patch

On Thu, Feb 9, 2017 at 5:43 AM, NIIBE Yutaka  wrote:
> Roger Shimizu  wrote:
>>
>> [0] 
>> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=b200e636ab20d2aa93d9f71f3789db5a04af0a56
>
> ??? Please note that I am a developer of the upstream.  The patch you
> addressed is already included in 2.1.18.

So we need another fix.
Thanks for explanation!

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

Bug#854651: unblock: debootstrap/1.0.88

[Steve McIntyre]

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

Hey folks,

Please unblock debootstrap 1.0.88

We have a tiny fix for #836525, which will allow debootstrap to deal
with arch-qualified dependencies. It'll be a major PITA if debootstrap
can't deal with these in stretch. 

KiBi already knows about this upload and is happy AFAIK. He and I have
both tested the patch.

diff -Nru debootstrap-1.0.87/debian/changelog 
debootstrap-1.0.88/debian/changelog
--- debootstrap-1.0.87/debian/changelog 2016-11-16 05:47:27.0 +
+++ debootstrap-1.0.88/debian/changelog 2017-02-08 23:52:56.0 +
@@ -1,3 +1,10 @@
+debootstrap (1.0.88) unstable; urgency=high
+
+  [ Sven Joachim ]
+  * Strip the arch-qualifier (Closes: #836525)
+
+ -- Steve McIntyre <93...@debian.org>  Wed, 08 Feb 2017 23:53:10 +
+
 debootstrap (1.0.87) unstable; urgency=high
 
   [ Julien Cristau ]
diff -Nru debootstrap-1.0.87/functions debootstrap-1.0.88/functions
--- debootstrap-1.0.87/functions2016-10-31 04:01:25.0 +
+++ debootstrap-1.0.88/functions2017-02-03 00:52:30.0 +
@@ -1336,6 +1336,7 @@
for $d (split /\s*,\s*/, $1) {
$d =~ s/\s*[|].*$//;
$d =~ s/\s*[(].*[)]\s*//;
+   $d =~ s/:.*//;
push @d, $d;
}
}

unblock debootstrap/1.0.88

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

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

Bug#854650: openssh-client: does not list rsa-sha2-256 and rsa-sha2-512

[brian m. carlson]

Package: openssh-client
Version: 1:7.4p1-6
Severity: normal

ssh_config(5) lists "ssh -Q key" as the way to discover valid algorithms
for the HostKeyAlgorithms page.  However, neither the man page nor that
option lists the rsa-sha2-256 and rsa-sha2-512 options.

Since these values are not documented, users are likely to omit them,
resulting in negotiating weaker signature algorithms (RSA/SHA-1) than
they might otherwise have.

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages openssh-client depends on:
ii  adduser   3.115
ii  dpkg  1.18.22
ii  libc6 2.24-9
ii  libedit2  3.1-20160903-3
ii  libgssapi-krb5-2  1.15-1
ii  libselinux1   2.6-3
ii  libssl1.0.2   1.0.2k-1
ii  passwd1:4.4-3
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.9-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- no debconf information

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#854236: unblock: inkscape 0.92.1

[Mattia Rizzolo]

[ Keeping lot of context as this one email didn't make it to the ML due
to the big attachment ]

On Sun, Feb 05, 2017 at 11:05:28AM +0100, Mattia Rizzolo wrote:
> This is a preapproval request.
> 
> Currently stretch has inkscape version 0.92.0 + a bunch of patches
> backported from their stable branch.  I'd like to eventually ship
> 0.92.1, which is due in about 2 weeks if they keep the current schedule.
> For avoidance of doubt, their stable branch only carries bugfixes and
> i18n updates.
> 
> Yesterday they made a 0.92.1~pre1 release, which I tried to package, the
> changes which will occur after this will only be l10n updates and very
> important bug fixes.
> Attached you can find the full debdiff and a filtered debdiff made by
> $ filterdiff -x '*/po/*' -x '*/share/tutorials/*' -x '*/share/examples/*' -x 
> '*/doc/*' -x '*/packaging/*'
> We are not shipping anything from ./doc, and we have no use in what's
> inside ./packaging (mostly Windows stuff); also the tutorials and the
> examples take the biggest part of the diff because upstream re-scaled
> all the .svg's: https://bugs.launchpad.net/inkscape/+bug/1651815
> http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15302
> 
> 
> In particular there is one bugfix which I'm interested, which is causing
> malformed rendering of text boxes.  This random blog post can give you
> an idea of the problem (upstream is not good at bug triaging, so there
> is no real trackable bug…):
> http://peppercarrot.com/en/article396/new-inkscape-0-92-breaks-your-previous-works-done-with-inkscape
> It has been partially fixed by
> http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15338
> http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15350
> http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15351
> We expect some more tidying for next point release 0.92.2.
> 
> 
> You can see all the upstream changes here:
> http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/changes

In the meantime 0.92.1~pre2 happened.  Attached there are
 * relative diff from 0.92.1~pre1 I already attached to my previous email
 * filterdiff as above from the version currently in stretch (gzipped to
   be sure it gets to the ML), uncompressed also available at
   
https://volatile.mapreri.org/2017-02-09/e5f65e4c685109cbb1580f1c731f7cc0/0.92.1pre2-filtered.diff
I avoided a full diff from what's in stretch as you made clear that a
30+ MB diff is pointless for you.


0.92.1 is now totally freezed, and they expect to release it as is with
just the version changed.
https://sourceforge.net/p/inkscape/mailman/inkscape-devel/thread/20170208223327.GI24863%40bryceharrington.org/#msg35655759

> Thank you for considering.

!

-- 
regards,
Mattia Rizzolo

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

 CMakeLists.txt   |2 
 CMakeScripts/inkscape-version.cmake  |2 
 README.fr.txt|   73 +--
 configure.ac |2 
 debian/changelog |7 +-
 debian/patches/series|1 
 debian/patches/upstream/trunk/15484.patch|   32 +++
 doc/keys.de.html |   10 +--
 doc/keys.fr.html |   10 +--
 inkscape.de.pod  |   18 +-
 inkscape.el.pod  |   16 -
 inkscape.fr.pod  |   15 -
 inkscape.ja.pod  |   15 -
 inkscape.pod |2 
 inkscape.sk.pod  |   16 -
 inkscape.zh_TW.pod   |   15 -
 po/fr.po |   61 ++
 src/gradient-drag.cpp|6 +-
 src/gradient-drag.h  |2 
 src/knot.cpp |4 -
 src/knot.h   |1 
 src/libnrtype/Layout-TNG-Scanline-Makers.cpp |2 
 src/widgets/desktop-widget.cpp   |7 ++
 src/widgets/text-toolbar.cpp |   41 +++
 src/widgets/toolbox.cpp  |4 +
 25 files changed, 244 insertions(+), 120 deletions(-)

diff -Nru inkscape-0.92.1~pre1/CMakeLists.txt inkscape-0.92.1~pre2/CMakeLists.txt
--- inkscape-0.92.1~pre1/CMakeLists.txt	2017-02-04 00:47:22.0 +0100
+++ inkscape-0.92.1~pre2/CMakeLists.txt	2017-02-08 08:49:15.0 +0100
@@ -19,7 +19,7 @@
 
 project(inkscape)
 
-set(INKSCAPE_VERSION 0.92.1pre1)
+set(INKSCAPE_VERSION 0.92.1pr

Bug#852659: [le-dico-de-rene-cougnenc] segment fault

[Sandro Tosi]

Hello Bernhard,

On Wed, Feb 8, 2017 at 4:43 PM, Bernhard Übelacker
 wrote:
> Hello Sandro,
>
> Am 08.02.2017 um 01:24 schrieb Sandro Tosi:
>> Hey Bernhard,
>> would be interested in preparing a NMU package with your patches
>> included (feel free to reply to me in private if you need instructions
>> on how to do that)? alternatively i'd be happy to NMU this myself
>
> I tried to prepare a package and put it in [1].
> Is it right how the changes are applied and what the changelog contains?
> The package would then still need a sponsor.

i just uploaded your nmu in delayed/3 (so the maintainer has 3 days of
time before it actually reaches the archive); it all look good, i'm
only a bit  wary about the -dbgsym change, but we'll look how it works
out in the end. please remember to follow up with the release team
once it's accepted.

Thanks for your contribution to Debian!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#854297: Version v304

[Ulrik Sverdrup]

Dear Maintainer,

I had some attention to the eye of a debian maintainer and finally
cleaned up our distributable tarball in Kupfer v304, so it doesn't
contain any crufty unused files that you have to account for. At the end
of my email I put a proposed new version of the copyright file (just
removing the sections that don't matter). The package should now build
using Python 3 with the waf script too (For example using `python3 waf
configure ... ` in Debian).

I looked at the debian package patch queue and what I can see they
should all now be upstream, except for the keyring patch. That one is
N/A to the new version of kupfer.

Best
Ulrik

Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: kupfer
Upstream-Contact: Ulrik Sverdrup 
Source: https://kupferlauncher.github.io/

Files: *
Copyright: 2007-2017, Ulrik Sverdrup 
License: GPL-3+

Files: auxdata/kupfer.svg:
Copyright: 2010 Nasser Alshammari 
License: GPL-3+


Files: kupfer/core/relevance.py
Copyright: 2009, Ulrik Sverdrup 
   2008, Christian Hergert 
   2007, Chris Halse Rogers, DR Colkitt
 David Siegel, James Walker
 Jason Smith, Miguel de Icaza
 Rick Harding, Thomsen Anders
 Volker Braun, Jonathon Anderson
License: GPL-3+

Files: kupfer/plugin/qsicons/*
Copyright: Quicksilver Developers
License: Apache-2.0

Files: waf*
Copyright: 2005-2010, Thomas Nagy
License: BSD-3

Files: debian/*
Copyright: 2009-2011, Luca Falavigna 
   2014, Hugo Lefeuvre 
License: GPL-3+

Bug#822974: [pkg-gnupg-maint] Backport of GnuPG 2.1

[Daniel Kahn Gillmor]

Hi Luca--

Thank you for all this work, this is awesome!  sorry for my delay in
responding.

On Wed 2017-02-08 15:05:09 -0500, Luca Capello wrote:

>> Daniel, what do you think about adding the jessie-backports branches I
>> have locally to the corresponding Git repositories on Alioth?

I think this is a great idea.  gcrypt isn't in the pkg-gnupg git
repos -- i don't know how Andreas wants to handle that.  But if you've
got patch series you want to propose for the pkg-gnupg repos, please
point me at them, either by sending them to this bug report, or by
pointing me to some other git repos (personal repos on alioth are also
fine), i can review and import them.

Or, if you prefer, i can do a single-step import process for each repo
that include all your backported sources in one commit.  let me know
what you prefer.

> I will work on the GnuPG 2.1 backports ASAP and report back.

very much appreciated, thanks!  happy to chat on IRC if you run into any
trouble.

--dkg


signature.asc
Description: PGP signature

Bug#827222: diffoscope: Support a timeout on the individual commands invoked by diffoscope

[Chris Lamb]

Chris Lamb:

> Thus, I am marking this as wontfix.

(I'm actually going to close the bug too...)


Regards,

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

Bug#852837: Should buggy inkscape 0.92 make it to stable?

[juichenieder-debbie]

Inkscape 0.92 with this bug, combined with the dog's breakfast it makes of
text from earlier versions of inkscape [1], makes me wonder if we should allow
0.92 to make it out to stable (given that the freeze has just begun).

As far as I know a patched version, 0.92.1 will come out with a half-baked
solution soon, followed by 0.92.2 with a cleaner solution.  With stretch in
freeze shouldn't we push inkscape back down to 0.91-12 and await the release of
0.92.2?  I know I would rather have a slightly less feature-rich version of
inkscape, but stable, then one with a few more features, but makes a mess of all
of nearly all previous files that I try to open...


[1] https://bugs.launchpad.net/inkscape/+bug/1655483?comments=all 

Bug#854593: diffoscope: autopkgtest fail

[Mattia Rizzolo]

On Thu, Feb 09, 2017 at 12:42:36PM +1300, Chris Lamb wrote:
> Ah, my "minimal" chroot had xxd installed.

Yes, autopkgtest's chroots are *very* minimal :)

Thanks for tracking this down!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#854593: diffoscope: autopkgtest fail

[Chris Lamb]

tags 854593 + pending
thanks

Chris Lamb wrote:

> > FAIL tests/comparators/test_device.py::test_diff
> > FAIL tests/comparators/test_device.py::test_diff_reverse
[…] 
> > FAIL tests/comparators/test_rpm.py::test_fallback_comparison

Ah, my "minimal" chroot had xxd installed. Fixed in Git:

  https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=5696911


Regards,

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

Bug#854487: [Pkg-puppet-devel] Bug#854487: Bug#854487: Bug#854487: Bug#854487: Binary-only package puppet was silently converted into a package shipping and running a service

[Russ Allbery]

Apollon Oikonomopoulos  writes:

> Additionally, all the setups I know of use cron for running the puppet
> agent, so these admins will want the service disabled anyway (of course
> this is argumentum ad populum, but it serves as an indication that this
> is not an unreasonable course of action).

Yeah, this is a good argument.  Works for me!  It's also good to use a
more robust mechanism for doing this so that we don't get accidental
problems in the future when the locking stuff changes again.

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

Bug#853947: [Swan-dev] Bug#853947: libreswan FTBFS on mips and mipsel: error: "_ABI64" is not defined [-Werror=undef]

[Paul Wouters]

On Wed, 8 Feb 2017, Daniel Kahn Gillmor wrote:


 #if _MIPS_SIM == _ABI64
  ^~
cc1: all warnings being treated as errors
../../../mk/depend.mk:28: recipe for target 'base64_rsa_pubkey.o' failed


Would you know how NSS deals with this on MIPS?


I don't know what to say about this, but nss itself builds fine on MIPS:

 https://buildd.debian.org/status/logs.php?arch=&pkg=nss


Right, so this is the case that really matters because the error in
libreswan comes from working around:

https://bugzilla.mozilla.org/show_bug.cgi?id=1336487

So we have copied some code from NSS into libreswan to deal with that
bug. And that is the code that is failing.


as do packages that depend on it, like ceph or systemtap:


Yes, because the function we need from NSS that isn't properly exported
uses some other internal-only functions and we needed to copy those as
well and that is were the problem is.

Interestingly, I found a page that seems to introduce the issue for nss:

https://www.linux-mips.org/archives/linux-mips/2004-10/msg00063.html

A snippet from that page:

+#include 
+
#define _MCOUNT_DECL(frompc,selfpc) \
static void __attribute_used__ __mcount (u_long frompc, u_long selfpc)

@@ -81,10 +83,10 @@
# define CPRETURN
#endif

-#if defined _ABIN32 && _MIPS_SIM == _ABIN32
+#if _MIPS_SIM == _MIPS_SIM_NABI32
# define PTR_ADDU_STRING "add" /* no u */
# define PTR_SUBU_STRING "sub" /* no u */
-#elif defined _ABI64 && _MIPS_SIM == _ABI64
+#elif _MIPS_SIM == _MIPS_SIM_ABI64
# define PTR_ADDU_STRING "daddu"
# define PTR_SUBU_STRING "dsubu"
#else

I found a copy of sgidefs.h which has:

#ifndef _ABI64
# define _ABI64 3

So, try the attached patch, that basically does:

+#ifndef _ABIO32
+# define _ABIO321
+#endif
+
+#ifndef _ABIN32
+# define _ABIN322
+#endif
+
+#ifndef _ABI64
+# define _ABI64 3
+#endif

Pauldiff --git a/include/nss_copies.h b/include/nss_copies.h
index bd3478f..12c478c 100644
--- a/include/nss_copies.h
+++ b/include/nss_copies.h
@@ -18,3 +18,16 @@
 
 SECCertTimeValidity NSSCERT_CheckCrlTimes(CERTCrl *crl, PRTime t);
 SECComparison NSSCERT_CompareAVA(const CERTAVA *a, const CERTAVA *b);
+
+/* Workaround for MIPS */
+#ifndef _ABIO32
+# define _ABIO321
+#endif
+
+#ifndef _ABIN32
+# define _ABIN322
+#endif
+
+#ifndef _ABI64
+# define _ABI64 3
+#endif

Bug#853619: proposed fix

[Kir Kolyshkin]

A fix has been committed to ploop repo:

https://src.openvz.org/projects/OVZL/repos/ploop/commits/d4298fb98245be22ebe9f576e455c7bf9b26

As gcc-7 is still experimental/unreleased, no new ploop release
is currently planned.

Bug#854041: systemd: dpkg fails for systemd package when upgrading from jessie to stretch

[Carsten Brandt]

On 09.02.2017 00:23, Michael Biebl wrote:
> I get an error trying to access that file:
> 
> Data directory (/data) not writable by ownCloud

Bad luck, there was a temporary issue with my server a few minutes ago.
Should be fixed now.

Bug#854524: unblock: linux/4.9.6-3

[Cyril Brulebois]

Jonathan Wiltshire  (2017-02-08):
> Control: tag -1 moreinfo
> 
> On Wed, Feb 08, 2017 at 01:46:50AM +, Ben Hutchings wrote:
> > Please unblock package linux
> > 
> > This includes many important bug fixes, including security fixes, and
> > new hardware support.  It also disables logfs, which is being removed
> > in Linux 4.10 and therefore would not be supportable in stretch.
> > 
> > The debdiff would be too large for you to review, unfortunately.
> > Instead, here are the changelog entries:
> 
> Likely to take on trust, but needs a d-i ack either way.

Fine with me, thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#854041: systemd: dpkg fails for systemd package when upgrading from jessie to stretch

[Michael Biebl]

Am 03.02.2017 um 15:19 schrieb Carsten Brandt:
> Am 03.02.2017 um 14:15 schrieb Michael Biebl:
>> Carsten, can you attach /var/lib/dpkg/status from before the upgrade.
>> This should give us an opportunity to reproduce the problem.
> 
> 
> You can download it from here:
> 
> https://cloud.cebe.cc/s/D5snvzhWpsLdtyg
> 
> It is the last version from /var/backups/dpkg.status.0

I get an error trying to access that file:

Data directory (/data) not writable by ownCloud

-- 
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#854649: synaptic: After Installation: Warning Message "UnSandboxed"

[S.Allen]

Package: synaptic
Version: 0.84.1
Severity: normal

Dear Maintainer,

Verbatim Error:

W: Download is performed unsandboxed as root as file
'/root/.synaptic/tmp//tmp_sh' couldn't be accessed by user '_apt'. -
pkgAcquire::Run (13: Permission denied)



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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.15-1
ii  libapt-inst2.0   1.4~beta4
ii  libapt-pkg5.01.4~beta4
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libept1.5.0  1.1+nmu3+b1
ii  libgcc1  1:6.3.0-5
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgnutls30  3.5.8-1
ii  libgtk-3-0   3.22.7-2
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpcre2-8-0 10.22-2
ii  libstdc++6   6.3.0-5
ii  libvte-2.91-00.46.1-1
ii  libx11-6 2:1.6.4-3
ii  libxapian30  1.4.3-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages synaptic recommends:
ii  gksu   2.0.2-9
ii  libgtk2-perl   2:1.2499-1
ii  policykit-10.105-17
ii  rarian-compat  0.8.1-6
ii  xdg-utils  1.1.1-1

Versions of packages synaptic suggests:
ii  apt-xapian-index 0.49
pn  deborphan
pn  dwww 
ii  menu 2.1.47
ii  software-properties-gtk  0.96.20.2-1
ii  tasksel  3.39

-- no debconf information

Bug#854648: systemd-sysv: Immediate shutdown can happen despite future time argument if unable to talk to shutdownd

[Will Aoki]

Package: systemd
Version: 215-17+deb8u6
Severity: minor

After upgrading a system from wheezy to jessie, I attempted to schedule a
reboot at 8:27 AM by executing '/sbin/shutdown -r 08:27 completing upgrade'.
It produced this (partial) error, which did not stay on the screen long enough
to copy:

   Failed to talk to shutdownd, proceeding with immediate shutdown:

and rebooted immediately.

Rebooting immediately when the user has specified a time in the future is
unexpected and undocumented behavior.

I have not tested this patch, but the gist of the fix is:

--- src/systemctl/systemctl.c   2017-02-08 15:45:39.0 -0700
+++ src/systemctl/systemctl.c.orig  2017-02-08 16:04:21.503618530 -0700
@@ -6897,7 +6897,8 @@
m);
 
 if (r < 0)
-log_warning("Failed to talk to shutdownd, proceeding 
with immediate shutdown: %s", strerror(-r));
+log_warning("Failed to talk to shutdownd, not 
scheduling shutdown: %s", strerror(-r));
+   return -1;
 else {
 char date[FORMAT_TIMESTAMP_MAX];
 


It could instead be fixed by updating the manpage, but not rebooting
immediately follows the principle of least surprise.

Bug#853947: [Swan-dev] Bug#853947: libreswan FTBFS on mips and mipsel: error: "_ABI64" is not defined [-Werror=undef]

[Daniel Kahn Gillmor]

On Wed 2017-02-08 13:37:39 -0500, Andrew Cagney wrote:
> On 3 February 2017 at 13:57, Daniel Kahn Gillmor  
> wrote:
>> -MMD -MF ./base64_rsa_pubkey.d \
>> -o ./base64_rsa_pubkey.o \
>> -c /«PKGBUILDDIR»/lib/libswan/base64_rsa_pubkey.c
>> In file included from /usr/include/nspr/prtypes.h:26:0,
>>  from /usr/include/nss/seccomon.h:17,
>>  from /usr/include/nss/nss.h:34,
>>  from /«PKGBUILDDIR»/lib/libswan/base64_rsa_pubkey.c:21:
>> /usr/include/nspr/prcpucfg.h:511:18: error: "_ABI64" is not defined 
>> [-Werror=undef]
>>  #if _MIPS_SIM == _ABI64
>>   ^~
>> cc1: all warnings being treated as errors
>> ../../../mk/depend.mk:28: recipe for target 'base64_rsa_pubkey.o' failed
>
> Would you know how NSS deals with this on MIPS?

I don't know what to say about this, but nss itself builds fine on MIPS:

  https://buildd.debian.org/status/logs.php?arch=&pkg=nss

as do packages that depend on it, like ceph or systemtap:

  https://buildd.debian.org/status/logs.php?arch=&pkg=ceph
  https://buildd.debian.org/status/logs.php?arch=&pkg=systemtap

other dependent packages appear to have some build failures there too:

  https://buildd.debian.org/status/logs.php?arch=&pkg=dogtag-pki


Sorry to not understand the problem space better!  I hope the build logs
linked above are useful in getting new ideas for how to solve it.

   --dkg


signature.asc
Description: PGP signature

Bug#850229: openmpi-bin: default for oversubscription changed

[Santiago Vila]

severity 850559 serious
thanks

On Thu, 19 Jan 2017, Graham Inggs wrote:

> On 19/01/2017 13:59, Santiago Vila wrote:
> > That would be somewhere in debian/rules (in dh_auto_build) for the affected
> > packages?
> > Or somewhere else?
> 
> Yes, just add 'export OMPI_MCA_rmaps_base_oversubscribe=1' near the top of
> debian/rules.
> 
> Most MPI programs should already have 'export
> OMPI_MCA_plm_rsh_agent=/bin/false' somewhere, so just below that line would be
> fine.
> 
> Would you please confirm that this fix works for one of the affected packages
> on your setup?

Sorry, my setup is only ready to test packages in the archive (testing or 
unstable).

I will gladly test any package which is uploaded for unstable.

Dear openmpi people and interested parties: please do agree on the
right fix for this, either following the route suggested by Ansgar
when he reassigned this to openmpi-bin or by adding a few lines to the
debian/rules file of affected packages, as suggested by Graham.

Graham, if you truly think adding a variable is better, please act
accordingly and reassign back to the affected packages.

In either case I'm setting this to serious again because it makes
packages to fail on single-CPU systems, and having more than one CPU is
definitely *not* part of the build-essential definition.

Thanks.

Bug#837081: netbeans: Crashes due to assertion failure in GLib

[Markus Koschany]

On 08.02.2017 13:40, Přemysl Vyhnal wrote:
> Thanks, logs attached
> to https://netbeans.org/bugzilla/show_bug.cgi?id=268644

Hello,

that was a misunderstanding. You need to attach the log files to this
bug report because upstream won't investigate this bug report as long as
everything works fine with the Oracle JDK. We also need the log files
from Debian's version of Netbeans but you apparently use a different
version because of

Product Version = NetBeans IDE 8.2 (Build 201609300101) (#5fd841261bf9)

in your log file.



signature.asc
Description: OpenPGP digital signature

Bug#854646: [ranger] sensible-pager patch breaks functionnalities

[Simon Désaulniers]

Package: ranger
Version: 1.8.1-0.1
Tags: important

Hi,

As discussed on upstream's bug trackker[1], using the following patch breaks
some functionnalities:

0002-make-sensible-decisions-on-which-pager-and-editor.patch

For instance, when entering a subshell and calling any program which requires a
pager, we get the error:

/usr/bin/sensible-pager: 3: /usr/bin/sensible-pager: Cannot fork

Regards,


[1]: https://github.com/ranger/ranger/issues/750

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature

Bug#854647: doc-linux-hr: Too outdated for being useful

[Adrian Bunk]

Package: doc-linux-hr
Version: 2416.1+nmu1
Severity: serious

I do not speak Croatian, but both from looking the contents
of the package and reading debian/copyright it is clear that
these are HOWTOs (several of them translations from English ones)
that date from 1995-2000.

Bug#854332: cloud-sptheme: please make the build reproducible

[Chris Lamb]

tags 854332 + fixed-upstream
thanks

Fixed upstream in 1.8.3:

  
https://bitbucket.org/ecollins/cloud_sptheme/pull-requests/22/please-make-the-build-reproducible/diff#comment-31148412


Regards,

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

Bug#853772: marked as done (1.8-1 crashes when attempting to download from www.svtplay.se)

[Gunnar Hjalmarsson]

Hi Olof,

I acted on this primarily to prevent the buggy 1.8-1 from ending up in 
Ubuntu 17.04. Thanks to Mattia it's now fixed in both 17.04 and unstable.


I have uploaded a more spot on fix to this PPA (debdiff attached):

https://launchpad.net/~gunnarhj/+archive/ubuntu/svtplay-dl

I assumed that this bug report can be reopened for the purpose.

HTH

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj
diff -ru svtplay-dl-1.8.orig/debian/changelog svtplay-dl-1.8/debian/changelog
--- svtplay-dl-1.8.orig/debian/changelog2016-11-15 20:25:32.0 
+0100
+++ svtplay-dl-1.8/debian/changelog 2017-02-08 22:33:06.445766021 +0100
@@ -1,3 +1,10 @@
+svtplay-dl (1.8-1.1~ppa) yakkety; urgency=medium
+
+  * debian/patches/debian-changes:
+Fix KeyError crash, issue #528. Closes: #853772
+
+ -- Gunnar Hjalmarsson   Wed, 08 Feb 2017 22:33:00 +0100
+
 svtplay-dl (1.8-1) unstable; urgency=medium
 
   * New upstream version 1.8
diff -ru svtplay-dl-1.8.orig/debian/patches/debian-changes 
svtplay-dl-1.8/debian/patches/debian-changes
--- svtplay-dl-1.8.orig/debian/patches/debian-changes   2016-11-15 
20:25:32.0 +0100
+++ svtplay-dl-1.8/debian/patches/debian-changes2017-02-08 
22:31:18.837408272 +0100
@@ -32,3 +32,118 @@
  
  svtplay-dl: $(PYFILES)
@# Verify that there's no .build already \
+
+Description: Fix KeyError crash
+Origin: https://github.com/spaam/svtplay-dl/commit/dac1b6
+Bug: https://bugs.debian.org/853772
+
+--- a/lib/svtplay_dl/service/svtplay.py2016-11-14 23:53:49.0 
+0100
 b/lib/svtplay_dl/service/svtplay.py2017-02-08 21:56:34.415324777 
+0100
+@@ -50,16 +50,22 @@
+ for i in janson["video"]["subtitles"]:
+ if i["format"] == "WebSRT":
+ yield subtitle(copy.copy(self.options), "wrst", i["url"])
++if "programVersionId" in janson["video"]:
++vid = janson["video"]["programVersionId"]
++else:
++vid = janson["video"]["id"]
++res = 
self.http.get("http://api.svt.se/videoplayer-api/video/{}".format(vid))
++janson = res.json()
+ 
+-if "videoReferences" in janson["video"]:
+-if len(janson["video"]["videoReferences"]) == 0:
++if "videoReferences" in janson:
++if len(janson["videoReferences"]) == 0:
+ yield ServiceError("Media doesn't have any associated videos 
(yet?)")
+ return
+ 
+-for i in janson["video"]["videoReferences"]:
++for i in janson["videoReferences"]:
+ parse = urlparse(i["url"])
+ query = parse_qs(parse.query)
+-if i["playerType"] == "hls" or i["playerType"] == "ios":
++if i["format"] == "hls":
+ streams = hlsparse(self.options, self.http.request("get", 
i["url"]), i["url"])
+ if streams:
+ for n in list(streams.keys()):
+@@ -71,7 +77,7 @@
+ if streams:
+ for n in list(streams.keys()):
+ yield streams[n]
+-if i["playerType"] == "playerType" or i["playerType"] == 
"flash":
++if i["format"] == "hds":
+ match = re.search(r"\/se\/secure\/", i["url"])
+ if not match:
+ streams = hdsparse(self.options, 
self.http.request("get", i["url"], params={"hdcore": "3.7.0"}), i["url"])
+@@ -85,7 +91,7 @@
+ if streams:
+ for n in list(streams.keys()):
+ yield streams[n]
+-if i["playerType"] == "dash264" or i["playerType"] == 
"dashhbbtv":
++if i["format"] == "dash264" or i["format"] == "dashhbbtv":
+ streams = dashparse(self.options, 
self.http.request("get", i["url"]), i["url"])
+ if streams:
+ for n in list(streams.keys()):
+@@ -119,7 +125,7 @@
+ 
+ def _genre(self, jansson):
+ videos = []
+-for i in jansson["clusterPage"]["content"]["clips"]:
++for i in jansson["clusterPage"]["clips"]:
+ videos.append(i["contentUrl"])
+ return videos
+ 
+@@ -147,16 +153,16 @@
+ if re.search("/genre", parse.path):
+ videos = self._genre(dataj)
+ else:
+-items = dataj["videoTitlePage"]["realatedVideosTabs"]
++items = dataj["videoTitlePage"]["relatedVideosTabs"]
+ for i in items:
+ if "sasong" in i["slug"]:
+ for n in i["videos"]:
+-if n["url"] not in videos:
+-videos.append(n["url"])
++if n["contentUrl"] not in videos:
++  

Bug#854295: brltty-espeak: crashes while emitting speech

[Samuel Thibault]

Hello,

Sebastian Humenda, on Sun 05 Feb 2017 21:02:37 +0100, wrote:
> I'm not sure whether the issue is actually in BRLTTY or espeak-ng, but
> I couldn't encounter any issues while using speech-dispatcher with
> espeak-ng yet.

Ok.  I'm afraid that might be an issue with the way BRLTTY uses espeak
and espeak-ng behaves: BRLTTY sets a callback, but espeak-ng calls it
from its own thread, which may pose some unexpected issues.  Could you
try the attached patch? It may cripple BRLTTY functionalities a bit, but
at least potentially make it more robust for Stretch, and we'll have a
closer look upstream.

Samuel
diff --git a/Drivers/Speech/eSpeak/speech.c b/Drivers/Speech/eSpeak/speech.c
index 6c303c759..9b58bc58b 100644
--- a/Drivers/Speech/eSpeak/speech.c
+++ b/Drivers/Speech/eSpeak/speech.c
@@ -167,7 +189,7 @@ static int spk_construct(volatile SpeechSynthesizer *spk, 
char **parameters)
if (val > espeakRATE_MINIMUM) maxrate = val;
}
 
-   espeak_SetSynthCallback(SynthCallback);
+   //espeak_SetSynthCallback(SynthCallback);
 
return 1;
 }

Bug#852111: Bug#854452: marked as done (ITP: kissebook -- A ebook organizer with quick 'open ebook file' option using user defined viewer and reader)

[Don Armstrong]

reopen 854452
forcemerge 852111 854452
retitle 854452 ITP: kissebook -- A ebook organizer with quick 'open ebook file' 
option using user defined viewer and reader
owner 854452 Elif AKDAĞ 
thanks

On Thu, 09 Feb 2017, Elif AKDAĞ wrote:
> I don't quite understand what you mean by mail for being a freshman. I wish

There was already an RFP bug for this package open, so you should have
just retitled that bug.[1] I've now merged the new bug you filed with
the existing RFP[2] and retitled the existing RFP[3] which you could
have done using the cont...@bugs.debian.org server control interface.


1: https://www.debian.org/devel/wnpp/
2: https://www.debian.org/Bugs/server-control#forcemerge
3: https://www.debian.org/Bugs/server-control#retitle
-- 
Don Armstrong  https://www.donarmstrong.com

We have to face the fact that either all of us are going to die
together or we are going to learn to live together and if we are to
live together we have to talk. 
 -- Eleanor Roosevelt

Bug#854616: [pkg-gnupg-maint] Bug#854616: Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

[Daniel Kahn Gillmor]

On Wed 2017-02-08 16:15:21 -0500, NIIBE Yutaka wrote:
> No, this is not a hack.  This is a configuration needed.
>
> It seems for me that Yubico has been recommended use of PC/SC service.
> Since no one has reported for use of internal CCID driver, there is no
> entry for Yubikey in /lib/udev/rules.d/60-scdaemon.rules on Debian.
>
> Now, since it is confirmed, we should add an entry.

Hi Gniibe--

Thanks for your work on sorting this out!  If there are patches that
should go into the scdaemon package for stretch, we should include,
hopefully soon!

If you want to roll a release of the gnupg2 package to update scdaemon,
that's fine with me.  Or if you'd rather push a series of patches to our
shared git repository on alioth for an extra pair of eyes, i'm happy to
review them when they're ready.

or, send patches upstream and post commit IDs here, or send a separate
patch go pkg-gnupg-maint, however you prefer :)

There are a few other udev rule updates that seem to be pending in
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=scdaemon;dist=unstable
and i think a patch (or series of patches) to include them all would be
completely reasonable to aim for inclusion with stretch.

Thanks for the smartcard wrangling!

   --dkg


signature.asc
Description: PGP signature

Bug#854442: XXE vulnerability in python-openpyxl

[Markus Koschany]

Hi,

I am currently investigating if the versions of openpyxl in Wheezy and
Jessie are vulnerable. Apparently support for lxml was first introduced
in version 1.8. Wheezy and Jessie ship older versions though.

Is there another attack vector or can we assume that all versions
without lxml support are not affected?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#854359: [pkg-gnupg-maint] Bug#854359: Bug#854359: gnupg: always fails when --recv-keys

[Daniel Kahn Gillmor]

Control: forwarded 854359 https://bugs.gnupg.org/gnupg/issue2928
Control: retitle 854359 dirmngr fails when reverse DNS lookups do not work

On Wed 2017-02-08 15:43:58 -0500, NIIBE Yutaka wrote:
> My point is that currently there is a little issue in keyservers side
> themselves.  One of keyservers in hkps.pool.sks-keyservers.net doesn't
> have valid combination of PTR record and A record.  Current
> implementation of dirmngr is not robost enough to handle this
> glitch ... which should be fixed, IMO.

I agree with gniibe's observation about problems with the reverse
lookups, as well as his diagnosis that it is a lack of robustness in
dirmngr.

This was reported upstream at https://bugs.gnupg.org/gnupg/issue2928 --
the use of the PTR lookup is not only not useful, it's actively causing
this failure.

I've adjusted the debian bug to point to the correct upstream bug.

 --dkg


signature.asc
Description: PGP signature

Bug#854645: ITP: golang-github-grpc-ecosystem-go-grpc-prometheus -- Prometheus monitoring for gRPC Go servers

[Potter, Tim]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-grpc-ecosystem-go-grpc-prometheus
  Version : 1.1+git20160910.0.6b7015e-1
  Upstream Author : Michael Witkowski
* URL : https://github.com/grpc-ecosystem/go-grpc-prometheus
* License : Apache-2.0
  Programming Lang: Go
  Description : Prometheus monitoring for gRPC Go servers

 This library uses gRPC Go interceptors (middleware) to implement both
 server- and client-side metrics and monitoring using Prometheus for a
 gRPC interface.
 .
 Using Prometheus for API monitoring allows querying and visualization
 of latency, request rates and other useful metrics that can be
 obtained from collecting time-series data.




signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#848945: Updated Patch

[Chris Dos]

Thank you for the suggestion.  I've updated the patch and attached it.
*** /tmp/10_linux.orig	2017-02-02 08:02:36.926542777 -0700
--- /etc/grub.d/10_linux	2017-02-02 15:26:02.138285042 -0700
***
*** 77,85 
  	GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
  	fi;;
  xzfs)
! 	rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 2>/dev/null || true`
! 	bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
! 	LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs}"
  	;;
  esac
  
--- 77,96 
  	GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
  	fi;;
  xzfs)
! 	zfsbootfs=`zpool get bootfs | sed '2,100!d' |  grep -v '\s-' | awk {'print $3'} 2>/dev/null || true`
! 	if [ "${zfsbootfs}" = "" ]
! 	then
! 		echo "zpool bootfs parameter not set.  System will fail to boot!" 1>&2 
! 	elif [ "$(echo ${zfsbootfs} | wc -w)" -gt "1" ]
! 	then
! 		echo "Multiple zpool bootfs parameters detected:" 1>&2
! 		echo ${zfsbootfs} 1>&2
! echo 1>&2
! 		zfsbootfs=`echo ${zfsbootfs} | awk {'print $1'}`
! 		echo "Using the first bootfs listed: ${zfsbootfs}" 1>&2
! 		echo "Final LINUX_ROOT_DEVICE=ZFS=${zfsbootfs}" 1>&2
! 	fi
! 	LINUX_ROOT_DEVICE="ZFS=${zfsbootfs}"
  	;;
  esac
  

Bug#854644: pysiogame: Catalan translation update

[Guillem Jover]

Package: pysiogame
Version: 3.60.814-1
Severity: wishlist
Tags: patch
X-Debbugs-CC: jo...@debian.org

Hi!

Jordi prepared a Catalan translation update, which I've updated very
slightly. Attached.

Thanks,
Guillem
diff --git i/i18n/custom/ca.py w/i18n/custom/ca.py
index d595cea..f5a9e0d 100644
--- i/i18n/custom/ca.py
+++ w/i18n/custom/ca.py
@@ -18,8 +18,8 @@ numbers2090 = ['vint', 'trenta', 'quaranta', 'cinquanta', 'seixanta', 'setanta',
 
 #The following 2 lines are not to be translated but replaced with a sequence of words starting in each of the letters of your alphabet in order, best if these words have a corresponding picture in images/flashcard_images.jpg. The second line has the number of the image that the word describes.
 #The images are numbered from left to bottom such that the top left is numbered 0, the last image is 73, if none of the available things have names that start with any of the letters we can add new pictures.
-dp['abc_flashcards_word_sequence'] = ['Ànec', 'Barca', 'Coala', 'Calçat', 'Dofí', 'Elefant', 'Formiga', 'Gat', 'Hipopotam', 'Iglú', 'Joguina', 'Kiwi', 'Lleó', 'Mússol', 'Nit', 'Oceà', 'Poma', 'Quadern', 'Ratolí', 'Síndria', 'Tomàquet', 'Ull', 'Violí', 'Windsurf', 'Xilofon', 'Yoga', 'Zebra']
-d['abc_flashcards_word_sequence'] = ['<1>À<2>nec', '<1>B<2>arca', '<1>C<2>oala', '<2>Cal<1>ç<2>at', '<1>D<2>ofí', '<1>E<2>l<1>e<2>fant', '<1>F<2>ormiga', '<1>G<2>at', '<1>H<2>ipopotam', '<1>I<2>glú', '<1>J<2>oguina', '<1>K<2>iwi', '<1>L<2>leó', '<1>M<2>ússol', '<1>N<2>it', '<1>O<2>ceà', '<1>P<2>oma', '<1>Q<2>uadern', '<1>R<2>atolí', '<1>S<2>índria', '<1>T<2>omàque<1>t', '<1>U<2>ll', '<1>V<2>iolí', '<1>W<2>indsurf', '<1>X<2>ilofon', '<1>Y<2>oga', '<1>Z<2>ebra']
+dp['abc_flashcards_word_sequence'] = ['Ànec', 'Barca', 'Coala', 'Calçat', 'Dofí', 'Elefant', 'Formiga', 'Gat', 'Hipopòtam', 'Iglú', 'Joguina', 'Kiwi', 'Lleó', 'Mussol', 'Nit', 'Oceà', 'Poma', 'Quadern', 'Ratolí', 'Síndria', 'Tomàquet', 'Ull', 'Violí', 'Windsurf', 'Xilòfon', 'Yoga', 'Zebra']
+d['abc_flashcards_word_sequence'] = ['<1>À<2>nec', '<1>B<2>arca', '<1>C<2>oala', '<2>Cal<1>ç<2>at', '<1>D<2>ofí', '<1>E<2>l<1>e<2>fant', '<1>F<2>ormiga', '<1>G<2>at', '<1>H<2>ipopòtam', '<1>I<2>glú', '<1>J<2>oguina', '<1>K<2>iwi', '<1>L<2>leó', '<1>M<2>ussol', '<1>N<2>it', '<1>O<2>ceà', '<1>P<2>oma', '<1>Q<2>uadern', '<1>R<2>atolí', '<1>S<2>índria', '<1>T<2>omàque<1>t', '<1>U<2>ll', '<1>V<2>iolí', '<1>W<2>indsurf', '<1>X<2>ilòfon', '<1>Y<2>oga', '<1>Z<2>ebra']
 
 d['abc_flashcards_frame_sequence'] = [3, 1, 72, 60, 59, 4, 0, 2, 47, 8, 58, 74, 11, 14, 54, 52, 42, 13, 12, 26, 33, 75, 21, 66, 23, 32, 25]
 
diff --git i/i18n/po/ca.po w/i18n/po/ca.po
index dac234b..7e085ea 100644
--- i/i18n/po/ca.po
+++ w/i18n/po/ca.po
@@ -9,7 +9,7 @@ msgstr ""
 "Project-Id-Version: 1.31.105\n"
 "Report-Msgid-Bugs-To: Ireneusz Imiolek \n"
 "POT-Creation-Date: 2013-11-01 15:33+\n"
-"PO-Revision-Date: 2014-11-24 19:31+0100\n"
+"PO-Revision-Date: 2016-10-24 11:18+0200\n"
 "Last-Translator: Ireneusz Imiolek \n"
 "Language-Team: Ireneusz Imiolek \n"
 "Language: Catalan\n"
@@ -133,7 +133,7 @@ msgid "Cube"
 msgstr "Cub"
 
 msgid "Square Prism"
-msgstr "Prisma Quadrat"
+msgstr "Prisma quadrat"
 
 msgid "Triangular Prism"
 msgstr "Prisma triangular"
@@ -163,7 +163,7 @@ msgid "Hi Stranger :) Would you like to log in so we know who you are?"
 msgstr "Hola foraster :) Vols iniciar la sessió per a saber qui ets?"
 
 msgid "Log in:"
-msgstr "Iniciar la sessió:"
+msgstr "Inici de sessió:"
 
 msgid "user name:"
 msgstr "nom d'usuari:"
@@ -172,7 +172,7 @@ msgid "password:"
 msgstr "paraula clau:"
 
 msgid "remember me"
-msgstr "recorda't de mi"
+msgstr "recorda-ho"
 
 msgid "Login"
 msgstr "Inici de sessió"
@@ -193,7 +193,7 @@ msgid "User Management"
 msgstr "Administració d'usuaris"
 
 msgid "Please select a user from the list."
-msgstr "Seleccion un usuari de la llista."
+msgstr "Selecciona un usuari de la llista."
 
 msgid "Delete user"
 msgstr "Esborra l'usuari"
@@ -221,22 +221,22 @@ msgid "allow adding new users on login screen"
 msgstr "permet afegir usuaris nous a la pantalla d'inici de sessió"
 
 msgid "display languages with uncompleted translations"
-msgstr "mostra idiomes amb traduccions incompletes"
+msgstr "mostra les llengües amb traduccions incompletes"
 
 msgid "require password to log in"
-msgstr "exigeix paraula clau per iniciar sessió"
+msgstr "exigeix contrasenya per iniciar sessió"
 
 msgid "require password to access admin area"
-msgstr "exigeix paraula clau per accedir a l'àrea d'administració"
+msgstr "exigeix contrasenya per accedir a l'àrea d'administració"
 
 msgid "Update admin's password:"
-msgstr "Modifica la paraula clau de l'administrador:"
+msgstr "Modifica la contrasenya de l'administrador:"
 
 msgid "previous password:"
-msgstr "paraula clau antiga:"
+msgstr "contrasenya antiga:"
 
 msgid "new password:"
-msgstr "paraula clau nova:"
+msgstr "contrasenya nova:"
 
 msgid "confirm new password:"
 msgstr "confirma contrasenya nova:"
@@ -263,13 +263,

Bug#854643: lxpanel: Battery plugin does not notify when battery is low

[Yvan Masson]

Package: lxpanel
Version: 0.9.3-1
Severity: normal

Dear Maintainer,

In my setup the battery plugin does not execute the notification
command when battery remaining time goes below threshold. I have
reproduced this issue both with the default command and with a custom
one (both work from a terminal).

I can not tell if it was working in the previous lxpanel versions.

Do not hesitate to ask if can provide more informations.

Best regards,
Yvan

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

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

Versions of packages lxpanel depends on:
ii  libasound2   1.1.3-4
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libfm-gtk4   1.2.5-1
ii  libfm-modules1.2.5-1
ii  libfm4   1.2.5-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-2
ii  libiw30  30~pre9-12
ii  libkeybinder00.3.1-1
ii  libmenu-cache3   1.0.2-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpangoft2-1.0-01.40.3-3
ii  libwnck222.30.7-5.1
ii  libx11-6 2:1.6.4-3
ii  libxml2  2.9.4+dfsg1-2.2
ii  lxmenu-data  0.1.5-2
ii  lxpanel-data 0.9.3-1

Versions of packages lxpanel recommends:
ii  lxterminal [x-terminal-emulator]  0.3.0-1
ii  pavucontrol   3.0-3+b2
ii  terminator [x-terminal-emulator]  1.90+bzr-1705-1
ii  xkb-data  2.19-1
ii  xterm [x-terminal-emulator]   327-2

Versions of packages lxpanel suggests:
ii  chromium [www-browser] 55.0.2883.75-6
ii  dillo [www-browser]3.0.5-3
ii  elinks [www-browser]   0.12~pre6-12
ii  firefox-esr [www-browser]  45.7.0esr-1
ii  menu   2.1.47
ii  netsurf [www-browser]  3.6-3
ii  netsurf-gtk [www-browser]  3.6-3
ii  w3m [www-browser]  0.5.3-34

-- no debconf information


pgpSXI1dxXqma.pgp
Description: Signature digitale OpenPGP

Bug#854642: ITP: golang-github-grpc-ecosystem-grpc-gateway -- gRPC to JSON proxy generator for Golang

[Potter, Tim]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-grpc-ecosystem-grpc-gateway
  Version : 1.1.0+git20170127.54.6863684-1
  Upstream Author : gRPC Ecosystem
* URL : https://github.com/grpc-ecosystem/grpc-gateway
* License : BSD-3-clause
  Programming Lang: Go
  Description : gRPC to JSON proxy generator for Golang

 Grpc-gateway is a protoc plugin that reads gRPC service definitions
 and generates a reverse-proxy server which translates a RESTful JSON
 API into gRPC. The server is generated according to custom options in
 your gRPC definition and helps you to provide your APIs in both gRPC
 and RESTful style at the same time.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#854613: linux-image-4.8.0-2-amd64: System hangs at "Loading initial ramdisk" after upgrading to 4.9

[Jonathan Yu]

On Wed, Feb 8, 2017 at 1:19 PM, Ben Hutchings  wrote:

> Control: notfound -1 4.8.15-2
> Control: tag -1 moreinfo
>
> On Wed, 2017-02-08 at 09:17 -0800, Jonathan Yu wrote:
> > Package: src:linux
> > Version: 4.8.15-2
> [...]
>

Hey Ben,

Forgot to say: Thank you very much for your great work! I've never had any
trouble upgrading in the past, which is a testament to your hard work :)

>
> But this is the working version, not the broken versin.  Which 4.9.x
> version did you install?  If it is 4.9.2-2 (current in testing), please
> try 4.9.6-3 (current in unstable).
>

I'm using: ii  linux-image-4.9.0-1-amd644.9.2-2
 amd64Linux 4.9 for 64-bit PCs (signed)

I will upgrade to the version in unstable and try again, thanks for the
tip!

Here's my apt policy (I guess it might be helpful if this was included in
reportbug reports) - I use packages mostly from testing :)

$ apt policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 http://dl.google.com/linux/chrome/deb stable/main amd64 Packages
 release v=1.0,o=Google, Inc.,a=stable,n=stable,l=Google,c=main,b=amd64
 origin dl.google.com
 -10 http://ftp.us.debian.org/debian experimental/non-free i386 Packages
 release
o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian experimental/non-free amd64 Packages
 release
o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian experimental/main i386 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian experimental/main amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/non-free i386 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/non-free amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/main i386 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/main amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/contrib i386 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=contrib,b=i386
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/contrib amd64 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=contrib,b=amd64
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/non-free i386 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=non-free,b=i386
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/non-free amd64 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/main i386 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=main,b=i386
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/main amd64 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
Pinned packages:

Bug#854641: mate-power-manager: charge and discharge predictions are vastly inaccurate & there is no help text

[Axel Stammler]

Package: mate-power-manager
Version: 1.8.1+dfsg1-5
Severity: normal

Dear Maintainer,

None of the predicted times are even broadly accurate (so that the computer 
often just
switches off with a few seconds or no warning). The statistics reflect that. 
Pressing the
Help button just creates a message box “Document Not Found;
The URI ‘help:mate-power-manager/index?statistics’ does not point to a valid 
page.” (which
does not help at all) and offers the choice “Search for packages containing this
document.” even though clicking on it just opens another complaining window, 
which this
time around whines “You do not have Package Kit," although this is incorrect:

i   packagekit 2  admin  Provides a package 
management servicestable
i   packagekit-command-not-found   0  misc   Offer to install 
missing programs automatically  stable
p   packagekit-dbg 0  debug  Debugging symbols for 
PackageKit stable
p   packagekit-docs0  docDocumentation for 
PackageKit stable
p   packagekit-gtk3-module 0  libs   Install fonts 
automatically using PackageKit stable
v   packagekit-system-interface0  Unknown   
i A packagekit-tools
   0  libs   Provides PackageKit command-line tools   stable

What can I do to get accurate statistics? Can I change the percentage settings 
for when
the remaining charge is considered low or critically low?

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

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

Versions of packages mate-power-manager depends on:
ii  dbus-x111.8.22-0+deb8u1
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.19-18+deb8u7
ii  libcairo2   1.14.0-2.1+deb8u2
ii  libcanberra-gtk00.30-2.1
ii  libcanberra00.30-2.1
ii  libdbus-1-3 1.10.8-1
ii  libdbus-glib-1-20.102-1
ii  libfontconfig1  2.11.0-6.3+deb8u1
ii  libfreetype62.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u5
ii  libglib2.0-02.48.1-1
ii  libgnome-keyring0   3.12.0-1+b1
ii  libgtk2.0-0 2.24.25-3+deb8u1
ii  libmate-panel-applet-4-11.8.1+dfsg1-3
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.40.1-1
ii  libpangocairo-1.0-0 1.40.1-1
ii  libpangoft2-1.0-0   1.40.1-1
ii  libunique-1.0-0 1.1.6-5
ii  libupower-glib3 0.99.1-3.2
ii  libx11-62:1.6.2-3
ii  libxext62:1.3.3-1
ii  libxrandr2  2:1.5.0-1
ii  libxrender1 1:0.9.8-1+b1
ii  mate-notification-daemon [notification-daemon]  1.8.1-3
ii  mate-power-manager-common   1.8.1+dfsg1-5
ii  notification-daemon 0.7.6-2
ii  policykit-1 0.105-15~deb8u2
ii  systemd 215-17+deb8u6
ii  upower  0.99.1-3.2

Versions of packages mate-power-manager recommends:
ii  udisks  1.0.5-1+b1

Versions of packages mate-power-manager suggests:
ii  mate-polkit  1.8.0+dfsg1-4

-- no debconf information

Bug#854640: firefox-esr: FTBFS on arm{el,hf}: mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation

[Emilio Pozuelo Monfort]

Source: firefox-esr
Version: 45.7.0esr-2
Severity: serious

Hi,

As you expected, firefox-esr failed to build on armel/armhf with GCC 6:

Executing /«PKGBUILDDIR»/build-browser/dist/bin/xpcshell -g 
/«PKGBUILDDIR»/build-browser/dist/bin/ -a 
/«PKGBUILDDIR»/build-browser/dist/bin/ -f 
/«PKGBUILDDIR»/toolkit/mozapps/installer/precompile_cache.js -e 
precompile_startupcache("resource://gre/");
Traceback (most recent call last):
  File "/«PKGBUILDDIR»/toolkit/mozapps/installer/packager.py", line 406, in 

main()
  File "/«PKGBUILDDIR»/toolkit/mozapps/installer/packager.py", line 400, in main
args.source, gre_path, base)
  File "/«PKGBUILDDIR»/toolkit/mozapps/installer/packager.py", line 161, in 
precompile_cache
errors.fatal('Error while running startup cache precompilation')
  File "/«PKGBUILDDIR»/python/mozbuild/mozpack/errors.py", line 103, in fatal
self._handle(self.FATAL, msg)
  File "/«PKGBUILDDIR»/python/mozbuild/mozpack/errors.py", line 98, in _handle
raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error while running startup cache 
precompilation
/«PKGBUILDDIR»/toolkit/mozapps/installer/packager.mk:41: recipe for target 
'stage-package' failed

I wonder if building without some optimization flags would help. I tried
to build with noopt on harris but the build failed earlier:

Executing: g++ -Wdate-time -Wall -Wempty-body -Woverloaded-virtual 
-Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -fstack-protector-strong 
-Wformat -Werror=format-security -D__ARM_PCS 
-fno-schedule-insns2 -fno-lifetime-dse -fno-delete-null-pointer-checks 
-fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections 
-fdata-sections -fno-exceptions -fno-math-errno -std
=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -o buffered_stun_socket_unittest 
/home/pochu/pochu-sid-firefox-esr/firefox-esr-45.7.0esr/build-browser/media/mtransport/test/tmpv98CrM.list
 -lpt
hread -Wl,--as-needed -Wl,--reduce-memory-overheads -Wl,--no-keep-memory 
-Wl,--stats -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id 
-Wl,-rpath-link,/home/pochu/pochu-sid-firefox-esr/firefox-e
sr-45.7.0esr/build-browser/dist/bin -Wl,-rpath-link,/usr/lib 
../../../intl/icu/target/lib/libicui18n.a 
../../../intl/icu/target/lib/libicuuc.a 
../../../intl/icu/target/lib/libicudata.a -pie 
-ldl -L/usr/lib/arm-linux-gnueabi -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lssl3 
-lsmime3 -lnss3 -lnssutil3 -lcrmf -lrt
/home/pochu/pochu-sid-firefox-esr/firefox-esr-45.7.0esr/build-browser/media/mtransport/test/tmpv98CrM.list:
INPUT("buffered_stun_socket_unittest.o")
INPUT("../../webrtc/trunk/testing/gtest_gtest/Unified_cpp_trunk_testing0.o")
[...]
INPUT("../../../netwerk/sctp/src/user_recv_thread.o")
INPUT("../../../netwerk/sctp/src/user_socket.o")

../standalone/test_nr_socket.o: In function `__throw_bad_alloc':
/home/pochu/pochu-sid-firefox-esr/firefox-esr-45.7.0esr/build-browser/media/mtransport/standalone/../../../dist/include/mozilla/throw_gcc.h:37:
 undefined reference to `mozalloc_abort'
/home/pochu/pochu-sid-firefox-esr/firefox-esr-45.7.0esr/build-browser/media/mtransport/standalone/../../../dist/include/mozilla/throw_gcc.h:37:
 undefined reference to `mozalloc_abort'
/home/pochu/pochu-sid-firefox-esr/firefox-esr-45.7.0esr/build-browser/media/mtransport/standalone/../../../dist/include/mozilla/throw_gcc.h:37:
 undefined reference to `mozalloc_abort'
collect2: error: ld returned 1 exit status

Cheers,
Emilio

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

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

Bug#854639: ITP: golang-github-cockroachdb-cmux -- Payload-based connection multiplexer for Golang

[Potter, Tim]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-cockroachdb-cmux
  Version : 0.0~git20170110.0.30d10be-1
  Upstream Author : Soheil Hassas Yeganeh, Tamir Duberstein
* URL : https://github.com/cockroachdb/cmux
* License : Apache-2.0
  Programming Lang: Go
  Description : Payload-based connection multiplexer for Golang

 The cmux library is a generic Go library to multiplex connections
 based on their payload. Using cmux you can serve gRPC, SSH, HTTPS,
 HTTP, Go RPC and pretty much any other payload on the same TCP
 listener. Lookahead is used to match and hand off connections
 to the appropriate server implementation.
 .
 This package is a fork of github.com/soheily/cmux.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#847277: [Piuparts-devel] Bug#847277: lava-server: fails to upgrade from jessie to stretch

[Neil Williams]

On Wed, 8 Feb 2017 21:17:14 +
Holger Levsen  wrote:

> On Wed, Feb 08, 2017 at 09:03:20PM +0100, Andreas Beckmann wrote:
> > > (alternatively, admins can just install python-django
> > > python-django-tables2 from jessie-backports and run `lava-server
> > > managedb migrate` manually.)
> > > There's nothing wrong AFAICT with requiring a step via
> > > jessie-backports.  
> > That's a *very* uncommon requirement (lava-server is the first
> > package doing this).  
> 
> yeah, besides being pretty uncommon it's also pretty wrong I think,
> as it implies the version in jessie-backports cannot be upgraded to
> the version in stretch, as this would make the intermediate step in
> jessie-backports mood… :-)

I need to clarify this.

* lava-server is the same version in jessie-backports as in stretch. [0]

* python-django is *not* the same version [1] because jessie-backports
  has the LTS. Both jessie and stretch have intermediate releases from
  django upstream (1.10, incidentally, will run out of security support
  during the lifetime of stretch just as 1.7 in jessie already has). The
  LTS is not suitable as a security update because of the changes
  needed in reverse dependencies between 1.7 and 1.8 and then from 1.8
  to 1.10 which would make all reverse dependencies uninstallable and
  unusable as soon as any of the services are restarted.

* lava-server is only needed in the list of packages to get from
  jessie-backports because it's the simplest way to ensure that the
  following command works: `lava-server manage migrate` - it is this
  command which uses the support in django1.8 LTS to handle the
  migrations inside django to allow the upgrade to lava-server
  2016.12-1~bpo8+1 and then on to django1.10 and 2016.12-1. It is django
  which makes it impossible to go directly from jessie, 1.7, to
  stretch, 1.10 without a route via 1.8 in jessie-backports.

[0] https://tracker.debian.org/pkg/lava-server
[1] https://tracker.debian.org/pkg/python-django
 
> That said, I can see how this could be more *convinient* (in the case
> where there are 3 very different versions involved, in stable,
> stable-bpo and testing/future stable but IMO this is broken
> unreliable design. What if the version in stable-bpo needs to be
> upgraded due to security issues and the only suitable version is the
> one in testing?)

The version of django in testing (1.10) *cannot* be used as a security
update for jessie - it is, by definition, not a suitable version
because it will break all reverse dependencies already in jessie.

There is a security update for django in stable-sec, it's based on 1.7.
The jessie-backport was updated to 1.8.15-1~bpo8+1 [2] *after*
1:1.10.1-1 migrated to testing. [3] The upload to backports was itself
a new upstream security release.

[2] https://tracker.debian.org/news/813577
[3] https://tracker.debian.org/news/796357
 
> That said, there is nothing wrong with this is this is *optional*.

It sadly isn't optional. It is compulsory for all paths from
lava-server in jessie to lava-server in stretch.

It's an inevitable consequence of having persistent (valuable) data
which is closely modelled by code which is in ongoing development.

The only Debian-like way to deal with this would be to have source
packages for python-django-17 in jessie, python-django-18 in
jessie-backports and in stretch and python-django-110 in stretch with
corresponding binary package name changes. IIRC the django maintainers
in Debian consider that there is insufficient manpower to follow this
approach. lava-server gets tested against both 1.8 and 1.10 anyway as
the majority of users are running lava-server on jessie with backports,
not stretch or unstable but developers are using unstable.

It's one of the reasons why we had to drop Ubuntu support for
lava-server - we don't have the manpower in the LAVA software team to
test on a matrix which combines Debian and Ubuntu versions of django.
(The last version of lava-server for Ubuntu was for Trusty 14.04LTS and
it was precisely these database migration issues which forced us to
seek removal of lava-server from Xenial 16.04LTS)

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpnsr3Y8PTiN.pgp
Description: OpenPGP digital signature

Bug#854638: icedove: SIGSEGV in js::UncheckedUnwrap at ./mozilla/js/src/proxy/Wrapper.cpp:76

[Jean-Francois Pirus]

Package: icedove
Version: 1:45.6.0-2
Severity: important

Random hard to catch crash usually when switching folder.

Linux tyche 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 
GNU/Linux


backtrace included
SignalStop	Print	Pass to program	Description
SIG38 No	Yes	Yes		Real-time event 38
Starting program: /usr/bin/icedove 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe5594700 (LWP 17013)]
[Thread 0x7fffe5594700 (LWP 17013) exited]
[New Thread 0x7fffe5594700 (LWP 17015)]
[New Thread 0x7fffde7ff700 (LWP 17016)]
[New Thread 0x77fed700 (LWP 17017)]
[New Thread 0x7fffddffe700 (LWP 17018)]
[New Thread 0x7fffdd4ff700 (LWP 17019)]
[New Thread 0x7fffdd2fe700 (LWP 17020)]
[New Thread 0x7fffdd0fd700 (LWP 17021)]
[New Thread 0x7fffdcefc700 (LWP 17022)]
[New Thread 0x7fffdccfb700 (LWP 17023)]
[New Thread 0x7fffdcafa700 (LWP 17024)]
[New Thread 0x7fffdc8f9700 (LWP 17025)]
[New Thread 0x7fffdc6f8700 (LWP 17026)]
[New Thread 0x7fffdc4f7700 (LWP 17027)]
[New Thread 0x7fffdc2f6700 (LWP 17028)]
[New Thread 0x7fffdc0f5700 (LWP 17029)]
[New Thread 0x7fffdbef4700 (LWP 17030)]
[New Thread 0x7fffdabff700 (LWP 17031)]
[New Thread 0x7fffd9e03700 (LWP 17032)]
[New Thread 0x7fffd9602700 (LWP 17033)]
[New Thread 0x7fffe4949700 (LWP 17034)]
[New Thread 0x7fffd87ff700 (LWP 17035)]
[New Thread 0x7fffd7469700 (LWP 17036)]
[New Thread 0x7fffd6c68700 (LWP 17037)]
[New Thread 0x7fffd46ff700 (LWP 17038)]
[New Thread 0x7fffd31ff700 (LWP 17039)]
[New Thread 0x7fffd2390700 (LWP 17040)]
[New Thread 0x7fffd0fff700 (LWP 17041)]
[New Thread 0x7fffd07fe700 (LWP 17042)]
[New Thread 0x7fffcfffd700 (LWP 17043)]
[New Thread 0x7fffcf7fc700 (LWP 17044)]
[New Thread 0x7fffceffb700 (LWP 17045)]
[New Thread 0x7fffce7fa700 (LWP 17046)]
[New Thread 0x7fffcdff9700 (LWP 17047)]
[New Thread 0x7fffcd7f8700 (LWP 17048)]
[New Thread 0x7fffccff7700 (LWP 17049)]
[New Thread 0x7fffcc7f6700 (LWP 17050)]
[New Thread 0x7fffcbff5700 (LWP 17051)]
[New Thread 0x7fffcb3ff700 (LWP 17052)]
[New Thread 0x7fffcabfe700 (LWP 17053)]
[New Thread 0x7fffca3fd700 (LWP 17054)]
[New Thread 0x7fffc9bfc700 (LWP 17055)]
[New Thread 0x7fffc8dff700 (LWP 17056)]
[New Thread 0x7fffc76ff700 (LWP 17057)]
[New Thread 0x7fffc6efe700 (LWP 17058)]
[Thread 0x7fffd46ff700 (LWP 17038) exited]
[Thread 0x7fffc9bfc700 (LWP 17055) exited]
[Thread 0x7fffca3fd700 (LWP 17054) exited]
[Thread 0x7fffc6efe700 (LWP 17058) exited]
[New Thread 0x7fffc5aff700 (LWP 17059)]
[New Thread 0x7fffc6efe700 (LWP 17060)]
[New Thread 0x7fffca3fd700 (LWP 17061)]
[New Thread 0x7fffc9bfc700 (LWP 17062)]
[New Thread 0x7fffd46ff700 (LWP 17063)]
[New Thread 0x7fffc43f2700 (LWP 17064)]
[New Thread 0x7fffc3bf1700 (LWP 17065)]
[New Thread 0x7fffc2bff700 (LWP 17066)]
[New Thread 0x7fffc21ff700 (LWP 17067)]
[Thread 0x7fffc6efe700 (LWP 17060) exited]
[Thread 0x7fffca3fd700 (LWP 17061) exited]
[New Thread 0x7fffc10ff700 (LWP 17068)]
[New Thread 0x7fffc08fe700 (LWP 17069)]
[New Thread 0x7fffca3fd700 (LWP 17070)]
[New Thread 0x7fffc6efe700 (LWP 17071)]
[New Thread 0x7fffbaaff700 (LWP 17072)]
[New Thread 0x7fffb9eff700 (LWP 17073)]
[New Thread 0x7fffb8eff700 (LWP 17074)]
[Thread 0x7fffc76ff700 (LWP 17057) exited]
[New Thread 0x7fffc76ff700 (LWP 17075)]
[Thread 0x7fffb9eff700 (LWP 17073) exited]
[New Thread 0x7fffb9eff700 (LWP 17076)]
[New Thread 0x7fffb82fe700 (LWP 17077)]
[Thread 0x7fffb82fe700 (LWP 17077) exited]
[Thread 0x7fffc76ff700 (LWP 17075) exited]
[Thread 0x7fffbaaff700 (LWP 17072) exited]
[New Thread 0x7fffbaaff700 (LWP 17080)]
[Thread 0x7fffc2bff700 (LWP 17066) exited]
[Thread 0x7fffc21ff700 (LWP 17067) exited]
[Thread 0x7fffb9eff700 (LWP 17076) exited]
[New Thread 0x7fffb9eff700 (LWP 17086)]
[New Thread 0x7fffc21ff700 (LWP 17087)]
[Thread 0x7fffc21ff700 (LWP 17087) exited]
[Thread 0x7fffc08fe700 (LWP 17069) exited]
[Thread 0x7fffb9eff700 (LWP 17086) exited]
[New Thread 0x7fffb9eff700 (LWP 17317)]
[New Thread 0x7fffc08fe700 (LWP 17318)]
[New Thread 0x7fffc21ff700 (LWP 17319)]
[New Thread 0x7fffc2bff700 (LWP 17321)]
[Thread 0x7fffc08fe700 (LWP 17318) exited]
[Thread 0x7fffc2bff700 (LWP 17321) exited]
[New Thread 0x7fffc2bff700 (LWP 17456)]
[New Thread 0x7fffc08fe700 (LWP 17457)]
[New Thread 0x7fffa1cff700 (LWP 17458)]
[New Thread 0x7fffa14fe700 (LWP 17459)]
[Thread 0x7fffc2bff700 (LWP 17456) exited]
[Thread 0x7fffc08fe700 (LWP 17457) exited]
[Thread 0x7fffa1cff700 (LWP 17458) exited]
[New Thread 0x7fffa1cff700 (LWP 17460)]
[New Thread 0x7fffc08fe700 (LWP 17461)]
[Thread 0x7fffa14fe700 (LWP 17459) exited]
[Thread 0x7fffc08fe700 (LWP 17461) exited]
[New Thread 0x7fffc08fe700 (LWP 17483)]
[New Thread 0x7fffa14fe700 (LWP 17484)]
[New Thread 0x7fffc2bff700 (LWP 17485)]
[New Thread 0x7fffb1cff700 (LWP 17486)]
[Thread 0x7fffb1cff700 (LWP 17486) exited]
[New Thread 0x7fffb1cff700 (LWP 17487)]
[Thread 0x7fffc08fe700 (LWP 17483) exited]
[Thread 0x7fffc2bff700 (LWP 17485) exited]
[New Thread 0x7fffd9eff700 (LWP 17512)]
[N

Bug#854637: ITP: golang-github-wsxiaoys-terminal -- Colorful terminal output for Golang

[Potter, Tim]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-wsxiaoys-terminal
  Version : 0.0~git20160513.0.0940f3f-1
  Upstream Author : Meng Zhang
* URL : https://github.com/wsxiaoys/terminal
* License : BSD-3-Clause
  Programming Lang: Go
  Description : Colorful terminal output for Golang

 Terminal is a simple golang package that provides basic terminal
 handling. Terminal wraps and color/format functions are implemented
 using standard ANSI escape codes.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#854636: ITP: golang-github-karlseguin-expect -- testing framework for Go with more consice syntax

[Potter, Tim]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-karlseguin-expect
  Version : 1.0.1+git20160716.12.5c2eadb-1
  Upstream Author : Karl Seguin
* URL : https://github.com/karlseguin/expect
* License : Expat
  Programming Lang: Go
  Description : Testing framework for Go with more concise syntax

 Expect is a testing framework for Go to help write shorter
 tests. Go's built-in testing package is fine, except it tends to lead
 to verbose code.  Expect runs within the go test framework but
 provides a different, concise syntax for specifying expectations.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#854635: ITP: golang-github-karlseguin-ccache -- A golang LRU Cache for high concurrency

[Potter, Tim]

X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-karlseguin-ccache
  Version : 2.0.2+git20161222.2.12c7ffd-1
  Upstream Author : Karl Seguin
* URL : https://github.com/karlseguin/ccache
* License : Expat
  Programming Lang: Go
  Description : A golang LRU Cache for high concurrency

 CCache is an LRU Cache, written in Go, focused on supporting high
 concurrency. Lock contention on the list is reduced by introducing a
 window which limits the frequency that an item can get promoted,
 using a buffered channel to queue promotions for a single worker, and
 garbage collecting within the same thread as the worker.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#852659: [le-dico-de-rene-cougnenc] segment fault

[Bernhard Übelacker]

Hello Sandro,

Am 08.02.2017 um 01:24 schrieb Sandro Tosi:
> Hey Bernhard,
> would be interested in preparing a NMU package with your patches
> included (feel free to reply to me in private if you need instructions
> on how to do that)? alternatively i'd be happy to NMU this myself

I tried to prepare a package and put it in [1].
Is it right how the changes are applied and what the changelog contains?
The package would then still need a sponsor.

Kind regards,
Bernhard

[1] https://mentors.debian.net/package/le-dico-de-rene-cougnenc

Bug#854606: ITP: libnfc-nci -- NFC stack for NCI based NFC Controllers by NXP

[Ben Hutchings]

On Wed, 2017-02-08 at 11:28 -0500, Josua Mayer wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Josua Mayer 
> 
> * Package name: libnfc-nci
>   Version : 2.1
>   Upstream Author : NXP Semiconductors
> * URL : https://github.com/NXPNFCLinux/linux_libnfc-nci
> * License : Apache-2.0
>   Programming Lang: C
>   Description : NFC stack for NCI based NFC Controllers by NXP
>
> This library provides an abstracted interface to NFC controllers in order 
> to build applications that make use of nfc technology.
> Description to be revised!
> 
> This library is provided by NFC to facilitate development of nfc enabled 
> applications.
> It currently has support for the pn7120 and pn7150 chips.

This doesn't look suitable for Debian.  Although it can be used with
GNU/Linux, it is clearly designed for Android.  Debian already
provides:

- Linux kernel NFC stack and drivers, providing a socket interface
- libnfc, providing a generic interface to many (mostly USB-attached)
  NFC controllers

I don't see a lot of value in adding a third, vendor-specific stack
that's incompatible with anything else packaged in Debian.

[...]
> However this library can be used with devices and nfc addon boards by other 
> vendors providing they feature a supported nfc chip.
> Such it could benefit a much broader audience than just SR customers.
[...]

Really?  The documentation says it's specific to NXP PN5xx.

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
Inside every large problem is a small problem struggling to get
out.



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

Bug#850447: systemd backport sections only 4K aligned, won't boot with arm64 64K kernel

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Thu, Jan 12, 2017 at 06:36:55PM +0100, Michael Biebl wrote:
> Control: reassign -1 release.debian.org
> Control: retitle -1 nmu: systemd_230-7~bpo8+2
> Control: user -1 release.debian@packages.debian.org
> Control: usertags -1 binnmu
> 
> Am 09.01.2017 um 18:26 schrieb Steven Capper:
> > Hi,
> > FWIW, I found that disabling gold (by tweaking configure.ac
> > ) then led to executables with the correct alignment.
> 
> Thanks Steven and Steve for getting this fixed in stable.
> 
> I'm going to reassign this bug to release.debian.org so it can be binNMU
> once binutils 2.25-5+deb8u1.1 reaches the archive.
> 
> 
> nmu systemd_230-7~bpo8+2 . arm64 . jessie-backports . -m "Rebuild with
> fixed binutils"

Backports is outside the release team's jurisdiction; whilst wanna-build
will probably let me monkey with it, it doesn't feel right. If there's a
precedent I'm not aware of, I'm happy to be corrected.

I suggest contacting debian-backpo...@lists.debian.org in the first
instance.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

[NIIBE Yutaka]

Antoine Beaupré  writes:
> This reminds me - it sure looks like pcscd was crashing back
> there. Should I revert back to using pcscd to try and reproduce the
> problem and file a pcscd bug about this?

Yes.  I think that this is a different problem, and it's pcscd issue.
-- 

Bug#854593: diffoscope: autopkgtest fail

[Chris Lamb]

Mattia Rizzolo wrote:

> https://ci.debian.net/data/packages/unstable/amd64/d/diffoscope/20170208_091322.autopkgtest.log.gz

So, we're failing 4 tests here when Recommends are not installed:

> FAIL tests/test_progress.py::test_progress

Fixed in:
  
  
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=83e939e0d6b00d7a404c6dcb6b7496542f845b3a

> FAIL tests/comparators/test_device.py::test_diff
> FAIL tests/comparators/test_device.py::test_diff_reverse

I can't reproduce this one locally. Is this because we don't have "real"
access to /dev/null on ci.debian.net? (!)

> FAIL tests/comparators/test_rpm.py::test_fallback_comparison

Can't reproduce this one either and not sure what is even going on.


Regards,

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

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

[Antoine Beaupré]

On 2017-02-09 06:15:21, NIIBE Yutaka wrote:
> Antoine Beaupré  writes:
>>> If this works, the udev line should be included into scdaemon package in
>>> future, so that each user doesn't need to configure.
>>
>> I confirm the udev hack works.
>
> No, this is not a hack.  This is a configuration needed.

This reminds me - it sure looks like pcscd was crashing back
there. Should I revert back to using pcscd to try and reproduce the
problem and file a pcscd bug about this?

A.

-- 
La guerre, c'est le massacre d'hommes qui ne se connaissent pas,
au profit d'hommes qui se connaissent mais ne se massacreront pas.
- Paul Valéry

Bug#854634: yubiserver: database permission

[bdo]

Package: yubiserver
Version: 0.6-3
Severity: important

Hi,

Database contains sensitive informations about token ids, however, it's world 
readable:

drwxr-xr-x  2 yubiserver yubiserver 4096 févr.  8 22:20 .
drwxr-xr-x 88 root   root   4096 févr.  8 22:20 ..
-rw-r--r--  1 yubiserver yubiserver 9216 févr.  8 22:20 yubiserver.sqlite


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

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

Versions of packages yubiserver depends on:
ii  adduser   3.115
ii  libc6 2.24-9
ii  libev41:4.22-1
ii  libgcrypt20   1.7.6-1
ii  libmhash2 0.9.9.9-7
ii  libsqlite3-0  3.16.2-2

yubiserver recommends no packages.

yubiserver suggests no packages.

-- no debconf information

Bug#822974: [pkg-gnupg-maint] Backport of GnuPG 2.1

[Luca Capello]

Hi there !

Adding Daniel Pocock and Robert Lange to Cc:, sorry if I forgot to do it
with my first reply to this bug.

On Sat, 28 Jan 2017 23:18:10 +0100, Luca Capello wrote:
> > >   libassuan-dev
> 
> --8<---cut here---start->8---
> libassuan (2.4.3-2~bpo8+1) jessie-backports; urgency=medium

In the archive since 2017-02-06:

  

> > >   libgcrypt20-dev
> 
> "[2017-01-26] Accepted 1.7.6-1 in unstable (medium) (Andreas Metzler)"
> 
> Cc:ing the Debian GnuTLS Maintainers list and Bcc:ing Andreas Metzler
> who did the upload: is that version target for stretch, so the one I
> should backport for GnuPG 2?

--8<---cut here---start->8---
libgcrypt20 (1.7.6-1~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.
- remove mingw-w64 and libgpg-error-mingw-w64-dev from
  Build-Depends-Indep: and libgcrypt-mingw-w64-dev binary package,
  no libgpg-error-mingw-w64-dev.
  * debian/rules:
- remove mingw-related instructions from override_dh_auto_build-indep
  and override_dh_auto_install-indep.

 -- Luca Capello   Wed, 08 Feb 2017 10:04:20 +0100
--8<---cut here---end--->8---

Working fine on 2 jessie-backports with gnupg2_2.1.11-7, it will be
uploaded at the end of the week.

> > >   libgpg-error-dev
> 
> "[2017-01-18] Accepted 1.26-2 in unstable (medium) (Daniel Kahn Gillmor)"
> 
> I guess this is the version intended for stretch, right?

--8<---cut here---start->8---
libgpg-error (1.26-2~bpo8+1) jessie-backports; urgency=medium

  * Rebuild for jessie-backports.
  * debian/control:
+ add myself to Uploaders:.
  * debian/gbp.conf:
+ add debian-branch=jessie-backports.

 -- Luca Capello   Wed, 08 Feb 2017 17:40:35 +0100
--8<---cut here---end--->8---

Working fine on 2 jessie-backports with gnupg2_2.1.11-7, it will be
uploaded at the end of the week.

Please note that I have also built the mingw-related binaries for
libgpg-error, which means that the other backports I did can be
"upgraded" to build the corresponding mingw-related binaries
(libgpg-error-mingw-w64-dev was a Build-Depends-Indep:), if needed.

> > >   libksba-dev
>
> --8<---cut here---start->8---
> libksba (1.3.5-2~bpo8+1) jessie-backports; urgency=medium

In the archive since 2017-02-06:

  

> > >   libnpth0-dev
> 
> --8<---cut here---start->8---
> npth (1.3-1~bpo8+1) jessie-backports; urgency=medium

In the archive singe 2017-02-06:

  

> Daniel, what do you think about adding the jessie-backports branches I
> have locally to the corresponding Git repositories on Alioth?

Still valid, as well as for the other packages (Bcc:ing Eric Dorland).

I will work on the GnuPG 2.1 backports ASAP and report back.

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature

Bug#847277: [Piuparts-devel] Bug#847277: lava-server: fails to upgrade from jessie to stretch

[Holger Levsen]

On Wed, Feb 08, 2017 at 09:17:14PM +, Holger Levsen wrote:
> On Wed, Feb 08, 2017 at 09:03:20PM +0100, Andreas Beckmann wrote:
> > > (alternatively, admins can just install python-django
> > > python-django-tables2 from jessie-backports and run `lava-server
> > > managedb migrate` manually.)
> > > There's nothing wrong AFAICT with requiring a step via jessie-backports.
> > That's a *very* uncommon requirement (lava-server is the first package
> > doing this).
> 
> yeah, besides being pretty uncommon it's also pretty wrong I think, as it
> implies the version in jessie-backports cannot be upgraded to the version
> in stretch, as this would make the intermediate step in jessie-backports
> mood… :-)
> 
> That said, I can see how this could be more *convinient* (in the case where
> there are 3 very different versions involved, in stable, stable-bpo and
> testing/future stable but IMO this is broken unreliable design. What if the
> version in stable-bpo needs to be upgraded due to security issues and the only
> suitable version is the one in testing?)
> 
> That said, there is nothing wrong with this is this is *optional*.

 _if_ this is optional…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

[Antoine Beaupré]

On 2017-02-09 06:15:21, NIIBE Yutaka wrote:
> Thanks a lot for your confirmation.
>
> Antoine Beaupré  writes:
>>> If this works, the udev line should be included into scdaemon package in
>>> future, so that each user doesn't need to configure.
>>
>> I confirm the udev hack works.
>
> No, this is not a hack.  This is a configuration needed.

Sorry for my imprecise vocabulary. This is all very obscure to me, so
everything looks like a hack. :)

> It seems for me that Yubico has been recommended use of PC/SC service.

I don't know about this, but that's how I made it work the first time. I
took this document as a source for how to make it work:

https://blog.night-shade.org.uk/2015/04/ssh-support-in-gpg-agent-on-ubunt/

... which suggests installing pcscd.

> Since no one has reported for use of internal CCID driver, there is no
> entry for Yubikey in /lib/udev/rules.d/60-scdaemon.rules on Debian.
>
> Now, since it is confirmed, we should add an entry.

Thanks for the clarification!

A.

-- 
La propriété est un piège: ce que nous croyons posséder nous possède.
- Alphonse Karr

Bug#854633: yubiserver: /etc/yubiserver/yubiserver.cfg is not used

[bdo]

Package: yubiserver
Version: 0.6-3
Severity: important

yubiserver.cfg settings are not used, in start script or in binary daemon

Setting junk parameters doesn't change anything.

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

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

Versions of packages yubiserver depends on:
ii  adduser   3.115
ii  libc6 2.24-9
ii  libev41:4.22-1
ii  libgcrypt20   1.7.6-1
ii  libmhash2 0.9.9.9-7
ii  libsqlite3-0  3.16.2-2

yubiserver recommends no packages.

yubiserver suggests no packages.

-- no debconf information

Bug#847277: lava-server: fails to upgrade from jessie to stretch

[Neil Williams]

On Wed, 8 Feb 2017 21:03:20 +0100
Andreas Beckmann  wrote:

> On 2017-02-08 20:16, Neil Williams wrote:
> > retitle 847277 django migrations in jessie require django from  
> jessie-backports to upgrade to stretch
> [...]
> 
> > On Wed, 08 Feb 2017 14:48:21 +0100
> > Andreas Beckmann  wrote:  
> 
> > The flow needs to go via jessie-backports, just like any django
> > project in jessie as the database migrations from jessie cannot be
> > handled by django1.10 without going via the LTS release, django1.8.
> > The bug, if any, is in django1.7 which does not (cannot) know how
> > to handle database migrations the way that django1.8 (and
> > subsequent releases) need to handle migrations. However, that
> > change can't be backported to jessie except by using the new flow
> > from 1.8 which breaks all other packages using django in jessie.
> > 
> > On a real instance, the postgres cluster would also need to be
> > migrated.  
> 
> I've started doing this in piuparts recently ...

Interesting. When tested in piuparts, lava-server checks to see if the
database contains only the migrations and no actual objects. It would
be good for piuparts to support purge leaving a database behind as this
is the expected behaviour when the installation created the empty
database but the user created (valuable) data afterwards. There is
nothing the package can do in an automated manner when a database
migration goes wrong anyway, even repeating the attempt could cause
permanent data loss.

> > If piuparts cannot handle such upgrades, that must be a bug in
> > piuparts.  
> 
> Having uncommon upgrade requirements (beyond
> sed -i s/jessie/stretch/ sources.list
> apt-get update
> apt-get dist-upgrade
> ) will need extra coding ...

.. or a control file in debian/ or debian/migrate/ maybe.

backports: jessie
Depends: python-django, python-django-tables2, $@

?

At least if it is restricted to official backports, it isn't another
open-ended maintainer script doing random things.

The extra steps in our test job are to ensure that the final state is a
fully working package - the a2enmod and other apache steps are not
required to allow the package to setup correctly. All that's actually
needed in a piuparts type test is to have the specified packages
installed on top of jessie before adding the stretch apt source. To me,
that would seem to be a useful option. (Syntax borrowed from autopkgtest.)

> > We test this regularly, albeit to the newer version in our staging
> > repo rather than the version in stretch.   
> 
> OK.
> 
> > https://staging.validation.linaro.org/scheduler/job/162057/definition#defline59
> > 
> > # on jessie, with backports enabled:
> > DEBIAN_FRONTEND=noninteractive apt-get -y install lava-dispatcher
> > lava-server 
> > apt -q -y -t jessie-backports install python-django-kvstore
> > python-django python-django-tables2 lava-server # now proceed with
> > the upgrade. DEBIAN_FRONTEND=noninteractive apt -y upgrade
> > DEBIAN_FRONTEND=noninteractive apt -y dist-upgrade  
> 
> Given that you are continuously testing your special upgrade path,
> I'll not reimplement that in piuparts for now (although it should be
> quite easy).
> 
> > (alternatively, admins can just install python-django
> > python-django-tables2 from jessie-backports and run `lava-server
> > managedb migrate` manually.)
> > 
> > There's nothing wrong AFAICT with requiring a step via
> > jessie-backports.  
> 
> That's a *very* uncommon requirement (lava-server is the first package
> doing this).

I suspect it would be much more common if services which use Debian
actually had a route to simple packaging within Debian which had this
support. It could provide an alternative to the endless docker hacks by
some upstreams.
 
> > There is also nothing LAVA can do about this, it's a django issue
> > which cannot be fixed in jessie as there are other packages in
> > jessie which are not compatible with django1.8 LTS (including the
> > version of LAVA in jessie).  
> 
> lava-server could error-out in preinst if an unsupported upgrade path
> is attempted, giving instructions to go via backports (link to
> lava-announce/2016-June/10.html)

As it happens, I'm looking at something similar for the stretch ->
buster packaging changes. (lava-server has a more complex route then
between jessie and stretch, involving deliberate data loss due to the
removal of deprecated database objects.)

I'll see if I can get some testing done for this. The awkward part
about exiting in a preinst with a message about backports is that it
leaves the package in a broken state which apt will continually try to
fix whenever any other package is installed or upgraded. This makes it
very problematic when a lot of these upgrades will happen remotely using
configuration management tools like salt and puppet. Even debconf
critical notes don't necessarily help when the admin is not on the same
console or tools like salt hide the output or bury it in a lot of
noise. Add in the 

Bug#853981: apache2-bin: mod_http2 together with mod_ruid2 breaks the server

[Julian Gilbey]

On Sun, Feb 05, 2017 at 01:59:56PM +0100, Stefan Fritsch wrote:
> On Thursday, 2 February 2017 18:56:38 CET Julian Gilbey wrote:
> > [Thu Feb 02 18:14:44.630796 2017] [core:notice] [pid 3650] AH00052: child
> > pid 3696 exit signal Aborted (6)
> 
> Please follow the instructions in /usr/share/doc/apache2/README.backtrace and 
> add a backtrace to this report. Thanks.

Oops, I forgot to stop the script command.  Here's a better gdb.out.

   Julian
Script started on Wed 08 Feb 2017 21:21:47 GMT
root@redfield:/etc/apache2# strace -p f -p /10047
strace: Process 10047 attached with 27 threads
[pid 10100] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10101] epoll_wait(9,  
[pid 10099] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 24, NULL 
[pid 10098] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 23, NULL 
[pid 10099] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10098] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10099] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10098] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10097] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 22, NULL 
[pid 10096] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 21, NULL 
[pid 10097] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10096] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10097] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10096] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10095] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 20, NULL 
[pid 10094] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 19, NULL 
[pid 10095] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10094] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10095] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10094] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10093] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 18, NULL 
[pid 10092] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 17, NULL 
[pid 10093] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10092] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10093] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10092] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10091] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 16, NULL 
[pid 10089] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 15, NULL 
[pid 10091] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10089] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10091] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10089] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10087] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 14, NULL 
[pid 10085] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 13, NULL 
[pid 10087] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10085] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10087] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10085] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10083] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 12, NULL 
[pid 10081] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 11, NULL 
[pid 10083] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10081] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10083] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10081] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10079] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 10, NULL 
[pid 10077] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 9, NULL 
[pid 10079] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10077] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10079] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10077] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10075] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 8, NULL 
[pid 10073] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 7, NULL 
[pid 10075] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10073] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10075] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10073] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10071] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 6, NULL 
[pid 10069] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 5, NULL 
[pid 10071] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10069] <... futex resumed> )   = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 10071] futex(0x7f913cd4867c, FUTEX_WAIT_PRIVATE, 25, NULL 
[pid 10069] futex(0x7f913cd4867c, FUTEX_WAIT_PRIV

Bug#853981: apache2-bin: mod_http2 together with mod_ruid2 breaks the server

[Julian Gilbey]

On Sun, Feb 05, 2017 at 01:59:56PM +0100, Stefan Fritsch wrote:
> On Thursday, 2 February 2017 18:56:38 CET Julian Gilbey wrote:
> > [Thu Feb 02 18:14:44.630796 2017] [core:notice] [pid 3650] AH00052: child
> > pid 3696 exit signal Aborted (6)
> 
> Please follow the instructions in /usr/share/doc/apache2/README.backtrace and 
> add a backtrace to this report. Thanks.

Hi Stefan,

I've done as best as I can for this.  Interestingly, when I started 
again with an absolutely clean installation of apache2, with the only
changes from the default installation being:

* adding the CoreDumpDirectory directive to apache2.conf
* enabling the ruid2 module (but not the http2 module)

I still obtained the same failing behaviour (but not a crash)

This is the /var/log/apache2/error.log message:

[Wed Feb 08 21:15:03.829771 2017] [core:notice] [pid 6416:tid 140261767853248] 
AH00052: child pid 9982 exit signal Aborted (6)

Running gdb on process 6416 gave essentially nothing; see the attached
gdb2.out.  (I pressed c after the page had failed to load, then did
ctrl-c to exit.  Nothing displayed in the gdb trace.)

More interesting was the effect of attaching to the child process: see
the gdb.out attached.

I also did an strace on the child process; that is in strace.out.

What is very interesting is that I have had mod_ruid2 on another
machine (also running testing) and it hasn't had any problems.

It certainly looks as though the bug is in that module.

Best wishes,

   Julian
Script started on Wed 08 Feb 2017 21:14:29 GMT
root@redfield:~# gddb -p 6416
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 6416
Reading symbols from target:/usr/sbin/apache2...Reading symbols from 
/usr/lib/debug/.build-id/42/8cd0f45f69360d47886da802ed345070c9bc00.debug...done.
done.
Reading symbols from target:/lib/x86_64-linux-gnu/libpcre.so.3...(no debugging 
symbols found)...done.
Reading symbols from 
target:/usr/lib/x86_64-linux-gnu/libaprutil-1.so.0...Reading symbols from 
/usr/lib/debug/.build-id/27/4bb6314ac13ddc5124af98cc9d95eff07fe9d1.debug...done.
done.
Reading symbols from target:/usr/lib/x86_64-linux-gnu/libapr-1.so.0...Reading 
symbols from 
/usr/lib/debug/.build-id/e4/34c8be0266b67f2a76aeba76ff6231a64d3732.debug...done.
done.
Reading symbols from target:/lib/x86_64-linux-gnu/libpthread.so.0...Reading 
symbols from 
/usr/lib/debug/.build-id/75/b2a574fa9c03e43b58f53b424b1daec1211862.debug...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Reading symbols from target:/lib/x86_64-linux-gnu/libc.so.6...Reading symbols 
from 
/usr/lib/debug/.build-id/4b/9cc30ba41f027a0dca6cd877f59f0db38f4025.debug...done.
done.
Reading symbols from target:/lib/x86_64-linux-gnu/libuuid.so.1...(no debugging 
symbols found)...done.
Reading symbols from target:/lib/x86_64-linux-gnu/librt.so.1...Reading symbols 
from 
/usr/lib/debug/.build-id/93/5f7cac8894edac152c05cf83b2decf1097920e.debug...done.
done.
Reading symbols from target:/lib/x86_64-linux-gnu/libcrypt.so.1...Reading 
symbols from 
/usr/lib/debug/.build-id/50/88d4df6ba5d1a3184f19d7dbac7ed53de3871b.debug...done.
done.
Reading symbols from target:/lib/x86_64-linux-gnu/libdl.so.2...Reading symbols 
from 
/usr/lib/debug/.build-id/e4/8bb27b88670405041a12eefef9ef586f6e1533.debug...done.
done.
Reading symbols from target:/lib/x86_64-linux-gnu/libexpat.so.1...(no debugging 
symbols found)...done.
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug/.build-id/09/5935d2da92389e2991f2b56d14dab9e6978696.debug...done.
done.
Reading symbols from target:/lib/x86_64-linux-gnu/libnss_compat.so.2...Reading 
symbols from 
/usr/lib/debug/.build-id/ce/a6be6f04a6d00a4a6e5fdc8bfb22e1c8106005.debug...done.
done.
Reading symbols from target:/lib/x86_64-linux-gnu/libnsl.so.1...Reading symbols 
from 
/usr/lib/debug/.build-id/6b/809180d68bae984119c3a606fad0c59baeae67.debug...done.
done.
Reading symbols from target:/lib/x86_64-linux-gnu/libnss_nis.so.2...Reading 
symbols from 
/usr/lib/debug/.build-id/05/99d07417db4e3a16202c6c1003016e33d347ef.debug...done.
done.
Reading symbols from target:/lib/x86_64-linux-gnu/libnss_files.so.2...Reading 
symbols from 
/usr/lib/debug/.build-id/94/a18f9eed80f719d9c1a3929e8a1e

Bug#854613: linux-image-4.8.0-2-amd64: System hangs at "Loading initial ramdisk" after upgrading to 4.9

[Ben Hutchings]

Control: notfound -1 4.8.15-2
Control: tag -1 moreinfo

On Wed, 2017-02-08 at 09:17 -0800, Jonathan Yu wrote:
> Package: src:linux
> Version: 4.8.15-2
[...]

But this is the working version, not the broken versin.  Which 4.9.x
version did you install?  If it is 4.9.2-2 (current in testing), please
try 4.9.6-3 (current in unstable).

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
Inside every large problem is a small problem struggling to get
out.



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

Bug#850917: [Piuparts-devel] Bug#854317: piuparts: adequate reports obsolete conffile for piuparts

[Holger Levsen]

On Wed, Feb 08, 2017 at 07:49:34PM +0100, Andreas Beckmann wrote:
> On 2017-02-08 18:55, Holger Levsen wrote:
> >> PS: @Holger: you should apply the log-alternatives-changes patch, too
> > I still don't know what patch you mean. Could you please explain (the 
> > probably
> > obvious…)
> #850917

ah. 

Michael, could you please amend 3f93dade64 with a debian/changelog entry?
Something like the git commit message, but a bit shorter ;) Thanks already!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#847277: [Piuparts-devel] Bug#847277: lava-server: fails to upgrade from jessie to stretch

[Holger Levsen]

On Wed, Feb 08, 2017 at 09:03:20PM +0100, Andreas Beckmann wrote:
> > (alternatively, admins can just install python-django
> > python-django-tables2 from jessie-backports and run `lava-server
> > managedb migrate` manually.)
> > There's nothing wrong AFAICT with requiring a step via jessie-backports.
> That's a *very* uncommon requirement (lava-server is the first package
> doing this).

yeah, besides being pretty uncommon it's also pretty wrong I think, as it
implies the version in jessie-backports cannot be upgraded to the version
in stretch, as this would make the intermediate step in jessie-backports
mood… :-)

That said, I can see how this could be more *convinient* (in the case where
there are 3 very different versions involved, in stable, stable-bpo and
testing/future stable but IMO this is broken unreliable design. What if the
version in stable-bpo needs to be upgraded due to security issues and the only
suitable version is the one in testing?)

That said, there is nothing wrong with this is this is *optional*.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

[NIIBE Yutaka]

Thanks a lot for your confirmation.

Antoine Beaupré  writes:
>> If this works, the udev line should be included into scdaemon package in
>> future, so that each user doesn't need to configure.
>
> I confirm the udev hack works.

No, this is not a hack.  This is a configuration needed.

It seems for me that Yubico has been recommended use of PC/SC service.
Since no one has reported for use of internal CCID driver, there is no
entry for Yubikey in /lib/udev/rules.d/60-scdaemon.rules on Debian.

Now, since it is confirmed, we should add an entry.
--