Bug#929557: additional point of view

[Geert Stappers]

An additional point of view. Prespective is Linux Kernel developer.

OOT means  Out of Tree.
And the tree is the Linux source code directory tree.


- Forwarded message from "Enrico Weigelt, metux IT consult" 
 -

Date: Wed, 29 May 2019 13:01:09 +0200
From: "Enrico Weigelt, metux IT consult" 
To: Dan , debian-ker...@lists.debian.org, 
debian-de...@lists.debian.org
Subject: Re: ZFS in Buster
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:60.0) Gecko/20100101 
Thunderbird/60.2.1

On 28.05.19 18:43, Dan wrote:

> Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0> that 
> prevents ZFS from using SIMD. The result is that ZFS won't be>
usable in Buster. See the following issue>
https://github.com/zfsonlinux/zfs/issues/8793
We recently had this discussion on lkml - yet another case of 3rdparty
folks that just don't follow the license rules.

It's not the kernel who broke zfs, it's zfs that broke itself. The
kernel is GPL, and they just have to follow the rules or go away.

OOT modules are conceptionally messy in the first place. It's sometimes
okay as an temporary workaround, until things get mainlined. But
intentionally keeping things oot for long time is just silly and creates
lots of more problems than it creates.

And they're even using now *deeply* arch-internal functions directly.

> NixOS reverted that particular commit:>
https://www.phoronix.com/scan.php?page=news_item=NixOS-Linux-5.0-ZFS-FPU-Drop
Intentional license violation. Not funny.

> Debian is the "Universal Operating System" and gives the user the> option to 
> choose. It provides "vim and emacs", "Gnome and KDE",
If you wanna have something new included, you'll have to sit down and do
the actual work. In the end of the day, it's that simple.

> Would it be possible to provide an alternative patched linux kernel
> that works with ZFS?

You mean patching against the license ?

> The ZFS developers proposed the Linux developers to rewrite the whole
> ZFS code and use GPL, but surprisingly the linux developers didn't
> accept. See below:
> https://github.com/zfsonlinux/zfs/issues/8314

Wait, no. It's not that we refused anything (actually, I don't even
recall any decent discussion on that @lkml). There even wasn't anything
to accept or refuse - except the existing code, that is nowhere near
a quality where any maintainer likes to even have a closer look at.

The major problem is that ZoL always has been oot on purpose, which is
the wrong approach to begin with. That also leads to bad code quality
(eg. lots of useless wrappers, horrible maintenance, ...)

What ZoL folks could do is step by step rewrite it to use mainline
functionality where ever technically feasible and work closely with
upstream to introduce missing functionality. Obviously, their current
proprietary userland interface can't be accepted for mainline - it
has to be reworked to be conformant w/ standard uapi (eg. we already
have it for things like snapshots, deduplication, quotas, ...)

But it's up to ZoL developers to do the actual work and post patches
to lkml. There won't be anybody else doing that.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287


- End forwarded message -

Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#929923: missing dictionaries.xcu confuses non-US English locales (e.g. en_AU)

[Rene Engelhard]

Hi,

On Tue, Jun 04, 2019 at 01:22:02PM +1000, Trent W. Buck wrote:
> This part isn't important, but I'll address it for the record.
> 
>  1. My original problem is "Australian English users cannot click Tools > 
> Thesaurus".
> 
>  2. One fix is "apt-get install mythes-en-au"  (note "AU" not "US").

Yeah, misread it, sorry. (Multitasking while doing university stuff.)

Regards,

Rene

Bug#929923: missing dictionaries.xcu confuses non-US English locales (e.g. en_AU)

[Rene Engelhard]

tag 929923 - wontfix
retitle 929923 mythes-en-us: add symlinks for en_AU etc.
thanks

Hi,

On Tue, Jun 04, 2019 at 12:51:44PM +1000, Trent W. Buck wrote:
> Do you agree so far?

Yes

> The solution
> 
> I think on non-Debian, LibreOffice knows that en_* should use
> th_en_US_v2 because of dictionaries/en/dictionaries.xcu:
> 
> 
> https://sources.debian.org/src/libreoffice-dictionaries/1:6.2.0-1/dictionaries/en/dictionaries.xcu/#L82
> 
> https://sources.debian.org/src/libreoffice-dictionaries/1:6.2.0-1/dictionaries/en/dictionaries.xcu/#L90
> 
> I think without that XML, LibreOffice guesses based on the file name.

Exactly.

>   c. make some crappy symlinks th_en_XX_v2.dic -> th_en_US_v2.dic.
>  This works for me.
> 
>  The downside is that debian/*.links and
>  dictionaries/*/dictionaries.xcu can get out of sync.
> 
> 
> UPDATE: I just noticed you are already doing (c) for other languages, e.g.
> 
> 
> https://sources.debian.org/src/libreoffice-dictionaries/1:6.2.0-1/debian/mythes-es.links/
> 
> So, I am simply proposing to do the same for English.

Yeah, one can do that...

Regards,

Rene

Bug#927775: monit: CVE-2019-11454 CVE-2019-11455

[Sergey B Kirpichev]

On Tue, 23 Apr 2019 06:53:03 +0200 Salvatore Bonaccorso  
wrote:
> CVE-2019-11454[0]:
> | Persistent cross-site scripting (XSS) in http/cervlet.c in Tildeslash
> | Monit before 5.25.3 allows a remote unauthenticated attacker to
> | introduce arbitrary JavaScript via manipulation of an unsanitized user
> | field of the Authorization header for HTTP Basic Authentication, which
> | is mishandled during an _viewlog operation.
> 
> 
> CVE-2019-11455[1]:
> | A buffer over-read in Util_urlDecode in util.c in Tildeslash Monit
> | before 5.25.3 allows a remote authenticated attacker to retrieve the
> | contents of adjacent memory via manipulation of GET or POST
> | parameters. The attacker can also cause a denial of service
> | (application outage).

Why severity "grave"?  Seems wrong accordingly to the
description in https://www.debian.org/Bugs/Developer#severities.

Bug#926540: unblock: xorg-server/2:1.20.4-1

[Cyril Brulebois]

Hi,

Andreas Boll  (2019-05-11):
> On Sat, Apr 06, 2019 at 10:25:31PM +0200, Cyril Brulebois wrote:
> > Hi,
> > 
> > Andreas Boll  (2019-04-06):
> > > CCing kibi for unblock-udeb review
> > 
> > This is coming a little late for RC1 that should be published very soon.
> > I've added this to my local todo list but feel free to prod me once RC1
> > is published.
> 
> Ping :)

Apologies for the delay, been busy…

Runtime tests look good, no objections.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#926630: unblock: libpng1.6/1.6.36-6

[Cyril Brulebois]

Hi,

Paul Gevers  (2019-05-11):
> > debdiff attached
> > 
> > thanks for caring,
> > 
> > unblock libpng1.6/1.6.36-6
> 
> I am fine with this, but it needs a review by d-i (CC-ed kibi).

Apologies for the delay.

Based on runtime tests: no objections.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#929951: php-ast: New upstream version 1.0.1 available

[Jason Hernandez]

Package: php-ast
Severity: important

Dear Maintainer,

There is a new version of php-ast available upstream at
https://github.com/nikic/php-ast/releases
This is a dependency for the static analysis tool phan -
https://github.com/phan/phan

Thank you.



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (310, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages php-ast depends on:
ii  libapache2-mod-php7.2 [phpapi-20170718]  7.2.9-1
ii  libc62.28-10
ii  php-common   2:69
ii  php7.2-cli [phpapi-20170718] 7.2.9-1
ii  php7.3-cli [phpapi-20180731] 7.3.4-2

php-ast recommends no packages.

php-ast suggests no packages.

Bug#929171: unblock: espeakup/1:0.80-15

[Cyril Brulebois]

Niels Thykier  (2019-05-18):
> Samuel Thibault:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > 
> > Hello,
> > 
> > As reported on Bug#929169, “the Linux kernel in Buster seems to take
> > much longer (as much as 12s!) to detect some sound card such as the
> > widespread Intel HDA. The current timeout in espeakup-udeb is thus way
> > too short, and makes the Debian installer useless for blind people
> > having such audio cards.”
> > 
> > In version 1:0.80-15 (debdiff attached) I have thus made the timeout
> > longer. A proper solution would be to make espeakup startup event-based,
> > but that would be very involved at this stage of development.
> > 
> > This version was confirmed to be fixing the issue on a few user systems.
> > 
> > Samuel
> > 
> > unblock espeakup/1:0.80-15
> > 
> > [...]
> 
> Ack from here; CC'ing KiBi for a d-i ack before it is fully unblocked.

Testing multi-cards support (-soundhw all), I'm seeing errors that are
likely due to busybox's sleep not supporting decimal numbers (“sleep
0.1” is called).

Not a regression if I'm reading the diff correctly, but might be worth
fixing at some point…

Speaking of error messages, we're also getting invalid commands from
amixer. Is that expected/known/tracked somewhere? (I think I've been
seeing this for months, maybe years.)


Back to the actual unblock request, that looks reasonable.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#929132: unblock (pre-approval): dbus/1.12.14-1

[Cyril Brulebois]

Niels Thykier  (2019-05-19):
> Ok. I have added an unblock and age-days 8 hint.  Also CC'ing KiBi for
> a d-i ack before adding an unblock-udeb hint.

Apologies for the delay; no objections.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#928732: CVE-2019-11460

[Salvatore Bonaccorso]

Hi Simon,

