Bug#902413: Systemd unit is also pointing to /var/run instead of /run

[Gabriel Filion]

Hello,

Additionally to what wavexx reported, the systemd unit file is also
pointing PIDFile= inside the deprecated /var/run instead of /run. The
init script is also pointing to that directory.

I'm reporting this here since it's related to why that tmpfiles line
exists. However, this would imply a change upstream

I suggest that the following changes for the upstream file. arguably
though many lines of python code also reference /var/run and should be
changed, too.

-8<8<-
--- a/files/fail2ban.service.in 2019-03-17 01:12:08.0 -0400
+++ b/files/fail2ban.service.in 2019-03-17 01:08:05.339634130 -0400
@@ -6,13 +6,13 @@

 [Service]
 Type=simple
-ExecStartPre=/bin/mkdir -p /var/run/fail2ban
 ExecStart=@BINDIR@/fail2ban-server -xf start
 # if should be logged in systemd journal, use following line or set
logtarget to sysout in fail2ban.local
 # ExecStart=@BINDIR@/fail2ban-server -xf --logtarget=sysout start
 ExecStop=@BINDIR@/fail2ban-client stop
 ExecReload=@BINDIR@/fail2ban-client reload
-PIDFile=/var/run/fail2ban/fail2ban.pid
+RuntimeDirectory=fail2ban
+PIDFile=/run/fail2ban/fail2ban.pid
 Restart=on-failure
 RestartPreventExitStatus=0 255

--- a/files/debian-initd2019-03-17 01:12:08.0 -0400
+++ b/files/debian-initd2019-03-17 01:14:18.993738399 -0400
@@ -34,7 +34,7 @@
 # Ad-hoc way to parse out socket file name
 SOCKFILE=`grep -h '^[^#]*socket *=' /etc/$NAME/$NAME.conf
/etc/$NAME/$NAME.local 2>/dev/null \
   | tail -n 1 | sed -e 's/.*socket *= *//g' -e 's/ *$//g'`
-[ -z "$SOCKFILE" ] && SOCKFILE='/var/run/fail2ban.sock'
+[ -z "$SOCKFILE" ] && SOCKFILE='/run/fail2ban.sock'

 # Exit if the package is not installed
 [ -x "$DAEMON" ] || exit 0
@@ -109,13 +109,13 @@
DAEMON_ARGS="$DAEMON_ARGS -x"
fi

-   # Assure that /var/run/fail2ban exists
-   [ -d /var/run/fail2ban ] || mkdir -p /var/run/fail2ban
+   # Assure that /run/fail2ban exists
+   [ -d /run/fail2ban ] || mkdir -p /run/fail2ban

if [ "$FAIL2BAN_USER" != "root" ]; then
# Make the socket directory, IP lists and fail2ban log
# files writable by fail2ban
-   chown "$FAIL2BAN_USER" /var/run/fail2ban
+   chown "$FAIL2BAN_USER" /run/fail2ban
# Create the logfile if it doesn't exist
touch /var/log/fail2ban.log
chown "$FAIL2BAN_USER" /var/log/fail2ban.log



signature.asc
Description: OpenPGP digital signature

Bug#650985: --Библии да! Конституции нет! / Bible Yes, Constitution No.00-32-18

[Pr.Tupirani]

ПОКОЛЕНИЕ ИИСУСА ХРИСТА

ПОКОЛЕНИЕ МУЧЕНИЦА
учить умирать
за Иисуса Христа

ЭТО МИНИСТЕРСТВО ГОЛОСА ВОССТАНОВЛЕНИЯ, ТОЛЬКО ДВЕРЬ ДЛЯ РАПТУРЫ ЦЕРКВИ:
http://bit.ly/thelastelijah-ru
PR. ТУПИРАНИ, ПОСЛЕДНИЙ ЭЛИЯ.
БИБЛИЯ ДА! КОНСТИТУЦИЯ НЕ!
2070: ИИСУС ВОЗВРАЩАЕТСЯ.
МЫ НЕ МАСОНОВ!
“Вот, Я пошлю к вам Илию пророка пред наступлением дня Господня, великого и 
страшного." (Малахия 4:5)
“Иисус сказал им в ответ: правда, Илия должен придти прежде и устроить всё;" 
(Матфея 17:11)
GENERATION JESUS CHRIST

GENERATION OF MARTYRS
TEACHING TO DIE
FOR JESUS CHRIST.



This is the ministry of the voice of restoration, the unique door for the 
rapture of the church:
http://restauracao.net/home.html


Pr. Tupirani, the last Elijah.
Bible Yes! Constitution No!
2070: Jesus will return.
We aren't freemasons!

 

 
“Behold, I will send you Elijah the prophet before the coming of the great and 
dreadful day of the Lord." (Malachi 4:5)

“Elijah truly shall first come and restore all things." (Matthew 17:11)
 
 
 
51859765
 
00-32-18

Bug#818366: synaptic: fails to start under Wayland

[Axel Beckert]

Hi Paul,

Paul Gevers wrote:
> I am going to raise my question again, if synaptic can't be run on the
> default desktop in the default login mode, isn't the average user better
> of if we don't ship synaptic with buster?

Huh? What kind of logic is that? So any X program which doesn't run
under Wayland but does work under X should not be shipped at all? WTF?

Of course with these issues, it doesn't make sense to install Synaptic
by default. But it's still useful for anyone who doesn't use Wayland,
which is AFAIK anyone who has no properly accelerated GPU.

And besides: Isn't GNOME/Wayland only on x86 architectures the
default, but on any other architecture XFCE (with X I assume) is the
default desktop because GNOME doesn't properly work on them? Following
the same logic, shouldn't we stop shipping GNOME? 

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#924762: further information

[ziegler]

The problem occurs also with the current kernel 
linux-image-4.19.0-4-amd64.

Bug#924704: bumblebee-nvidia: nvidia-driver 410 doesn't appear to allow the unloading of the nvidia module

[Danfun360]

Well, the good news is, the GLX alternative bug with legacy-390xx appears
to have been fixed.

The bad news is that the main bug of bumblebeed failing to load at startup
for whatever reason is still there. Have any suggestions for
troubleshooting? (Also, since this bug affects both the latest
nvidia-driver (410) as well as nvidia-driver-legacy-390xx, I'd prefer
trying to work with 410)

On Sat, Mar 16, 2019 at 5:48 PM Luca Boccassi  wrote:

> That's not the case anymore in buster, 390xx works fine with other packages
>
> On Sat, 16 Mar 2019, 21:03 Danfun360 
>> I already tried legacy-390xx. As I said before, there doesn't seem to be
>> equivalents of nvidia-cuda-toolkit and nvidia-cuda-dev that don't try to
>> force the latest nvidia drivers. Also, bumblebee doesn't recognize the
>> legacy-390xx drivers as a GLX alternative (I get an error stating such).
>>
>> If I was to remove bbswitch, would I be unable to use PRIMUS? Also how
>> would I go about with my VGA Passthrough setup?
>>
>> On Sat, Mar 16, 2019 at 4:12 PM Luca Boccassi  wrote:
>>
>>> Control: severity -1 minor
>>>
>>> Try switching to legacy-390xx, or removing bbswitch and using the
>>> kernel's power management, with these laptops it's always a dice roll
>>> on what will actually work
>>>
>>> On Sat, 2019-03-16 at 14:19 -0400, Danfun360 wrote:
>>> > The graphics card in my laptop is an Nvidia Geforce GTX 1050.
>>> >
>>> > On Sat, Mar 16, 2019 at 7:20 AM Luca Boccassi >> > m>
>>> > wrote:
>>> >
>>> > > What Nvidia card does your laptop have?
>>> > >
>>> > > On Sat, 16 Mar 2019, 03:42 Daniel O. >> > >
>>> > > > Package: bumblebee-nvidia
>>> > > > Version: 3.2.1-20
>>> > > > Severity: grave
>>> > > > Justification: renders package unusable
>>> > > >
>>> > > > Dear Maintainer, I write this bug report because this
>>> > > > bumblebee/bumblebeed
>>> > > > doesn't work as it should.
>>> > > >
>>> > > >* What led up to the situation? Bumblebee used to work
>>> > > > correctly when
>>> > > > the
>>> > > > nvidia driver was at 390. A few days ago it was upgraded to 410.
>>> > > > At the
>>> > > > time I
>>> > > > was running Debian Buster (testing as of this writing). That's
>>> > > > where
>>> > > > things
>>> > > > started to get problematic. It appears that the nvidia module
>>> > > > couldn't be
>>> > > > unloaded or something. bbswitch reported as "ON" without optirun,
>>> > > > and as
>>> > > > the
>>> > > > nvidia drivers were considered in use, I was unable to unbind the
>>> > > > nvidia
>>> > > > driver
>>> > > > for VGA Passthrough as I had been doing before.
>>> > > >* What exactly did you do (or not do) that was effective (or
>>> > > >  ineffective)? I uninstalled every bumblebee and nvidia
>>> > > > package. I
>>> > > > then
>>> > > > reinstalled everything. No luck. I then uninstalled everything
>>> > > > and went
>>> > > > for the
>>> > > > legacy 390 package. Unfortunately there were problems with that:
>>> > > > nvidia-cuba-
>>> > > > toolkit and nvidia-cuba-dev require the latest nvidia driver
>>> > > > installed.
>>> > > > On top
>>> > > > of that, bumblebee refused to see the legacy 390 drivers as a glx
>>> > > > alternative.
>>> > > > I uninstalled all the nvidia stuff again, switched to Debian Sid,
>>> > > > and
>>> > > > installed
>>> > > > the latest nvidia drivers again (they were slightly more up to
>>> > > > date on
>>> > > > Sid than
>>> > > > in Buster). Still no change.
>>> > > >* What was the outcome of this action? Bumblebee should be
>>> > > > able to
>>> > > > blacklist
>>> > > > the nvidia driver and isolate it from the operating system in
>>> > > > such a way
>>> > > > that
>>> > > > the system would run on the integrated GPU and run the discrete
>>> > > > GPU for
>>> > > > applications when called for.
>>> > > >* What outcome did you expect instead? The nvidia driver is
>>> > > > not
>>> > > > blacklisted,
>>> > > > and the discrete GPU is in control.
>>> > > >
>>> > > > On a different note, I tried posting a bug report upstream. It
>>> > > > has some
>>> > > > information this report might not have (vice versa is definitely
>>> > > > the case,
>>> > > > unfortunately). It can be found at https://github.com/Bumblebee-
>>> > > > Project/Bumblebee/issues/1023
>>> > > >
>>> > > >
>>> > > >
>>> > > > -- System Information:
>>> > > > Debian Release: buster/sid
>>> > > >   APT prefers unstable
>>> > > >   APT policy: (500, 'unstable')
>>> > > > Architecture: amd64 (x86_64)
>>> > > > Foreign Architectures: i386
>>> > > >
>>> > > > Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
>>> > > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>>> > > > TAINT_UNSIGNED_MODULE
>>> > > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>>> > > > LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
>>> > > > Shell: /bin/sh linked to /usr/bin/dash
>>> > > > Init: systemd (via /run/systemd/system)
>>> > > > LSM: AppArmor: enabled
>>> > > >
>>> > > > Versions of packages bumblebee-nvidia depends on:
>>> 

Bug#924762: emacs: commandline with extended characters kills the X server

[ziegler]

Package: emacs
Version: 1:26.1+1-3.2
Severity: grave
Tags: upstream

Dear Maintainer,

the command "emacs FILENAME", with extended characters in FILENAME,
causes the X-server to crash immediately.

xdm.log contains:

  Sun Mar 17 01:43:04 2019 xdm info (pid 7547): sourcing
  /etc/X11/xdm/Xreset
  XIO:  fatal IO error 4 (Interrupted system call) on X server ":0"
after 19 requests (13 known processed) with 0 events remaining.
(II) Server terminated successfully (0). Closing log file.


To reproduce, type "emacs $(echo -e \\xE4)" in an X-terminal.

This does not happen in the console.

Also, if emacs --daemon is running," emacsclient -c FILENAME" works
fine.

I put Severity:grave, because of the potential data loss.

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

Kernel: Linux 5.0.2-00092-ge9de71fc75e3 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE=de_DE 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs depends on:
ii  emacs-gtk  1:26.1+1-3.2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#924761: Gdebi gives no indication when it is working, and by dint of that makes the user suspect a hang

[Nicholas Joll]

Package: gdebi
Version: 0.9.5.7xmint8

When I open a large .deb with gdebi, such as a .deb created by building
the Linux kernel, gdebi - because it is doing some sort of checking or
loading? - does nothing, sometimes for some ten seconds. (This happens
even on a quadcore, i7, nvme SSD laptop with 16GM of RAM.) No message is
displayed about what is transpiring. Consequently the user has little
idea what is happening and wonders whether gdebi has hung. A related
problem: on my system at least, the terminal that one can display from
gdebi has a non-flashing cursor; hence one cannot visually distinguish a
hang from an operation in progress. Still, perhaps that latter problem
involves something other than gdebi.

Kernel: 5.0.0
$  ls -l /lib/*/libc.so.6
lrwxrwxrwx 1 root root 12 Apr 16  2018 /lib/i386-linux-gnu/libc.so.6 ->
libc-2.27.so
lrwxrwxrwx 1 root root 12 Apr 16  2018 /lib/x86_64-linux-gnu/libc.so.6
-> libc-2.27.so

My OS: Linux Mint 19.1 x64 Cinnamon (but this is - in some fundamental
sense, anyway - a Debian package, I take it; hence this bug report).

Bug#924760: Grub is extremely picky in regards to partition

[Brian Wengel]

Package: debian-installer
Version: Buster, debian-testing-amd64-DVD-1.iso, downloaded 2019-03-16

I hope the installer could be a little more flexible in regards to  EFI
partition, or is it because it require a SWAP partition, haven't been able
to point down the problem. Can only make a successful installation using
automatic.

Why put a size limit which is way larger than the technical limit?
This is Linux, not Apple or Windows!

I believe you can install grub2 on a 5MB FAT16 partition if you prefer.
But the installer absolutely want a very big partition.
There might be a technical reason, but I assume is just a matter of
opinion, right?
It fine it give a warning, but please let the user decide what to do. He
know what is best for him, not you. It is a very paternalistic attitude and
very far from the Linux spirit.

Bug#924735: debian-history: [INTL:pt] Updated Portuguese translation

[Osamu Aoki]

control: tags -1 pending

Hi,

On Sat, Mar 16, 2019 at 05:41:15PM +, Américo Monteiro wrote:
> Package: debian-history
> Version: 
> Tags: l10n, patch
> Severity: wishlist
> 
> Updated Portuguese translation for  debian-history messages
> Translator: Américo Monteiro 
> Feel free to use it.
> 
> For translation updates please contact 'Last Translator' 

Yes, committed to GIT with the new 'Last Translator'

Osamu
 
> -- 
> Melhores cumprimentos/Best regards,
> 
> Américo Monteiro
> 
> -

Bug#832920: (no subject)

[Thomas Lange]

If you access it via http, you will get code http 302 which is a
redirect. Browsers will then use https.

IMO we can close this bug now.
-- 
regards Thomas

Bug#924758: php7.0: Port to Debian Buster

[Dmitry Katsubo]

Package: php7.0
Version: 7.0.33-0+deb9u3
Severity: wishlist

Dear PHP maintainers,

There is a demand to run both PHP 7.0 and 7.3 on the same Debian server to 
allow transition of applications. Most of the applications are PHP 7.1 ready 
and sort of PHP 7.2 friendly, but 7.3 is really
a big jump.

Co-existence of these versions is almost possible, however I faced a problem 
with php7.0-curl which depends on libcurl3 which on some reason cannot be 
installed next to libcurl4 which is needed by
php7.3-curl (if you know the reason, please share).

So I have decided to recompile PHP for Debian Buster. In it almost worked 
except the following:

* libicu57 instead of libicu63 should be installed. This is because ./configure 
relies on /bin/icu-config which is not present in libicu-dev_63. Would be nice 
if PHP 7.0 can be linked against libicu63.
* On some reason autodetection of completion_matches() presence in readline.h 
does not work and HAVE_RL_COMPLETION_MATCHES stays undefined. This causes the 
following error:

/home/packages/php/php7.0-7.0.33/ext/readline/readline.c:34:31: error: 
conflicting types for ‘completion_matches’
 #define rl_completion_matches completion_matches
   ^~
In file included from 
/home/packages/php/php7.0-7.0.33/ext/readline/readline.c:38:
/usr/include/editline/readline.h:183:15: note: previous declaration of 
‘completion_matches’ was here
 char**completion_matches(/* const */ char *, rl_compentry_func_t *);
   ^~
make[2]: *** [Makefile:1663: ext/readline/readline.lo] Error 1
make[2]: Leaving directory '/home/packages/php/php7.0-7.0.33/ext-build'

I don't know how to fix that correctly.

I wonder if somebody could port PHP 7.0 to Debian Buster. Many thanks!

-- 
With best regards,
Dmitry

Bug#924755: gnome-user-docs: fails to clean after build: execvp: /bin/bash: Argument list too long

[Jeremy Bicha]

On Sat, Mar 16, 2019 at 6:40 PM Andreas Beckmann  wrote:
> Version: 3.32.0-1
> Severity: serious
> Justification: fails to build from source

I question the severity you have assigned to this issue. As I assume
you're aware, by marking the bug as "serious, version 3.32.0-1", you
will prevent newer versions from reaching Testing once we finally
start pushing GNOME 3.32 stuff to Unstable. I question if there is
anywhere in policy that says a package has to build twice in a row.
That's obviously not needed for the official buildds. And I question
whether this issue is new in 3.32.

I suggest we downgrade this issue to "important". I recommend that you
also report this issue to GNOME.

I have ported gnome-user-docs to meson a good while ago, but it hasn't
been accepted yet because the GNOME doc websites don't handle cmake &
meson modules well yet. There's a good chance switching to meson would
fix this issue.

Thanks,
Jeremy Bicha

Bug#904111: {2019 Top News}

[Mohamad Saiful Syazwi Bin Zaiman]

From: Mohamad Saiful Syazwi Bin Zaiman
Sent: Sunday, March 17, 2019 6:41 AM
To: i...@donation.com
Subject: {2019 Top News}

Mrs Susan picked you Reply To mrssusan...@gmail.com  for more details

Bug#924756: libg3d: fails to clean after build

[Andreas Beckmann]

Source: libg3d
Version: 0.0.8-27
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

libg3d/experimental fails to build twice in a row because cleaning after
the first (and successful) build fails:

 fakeroot debian/rules clean
dh clean --without autoreconf
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/build/libg3d-0.0.8'
rm -rf "/build/libg3d-0.0.8/build"
make[1]: Leaving directory '/build/libg3d-0.0.8'
   dh_clean
dh_clean: mv 
debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c.tmp
 build/config/config.guess: No such file or directory
make: *** [debian/rules:20: clean] Error 2


Andreas


libg3d_0.0.8-27_twice.log.gz
Description: application/gzip

Bug#924736: [Pkg-zsh-devel] Bug#924736: zsh 5.7.1 segfaults when three setopt options are in play

[wesleys]

Hello Axel,


> I can also confirm that this is reproducible with zsh compiled as of
> the current git HEAD (commit 947e26fe).
> 
> Will forward your bug report to upstream.

I've bisected the bug and it seems 
https://github.com/zsh-users/zsh/commit/758966502caa6f91abcbaaebf2610609250de1fb
 is responsible for the breakage. It has two options (and maybe more)
1) revert
2) A minimal patch to change 1 line (thanks to #zsh)

I just subscribed to zsh-workers and saw your mail, I will forward this bit of 
information as well.

Thanks!
Wesley

Bug#924754: libhandy: Please package 0.0.9

[Jeremy Bicha]

Source: libhandy
Version: 0.0.8-1
Severity: wishlist

Please package libhandy 0.0.9. Some GNOME 3.32 apps being packaged for
Debian experimental require that version.

Thanks,
Jeremy Bicha

Bug#924704: bumblebee-nvidia: nvidia-driver 410 doesn't appear to allow the unloading of the nvidia module

[Luca Boccassi]

That's not the case anymore in buster, 390xx works fine with other packages

On Sat, 16 Mar 2019, 21:03 Danfun360  I already tried legacy-390xx. As I said before, there doesn't seem to be
> equivalents of nvidia-cuda-toolkit and nvidia-cuda-dev that don't try to
> force the latest nvidia drivers. Also, bumblebee doesn't recognize the
> legacy-390xx drivers as a GLX alternative (I get an error stating such).
>
> If I was to remove bbswitch, would I be unable to use PRIMUS? Also how
> would I go about with my VGA Passthrough setup?
>
> On Sat, Mar 16, 2019 at 4:12 PM Luca Boccassi  wrote:
>
>> Control: severity -1 minor
>>
>> Try switching to legacy-390xx, or removing bbswitch and using the
>> kernel's power management, with these laptops it's always a dice roll
>> on what will actually work
>>
>> On Sat, 2019-03-16 at 14:19 -0400, Danfun360 wrote:
>> > The graphics card in my laptop is an Nvidia Geforce GTX 1050.
>> >
>> > On Sat, Mar 16, 2019 at 7:20 AM Luca Boccassi > > m>
>> > wrote:
>> >
>> > > What Nvidia card does your laptop have?
>> > >
>> > > On Sat, 16 Mar 2019, 03:42 Daniel O. > > >
>> > > > Package: bumblebee-nvidia
>> > > > Version: 3.2.1-20
>> > > > Severity: grave
>> > > > Justification: renders package unusable
>> > > >
>> > > > Dear Maintainer, I write this bug report because this
>> > > > bumblebee/bumblebeed
>> > > > doesn't work as it should.
>> > > >
>> > > >* What led up to the situation? Bumblebee used to work
>> > > > correctly when
>> > > > the
>> > > > nvidia driver was at 390. A few days ago it was upgraded to 410.
>> > > > At the
>> > > > time I
>> > > > was running Debian Buster (testing as of this writing). That's
>> > > > where
>> > > > things
>> > > > started to get problematic. It appears that the nvidia module
>> > > > couldn't be
>> > > > unloaded or something. bbswitch reported as "ON" without optirun,
>> > > > and as
>> > > > the
>> > > > nvidia drivers were considered in use, I was unable to unbind the
>> > > > nvidia
>> > > > driver
>> > > > for VGA Passthrough as I had been doing before.
>> > > >* What exactly did you do (or not do) that was effective (or
>> > > >  ineffective)? I uninstalled every bumblebee and nvidia
>> > > > package. I
>> > > > then
>> > > > reinstalled everything. No luck. I then uninstalled everything
>> > > > and went
>> > > > for the
>> > > > legacy 390 package. Unfortunately there were problems with that:
>> > > > nvidia-cuba-
>> > > > toolkit and nvidia-cuba-dev require the latest nvidia driver
>> > > > installed.
>> > > > On top
>> > > > of that, bumblebee refused to see the legacy 390 drivers as a glx
>> > > > alternative.
>> > > > I uninstalled all the nvidia stuff again, switched to Debian Sid,
>> > > > and
>> > > > installed
>> > > > the latest nvidia drivers again (they were slightly more up to
>> > > > date on
>> > > > Sid than
>> > > > in Buster). Still no change.
>> > > >* What was the outcome of this action? Bumblebee should be
>> > > > able to
>> > > > blacklist
>> > > > the nvidia driver and isolate it from the operating system in
>> > > > such a way
>> > > > that
>> > > > the system would run on the integrated GPU and run the discrete
>> > > > GPU for
>> > > > applications when called for.
>> > > >* What outcome did you expect instead? The nvidia driver is
>> > > > not
>> > > > blacklisted,
>> > > > and the discrete GPU is in control.
>> > > >
>> > > > On a different note, I tried posting a bug report upstream. It
>> > > > has some
>> > > > information this report might not have (vice versa is definitely
>> > > > the case,
>> > > > unfortunately). It can be found at https://github.com/Bumblebee-
>> > > > Project/Bumblebee/issues/1023
>> > > >
>> > > >
>> > > >
>> > > > -- System Information:
>> > > > Debian Release: buster/sid
>> > > >   APT prefers unstable
>> > > >   APT policy: (500, 'unstable')
>> > > > Architecture: amd64 (x86_64)
>> > > > Foreign Architectures: i386
>> > > >
>> > > > Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
>> > > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>> > > > TAINT_UNSIGNED_MODULE
>> > > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>> > > > LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
>> > > > Shell: /bin/sh linked to /usr/bin/dash
>> > > > Init: systemd (via /run/systemd/system)
>> > > > LSM: AppArmor: enabled
>> > > >
>> > > > Versions of packages bumblebee-nvidia depends on:
>> > > > ii  bumblebee   3.2.1-20
>> > > > ii  glx-alternative-nvidia  0.9.1
>> > > > ii  nvidia-driver   410.104-1
>> > > > ii  nvidia-kernel-dkms  410.104-1
>> > > >
>> > > > bumblebee-nvidia recommends no packages.
>> > > >
>> > > > bumblebee-nvidia suggests no packages.
>> > > >
>> > > > -- no debconf information
>> > > >
>> > > > ___
>> > > > pkg-nvidia-devel mailing list
>> > > > pkg-nvidia-de...@alioth-lists.debian.net
>> > > > 

Bug#924753: gnome-shell: external monitor with different dpi fails to scale properly

[Artificial Amateur]

Package: gnome-shell
Version: 3.30.2-3
Severity: normal

Dear Maintainer,

   * Laptop contains an integrated 4k display with HiDPI enabled. External 2k
monitor display with LOWDPI.
   * Connecting the external monitor created windows on the lowdpi monitor to
have outrageously large scaling.
   * Expected monitors to automatically adjust individual monitor scaling to be
appropriate.
   * I was able to use a temporary fix by running: `xrandr --output DP-2 --auto
--output DP-1.2 --auto --scale 2x2 --right-of DP-2` allowing the hidpi and
lowdpi monitors to display similarly scaled windows on each display.



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

Kernel: Linux 4.19.0-2-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-3
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-1
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4
ii  gir1.2-mutter-3  3.30.2-6
ii  gir1.2-nm-1.01.14.6-2
ii  gir1.2-nma-1.0   1.8.20-1
ii  gir1.2-pango-1.0 1.42.4-6
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-3
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-8
ii  libcairo21.16.0-3
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1
ii  libedataserver-1.2-233.30.5-1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1
ii  libglib2.0-0 2.58.3-1
ii  libglib2.0-bin   2.58.3-1
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libical3 3.0.4-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-6
ii  libnm0   1.14.6-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii  libpulse-mainloop-glib0  12.2-4
ii  libpulse012.2-4
ii  libsecret-1-00.18.7-1
ii  libstartup-notification0 0.12-6
ii  libsystemd0  241-1
ii  libx11-6 2:1.6.7-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.30.2-6
ii  python3  3.7.2-1

Versions of packages gnome-shell recommends:
ii  bolt  0.7-2
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.30.2-3
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.30.3-1
ii  gnome-user-docs   3.30.2-1
ii  iio-sensor-proxy 

Bug#924752: unblock: rust-failure/0.1.5-1

[Ximin Luo]

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

Please unblock package rust-failure

rust-failure-derive was mistakenly uploaded a few weeks ago and has now
migrated to testing. It is not compatible with rust-failure 0.1.3-1 which
is currently in testing, and causes FTBFS of other packages e.g #924206.

Robin and kpcyrd, please confirm that this fixes the problem.

unblock rust-failure/0.1.5-1

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru rust-failure-0.1.3/book/src/error-errorkind.md 
rust-failure-0.1.5/book/src/error-errorkind.md
--- rust-failure-0.1.3/book/src/error-errorkind.md  2018-07-27 
11:18:03.0 -0700
+++ rust-failure-0.1.5/book/src/error-errorkind.md  2018-12-29 
15:13:10.0 -0800
@@ -39,6 +39,10 @@
 
 ```rust
 impl Fail for MyError {
+fn name() -> Option<> {
+self.inner.name()
+}
+
 fn cause() -> Option<> {
 self.inner.cause()
 }
@@ -140,4 +144,4 @@
 
 [use-error]: ./use-error.html
 [custom-fail]: ./custom-fail.html
-[context-api]: https://boats.gitlab.io/failure/doc/failure/struct.Context.html
+[context-api]: https://docs.rs/failure/latest/failure/struct.Context.html
diff -Nru rust-failure-0.1.3/book/src/error-msg.md 
rust-failure-0.1.5/book/src/error-msg.md
--- rust-failure-0.1.3/book/src/error-msg.md2018-07-26 14:32:49.0 
-0700
+++ rust-failure-0.1.5/book/src/error-msg.md2018-12-29 15:00:15.0 
-0800
@@ -55,5 +55,5 @@
 
 [custom-fail]: ./custom-fail.html
 [use-error]: ./use-error.html
-[err-msg-api]: https://boats.gitlab.io/failure/doc/failure/fn.err_msg.html
-[format-err-api]: 
https://boats.gitlab.io/failure/doc/failure/macro.format_err.html
+[err-msg-api]: https://docs.rs/failure/latest/failure/fn.err_msg.html
+[format-err-api]: https://docs.rs/failure/latest/failure/macro.format_err.html
diff -Nru rust-failure-0.1.3/book/src/fail.md 
rust-failure-0.1.5/book/src/fail.md
--- rust-failure-0.1.3/book/src/fail.md 2018-10-20 12:05:53.0 -0700
+++ rust-failure-0.1.5/book/src/fail.md 2018-12-29 14:59:06.0 -0800
@@ -147,6 +147,6 @@
 implement `std::error::Error` and also override the backtrace and cause methods
 on `Fail`. We intend to enable this with specialization when it becomes stable.
 
-[derive-docs]: https://boats.gitlab.io/failure/derive-fail.html
+[derive-docs]: ./derive-fail.html
 [stderror]: https://doc.rust-lang.org/std/error/trait.Error.html
 [backtrace-crate]: http://alexcrichton.com/backtrace-rs
diff -Nru rust-failure-0.1.3/book/src/intro.md 
rust-failure-0.1.5/book/src/intro.md
--- rust-failure-0.1.3/book/src/intro.md2018-07-27 11:09:57.0 
-0700
+++ rust-failure-0.1.5/book/src/intro.md2018-12-29 14:58:24.0 
-0800
@@ -6,7 +6,7 @@
 * [API documentation][api]
 * [failure source code][repo]
 
-[api]: https://boats.gitlab.io/failure/doc/failure
+[api]: https://docs.rs/failure
 [repo]: https://github.com/rust-lang-nursery/failure
 
 ```rust
diff -Nru rust-failure-0.1.3/book/src/string-custom-error.md 
rust-failure-0.1.5/book/src/string-custom-error.md
--- rust-failure-0.1.3/book/src/string-custom-error.md  2018-10-20 
12:05:53.0 -0700
+++ rust-failure-0.1.5/book/src/string-custom-error.md  2018-12-29 
15:13:39.0 -0800
@@ -20,6 +20,10 @@
 }
 
 impl Fail for MyError {
+fn name() -> Option<> {
+self.inner.name()
+}
+
 fn cause() -> Option<> {
 self.inner.cause()
 }
@@ -105,6 +109,10 @@
 }
 
 impl Fail for MyError {
+fn name() -> Option<> {
+self.inner.name()
+}
+
 fn cause() -> Option<> {
 self.inner.cause()
 }
diff -Nru rust-failure-0.1.3/Cargo.lock.ci rust-failure-0.1.5/Cargo.lock.ci
--- rust-failure-0.1.3/Cargo.lock.ci1969-12-31 16:00:00.0 -0800
+++ rust-failure-0.1.5/Cargo.lock.ci2018-12-29 12:51:09.0 -0800
@@ -0,0 +1,136 @@
+[[package]]
+name = "backtrace"
+version = "0.3.9"
+source = "registry+https://github.com/rust-lang/crates.io-index;
+dependencies = [
+ "backtrace-sys 0.1.24 
(registry+https://github.com/rust-lang/crates.io-index)",
+ "cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
+ "libc 0.2.43 (registry+https://github.com/rust-lang/crates.io-index)",
+ "rustc-demangle 0.1.11 
(registry+https://github.com/rust-lang/crates.io-index)",
+ "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
+]
+
+[[package]]
+name = "backtrace-sys"
+version = "0.1.24"

Bug#838903: A note about switching to the new "Command" applet

[Marcin Owsiany]

FTR, I added a little note that might help anyone wanting to switch to the
"Command" applet from command-runner-applet:
https://github.com/porridge/command-runner-applet/blob/master/README#L15-L18

Bug#924751: dh-cargo: Document dh-cargo-built-using

[Ximin Luo]

Package: dh-cargo
Version: 17
Severity: important

dh-cargo-built-using is used by several important crates but the documentation
for this is atrocious (basically "RTFS"). This should be improved, especially
since we'll probably be expanding it in future to support that other feature.
("Support transitive runtime depends")

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

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

Versions of packages dh-cargo depends on:
ii  cargo  0.33.0-1
ii  debhelper  12.1.1
ii  perl   5.28.1-4
ii  python33.7.2-1

dh-cargo recommends no packages.

dh-cargo suggests no packages.

-- no debconf information

Bug#924750: dh-cargo: Support transitive runtime-depends

[Ximin Luo]

Package: dh-cargo
Version: 17
Severity: important

Some crates (e.g. opener) cause a runtime-dependency *for any crate that uses
it*. For example cargo should really Depends: xdg-utils because it uses opener.

We currently have no way of expressing this. We could use a mechanism similar
to dh-cargo-built-using which embeds this information into the build.rs output.
We should support depends/recommends/suggests, arguably xdg-utils from the
above example should be a Recommends rather than a hard Depends.

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

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

Versions of packages dh-cargo depends on:
ii  cargo  0.33.0-1
ii  debhelper  12.1.1
ii  perl   5.28.1-4
ii  python33.7.2-1

dh-cargo recommends no packages.

dh-cargo suggests no packages.

-- no debconf information

Bug#924749: ITP: hd-idle -- Spin down idle [USB] hard disks

[Alex Mestiashvili]

Package: wnpp
Severity: wishlist
Owner: Alex Mestiashvili 

* Package name: hd-idle
  Version : 1.05
  Upstream Author : Christian Mueller 
* URL : http://hd-idle.sourceforge.net/
* License : GPLv2
  Programming Lang: C
  Description : Spin down idle [USB] hard disks

hd-idle is a utility program for spinning-down external disks after a period
of idle time. Since most external IDE disk enclosures don't support setting
the IDE idle timer, a program like hd-idle is required to spin down idle disks
automatically.
.
A word of caution: hard disks don't like spinning up too often. Laptop disks
are more robust in this respect than desktop disks but if you set your disks
to spin down after a few seconds you may damage the disk over time due to the
stress the spin-up causes on the spindle motor and bearings. It seems that
manufacturers recommend a minimum idle time of 3-5 minutes, the default in
hd-idle is 10 minutes.
.
One more word of caution: hd-idle will spin down any disk accessible via the
SCSI layer (USB, IEEE1394, ...) but it will not work with real SCSI disks
because they don't spin up automatically. Thus it's not called scsi-idle and
I don't recommend using it on a real SCSI system unless you have a kernel
patch that automatically starts the SCSI disks after receiving a sense buffer
indicating the disk has been stopped. Without such a patch, real SCSI disks
won't start again and you can as well pull the plug.


Some drives, do not support spin down via hdparm, but can be spun down
using hd-idle.
The package will be maintained under collab-maint on salsa.

Bug#924736: [Pkg-zsh-devel] Bug#924736: zsh 5.7.1 segfaults when three setopt options are in play

[Axel Beckert]

Control: tag -1 + upstream confirmed

Hi Wesley,

Wesley Schwengle wrote:
> Have a zshrc with the following setopts:
> 
> setopt hist_reduce_blanks
> setopt hist_ignore_space
> setopt interactivecomments
> 
> * Run zsh -f
> * Now enter ` #`
> * You get a command not found error
> * Now source your zshrc
> * Again entery ` #`
> * Segfault

I can reproduce this on Sid amd64.

And this set of options also seems to be already minimal to trigger
this issue.

> It does work on Debian stable (zsh 5.3.1).

Correct, I can not reproduce this on Stretch amd64 with zsh 5.3.1-4.

wesl...@euronet.nl wrote:
> on #zsh there was some confusion about the reproduction path
> ` #` should be typed *without* the backticks. Spaces are hard to show on 
> a text only medium.
> 
> FWIW, it seems like an upstream bug, I can also reproduce it on Arch

Thanks for that detail.

I can also confirm that this is reproducible with zsh compiled as of
the current git HEAD (commit 947e26fe).

Will forward your bug report to upstream.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#924704: bumblebee-nvidia: nvidia-driver 410 doesn't appear to allow the unloading of the nvidia module

[Danfun360]

I already tried legacy-390xx. As I said before, there doesn't seem to be
equivalents of nvidia-cuda-toolkit and nvidia-cuda-dev that don't try to
force the latest nvidia drivers. Also, bumblebee doesn't recognize the
legacy-390xx drivers as a GLX alternative (I get an error stating such).

If I was to remove bbswitch, would I be unable to use PRIMUS? Also how
would I go about with my VGA Passthrough setup?

On Sat, Mar 16, 2019 at 4:12 PM Luca Boccassi  wrote:

> Control: severity -1 minor
>
> Try switching to legacy-390xx, or removing bbswitch and using the
> kernel's power management, with these laptops it's always a dice roll
> on what will actually work
>
> On Sat, 2019-03-16 at 14:19 -0400, Danfun360 wrote:
> > The graphics card in my laptop is an Nvidia Geforce GTX 1050.
> >
> > On Sat, Mar 16, 2019 at 7:20 AM Luca Boccassi  > m>
> > wrote:
> >
> > > What Nvidia card does your laptop have?
> > >
> > > On Sat, 16 Mar 2019, 03:42 Daniel O.  > >
> > > > Package: bumblebee-nvidia
> > > > Version: 3.2.1-20
> > > > Severity: grave
> > > > Justification: renders package unusable
> > > >
> > > > Dear Maintainer, I write this bug report because this
> > > > bumblebee/bumblebeed
> > > > doesn't work as it should.
> > > >
> > > >* What led up to the situation? Bumblebee used to work
> > > > correctly when
> > > > the
> > > > nvidia driver was at 390. A few days ago it was upgraded to 410.
> > > > At the
> > > > time I
> > > > was running Debian Buster (testing as of this writing). That's
> > > > where
> > > > things
> > > > started to get problematic. It appears that the nvidia module
> > > > couldn't be
> > > > unloaded or something. bbswitch reported as "ON" without optirun,
> > > > and as
> > > > the
> > > > nvidia drivers were considered in use, I was unable to unbind the
> > > > nvidia
> > > > driver
> > > > for VGA Passthrough as I had been doing before.
> > > >* What exactly did you do (or not do) that was effective (or
> > > >  ineffective)? I uninstalled every bumblebee and nvidia
> > > > package. I
> > > > then
> > > > reinstalled everything. No luck. I then uninstalled everything
> > > > and went
> > > > for the
> > > > legacy 390 package. Unfortunately there were problems with that:
> > > > nvidia-cuba-
> > > > toolkit and nvidia-cuba-dev require the latest nvidia driver
> > > > installed.
> > > > On top
> > > > of that, bumblebee refused to see the legacy 390 drivers as a glx
> > > > alternative.
> > > > I uninstalled all the nvidia stuff again, switched to Debian Sid,
> > > > and
> > > > installed
> > > > the latest nvidia drivers again (they were slightly more up to
> > > > date on
> > > > Sid than
> > > > in Buster). Still no change.
> > > >* What was the outcome of this action? Bumblebee should be
> > > > able to
> > > > blacklist
> > > > the nvidia driver and isolate it from the operating system in
> > > > such a way
> > > > that
> > > > the system would run on the integrated GPU and run the discrete
> > > > GPU for
> > > > applications when called for.
> > > >* What outcome did you expect instead? The nvidia driver is
> > > > not
> > > > blacklisted,
> > > > and the discrete GPU is in control.
> > > >
> > > > On a different note, I tried posting a bug report upstream. It
> > > > has some
> > > > information this report might not have (vice versa is definitely
> > > > the case,
> > > > unfortunately). It can be found at https://github.com/Bumblebee-
> > > > Project/Bumblebee/issues/1023
> > > >
> > > >
> > > >
> > > > -- System Information:
> > > > Debian Release: buster/sid
> > > >   APT prefers unstable
> > > >   APT policy: (500, 'unstable')
> > > > Architecture: amd64 (x86_64)
> > > > Foreign Architectures: i386
> > > >
> > > > Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
> > > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> > > > TAINT_UNSIGNED_MODULE
> > > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> > > > LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> > > > Shell: /bin/sh linked to /usr/bin/dash
> > > > Init: systemd (via /run/systemd/system)
> > > > LSM: AppArmor: enabled
> > > >
> > > > Versions of packages bumblebee-nvidia depends on:
> > > > ii  bumblebee   3.2.1-20
> > > > ii  glx-alternative-nvidia  0.9.1
> > > > ii  nvidia-driver   410.104-1
> > > > ii  nvidia-kernel-dkms  410.104-1
> > > >
> > > > bumblebee-nvidia recommends no packages.
> > > >
> > > > bumblebee-nvidia suggests no packages.
> > > >
> > > > -- no debconf information
> > > >
> > > > ___
> > > > pkg-nvidia-devel mailing list
> > > > pkg-nvidia-de...@alioth-lists.debian.net
> > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-nvid
> > > > ia-devel
> > >
> > >
> --
> Kind regards,
> Luca Boccassi
>

Bug#740893: ‘libjs-jquery-hotkeys’ 0.2.0 works with ‘python-coverage’

[Paul Gevers]

Hi,

On Wed, 13 Mar 2019 12:44:37 +1100 Ben Finney  wrote:
> On 10-Oct-2018, Thomas Goirand wrote:
> > I've prepared an update of this package to the version available at:
> > https://github.com/jeresig/jquery.hotkeys
> > 
> > Can you please try?
> 
> Testing this manually, I find that the “0.2.0” version you've prepared
> means that it works for the dependency in ‘python-coverage’ for
> hotkeys support.
> 
> Are there more checks you would like to be done?

Please be aware that one of the reverse-dependencies of
libjs-jquery-hotkeys is cacti, which uses the tzuryby version upstream.
I haven't investigated, but I expect that replacing libjs-jquery-hotkeys
with the jeresig version is going to break cacti.

If I understand this bug properly, I think Debian could/should have two
versions of libjs-jquery-hotkeys, one for each upstream. If that is
correct, than it is too late in the release cycle to fix this issue if
we keep in mind that it is already 5 years old and present in stable
releases.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#924748: unblock: shibboleth-sp/3.0.4+dfsg1-1

[Ferenc Wágner]

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

Please unblock package shibboleth-sp

Dear Release Team,

When upstream fixed #924346 in xmltooling, they also fixed the same
problem (uncaught parser exceptions) in shibboleth-sp to prevent DoS
crashes that haven't been identified yet.  The fixes were published
together in new patch-level upstream releases for the whole Shibboleth
Service Provider stack: xmltooling, opensaml and shibboleth-sp.  Beyond
the DoS prevention, shibboleth-sp 3.0.4 consists of three other bugfixes:
* incorrect C++ code usage pattern invoking undefined behavior via
  boost::bind (https://issues.shibboleth.net/jira/browse/SSPCPP-847,
  already mentioned in unblock request #924577);
* certain web applications provoking unbounded cookie data growth
  (https://issues.shibboleth.net/jira/browse/SSPCPP-851); and
* documented configuration settings being ignored in some contexts
  (https://issues.shibboleth.net/jira/browse/SSPCPP-848).
This last one can be worked around by verbosely expanding the affected
configuration constructs, so it can be considered a minor issue.  But
the other three are major or potentially serious, so I ask for your
permission to to upload 3.0.4+dfsg1-1 to unstable with a future unblock.

Thanks,
Feri.

diff -Nru shibboleth-sp-3.0.3+dfsg1/configure 
shibboleth-sp-3.0.4+dfsg1/configure
--- shibboleth-sp-3.0.3+dfsg1/configure 2018-12-12 20:16:00.0 +0100
+++ shibboleth-sp-3.0.4+dfsg1/configure 2019-03-08 16:15:39.0 +0100
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for shibboleth 3.0.3.
+# Generated by GNU Autoconf 2.69 for shibboleth 3.0.4.
 #
 # Report bugs to .
 #
@@ -590,8 +590,8 @@
 # Identity of this package.
 PACKAGE_NAME='shibboleth'
 PACKAGE_TARNAME='shibboleth-sp'
-PACKAGE_VERSION='3.0.3'
-PACKAGE_STRING='shibboleth 3.0.3'
+PACKAGE_VERSION='3.0.4'
+PACKAGE_STRING='shibboleth 3.0.4'
 PACKAGE_BUGREPORT='https://issues.shibboleth.net/'
 PACKAGE_URL=''
 
@@ -1522,7 +1522,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures shibboleth 3.0.3 to adapt to many kinds of systems.
+\`configure' configures shibboleth 3.0.4 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1592,7 +1592,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of shibboleth 3.0.3:";;
+ short | recursive ) echo "Configuration of shibboleth 3.0.4:";;
esac
   cat <<\_ACEOF
 
@@ -1792,7 +1792,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-shibboleth configure 3.0.3
+shibboleth configure 3.0.4
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2670,7 +2670,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by shibboleth $as_me 3.0.3, which was
+It was created by shibboleth $as_me 3.0.4, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -3535,7 +3535,7 @@
 
 # Define the identity of the package.
  PACKAGE='shibboleth-sp'
- VERSION='3.0.3'
+ VERSION='3.0.4'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -24198,7 +24198,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by shibboleth $as_me 3.0.3, which was
+This file was extended by shibboleth $as_me 3.0.4, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -24264,7 +24264,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-shibboleth config.status 3.0.3
+shibboleth config.status 3.0.4
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru shibboleth-sp-3.0.3+dfsg1/configure.ac 
shibboleth-sp-3.0.4+dfsg1/configure.ac
--- shibboleth-sp-3.0.3+dfsg1/configure.ac  2018-10-12 20:06:42.0 
+0200
+++ shibboleth-sp-3.0.4+dfsg1/configure.ac  2019-03-08 16:09:43.0 
+0100
@@ -1,5 +1,5 @@
 AC_PREREQ([2.50])
-AC_INIT([shibboleth],[3.0.3],[https://issues.shibboleth.net/],[shibboleth-sp])
+AC_INIT([shibboleth],[3.0.4],[https://issues.shibboleth.net/],[shibboleth-sp])
 AC_CONFIG_SRCDIR(shibsp)
 AC_CONFIG_AUX_DIR(build-aux)
 AC_CONFIG_MACRO_DIR(m4)
diff -Nru shibboleth-sp-3.0.3+dfsg1/config_win32.h 
shibboleth-sp-3.0.4+dfsg1/config_win32.h
--- shibboleth-sp-3.0.3+dfsg1/config_win32.h2018-10-12 20:06:42.0 
+0200
+++ shibboleth-sp-3.0.4+dfsg1/config_win32.h2019-03-08 16:09:43.0 
+0100
@@ -121,13 

Bug#924745: rclone: please upload 1.46 to experimental (supports symlinks)

[Drew Parsons]

Package: rclone
Version: 1.45-2+b20
Severity: normal

A new upstream version 1.46 is now available for rclone. This version
introduces support for symlinks which is a huge step forward.

A pity the timing means we can't get it into buster.  But could you
upload it into experimental in the meantime?

Thanks,
Drew

Bug#924704: bumblebee-nvidia: nvidia-driver 410 doesn't appear to allow the unloading of the nvidia module

[Luca Boccassi]

Control: severity -1 minor

Try switching to legacy-390xx, or removing bbswitch and using the
kernel's power management, with these laptops it's always a dice roll
on what will actually work

On Sat, 2019-03-16 at 14:19 -0400, Danfun360 wrote:
> The graphics card in my laptop is an Nvidia Geforce GTX 1050.
> 
> On Sat, Mar 16, 2019 at 7:20 AM Luca Boccassi  m>
> wrote:
> 
> > What Nvidia card does your laptop have?
> > 
> > On Sat, 16 Mar 2019, 03:42 Daniel O.  > 
> > > Package: bumblebee-nvidia
> > > Version: 3.2.1-20
> > > Severity: grave
> > > Justification: renders package unusable
> > > 
> > > Dear Maintainer, I write this bug report because this
> > > bumblebee/bumblebeed
> > > doesn't work as it should.
> > > 
> > >    * What led up to the situation? Bumblebee used to work
> > > correctly when
> > > the
> > > nvidia driver was at 390. A few days ago it was upgraded to 410.
> > > At the
> > > time I
> > > was running Debian Buster (testing as of this writing). That's
> > > where
> > > things
> > > started to get problematic. It appears that the nvidia module
> > > couldn't be
> > > unloaded or something. bbswitch reported as "ON" without optirun,
> > > and as
> > > the
> > > nvidia drivers were considered in use, I was unable to unbind the
> > > nvidia
> > > driver
> > > for VGA Passthrough as I had been doing before.
> > >    * What exactly did you do (or not do) that was effective (or
> > >  ineffective)? I uninstalled every bumblebee and nvidia
> > > package. I
> > > then
> > > reinstalled everything. No luck. I then uninstalled everything
> > > and went
> > > for the
> > > legacy 390 package. Unfortunately there were problems with that:
> > > nvidia-cuba-
> > > toolkit and nvidia-cuba-dev require the latest nvidia driver
> > > installed.
> > > On top
> > > of that, bumblebee refused to see the legacy 390 drivers as a glx
> > > alternative.
> > > I uninstalled all the nvidia stuff again, switched to Debian Sid,
> > > and
> > > installed
> > > the latest nvidia drivers again (they were slightly more up to
> > > date on
> > > Sid than
> > > in Buster). Still no change.
> > >    * What was the outcome of this action? Bumblebee should be
> > > able to
> > > blacklist
> > > the nvidia driver and isolate it from the operating system in
> > > such a way
> > > that
> > > the system would run on the integrated GPU and run the discrete
> > > GPU for
> > > applications when called for.
> > >    * What outcome did you expect instead? The nvidia driver is
> > > not
> > > blacklisted,
> > > and the discrete GPU is in control.
> > > 
> > > On a different note, I tried posting a bug report upstream. It
> > > has some
> > > information this report might not have (vice versa is definitely
> > > the case,
> > > unfortunately). It can be found at https://github.com/Bumblebee-
> > > Project/Bumblebee/issues/1023
> > > 
> > > 
> > > 
> > > -- System Information:
> > > Debian Release: buster/sid
> > >   APT prefers unstable
> > >   APT policy: (500, 'unstable')
> > > Architecture: amd64 (x86_64)
> > > Foreign Architectures: i386
> > > 
> > > Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
> > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> > > TAINT_UNSIGNED_MODULE
> > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> > > LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> > > Shell: /bin/sh linked to /usr/bin/dash
> > > Init: systemd (via /run/systemd/system)
> > > LSM: AppArmor: enabled
> > > 
> > > Versions of packages bumblebee-nvidia depends on:
> > > ii  bumblebee   3.2.1-20
> > > ii  glx-alternative-nvidia  0.9.1
> > > ii  nvidia-driver   410.104-1
> > > ii  nvidia-kernel-dkms  410.104-1
> > > 
> > > bumblebee-nvidia recommends no packages.
> > > 
> > > bumblebee-nvidia suggests no packages.
> > > 
> > > -- no debconf information
> > > 
> > > ___
> > > pkg-nvidia-devel mailing list
> > > pkg-nvidia-de...@alioth-lists.debian.net
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-nvid
> > > ia-devel
> > 
> > 
-- 
Kind regards,
Luca Boccassi

Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)

[Tim Rühsen]

Please do not remove this package, the first CI builds (MinGW cross
builds) already break (GNU Wget / Wget2).

Well, it's already gone from buster... please add it back or provide a
another way to convert charsets within cross-compiled Windows executables.

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#924747: ruby-doorkeeper-openid-connect: CVE-2019-9837

[Salvatore Bonaccorso]

Source: ruby-doorkeeper-openid-connect
Version: 1.5.2-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/doorkeeper-gem/doorkeeper-openid_connect/issues/61

Hi,

The following vulnerability was published for ruby-doorkeeper-openid-connect.

CVE-2019-9837[0]:
| Doorkeeper::OpenidConnect (aka the OpenID Connect extension for
| Doorkeeper) 1.4.x and 1.5.x before 1.5.4 has an open redirect via the
| redirect_uri field in an OAuth authorization request (that results in
| an error response) with the 'openid' scope and a prompt=none value.
| This allows phishing attacks against the authorization flow.

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-9837
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9837
[1] https://github.com/doorkeeper-gem/doorkeeper-openid_connect/issues/61
[2] https://github.com/doorkeeper-gem/doorkeeper-openid_connect/pull/66

Regards,
Salvatore

Bug#924685: RFP: cumin -- An automation and orchestration framework

[Moritz Muehlenhoff]

Antoine Beaupre wrote:
> Upstream (in CC) already ships Debian packages on their Github
> releases page, but it would be great to see this in Debian.
> 
> I'd be happy to sponsor this package if upstream is willing to act as
> maintainers, otherwise I will look at packaging this myself.

Hi Antoine,
thanks for your interest in Cumin :-)

We're totally planning to maintain Cumin in Debian, but there's a
few breaking changes lined up we don't want to impose on Debian
users (plus NEW is frozen anyway), so this will probably only
happen in a few months at the start of the bullseye development cycle.

Cheers,
Moritz

Bug#924325: gcc-8-cross: FTBFS for unknown reasons

[Matthias Klose]

On 16.03.19 18:37, Santiago Vila wrote:
> On Sat, Mar 16, 2019 at 05:59:16PM +0100, Matthias Klose wrote:
>> On 11.03.19 18:47, Santiago Vila wrote:
>>> On Mon, Mar 11, 2019 at 06:34:18PM +0100, Matthias Klose wrote:
>>>
 I have no clue, I have never seen that before, and it seems to work fine 
 on the
 buildds, and in the cross-toolchain-base* package's autopkg test.  
 Starting here
 a build with -j1 to see if it's reproducible.

 Is this seen with gcc-7-cross and gcc-9-cross as well?
>>>
>>> It happened to me with the (now removed) gcc-7-cross as well, yes.
>>> In case it helps, these are the logs I had in my last backup:
>>>
>>> https://people.debian.org/~sanvila/build-logs/gcc-7-cross/
>>>
>>> (Never tried gcc-9-cross yet because my usual target is testing and
>>> sometimes sid).
>>
>> a gcc-9 build with -j1 succeeds.  I'm not spending more time on this.
> 
> I'm confused. What do you mean by "a gcc-9 build"?
> 
> Did you try to build gcc-9-cross instead of gcc-8-cross, which is the
> package in the bug report?

gcc-9-cross, yes.

Bug#924746: RM: emacs25-common-non-dfsg -- RoQA; superseded by src:emacs-non-dfsg

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

For the unversioned emacs packages, the new source package for non-free
bits is emacs-non-dfsg, which covers emacs 26.


Andreas

Bug#924744: cockpit: fails to clean after build: find: './dist': No such file or directory

[Andreas Beckmann]

Source: cockpit
Version: 189-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

cockpit/experimental fails to build twice in a row because the clean
target fails after the package was build successfully:

 fakeroot debian/rules clean
dh clean
   dh_auto_clean
make -j3 distclean
make[1]: Entering directory '/build/cockpit-189'
test -z "cockpit-bridge" || rm -f cockpit-bridge
test -z "test-server" || rm -f test-server
test -z "doc/man/cockpit-bridge.1  doc/man/cockpit.1 doc/man/cockpit-desktop.1 
doc/man/cockpit-ws.8 doc/man/cockpit.conf.5 doc/man/pam_ssh_add.8 
doc/man/remotectl.8  valgrind-suppressions  dist/apps/stamp dist/das
test -z " cockpit-askpass cockpit-stub cockpit-pcp cockpit-ssh cockpit-ws 
cockpit-session" || rm -f  cockpit-askpass cockpit-stub cockpit-pcp cockpit-ssh 
cockpit-ws cockpit-session
find . -name '*.gc??' -delete
test -z "libcockpit-stub.a libcockpit-bridge.a  libcockpit-pcp.a 
libcockpit-common.a libwebsocket.a libcockpit-ssh.a libcockpit-ws.a libretest.a 
libpam_ssh_add.a" || rm -f libcockpit-stub.a libcockpit-bridge.a  li
test -z "test-paths test-rules test-pipe-channel test-packages test-peer 
test-dbus-meta test-fs test-metrics test-connect test-stream test-httpstream 
test-setup test-websocketstream test-process test-bridge test-r
test -z "remotectl" || rm -f remotectl
rm -f *.o
rm -f src/bridge/*.o
rm -f src/common/*.o
rm -f src/pam-ssh-add/*.o
rm -f src/retest/*.o
rm -f src/ssh/*.o
test -z "pkg/users/test-list-public-keys.log dist/base1/test-base64.log 
dist/base1/test-utf8.log dist/base1/test-events.log dist/base1/test-chan.log 
dist/base1/test-dbus.log dist/base1/test-dbus-address.log dist/b
rm -f src/websocket/*.o
rm -f src/ws/*.o
rm -f *.tab.c
test -z "pkg/users/test-list-public-keys.trs dist/base1/test-base64.trs 
dist/base1/test-utf8.trs dist/base1/test-events.trs dist/base1/test-chan.trs 
dist/base1/test-dbus.trs dist/base1/test-dbus-address.trs dist/b
test -z "doc/guide/version" || rm -f doc/guide/version
test . = "." || test -z "" || rm -f 
rm -f src/bridge/.deps/.dirstamp
test -z "test-suite.log" || rm -f test-suite.log
rm -f src/bridge/.dirstamp
find . -name '*.pyc' -delete
rm -f src/common/.deps/.dirstamp
rm -f config.h stamp-h1
rm -f src/common/.dirstamp
rm -rf dist/
rm -f src/pam-ssh-add/.deps/.dirstamp
rm -f src/pam-ssh-add/.dirstamp
rm -f src/retest/.deps/.dirstamp
rm -f src/retest/.dirstamp
rm -f src/ssh/.deps/.dirstamp
rm -f src/ssh/.dirstamp
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -f src/websocket/.deps/.dirstamp
rm -f cscope.out cscope.in.out cscope.po.out cscope.files
rm -f src/websocket/.dirstamp
rm -f src/ws/.deps/.dirstamp
rm -f src/ws/.dirstamp
test -z "./Makefile node_modules cockpit-cache-*.tar.xz " || rm -f ./Makefile 
node_modules cockpit-cache-*.tar.xz 
rm: cannot remove 'node_modules': Is a directory
make[1]: [Makefile:8857: distclean-generic] Error 1 (ignored)
find: './dist': No such file or directory
make[1]: *** [Makefile:9446: clean-local] Error 1
make[1]: Leaving directory '/build/cockpit-189'
dh_auto_clean: make -j3 distclean returned exit code 2
make: *** [debian/rules:18: clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit 
status 2


The dist directory tree has been deleted a few statements earlier ...


Andreas


cockpit_189-1_twice.log.gz
Description: application/gzip

Bug#924743: unblock: packagekit/1.1.12-5

[Matthias Klumpp]

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

Dear Release Team,
please consider unblocking packagekit 1.1.12-5.

This revision contains a lot of fixes compared to the one currently in testing:

* Add aptcc-frontend-locking.patch
  This implements APT frontend locking, which prevents other programs
  from stealing the dpkg lock in race conditions where apt(cc) has to
  release the lock in order to run dpkg.
  The APT team would really like to see this in Buster, as it prevents
a whole class of issues.

* Do not ship the GTK+2 plugin (Closes: #922118)
  We should never have shipped the GTK+2 plugin in a package the
explicitly mentions to be only for GTK+3. This restores the status quo
from a few PK releases where only the GTK+3 plugin was actually
present (the proper fix needs to happen upstream at some point).
This will allow the GNOME team and maybe other interested parties to
depend on the plugin without pulling in the legacy GTK+2.

* Remove Ubuntu-specific patch series, handle vendor config by
  conditionally installing it in d/rules (Closes: #915352)
  This change just makes the packagekit package more compliant to the
current policy.

* Add no-distupgrade.patch:
  - Disable GetDistroUpgrades() completely, it was partially
disabled before but still caused problems.
  There are tons of bug reports about this in forums and the Ubuntu
bugtracker, so we really want this in Buster. We also don't want
anyone to attempt a dist-upgrade with PackageKit for now.

* Add keep-ref-on-transaction-while-doing-polkit-call.patch
  - Avoids some log spam

* Add aptcc-use-correct-return-type-in-function.patch:
  - Fix function return type, which resolves packagekitd crash
when gnome-software launches, causing gnome-software to hang
(Closes: #917812, #922236)
  This is a quite serious bug that happens because of an error in PK's
code combined wiith some odd compiler optimizations.

I don't see much potential for regressions, as all of these changes
are quite self-contained.
The individual patches are all upstreamed and can be reviewed at
https://salsa.debian.org/pkgutopia-team/packagekit/tree/master/debian/patches
as well.

Thank you for considering!
Matthias Klumpp

unblock packagekit/1.1.12-5

Bug#924722: ktexteditor: symbols update for riscv64

[James Clarke]

On 16 Mar 2019, at 11:55, Aurelien Jarno  wrote:
> 
> Source: ktexteditor
> Version: 5.54.0-1
> Severity: normal
> Tags: patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> Hi,
> 
> ktexteditor currently fails to build on the riscv64 architecture due to
> differences on the symbols file, as can be seen on the following build
> log:
> 
> https://buildd.debian.org/status/fetch.php?pkg=ktexteditor=riscv64=5.54.0-1=1552467392=0
> 
> The attached patch update the symbols file. It looks like riscv64
> behaves the same way than armel and mips64el, but I do not necessarily
> understand why. It would be nice if you can include it in the next
> upload.

FWIW, the non-optional (non-template instantiation) lines are down to the
default __gnu_cxx::_Lock_policy, which is defined as follows for multi-threaded
code:

#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
 && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
  _S_atomic;
#else
  _S_mutex;
#endif

However, riscv64 only has _4 and _8, which I assume is due to it only having
lr.w and lr.d. But, at the same time, this is also true for MIPS, which still
defines _1 and _2, expanding them to a masked compare-and-swap, so it seems to
me that GCC should be doing the same on riscv64 and that this is really a GCC
bug. The LLVM backend for RISC-V supports this just like for MIPS (though the
Clang frontend doesn't currently let you use atomics). Aurelien, thoughts?

James

Bug#924742: unblock: appstream/0.12.6-1

[Matthias Klumpp]

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

Dear Release Team,
please consider unblocking appstream 0.12.6-1.

This minor release contains just two changes[1], one adds a few new
XML/YAML tags to the AppStream specification which allow releases to
denote the location of source code as well as binaries for the
respective release. The risk of breakage due to this feature is
minimal.
The other improves the search functionality of libappstream, which is
the change I would really like to see in Buster. A full revamp of
AppStream's fulltext search is planned for a future post-Buster
release, but the changes in this release are already a major
improvement and will help users find the things they are looking for
in software centers included in Debian.

Thank you for considering!
Matthias Klumpp

[1]: https://github.com/ximion/appstream/blob/master/NEWS#L5

unblock appstream/0.12.6-1

Bug#924741: RM: nbsphinx0.3 -- RoQA; superseded by nbsphinx (0.4.2+ds-1)

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

nbsphinx (0.4.2+ds-1) restored python2 support and builds
python-nbsphinx, again. So this package which was meant to retain an old
version supporting python2 is no longer needed

nbsphinx0.3 | 0.4.1+zero.3.5+ds-1 | source
python-nbsphinx0.3-doc | 0.4.1+zero.3.5+ds-1 | all


Andreas

Bug#924740: plasma-desktop: plasma activities preview fails with svg wallpapers

[Larus]

Package: plasma-desktop
Version: 4:5.14.5.1-1
Severity: minor

Dear Maintainer,

when choosing a SVG-wallpaper like the default in debian, the preview/thumbnail
of the activity panel shows no background.
When turning the same one in a "normal" image format like png, preview suceeds.



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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.14.5-1
ii  kactivitymanagerd5.14.5-1
ii  kde-cli-tools4:5.14.5-1
ii  kded55.54.0-1
ii  kio  5.54.1-1
ii  kpackagetool55.54.0-1
ii  libappstreamqt2  0.12.6-1
ii  libc62.28-8
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-2
ii  libkf5activities55.54.0-1
ii  libkf5activitiesstats1   5.54.0-1
ii  libkf5archive5   5.54.0-1
ii  libkf5auth5  5.54.0-2
ii  libkf5baloo5 5.54.0-1
ii  libkf5codecs55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.54.0-1
ii  libkf5configgui5 5.54.0-1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5declarative5   5.54.0-1
ii  libkf5emoticons-bin  5.54.0-1
ii  libkf5emoticons5 5.54.0-1
ii  libkf5globalaccel-bin5.54.0-1
ii  libkf5globalaccel5   5.54.0-1
ii  libkf5guiaddons5 5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5itemmodels55.54.0-1
ii  libkf5itemviews5 5.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kcmutils5  5.54.0-1
ii  libkf5kdelibs4support5   5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5newstuff5  5.54.0-2
ii  libkf5notifications5 5.54.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5package5   5.54.0-1
ii  libkf5parts5 5.54.0-1
ii  libkf5people55.54.0-1
ii  libkf5peoplewidgets5 5.54.0-1
ii  libkf5plasma55.54.0-1
ii  libkf5plasmaquick5   5.54.0-1
ii  libkf5quickaddons5   5.54.0-1
ii  libkf5runner55.54.0-1
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5solid5 5.54.0-1
ii  libkf5sonnetui5  5.54.0-1
ii  libkf5wallet-bin 5.54.0-1
ii  libkf5wallet55.54.0-1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libkfontinst54:5.14.5.1-1
ii  libkfontinstui5  4:5.14.5.1-1
ii  libkworkspace5-5 4:5.14.5.1-1
ii  libphonon4qt5-4  4:4.10.2-1
ii  libqt5concurrent55.11.3+dfsg-5
ii  libqt5core5a 5.11.3+dfsg-5
ii  libqt5dbus5  5.11.3+dfsg-5
ii  libqt5gui5   5.11.3+dfsg-5
ii  libqt5network5   5.11.3+dfsg-5
ii  libqt5printsupport5  5.11.3+dfsg-5
ii  libqt5qml5   5.11.3-4
ii  libqt5quick5 5.11.3-4
ii  libqt5quickwidgets5  5.11.3-4
ii  libqt5sql5   5.11.3+dfsg-5
ii  libqt5svg5   5.11.3-2
ii  libqt5widgets5   5.11.3+dfsg-5
ii  libqt5x11extras5 5.11.3-2
ii  libqt5xml5  

Bug#924738: unblock: directfb/1.7.7-9

[Andreas Beckmann]

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

Please unblock package directfb

trivial FTBFS fix on armel/armhf: add missing #include
i could reproduce the problem on armhf (didn't try armel)

unblock directfb/1.7.7-9

Andreas
diff -Nru directfb-1.7.7/debian/changelog directfb-1.7.7/debian/changelog
--- directfb-1.7.7/debian/changelog 2018-03-29 18:33:45.0 +0200
+++ directfb-1.7.7/debian/changelog 2019-03-16 17:29:57.0 +0100
@@ -1,3 +1,10 @@
+directfb (1.7.7-9) unstable; urgency=medium
+
+  * QA upload.
+  * Add missing #include to ensure makedev() is defined.  (Closes: #924327)
+
+ -- Andreas Beckmann   Sat, 16 Mar 2019 17:29:57 +0100
+
 directfb (1.7.7-8) unstable; urgency=medium
 
   * QA upload.
@@ -115,7 +122,7 @@
 
   * Non-maintainer upload.
   * Merge from 1.2.10.0-5.1:
-- d/control: drop build depend on libts-dev. 
+- d/control: drop build depend on libts-dev.
 - d/libdirectfb-1.4-0.install.*: drop install libdirectfb_tslib.so
 - d/libdirectfb-dev.install.*: drop install libdirectfb_tslib.a
   * Merge from 1.2.10.0-5:
diff -Nru directfb-1.7.7/debian/patches/94_fix_mknod.patch 
directfb-1.7.7/debian/patches/94_fix_mknod.patch
--- directfb-1.7.7/debian/patches/94_fix_mknod.patch2018-02-03 
15:24:10.0 +0100
+++ directfb-1.7.7/debian/patches/94_fix_mknod.patch2019-03-16 
09:44:37.0 +0100
@@ -1,14 +1,12 @@
 From: Debian Multimedia Maintainers
  
 Date: Thu, 16 Mar 2017 20:48:20 +0100
-Subject: _fix_mknod
+Subject: fix mknod and makedev
 
 ---
  gfxdrivers/davinci/davinci_c64x.c | 2 ++
  1 file changed, 2 insertions(+)
 
-diff --git a/gfxdrivers/davinci/davinci_c64x.c 
b/gfxdrivers/davinci/davinci_c64x.c
-index 431ffdd..420b567 100644
 --- a/gfxdrivers/davinci/davinci_c64x.c
 +++ b/gfxdrivers/davinci/davinci_c64x.c
 @@ -37,6 +37,8 @@
@@ -16,7 +14,7 @@
  #include 
  #include 
 +#include 
-+
++#include 
  #include 
  
  #include 

Bug#923980: claws-mail-gdata-plugin: gdata plugin crashes after update to 3.17.3-1

[Ricardo Mones]

control: severity -1 important
control: tags -1 confirmed fixed-upstream

Hi Christian,

On Thu, 07 Mar 2019 22:10:53 +0100
Christian Beier  wrote:

> Package: claws-mail-gdata-plugin
> Version: 3.17.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I recently upgraded from stretch to buster, now claws-mail with gdata
> plugin enabled segfaults.
> 
> Runs fine without gdata plugin enabled.
> 
> Also runs fine with `LANG=C claws-mail`
> 
> It seems the locale makes a difference, please see attached backtrace for
> the default de_DE.UTF-8

Thanks for reporting! I've fixed this upstream¹, but hopefully will provide
an updated package soon.

best regards,

¹
https://git.claws-mail.org/?p=claws.git;a=commitdiff;h=0ffa910327b3476aafec74013d69af98dd9fb5e2
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «Conscious is when you are aware of something and conscience is when 
 you wish you weren't.»


pgpSjRWPmOD9J.pgp
Description: Firma digital OpenPGP

Bug#924736: Acknowledgement (zsh 5.7.1 segfaults when three setopt options are in play)

[wesleys]

on #zsh there was some confusion about the reproduction path
` #` should be typed *without* the backticks. Spaces are hard to show on a 
text only medium.

FWIW, it seems like an upstream bug, I can also reproduce it on Arch

Cheers,
Wesley

Bug#924704: bumblebee-nvidia: nvidia-driver 410 doesn't appear to allow the unloading of the nvidia module

[Danfun360]

The graphics card in my laptop is an Nvidia Geforce GTX 1050.

On Sat, Mar 16, 2019 at 7:20 AM Luca Boccassi 
wrote:

> What Nvidia card does your laptop have?
>
> On Sat, 16 Mar 2019, 03:42 Daniel O. 
>> Package: bumblebee-nvidia
>> Version: 3.2.1-20
>> Severity: grave
>> Justification: renders package unusable
>>
>> Dear Maintainer, I write this bug report because this bumblebee/bumblebeed
>> doesn't work as it should.
>>
>>* What led up to the situation? Bumblebee used to work correctly when
>> the
>> nvidia driver was at 390. A few days ago it was upgraded to 410. At the
>> time I
>> was running Debian Buster (testing as of this writing). That's where
>> things
>> started to get problematic. It appears that the nvidia module couldn't be
>> unloaded or something. bbswitch reported as "ON" without optirun, and as
>> the
>> nvidia drivers were considered in use, I was unable to unbind the nvidia
>> driver
>> for VGA Passthrough as I had been doing before.
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)? I uninstalled every bumblebee and nvidia package. I
>> then
>> reinstalled everything. No luck. I then uninstalled everything and went
>> for the
>> legacy 390 package. Unfortunately there were problems with that:
>> nvidia-cuba-
>> toolkit and nvidia-cuba-dev require the latest nvidia driver installed.
>> On top
>> of that, bumblebee refused to see the legacy 390 drivers as a glx
>> alternative.
>> I uninstalled all the nvidia stuff again, switched to Debian Sid, and
>> installed
>> the latest nvidia drivers again (they were slightly more up to date on
>> Sid than
>> in Buster). Still no change.
>>* What was the outcome of this action? Bumblebee should be able to
>> blacklist
>> the nvidia driver and isolate it from the operating system in such a way
>> that
>> the system would run on the integrated GPU and run the discrete GPU for
>> applications when called for.
>>* What outcome did you expect instead? The nvidia driver is not
>> blacklisted,
>> and the discrete GPU is in control.
>>
>> On a different note, I tried posting a bug report upstream. It has some
>> information this report might not have (vice versa is definitely the case,
>> unfortunately). It can be found at https://github.com/Bumblebee-
>> Project/Bumblebee/issues/1023
>>
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
>> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>> TAINT_UNSIGNED_MODULE
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages bumblebee-nvidia depends on:
>> ii  bumblebee   3.2.1-20
>> ii  glx-alternative-nvidia  0.9.1
>> ii  nvidia-driver   410.104-1
>> ii  nvidia-kernel-dkms  410.104-1
>>
>> bumblebee-nvidia recommends no packages.
>>
>> bumblebee-nvidia suggests no packages.
>>
>> -- no debconf information
>>
>> ___
>> pkg-nvidia-devel mailing list
>> pkg-nvidia-de...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-nvidia-devel
>
>

Bug#924699: CANCEL / REMOVE THIS BUG-REPORT

[Mattia Rizzolo]

On Sat, Mar 16, 2019 at 08:54:32AM +0100, Brian Wengel wrote:
> (how do you remove a bug? Couldn't find anything about it on
> https://wiki.debian.org/HowtoUseBTS and
> https://www.debian.org/Bugs/Reporting)

You can't remove a bug, only close it.
To close a bug, mail -cl...@bugs.debian.org, i.e.
924699-cl...@bugs.debian.org.

However, if you think there is a issue (from your description, I bet
something related to pam), please reassign it to an appropriate package.
For an initial debug, I'd reassign it to util-linux.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#924737: unblock: libbpp-seq-omics/2.4.1-3

[Andreas Tille]

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

Please unblock package libbpp-seq-omics


libbpp-seq-omics (2.4.1-3) unstable; urgency=medium

  * Rebuild for new version of gcc to fix symbols
Closes: #924734

 -- Andreas Tille   Sat, 16 Mar 2019 19:07:21 +0100



unblock libbpp-seq-omics/2.4.1-3

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libbpp-seq-omics-2.4.1/debian/changelog 
libbpp-seq-omics-2.4.1/debian/changelog
--- libbpp-seq-omics-2.4.1/debian/changelog 2019-01-06 17:30:24.0 
+0100
+++ libbpp-seq-omics-2.4.1/debian/changelog 2019-03-16 19:07:21.0 
+0100
@@ -1,3 +1,10 @@
+libbpp-seq-omics (2.4.1-3) unstable; urgency=medium
+
+  * Rebuild for new version of gcc to fix symbols
+Closes: #924734
+
+ -- Andreas Tille   Sat, 16 Mar 2019 19:07:21 +0100
+
 libbpp-seq-omics (2.4.1-2) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff -Nru libbpp-seq-omics-2.4.1/debian/libbpp-seq-omics3.symbols.amd64 
libbpp-seq-omics-2.4.1/debian/libbpp-seq-omics3.symbols.amd64
--- libbpp-seq-omics-2.4.1/debian/libbpp-seq-omics3.symbols.amd64   
2019-01-06 17:30:24.0 +0100
+++ libbpp-seq-omics-2.4.1/debian/libbpp-seq-omics3.symbols.amd64   
2019-03-16 19:07:21.0 +0100
@@ -23,7 +23,6 @@
  _ZN3bpp11MafSequenceD0Ev@Base 2.4.1
  _ZN3bpp11MafSequenceD1Ev@Base 2.4.1
  
_ZN3bpp11VectorTools11vectorUnionINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcESt6vectorIT_SaIS9_EERKS8_ISB_SaISB_EE@Base
 2.4.1
- _ZN3bpp11VectorTools15shannonDiscreteIidEET0_RKSt6vectorIT_SaIS4_EEd@Base 
2.4.1
  
_ZN3bpp11VectorTools18vectorIntersectionINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcESt6vectorIT_SaIS9_EERKSB_SD_@Base
 2.4.1
  _ZN3bpp12EdSymbolList11getListenerEm@Base 2.4.1
  
_ZN3bpp12EdSymbolList20afterSequenceChangedERKNS_22SymbolListEditionEventE@Base 
2.4.1
@@ -39,6 +38,7 @@
  _ZN3bpp12EdSymbolList7shuffleEv@Base 2.4.1
  _ZN3bpp12EdSymbolListixEm@Base 2.4.1
  _ZN3bpp12SequenceMaskC1ERKSt6vectorIbSaIbEEb@Base 2.4.1
+ _ZN3bpp12SequenceMaskD0Ev@Base 2.4.1
  _ZN3bpp13AlphabetStateD0Ev@Base 2.4.1
  _ZN3bpp13AlphabetStateD1Ev@Base 2.4.1
  _ZN3bpp13BasicSequenceD0Ev@Base 2.4.1
@@ -122,6 +122,8 @@
  _ZN3bpp19OutOfRangeExceptionD2Ev@Base 2.4.1
  _ZN3bpp19VectorSiteContainerD0Ev@Base 2.4.1
  _ZN3bpp19VectorSiteContainerD1Ev@Base 2.4.1
+ 
_ZN3bpp20AbstractCoreSequence11setCommentsERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE@Base
 2.4.1
+ 
_ZN3bpp20AbstractCoreSequence7setNameERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
  
_ZN3bpp20BasicSequenceFeature12getAttributeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
  
_ZN3bpp20BasicSequenceFeature12setAttributeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_@Base
 2.4.1
  
_ZN3bpp20BasicSequenceFeature13setSequenceIdERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
@@ -345,6 +347,10 @@
  _ZNK3bpp12EdSymbolList4sizeEv@Base 2.4.1
  _ZNK3bpp12EdSymbolList5cloneEv@Base 2.4.1
  _ZNK3bpp12EdSymbolListixEm@Base 2.4.1
+ _ZNK3bpp12SequenceMask11isRemovableEv@Base 2.4.1
+ _ZNK3bpp12SequenceMask11isValidWithERKNS_22SequenceWithAnnotationEb@Base 2.4.1
+ _ZNK3bpp12SequenceMask7getTypeB5cxx11Ev@Base 2.4.1
+ _ZNK3bpp12SequenceMask8isSharedEv@Base 2.4.1
  _ZNK3bpp13AlphabetState5cloneEv@Base 2.4.1
  _ZNK3bpp13CodonAlphabet23getUnknownCharacterCodeEv@Base 2.4.1
  
_ZNK3bpp14LetterAlphabet16isCharInAlphabetERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
@@ -387,6 +393,8 @@
  _ZNK3bpp19AbstractMafIterator9isVerboseEv@Base 2.4.1
  
_ZNK3bpp19MafStatisticsResult8getValueERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
  
_ZNK3bpp19MafStatisticsResult8hasValueERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
+ _ZNK3bpp20AbstractCoreSequence11getCommentsB5cxx11Ev@Base 2.4.1
+ _ZNK3bpp20AbstractCoreSequence7getNameB5cxx11Ev@Base 2.4.1
  _ZNK3bpp20BasicSequenceFeature10isStrandedEv@Base 2.4.1
  
_ZNK3bpp20BasicSequenceFeature12getAttributeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
  _ZNK3bpp20BasicSequenceFeature12isIncludedInERKNS_8SeqRangeE@Base 2.4.1
@@ -456,9 +464,7 @@
  _ZNK3bpp6NumberIjE8toStringB5cxx11Ev@Base 2.4.1
  _ZNK3bpp8MafBlock11getSequenceEm@Base 2.4.1
  _ZNK3bpp8MafBlock14getDescriptionB5cxx11Ev@Base 2.4.1
- _ZNK3bpp8MafBlock14getSpeciesListB5cxx11Ev@Base 2.4.1
  
_ZNK3bpp8MafBlock21getSequenceForSpeciesERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
- 

Bug#924736: zsh 5.7.1 segfaults when three setopt options are in play

[Wesley Schwengle]

Package: zsh
Version: 5.7.1-1
Severity: important

Dear Maintainer,

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

Have a zshrc with the following setopts:

setopt hist_reduce_blanks
setopt hist_ignore_space
setopt interactivecomments

* Run zsh -f
* Now enter ` #`
* You get a command not found error
* Now source your zshrc
* Again entery ` #`
* Segfault

I've reproduced it with a docker image from debian testing.
https://gist.github.com/waterkip/ab532e8dc65ad948046b6848dcfacffa

It does work on Debian stable (zsh 5.3.1).

Dockerfile contents:

FROM debian:testing
WORKDIR /root
RUN apt-get update && apt-get install --no-install-recommends -y zsh
COPY zsh/.zsh/minimal-zshrc .zshrc

$ dpkg -l zsh
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  zsh5.7.1-1  amd64shell with lots of features

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version Architecture Description
+++-==-===--
ii  curl   7.64.0-1amd64command line tool 
for transferring data with URL syntax
ii  docker-ce-cli  5:18.09.3~3-0~debian-buster amd64Docker CLI: the 
open-source application container engine
ii  mpv0.29.1-1amd64video player based 
on MPlayer/mplayer2
ii  pulseaudio 12.2-4  amd64PulseAudio sound 
server
ii  systemd241-1   amd64system and service 
manager
ii  udev   241-1   amd64/dev/ and hotplug 
management daemon
ii  vlc-bin3.0.6-1 amd64binaries from VLC
ii  youtube-dl 2019.01.17-1all  downloader of 
videos from YouTube and other sites

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 zsh depends on:
ii  libc6   2.28-8
ii  libcap2 1:2.25-2
ii  libtinfo6   6.1+20181013-2
ii  zsh-common  5.7.1-1

Versions of packages zsh recommends:
ii  libc6 2.28-8
ii  libncursesw6  6.1+20181013-2
ii  libpcre3  2:8.39-11

Versions of packages zsh suggests:
pn  zsh-doc  

-- no debconf information

Bug#924735: debian-history: [INTL:pt] Updated Portuguese translation

[Américo Monteiro]

Package: debian-history
Version: 
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for  debian-history messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


debian-history_pt.po.gz
Description: application/gzip

Bug#924325: gcc-8-cross: FTBFS for unknown reasons

[Santiago Vila]

On Sat, Mar 16, 2019 at 05:59:16PM +0100, Matthias Klose wrote:
> On 11.03.19 18:47, Santiago Vila wrote:
> > On Mon, Mar 11, 2019 at 06:34:18PM +0100, Matthias Klose wrote:
> > 
> >> I have no clue, I have never seen that before, and it seems to work fine 
> >> on the
> >> buildds, and in the cross-toolchain-base* package's autopkg test.  
> >> Starting here
> >> a build with -j1 to see if it's reproducible.
> >>
> >> Is this seen with gcc-7-cross and gcc-9-cross as well?
> > 
> > It happened to me with the (now removed) gcc-7-cross as well, yes.
> > In case it helps, these are the logs I had in my last backup:
> > 
> > https://people.debian.org/~sanvila/build-logs/gcc-7-cross/
> > 
> > (Never tried gcc-9-cross yet because my usual target is testing and
> > sometimes sid).
> 
> a gcc-9 build with -j1 succeeds.  I'm not spending more time on this.

I'm confused. What do you mean by "a gcc-9 build"?

Did you try to build gcc-9-cross instead of gcc-8-cross, which is the
package in the bug report?

Or you mean that you tried to build gcc-8-cross using gcc-9 as the C compiler?

Thanks.

Bug#919929: python-scipy: autopkgtest fails (Re: bug#919929)

[Drew Parsons]

Incidentally, the matrix DeprecationWarnings related to the test 
failures seem to have started with the switch of default python3 from 
3.6 to 3.7, 21 Nov 2018. Not from numpy as such (certainly not numpy 
1.16).


Possibly due to https://github.com/python/cpython/pull/4458 
(https://bugs.python.org/issue31975) which landed in 3.7.0 alpha 4.

Bug#924325: gcc-8-cross: FTBFS for unknown reasons

[Matthias Klose]

On 11.03.19 18:47, Santiago Vila wrote:
> On Mon, Mar 11, 2019 at 06:34:18PM +0100, Matthias Klose wrote:
> 
>> I have no clue, I have never seen that before, and it seems to work fine on 
>> the
>> buildds, and in the cross-toolchain-base* package's autopkg test.  Starting 
>> here
>> a build with -j1 to see if it's reproducible.
>>
>> Is this seen with gcc-7-cross and gcc-9-cross as well?
> 
> It happened to me with the (now removed) gcc-7-cross as well, yes.
> In case it helps, these are the logs I had in my last backup:
> 
> https://people.debian.org/~sanvila/build-logs/gcc-7-cross/
> 
> (Never tried gcc-9-cross yet because my usual target is testing and
> sometimes sid).

a gcc-9 build with -j1 succeeds.  I'm not spending more time on this.

Matthias

Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?

[Niko Tyni]

On Sat, Mar 16, 2019 at 12:29:07PM +0200, Niko Tyni wrote:
> > > This will cause temporary uninstallability of libmarc-charset-perl in
> > > sid so the uploads should be coordinated a bit. I guess I can do both
> > > if needed.
> > 
> > Thanks.
> > (If it helps I can also upload libmarc-charset-perl but maybe the
> > coordination effort is higher than if you just go ahead :))
> 
> Yeah, thanks. I'll try to handle this myself.

Just uploaded perl_5.28.1-5 and pushed the planned libmarc-charset-perl
changes to salsa.

Will upload libmarc-charset-perl later when the new perl is built and
available on the mirrors. Fine by me if someone else beats me to it.
-- 
Niko

Bug#885440: Библии да! Конституции нет! --------- Bible Yes, Constitution No.newsletter dated 13-27-52

[Pr.Tupirani]

ПОКОЛЕНИЕ ИИСУСА ХРИСТА

ПОКОЛЕНИЕ МУЧЕНИЦА
учить умирать
за Иисуса Христа

ЭТО МИНИСТЕРСТВО ГОЛОСА ВОССТАНОВЛЕНИЯ, ТОЛЬКО ДВЕРЬ ДЛЯ РАПТУРЫ ЦЕРКВИ:
http://bit.ly/thelastelijah-ru
PR. ТУПИРАНИ, ПОСЛЕДНИЙ ЭЛИЯ.
БИБЛИЯ ДА! КОНСТИТУЦИЯ НЕ!
2070: ИИСУС ВОЗВРАЩАЕТСЯ.
МЫ НЕ МАСОНОВ!
“Вот, Я пошлю к вам Илию пророка пред наступлением дня Господня, великого и 
страшного." (Малахия 4:5)
“Иисус сказал им в ответ: правда, Илия должен придти прежде и устроить всё;" 
(Матфея 17:11)
GENERATION JESUS CHRIST

GENERATION OF MARTYRS
TEACHING TO DIE
FOR JESUS CHRIST.



This is the ministry of the voice of restoration, the unique door for the 
rapture of the church:
http://restauracao.net/home.html


Pr. Tupirani, the last Elijah.
Bible Yes! Constitution No!
2070: Jesus will return.
We aren't freemasons!

 

 
“Behold, I will send you Elijah the prophet before the coming of the great and 
dreadful day of the Lord." (Malachi 4:5)

“Elijah truly shall first come and restore all things." (Matthew 17:11)
 
 
 
62898100
 
 
13-27-52

Bug#924734: libbpp-seq-omics: FTBFS (dh_makeshlibs fails)

[Santiago Vila]

Package: src:libbpp-seq-omics
Version: 2.4.1-2
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_autoreconf -a
   dh_auto_configure -a
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ..
-- The CXX compiler identification is GNU 8.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- bpp-core 4.1.0 found:

[... snipped ...]

  _ZTv0_n24_N3bpp13BasicSequenceD0Ev@Base 2.4.1
@@ -1134,7 +1150,9 @@
  
_ZTv0_n48_N3bpp25SimpleMafStatisticsResult8setValueERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi@Base
 2.4.1
  _ZTv0_n48_N3bpp36CsvStatisticsOutputIterationListener14iterationStopsEv@Base 
2.4.1
  _ZTv0_n48_NK3bpp12EdSymbolList11getAlphabetEv@Base 2.4.1
+ _ZTv0_n48_NK3bpp12SequenceMask11isRemovableEv@Base 2.4.1-2
  _ZTv0_n48_NK3bpp15SequenceQuality11isRemovableEv@Base 2.4.1
+ _ZTv0_n48_NK3bpp20AbstractCoreSequence7getNameB5cxx11Ev@Base 2.4.1-2
  _ZTv0_n48_NK3bpp21AbstractMafStatistics9getResultEv@Base 2.4.1
  _ZTv0_n48_NK3bpp22SequenceWithAnnotation7getNameB5cxx11Ev@Base 2.4.1
  _ZTv0_n48_NK3bpp25AbstractSequenceContainer11getAlphabetEv@Base 2.4.1
@@ -1144,6 +1162,7 @@
  
_ZTv0_n56_N3bpp16GtfFeatureReader17getFeaturesOfTypeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERNS_18SequenceFeatureSetE@Base
 2.4.1
  _ZTv0_n56_N3bpp17SiteMafStatistics7computeERKNS_8MafBlockE@Base 2.4.1
  
_ZTv0_n56_N3bpp19AbstractMafIterator20addIterationListenerEPNS_17IterationListenerE@Base
 2.4.1
+ 
_ZTv0_n56_N3bpp20AbstractCoreSequence7setNameERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1-2
  
_ZTv0_n56_N3bpp21BedGraphFeatureReader17getFeaturesOfTypeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERNS_18SequenceFeatureSetE@Base
 2.4.1
  
_ZTv0_n56_N3bpp22SequenceWithAnnotation7setNameERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
  _ZTv0_n56_N3bpp25PolymorphismMafStatistics7computeERKNS_8MafBlockE@Base 2.4.1
@@ -1153,6 +1172,7 @@
  
_ZTv0_n56_N3bpp34SiteFrequencySpectrumMafStatistics7computeERKNS_8MafBlockE@Base
 2.4.1
  
_ZTv0_n56_N3bpp37FourSpeciesPatternCountsMafStatistics7computeERKNS_8MafBlockE@Base
 2.4.1
  _ZTv0_n56_NK3bpp12EdSymbolList4sizeEv@Base 2.4.1
+ _ZTv0_n56_NK3bpp12SequenceMask8isSharedEv@Base 2.4.1-2
  _ZTv0_n56_NK3bpp15BasicSymbolList4sizeEv@Base 2.4.1
  _ZTv0_n56_NK3bpp15SequenceQuality8isSharedEv@Base 2.4.1
  
_ZTv0_n64_N3bpp16GffFeatureReader21getFeaturesOfSequenceERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERNS_18SequenceFeatureSetE@Base
 2.4.1
@@ -1160,12 +1180,14 @@
  
_ZTv0_n64_N3bpp21BedGraphFeatureReader21getFeaturesOfSequenceERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERNS_18SequenceFeatureSetE@Base
 2.4.1
  _ZTv0_n64_N3bpp22SequenceWithAnnotation10setContentERKSt6vectorIiSaIiEE@Base 
2.4.1
  _ZTv0_n64_NK3bpp17SiteMafStatistics16getSupportedTagsB5cxx11Ev@Base 2.4.1
+ _ZTv0_n64_NK3bpp20AbstractCoreSequence11getCommentsB5cxx11Ev@Base 2.4.1-2
  _ZTv0_n64_NK3bpp22SequenceWithAnnotation11getCommentsB5cxx11Ev@Base 2.4.1
  _ZTv0_n64_NK3bpp25PolymorphismMafStatistics16getSupportedTagsB5cxx11Ev@Base 
2.4.1
  
_ZTv0_n64_NK3bpp28CharacterCountsMafStatistics16getSupportedTagsB5cxx11Ev@Base 
2.4.1
  
_ZTv0_n64_NK3bpp30SequenceDiversityMafStatistics16getSupportedTagsB5cxx11Ev@Base
 2.4.1
  
_ZTv0_n64_NK3bpp34SiteFrequencySpectrumMafStatistics16getSupportedTagsB5cxx11Ev@Base
 2.4.1
  
_ZTv0_n64_NK3bpp37FourSpeciesPatternCountsMafStatistics16getSupportedTagsB5cxx11Ev@Base
 2.4.1
+ 
_ZTv0_n72_N3bpp20AbstractCoreSequence11setCommentsERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE@Base
 2.4.1-2
  
_ZTv0_n72_N3bpp22SequenceWithAnnotation10setContentERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE@Base
 2.4.1
  
_ZTv0_n72_N3bpp22SequenceWithAnnotation11setCommentsERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE@Base
 2.4.1
  _ZTv0_n72_NK3bpp5Fastq12nextSequenceERSiRNS_8SequenceE@Base 2.4.1
dh_makeshlibs: failing due to earlier errors
make: *** [debian/rules:10: binary-arch] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned 
exit status 2


(The above is just how the build ends and not necessarily the most relevant 

Bug#919793: prospector won't run at all

[VA]

found 919793 0.12.7-2.1
thanks

prospector is still completely unusable in latest package, but with 
different errors.


Without pyroma installed:

Traceback (most recent call last):
  File "/usr/bin/prospector", line 11, in 
load_entry_point('prospector==0.12.7', 'console_scripts', 
'console_script')()

  File "/usr/share/prospector/prospector/run.py", line 165, in main
prospector.execute()
  File "/usr/share/prospector/prospector/run.py", line 53, in execute
for tool in self.config.get_tools(found_files):
  File "/usr/share/prospector/prospector/config/__init__.py", line 45, 
in get_tools

config_result = tool.configure(self, found_files)
  File "/usr/share/prospector/prospector/tools/pylint/__init__.py", 
line 172, in configure

linter.reset_options()
  File "/usr/share/prospector/prospector/tools/pylint/linter.py", line 
30, in reset_options

OptionsManagerMixIn.__init__(self, usage=PyLinter.__doc__, quiet=True)
TypeError: __init__() got an unexpected keyword argument 'quiet'

And with pyroma installed:

Traceback (most recent call last):
  File "/usr/bin/prospector", line 11, in 
load_entry_point('prospector==0.12.7', 'console_scripts', 
'console_script')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
489, in load_entry_point

return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
2793, in load_entry_point

return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
2411, in load

return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
2417, in resolve

module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/share/prospector/prospector/run.py", line 8, in 
from prospector import blender, postfilter, tools
  File "/usr/share/prospector/prospector/tools/__init__.py", line 48, 
in 

'pyroma': _optional_tool('pyroma'),
  File "/usr/share/prospector/prospector/tools/__init__.py", line 29, 
in _optional_tool

tool_package = __import__(package_name, fromlist=[tool_class_name])
  File "/usr/share/prospector/prospector/tools/pyroma/__init__.py", 
line 27, in 

ratings.PEP386Version: 'PYR04',
AttributeError: module 'pyroma.ratings' has no attribute 'PEP386Version'

Bug#924733: pyqwt3d: FTBFS (SIP failed to generate the C++ code)

[Santiago Vila]

Package: src:pyqwt3d
Version: 0.1.8-4
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh_testdir
export QTDIR=/usr/share/qt5
set -e ;\
for py in 3.7 ; do \
mkdir -p build/py$py-qt5; \
cp -Rl `ls . |grep -v build|grep -v debian` build/py$py-qt5; \
(cd build/py$py-qt5/configure;\
python$py configure-qt5.py -5 -I /usr/include/qwtplot3d 
--extra-libs=qwtplot3d-qt5 -D GL2PS_HAVE_ZLIB); \
done
sip: Deprecation warning: ../sip/OpenGL_Qt5_Module.sip:31: %Module version 
number should be specified using the 'version' argument
sip: Deprecation warning: ../sip/Qwt3D_Qt5_Module.sip:31: %Module version 
number should be specified using the 'version' argument
sip: ../sip/types.sip:5: syntax error
Command line options:
{'debug': False,
 'disable_numarray': False,
 'disable_numeric': False,
 'disable_numpy': False,
 'excluded_features': [],
 'extra_cflags': [],
 'extra_cxxflags': [],
 'extra_defines': ['GL2PS_HAVE_ZLIB'],
 'extra_include_dirs': ['/usr/include/qwtplot3d'],
 'extra_lflags': [],
 'extra_lib_dirs': [],
 'extra_libs': ['qwtplot3d-qt5'],
 'jobs': '',
 'module_install_path': '',
 'modules': [],
 'qt': 5,
 'qwtplot3d_sources': '',
 'sip_include_dirs': ['-I ../sip'],
 'subdirs': [],
 'timelines': [],
 'trace': '',
 'zlib_sources': ''}

Found SIP-4.19.14.

Found 'posix' operating system:
3.7.2+ (default, Feb 27 2019, 15:41:59) 
[GCC 8.2.0]

Found NumPy-1.16.1.

Setup the OpenGL package build.
-n sip -t WS_X11 -t Qt_5_11_3
sip invokation:
('/usr/bin/sip -I /usr/share/sip/PyQt5 -n sip -t WS_X11 -t Qt_5_11_3 -b '
 'tmp-OpenGL_Qt5/OpenGL_Qt5.sbf -c tmp-OpenGL_Qt5   '
 '../sip/OpenGL_Qt5_Module.sip')
Copy tmp-OpenGL_Qt5/sipOpenGLcmodule.cpp -> OpenGL_Qt5/sipOpenGLcmodule.cpp.
Copy tmp-OpenGL_Qt5/sipAPIOpenGL.h -> OpenGL_Qt5/sipAPIOpenGL.h.
Copy tmp-OpenGL_Qt5/OpenGL_Qt5.sbf -> OpenGL_Qt5/OpenGL_Qt5.sbf.
3 file(s) lazily copied.
Setup the Qwt3D package build.
Extended options:
{'debug': False,
 'disable_numarray': False,
 'disable_numeric': False,
 'disable_numpy': False,
 'excluded_features': ['-x HAS_QT3 -x HAS_QT4'],
 'extra_cflags': [],
 'extra_cxxflags': [],
 'extra_defines': ['GL2PS_HAVE_ZLIB', 'HAS_NUMPY'],
 'extra_include_dirs': ['/usr/include/qwtplot3d',
'/usr/include/python3.7m',
'/usr/lib/python3/dist-packages/numpy/core/include',
'/usr/include/x86_64-linux-gnu/qt5/Qt',
'/usr/include/x86_64-linux-gnu/qt5/QtCore',
'/usr/include/x86_64-linux-gnu/qt5/QtGui',
'/usr/include/x86_64-linux-gnu/qt5/QtWidgets',
'/usr/include/x86_64-linux-gnu/qt5/QtOpenGL',
'/usr/include/x86_64-linux-gnu/qt5'],
 'extra_lflags': [],
 'extra_lib_dirs': [],
 'extra_libs': ['qwtplot3d-qt5'],
 'jobs': '',
 'module_install_path': '/usr/lib/python3.7/dist-packages/PyQt5/Qwt3D',
 'modules': [],
 'opengl': 'OpenGL_Qt5',
 'qt': 5,
 'qwt3d': 'Qwt3D_Qt5',
 'qwtplot3d_sources': '',
 'sip_include_dirs': ['-I ../sip'],
 'subdirs': ['Qwt3D_Qt5', 'OpenGL_Qt5'],
 'timelines': [],
 'trace': '',
 'zlib_sources': ''}

sip invokation:
('/usr/bin/sip -I /usr/share/sip/PyQt5 -n sip -t WS_X11 -t Qt_5_11_3 -b '
 'tmp-Qwt3D_Qt5/qwt3d.sbf -c tmp-Qwt3D_Qt5   -I ../sip -x HAS_QT3 -x HAS_QT4 '
 '../sip/Qwt3D_Qt5_Module.sip')

SIP failed to generate the C++ code.
make: *** [debian/rules:25: configure-stamp] Error 1
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -A"
and it also fails here:

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

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#924732: unblock: matrix-synapse/0.99.2-2

[Andrej Shadura]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package matrix-synapse

This upload fixes these issues:

* #923573: when installing synapse with sysvinit and a strict umask, the
  signing key will be generated with owner/mode making it inaccessible
  for the system user synapse runs as. The change is to squash owner/mode
  to the expected values.
* #923574: No longer enable webclient by default, since it’s been
  recently removed, to eliminate a warning.
* #923586: Print a warning when the configuration file setting the
  server name is missing. Previously, the init script would just exit
  with no diagnostic, leaving the users puzzled.

Also, this upload updates NEWS with an important detail regarding
upcoming removal of self-signed certificates support, and slightly
changes formatting in the init script.

Please see the attached diff for more details.

unblock matrix-synapse/0.99.2-2

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAlyNHrkUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdJ4Lwf+MzBtXH8b9pfpDVZYL9CZIRbfhmQH
1B8jMSs/ndZnRztTkS3r6S/1tx/Nagof04yQNJqirMx8ctC2Lt0H0GqGtMVO3Ror
uiK+wZmYUJ6oCaOdh4uaChEnfaXSDnn9nQx6PNMJtljmZgDSA+lA/ziaCuFo6XIK
WKBF2gTDaSKGYfKbu95NeuFSwY2KOKzUNZx0Vul9Ly/2djX3IcC1Em95xEuHl3mu
du3PdiL7bbcPjcO4/svUi1UgqotLTYsOn8sYo7kLMyC1VIH3mBjv+aluVpF5KFp6
Ncf2EmeKGsZAsW4Y8ZCKUZpWbMw1iUUyT5T3vFBaWT2qGikbAfZBFR6+mQ==
=zA57
-END PGP SIGNATURE-
diff --git a/debian/NEWS b/debian/NEWS
index a7621ab..1239f31 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -14,6 +14,11 @@ matrix-synapse (0.99.0-1) unstable; urgency=medium
   in Debian packages, which means that you need to set it up manually
   for now.
 
+  Please note that if your homeserver runs under a different domain
+  name than your server name, you will need to configure the .well-known
+  resource; just having an SRV record will not be enough to federate
+  with Synapse 1.0 servers.
+
   See /usr/share/doc/matrix-synapse/misc/MSC1711_certificates_FAQ.md.gz
   for more details.
 
diff --git a/debian/changelog b/debian/changelog
index 151dbb6..86912b6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+matrix-synapse (0.99.2-2) unstable; urgency=medium
+
+  * Make sure the key file is owned by the user running synapse
+(Closes: #923573).
+  * No longer enable webclient by default (Closes: #923574).
+  * Print a warning when the server name has not been set (Closes: #923586).
+  * Update NEWS with a note on .well-known vs SRV.
+
+ -- Andrej Shadura   Sat, 16 Mar 2019 16:48:56 +0100
+
 matrix-synapse (0.99.2-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/homeserver.yaml b/debian/homeserver.yaml
index 68f749f..53df7a7 100644
--- a/debian/homeserver.yaml
+++ b/debian/homeserver.yaml
@@ -139,7 +139,6 @@ listeners:
 # List of resources to host on this listener.
 names:
   - client # The client-server APIs, both v1 and v2
-  - webclient  # The bundled webclient.
 
 # Should synapse compress HTTP responses to clients that support it?
 # This should be disabled if running synapse behind a load balancer
@@ -170,7 +169,7 @@ listeners:
 x_forwarded: false
 
 resources:
-  - names: [client, webclient]
+  - names: [client]
 compress: true
   - names: [federation]
 compress: false
diff --git a/debian/matrix-synapse.init b/debian/matrix-synapse.init
index d537d8d..f6c1869 100755
--- a/debian/matrix-synapse.init
+++ b/debian/matrix-synapse.init
@@ -52,23 +52,31 @@ get_config_key()
 do_start()
 {
# Fail silently if CONFIGFILE_SERVERNAME doesn't exist
-   [ -f $CONFIGFILE_SERVERNAME ] || return 0
+   if [ ! -f $CONFIGFILE_SERVERNAME ]
+   then
+   log_warning_msg "$CONFIGFILE_SERVERNAME not found, not starting 
synapse."
+   return 0
+   fi
+   KEYFILE=$(get_config_key signing_key_path)
 
# Running --generate-config to create keys if any are absent.
# Doesn't matter if not
$PYTHON -m "synapse.app.homeserver" $CONFIGS --generate-keys || return 2
+   # Make sure the key file is owned by the user running synapse
+   chown $USER:nogroup $KEYFILE
+   chmod 0600 $KEYFILE
 
# Return
#   0 if daemon has been started
#   1 if daemon was already running
#   2 if daemon could not be started
-   PIDFILE=`get_config_key "pid_file"`
+   PIDFILE=$(get_config_key pid_file)
RETVAL=$?
if [ "$RETVAL" != 0 ]; then
return $RETVAL
fi
if [ -r "$PIDFILE" ]; then
-   kill -0 `cat $PIDFILE` && return 1
+   kill -0 $(cat $PIDFILE) && return 1
fi
 
export PYTHONPATH
@@ -95,7 +103,7 @@ do_stop()
#   1 if daemon was already stopped
#   2 if daemon 

Bug#919929: unblock request: python-scipy/1.1.0-4 skimage/0.14.2-2: autopkgtest passes (Re: bug#919929)

[Drew Parsons]

On 2019-03-16 22:07, Paul Gevers wrote:

On 16-03-2019 13:48, Drew Parsons wrote:


Is there enough will to add more scipy patches for the buster release 
to

reduce the remaining DeprecationWarnings? (they don't break tests,
they're just annoying)
Or should we just let it go at this point and let them get cleared in
future versions?)


I'd let it be for now.


No problem, will do (more precisely, not do).



That being the case, in the interests of making a stable release that
passes it own tests, I'd like to request an unblock for
python-scipy/1.1.0-4 (together with skimage/0.14.2-2)


skimage was already unblocked. I'll unblock python-scipy as well.



Thanks Paul.  Looks like we'll be able to close Bug#919929 once 
python-scipy/1.1.0-4 is settled into testing.


Drew

Bug#920139: sddm: GTK and GNOME: Applications won't launch due error of glib2

[Bernhard Übelacker]

Control: tags 920139 + unreproducible moreinfo


Hello Adrian Immanuel,
I am sorry for the late reply.

First a question: Do you still observe this fault?


I took a look today inside the md5sums you supplied
and tried to reproduce this setup inside a VM.

Unfortunately I found following old packages that are not
packaged in Debian anymore or maybe not installed in the
latest version:

  nautilus-pastebin: last built 2012, found just at snapshot.debian.org
  geoclue: last in jessie
  easytag: not in the lastest version?
  command-runner-applet: last in jessie
  gnome-search-tool: last in stretch
  sflphone-gnome: last in stretch

Can you please have a look at these packages, if you
really use them?
If not you might uninstall them and test if you still
can observe the not launching applications?

If you use synaptic, there should be a folder with outdated packages.


However, I tried to put your gsettings.compiled into that VM
and could login into GNOME and GNOME Classic sessions without
hitting that fault (traps: gnome-session-b...).

Kind regards,
Bernhard


# Stretch amd64 qemu VM 2019-03-16


apt update
apt dist-upgrade


#


# approx and sources.list to Buster snapshot from 20190210

debian-10-buster-snapshot.debian.org  
https://snapshot.debian.org/archive/debian/20190210T00Z/
debian-10-buster-debug-snapshot.debian.org  
https://snapshot.debian.org/archive/debian-debug/20190210T00Z/

deb [check-valid-until=no] 
http://192.168.178.25:/debian-10-buster-snapshot.debian.org/ buster main


#


apt update
apt dist-upgrade
reboot


apt install dpkg-dev devscripts systemd-coredump mc htop gdb strace 
xserver-xorg sddm
apt install gnome gnucash anjuta-extras tali telepathy-logger gthumb 
gnome-builder gnome-panel gjots2 gobby cinnamon-desktop-data 
ukui-settings-daemon seahorse-nautilus nemo gnome-photos dconf-editor easytag 
meld sound-juicer gnome-system-log virt-manager light-locker 
telepathy-mission-control-5 oregano gbonds-data gnomint liferea teg zapping 
accerciser blueman pulseaudio-module-gsettings almanah caribou-antler bijiben 
gnome-boxes gucharmap deja-dup gnome-dictionary empathy eog-plugins 
epiphany-browser font-manager geary gedit-latex-plugin 
gedit-source-code-browser-plugin ghex gimagereader gitg glabels gnome-nettool 
gnome-subtitles gnote gnumeric goobox gpaste gtranslator gwaei latexila 
gnome-multi-writer gnome-packagekit planner polari gnome-shell-mailnag 
gnome-shell-extension-weather gnome-shell-timer gnome-system-tools telegnome 
gtk-3-examples gtkhash libgtk-3-dev atril caja nemiver soundconverter gnomekiss 
ukwm mousepad



#



md5sum /usr/share/glib-2.0/schemas/* | sort -k 2



#


wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=920139;filename=usr-share-glib-2.0-schemas-md5sums.txt;msg=41;
 -O usr-share-glib-2.0-schemas-md5sums.txt
cat usr-share-glib-2.0-schemas-md5sums.txt | sort -k 2


#





nautilus-pastebin: last built 2012, found just at snapshot.debian.org
geoclue:  last in jessie
easytag not in the lastest version?
command-runner-applet:  last in jessie
gnome-search-tool: last in stretch
sflphone-gnome: last in stretch









wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=920139;filename=gschemas.compiled;msg=41;
 -O /usr/share/glib-2.0/schemas/gschemas.compiled
reboot

Bug#866421: patch

[Thomas Walz]

Control: tags -1 + patch


I fixed the problem by changing Imaging to PIL. See attached patch.

--- comix-4.0.4/debian/changelog2016-02-24 14:16:57.0 +0100
+++ comix-4.0.4/debian/changelog2018-09-28 19:07:08.0 +0200
@@ -1,3 +1,10 @@
+comix (4.0.4-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * added patch import PIL rather than Imaging (Closes: #866421)
+
+ --Fri, 28 Sep 2018 19:07:08 +0200
+
 comix (4.0.4-3) unstable; urgency=low
 
   * Didn't really add unar support, remove suggestion.
--- comix-4.0.4/debian/control  2016-02-24 13:45:55.0 +0100
+++ comix-4.0.4/debian/control  2018-09-28 19:07:08.0 +0200
@@ -8,7 +8,7 @@
 
 Package: comix
 Architecture: all
-Depends: ${misc:Depends}, python (>= 2.4), python-gtk2 (>= 2.12), 
python-imaging (>= 1.1.5)
+Depends: ${misc:Depends}, python (>= 2.4), python-gtk2 (>= 2.12), python-pil 
(>= 1.1.5)
 Recommends: mcomix
 Suggests: unrar-free | unrar, python (>=2.5)|python-sqllite2
 Description: GTK Comic Book Viewer
--- comix-4.0.4/debian/patches/866421-python-imaging-removal.patch  
1970-01-01 01:00:00.0 +0100
+++ comix-4.0.4/debian/patches/866421-python-imaging-removal.patch  
2018-09-28 19:07:08.0 +0200
@@ -0,0 +1,144 @@
+Description: remove python-imaging dependency
+
+
+Author: Thomas Walz 
+Bug-Debian: https://bugs.debian.org/866421
+
+Last-Update: 2018-09-28
+
+Index: comix-4.0.4/install.py
+===
+--- comix-4.0.4.orig/install.py
 comix-4.0.4/install.py
+@@ -240,14 +240,14 @@ def check_dependencies():
+ print '!!! PyGTK  Not found'
+ required_found = False
+ try:
+-import Image
+-assert Image.VERSION >= '1.1.5'
++import PIL
++assert PIL.VERSION >= '1.1.5'
+ print 'Python Imaging Library ... OK'
+ except ImportError:
+ print '!!! Python Imaging Library ... Not found'
+ required_found = False
+ except AssertionError:
+-print '!!! Python Imaging Library ... version', Image.VERSION,
++print '!!! Python Imaging Library ... version', PIL.VERSION,
+ print 'found'
+ print '!!! Python Imaging Library 1.1.5 or higher is required'
+ required_found = False
+Index: comix-4.0.4/src/comix.py
+===
+--- comix-4.0.4.orig/src/comix.py
 comix-4.0.4/src/comix.py
+@@ -49,7 +49,7 @@ except ImportError:
+ sys.exit(1)
+ 
+ try:
+-import Image
++import PIL as Image
+ assert Image.VERSION >= '1.1.5'
+ except AssertionError:
+ print "You don't have the required version of the Python Imaging",
+Index: comix-4.0.4/src/histogram.py
+===
+--- comix-4.0.4.orig/src/histogram.py
 comix-4.0.4/src/histogram.py
+@@ -1,9 +1,9 @@
+ """histogram.py - Draw histograms (RGB) from pixbufs."""
+ 
+ import gtk
+-import Image
+-import ImageDraw
+-import ImageOps
++from PIL import Image
++from PIL import ImageDraw
++from PIL import ImageOps
+ 
+ import image
+ 
+Index: comix-4.0.4/src/image.py
+===
+--- comix-4.0.4.orig/src/image.py
 comix-4.0.4/src/image.py
+@@ -1,10 +1,10 @@
+ """image.py - Various image manipulations."""
+ 
+ import gtk
+-import Image
+-import ImageEnhance
+-import ImageOps
+-import ImageStat
++from PIL import Image
++from PIL import ImageEnhance
++from PIL import ImageOps
++from PIL import ImageStat
+ 
+ from preferences import prefs
+ 
+@@ -169,7 +169,7 @@ def get_most_common_edge_colour(pixbuf):
+ 
+ def pil_to_pixbuf(image):
+ """Return a pixbuf created from the PIL ."""
+-imagestr = image.tostring()
++imagestr = image.tobytes()
+ IS_RGBA = image.mode == 'RGBA'
+ return gtk.gdk.pixbuf_new_from_data(imagestr, gtk.gdk.COLORSPACE_RGB,
+ IS_RGBA, 8, image.size[0], image.size[1],
+Index: comix-4.0.4/src/library.py
+===
+--- comix-4.0.4.orig/src/library.py
 comix-4.0.4/src/library.py
+@@ -8,8 +8,8 @@ from xml.sax.saxutils import escape as x
+ import gtk
+ import gobject
+ import pango
+-import Image
+-import ImageDraw
++import PIL as Image
++from PIL import ImageDraw
+ 
+ import archive
+ import encoding
+Index: comix-4.0.4/src/thumbbar.py
+===
+--- comix-4.0.4.orig/src/thumbbar.py
 comix-4.0.4/src/thumbbar.py
+@@ -4,8 +4,8 @@ import urllib
+ 
+ import gtk
+ import gobject
+-import Image
+-import ImageDraw
++from PIL import Image
++from PIL import ImageDraw
+ 
+ import image
+ from preferences import prefs
+Index: comix-4.0.4/src/thumbnail.py
+===
+--- comix-4.0.4.orig/src/thumbnail.py
 comix-4.0.4/src/thumbnail.py

Bug#501481: [Pkg-sysvinit-devel] Bug#501481: drop logsave from checkroot.sh and checkfs.sh please?

[Harald Dunkel]

I am running ext4 instead of reiserfs today, but logging fsck has still
a *severe* impact on boot time performance. We have a few Debian file
servers in the office, e.g. providing /home/* via NFS. They are managed
remotely using some serial-over-line technology instead of a vga console.

A few months ago such a server went down without a clean umount. On the
next boot it was busy for >2h to show billions of lines about some tiny
repairs it has performed. Mo end was in sight. Then I gave up, interrupted
fsck, booted the host in single user mode, and rerun fsck writing to a log
file instead of the serial line. It was completed within 15 minutes. No
serious problems.

Regards
Harri

Bug#924670: unblock: augustus/3.3.2+dfsg-2

[Andreas Beckmann]

Hi Sascha,

On Fri, 15 Mar 2019 19:25:28 +0100 Ivo De Decker  wrote:
> The built-using field has to refer to the source package, not the binary
> package, so the reference to libbam-dev in the Built-Using header is wrong.
> A package with a non-existant reference in built-using will be rejected by the
> archive.

this is how I set Built-Using in src:pocl

debian/control:
Built-Using:
 ${Built-Using:clang},

debian/rules:
override_dh_gencontrol:
dh_gencontrol -- \
-V'Built-Using:clang=$(shell dpkg-query -f '$${source:Package} 
(= $${source:Version})' -W libclang-$(LLVM_VERSION)-dev)' \

This should be easily adjustable for your use case.


Andreas

Bug#924731: phamm: CVE-2018-20806: Reflected XSS in Phamm login page

[Salvatore Bonaccorso]

Source: phamm
Version: 0.6.5-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/lota/phamm/issues/24

Hi,

The following vulnerability was published for phamm.

CVE-2018-20806[0]:
| Phamm (aka PHP LDAP Virtual Hosting Manager) 0.6.8 allows XSS via the
| login page (the /public/main.php action parameter).

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-2018-20806
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20806
[1] https://github.com/lota/phamm/issues/24

Regards,
Salvatore

Bug#924729: Acknowledgement ([epiphany-browser] web applications lost when upgraded from 3.30.3-1 to 3.31.91-2)

[Olivier Bonvalet]

Note : to manually fix that, I used :

for DESKTOPFILE in $HOME/.local/share/epiphany/app*/*.desktop ; do
NEWDIR=`dirname $DESKTOPFILE`
APPID=`basename $NEWDIR`
OLDDIR=$HOME/.config/epiphany/$APPID
sed -i "s#$OLDDIR#$NEWDIR#" $DESKTOPFILE &&\
ln -f -s $DESKTOPFILE $HOME/.local/share/applications/
done

--
Olivier

Le samedi 16 mars 2019 à 14:39 +, Debian Bug Tracking System a
écrit :
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 924729: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924729.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due
> course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian GNOME Maintainers <
> pkg-gnome-maintain...@lists.alioth.debian.org>
> 
> If you wish to submit further information on this problem, please
> send it to 924...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

Bug#924139: www.debian.org: migrate from python to python3

[Carsten Schoenert]

Hi Cyril,

On Sat, Mar 09, 2019 at 09:48:53PM +0100, Cyril Brulebois wrote:
... 
> There are a couple of scripts that rely on Python at the moment:
... 
> It might be possible to get rid of the first one after the CVS→Git
> migration, but others might need to get ported to Python 3 at some
> point, as Python 2 is on the way out.
> 
> The debian.org metapackage for the website will need to get updated
> accordingly during/after the migration.

I tried to make the migration over to Python3 for the files that have
been identifed by 2to3 as required to get reworked.

As far as possible I've tested the scripts. But someone with more
knowledge will have to take a look athe the possible corner cases.

The follwoing files I could test succesfully.
 english/security/oval/generate.py
 english/security/oval/oval/definition/generator.py
 english/security/oval/oval/parser/dsa.py

These two scripts I'm unable to test.
 english/mirror/timestamps/archive_mirror_check.py
 english/mirror/timestamps/mirror_check.py

I added two patches with the resulting changes.

Regards
Carsten
>From eefa86aa6edf33982e8c5a599cec07480050bbc8 Mon Sep 17 00:00:00 2001
From: Carsten Schoenert 
Date: Sat, 16 Mar 2019 15:03:29 +0100
Subject: [PATCH 1/2] Oval: modify scripts to use Python3

Move over to Python3 syntax so the script generate.py can be used with
the Python3 interpreter.
---
 english/security/oval/generate.py |  7 ++-
 .../oval/oval/definition/generator.py | 59 +++
 english/security/oval/oval/parser/dsa.py  |  3 +-
 3 files changed, 42 insertions(+), 27 deletions(-)

diff --git a/english/security/oval/generate.py b/english/security/oval/generate.py
index 830ddb48007..f966f2213b4 100644
--- a/english/security/oval/generate.py
+++ b/english/security/oval/generate.py
@@ -1,8 +1,9 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 # -*- coding: utf-8 -*-
 # Extracts the data from the security tracker and creates OVAL queries to
 # be used with the OVAL query interpreter (see http://oval.mitre.org)
 
+# (c) 2019 Carsten Schoenert
 # (c) 2016 Sebastien Delafond 
 # (c) 2015 Nicholas Luedtke
 # Licensed under the GNU General Public License version 2. 
@@ -41,8 +42,8 @@ DEBIAN_VERSION = {
 def usage (prog = "parse-wml-oval.py"):
 """Print information about script flags and options"""
 
-print """usage: %s [vh] [-d ]\t-d\twhich directory use for
-dsa definition search\t-v\tverbose mode\t-h\tthis help""" % prog
+print("""usage: {} [vh] [-d ]\t-d\twhich directory use for"""
+  """dsa definition search\t-v\tverbose mode\t-h\tthis help""".format(prog))
 def printdsas(ovals):
 """ Generate and print OVAL Definitions for collected DSA information """
 
diff --git a/english/security/oval/oval/definition/generator.py b/english/security/oval/oval/definition/generator.py
index 087d9000472..4996559cc4f 100644
--- a/english/security/oval/oval/definition/generator.py
+++ b/english/security/oval/oval/definition/generator.py
@@ -3,6 +3,7 @@
 # OVAL definitions of Debian Security Advisories.
 # Use various optimizations to minimize result XML
 #
+# (c) 2019 Carsten Schoenert
 # (c) 2016 Sebastien Delafond 
 # (c) 2015 Nicholas Luedtke
 # (c) 2007 Pavel Vinogradov
@@ -16,8 +17,22 @@ from lxml import etree
 from oval.definition.differ import differ
 import re
 
-# from http://boodebr.org/main/python/all-about-python-and-unicode#UNI_XML
-RE_XML_ILLEGAL = u'([\u-\u0008\u000b-\u000c\u000e-\u001f\ufffe-\u])' + u'|' + u'([%s-%s][^%s-%s])|([^%s-%s][%s-%s])|([%s-%s]$)|(^[%s-%s])' % (unichr(0xd800),unichr(0xdbff),unichr(0xdc00),unichr(0xdfff), unichr(0xd800),unichr(0xdbff),unichr(0xdc00),unichr(0xdfff), unichr(0xd800),unichr(0xdbff),unichr(0xdc00),unichr(0xdfff)) 
+# We add some Unicode characters for High Private Use Surrogates aka "�" we
+# need to ignore.
+# Have a look at https://unicodemap.org/range/76/High_Private_Use_Surrogates/
+# Based on http://boodebr.org/main/python/all-about-python-and-unicode#UNI_XML
+RE_XML_ILLEGAL = u'([\u-\u0008\u000b-\u000c\u000e-\u001f\ufffe-\u])' + u'|' + u'([{0}-{1}][^{2}-{3}])|([^{4}-{5}][{6}-{7}])|([{8}-{9}]$)|(^[{10}-{11}])'.format(chr(0xd800),
+chr(0xdbff),
+chr(0xdc00),
+chr(0xdfff),
+

Bug#774232: recommend using a wired connexion

[Antoine Beaupré]

On 2019-03-16 15:18:27, Paul Gevers wrote:
> Hi,
>
> On Mon, 05 Jan 2015 15:59:51 -0500 Antoine =?utf-8?Q?Beaupr=C3=A9?=
>  wrote:
>> On 2015-01-05 15:52:23, Andrei POPESCU wrote:
>> > There might however be an issue with remote upgrades over wireless 
>> > connections handled by Network Manager as it still reinitializes the 
>> > connection on service restart, so doing a remote upgrade over wireless 
>> > could under specific circumstances lead to problems.
>> 
>> That. Exactly. :) I would be terrified of doing a remote upgrade over
>> wifi, and that's probably because I know a little more what I am doing
>> than the average Debian user - so I think it makes sense to warn against
>> that particular foot-shooting device.
>
> I expect this is still an issue, but I wonder how hypothetical this is.
> Is there any evidence that this is a real issue? I would update remotely
> over WiFi myself, but ...
>
> So, if we want to share our worries, how to phrase this? Does the
> following make sense?
> """
> Upgrading systems remotely that are connected via WiFi managed by
> Network Manager isn't recommended. Network Manager re-initializes the
> connection on service restart which could lead to problems under certain
> circumstances.
> """

The thing is am I do not believe the Debian package restarts network
manager automatically. I have needrestart here for stuff like that, and
even *that* blocks that automated restart by default...

a.

-- 
Si Dieu existe, j'espère qu'Il a une excuse valable
- Daniel Pennac

Bug#924730: "No kernel modules were found" using the direct online installer (virsh)

[Brian Wengel]

Package: debian-installer
Version: From testing,
http://httpredir.debian.org/debian/dists/buster/main/installer-amd64/

Installing Debian 10 as KVM/QEMU guest, host Debian 9.

Virsh-install command:
SCIO virt-install \
--virt-type kvm \
--name "Debian10" \
--vcpus 2 \
--memory 2048 \
--boot uefi \
--cpu host \
--os-variant debiantesting \
--features acpi=on \
--location
http://httpredir.debian.org/debian/dists/buster/main/installer-amd64/ \
--disk device=cdrom,bus=scsi \--disk device=disk,path="
/vm/Debian10/disk1.qcow2",format=qcow2,cache=unsafe,discard=unmap,bus=scsi \
--controller type=virtio-serial \
--controller type=scsi,model=virtio-scsi \
--network bridge=brLAN,model=virtio, \
--graphics vnc,port=5904,keymap=local,listen=0.0.0.0 \
--noautoconsole


Error, see attached screen-dump.
The installation went better using the DVD iso file.

Bug#850256:

[Shasha Reid]

Dear Friend, Did you receive my mail? I have been waiting for your responds. 

Bug#923891: have the same problem

[Dragos Jarca]

Thx Soren Stoutner for the workaround!

I'm waiting to for resolution of this major bug!

Dragos

Bug#924729: [epiphany-browser] web applications lost when upgraded from 3.30.3-1 to 3.31.91-2

[Olivier Bonvalet]

Package: epiphany-browser
Version: 3.31.91-2
Severity: normal

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

I've upgrade Epiphany to 3.31.91-2, and lost all web applications.

When looking into ~/.local/share/applications/, all previous web
applications are now broken symlinks.

For example :
epiphany-facebook-messenger-bb7a2a656c936e6625271c12ba952aa4df00370b.desktop
targets :

~/.config/epiphany/app-epiphany-facebook-messenger-bb7a2a656c936e6625271c12ba952aa4df00370b/epiphany-facebook-messenger-bb7a2a656c936e6625271c12ba952aa4df00370b.desktop

The correct is probably :

~/.local/share/epiphany/app-epiphany-facebook-messenger-bb7a2a656c936e6625271c12ba952aa4df00370b/epiphany-facebook-messenger-bb7a2a656c936e6625271c12ba952aa4df00370b.desktop


and if I create a new one, it's created in :
~/.local/share/


Thanks,


--- System information. ---
Architecture: 
Kernel:   Linux 4.19.0-2-amd64

Debian Release: buster/sid
  500 testing apt.daevel.fr 
1 unstableapt.daevel.fr 
1 experimentalapt.daevel.fr 

--- Package information. ---
Depends  (Version) | Installed
==-+-===
epiphany-browser-data   (>= 3.31.91-2) | 3.31.91-2
libc6(>= 2.14) | 2.28-8
libcairo2  (>= 1.14.0) | 1.16.0-3
libdazzle-1.0-0   (>= 3.29.91) | 3.30.2-2
libgcr-base-3-1 (>= 3.8.0) | 3.28.1-1
libgcr-ui-3-1   (>= 3.8.0) | 3.28.1-1
libgdk-pixbuf2.0-0 (>= 2.36.5) | 2.38.0+dfsg-7
libglib2.0-0   (>= 2.56.0) | 2.58.3-1
libgmp10   | 2:6.1.2+dfsg-4
libgtk-3-0 (>= 3.23.1) | 3.24.5-1
libhogweed4  (>= 3.2~) | 3.4.1-1
libicu63  (>= 63.1-1~) | 63.1-6
libjavascriptcoregtk-4.0-18| 2.22.6-1
libjson-glib-1.0-0  (>= 1.2.0) | 1.4.4-2
libnettle6   (>= 3.4~) | 3.4.1-1
libnotify4  (>= 0.7.0) | 0.7.7-4
libpango-1.0-0 (>= 1.14.0) | 1.42.4-6
libsecret-1-0(>= 0.18) | 0.18.7-1
libsoup2.4-1  (>= 2.41.90) | 2.64.2-2
libsqlite3-0(>= 3.5.9) | 3.27.2-1
libwebkit2gtk-4.0-37  (>= 2.21.92) | 2.22.6-1
libxml2 (>= 2.7.4) | 2.9.4+dfsg1-7+b3
default-dbus-session-bus   | 
 OR dbus-session-bus   | 
iso-codes  | 4.2-1
gsettings-desktop-schemas  | 3.28.1-1


Recommends   (Version) | Installed
==-+-===
yelp   | 3.31.90-1
evince | 3.30.2-3
ca-certificates| 20190110


Package's Suggests field is empty.

Bug#924421: ld.gold searches for non-existent -lug, eventually crashes

[Eduard Bloch]

Control: -1 reopen

Hallo,
* Eduard Bloch [Fri, Mar 15 2019, 09:39:26AM]:
> > > (gdb) run -plugin /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so -plug
> > > Starting program: /usr/bin/ld.gold -plugin 
> > > /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so -plug
> > > [Thread debugging using libthread_db enabled]
> > > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > > /usr/bin/ld.gold: error: cannot find -lug
> > 
> > I suspect the run line is incomplete.
> 
> That's what "file" told me checking the core dump.
> 
> However, I cannot reproduce it anymore. After updating the toolchain,
> the issue seems to have disappeared.

I am sorry, I have to reopen it since the issue is back and is perfectly
reproducible. It seems to be a combination of -Wl,--threads and LTO
(and maybe a machine with 4+ cores) which triggers segfaulting. It
happens on Intel and AMD machines, hardly a hardware problem.

The issue was only temporarily covered by local problems (maybe some
cmake issue, garbling parameters after updating cmake without clearing
the local cache and then by incorrect detection of LTO in the build
script).

Repro:

git clone https://salsa.debian.org/blade/apt-cacher-ng.git
cd apt-cacher-ng
git checkout d204340833d88424792a42013e310f21aecef39b
there:
cmake .
(that should include: "-- LTO use: ON" and "Performing Test LD_MULTITHREADED - 
Success")
make -j$(nproc)

Result:
...
collect2: fatal error: ld terminated with signal 11 [Speicherzugriffsfehler], 
core dumped
compilation terminated.
make[2]: *** [client/CMakeFiles/in.acng.dir/build.make:84: in.acng] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:91: client/CMakeFiles/in.acng.dir/all] 
Fehler 2

Best regards,
Eduard.

Bug#718597: The format of doc-debian is not dwww problem

[Osamu Aoki]

control: severity -1 wishlist
control: tags -1 moreinfo

Hi,

If the file format is not well defined, that's the problem of doc-base
not providing good info.

If each package doesn't provide doc-debian file in righjt format, that's
the problem of each package.

I keep this bug report here as a reminder but not-much can be done from
dwww.  Please tell us what dwww has to do here.

Regards,

Osamu

Bug#924728: ITP: Upgrading golang-github-ghodss-yaml

[Tong Sun]

package: wnpp
Severity: wishlist
Owner: Debian Go packaging team 

Upgrading golang-github-ghodss-yaml to the new upstream version (and
the new packaging standards).
https://salsa.debian.org/go-team/packages/golang-github-ghodss-yaml

Check the following for the discussion details.


-- Forwarded message -
From: Shengjing Zhu 
Date: Sun, Mar 10, 2019 at 5:00 AM
Subject: Re: Updating golang-github-ghodss-yaml

On Sun, Mar 10, 2019 at 1:15 PM Tong Sun wrote:
>
> Hi,
>
> I'm thinking to update golang-github-ghodss-yaml as it is about two years old 
> now and some useful functionalities have been added in. So, the questions are:
>
> - would there be any objections?
> - for two years the upstream author didn't publish any new version. Would the 
> procedure be trying to nudge him for a new version first before going to the 
> latest git version? How long should I normally wait, if upstream author is 
> not responsive, before going to the latest git version?
>

I think you can update when it's needed. For example, your package
needs new version, or bugs in old version.

And just pay attention to coordinate with the reverse dependencies,
you can use ratt[1] to check if the new version causes regressions.

[1] https://packages.debian.org/unstable/ratt

--
Shengjing Zhu

Bug#815417: Now desktop provides easy access

[Osamu Aoki]

control: severity -1 wishlist
control: tags -1 moreinfo

Hi,

Now under GNOME, pressing META(WINDOWS)-key and typing "dwww" provies
iconn entry point to dwww thanks to the desktop file.

So this bug is now wishlist/moreinfo  If Eduard still feels important
and provides patch, then we can reconsider.

Policy change really tells us to move onto new ways.

Regards,

Osamu

Bug#774232: recommend using a wired connexion

[Paul Gevers]

Hi,

On Mon, 05 Jan 2015 15:59:51 -0500 Antoine =?utf-8?Q?Beaupr=C3=A9?=
 wrote:
> On 2015-01-05 15:52:23, Andrei POPESCU wrote:
> > There might however be an issue with remote upgrades over wireless 
> > connections handled by Network Manager as it still reinitializes the 
> > connection on service restart, so doing a remote upgrade over wireless 
> > could under specific circumstances lead to problems.
> 
> That. Exactly. :) I would be terrified of doing a remote upgrade over
> wifi, and that's probably because I know a little more what I am doing
> than the average Debian user - so I think it makes sense to warn against
> that particular foot-shooting device.

I expect this is still an issue, but I wonder how hypothetical this is.
Is there any evidence that this is a real issue? I would update remotely
over WiFi myself, but ...

So, if we want to share our worries, how to phrase this? Does the
following make sense?
"""
Upgrading systems remotely that are connected via WiFi managed by
Network Manager isn't recommended. Network Manager re-initializes the
connection on service restart which could lead to problems under certain
circumstances.
"""

Paul



signature.asc
Description: OpenPGP digital signature

Bug#924596: network-manager-openvpn: GUI cannot import openvpn from config-file

[Jürgen Bausa]

Some more insights:

My openvpn-config file (to be imported into NM) includes the following lines:

dev tun
float

Both options are ignored when importing via gui. When using nmcli, I find

dev=tun 

in /etc/NetworkManager/system-connections/my_openVPN. When using the gui, they 
are 
missing. Adding theses options to the config generated by the gui makes it work.

Juergen

Bug#919929: unblock request: python-scipy/1.1.0-4 skimage/0.14.2-2: autopkgtest passes (Re: bug#919929)

[Paul Gevers]

Hi Drew,

On 16-03-2019 13:48, Drew Parsons wrote:
>> The numpy.sparse tests pass with this patch, and most of the matrix
>> PendingDeprecationWarnings are gone (the upstream patch missed
>> integrate/tests/test_ivp.py, but the remaining warnings are few enough
>> to not need to worry about).
> 
> Well, turns out the other warnings worried Aurelien enough to file
> Bug#924396.
> 
> Is there enough will to add more scipy patches for the buster release to
> reduce the remaining DeprecationWarnings? (they don't break tests,
> they're just annoying)
> Or should we just let it go at this point and let them get cleared in
> future versions?)

I'd let it be for now.

> That being the case, in the interests of making a stable release that
> passes it own tests, I'd like to request an unblock for
> python-scipy/1.1.0-4 (together with skimage/0.14.2-2)

skimage was already unblocked. I'll unblock python-scipy as well.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#924621: [Pkg-openssl-devel] Bug#924621: Bug#924621: openssl 1.1.1b-1 make fetchmail unusable

[Kurt Roeckx]

On Sat, Mar 16, 2019 at 09:06:06AM +0900, Atsuhito Kohda wrote:
> Hi Sebastian,
> 
> On Fri, 15 Mar 2019 22:08:13 +0100, Sebastian Andrzej Siewior wrote:
> 
> > Do you have somewhere more information what failed on the fetchmail
> > side? 
> 
> Yes, I have error messages of fetchmail but they contains
> some Japanese characters. (I added simple translations of
> them but not precise translations.)
> 
> fetchmail: System error during SSL_connect(): 接続が相手からリセットされました
> fetchmail: SSL による接続に失敗しました。
> fetchmail: socketエラーが **server name** よりメールを受信している最中に発生しました。
> fetchmail: Query status=2 (SOCKET)
> 
> line #1:connection is reset by server
> line #2:connection by SSL is failed
> line #3:during receiving mail from **server name**, a socket error occured
> 
> > Is the server using by any chance a small DH key?
> 
> Not sure but on the server dovecot (of Debian package) is running.

So from what I understand, the problem is really on the dovecot
side. What does dovecot's log show?

Dovecot can configure DH, which seems to default to:
ssl_dh = 

Bug#924018: RM: python3.6 -- superseded by python3.7

[Matthias Klose]

Control: tag -1 - moreinfo

On 11.03.19 16:51, Mattia Rizzolo wrote:
> Control: tag -1 moreinfo
> Control: block -1 by 916820 918427
> Control: severity 918427 serious
> 
>> Please remove python3.6 from unstable.
> 
> This needs some more work.

nmu's for python-openflow, kytos-utils, vitrage and prospector are now in 
unstable.

Bug#687293: absolute path /usr/share/doc/ for dwww

[Osamu Aoki]

control: severity -1 wishlist
control: tags -1 moreinfo

Hi,

I tried to reproduce bug under the current situation.  But so far
unsuccessful.

Can you give us an updated example where this patch is really needed?

This is only a "wishlist" since this can be avoided by packages not
using absolute path.

Thanks for your help.

Osamu

Bug#853035: [Pkg-javascript-devel] Bug#853035: fixed in node-liftoff 2.3.0-3

[Xavier]

Le 15/03/2019 à 20:40, Chris Lamb a écrit :
> Chris Lamb wrote:
> 
>>> I didn't find other ways to fix these FTBFS than:
>>
>> 
>>
>> Thank you. However, can I just underline:
>>
 If this was the "only" way to fix the problem, that should be
 documented in the package and in the changelog, not simply on
 this issue.
> 
> Another gentle ping on this? This has a "danger" of being closed
> without a real/proper resolution, alas.
> 
> Regards,

I didn't find any better way that increasing timeout since mocha uses a
very short by default (like done with many other node modules). Could
someone else (JS team member) give his advice?

Bug#924727: check-mk: build-depends on no longer available g++-6

[Andreas Beckmann]

Source: check-mk
Version: 1.4.0p9-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

check-mk/experimental cannot be built any more since it build-depends on
an ancient no longer available g++ version.


Andreas

Bug#924305: unblock: python-saharaclient/2.0.0-2.1

[Andreas Beckmann]

Control: tag -1 - moreinfo

On 2019-03-13 21:48, Ivo De Decker wrote:
> Please don't file unblock request for packages not (yet) in unstable. We can't
> do anything about them, and it's just extra work to check.

It's now in.

Well, you could have treated it as a pre-approval request and tag it
confirmed or comment on the diff (at the time where the deferred upload
could still be replaced by a better version).


Andreas

Bug#822323: enable Apache's cgi module for dwww

[Osamu Aoki]

control: forcemerge -1 781987
control: retitle -1 Provide easily accessible pointer to enable CGI
control: retitle 781987 Provide easily accessible pointer to enable CGI

Hi,

It is easy to say:
  It should work out of the box

But if this involves security concern, it is non-trivial thing to do as
a Distribution.   Also, we don't limit web server to be apache only.  So
running trigger to enable CGI is fragile for such case and automatically
activating module is bad idea.

But we also have to make it easy for user to activate CGI.

So touching up documentation and d/control is a realistic approach.

Thus I am pushing to update documentation since this is safe and
non-intrusive.

Osamu

~

Bug#924666: invoke-rc.d: syntax error: unknown option "--skip-systemd-native"

[Andrej Shadura]

On Sat, 16 Mar 2019 at 12:33, Jean-Marc LACROIX
 wrote:
> Hi,
>
> According to previous tests, due to a serious bug in the
> post-installation scripts, it is no longer possible to reinstall or
> remove any type of package. The system is then definitely unusable.

hostapd from buster Pre-Depends on init-system-helpers >= 1.54 which
supports the required option.

> Many thanks To William Bonnet for his support on Debian systems

I don’t know who William Bonnet is.

-- 
Cheers,
  Andrej

Bug#919929: unblock request: python-scipy/1.1.0-4 skimage/0.14.2-2: autopkgtest passes (Re: bug#919929)

[Drew Parsons]

On 2019-03-11 14:39, Drew Parsons wrote:


I've adapted the 3 patches and pushed to salsa,
   matrix_API_614847c5.patch
   matrix_API_more_e0cfa29e2.patch
   matrix_API_filter_check_87e48c3c5.patch
https://salsa.debian.org/python-team/modules/python-scipy/tree/master/debian/patches

...

The numpy.sparse tests pass with this patch, and most of the matrix
PendingDeprecationWarnings are gone (the upstream patch missed
integrate/tests/test_ivp.py, but the remaining warnings are few enough
to not need to worry about).


Well, turns out the other warnings worried Aurelien enough to file 
Bug#924396.


Is there enough will to add more scipy patches for the buster release to 
reduce the remaining DeprecationWarnings? (they don't break tests, 
they're just annoying)
Or should we just let it go at this point and let them get cleared in 
future versions?)


...


With these patches, the sparse matrix tests pass. There remain three
errors unrelated to sparse matrix:
  spatial/tests/test__plotutils.py::TestPlotting::test_delaunay FAILED
[ 76%]
  spatial/tests/test__plotutils.py::TestPlotting::test_voronoi FAILED
[ 76%]
  spatial/tests/test__plotutils.py::TestPlotting::test_convex_hull
FAILED  [ 76%]

,,,

  >   with suppress_warnings as sup:
  E   AttributeError: __enter__

Apart from that, I'm happy to upload the sparse matrix patches once
the s390x update reaches testing.



Those errors must have been local to me.  scipy 1.1.0-4 now passes debci 
tests cleanly.


That being the case, in the interests of making a stable release that 
passes it own tests, I'd like to request an unblock for 
python-scipy/1.1.0-4 (together with skimage/0.14.2-2)


Drew

Bug#924725: google-android-installers: FTBFS in stretch/i386

[Andreas Beckmann]

Source: google-android-installers
Version: 1472023576
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Control: close -1 1472023576+nmu2

Hi,

google-android-installers/stretch now FTBFS in stretch/i386:

 fakeroot debian/rules binary
dh binary
   create-stamp debian/debhelper-build-stamp
   dh_testroot
   dh_prep
   dh_installdirs
   dh_auto_install
   dh_install
   dh_installdocs
   dh_installchangelogs
   dh_installdebconf
   dh_lintian
   dh_perl
   dh_link
   dh_strip_nondeterminism
   dh_compress
   dh_fixperms
   dh_strip
   dh_makeshlibs
   dh_shlibdeps
   dh_installdeb
   debian/rules override_dh_gencontrol
make[1]: Entering directory '/build/google-android-installers-1472023576'
dh_gencontrol -- -Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-24-installer -- -v24+r02 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-23-installer -- -v23+r03 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-22-installer -- -v22+r02 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-21-installer -- -v21+r02 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-20-installer -- -v20+r02 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-19-installer -- -v19+r04 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-18-installer -- -v18+r03 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-17-installer -- -v17+r03 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-16-installer -- -v16+r05 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-15-installer -- -v15+r05 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-14-installer -- -v14+r04 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-13-installer -- -v13+r01 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-12-installer -- -v12+r03 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-11-installer -- -v11+r02 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-10-installer -- -v10+r02 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-9-installer -- -v9+r02 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-8-installer -- -v8+r03 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-7-installer -- -v7+r03 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-6-installer -- -v6+r01 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-5-installer -- -v5+r01 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-4-installer -- -v4+r03 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-3-installer -- -v3+r04 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-platform-2-installer -- -v2+r1 -Tdebian/substvars
dh_gencontrol -pgoogle-android-build-tools-24-installer -- -v24.0.2 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-build-tools-23-installer -- -v23.0.3 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-build-tools-22-installer -- -v22.0.1 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-build-tools-21-installer -- -v21.1.2 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-build-tools-20-installer -- -v20.0.0 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-build-tools-19-installer -- -v19.0.3 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-build-tools-18-installer -- -v18.1.1 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-build-tools-17-installer -- -v17.0.0 
-Tdebian/substvars
dh_gencontrol -pgoogle-android-ndk-installer -- -v12.b+1 -Tdebian/substvars
dpkg-gencontrol: error: current host architecture 'i386' does not appear in 
package's architecture list (amd64)
dh_gencontrol: dpkg-gencontrol -pgoogle-android-ndk-installer 
-ldebian/changelog -Tdebian/google-android-ndk-installer.substvars 
-Pdebian/google-android-ndk-installer -v12.b+1 -Tdebian/substvars returned exit 
code 255
debian/rules:40: recipe for target 'override_dh_gencontrol' failed
make[1]: *** [override_dh_gencontrol] Error 2
make[1]: Leaving directory '/build/google-android-installers-1472023576'
debian/rules:37: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

dpkg-gencontrol seems to have gotten more strict compared to the time
when this package was built successfully in 2016.

This was fixed automatically at the point this source stopped building the
google-android-ndk-installer package.


Andreas


google-android-installers_1472023576.log.gz
Description: application/gzip

Bug#849390: google-android-ndk-installer: Superseded by google-android-installers?

[Andreas Beckmann]

Followup-For: Bug #849390
Control: reassign -1 src:google-android-installers 1472023576
Control: fixed -1 1472023576+nmu2
Control: retitle -1 src:google-android-installers: google-android-ndk-installer 
is now built from a separate source package
Control: tag -1 sid buster

This was resolved by removal of the binary package from 
src:google-android-installers.

google-android-ndk-installer | 12.b+1| stable/contrib   | amd64
google-android-ndk-installer | 13b   | unstable/contrib | source, amd64


Andreas

Bug#924726: unblock: ruby-mobile-fu/1.4.0+github-2

[Pirate Praveen]

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

Please unblock package ruby-mobile-fu

This package was depending on rails which also installed many development
packages not useful in a production system. This was fixed in last upload of
rails. So this package now depends on ruby-rails instead of rails.

$ debdiff ruby-mobile-fu_1.4.0+github-1.dsc ruby-mobile-fu_1.4.0+github-2.dsc 
dpkg-source: warning: extracting unsigned source package 
(/home/pravi/forge/debian/git/ruby-team/ruby-mobile-fu_1.4.0+github-1.dsc)
dpkg-source: warning: extracting unsigned source package 
(/home/pravi/forge/debian/git/ruby-team/ruby-mobile-fu_1.4.0+github-2.dsc)
diff -Nru ruby-mobile-fu-1.4.0+github/debian/changelog 
ruby-mobile-fu-1.4.0+github/debian/changelog
--- ruby-mobile-fu-1.4.0+github/debian/changelog2018-09-28 
00:34:13.0 +0530
+++ ruby-mobile-fu-1.4.0+github/debian/changelog2019-03-06 
17:13:39.0 +0530
@@ -1,3 +1,10 @@
+ruby-mobile-fu (1.4.0+github-2) unstable; urgency=medium
+
+  * Change dependency rails -> ruby-rails
+  * Bump Standards-Version to 4.3.0 (no changes needed)
+
+ -- Pirate Praveen   Wed, 06 Mar 2019 17:13:39 +0530
+
 ruby-mobile-fu (1.4.0+github-1) unstable; urgency=medium
 
   * Team upload
diff -Nru ruby-mobile-fu-1.4.0+github/debian/control 
ruby-mobile-fu-1.4.0+github/debian/control
--- ruby-mobile-fu-1.4.0+github/debian/control  2018-09-28 00:34:13.0 
+0530
+++ ruby-mobile-fu-1.4.0+github/debian/control  2019-03-06 17:13:39.0 
+0530
@@ -8,10 +8,10 @@
rake,
ruby-json,
ruby-httparty,
-   rails,
+   ruby-rails,
ruby-rack-mobile-detect,
ruby-mocha
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Vcs-Git: https://salsa.debian.org/ruby-team/ruby-mobile-fu.git
 Vcs-Browser: https://salsa.debian.org/ruby-team/ruby-mobile-fu
 Homepage: https://github.com/benlangfeld/mobile-fu
@@ -21,8 +21,8 @@
 Package: ruby-mobile-fu
 Architecture: all
 XB-Ruby-Versions: ${ruby:Versions}
-Depends: rails,
- ruby | ruby-interpreter,
+Depends: ruby | ruby-interpreter,
+ ruby-rails,
  ruby-rack-mobile-detect,
  ${misc:Depends},
  ${shlibs:Depends}

unblock ruby-mobile-fu/1.4.0+github-2

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#924724: unblock: ruby-recaptcha/4.11.1-2

[Pirate Praveen]

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

Please unblock package ruby-recaptcha

This package was unnecessarily dependning on rails which pulls in a large
number of unneeded packages. This was noticed after the last rails update
which moved all development dependencies to rails binary from ruby-rails.

reverse-depends rails showed ruby-recaptcha and ruby-mobile-fu

$ debdiff ruby-recaptcha_4.11.1-1.dsc ruby-recaptcha_4.11.1-2.dsc 
dpkg-source: warning: extracting unsigned source package 
(/home/pravi/forge/debian/git/ruby-team/ruby-recaptcha_4.11.1-1.dsc)
dpkg-source: warning: extracting unsigned source package 
(/home/pravi/forge/debian/git/ruby-team/ruby-recaptcha_4.11.1-2.dsc)
diff -Nru ruby-recaptcha-4.11.1/debian/changelog 
ruby-recaptcha-4.11.1/debian/changelog
--- ruby-recaptcha-4.11.1/debian/changelog  2018-08-24 23:50:37.0 
+0530
+++ ruby-recaptcha-4.11.1/debian/changelog  2019-03-06 17:03:24.0 
+0530
@@ -1,3 +1,11 @@
+ruby-recaptcha (4.11.1-2) unstable; urgency=medium
+
+  * Remove unneeded dependency on rails, add ruby-json dependency
+  * Bump Standards-Version to 4.3.0 (no changes needed)
+  * Update debhelper compatibility level to 11~
+
+ -- Pirate Praveen   Wed, 06 Mar 2019 17:03:24 +0530
+
 ruby-recaptcha (4.11.1-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru ruby-recaptcha-4.11.1/debian/control 
ruby-recaptcha-4.11.1/debian/control
--- ruby-recaptcha-4.11.1/debian/control2018-08-24 23:50:37.0 
+0530
+++ ruby-recaptcha-4.11.1/debian/control2019-03-06 17:03:24.0 
+0530
@@ -3,9 +3,9 @@
 Priority: optional
 Maintainer: Debian Ruby Extras Maintainers 

 Uploaders: Pirate Praveen 
-Build-Depends: debhelper (>= 11),
+Build-Depends: debhelper (>= 11~),
gem2deb
-Standards-Version: 4.2.0
+Standards-Version: 4.3.0
 Homepage: https://github.com/ambethia/recaptcha/
 Vcs-Browser: https://salsa.debian.org/ruby-team/ruby-recaptcha
 Vcs-Git: https://salsa.debian.org/ruby-team/ruby-recaptcha.git
@@ -14,8 +14,8 @@
 Package: ruby-recaptcha
 Architecture: all
 XB-Ruby-Versions: ${ruby:Versions}
-Depends: rails (>> 4.1),
- ruby | ruby-interpreter,
+Depends: ruby | ruby-interpreter,
+ ruby-json,
  ${misc:Depends},
  ${shlibs:Depends}
 Description: Ruby helpers for the reCAPTCHA API

unblock ruby-recaptcha/4.11.1-2

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#924723: ITP: samskivert -- Utility library for java

[Wookey]

Package: wnpp
Severity: wishlist
Owner: Wookey 

* Package name: samskivert
  Version : 1.9
  Upstream Author : Michael Bayne 
* URL : https://github.com/samskivert/samskivert
* License : LGPL 2.1 or later
  Programming Lang: Java
  Description : Utility library for java

 A utility library with an emphasis on reusability without further
 dependencies. Provides routines for io, JDBC support services,
 swing extensions, i18n and text processing, extensions to
 Commons Digester, and a variety  of utility services including data
 structures, synchronization support, text processing and more.
 

This package is a dependency for energy2D which I am also packaging.
That is finite element analysis software for 2D energy simulation. 

Bug#924321: python-openflow: please stop buildd-depending on py3.6

[Matthias Klose]

now NMUed. This was the last package preventing the removal of python3.6 in
unstable.

Bug#924722: ktexteditor: symbols update for riscv64

[Aurelien Jarno]

Source: ktexteditor
Version: 5.54.0-1
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

ktexteditor currently fails to build on the riscv64 architecture due to
differences on the symbols file, as can be seen on the following build
log:

https://buildd.debian.org/status/fetch.php?pkg=ktexteditor=riscv64=5.54.0-1=1552467392=0

The attached patch update the symbols file. It looks like riscv64
behaves the same way than armel and mips64el, but I do not necessarily
understand why. It would be nice if you can include it in the next
upload.

Thanks,
Aurelien
diff -Nru ktexteditor-5.54.0/debian/changelog 
ktexteditor-5.54.0/debian/changelog
--- ktexteditor-5.54.0/debian/changelog 2019-01-17 23:27:20.0 +0100
+++ ktexteditor-5.54.0/debian/changelog 2019-03-15 21:28:59.0 +0100
@@ -1,3 +1,9 @@
+ktexteditor (5.54.0-1+riscv64) unreleased; urgency=medium
+
+  * Update symbols files for riscv64.
+
+ -- Aurelien Jarno   Fri, 15 Mar 2019 20:28:59 +
+
 ktexteditor (5.54.0-1) unstable; urgency=medium
 
   * New upstream release (5.52.0).
diff -Nru ktexteditor-5.54.0/debian/libkf5texteditor5.symbols 
ktexteditor-5.54.0/debian/libkf5texteditor5.symbols
--- ktexteditor-5.54.0/debian/libkf5texteditor5.symbols 2019-01-17 
23:27:20.0 +0100
+++ ktexteditor-5.54.0/debian/libkf5texteditor5.symbols 2019-03-15 
21:28:57.0 +0100
@@ -2547,17 +2547,17 @@
  _ZNK7KateCmd11fromHistoryEi@Base 5.9.0
  _ZNK7KateCmd12queryCommandERK7QString@Base 5.9.0
  _ZNK7KateCmd8commandsEv@Base 5.9.0
- (optional=templinst|arch=!amd64 !arm64 
!mips64el)_ZNSt10_HashtableItSt4pairIKtsESaIS2_ENSt8__detail10_Select1stESt8equal_toItESt4hashItENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeEjjPNS4_10_Hash_nodeIS2_Lb0EEEj@Base
 5.51.0
- (optional=templinst|arch=amd64 arm64 
mips64el)_ZNSt10_HashtableItSt4pairIKtsESaIS2_ENSt8__detail10_Select1stESt8equal_toItESt4hashItENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeEmmPNS4_10_Hash_nodeIS2_Lb0EEEm@Base
 5.50.0
- 
(optional=templinst|arch=armel)_ZNSt15_Sp_counted_ptrIDnLN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base
 5.51.0
- 
(optional=templinst|arch=!armel)_ZNSt15_Sp_counted_ptrIDnLN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 5.50.0
- 
(optional=templinst|arch=armel)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base
 5.51.0
- 
(optional=templinst|arch=!armel)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 5.50.0
+ (optional=templinst|arch=!amd64 !arm64 !mips64el 
!riscv64)_ZNSt10_HashtableItSt4pairIKtsESaIS2_ENSt8__detail10_Select1stESt8equal_toItESt4hashItENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeEjjPNS4_10_Hash_nodeIS2_Lb0EEEj@Base
 5.51.0
+ (optional=templinst|arch=amd64 arm64 mips64el 
riscv64)_ZNSt10_HashtableItSt4pairIKtsESaIS2_ENSt8__detail10_Select1stESt8equal_toItESt4hashItENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeEmmPNS4_10_Hash_nodeIS2_Lb0EEEm@Base
 5.50.0
+ (optional=templinst|arch=armel 
riscv64)_ZNSt15_Sp_counted_ptrIDnLN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base
 5.51.0
+ (optional=templinst|arch=!armel 
!riscv64)_ZNSt15_Sp_counted_ptrIDnLN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 5.50.0
+ (optional=templinst|arch=armel 
riscv64)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base
 5.51.0
+ (optional=templinst|arch=!armel 
!riscv64)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 5.50.0
  
(optional=templinst)_ZNSt6vectorIN11KTextEditor5RangeESaIS1_EE17_M_realloc_insertIJRKS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 5.54.0
- (optional=templinst|arch=!amd64 !arm64 
!mips64el)_ZNSt6vectorIN19KSyntaxHighlighting6FormatESaIS1_EE17_M_default_appendEj@Base
 5.51.0
- (optional=templinst|arch=amd64 arm64 
mips64el)_ZNSt6vectorIN19KSyntaxHighlighting6FormatESaIS1_EE17_M_default_appendEm@Base
 5.50.0
+ (optional=templinst|arch=!amd64 !arm64 !mips64el 
!riscv64)_ZNSt6vectorIN19KSyntaxHighlighting6FormatESaIS1_EE17_M_default_appendEj@Base
 5.51.0
+ (optional=templinst|arch=amd64 arm64 mips64el 
riscv64)_ZNSt6vectorIN19KSyntaxHighlighting6FormatESaIS1_EE17_M_default_appendEm@Base
 5.50.0
  
(optional=templinst)_ZNSt6vectorIN19KSyntaxHighlighting6FormatESaIS1_EE17_M_realloc_insertIJRKS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 5.50.0
- 
(optional=templinst|arch=!mips64el)_ZNSt6vectorIN4Kate12TextLineData7FoldingESaIS2_EE17_M_realloc_insertIJRiS6_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 5.50.0
+ (optional=templinst|arch=!mips64el 

Bug#924397: corekeeper: insecure use of world-writable /var/crash

[Jakub Wilk]

* Paul Wise , 2019-03-15, 08:59:
As a data point, apport creates /var/crash as world-writable in 
postinst:


Does apport use a core dump handler?


Yes.

If so it shouldn't need a world writable directory since the core dump 
handler runs as root.


Apparmor saves dumps directly in /var/crash (bad idea...), so the sticky 
bit is needed so that the user can delete their own core dumps.


I've filed #924692 and #924693 so far, but there's probably more.

--
Jakub Wilk

Bug#924666: invoke-rc.d: syntax error: unknown option "--skip-systemd-native"

[Jean-Marc LACROIX]

Hi,

According to previous tests, due to a serious bug in the 
post-installation scripts, it is no longer possible to reinstall or 
remove any type of package. The system is then definitely unusable.


Thanks in advance to apply following patch 

To reproduce :

step 1: no hostapd on the system

ansible@srv-authenticator-100:~$ dpkg -l |grep hostapd
ansible@srv-authenticator-100:~$

step 2: install buster release

ansible@srv-authenticator-100:~$ sudo apt -t buster install hostapd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  hostapd
0 upgraded, 1 newly installed, 0 to remove and 303 not upgraded.
Need to get 0 B/777 kB of archives.
After this operation, 2081 kB of additional disk space will be used.
Selecting previously unselected package hostapd.
(Reading database ... 23028 files and directories currently installed.)
Preparing to unpack .../hostapd_2%3a2.7+git20190128+0c1e29f-2_amd64.deb ...
Unpacking hostapd (2:2.7+git20190128+0c1e29f-2) ...
Setting up hostapd (2:2.7+git20190128+0c1e29f-2) ...
invoke-rc.d: syntax error: unknown option "--skip-systemd-native"
dpkg: error processing package hostapd (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for man-db (2.7.6.1-2) ...
Errors were encountered while processing:
 hostapd
E: Sub-process /usr/bin/dpkg returned an error code (1)
ansible@srv-authenticator-100:~$

step 3: As system is broken, be sure to verify that system is unusable

ansible@srv-authenticator-100:~$ sudo dpkg --purge --force-all hostapd
(Reading database ... 23054 files and directories currently installed.)
Removing hostapd (2:2.7+git20190128+0c1e29f-2) ...
invoke-rc.d: syntax error: unknown option "--skip-systemd-native"
dpkg: error processing package hostapd (--purge):
 subprocess installed pre-removal script returned error exit status 1
invoke-rc.d: syntax error: unknown option "--skip-systemd-native"
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 hostapd
ansible@srv-authenticator-100:~$


step 4: search invalid parameter 

ansible@srv-authenticator-100:~$ egrep -e '-skip-systemd-native' 
/var/lib/dpkg/info/hostapd.*
/var/lib/dpkg/info/hostapd.postinst:invoke-rc.d 
--skip-systemd-native hostapd $_dh_action || exit 1
/var/lib/dpkg/info/hostapd.prerm:   invoke-rc.d 
--skip-systemd-native hostapd stop || exit 1



step 5 : patch Debian scripts .

 sudo sed -i -e 's/--skip-systemd-native//g' 
/var/lib/dpkg/info/hostapd.*


step 6 : As system is broken, be sure to verify that system is usable now
ansible@srv-authenticator-100:~$ sudo  apt remove --purge hostapd -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  hostapd*
0 upgraded, 0 newly installed, 1 to remove and 1 not upgraded.
1 not fully installed or removed.
After this operation, 2081 kB disk space will be freed.
(Reading database ... 23054 files and directories currently installed.)
Removing hostapd (2:2.7+git20190128+0c1e29f-2) ...
/etc/init.d/hostapd: 30: /etc/init.d/hostapd: log_action_msg: not found
Processing triggers for man-db (2.7.6.1-2) ...
(Reading database ... 23032 files and directories currently installed.)
Purging configuration files for hostapd (2:2.7+git20190128+0c1e29f-2) ...
dpkg: warning: while removing hostapd, directory '/etc/hostapd' not 
empty so not removed

ansible@srv-authenticator-100:~$



Many thanks To William Bonnet for his support on Debian systems

Best regards

Bug#924659: ITP: fossology -- FOSSology is an open source license compliance software system and toolkit.

[Gaurav Mishra]

Hello,

Thank you Chris, I will keep that in mind.

Thanks Moritz to inform that. The FOSSology version last maintained on
Debian was 1.2.0 which was released in 2012. The current version is 3.4.0.

Thanks Guillem. I went through the bugs reported and most of them are
solved now. And FOSSology was removed due to being obsolete in bug 656591.
But we are maintaining FOSSology from 2014 so it active from at least 5
years again and I would like to adopt FOSSology.

Since I am not a Debian developer, I need your help to package and publish
FOSSology as a Debian package.

You help will be much appreciated.

Thanks and regards,
Gaurav Mishra

On Sat, 16 Mar 2019 at 03:35, Guillem Jover  wrote:

> Hi!
>
> On Fri, 2019-03-15 at 20:27:57 +0530, Gaurav Mishra wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Gaurav Mishra 
>
> >   Package name : fossology
> >   Version : 3.4.0
> >   Upstream Author : Michael Jaeger 
> >   URL : https://www.fossology.org/
> >   License : GPL-2.0-only, LGPL-2.1-only
> >   Programming Lang: C, C++, PHP
> >   Description : FOSSology is an open source license compliance software
> > system and toolkit.
> >
> >  FOSSology is an open source license compliance software system and
> > toolkit. As a toolkit you can run license, copyright and export control
> > scans from the command line. As a system, a database and web ui are
> > provided to give you a compliance workflow. License, copyright and export
> > scanners are tools used in the workflow.
> >
> >  - Why is this package useful/relevant?
> >- FOSSology is a famous tool used for open source license compliance.
> >  We have a large database of users which can be benifited by
> >  publishing this as a Debian package.
> >  - Do you use it?
> >- You can check https://www.fossology.org/ to get a list of compaines
> >  and organizations using FOSSology.
> >  - How do you plan to maintain it?
> >- FOSSology is currently maintained at
> >  https://github.com/fossology/fossology. I have created a mirror for
> >  the same at https://salsa.debian.org/fossology-team/fossology.
> >  - Are you looking for co-maintainers or a sponsor?
> >- We are looking for a sponsor to help us publish FOSSology as a
> >  Debian package.
>
> JFYI:
>
>   ,---
>   $ deb-why-removed fossology
>   Date: Sun, 10 Jun 2012 09:58:31 +
>   Ftpmaster: Luca Falavigna
>   Suite: unstable
>   Sources:
>fossology_1.2.0-3.1
>   Binaries:
>fossology_1.2.0-3.1 [all]
>fossology-agents_1.2.0-3.1 [amd64, armel, armhf, i386, ia64,
> kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
>fossology-agents-single_1.2.0-3.1 [amd64, armel, armhf, i386, ia64,
> kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
>fossology-common_1.2.0-3.1 [amd64, armel, armhf, i386, ia64,
> kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
>fossology-db_1.2.0-3.1 [all]
>fossology-dev_1.2.0-3.1 [amd64, armel, armhf, i386, ia64,
> kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
>fossology-scheduler_1.2.0-3.1 [amd64, armel, armhf, i386, ia64,
> kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
>fossology-scheduler-single_1.2.0-3.1 [amd64, armel, armhf, i386, ia64,
> kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc]
>fossology-web_1.2.0-3.1 [all]
>fossology-web-single_1.2.0-3.1 [all]
>   Reason: RoQA; unmaintained, RC buggy
>   Bug: 656591
>   Also-Bugs: 591107 592025 595593 627771 639468 658953 674381
>   `---
>
> Thanks,
> Guillem
>

Bug#924672: unblock: wpa/2:2.7+git20190128+0c1e29f-3

[Emilio Pozuelo Monfort]

Control: tags -1 moreinfo

Hi Andrej,

On 15/03/2019 17:52, Andrej Shadura wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package wpa.
> 
> This upload fixes two issues:
> 
> * #924666: warning is printed using a function defined in a file sourced
>   a few lines later, resulting in an error when a configuration file
>   has not yet been created — or has been already deleted (e.g. when
>   purging).
> * #924632: OpenSSL backend in 2.7 and later breaks engine support when
>   linking against OpenSSL 1.1.
> 
> unblock wpa/2:2.7+git20190128+0c1e29f-3

It looks like you haven't uploaded this yet. Let us know when the package is in
the archive.

Emilio

Bug#924704: bumblebee-nvidia: nvidia-driver 410 doesn't appear to allow the unloading of the nvidia module

[Luca Boccassi]

What Nvidia card does your laptop have?

On Sat, 16 Mar 2019, 03:42 Daniel O.  Package: bumblebee-nvidia
> Version: 3.2.1-20
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer, I write this bug report because this bumblebee/bumblebeed
> doesn't work as it should.
>
>* What led up to the situation? Bumblebee used to work correctly when
> the
> nvidia driver was at 390. A few days ago it was upgraded to 410. At the
> time I
> was running Debian Buster (testing as of this writing). That's where things
> started to get problematic. It appears that the nvidia module couldn't be
> unloaded or something. bbswitch reported as "ON" without optirun, and as
> the
> nvidia drivers were considered in use, I was unable to unbind the nvidia
> driver
> for VGA Passthrough as I had been doing before.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? I uninstalled every bumblebee and nvidia package. I then
> reinstalled everything. No luck. I then uninstalled everything and went
> for the
> legacy 390 package. Unfortunately there were problems with that:
> nvidia-cuba-
> toolkit and nvidia-cuba-dev require the latest nvidia driver installed. On
> top
> of that, bumblebee refused to see the legacy 390 drivers as a glx
> alternative.
> I uninstalled all the nvidia stuff again, switched to Debian Sid, and
> installed
> the latest nvidia drivers again (they were slightly more up to date on Sid
> than
> in Buster). Still no change.
>* What was the outcome of this action? Bumblebee should be able to
> blacklist
> the nvidia driver and isolate it from the operating system in such a way
> that
> the system would run on the integrated GPU and run the discrete GPU for
> applications when called for.
>* What outcome did you expect instead? The nvidia driver is not
> blacklisted,
> and the discrete GPU is in control.
>
> On a different note, I tried posting a bug report upstream. It has some
> information this report might not have (vice versa is definitely the case,
> unfortunately). It can be found at https://github.com/Bumblebee-
> Project/Bumblebee/issues/1023
>
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages bumblebee-nvidia depends on:
> ii  bumblebee   3.2.1-20
> ii  glx-alternative-nvidia  0.9.1
> ii  nvidia-driver   410.104-1
> ii  nvidia-kernel-dkms  410.104-1
>
> bumblebee-nvidia recommends no packages.
>
> bumblebee-nvidia suggests no packages.
>
> -- no debconf information
>
> ___
> pkg-nvidia-devel mailing list
> pkg-nvidia-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-nvidia-devel

Bug#924721: release.debian.org: unblock: jekyll/3.8.3+dfsg-4

[Youhei SASAKI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

Please unblock package jekyll/3.8.3+dfsg-4 for RC bug
jekyll: Could not load bundler: #924230

debdiff attached.

Best Wishes,
Youhei
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqTqcE/iQFWNasLmk5TzVIkdfgcFAlyM19UACgkQk5TzVIkd
fge9CxAAoPx0o67zbvXT2c7o6u9kjYGS+gnFNuNTPIiCbqOd7WV1x+loh/CIxnGM
cI1LljTkBjifS5RuZEbXjATRde9ftEihK0Gvhp3V+EHCIJ/tePEkR6wwzGJwLBln
KRBneIB6QUclcUOrLkSUj8mmM5/QIf+0t4ayi+uZrrxZ4K18lt5ER+hBIOKnx5G/
Z/Ata7i8A78G8hZZgxdOEnRznz55qgVeQuTV15ep3E5MWjpiMqpe3u2BA2Wj1eQA
51Rp2s/6URWftMRa4IHn+vnHHdHiuxvdzaDF4wzTH4wufQlnw8WxB6Mf1Rily2lt
9BR6/slDVMNN0CD604YTxlomJxLPOjxuhrN+vsCKal/j/o582CywJ5T2zRrRkWIf
xc/cUBjrxifUI6IN1P7/xPzSveJZiJQlMeLEz7nc6uKIez6iJ3BoGlI2BHPW0Ya5
ReBhYj7VnyfM5+9aRqsV+dxFwEQwag/ahbDn5ptXH+NyntsHPk0yxgDa8SHouXQo
ZYpho9E/q6kcWa8xOXYQexyYJl1GBGCsopXxKQ8Yj91XBpp2MAg7SjPjVqsFN2hY
G4w/EvtLH5iFQy4+FaN4BvofgSJF3qbC1fCuq1qJn/ALX8dnd8poBfN6Tya3JkhL
6nXBZokDDW5PL5oexiL/+IEIQDnwseYJiTgnP7jS+vLwwP8gdEw=
=Fcli
-END PGP SIGNATURE-


jekyll_3.8.3+dfsg-3.1to4.diff.gz
Description: Binary data

Bug#924717: corekeeper: no way to disable core dumping

[Jakub Wilk]

* Paul Wise , 2019-03-16, 18:43:

* corekeeper doesn't enforce this limit on its own either.

Should corekeeper use `ulimit -c` to retrieve the limit?


That would give you the limit for the core handler process, not for the 
process that crashed.


You can use %c in core_pattern to get the soft limit of the crashing 
process.


(Hmm, it's not documented what's the value you get when there's no 
limit...)



Should corekeeper enforce the soft or hard limit?


Soft.


Is this an appropriate way to enforce the limit?


I think this should work:

  head -c "$limit" > "/var/crash/$owner/$core"

(I'll leave wrapping this in su(1) as an exercise to reader. :-P)

You will also need special cases when the limit is 0, and when there's 
no limit.


--
Jakub Wilk