On Mon, Jun 03, 2019 at 11:34:36PM +0100, Simon McVittie wrote:
> Version: 3.32.1-1
> 
> On Thu, 09 May 2019 at 22:34:53 +0200, Moritz Muehlenhoff wrote:
> > This was assigned CVE-2019-11460:
> > https://gitlab.gnome.org/GNOME/gnome-desktop/issues/112
> 
> This was fixed in 3.32.1, so I believe the bug is already not present
> in experimental:
> 
> $ git grep TIOCSTI
> libgnome-desktop/gnome-desktop-thumbnail-script.c:{SCMP_SYS (ioctl), 
> _A1(SCMP_CMP_MASKED_EQ, 0xu, (int)TIOCSTI)},
> 
> I'm preparing a backport of the upstream commit to 3.30.x for buster.
> (It was in 3.30.2.3, but that version has a lot of Autotools noise
> for a one-line change, so it doesn't seem worth following upstream
> 3.30.x releases unless/until there's a larger important fix.)
> 
> On Thu, 09 May 2019 at 23:00:41 +0200, Salvatore Bonaccorso wrote:
> > found 928732 3.32.1-1
> 
> ... or please reopen if you have information to the contrary?

Hmm, but not I think this was not in 3.32.*1*-1. #112 is fixed by
e3dca7d49bf179f98ac114cad9f4d4889f75d90c which was included in 3.33.1.
The fix went as well upstream in 3.32.1.1 and in 3.32.*2*. So I think
found 3.32.1-1 was actually correct, bug it's fixed in the current
version in experimental as 3.32.2-1.

I checked as well by fetching 3.32.1-1 explicitly from snapshots.

Regards,
Salvatore

Bug#929215: unblock: systemd/241-5

[Cyril Brulebois]

Hi,

Michael Biebl  (2019-06-03):
> 241-5 is waiting for an ack from d-i. Since the AMD related RDRAND
> breakage is rather nasty for users of those affected systemd, it would
> be good to have that version in testing.
> While I don't expect any issues on the udeb/udev related parts, it would
> be great if you can have a look and give this version a try wrt to d-i.

Apologies for the delay.

Changes look good, and so do runtime tests, so no objections.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#929923: missing dictionaries.xcu confuses non-US English locales (e.g. en_AU)

[Trent W. Buck]

Rene Engelhard wrote:
> On Mon, Jun 03, 2019 at 10:04:02PM +0200, Rene Engelhard wrote:
> > $ apt-cache show mythes-en-us
> > Package: mythes-en-us
> > Source: libreoffice-dictionaries
> 
> Sorry, edited and sent too fast. This is the key point here. This mythes
> dict is *exactly* what gets shipped in LibreOffice itself. So I don't
> understand your comment about it being old and predating
> LibreOffice

This part isn't important, but I'll address it for the record.

 1. My original problem is "Australian English users cannot click Tools > 
Thesaurus".

 2. One fix is "apt-get install mythes-en-au"  (note "AU" not "US").
This is a bad fix, because mythes-en-au is old and
not part of libreoffice-dictionaries.


bash5$ rmadison -s testing mythes-en-au mythes-en-us
mythes-en-au | 2.1-5.4   | testing| all
mythes-en-us | 1:6.2.0-1 | testing| all


bash5$ grep-aptavail -s Package,Source -P mythes-en-
Package: mythes-en-us
Source: libreoffice-dictionaries

Package: mythes-en-au
Source: openoffice.org-en-au

Bug#929923: missing dictionaries.xcu confuses non-US English locales (e.g. en_AU)

[Trent W. Buck]

tag 929923 + patch
thanks

Rene Engelhard wrote:
> On Mon, Jun 03, 2019 at 07:21:47PM +1000, Trent W. Buck wrote:
>> Upstream, LibreOffice uses a dictionaries.xcu file to say "use the en_US 
>> thesaurus for ALL en locales".
>> AFAICT Debian doesn't ship dictionaries.xcu files, though they are present 
>> in the libreoffice-dictionaries source package.
>
> Yeah, that is a side effect on how we package it. Application-agnostic.
>
> If we packaged it as a LO-only extension we could include that file, as
> it is now, not. (and mythes is not used by LO only ttbomk).
>
> [code showing mythes-en-us is used by lyx and texlive]
>
> And packaging this up as an extension would either loose the ability to use it
> in other applications or duplicate it.

I agree that the thesaurus should be application-agnostic.
I agree that packaging as a LO-only extension is a bad idea.


My original bug report was not very clear (sorry!); I will rephrase below.
Short version: I propose 929923.patch (attached).


The problem
===

 1. LibreOffice only has one English-language thesaurus, th_en_US_v2.
 2. On Windows LibreOffice, Tools > Thesaurus is clickable for non-US English.
 3. On Debian LibreOffice, Tools > Thesaurus is greyed out for non-US English.

This is the bug.

To reproduce:

  * Install libreoffice and mythes-en-us.
  * Open LO writer.
  * Tools > Language > For All Text > English (UK)
  * Tools > Thesaurus is greyed out.
  * Tools > Language > For All Text > English (USA)
  * Tools > Thesaurus is clickable.

I want Debian LibreOffice to behave like non-Debian LibreOffice.

Do you agree so far?


The solution

I think on non-Debian, LibreOffice knows that en_* should use
th_en_US_v2 because of dictionaries/en/dictionaries.xcu:


https://sources.debian.org/src/libreoffice-dictionaries/1:6.2.0-1/dictionaries/en/dictionaries.xcu/#L82

https://sources.debian.org/src/libreoffice-dictionaries/1:6.2.0-1/dictionaries/en/dictionaries.xcu/#L90

I think without that XML, LibreOffice guesses based on the file name.
This causes Tools > Thesaurus to work for en_US, but
not for other locales mentioned on #L90, above.

I can see three ways to address this:

  a. like upstream, bundle the .dic and .xcu files into an .oxt (LibreOffice 
Extension).
 This makes the thesaurus inaccessible to non-LO apps, which is 
unacceptable.

  b. distribute the XML somewhere else, such as into

   /usr/lib/libreoffice/share/registry/mythes-en-us.xcd

 I couldn't get this to work (see attached draft).

  c. make some crappy symlinks th_en_XX_v2.dic -> th_en_US_v2.dic.
 This works for me.

 The downside is that debian/*.links and
 dictionaries/*/dictionaries.xcu can get out of sync.


UPDATE: I just noticed you are already doing (c) for other languages, e.g.


https://sources.debian.org/src/libreoffice-dictionaries/1:6.2.0-1/debian/mythes-es.links/

So, I am simply proposing to do the same for English.
Attached is a simple draft patch.



http://www.w3.org/2001/XMLSchema;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xmlns:oor="http://openoffice.org/2001/registry;>
  
  
  
  

  

  
/usr/share/mythes/th_en_US_v2.dat
  
  
DICT_THES
  
  
en-GB en-US en-PH en-ZA en-NA en-ZW en-AU en-CA en-IE en-IN 
en-BZ en-BS en-GH en-JM en-MW en-NZ en-TT
  

  

  

commit 4f2ef16491ab99544e46a8380324a1aecc2ae210
Author: root 
Date:   Tue Jun 4 12:41:58 2019 +1000

Non-maintainer upload.

* Non-maintainer upload.
* Fix Tools > Thesaurus for English (non-USA) in LibreOffice.
  Closes: #929923

diff --git a/debian/changelog b/debian/changelog
index fc56faf..aaf9096 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+libreoffice-dictionaries (1:6.2.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix Tools > Thesaurus for English (non-USA) in LibreOffice.
+Closes: #929923
+
+ -- Trent W. Buck   Tue, 04 Jun 2019 12:32:55 +1000
+
 libreoffice-dictionaries (1:6.2.0-1) unstable; urgency=medium
 
   * New upstream version 6.2.0.
diff --git a/debian/control b/debian/control
index da6f316..a791361 100644
--- a/debian/control
+++ b/debian/control
@@ -433,6 +433,10 @@ Multi-Arch: foreign
 Depends: dictionaries-common, ${misc:Depends}
 Suggests: libreoffice-writer
 Provides: mythes-thesaurus, mythes-thesaurus-en-us
+# This is the ancient mythes-en-au from OpenOffice.org, from way back before Oracle bought Sun.
+# It hasn't had an update since 2011.  Upstream LibreOffice uses the English (USA) thesaurus for all English languages.
+Breaks: mythes-en-au (<< 2.1-5.4)
+Replaces: mythes-en-au (<< 2.1-5.4)
 Description: English (USA) Thesaurus for LibreOffice
  Libreoffice is a full-featured office productivity suite that provides a
  near drop-in replacement for Microsoft(R) Office.
diff --git 

Bug#929557: Please revert LTS kernel change that will break ZFS for Buster point releases

[Bastian Blank]

Control: severity -1 wishlist

On Mon, Jun 03, 2019 at 06:39:39PM -0700, Mo Zhou wrote:
> I believe this is a kernel bug. Instead of submitting
> a grave RC for the 10.1 release, we'd better sort it out
> right now before the Buster release.

We already stated that we wont change it by marking this bug as wontfix.
We also told youd that it is your turn to pursuade upstream.

The export of this low-level functions was revoked because it was often
used in a wrong way.  The safe alternative is still exported, however
marked as gpl-only.  It is up to you to pursuade upstream to change the
still existing export, which should be possible, but this needs do be
done by you.  After upstream applied it we can cherry pick this chane.

Regards,
Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3

Bug#929834: Buster/XFCE unlock screen is blank

[Paul Wise]

On Tue, Jun 4, 2019 at 4:12 AM Yves-Alexis Perez wrote:

> My gut feeling is that light-locker just uses codepaths not really used
> otherwise, like vt-switch at the same time as suspend/resume or screen off/on.
> Unfortunately debugging i915 is completely out of my league (and I already
> tried multiple time on other issues).

I suggest reporting this to the Intel developers upstream, they should
be able to diagnose the issue and hopefully provide a fix.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#929255: stretch-pu: package corekeeper/1.7~deb9u1

[Paul Wise]

On Mon, 2019-06-03 at 15:12 +0100, Adam D. Barratt wrote:

> Please go ahead.

Uploaded.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#788104: Info received (RFS: lfdk/2.0.0+git20150619.906338f [ITP])

[You-Sheng Yang]

Hi, Gaffa, Colin,

I recently created a repository to host debian packaging for lfdk. Would
you mind guiding me through the process the include this utility in
Debian? Thank you.

-- 
You-Sheng Yang



signature.asc
Description: OpenPGP digital signature

Bug#929692: RFP: iwlwifi-dkms -- iwlwifi driver backport in DKMS format

[You-Sheng Yang]

Renamed source/binary package names to backport-iwlwifi-dkms in my
gitlab fork: https://gitlab.com/vicamo/backport-iwlwifi-dkms

Thank you.

On Thu, 30 May 2019 17:37:30 +0800 Anthony Wong  wrote:
> Which git tree and branch do you take it from? If it is
> https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git
> then
> the package name is better called backport-iwlwifi-dkms or
> iwlwifi-backport-dkms to make the package name clear in reflecting what it
> does.
> 
> Thanks,
> Anthony

-- 
You-Sheng Yang



signature.asc
Description: OpenPGP digital signature

Bug#929557: Please revert LTS kernel change that will break ZFS for Buster point releases

[Mo Zhou]

control: severity -1 grave

Dear kernel maintainers,

Buster will be released with 4.19.37 kernel. That's fine
and it doesn't break ZFS. However, the changes introduced
in 4.19.38 and linux 5.0 break ZFS. That means the current
0.7.12-2 will fail to build everywhere after the first
Buster point release (with kernel version bump).
A foreseeable stable RC is grave enough.

Upstream has made a compromise to disable SIMD for kernels
that received the breaking change:
 
https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730

Based on these, we Debian ZoL maintainers have several
possible choices:

1. unblock 0.7.13-1 (see rmadison -S zfs-linux)
   (it contains the above patch)
2. revert debdiff(0.7.12-2,0.7.12-5), apply the upstream
   patch and upload 0.7.12-6 through t-p-u.
3. ask kernel maintainers to revert problematic commits

Freeze policy makes it difficult for the release team to
accept solution 1. Solution 2 is able to eliminate bugs
but I doubt how useful a SIMD-less ZFS is. Compared to
the others, solution 3 is the best solution because there
won't be any future breakage or significant performance loss.

My position is solution 3, as it's the ***LTS KERNEL UPDATE***
that introduced breaking change breaks ZFS 0.7.12-2.
It's not a bug of ZFS 0.7.12-2 at all.

Debian ZFS users are sensitive because I and Aron often
receive private user reports and prodding mails. That means
reverting the problematic kernel commit is beneficial to
our users. Our priorities are our users and free software,
NOT to stick to the problematic breaking LTS update.

I believe this is a kernel bug. Instead of submitting
a grave RC for the 10.1 release, we'd better sort it out
right now before the Buster release.

Thanks,
Mo

Bug#805711: Info received (light-locker: no login possible after suspend)

[Matthew Crews]

This issue is still present in Buster. The workaround (switch to VT8
then back to VT7) also still works in Buster.



signature.asc
Description: OpenPGP digital signature

Bug#757726: ruby-rchardet: require 'rchardet fails' with invalid multibyte escape

[Marek Veber]

This version 1.3.3 is not ready for ruby-1.9 or ruby-2 ...
On places with this bug can be inserted: "string[0]" ->
"string.bytes[0]", but there is version 1.8 on rubygems (on github's
changelog there is declared support for ruby-1.9.3 just in release 1.4.2)

Bug#929950: unblock: guile-2.2/2.2.4+1-2

[Rob Browning]

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

Please unblock package guile-2.2

See the two bugs mentioned in the changelog.  Recent builds (tests) have
started failing on additional architectures, including amd64 (locally
too) due to the popen.test issue, and the motivation for the
"alternatives" related change is described in bug 926182.

The changes proposed are the first 5 commits here:
https://salsa.debian.org/rlb/deb-guile/commits/02b16a15a8459b2fe12bb925c1d639149c75c0ce

i.e.:

diff --git a/debian/.git-dpm b/debian/.git-dpm
index 2d64dcbe1..d47d6bf93 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-59d9bcd468aab0d97d763595fd4e934044dc7590
-59d9bcd468aab0d97d763595fd4e934044dc7590
+c17d093ff083f4f8ba604d7ea60d76282fd31daf
+c17d093ff083f4f8ba604d7ea60d76282fd31daf
 4d0be7303dd8f27e1e15478751a9daa2c680a677
 4d0be7303dd8f27e1e15478751a9daa2c680a677
 guile-2.2_2.2.4+1.orig.tar.xz
diff --git a/debian/changelog b/debian/changelog
index ca83af872..3cf949776 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,10 +1,32 @@
-guile-2.2 (2.2.4+1-1~1.gbpc776ff) UNRELEASED; urgency=medium
+guile-2.2 (2.2.4+1-2) unstable; urgency=medium
 
-  ** SNAPSHOT build @c776ff77c289f2a3775a99f0d9ca9b33bcd5c6ae **
+  * Backport upstream fix for after-gc-hook test failures.  Replace
+0006-gc.test-after-gc-hook-mark-unresolved-on-failure-for.patch that
+marked the failure as unresolved on mips(el) (a failure which has been
+seen since on at least sparc64 and amd64) with
+0006-Fix-gc.test-after-gc-hook-gets-called-failures.patch which
+addresses the underlying problem. (Closes: 900652)
 
-  * UNRELEASED
+  * Handle guile-config/guile-snarf/guild as alternatives.  Arrange for
+guile-config, guile-snarf, guild (and guile-tools) to be handled via
+update-alternatives with all of the other tools dependent on
+guile-config.  Configure with "--program-suffix -2.2" which gives the
+binaries the correct names from the start, so that we don't have to
+manually change them in debian/rules.  This also arranges for
+guile-config, etc. to refer to the versioned guile in their #! lines,
+which is what we should have been doing all along.
 
- -- Rob Browning   Sat, 28 Jul 2018 15:05:31 -0500
+Thanks to Ahmed El-Mahmoudy and Norbert Preining for reporting the
+problem, Kari Pahula and Vagrant Cascadian for help devising the fix,
+and Thibaut Paumard for help testing. (Closes: 926182)
+
+ -- Rob Browning   Sun, 02 Jun 2019 11:17:15 -0500
+
+guile-2.2 (2.2.4+1-1) unstable; urgency=medium
+
+  * Upgrade to 2.2.4.
+
+ -- Rob Browning   Sat, 28 Jul 2018 15:10:51 -0500
 
 guile-2.2 (2.2.3+1-6) unstable; urgency=medium
 
diff --git a/debian/guile-dev.install b/debian/guile-dev.install
index d73d1164f..8c10f5018 100644
--- a/debian/guile-dev.install
+++ b/debian/guile-dev.install
@@ -1,7 +1,7 @@
-debian/tmp/usr/bin/guild
-debian/tmp/usr/bin/guile-config
-debian/tmp/usr/bin/guile-snarf
-debian/tmp/usr/bin/guile-tools
+debian/tmp/usr/bin/guild-@DEB_SRC_EFF_VER@
+debian/tmp/usr/bin/guile-config-@DEB_SRC_EFF_VER@
+debian/tmp/usr/bin/guile-snarf-@DEB_SRC_EFF_VER@
+debian/tmp/usr/bin/guile-tools-@DEB_SRC_EFF_VER@
 debian/tmp/usr/include/*
 debian/tmp/usr/lib/*/*.a
 debian/tmp/usr/lib/*/libguile-@DEB_SRC_EFF_VER@.so
diff --git a/debian/guile-dev.postinst b/debian/guile-dev.postinst
new file mode 100644
index 0..afee5e43a
--- /dev/null
+++ b/debian/guile-dev.postinst
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+set -e
+
+update-alternatives \
+--install /usr/bin/guile-config guile-config \
+  /usr/bin/guile-config-@DEB_SRC_EFF_VER@ @DEB_ALT_PRIORITY@ \
+--slave /usr/bin/guile-snarf guile-snarf \
+/usr/bin/guile-snarf-@DEB_SRC_EFF_VER@ \
+--slave /usr/bin/guild guile-guild \
+/usr/bin/guild-@DEB_SRC_EFF_VER@ \
+--slave /usr/bin/guile-tools guile-tools \
+/usr/bin/guile-tools-@DEB_SRC_EFF_VER@
+
+#DEBHELPER#
diff --git a/debian/guile-dev.prerm b/debian/guile-dev.prerm
new file mode 100644
index 0..95ce087e0
--- /dev/null
+++ b/debian/guile-dev.prerm
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+set -e
+
+if [ "$1" != upgrade ]
+then
+update-alternatives --verbose \
+--remove guile-config \
+/usr/bin/guile-config-@DEB_SRC_EFF_VER@
+fi
+
+#DEBHELPER#
diff --git a/debian/guile-libs.install b/debian/guile-libs.install
index 5dca45303..a2335c3f1 100644
--- a/debian/guile-libs.install
+++ b/debian/guile-libs.install
@@ -1,4 +1,4 @@
-debian/tmp/usr/bin/guile /usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin
+debian/tmp/usr/bin/guile /usr/lib/@MARCH@guile/@DEB_SRC_EFF_VER@/bin
 debian/tmp/usr/lib/*/guile/@DEB_SRC_EFF_VER@/ccache/*
 debian/tmp/usr/lib/*/libguile-@DEB_SRC_EFF_VER@.so.*
 debian/tmp/usr/lib/*/guile/@DEB_SRC_EFF_VER@/extensions/guile-readline.so*
diff --git a/debian/guile.links 

Bug#929903: openssl: m2crypto test case regression

[Sebastian Andrzej Siewior]

On 2019-06-02 23:39:22 [+0200], Kurt Roeckx wrote:
> > So, I added a small test for RSA_SSLV23_PADDING, as an extra commit,
> > since it will likely not cherry-pick in stable branches.
> 
> It's about this change:
> -good &= constant_time_lt(threes_in_row, 8);
> +good &= constant_time_ge(threes_in_row, 8);
> 
> (That should probably have been a separate commit.)
> 
> Can you confirm that that is the reason for the change in
> behaviour?

yes, I confirm that this is the change that makes the testcase fail.

> I don't understand the m2crypto code, so I have no idea what it's
> testing.

So if I decoded it right, it does

| fbuf = sha1("The magic words are squeamish ossifrage."); /* 0xbf, 0xf0, 
0x04 … */
| flen = RSA_public_encrypt(20, fbuf, tobuf, )
| /* flen -> 128 */
| r = RSA_private_decrypt(128, tobuf, tobuf2, )

before the change, RSA_private_decrypt() used to return an error
 r -> -1, rsa routines|rsa_ossl_private_decrypt|padding check failed>

after that, it return `20' and probably passes. Would it be likely that
m2crypto tested that an openssl bug existed which got fixed?

> Kurt

Sebastian

Bug#929829: [Pkg-javascript-devel] Bug#929829: Bug#929829: gulp 4 cannot build node-babel 7 - Cannot convert undefined or null to object

[Xavier]

Le 03/06/2019 à 22:23, Xavier a écrit :
> Le 01/06/2019 à 12:14, Pirate Praveen a écrit :
>> ...
>> gulp build
>> [15:37:17] Local modules not found in ~/forge/debian/git/js-team/node-babel
>> [15:37:17] Try running: npm install
>> [15:37:17] Using globally installed gulp
>> [15:37:17] Using gulpfile ~/forge/debian/git/js-team/node-babel/Gulpfile.js
>> [15:37:17] Starting 'build'...
>> [15:37:17] Cannot convert undefined or null to object
> 
> This error is reported by node-extend-shallow. Looking at yarn.lock, an
> older extend-shallow is required by :
>  - braces@2.3.0
>  - expand-brackets@2.1.4
>  - extglob@2.0.4
>  - fill-range@4.0.0
>  - plugin-error@0.1.2
>  - regex-not@1.0.0
>  - set-value@2.0.0
>  - snapdragon@0.8.1
>  - to-regex@^3.0.2
> 
> I think the best for now it to upgrade all gulp dependencies in experimental

set-value updated, no changes...

Bug#929907: libgnutls30: Connections to older GnUTLS servers break

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

> Is this reproducile with gnutls-cli or is the respective server
> publically accessible? 

It is reproducible.

1. Create a buster chroot for the server, or something
   similar.
2. Install gnutls-bin 3.6.6-3 and ssl-cert.
3. Start something like:
   gnutls-serv --echo --x509keyfile /etc/ssl/private/ssl-cert-snakeoil.key 
--x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem
4. Create a buster chroot for the client.
5. Install gnutls-bin 3.6.7-2 and pwgen (I used that to generate
   random blobs of printable data).
6. Try:
   pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost

- From a size of 16383 bytes onwards, I get:

|<1>| Received packet with illegal length: 16385
|<1>| Discarded message[1] due to invalid decryption
*** Fatal error: A TLS record packet with invalid length was received.
*** Server has terminated the connection abnormally.


After upgrading the server to 3.6.7-2, the problem goes away.

Actually, this might as well be an issue in 3.6.6, that was masked
while clients were also 3.6.6… I don't know ;)!

- -nik
-BEGIN PGP SIGNATURE-

iQJlBAEBCgBPFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlz1locxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYwAKCRC3mjwW
oMTylrJ7D/9ji2A9+audQYrS1BYInzijlV0QBJLO3ZbAUqt0zhD0jp6Xw9gUKIpW
RU/TGNCzPoXusCefCsdRZAXPHt6aMCgu0ir/oPebMqz8PfIDVoqe588E4dF608u1
/QpfpBzf2DJVfwIjuAPXHLpYL7SmCE9HRanRxR1Wdnxg7mfzhnWO0Nq0Ef7+fsvr
ADMoQaQ6bXko6zS8g2+7cVcI9WURwaozErSHujBhJQjbKlAkO0hzGlpUgWYuu/gd
YghSxaCIQRBuPqoF3prFRA1PkdJnJxaVBaWh15laejxxGZTbb7DRqv7MGewm+LUC
oi/QsnfoZ6hdOKCCP4mGzDKn47oZuVh6ldEemhOC7RK0Gzss+1qqx5XXdcOF3Xcr
brxEshkYLvSMqzLZP4JaKe8a2joTYcn42yvkszB1FlTLmBJ1sK93bRIdZQf2FYKo
RT+2oLITjS9tjRbJjrfoIGzCS0UCiNkJeotYBYS33jHU94igTrLOlayNoCmCe++U
KQsn+09eWnGa9jdeAE6gfGzuxz5krvG2dK2cM/+clHak53EkzRQMGX9hKOkpIa0b
Bs+0bKiNbCLSQtaYx4x9vSxWJg/3XOe+TXGu6CwvYFRlTW1ZXz5uOHGvbCyFoTPK
Q4bbKqP+xmcfdxibx18A2rqMsByNOiNqliC9+3PdreZ2pCPeO3X1PA==
=Blay
-END PGP SIGNATURE-

Bug#929781: rkt: CVE-2019-10144 CVE-2019-10145 CVE-2019-10147

[Moritz Mühlenhoff]

On Sun, Jun 02, 2019 at 08:12:50AM +1000, Dmitry Smirnov wrote:
> On Friday, 31 May 2019 4:46:08 PM AEST Salvatore Bonaccorso wrote:
> > The following vulnerabilities were published for rkt.
> > 
> > CVE-2019-10144[0]:
> > rkt: processes run with `rkt enter` are given all capabilities during stage
> > 2
> > 
> > CVE-2019-10145[1]:
> > processes run with rkt enter do not have seccomp filtering during stage 2
> > 
> > CVE-2019-10147[2]:
> > processes run with rkt enter are not limited by cgroups during stage 2
> 
> I do not understand how this is a vulnerability. rkt enter is an interactive 
> root-only command (requires sudo or root access). IMHO interactive root 
> session started by admin (e.g. to enter container for inspection, etc.) 
> should not be restricted.

Well, see 
https://www.twistlock.com/labs-blog/breaking-out-of-coresos-rkt-3-new-cves/,
the claim is that this allows an attacker with root in the rkt container to 
execute
code with root permissions on the host.

Cheers,
Moritz

Bug#927672: CVE-2019-11372 CVE-2019-11373

[Moritz Mühlenhoff]

On Sun, Apr 21, 2019 at 12:00:08AM +0200, Moritz Muehlenhoff wrote:
> Source: libmediainfo
> Severity: important
> Tags: security
> 
> Please see
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11372
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11373

What's the status, can we get that fixed for buster?

Cheers,
Moritz

Bug#929948: CVE-2019-7733

[Moritz Muehlenhoff]

Source: liblivemedia
Severity: important
Tags: security

This was assigned CVE-2019-7733:
https://github.com/rgaufman/live555/issues/21

Cheers,
Moritz
 

Bug#929949: New upstream version 0.8 available, compatible with python3

[Sebastien Bacher]

Package: duplicity
Version: 0.7.18.2-1

Upstream rolled out a 0.8 version which is finally compatible with 
python3, it would be nice to have it uploaded to Debian

https://code.launchpad.net/duplicity/0.8-series/0.8.00/+download/duplicity-0.8.00.tar.gz

Cheers,

Bug#929829: [Pkg-javascript-devel] Bug#929829: gulp 4 cannot build node-babel 7 - Cannot convert undefined or null to object

[Xavier]

Le 01/06/2019 à 12:14, Pirate Praveen a écrit :
> ...
> gulp build
> [15:37:17] Local modules not found in ~/forge/debian/git/js-team/node-babel
> [15:37:17] Try running: npm install
> [15:37:17] Using globally installed gulp
> [15:37:17] Using gulpfile ~/forge/debian/git/js-team/node-babel/Gulpfile.js
> [15:37:17] Starting 'build'...
> [15:37:17] Cannot convert undefined or null to object

This error is reported by node-extend-shallow. Looking at yarn.lock, an
older extend-shallow is required by :
 - braces@2.3.0
 - expand-brackets@2.1.4
 - extglob@2.0.4
 - fill-range@4.0.0
 - plugin-error@0.1.2
 - regex-not@1.0.0
 - set-value@2.0.0
 - snapdragon@0.8.1
 - to-regex@^3.0.2

I think the best for now it to upgrade all gulp dependencies in experimental

Bug#929923: missing dictionaries.xcu confuses non-US English locales (e.g. en_AU)

[Rene Engelhard]

Hi,

On Mon, Jun 03, 2019 at 10:04:02PM +0200, Rene Engelhard wrote:
> $ apt-cache show mythes-en-us
> Package: mythes-en-us
> Source: libreoffice-dictionaries

Sorry, edited and sent too fast. This is the key point here. This mythes
dict is *exactly* what gets shipped in LibreOffice itself. So I don't
understand your comment about it being old and predating
LibreOffice

Regards,
 
Rene

Bug#928026: release-notes: document the state of security support for golang packages in Buster

[Paul Gevers]

Control: tags -1 patch

On Fri, 26 Apr 2019 10:29:58 + Holger Levsen 
wrote:
> package: release-notes

> > This is already an issue in Stretch (e.g. #922170), but will be much
> > worse in Buster, so unless someone reliably commits to work on
> > this ASAP the available options are to drop everything Go apart
> > from the toolchain packages from buster or exclude of all that mess
> > from security updates so that people know what they can expect.
>  
> filing a bug (in coordination with Moritz) so this doesnt get forgotten.

I have pushed a first version (attached).

Paul
From f9cea40327e80aa405fc3878a54fcb4cad313027 Mon Sep 17 00:00:00 2001
From: Paul Gevers 
Date: Mon, 3 Jun 2019 22:06:13 +0200
Subject: [PATCH] issues.dbk: Go and static linking

Closes: #928026
---
 en/issues.dbk | 16 
 1 file changed, 16 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index 481df49b..14993901 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -506,6 +506,22 @@ $ sudo update-initramfs -u
   The same strategy will be applied for Thunderbird.
 
   
+
+  
+Go based packages
+
+  The Debian infrastructure currently doesn't properly enable rebuilding
+  packages that statically link parts of other packages on a large
+  scale. Until buster that hasn't been a problem in practice, but with the
+  growth of the Go ecosystems it means that Go based packages won't be
+  covered by regular security support until the infrastructure is improved
+  to cope with these kind of packages in a maintainable manner.
+
+
+  If updates are warranted, they can only come via regular point releases
+  and thus may be deployed late.
+
+  
 
 
 
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#929940: r-cran-rcmdr: Installation needs to install other packages manually

[Dirk Eddelbuettel]

On 3 June 2019 at 13:21, Dirk Eddelbuettel wrote:
| 
| On 3 June 2019 at 19:21, jpg wrote:
| | Package: r-cran-rcmdr
| | Version: 2.5-1-1
| | Severity: normal
| | 
| | Dear Maintainer,
| | 
| | I have already R and several packages installed.
| | 
| | When I installed r-cran-rcmdr and loaded Rcmdr with "library(Rcmdr), a 
dialogbox said that the
| | following packages were missing :
| | 
| | r-cran-aplpack
| | r-cran-leaps
| | r-cran-multcomp
| | r-cran-lmtest
| | r-cran-sem
| | r-cran-rgl
| | 
| | I manually installed them with aptitude and their dependencies. Then 
everything
| | was fine when I launched Rcmdr again.
| | 
| | I expected that every needed packages were automatically installed.
| 
| There is a difference between _required_ packages and _suggested_ packages.
| Rcmdr has a *very* large footprint.
| 
| See below for a quick analysis without and with Suggests:.  The cost of
| Suggests is prohibitive. Add 'recursive=TRUE' to see the full cost -- for
| Suggests it is on the order of 1400 packages. The current situation is the
| result of a multi-year conversation with the Rcmdr author.
| 
| You can also tell apt / apt-get and other to install (available in Debian)
| suggested packages for you.  That way you skip dialogue. I don't know of the
| top of my head what the option is, but the apt documentation should be
| helpful here.

Here is one quick google query result for 'tell apt-get to install suggested 
packages':


https://askubuntu.com/questions/18545/installing-suggested-recommended-packages/60309

Hth, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#929834: Buster/XFCE unlock screen is blank

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2019-06-03 at 12:59 -0700, Russ Allbery wrote:
> Ah, good call.  I was also seeing other problems with the Intel driver in
> combination with light-locker where the monitor resolution would be set to
> some incorrect value after restore from lock.  This would come with kernel
> errors like:
> 
> [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo 
> underrun on pipe B
> [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO 
> underrun
> 
> and then lots and lots of:
> 
> [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle 
> patterns

My gut feeling is that light-locker just uses codepaths not really used
otherwise, like vt-switch at the same time as suspend/resume or screen off/on.
Unfortunately debugging i915 is completely out of my league (and I already
tried multiple time on other issues).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlz1fv0ACgkQ3rYcyPpX
RFuTTQf+ITXxUm6DnBRNuGwsKbKCFoeXUAiP+v5GdIJDDifEWG91inoF1tf6GswS
l1RRJHYczv9WtjL+6e1522vzAp0h6jw5WuAcQfXcAZZR4n/GU25VVa6gsIqbGIv9
XvsoN+Y/MGdJueg0xYfBTuiInoySchJ4cv2oh56MkcndjgDiPtiH8bAXCcxwBflj
OXkCEUj8LLoOACdTYBWA02vA66daEMRk7Y6gkO+BwbvS/ZeVL1T2xQV0W47obtF5
AaBhx/AwM59Bzk5RUD8EBi5cOWuXB7KIYcuXLzaFjNzk6yXXTAx26740dR8q3CoD
JHld4HjQRllFUxsDiZvz5+1q5+nShw==
=ho8d
-END PGP SIGNATURE-

Bug#929947: unblock: go-dep/0.5.1+really0.5.0-1

[Dr. Tobias Quathamer]

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

Please unblock package go-dep

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock go-dep/0.5.1+really0.5.0-1

Regards,
Tobias
diff -Nru go-dep-0.5.0/debian/changelog go-dep-0.5.1+really0.5.0/debian/changelog
--- go-dep-0.5.0/debian/changelog	2018-08-01 10:41:08.0 +0200
+++ go-dep-0.5.1+really0.5.0/debian/changelog	2019-06-03 21:37:23.0 +0200
@@ -1,3 +1,20 @@
+go-dep (0.5.1+really0.5.0-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert all changes between 0.5.0-1 and 0.5.1-1.
+See https://bugs.debian.org/928227 for a rationale.
+
+ -- Dr. Tobias Quathamer   Mon, 03 Jun 2019 21:37:23 +0200
+
+go-dep (0.5.1-1) unstable; urgency=medium
+
+  * New upstream version 0.5.1
+  * Bump Standards-Version
+  * Update debian/copyright
+  * Update build-dependencies
+
+ -- Hilko Bengen   Sat, 20 Apr 2019 18:16:23 +0200
+
 go-dep (0.5.0-1) unstable; urgency=medium
 
   * New upstream version 0.5.0


signature.asc
Description: OpenPGP digital signature

Bug#929923: missing dictionaries.xcu confuses non-US English locales (e.g. en_AU)

[Rene Engelhard]

tag 929923 + wontfix
thanks

Hi,

On Mon, Jun 03, 2019 at 07:21:47PM +1000, Trent W. Buck wrote:
> Package: mythes-en-us
> Version: 1:5.2.5-1
> Severity: normal
> 
> Hi Rene et al.
> 
> My users are in en_AU.UTF-8 locale.
> They reported that Tools > Thesaurus doesn't work with mythes-en-us installed.
> Debian has a mythes-en-au, but it's a REALLY old one (2011) that predates 
> LibreOffice.

$ apt-cache show mythes-en-us
Package: mythes-en-us
Source: libreoffice-dictionaries
Version: 1:6.2.0-1
Installed-Size: 21468
Maintainer: Debian LibreOffice Maintainers 
Architecture: all
Provides: mythes-thesaurus, mythes-thesaurus-en-us
Depends: dictionaries-common
Suggests: libreoffice-writer
Description-en: English (USA) Thesaurus for LibreOffice
 Libreoffice is a full-featured office productivity suite that provides a
 near drop-in replacement for Microsoft(R) Office.
 .
 This package contains an English (USA) thesaurus for LibreOffice.
Description-md5: 9d435f11edba42588212907de47dc9b8
Multi-Arch: foreign
Homepage: https://wiki.documentfoundation.org/Language_support_of_LibreOffice
Tag: made-of::dictionary, role::app-data, suite::TODO
Section: text
Priority: optional
Filename: pool/main/libr/libreoffice-dictionaries/mythes-en-us_6.2.0-1_all.deb
Size: 3288536
MD5sum: a20256fa3c11071ec45bfba145949ebc
SHA256: 27ff118a697ea629f012e8f9c6ba7bfc975d3414768341c4b1e5609829093b99

rene@frodo:~$ rmadison mythes-en-us
mythes-en-us | 1:3.3.0-4+deb8u1 | oldstable  | all
mythes-en-us | 1:5.2.5-1| stable | all
mythes-en-us | 1:6.2.0-1| testing| all
mythes-en-us | 1:6.2.0-1| unstable   | all

> Upstream, LibreOffice uses a dictionaries.xcu file to say "use the en_US 
> thesaurus for ALL en locales".
> AFAICT Debian doesn't ship dictionaries.xcu files, though they are present in 
> the libreoffice-dictionaries source package.

Yeah, that is a side effect on how we package it. Application-agnostic.

If we packaged it as a LO-only extension we could include that file, as
it is now, not. (and mythes is not used by LO only ttbomk).

rene@frodo:~$ grep-dctrl -FDepends libmythes 
/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
 -sPackage
Package: libreoffice-core
Package: lyx

Package: libmythes-dev
rene@frodo:~$ grep-dctrl -FRecommends mythes 
/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
 -sPackage
(tasks, nothing interesting for this bug.)
rene@frodo:~$ grep-dctrl -FSuggests mythes 
/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
 -sPackage
Package: libreoffice
Package: libreoffice-dev
Package: libreoffice-l10n-af
Package: libreoffice-l10n-am
Package: libreoffice-l10n-ar
Package: libreoffice-l10n-as
Package: libreoffice-l10n-ast
Package: libreoffice-l10n-be
Package: libreoffice-l10n-bg
Package: libreoffice-l10n-bn
Package: libreoffice-l10n-br
Package: libreoffice-l10n-bs
Package: libreoffice-l10n-ca
Package: libreoffice-l10n-cs
Package: libreoffice-l10n-cy
Package: libreoffice-l10n-da
Package: libreoffice-l10n-de
Package: libreoffice-l10n-dz
Package: libreoffice-l10n-el
Package: libreoffice-l10n-en-gb
Package: libreoffice-l10n-en-za
Package: libreoffice-l10n-eo
Package: libreoffice-l10n-es
Package: libreoffice-l10n-et
Package: libreoffice-l10n-eu
Package: libreoffice-l10n-fa
Package: libreoffice-l10n-fi
Package: libreoffice-l10n-fr
Package: libreoffice-l10n-ga
Package: libreoffice-l10n-gd
Package: libreoffice-l10n-gl
Package: libreoffice-l10n-gu
Package: libreoffice-l10n-gug
Package: libreoffice-l10n-he
Package: libreoffice-l10n-hi
Package: libreoffice-l10n-hr
Package: libreoffice-l10n-hu
Package: libreoffice-l10n-id
Package: libreoffice-l10n-is
Package: libreoffice-l10n-it
Package: libreoffice-l10n-ja
Package: libreoffice-l10n-ka
Package: libreoffice-l10n-kk
Package: libreoffice-l10n-km
Package: libreoffice-l10n-kmr
Package: libreoffice-l10n-kn
Package: libreoffice-l10n-ko
Package: libreoffice-l10n-lt
Package: libreoffice-l10n-lv
Package: libreoffice-l10n-mk
Package: libreoffice-l10n-ml
Package: libreoffice-l10n-mn
Package: libreoffice-l10n-mr
Package: libreoffice-l10n-nb
Package: libreoffice-l10n-ne
Package: libreoffice-l10n-nl
Package: libreoffice-l10n-nn
Package: libreoffice-l10n-nr
Package: libreoffice-l10n-nso
Package: libreoffice-l10n-oc
Package: libreoffice-l10n-om
Package: libreoffice-l10n-or
Package: libreoffice-l10n-pa-in
Package: libreoffice-l10n-pl
Package: libreoffice-l10n-pt
Package: libreoffice-l10n-pt-br
Package: libreoffice-l10n-ro
Package: libreoffice-l10n-ru
Package: libreoffice-l10n-rw
Package: libreoffice-l10n-si
Package: libreoffice-l10n-sk
Package: libreoffice-l10n-sl
Package: libreoffice-l10n-sr
Package: libreoffice-l10n-ss
Package: libreoffice-l10n-st
Package: libreoffice-l10n-sv
Package: libreoffice-l10n-ta
Package: libreoffice-l10n-te
Package: libreoffice-l10n-tg
Package: libreoffice-l10n-th
Package: libreoffice-l10n-tn
Package: libreoffice-l10n-tr
Package: 

Bug#928956: Document removal of ecryptfs-utils from Buster

[Paul Gevers]

Hi,

On 02-06-2019 12:45, Justin B Rye wrote:
> Holger Wansing wrote:
 +The ecryptfs-utils 
 package
 +is not part of buster due to an unfixed serious bug (>>> +url="765854">#765854). At the time of 
 writing this
>>>   paragraph, there was no clear advice for users of encryptfs,
>>>   except not to upgrade.
>>
>> Maybe adding something like
>> "or migrate to " 
>> to the end would be helpfu?
>>
>> And also, I wonder if "ecryptfs-utils" (without n) and 
>> encryptfs (with n) are both correct?
> 
> Oops!  Well, I can fix that bit.
> 
> And to make it easier to remember we can use the upstream "brand name"
> spelling "eCryptfs".
> 
> (I wonder: is it "extended" Cryptfs?  "enterprisey" Cryptfs?)

Pushed.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#929834: Buster/XFCE unlock screen is blank

[Russ Allbery]

Yves-Alexis Perez  writes:

> Actually it seems to me that the bug is a bad interaction with light-
> locker/lightdm locking system (which relies on vt switch) and the Intel
> driver. It only seems to happens on this driver, and I think it's also
> been reproduced just by doing vt-switches (but can't remember where it
> was reported).

Ah, good call.  I was also seeing other problems with the Intel driver in
combination with light-locker where the monitor resolution would be set to
some incorrect value after restore from lock.  This would come with kernel
errors like:

[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo 
underrun on pipe B
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO 
underrun

and then lots and lots of:

[drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle 
patterns

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

Bug#929834: Buster/XFCE unlock screen is blank

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2019-06-03 at 21:55 +0200, Yves-Alexis Perez wrote:
> I noted Andreas raised the severity, but I hope someone has an idea how to fix
> that because I don't.

Also, since it was posted on -devel, I guess there's a bit of exposure: if
some people care about Xfce, by all mean please join the team and give a help,
because right now it's basically on my shoulders, with bits of help here and
there from other (mostly on the packaging side, not really on bug triaging). 

It's been like that since years, and it's not really working fine, especially
when I'm not around. And at that point I'm not comfortable anymore with that
because it more likely that I might be “not around” now than before.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlz1e+oACgkQ3rYcyPpX
RFtp6gf/SeqjvtvV/3TZg5DX327r4oJcLku0EggZJWfiyFYM73Erq81YZMNbOTsL
/9xcg6wri9gHZO4+tkzjhdrv0Meuh9+cXHDeBgdg0I9b6HKl1T4Xo6CE7fFvrexn
KgQGqy5Tc1yttQVrPFTI9s+WEhxrByEB70rYHuOQW0TvgKIYaAdpfG1gRV14gw23
vvgeBwNpYSlfiD1Od/lVjkYuyPRcmwi2FNC6sbhSIui3Ll2UppOeFoqA4Y962vnM
XP1cMux8BOEwfHZnjL9bzV7x+tWGFz7l2mbV/Xyew5hHBIstYkFk6VDIJHLxeMd1
nMXCY+neAYb7gzfXQlCNVAg+w63a/w==
=E2SN
-END PGP SIGNATURE-

Bug#929834: Buster/XFCE unlock screen is blank

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2019-05-31 at 18:32 -0700, Russ Allbery wrote:
> This appears to be a bug in light-locker specifically, which is the
> default screen lock program with XFCE with lightdm.  See, for instance:
> 
> https://github.com/the-cavalry/light-locker/issues/114

Actually it seems to me that the bug is a bad interaction with light-
locker/lightdm locking system (which relies on vt switch) and the Intel
driver. It only seems to happens on this driver, and I think it's also been
reproduced just by doing vt-switches (but can't remember where it was
reported).
> 
> Switching to another greeter from the default gtk-greeter appears to help
> according to that bug, which may mean that the bug is actually in
> lightdm-gtk-greeter.  There doesn't appear to be a Debian bug for this; it
> might be a good idea to open one against light-locker (or, if you confirm
> switching to slick-greeter per that bug, lightdm-gtk-greeter).

There are at least a gazillion bugs against light-locker and lightdm, or xfce.
I tried to at least merge some of them (like #846278) but clearly failed to
identify all of them.

And people are still reporting new ones (or posting to -devel) so clearly they
are hard to spot.

Maybe locking through vt-switch is a bad idea,

I noted Andreas raised the severity, but I hope someone has an idea how to fix
that because I don't.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlz1eyAACgkQ3rYcyPpX
RFvkhQf8Dqj0s6569PTiyxfczeA2PV83LWFdBOaCU3FDHv3I3Gdk2E+CR8UpunwI
n+YsAEIU/bixAGVhH8yiPKSJiZg4Zjv7pCLVKNHSeg9vigAIWzjag+dArFQciZkP
4JdqtmJRxPwKyK4v7Fp2u3/DK8kjHvUKr0AafkhVGxo0qSuvTUxqBhiy5CeBX4NP
2lnZ5JE+zUsuweEFomy/FAXMMC8E34eWCWtQ/w4iJlwlUghPLR0YbRANN1sbqz73
MHT/fCF+xCKoSRDQT+UZWNGs9hCEDOpoAydXIuwiMzXxsKG83SFGuCFku4ZGZ0vK
d4nzUUNx7UhpwcGWSKAXOq1TbtfnJA==
=lmZk
-END PGP SIGNATURE-

Bug#928987: compiz: make a compiz-boxmenu package

[Samuel Thibault]

Hello,

Giacomo Boffi, le lun. 03 juin 2019 11:58:38 +0200, a ecrit:
> In the hope that this helps, ciao ፨ gb

Completely, thanks! I have now uploaded a package, it'll now have to
pass through NEW.

Samuel

Bug#929889: debootstrap: Support unconventional PATH on foreign distros

[Tianon Gravi]

On Sun, 2 Jun 2019 at 11:12, Vagrant Cascadian  wrote:
> The following patch fixes issues when the hard-coded
> PATH=/sbin:/usr/sbin:/bin:/usr/bin does not contain chroot or other
> commonly used utilities, by changing to PATH=$PATH:/sbin:...

Do you think it would make sense to instead use "/usr/bin/env" inside
the chroot to just explicitly set PATH to a sane value?  Maybe even
with "-i" to ensure we don't leak any other environment variables too?


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#929945: cairo: CVE-2019-6462

[Salvatore Bonaccorso]

Source: cairo
Version: 1.16.0-4
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/cairo/cairo/issues/353
Control: found -1 1.14.8-1 

Hi,

The following vulnerability was published for cairo, filling for
tracking the issue.

CVE-2019-6462[0]:
| An issue was discovered in cairo 1.16.0. There is an infinite loop in
| the function _arc_error_normalized in the file cairo-arc.c, related to
| _arc_max_angle_for_tolerance_normalized.


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-6462
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6462
[1] https://gitlab.freedesktop.org/cairo/cairo/issues/353

Regards,
Salvatore

Bug#929944: cairo: CVE-2019-6461

[Salvatore Bonaccorso]

Source: cairo
Version: 1.16.0-4
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/cairo/cairo/issues/352
Control: found -1 1.14.8-1

Hi,

The following vulnerability was published for cairo, filling for
tracking.

CVE-2019-6461[0]:
| An issue was discovered in cairo 1.16.0. There is an assertion problem
| in the function _cairo_arc_in_direction in the file cairo-arc.c.


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-6461
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6461
[1] https://gitlab.freedesktop.org/cairo/cairo/issues/352

Regards,
Salvatore

Bug#929943: linux-image-4.19.0-5-amd64: NFS handle leak? Suspend-to-RAM inhibition

[Philipp Marek]

Package: src:linux
Version: 4.19.37-3
Severity: normal

Sequence of events:

 1. Notebook is rebooted properly, used for work for some hours
 2. Notebook lid was closed, STR works as usual
 3. Notebook opened; some work; lid close, STR works
 4. Notebook was opened; NFS4 from remote machine mounted
 5. Files copied around
 6. NFS server stopped (data only temporarily shared)
 7. NFS unmounted via "umount dir/", returns immediately to shell
 7. I remember that I stopped the server already, "umount dir/ -f &"
 9. Closing the lid
 6. About half an hour later I take the notebook from my bag and see that 
it's still running
10. I see the messages about NFS
11. I start NFS again for a clean umount - but it's not mounted any more, 
so there's nothing to umount
12. Manual "acpitool -s" (twice) doesn't work (19:34:26)
13. I stop the NFS server again
14. Closing the lid still doesn't work
15. I start NFS again
16. At 20:00 an "at" job stops the NFS server again
17. MUCH LATER one of the backgrounded "acpitool -s" seems to work, 
notebook gets suspended while I'm working with it
18. Something's still thinking that NFS is mounted


Here's some log data, shortened/annotated:

  16:24:14  2. PM: suspend entry (deep)
  16:24:14 PM: Syncing filesystems ... done.
  16:49:34  3. PM: suspend exit
  17:13:53  "  PM: suspend entry (deep)
  18:23:36  "  PM: Syncing filesystems ... done.
  18:23:36  4. PM: suspend exit
  18:41:39  9. PM: suspend entry (deep)
  18:43:31 PM: Syncing filesystems ...
  18:45:12 10. INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:47:13 INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:49:14 INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:51:14 INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:53:15 INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:55:16 INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:57:17 INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:59:18 INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  19:01:19 INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  19:03:19 INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  19:32:34 11. nfs: server rpi3 OK
  19:34:26 12. PM: suspend entry (deep)
  19:34:26 PM: suspend exit
  19:34:30 PM: suspend entry (deep)
  19:34:30 PM: suspend exit
  19:37:09 14. PM: suspend entry (deep)
  19:37:09 PM: suspend exit
  19:40:27 15. nfs: server rpi3 OK
  20:52:49 17. done.
  20:52:49 Freezing user space processes ... (elapsed 0.029 seconds) done.  

 
  20:52:49 18. PM: suspend exit 
  20:55:33 nfs: server rpi3 not responding, timed out


I know this is not that easy to understand; still, I hope it's 
reproducible.

Thank you!


-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/n555--vg-root ro 
initrd=/install/initrd.gz quiet

** Not tainted

Bug#926118: Alternative for Re: Bug#926118: unblock: libmspack/0.10.1-1

[Paul Gevers]

Control: tags -1 moreinfo confirmed

Hi Jens, duck,

On 01-06-2019 17:47, Jens Reyer wrote:
> I'm posting this now because I'm really worried about the lack of
> progress with this issue.  However as stated before by me in this bug
> here, and by the libmspack maintainer in #923885, we both think that
> 0.10.1-1 is for various reasons better, and better tested and thus risk
> free.

I acknowledge your view. I don't think the freeze time (and process) is
great for anybody.

> About this alternative version here:
> 
> +libmspack (0.10.1+really0.8-0.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Revert back to libmspack/0.8-1.
> +  * Add build-dependency on quilt.
> +  * Add patch from upstream to fix regression when extracting cabinets
> +using -F option (Closes: #912687).
> +
> + -- Jens Reyer   Sat, 01 Jun 2019 14:32:06 +0200
> +
> 
> 
> 1.) Versioning and targeted suite
> 
> This proposal reverts the upstream version back from 0.10 (unstable) to
> 0.8 (testing), therefore the "new" upstream version 0.10.1+really0.8.
> For building I just symlinked the 0.8 orig.tar.
> 
> It's based directly on 0.8-1, dropping all debian/ changes (including
> the changelog) since then.
> 
> So this version should be fine to go via unstable (not sure about the
> reverted d/changelog)).

We prefer this route.

> Alternatively we could go via testing-proposed.>
> 
> 2.) Code
> 
> I took only the "fix" part from the upstream commit fixing this, but not
> the documentation or updated testsuite (which includes changed binaries).
> 
> I verified that the issue affecting winetricks is solved.
> 
> I assume a fix for #914794 (libmspack fails tests on big endian
> architectures (s390x, mips)), reported against 0.9.1-1 is not necessary.
>  However if that was caused by a change in the toolchain instead of
> changes in the package, I'll also add that fix here.
> 
> 
> 
> 
> I'm looking forward to get some feedback from the release team,
> preferably by:
> 
> unblock libmspack/0.10.1-1
> 
> Otherwise please tell us if we should go with this version (targeting
> unstable or testing-proposed?), or something else (e.g. filing bugs for
> every issue fixed in 0.10.1-1)
> 
> Before (if at all) doing any upload I'll of course coordinate it with
> the libmspack maintainer.

Please align. I'll unblock the targeted fix you propose above. Seeing
the progress on the current package, I don't think you should expect the
current version to be unblocked before buster.

You can remove the moreinfo tag when the +really package is ready to be
unblocked.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#929916: libreswan: CVE-2019-12312

[Salvatore Bonaccorso]

Hi Daniel!

On Mon, Jun 03, 2019 at 12:24:08PM -0400, Daniel Kahn Gillmor wrote:
> On Mon 2019-06-03 06:26:28 +0200, Salvatore Bonaccorso wrote:
> > Source: libreswan
> > Version: 3.27-4
> > Severity: grave
> > Tags: patch security upstream fixed-upstream
> > Justification: user security hole
> > Forwarded: https://github.com/libreswan/libreswan/issues/246
> > Control: fixed -1 3.28-1
> >
> > The following vulnerability was published for libreswan.
> >
> > CVE-2019-12312[0]:
> > | In Libreswan before 3.28, an assertion failure can lead to a pluto IKE
> > | daemon restart. An attacker can trigger a NULL pointer dereference by
> > | sending two IKEv2 packets (init_IKE and delete_IKE) in 3des_cbc mode
> > | to a Libreswan server. This affects send_v2N_spi_response_from_state
> > | in programs/pluto/ikev2_send.c when built with Network Security
> > | Services (NSS).
> 
> thanks for this heads-up, Salvatore.
> 
> I'm working with upstream libreswan at patching this now, publishing my
> work on the debian/master branch in salsa.

The upstream issue lists as
https://github.com/libreswan/libreswan/commit/7142d2c37d58cf024595a7549f0fb0d3946682f8
as the fixing commit, fwiw.

> out of curiosity, how was this CVE applied for, and how was it
> coordinated?  When I pointed it out to libreswan upstream on the
> freenode IRC #swan, it sounded like they had never heard of it.

I do not know. The CVE appeared for us on the radar via the MITRE feed
update. Could be that the reporter of the upstream issue did request a
CVE on its own. If you ask MITRE they though would not disclose who
requested a specific CVE, so we might not know in the end. I suspect
it was not coordinated at all with upstream.

> thanks for all you do for debian security!

likewise for all your contributions within Debian!

Regards,
Salvatore

Bug#929942: Bug in libreoffice-writer / Biolinum open type font

[Florian Nisbach]

Package: libreoffice-writer
Version: 1:6.1.5-3

Package: fonts-linuxlibertine
Version: 5.3.0-4

When a document contains a lowercase italic "m" in the open type font Linux
Biolinum O, the following two things happen:
* on prinouts, the m does not appear
* if exported to PDF (or printed to PDF), broken PDF files are produced,
e.g. the whole pages containing an m are not visible in evince.

The bug does NOT appear
* using Linux Libertine O instead of Biolinum
* outside of libreoffice (tested in inkscape)
* using the True Type version of the Linux Biolinum fonts from
libertine-fonts.org
* using the Libertinus Sans font from github.com/alif-type/libertinus

I'm attaching a demo otf and pdf file (the latter exported to pdf from
Libreoffice Writer)

I run Debian GNU/Linux 10, kernel 4.19.0-5-amd64, libc6 2.28-10.
Best, Florian


Strange-m-bug.odt
Description: application/vnd.oasis.opendocument.text


Strange-m-bug.pdf
Description: Adobe PDF document

Bug#538008: dante-server: disregard my message from june 3

[xavier renaut]

Package: dante-server
Followup-For: Bug #538008

Dear Maintainer,

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

Please disregard my message from june 3 where I wasnt able to start the dante 
server.
on a normal vm (ec2) with stable kernel, with sysv-rc, it starts without issues.

(the previous report is on openvz with old kernel)


   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages dante-server depends on:
ii  libc6 2.24-11+deb9u4
ii  libpam0g  1.1.8-3.6
ii  libwrap0  7.6.q-26
ii  lsb-base  9.20170808

dante-server recommends no packages.

dante-server suggests no packages.

Bug#929931: CTDB: Debian Enablement (focus: NFS HA)

[Rafael David Tinoco]

https://bugs.launchpad.net/debian/+source/ctdb/+bug/722201/comments/19



Future possible issue While ctdb is not merged to *at least* samba-4.9.7
(in Debian):

commit 022b9a6ca7d8cb6f541b1b24b27da4e1a3bea04b
Author: Martin Schwenke 
Date: Tue Mar 26 00:49:49 2019

ctdb-scripts: Add test variable CTDB_NFS_DISTRO_STYLE

BUG: https://bugzilla.samba.org/show_bug.cgi?id=13860

Signed-off-by: Martin Schwenke 
Reviewed-by: Amitay Isaacs 
(cherry picked from commit e72c3c800a50fe746164e319e21180c44d041619)


/etc/ctdb/nfs-linux-kernel-callout :

TODO:

 - place non-upstream (?) patch (DEP3) inside debian/patches (quilt):

 # Red Hat
 # nfs_service="nfs"
 # nfslock_service="nfslock"
 # nfs_config="/etc/sysconfig/nfs"

 # SUSE
 # nfs_service="nfsserver"
 # nfslock_service=""
 # nfs_config="/etc/sysconfig/nfs"

 # Debian
 nfs_service="nfs-kernel-server"
 nfslock_service=""
 nfs_config="/etc/default/nfs-kernel-server"



https://bugs.launchpad.net/debian/+source/ctdb/+bug/722201/comments/21



Future possible issue while ctdb is not merged to *at least* samba-4.9.8
(in Debian):

commit 49fa08814e2a1032e88353eec42b952316d6ec18
Author: Martin Schwenke 
Date: Wed Mar 20 07:22:43 2019

ctdb-scripts: Update statd-callout to try several configurationfiles

The alternative seems to be to try something via CTDB_NFS_CALLOUT.
That would be complicated and seems like overkill for something this
simple.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=13860

Signed-off-by: Martin Schwenke 
Reviewed-by: Amitay Isaacs 
(cherry picked from commit a2bd4085896804ee2da811e17f18c78a5bf4e658)

BUT, still, isn't appropriate since Debian systemd NFS server script is
called either nfs-kernel-server.service (or an alias called
nfs-server.service) OR nfs-ganesha.service (if using the userland nfs
server version).

/etc/ctdb/statd-callout:

 - place non-upstream (?) patch (DEP3) inside debian/patches(quilt)

 load_system_config "nfs-kernel-server"
 ...
 ctdb_setup_state_dir "service" "nfs-kernel-server"



TODO: NFS_HOSTNAME variable is mandatory for CTDB PUBLIC ADDRS

 - ctdb has to depend on nfs-common
(/usr/lib/systemd/scripts/nfs-utils_env.sh)
 - ctdb has to update /usr/lib/systemd/scripts/nfs-utils_env.sh ->
NFS_HOSTNAME=nodename
 - /etc/default/nfs-common has to be updated -> NFS_HOSTNAME=nodename



https://bugs.launchpad.net/ubuntu/+source/samba/+bug/722201/comments/23
BUG: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1821775
BUG: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1828799



TODO: Missing needed directories and files for initial start to work

 - ctdb.postinst and ctdbpostrm to create and delete
/var/lib/ctdb{volatile,persistent,state}
 - ctdb.postinst and ctdbpostrm to create and delete /etc/ctdb/nodes
(127.0.0.1 only) and /etc/ctdb/public_addresses (empty) files.
 - tmpfiles.d to create /run/ctdb



signature.asc
Description: OpenPGP digital signature

Bug#929597: CVE-2019-12211 CVE-2019-12212 CVE-2019-12213 CVE-2019-12214

[Anton Gladky]

There is no upstream fix still available.

I am planning to decrease the severity of
the ticket to normal and track it as a simple
security issue.

Anton

Am Mo., 27. Mai 2019 um 23:01 Uhr schrieb Anton Gladky :
>
> CVE-2019-12214 does not affect buster and stretch.
> Jessie should be double checked because an older
> version is used there.
>
> Anton
>
> Am So., 26. Mai 2019 um 22:01 Uhr schrieb Anton Gladky :
> >
> > Hi Moritz,
> >
> > thanks for the reporting. As far as I see, there is still
> > no available fix from upstream.
> >
> > Cheers
> >
> > Anton
> >
> > Am So., 26. Mai 2019 um 21:27 Uhr schrieb Moritz Muehlenhoff 
> > :
> > >
> > > Source: freeimage
> > > Severity: grave
> > > Tags: security
> > >
> > > Please see
> > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12211
> > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12212
> > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12213
> > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12214
> > >
> > > Cheers,
> > > Moritz
> > >
> > > --
> > > debian-science-maintainers mailing list
> > > debian-science-maintain...@alioth-lists.debian.net
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#929941: [INTL:da] Danish translation of the template debian-security-support

[Joe Dalton]

Package: debian-security-support
Severity: wishlist
Tags: l10n patch

Please include the attached Danish debian-security-support translation

joe@debianbuster:~/over/debianp/debian-security-support$ msgfmt --statistics -c 
-v -o /dev/null da.po
da.po: 21 oversatte tekster.

bye
Joe

da.po.tar.bz2
Description: application/bzip

Bug#929525:

[Aidan Sojourner]

Hello,

I have the same bug. I believe the issue is due to the primus package
recommending the legacy driver in addition to the current driver. Is this
the intended behavior?
Note that I _was_ able to upgrade my nvidia packages with
--no-install-recommends.

Bug#929940: r-cran-rcmdr: Installation needs to install other packages manually

[jpg]

Package: r-cran-rcmdr
Version: 2.5-1-1
Severity: normal

Dear Maintainer,

I have already R and several packages installed.

When I installed r-cran-rcmdr and loaded Rcmdr with "library(Rcmdr), a 
dialogbox said that the
following packages were missing :

r-cran-aplpack
r-cran-leaps
r-cran-multcomp
r-cran-lmtest
r-cran-sem
r-cran-rgl

I manually installed them with aptitude and their dependencies. Then everything
was fine when I launched Rcmdr again.

I expected that every needed packages were automatically installed.

Thanks for your attention
JP



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages r-cran-rcmdr depends on:
ii  r-base-core [r-api-3.5]  3.5.2-1
ii  r-cran-abind 1.4-5-1.2
ii  r-cran-car   3.0-2-1
ii  r-cran-effects   4.1.0-1
ii  r-cran-rcmdrmisc 2.5-1-1
ii  r-cran-relimp1.0-5-3
ii  r-cran-tcltk21.2-11-2

r-cran-rcmdr recommends no packages.

Versions of packages r-cran-rcmdr suggests:
ii  r-cran-knitr 1.21+dfsg-2
ii  r-cran-markdown  0.9+dfsg-1
pn  r-cran-rodbc 

-- no debconf information

Bug#929907: libgnutls30: Connections to older GnUTLS servers break

[Andreas Metzler]

Control: severity -1 serious

On 2019-06-03 Dominik George  wrote:
> Package: libgnutls30
> Version: 3.6.7-3
> Severity: grave
> Justification: renders package unusable

> The update to 3.6.7-3 reproducibly breaks ldap-utils (or, maybe,the ldap
> client library) when connecting to a server with the previous 3.6.6-2
> version.  I am afraid it breaks more than that.  GnuTLS-secured connections
> are just closed with no visible reason.

> Seen on more than 12 systems, then went to a system that had not got the
> update yet.  An ldapsearch works with 3.6.6-2, and fails after updating to
> 3.6.7-3 with the connection just being closed after reading some data from
> the LDAP server setill on 3.6.6-2.  Upgrading GnuTLS to 3.6.7-3 on the
> server made the problem go away.

Hello,

Is this reproducile with gnutls-cli or is the respective server
publically accessible? 

> I am setting this critical as I cannot imagine it is expected that GnuTLS
> clients require the server to be the exact same version.

Downgrading to serious for the time being, critical means something
different. [1]

cu Andreas

[1] https://www.debian.org/Bugs/Developer.en.html#severities

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#538008: dante-server: dante won't start at boot

[xavier renaut]

Package: dante-server
Version: 1.4.2+dfsg-5
Followup-For: Bug #538008

Dear Maintainer,

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

   * What led up to the situation?

configuring dante like this : 

/etc/danted.conf :
internal: eth0 port = 1080
external: eth0


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

install dante-server
configure
reboot



   * What was the outcome of this action?

dante was not started : 

Jun  3 13:11:51 accessproxy danted[1185]: warning: bindinternal(): bind of 
address fe80::f84c:f9ff:fed2:3371.1080 (address #2/2) for server to listen on 
failed: Cannot assign requested address
Jun  3 13:11:51 accessproxy danted[1185]: error: serverinit(): failed to bind 
internal addresses: Cannot assign requested address
Jun  3 13:11:51 accessproxy danted[1185]: alert: mother[1/1]: shutting down



   * What outcome did you expect instead?

Jun  3 13:35:13 accessproxy danted[5452]: info: Dante/server[1/1] v1.4.1 running



I'm on machine with sysv, not systemd : 

ii  sysv-rc 2.88dsf-59.9   all  
System-V-like runlevel change mechanism
ii  sysvinit-core   2.88dsf-59.9   amd64
System-V-like init utilities
ii  sysvinit-utils  2.88dsf-59.9   amd64
System-V-like utilities


I also tried to add $network in the init script : 
# Required-Start:$remote_fs $syslog $network

but it doesnt help.

thanks.


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


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

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

Versions of packages dante-server depends on:
ii  libc6 2.24-11+deb9u4
ii  libpam0g  1.1.8-3.6
ii  libwrap0  7.6.q-26
ii  lsb-base  9.20170808

dante-server recommends no packages.

dante-server suggests no packages.

Bug#928746: unblock: zfs-linux/0.7.13-1

[Sam Hartman]

Please start talking to the kernel team now, and let them know your
position.

If you strongly suspect you're going to file an RC bug in the future,
you should be talking now, not just holding back.

I'm available to mediate if that ends up being useful.

Bug#929939: ITP: pizzly -- gene-fusion detection with kallisto

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: pizzly
* URL : http://github.com/pmeisted/pizzly
* License : BSD
  Programming Lang: C++
  Description : gene-fusion detection with kallisto

Team-maintained on https://salsa.debian.org/med-team/pizzly

Bug#929938: linux: please enable CONFIG_XFRM_STATISTICS=y

[Daniel Kahn Gillmor]

X-Debbugs-Cc: Paul Wouters 
Package: linux
Version: 4.19.37-3
Control: affects -1 libreswan

0 dkg@alice:~$ grep CONFIG_XFRM_STATISTICS /boot/config-4.19.0-5-amd64 
# CONFIG_XFRM_STATISTICS is not set
0 dkg@alice:~$ 

Paul Wouters, Libreswan upstream developer says:

> Still this kernel option is the only way to get IPsec kernel error
> counters, which are the only diagnostic available for kernel IPsec, so
> they should really enable it.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#781961: systemd-logind integration for XScreenSaver

[Jamie Zawinski]

> Jamie, if there is a way to sync on the X server actually completing its
> work, then we could do that instead.

xscreensaver-command uses XSendEvent to send the ClientMessage to xscreensaver; 
it then waits up to 10 seconds for a response message to be written to the 
window. However, that the response is sent when xscreensaver has *begun* the 
process of blanking the screen, not after. It's probably only a few hundred 
instructions, but there are a couple of X11 round-trips before that window 
shows up. Also recall that if the user has "fade" turned on, blanking the 
screen could involve a multi-second animation.

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#929937: dovecot-lmtpd: _fully_ support RfC 5233 (Sieve Subaddress Extension) for LMTP transport

[Paul Muster]

Package: dovecot-lmtpd
Version: 1:2.2.27-3+deb9u4
Severity: wishlist
Tags: upstream

Dear Maintainer,

Dovecot's LMTP implementation and Pigeonhole Sieve already do support
the  format. RfC 5233, the Sieve subaddress
extension, also offers .

Way forward could be like this:

1) Introduce a new config option 'detail_affix' with parameters 'prefix'
and 'suffix', defaulting to 'suffix' making sur
If 'detail_affix' is switched to 'prefix' the expected format of local
parts turns into  respec

2) Add documentation to the Wiki https://wiki2.dovecot.org/LMTP:

* detail_affix = suffix

3) Add description to the relevant default config files¹:

  # The separator that is expected between the :user and :detail
  # address parts introduced by the subaddress extension. This may
  # also be a sequence of characters (e.g. '--'). The current
  # implementation looks for the separator from the left of the
  # localpart and uses the first one encountered. The :user part is
  # left of the separator and the :detail part is right. This setting
  # is also used by Dovecot's LMTP service.
  #recipient_delimiter = +
+
+ # Define if :detail is a prefix or a suffix to the :user address part,
+ # e.g. left or right, when using subaddress extension.
+ # Defaults to 'suffix' making sure not to break existing setups using
+ #  format.
+ # Switch to 'prefix' if you use the  format
+ # described in RfC 5233.
+ #detail_affix = suffix

4) Changelog

   + now we _fully_ support IETF RfC 5233² (Sieve Subaddress Extension),
 see new config parameter 'detail_affix'.


What do you think?

BTW: Posting on Upstream's Mailing List dove...@dovecot.org:
https://dovecot.org/pipermail/dovecot/2019-May/115884.html

Thanks & greetings,

Paul


¹ On my Debian this is
/etc/dovecot/conf.d/20-lmtp.conf
and
/etc/dovecot/conf.d/90-sieve.conf

² https://tools.ietf.org/html/rfc5233

-- Package-specific info:

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

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

Versions of packages dovecot-lmtpd depends on:
ii  dovecot-core  1:2.2.27-3+deb9u4
ii  libc6 2.24-11+deb9u3
ii  ucf   3.0036

dovecot-lmtpd recommends no packages.

dovecot-lmtpd suggests no packages.

Versions of packages dovecot-lmtpd is related to:
ii  dovecot-core [dovecot-common]  1:2.2.27-3+deb9u4
pn  dovecot-dbg
pn  dovecot-dev
pn  dovecot-gssapi 
ii  dovecot-imapd  1:2.2.27-3+deb9u4
ii  dovecot-ldap   1:2.2.27-3+deb9u4
ii  dovecot-lmtpd  1:2.2.27-3+deb9u4
ii  dovecot-managesieved   1:2.2.27-3+deb9u4
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
ii  dovecot-sieve  1:2.2.27-3+deb9u4
pn  dovecot-sqlite 

-- no debconf information

Bug#929936: dovecot-sieve: _fully_ support RfC 5233 (Sieve Subaddress Extension)

[Paul Muster]

Package: dovecot-sieve
Version: 1:2.2.27-3+deb9u4
Severity: wishlist
Tags: upstream

Dear Maintainer,

Dovecot's LMTP implementation and Pigeonhole Sieve already do support
the  format. RfC 5233, the Sieve subaddress
extension, also offers .

Way forward could be like this:

1) Introduce a new config option 'detail_affix' with parameters 'prefix'
and 'suffix', defaulting to 'suffix' making sure not to break existing
setups using  respectively
:user:detail format.
If 'detail_affix' is switched to 'prefix' the expected format of local
parts turns into  respectively
:detail:user.

2) Add documentation to the Wiki https://wiki2.dovecot.org/LMTP:

* detail_affix = suffix

3) Add description to the relevant default config files¹:

  # The separator that is expected between the :user and :detail
  # address parts introduced by the subaddress extension. This may
  # also be a sequence of characters (e.g. '--'). The current
  # implementation looks for the separator from the left of the
  # localpart and uses the first one encountered. The :user part is
  # left of the separator and the :detail part is right. This setting
  # is also used by Dovecot's LMTP service.
  #recipient_delimiter = +
+
+ # Define if :detail is a prefix or a suffix to the :user address part,
+ # e.g. left or right, when using subaddress extension.
+ # Defaults to 'suffix' making sure not to break existing setups using
+ #  format.
+ # Switch to 'prefix' if you use the  format
+ # described in RfC 5233.
+ #detail_affix = suffix

4) Changelog

   + now we _fully_ support IETF RfC 5233² (Sieve Subaddress Extension),
 see new config parameter 'detail_affix'.


What do you think?

BTW: Posting on Upstream's Mailing List dove...@dovecot.org:
https://dovecot.org/pipermail/dovecot/2019-May/115884.html

Thanks & greetings,

Paul


¹ On my Debian this is
/etc/dovecot/conf.d/20-lmtp.conf
and
/etc/dovecot/conf.d/90-sieve.conf

² https://tools.ietf.org/html/rfc5233


-- Package-specific info:

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

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

Versions of packages dovecot-sieve depends on:
ii  dovecot-core  1:2.2.27-3+deb9u4
ii  libc6 2.24-11+deb9u3
ii  ucf   3.0036

dovecot-sieve recommends no packages.

dovecot-sieve suggests no packages.

Versions of packages dovecot-sieve is related to:
ii  dovecot-core [dovecot-common]  1:2.2.27-3+deb9u4
pn  dovecot-dbg
pn  dovecot-dev
pn  dovecot-gssapi 
ii  dovecot-imapd  1:2.2.27-3+deb9u4
ii  dovecot-ldap   1:2.2.27-3+deb9u4
ii  dovecot-lmtpd  1:2.2.27-3+deb9u4
ii  dovecot-managesieved   1:2.2.27-3+deb9u4
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
ii  dovecot-sieve  1:2.2.27-3+deb9u4
pn  dovecot-sqlite 

-- no debconf information

Bug#929916: libreswan: CVE-2019-12312

[Daniel Kahn Gillmor]

On Mon 2019-06-03 06:26:28 +0200, Salvatore Bonaccorso wrote:
> Source: libreswan
> Version: 3.27-4
> Severity: grave
> Tags: patch security upstream fixed-upstream
> Justification: user security hole
> Forwarded: https://github.com/libreswan/libreswan/issues/246
> Control: fixed -1 3.28-1
>
> The following vulnerability was published for libreswan.
>
> CVE-2019-12312[0]:
> | In Libreswan before 3.28, an assertion failure can lead to a pluto IKE
> | daemon restart. An attacker can trigger a NULL pointer dereference by
> | sending two IKEv2 packets (init_IKE and delete_IKE) in 3des_cbc mode
> | to a Libreswan server. This affects send_v2N_spi_response_from_state
> | in programs/pluto/ikev2_send.c when built with Network Security
> | Services (NSS).

thanks for this heads-up, Salvatore.

I'm working with upstream libreswan at patching this now, publishing my
work on the debian/master branch in salsa.

out of curiosity, how was this CVE applied for, and how was it
coordinated?  When I pointed it out to libreswan upstream on the
freenode IRC #swan, it sounded like they had never heard of it.

thanks for all you do for debian security!

--dkg


signature.asc
Description: PGP signature

Bug#928746: unblock: zfs-linux/0.7.13-1

[Mo Zhou]

control: retitle -1 unblock: zfs-linux/0.7.12-6 (or 0.7.13-1)
control: close -1

Hi Release Team,

On 2019-06-03 15:05, Mo Zhou wrote:
> Patching the kernel is impossible because kernel maintainers
> refused to do that. So that's an invalid solution.

After a short discussion with Aron Xu, I realized that I made
a mistake about the kernel SIMD problem.

It's the ***LTS KERNEL UPDATE*** that breaks ZFS 0.7.12-2.
It's not a bug of 0.7.12-2 at all. An LTS KERNEL UPDATE
that BREAKS stuff indicates a grave RC.

> I'll never argue about ZFS unblock again for Buster.

Sorry and I decided to give up the unblock request.
We[2] Debian ZoL maintainers decided to do nothing about
the kernel SIMD issue and we'll file an RC bug against
the kernel immediately after the 10.1 point release
because it breaks stuff.

[1]
https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730
[2] Aron and Me.

Bug#929935: unblock: golang-github-magiconair-properties/1.8.1+really1.8.0-1

[Dr. Tobias Quathamer]

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

Please unblock package golang-github-magiconair-properties

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock golang-github-magiconair-properties/1.8.1+really1.8.0-1

Regards,
Tobias
diff -Nru golang-github-magiconair-properties-1.8.0/debian/changelog golang-github-magiconair-properties-1.8.1+really1.8.0/debian/changelog
--- golang-github-magiconair-properties-1.8.0/debian/changelog	2018-06-26 10:58:49.0 +0200
+++ golang-github-magiconair-properties-1.8.1+really1.8.0/debian/changelog	2019-06-03 17:42:15.0 +0200
@@ -1,3 +1,20 @@
+golang-github-magiconair-properties (1.8.1+really1.8.0-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert all changes between 1.8.0-1 and 1.8.1-1.
+See https://bugs.debian.org/928227 for a rationale.
+
+ -- Dr. Tobias Quathamer   Mon, 03 Jun 2019 17:42:15 +0200
+
+golang-github-magiconair-properties (1.8.1-1) unstable; urgency=medium
+
+  * New upstream version 1.8.1
+  * Update Maintainer email address to team+pkg...@tracker.debian.org
+  * Bump Standards-Version to 4.3.0 (no change)
+  * Update copyright years in debian/copyright
+
+ -- Anthony Fok   Fri, 24 May 2019 10:45:35 -0600
+
 golang-github-magiconair-properties (1.8.0-1) unstable; urgency=medium
 
   [ Alexandre Viau ]


signature.asc
Description: OpenPGP digital signature

Bug#929929: Being unable to build with >= 4.19.38 is an RC

[Mo Zhou]

control: close -1

I made a big mistake. It's the ***LTS KERNEL UPDATE***
that breaks ZFS 0.7.12-2. It's not a ZFS bug at all!

An LTS KERNEL UPDATE that breaks stuff is where the
grave RC lies.

Bug#929934: unblock: golang-github-disintegration-imaging/1.6.0+really1.5.0-1

[Dr. Tobias Quathamer]

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

Please unblock package golang-github-disintegration-imaging

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock golang-github-disintegration-imaging/1.6.0+really1.5.0-1

Regards,
Tobias
diff -Nru golang-github-disintegration-imaging-1.5.0/debian/changelog golang-github-disintegration-imaging-1.6.0+really1.5.0/debian/changelog
--- golang-github-disintegration-imaging-1.5.0/debian/changelog	2018-12-20 01:19:10.0 +0100
+++ golang-github-disintegration-imaging-1.6.0+really1.5.0/debian/changelog	2019-06-03 17:27:43.0 +0200
@@ -1,3 +1,18 @@
+golang-github-disintegration-imaging (1.6.0+really1.5.0-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert all changes between 1.5.0-1 and 1.6.0-1.
+See https://bugs.debian.org/928227 for a rationale.
+
+ -- Dr. Tobias Quathamer   Mon, 03 Jun 2019 17:27:43 +0200
+
+golang-github-disintegration-imaging (1.6.0-1) unstable; urgency=medium
+
+  * New upstream version 1.6.0
+  * Bump Standards-Version to 4.3.0 (no change)
+
+ -- Anthony Fok   Sun, 14 Apr 2019 03:57:23 -0600
+
 golang-github-disintegration-imaging (1.5.0-1) unstable; urgency=medium
 
   * New upstream version 1.5.0


signature.asc
Description: OpenPGP digital signature

Bug#792567: Bug#929747: qa.debian.org: Please add cross-buildability in summary

[Johannes Schauer]

Hi,

On Mon, 3 Jun 2019 17:12:22 +0200 Helmut Grohne  wrote:
> On Thu, May 30, 2019 at 05:22:12PM +0200, Helmut Grohne wrote:
> > On Thu, May 30, 2019 at 10:57:52AM +0200, Samuel Thibault wrote:
> > > https://tracker.debian.org/ has a link to the cross-buildability status
> > > of a package. It'd be useful to have a tick or cross on the
> > > https://qa.debian.org/developer.php page, e.g. in the CI/Rep column, as
> > > a link to the cross-buildability status, to be able to easily check the
> > > status of one's own packages.
> > 
> > If you do, please consider:
> >  * crossqa.d.n only works on unstable. If a package is not in unstable,
> >there shouldn't be a link. (e.g. gcc-9)
> >  * crossqa.d.n only fills a page if there is some package built for one
> >of the architectures being tested. Therefore no link should be
> >emitted for indep-only packages. Currently, we test for any non-x86
> >release architecture, so if a package only builds for some x86, it
> >will be 404 as well.
> > 
> > If some API is missing in the service, please get in touch with me.
> 
> I talked with Christoph about the missing APIs and it became clear to us
> that publishing cross build status doesn't make sense as long as
> satisfiability isn't published. qa.d.o. does compute satisfiability for
> a while now:
> 
> https://qa.debian.org/dose/debcheck/cross_unstable_main_amd64/
> 
> Please integrate a satisfiability status before integrating crossqa.d.n.
> 50% of packages are cross-unsatisfiable, so this is the big fish.

bug #792567 is also relevant in this context. This bug asks for including cross
build dependency satisfiability from qa.d.o/dose/debcheck. Bug #792567 asks for
including build dependency and normal dependeny satisfiability results from
qa.d.o/dose/debcheck. Since the data for both issues comes from the same source
and since the data for both issues is exported in the same format, fixing one
of these bugs will make it trivial to also fix the other.

As the author of the feature that made qa.d.o/dose/debcheck export machine
readable data and as the author of some commits to distro-tracker (which
already includes the results of qa.d.o/dose/debcheck), I wanted to give an
overview of the machine readable interface to qa.d.o/dose/debcheck.

Basically you are interested in:

https://qa.debian.org/dose/debcheck/SCENARIO/latest/some.txt

Where SCENARIO can be one of:

 - "unstable_main" for dependency satisfaction problems of binary packages in
   unstable
 - "src_unstable_main" build dependency satisfaction of source packages in
   unstable
 - "cross_unstable_main" cross build dependency satisfaction of source packages
   built on amd64 for all other release architectures in unstable

The format is line-based and values are separated by a '#'. The values are:

 - package name
 - version
 - whether the package is arch:all
 - a anchor hash so that you can directly link to the problem instance via
   
https://qa.debian.org/dose/debcheck/SCENARIO/latest/packages/PKGNAME.html#ANCHOR
 - a human readable short summary of the problem
 - the architectures exhibiting the problem, separated by spaces

Additionally, qa.d.org/dose/debcheck offers a per-source view under URLs of
this format: https://qa.debian.org/dose/debcheck/src/PKGNAME.html where PKGNAME
is a source package name. These pages are only computed for source packages
that either produce binary packages with dependency problems or that suffer
from (cross) build dependency problems themselves.

Feel free to prod me if you need any help in making sense out of the data that
comes out of qa.d.o/dose/debcheck.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#926976: [pre-a] unblock: blis/0.5.1-13

[Mo Zhou]

control: close -1

Let's just leave the bug for Buster. It's not critical.

Bug#929747: qa.debian.org: Please add cross-buildability in summary

[Samuel Thibault]

Helmut Grohne, le lun. 03 juin 2019 17:12:22 +0200, a ecrit:
> What we need here is more people working on the difficult issues, not
> random maintainers staring at undecipherable cross build failures.

Ok :)

> What we also need is maintainers replying to bug reports and
> converting their packages to using debhelper. I get the feeling that
> we're putting priorities in the wrong order.
> 
> I'm sorry if this comes across a little blunt, but some of this looks
> to me like wasting people's time.

No problem, the rationale is clear and now recorded in an appropriate
bug report :)

Samuel

Bug#929931: CTDB: Debian Enablement (focus: NFS HA)

[Rafael David Tinoco]

> Initial support enabling CTDB to install/run in Ubuntu Server.
>
> BUGS:
>
> CTDB port is not aware of Ubuntu-specific NFS Settings
> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/722201
>
> Desc: CTDB has been ported from RH-based distribution and its only
> partially
> aware of Debian-specific settings/files/scripts.  This bug has focus
> in NFS CTDB
> support.

https://bugzilla.samba.org/show_bug.cgi?id=13984

Bug#928741: [pre-a] unblock: julia/1.0.4+dfsg-1

[Mo Zhou]

control: close -1

Hi Paul,

On 2019-05-30 19:29, Paul Gevers wrote:
> On Thu, 09 May 2019 19:26:06 -0700 Mo Zhou  wrote:
>> The current version in testing is 1.0.3, I'm requesting
>> unblock for 1.0.4 (not-yet-released) because Julia's
>> 1.0.X series is strictly a bug-fix-only branch. As per
>> upstream's call-for-community-testing announcement:
> 
> I appreciate you want the latest you can get for you package into
> buster. However, a new upstream (even for only bug fixes branches) does
> not meet the freeze policy. Can you please indicate which bugs in the
> changelog you consider important or more severe (in Debian BTS terms)?
> How much of the changes would fall in that category?

Thanks for the review.
I quickly went through the commit history and didn't find a bug fix
that is critical. So let's keep the testing version as is,
and I'll later push these updates through bpo.

Bug#929933: unblock: golang-github-bep-debounce/1.2.0+really1.1.0-1

[Dr. Tobias Quathamer]

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

Please unblock package golang-github-bep-debounce

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock golang-github-bep-debounce/1.2.0+really1.1.0-1

Regards,
Tobias
diff -Nru golang-github-bep-debounce-1.1.0/debian/changelog golang-github-bep-debounce-1.2.0+really1.1.0/debian/changelog
--- golang-github-bep-debounce-1.1.0/debian/changelog	2018-04-10 10:23:24.0 +0200
+++ golang-github-bep-debounce-1.2.0+really1.1.0/debian/changelog	2019-06-03 17:12:45.0 +0200
@@ -1,3 +1,20 @@
+golang-github-bep-debounce (1.2.0+really1.1.0-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert all changes between 1.1.0-1 and 1.2.0-1.
+See https://bugs.debian.org/928227 for a rationale.
+
+ -- Dr. Tobias Quathamer   Mon, 03 Jun 2019 17:12:45 +0200
+
+golang-github-bep-debounce (1.2.0-1) unstable; urgency=medium
+
+  * New upstream version 1.2.0
+  * Bump Standards-Version to 4.3.0 (no change)
+  * Update Maintainer email address to team+pkg...@tracker.debian.org
+  * Update copyright years in debian/copyright
+
+ -- Anthony Fok   Tue, 19 Feb 2019 09:46:32 -0700
+
 golang-github-bep-debounce (1.1.0-1) unstable; urgency=medium
 
   * Initial release (Closes: #895336)


signature.asc
Description: OpenPGP digital signature

Bug#929747: qa.debian.org: Please add cross-buildability in summary

[Helmut Grohne]

Control: clone -1 -2
Control: retitle -2 qa.debian.org: Please add cross build satisfiability in 
summary
Control: block -1 by -2

On Thu, May 30, 2019 at 05:22:12PM +0200, Helmut Grohne wrote:
> On Thu, May 30, 2019 at 10:57:52AM +0200, Samuel Thibault wrote:
> > https://tracker.debian.org/ has a link to the cross-buildability status
> > of a package. It'd be useful to have a tick or cross on the
> > https://qa.debian.org/developer.php page, e.g. in the CI/Rep column, as
> > a link to the cross-buildability status, to be able to easily check the
> > status of one's own packages.
> 
> If you do, please consider:
>  * crossqa.d.n only works on unstable. If a package is not in unstable,
>there shouldn't be a link. (e.g. gcc-9)
>  * crossqa.d.n only fills a page if there is some package built for one
>of the architectures being tested. Therefore no link should be
>emitted for indep-only packages. Currently, we test for any non-x86
>release architecture, so if a package only builds for some x86, it
>will be 404 as well.
> 
> If some API is missing in the service, please get in touch with me.

I talked with Christoph about the missing APIs and it became clear to us
that publishing cross build status doesn't make sense as long as
satisfiability isn't published. qa.d.o. does compute satisfiability for
a while now:

https://qa.debian.org/dose/debcheck/cross_unstable_main_amd64/

Please integrate a satisfiability status before integrating crossqa.d.n.
50% of packages are cross-unsatisfiable, so this is the big fish.

Once that is done, we should revisit the cross-buildability as we have
failures for roughly one sixth of the archive and patches for 1/14 of
the archive. In other words: Every third cross build failure has a patch
sitting in the BTS already. So for now, just checking whether your
package has a patch is a much better use of your time. Beyond that, more
than half of the patches essentially are "use debhelper".

What we need here is more people working on the difficult issues, not
random maintainers staring at undecipherable cross build failures. What
we also need is maintainers replying to bug reports and converting their
packages to using debhelper. I get the feeling that we're putting
priorities in the wrong order.

I'm sorry if this comes across a little blunt, but some of this looks to
me like wasting people's time.

Helmut

Bug#929714: python-acora: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2

[Hideki Yamane]

control: tags -1 +patch

On Wed, 29 May 2019 16:29:31 +0200 Lucas Nussbaum  wrote:
> >  dpkg-source -b .
> > dpkg-source: info: using source format '3.0 (quilt)'
> > dpkg-source: info: building python-acora using existing 
> > ./python-acora_2.2.orig.tar.gz
> > dpkg-source: info: local changes detected, the modified files are:
> >  python-acora-2.2/acora/_acora.c
> >  python-acora-2.2/acora/_acora.html
> >  python-acora-2.2/acora/_cacora.c
> >  python-acora-2.2/acora/_cacora.html
> > dpkg-source: error: aborting due to unexpected upstream changes, see 
> > /tmp/python-acora_2.2-1.diff.VWSw_l
> > dpkg-source: info: you can integrate the local changes with dpkg-source 
> > --commit
> > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2

 Just removing some lines from debian/rules improves it, debdiff
 attached.

-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp


python-acora.debdiff
Description: Binary data

Bug#928746: unblock: zfs-linux/0.7.13-1

[Mo Zhou]

Hi Paul,

On 2019-05-30 19:51, Paul Gevers wrote:
> or more severe in Debian BTS terms. I may have been wrong, but then
> please point me to the changes so important that you want them in
> buster. Please also be prepared to undo the new upstream release and
> just fix the bugs that are so important to you.

I've already forgotten them and I'm tired to review the diff.
Let's forget all the important stuff and only focus on the grave one:

Due to a stable kernel change (4.19.37->4.19.38) that makes me sad,
we got a grave RC for ZFS 0.7.12-2 (testing) which makes it not suitable
for the Buster release:

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

We have two solutions for this stable RC:

1. just unblock 0.7.13-1 .
2. revert debdiff(0.7.12-2,0.7.12-5), then cherry-pick
   the commits[1] that fix the build issue, then go
   through t-p-u for 0.7.12-6 .

Patching the kernel is impossible because kernel maintainers
refused to do that. So that's an invalid solution.

> Be aware that requests like this one are draining energy from the
> release team. It isn't nice to turn a maintainer down on a request,
> repeating the process is worse. Your changes are huge (your explanation
> is appreciated), we get several unblock requests per day and we have a
> freeze policy in place to manage it. Please don't push your pet project
> so hard if it doesn't meet the policy that you are driving the
> volunteers in the release team away. Thanks for also considering our time.

Sorry for that. My motivation is just that 0.7.13-1 is really
expected to reduce the number of problems compared to 0.7.12-2...

Please make a choice between the two proposed solution above.
If release team doesn't trust every line of code, please just
choose 2. I'll never argue about ZFS unblock again for Buster.

[1] Patch:
https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730

Bug#859874: Reproducible on stretch?

[Patrik Schindler]

Hello,

thank you for your patience.

Unfortunately I didn't record details to my test setup, so I created a new 
Tunes Library on Stretch and tested to access it. I get frequent messages that 
the iTunes Library could not be saved.

No messages in log.smbd, though.

What do you need me to do to provide further information?

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc

Bug#929929: zfs smid

[Chris Zubrzycki]

Is there any chance to keep the removed exported symbol? Could you guys 
convince the kernel team? There’s no copyright issue since it’s released code, 
it’s just keeping a symbol that has been in exported in the kernel for the past 
7 years. On top of that, Greg is violating the kernel release rules by removing 
exports/doing code cleanup in stable kernels.

Bug#928292: stretch-pu: package signing-party/2.5-1

[Adam D. Barratt]

Control: tags -1 +  confirmed

On Wed, 2019-05-01 at 13:52 +0200, Guilhem Moulin wrote:
> Hi Salvatore,
> 
> On Wed, 01 May 2019 at 13:37:12 +0200, Salvatore Bonaccorso wrote:
> > On Wed, May 01, 2019 at 01:27:26PM +0200, Guilhem Moulin wrote:
> > > +signing-party (2.5-1+deb9u1) stretch; urgency=medium
> > > +
> > > +  * Backport security fix for CVE-2018-15599: unsafe shell call
> > > enabling shell
> > 
> >   ^^ That would be CVE-
> > 2019-11627
> > 
> > (and as well for the patch name itself).
> 
> Ooops, I got fooled by my copy-paste fu, and did the same mistake in
> 2.10-1…  Thanks for spotting!  New debdiff attached.

Please go ahead.

Regards,

Adam

Bug#928553: stretch-pu: package libthrift-java/0.9.1-2.1~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-05-07 at 04:02 +0200, Andreas Beckmann wrote:
> The fix for CVE-2018-1320 was in sid (0.9.1-2.1) before the package
> got
> removed, and is in jessie-lts (0.9.1-2+deb8u1), leaving stretch at an
> older version than jessie-lts. So let's get it in stretch to restore
> monotonic version ordering.
> 

Please go ahead.

Regards,

Adam

Bug#929931: CTDB: Debian Enablement (focus: NFS HA)

[Rafael David Tinoco]

Package: ctdb
Version: 2:4.9.5+dfsg-4
Severity: important
Tags: upstream patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Initial support enabling CTDB to install/run in Ubuntu Server.

BUGS:

CTDB port is not aware of Ubuntu-specific NFS Settings
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/722201

Desc: CTDB has been ported from RH-based distribution and its only partially
aware of Debian-specific settings/files/scripts.  This bug has focus in NFS CTDB
support.

- 

ctdb service crashes on start Edit
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1335540

+

ctdb cannot create PID file Edit
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1821775

+

Package ctdb does not create directories in /var/lib/ctdb
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1828799

OBS: 3 bugs related to service not being able to start correctly due to missing
directories and config files.

Those fixes will allow CTDB to be used to configure a HA NFS SERVER.

- 

I'm fixing these and some other minor bugs, including upstream issues like:

https://lists.samba.org/archive/samba-technical/2019-June/133694.html

And will be providing a debdiff proposal soon.

Thanks in advance

Best Regards,
Rafael D. Tinoco
rafaeldtin...@ubuntu.com

- -- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages ctdb depends on:
ii  iproute24.20.0-2
ii  libbsd0 0.9.1-2
ii  libc6   2.28-10
ii  libpopt01.16-12
pn  libtalloc2  
pn  libtdb1 
pn  libtevent0  
ii  lsb-base10.2019051400
ii  psmisc  23.2-1
pn  samba-libs  
ii  sudo1.8.27-1
pn  tdb-tools   
pn  time

Versions of packages ctdb recommends:
pn  ethtool  

Versions of packages ctdb suggests:
ii  logrotate  3.14.0-4
ii  lsof   4.91+dfsg-1

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE9/EO4QjRa7yS94ISqT4OCtg8DQ8FAlz1KyAACgkQqT4OCtg8
DQ9D7A/+ILKmxpBqcT7v0MJRcgmXAnGifYsDvjLY+xrRm1Lk9Y+72gpRcZELeetR
a5IB7gVLFjNoKKRis3NutSsyZCJ7vRGy4xgi73DSdMI9QUa1NwoDmRDDPFKH31Ub
E52BowqPH6i3VSUDlbCQls2Fuq5TKM/e7kSLiaBPq8LwQwFDayJFMvMCAgkwvONM
N76RkLTpEgpaB7/+g4CoxPZ9r2xSMRdx94f6XkqpkVv8jJGuFGBG1wTz3LnA+6jf
KrqChKHf8Itu261rBr90akNGZUkTlDTLpkUPy4yVr3jkssIcwYhng821eXRwEHzD
84wwJItoN9IkuHnLZcdeAa/Ggm3PG+e8se7Y10HVsZsAH9pqzc+jvfAzpByFz/Es
zg8lR37m3UPGbuVUm9fpKS3oSJV6hIRFHUybb1+ImTnYhgTblhPxfJrAL7e1YqSN
4wj0eLu5IFZivN4AeWnVXpRzfqoDT/ENGMibrpBNaoVbfRn5S1pF/s56CWQ3AnMT
1iQjaIIfl9sBULMR5YrNqhN6FAioN9ybmQMZNr1nxzPtaCDnG/iMyvcmgoAZjzEx
bGl46c17AN//PB0j5FaQl8Fv/OtpVFLwK7TZcA9ul5KqXicuB9XqgcjcuTk2izAQ
pv2axmUZTkrLEVzv2j2Vm7t38SSzi3WiqAMhnPLUvsrgUR5X7w4=
=bexg
-END PGP SIGNATURE-

Bug#929255: stretch-pu: package corekeeper/1.7~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2019-05-20 at 12:19 +0800, Paul Wise wrote:
> I'd like to backport the security fixes and hardening in corekeeper
> from buster to stretch.
> 

Please go ahead.

Regards,

Adam

Bug#929613: stretch-pu: package minissdpd/1.2.20130907-4.1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2019-05-27 at 10:17 +0100, Chris Lamb wrote:
>   minissdpd (1.2.20130907-4.1+deb9u1) stretch; urgency=medium
>   
> * CVE-2019-12106: Prevent a use-after-free vulnerability that
> would allow a
>   remote attacker to crash the process. (Closes: #929297)

Please go ahead.

Regards,

Adam

Bug#929930: libreswan: replace xfrm_stats with xfrm_acq_expires

[Daniel Kahn Gillmor]

Package: libreswan
Version: 3.28-1

libreswan tries to detect XFRM support by lookng at /proc/net/xfrm_stat,
but that's only relevant on kernels with CONFIG_XFRM_STATISTICS
enabled.  /proc/sys/net/core/xfrm_acq_expires is a more robust way to
test for xfrm support.  This probably needs to be patched in 3.28.

See libreswan upstream git commit
716f4b712724c6698469563e531dea3667507ceb for more examples.

--dkg


signature.asc
Description: PGP signature

Bug#929887: /usr/lib/qgis/crssync: error while loading shared libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such file or directory

[積丹尼 Dan Jacobson]

It turns out that all you need to do is simply add a dependency on
libhdf5-100 and then the package is perfectly installable!

(Otherwise I don't understand the point of uploading a package that
nobody can install using apt.)

Here is what I successfully installed:

Package: qgis
Version: 3.4.8+dfsg-1

-- System Information:
Debian Release: 10.0
  APT prefers experimental
  APT policy: (990, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)

Versions of packages qgis depends on:
ii  libc62.28-10
ii  libexpat12.2.6-1
ii  libgcc1  1:9.1.0-2
ii  libgdal20 [gdal-abi-2-4-0]   2.4.1+dfsg-1~exp1
ii  libgeos-c1v5 3.7.1-1
ii  libgsl23 2.5+dfsg-6
ii  libgslcblas0 2.5+dfsg-6
ii  libpq5   11.3-1
ii  libproj135.2.0-1
ii  libqca-qt5-2 2.1.3-2
ii  libqgis-3d3.4.8  3.4.8+dfsg-1
ii  libqgis-analysis3.4.83.4.8+dfsg-1
ii  libqgis-app3.4.8 3.4.8+dfsg-1
ii  libqgis-core3.4.83.4.8+dfsg-1
ii  libqgis-gui3.4.8 3.4.8+dfsg-1
ii  libqgis-native3.4.8  3.4.8+dfsg-1
ii  libqscintilla2-qt5-132.10.4+dfsg-2
ii  libqt53dcore55.11.3+dfsg-2
ii  libqt53dextras5  5.11.3+dfsg-2
ii  libqt53dinput5   5.11.3+dfsg-2
ii  libqt53dlogic5   5.11.3+dfsg-2
ii  libqt53drender5  5.11.3+dfsg-2
ii  libqt5concurrent55.11.3+dfsg1-1
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5dbus5  5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5keychain1  0.9.1-2
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5positioning5   5.11.3+dfsg-2
ii  libqt5printsupport5  5.11.3+dfsg1-1
ii  libqt5qml5   5.11.3-4
ii  libqt5quick5 5.11.3-4
ii  libqt5quickwidgets5  5.11.3-4
ii  libqt5serialport55.11.3-2
ii  libqt5sql5   5.11.3+dfsg1-1
ii  libqt5svg5   5.11.3-2
ii  libqt5webkit55.212.0~alpha2-21
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libqt5xml5   5.11.3+dfsg1-1
ii  libqwt-qt5-6 6.1.4-1
ii  libspatialindex5 1.9.0-1
ii  libspatialite7   5.0.0~beta0-1~exp2
ii  libsqlite3-0 3.27.2-2
ii  libstdc++6   9.1.0-2
ii  libzip4  1.5.1-4
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-2
ii  python3-qgis 3.4.8+dfsg-1
ii  qgis-common  3.4.8+dfsg-1
ii  qgis-providers   3.4.8+dfsg-1

Versions of packages qgis recommends:
pn  qgis-plugin-grass  

Versions of packages qgis suggests:
pn  gpsbabel  

-- no debconf information

The only warnings I saw were

Setting up qgis-providers (3.4.8+dfsg-1) ...
QFSFileEngine::open: No file name specified
QFSFileEngine::open: No file name specified
QFSFileEngine::open: No file name specified
QFSFileEngine::open: No file name specified
QFSFileEngine::open: No file name specified

And the only thing I needed to tell aptitude was

   Keep the following packages at their current version:
   42) libgdal26 [Not Installed]

But I still could install qgis just fine.

Bug#781961: systemd-logind integration for XScreenSaver

[Martin Lucina]

> Note that after using this for 15 days now, I still occasionally (say 1 in
> 10 times?) get a flash of the unlocked screen content on resume, followed
> by the XScreenSaver password dialog. Unclear to me what is going on here
> other than "random scheduling races" but that's precisely what this
> inhibitor mechanism is supposed to avoid, so hmm, go figure?!

... (more hypothesis) this is indeed a race, between X actually committing
the result of "xscreensaver-command -lock" to the hardware and systemd
suspending the system.

Confirmed-ish by adding the "traditional workaround for all distributed
systems problems", namely sleep(1) on our suspend path, works for me, so
I've committed that change to GitHub for now.

Jamie, if there is a way to sync on the X server actually completing its
work, then we could do that instead.

Martin

Bug#929929: Being unable to build with >= 4.19.38 is an RC

[Mo Zhou]

Source: zfs-linux
Version: 0.7.12-2
Severity: grave
Clarification: a foreseeable stable RC is grave enough.

Buster will be released with 4.19.37 kernel. That's fine
and it doesn't break ZFS. However, the changes introduced
in 4.19.38 and linux 5.0 break ZFS. That means the current
0.7.12-2 will fail to build everywhere after the first
Buster point release (with kernel version bump).
RC in stable is terrible enough.

We have two choices:
1. just unblock 0.7.13-1 .
2. revert diff(0.7.12-2,0.7.12-5), then cherry-pick
   the commits that fix the build issue, then go
   through t-p-u for 0.7.12-6 .

I dislike the second one but the first one seems hard
to achieve. Sigh.

Bug#929928: coreutils: nohup segfaults with command line

[Stefan Schwarzer]

Package: coreutils
Version: 8.30-3
Severity: normal

Dear Maintainer,

I am trying to run a program detached in the background from an ssh login, 
like 
  nohup  
where  is my executable and  a configuration file. 
The combination   runs without issue. As far as I understand from
the documentation (man or info respectively,  denotes program 
(as opposed to nohup) arguments. Now, when prefixed with nohup, nohup segfaults 
within about a second, apparently (strace)  due to an access to 
an invalid file descriptor (see strace excerpt below) - I had expected 
nohup.out to be 
created and contain the program output (possibly with the exception of stderr).

[...]
epoll_ctl(4, EPOLL_CTL_ADD, 5, {EPOLLIN|EPOLLERR, {u32=2246584660, 
u64=94143634745684}}) = 0
clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=11500, tv_nsec=213387281}) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
epoll_ctl(4, EPOLL_CTL_ADD, 6, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLET, 
{u32=2246468080, u64=94143634629104}}) = 0
setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(6, {sa_family=AF_INET, sin_port=htons(10201), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(6, 128)
[... stuff involving fd 2 and 6]

clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=11500, tv_nsec=601792740}) = 0
mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 
0x7f3422bf5000
mprotect(0x7f3422bf6000, 8388608, PROT_READ|PROT_WRITE) = 0
clone(child_stack=0x7f34233f4f70, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f34233f59d0, tls=0x7f34233f5700, child_tidptr=0x7f34233f59d0) 
= 3216
mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 
0x7f34223f4000
mprotect(0x7f34223f5000, 8388608, PROT_READ|PROT_WRITE) = 0
clone(child_stack=0x7f3422bf3f70, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f3422bf49d0, tls=0x7f3422bf4700, child_tidptr=0x7f3422bf49d0) 
= 3217
fstat(0, {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}) = 0
ioctl(0, TCGETS, 0x7fffc9dc7a10)= -1 ENOTTY (Inappropriate ioctl for 
device)
read(0, 0x559f85e82fe0, 4096)   = -1 EBADF (Bad file descriptor)
+++ killed by SIGSEGV +++
Segmentation fault

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libselinux1  2.8-1+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#929834: lightdm-gtk-greeter: After locking screen, display is turned off and unlock prompt is not visible

[Andreas Tille]

Control: severity -1 grave

Hi,

I've set the severity of this bug to grave.  It has turned out that in
combination with xfce light-locker leaves the user with a black screen
leading normal users to the assumption that the computer is frozen.  I
have observed users pressing power button of their laptops to shut it
down to "solve" this situation.

It is inacceptable to expect users to learn specific tricks to restore
normal operation (like switching VT and back).  Thus I consider the
package "unusable by most or all users" which is why I have set the
severity of this bug to grave.

There is an according thread on debian-devel[1] list which is discussing
the issue (I've bounced those mails from the thread to the bug report
that might be helpful to understand the issue).

Kind regards
  Andreas.


[1] https://lists.debian.org/debian-devel/2019/06/msg0.html

-- 
http://fam-tille.de

Bug#929927: python-django: CVE-2019-12308: AdminURLFieldWidget XSS

[Salvatore Bonaccorso]

Source: python-django
Version: 1:1.11.20-1
Severity: important
Tags: security upstream
Control: found -1 2:2.2.1-1

Hi,

The following vulnerability was published for python-django.

CVE-2019-12308[0]:
AdminURLFieldWidget XSS

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-12308
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12308
[1] https://www.djangoproject.com/weblog/2019/jun/03/security-releases/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#929834: Buster/XFCE unlock screen is blank

[Russ Allbery]

(This probably belonged on debian-user, but since I have background on
this specific problem and already did the research.)

Raj Kiran Grandhi  writes:

> In a fresh install of Buster with XFCE desktop, locking the screen
> blanks the monitor and the monitor enters a power save state. After
> that, neither moving the mouse nor typing on the keyboard would turn
> the monitor back on.

Ctrl-Alt-F7 will also restore the desktop (which I think is just another
version of your solution 2 of switching VTs).

This appears to be a bug in light-locker specifically, which is the
default screen lock program with XFCE with lightdm.  See, for instance:

https://github.com/the-cavalry/light-locker/issues/114

Switching to another greeter from the default gtk-greeter appears to help
according to that bug, which may mean that the bug is actually in
lightdm-gtk-greeter.  There doesn't appear to be a Debian bug for this; it
might be a good idea to open one against light-locker (or, if you confirm
switching to slick-greeter per that bug, lightdm-gtk-greeter).

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

Bug#929834: Buster/XFCE unlock screen is blank

[Raj Kiran Grandhi]

Hi,

In a fresh install of Buster with XFCE desktop, locking the screen
blanks the monitor and the monitor enters a power save state. After
that, neither moving the mouse nor typing on the keyboard would turn
the monitor back on.
I could find two ways to get the display back on:

1. Typing the password without any visual feedback (while the monitor
continues to be in the power save state) unlocks the screen and the user
session is displayed normally.

2. Switching to another VT, say vt1 or vt2 turns the monitor back on
and on switching
back to the vt of the original session the unlock prompt is displayed
normally and the screen can be unlocked.

For a single user system, this is not a big deal, but is an important
issue if multiple users are logged in simultaneously.

I am not sure to which package this bug belongs to.
The closest I could find online was this:
https://bbs.archlinux.org/viewtopic.php?id=240200 wherein installing
the nouveau video driver appeared to have fixed the issue. However,
that solution is not applicable in my case as I have an integrated
intel graphics controller.

I had discovered this behaviour after a dist-upgrade to buster from
the current stable. I then made a clean install onto a spare hdd using
debian-buster-DI-rc1-amd64-netinst.iso and choosing the XFCE desktop
and am able to reproduce this bug.
Asking around on debian-user, I found a couple of other users who have
also experienced this same issue.

I shall be happy to assist the developers in troubleshooting this
issue. Please let me know if any other info is needed. I am running on
Intel i5-4440 CPU with its integrated graphics controller.

Thank you,
Raj Kiran

Bug#929834: Buster/XFCE unlock screen is blank

[Jonathan Carter]

Hey Adam

On 2019/06/01 18:29, Adam Borowski wrote:
> At the time of the xscreensaver debacle, there was no sane alternative
> (candidates depended on 80% of GNOME, offered no feedback nor discoverable
> controls to the user, etc).  There _is_ a wonderful alternative now:
> xfce4-screensaver, which seems to work perfectly[2] -- but alas, it's not in
> Buster.

When I first filed the ITP for xfce4-screensaver I got some pushback (of
which I don't all disagree with). After some discussion and digging in
deeper into the issue the Debian Xfce team agreed that it can be
maintained as part of the Xfce team. At freeze time it was still in
alpha and had some show-stopper issues, we decided that it would be best
for everyone not to have that in buster at that time. There are also
still some integration issues that are still outstanding. Overall it
just wasn't ready for buster in time, but I'll be happy to work on a
backport for buster when some of the last few issues have been resolved.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Bug#929834: Buster/XFCE unlock screen is blank

[Adam Borowski]

On Sat, Jun 01, 2019 at 11:06:42AM +0200, Andreas Tille wrote:
> > This appears to be a bug in light-locker specifically, which is the
> > default screen lock program with XFCE with lightdm.  See, for instance:
> > 
> > https://github.com/the-cavalry/light-locker/issues/114
> > 
> > Switching to another greeter from the default gtk-greeter appears to help
> > according to that bug, which may mean that the bug is actually in
> > lightdm-gtk-greeter.  There doesn't appear to be a Debian bug for this; it
> > might be a good idea to open one against light-locker (or, if you confirm
> > switching to slick-greeter per that bug, lightdm-gtk-greeter).
> 
> Yes, please file the bug (and may be report the bug number here).  We
> should not release with a broken greeter as default since we can not
> assume that normal users will find out the "switch VT trick" and instead
> will assume the box is frozen. 

While I greatly prefer slick-greeter (I use it exclusively since the first
day I reviewed+sponsored the package), I recall it doesn't support a11y
anywhere as well as the default greeter.  This is old data, though -- as my
wetware doesn't require a11y, I wouldn't even know what to look at.

But, the culprit is light-locker.  In general, it's in such a buggy state
that I believe it shouldn't be in the distribution at all, much less a
default of any kind.  After it replaced xscreensaver[1] as the xfce's
dependency, I went into some pretty heated arguments, but then stormed off
and ignored the issue.

Just some issues with light-locker.  INACCURATE, BASED ON AN OLD VERSION,
AND NOT RESEARCHED WELL AT ALL.  (Ie, areas to look at, not proper reports)
* it doesn't show anyone is logged in -- lock screen is pixel-to-pixel
  identical as the login screen
* breaks when the *DM is not lightdm.  A package dependency doesn't mean
  that lightdm is running or used to start that session.
* breaks with multiseat (as in: concurrent same-uid logins from different
  seats, not the systemd meaning)
* breaks if ssh -X into the box is used with some programs
* breaks with any non-standard VT assignment
(Some of the issues might have been already fixed.)

At the time of the xscreensaver debacle, there was no sane alternative
(candidates depended on 80% of GNOME, offered no feedback nor discoverable
controls to the user, etc).  There _is_ a wonderful alternative now:
xfce4-screensaver, which seems to work perfectly[2] -- but alas, it's not in
Buster.

Using unstable myself, I'm not sure what to recommend for Buster.  But if
the bugs can't get fixed in late freeze, and slick-greeter is not enough,
I's light-locker not the greeter I'd propose switching out of.


Meow!

[1]. When jwz planted a time-bomb in xscreensaver.
[2]. There was an issue with taking lots of CPU even when the monitor has
 been long since powered down, but that's now fixed.
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

Bug#929834: Buster/XFCE unlock screen is blank

[Holger Levsen]

On Sat, Jun 01, 2019 at 06:29:31PM +0200, Adam Borowski wrote:
> Using unstable myself, I'm not sure what to recommend for Buster.  

https://tracker.debian.org/pkg/physlock


signature.asc
Description: PGP signature

Bug#929834: Buster/XFCE unlock screen is blank

[Russ Allbery]

Adam Borowski  writes:

> But, the culprit is light-locker.  In general, it's in such a buggy
> state that I believe it shouldn't be in the distribution at all, much
> less a default of any kind.  After it replaced xscreensaver[1] as the
> xfce's dependency, I went into some pretty heated arguments, but then
> stormed off and ignored the issue.

It's worth noting here that xscreensaver has an IMO serious security
vulnerability (unless maybe this has been fixed?): because it doesn't
integrate properly with the desktop, it doesn't hide desktop
notifications.  Desktop notifications will appear above the lock screen.
If you therefore leave a locked computer in some relatively public place
(such as an open plan office at work), you may be exposing things on your
screen that you didn't expect, such as direct messages from some messaging
system that's plugged into desktop notifications.

I did some research on that a while back and ended up not filing a bug
about it because it looked relatively pointless.  It appeared to be a deep
design choice on both sides, and not something anyone was likely to solve,
so I just switched to a desktop-aware locker.

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

Bug#929834: Buster/XFCE unlock screen is blank

[Theodore Ts'o]

On Sat, Jun 01, 2019 at 06:16:58AM +0530, Raj Kiran Grandhi wrote:
> 
> In a fresh install of Buster with XFCE desktop, locking the screen
> blanks the monitor and the monitor enters a power save state. After
> that, neither moving the mouse nor typing on the keyboard would turn
> the monitor back on.
> I could find two ways to get the display back on:
> 
> 1. Typing the password without any visual feedback (while the monitor
> continues to be in the power save state) unlocks the screen and the user
> session is displayed normally.
> 
> 2. Switching to another VT, say vt1 or vt2 turns the monitor back on
> and on switching
> back to the vt of the original session the unlock prompt is displayed
> normally and the screen can be unlocked.

There's another workaround (which is the one I use):

xset s off

This has other consequences as well, of course, but I tend to suspend
my laptop if it's ever going to be left alone, particularly if it's
running on battery.

And once I found a workaround which worked for my laptop, I was too
lazy to find a more "proper" fix.  :-)

- Ted

Bug#929834: Buster/XFCE unlock screen is blank

[Russ Allbery]

Georg Faerber  writes:
> On 19-06-01 11:04:28, Russ Allbery wrote:

>> I did some research on that a while back and ended up not filing a bug
>> about it because it looked relatively pointless.  It appeared to be a
>> deep design choice on both sides, and not something anyone was likely
>> to solve, so I just switched to a desktop-aware locker.

> If I may ask, which one?

light-locker, hence why I know about the bug that started this thread.  :)
(I never filed it as a bug since I didn't mind the workaround.  In
retrospect, I should have.)

Obviously given the discussion here I'm not sure I'd recommend that one.

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

Bug#929926: lxc-cgroup didn't show cpu usage

[Leonid Balioshenko]

Package: lxc
Version: 1:3.1.0+really3.0.3-8
Severity: normal

Dear Maintainer,

   * What led up to the situation?
"lxc-cgroup -n example_container cpuacct.stat" provides no output
Looks like this was fixed in in version 3.0.4:
https://github.com/lxc/lxc/issues/2742
Please, update version of lxc for Debian buster in repository to 3.0.4



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

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

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libgnutls303.6.6-2
ii  liblxc11:3.1.0+really3.0.3-8
ii  libseccomp22.3.3-4
ii  libselinux12.8-1+b1
ii  lsb-base   10.2019051400

Versions of packages lxc recommends:
ii  apparmor   2.13.2-10
ii  bridge-utils   1.6-2
ii  debootstrap1.0.114
pn  dirmngr
pn  dnsmasq-base   
pn  gnupg  
ii  iproute2   4.20.0-2
ii  iptables   1.8.2-4
pn  libpam-cgfs
pn  lxc-templates  
pn  lxcfs  
ii  openssl1.1.1b-2
ii  rsync  3.1.3-6
pn  uidmap 

Versions of packages lxc suggests:
pn  btrfs-progs  
pn  lvm2 
pn  python3-lxc  

-- Configuration Files:
/etc/apparmor.d/abstractions/lxc/container-base changed [not included]
/etc/default/lxc changed [not included]
/etc/lxc/default.conf changed [not included]

-- debconf information excluded

Bug#903759: [Debian-med-packaging] Bug#903759: Bug#903759: 903759: marking as pending

[Andrius Merkys]

Hi Graham,

On 2019-06-03 14:04, Graham Inggs wrote:
> Thanks for the upload, and congratulations!

Thanks a lot! :)

> I filed an unblock request (#929924).

Great - I forgot to do so.

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania