Bug#927879: ca-certificates should not hardcode QuoVadis certificate authorities in /etc/ca-certificates.conf

[Soppy bear]

On Thu, 25 Apr 2019 18:38:04 +0200
Kurt Roeckx  wrote:


> So far "normal use", we install the list as provided
> by Mozilla as the default. 
> 
> 
> Kurt


Lol... im guessing Debian security should have spotted this issue before me. 

I am sorry but it is not very careful to trust and import any third-party 
certificate authorities not needed for standard TLS 1.2 security into the 
Debian package system
by default..

Also i dont trust Mozilla corporation (and their third-party partners, 
including Dark Matter and the UAE i guess) 
anymore because firefox has become a disgrace for the free software movement i 
still believe in. :o)

Regards,

tk
--
tkad...@yandex.com | Twitter: @wise_project
https://www.isotoperesearch.ca/
Not everyone who wander are lost.

Bug#927275: Info received (Bug#927275: Info received (Bug#927275: gnome-shell - Intel GPU - monitors.xml is ignored and settings are not applied after suspend/reboot))

[-]

Am Mittwoch, den 24.04.2019, 07:50 +0100 schrieb Simon McVittie:
> On Wed, 24 Apr 2019 at 07:26:54 +0200, - wrote:
> > Then I connected the dock (at work), the thunderbolt
> > authentification
> > was done, and suddenly the whole gnome-seesion crashed.
> 
> From your log, the root cause is that Xwayland crashed (GNOME Shell
> in
> Wayland mode can't currently work without Xwayland). Please report
> this
> as a separate bug in the xwayland package.

Done as Bug#927852.

In addition to this bug, sometimes monitor.xml seems to be applied,
sometimes not, as described in the messages before.
I am still not able to find a pattern. Sometimes monitors.xml is even
applied if the laptop is running and then connected to the dock,
sometimes not. I still hope someone is able to figure out by reading
the logs I have supplied.

If there is anything more I can test, please let me know.

best regards

Christian Höffer

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

On 4/25/19 8:21 PM, Ben Hutchings wrote:
> Control: reassign -1 jitterentropy-rngd
> Control: severity -1 wishlist
>
> There is no dependency between the user-space daemon and the kernel
> module.  And I don't see any kernel bug here, but this might be a
> wishlist item for the user-space package.
>
> Ben.
>
I see. Thanks Ben. Is there anything you guys can do at your end to
force this particular module to load on all hosts running a kernel that
supports it? Reason is crypto entropy is exceptionally important.

Thanks.




signature.asc
Description: OpenPGP digital signature

Bug#927940: [Windows Subsystem for Linux] Applications cannot find libQt5Core.so.5

[Scott Kitterman]

On April 26, 2019 2:10:36 AM UTC, Ryo IGARASHI  wrote:
>Hi, Bernhard,
>
>Thank you for the workaround. Now that I can launch QT application on
>my machine.
>
>As this issue only affects WSL environment, I don't think this is an
>RC bug, but I will
>let the maintainers set the proper severities.
>
>Maybe do we need a comment about this issue on the buster release
>notes?
>
>2019年4月26日(金) 1:37 Bernhard Übelacker :
>>
>> Control: retitle 927940 [Windows Subsystem for Linux] Applications
>cannot find libQt5Core.so.5

This isn't a Qt5 bug at all.  If you try and link Qt5 in a Sid chroot on an old 
enough Debian version, the same thing happens because of missing kernel 
functions.  It's a host kernel issue.

Since the kernel in this instance isn't Debian's I don't think it's a Debian 
bug either.

I'm not one of the Qt maintainers, so I'm not going to change the status of the 
bug, but I think the correct thing to do is to close it.  No Debian issue here.

Scott K

Bug#927992: Write errors and warnings to STDERR, don't hide them if not a tty

[積丹尼 Dan Jacobson]

Package: apt
Version: 1.8.0
File: /usr/bin/apt-cache

In Unix/Linux we have STDOUT and STDERR. Please just use these two,
and don't invent "smarter ways."

Really really bad and this will come back to bite you one day:

You have a kind of message that is only shown if the user is on a tty.

You don't user the industry standard of sending it to STDERR,
You instead just hide it... if the user apparently isn't using a TTY.

One can't even pipe the output of your program to any other program,
expecting messages to go to STDERR. The message just disappears!

$ apt-cache show twitter-bootstrap
N: Can't select candidate version from package twitter-bootstrap as it has no 
candidate
N: Can't select versions from package 'twitter-bootstrap' as it is purely 
virtual
N: No packages found
$ apt-cache show twitter-bootstrap 2>&1|wc
  0   0   0

In fact I can think of no other program in the entire history of Unix
that has decided to do that.

If the user doesn't want the message he can just do 2> /dev/null. Or
2>&- . That's how we do things on Linux/Unix.

$ apt show twitter-bootstrap
Package: twitter-bootstrap
State: not a real package (virtual)
N: Can't select candidate version from package twitter-bootstrap as it has no 
candidate
N: Can't select versions from package 'twitter-bootstrap' as it is purely 
virtual
N: No packages found

Now experimenting with apt,

$ apt show twitter-bootstrap 2>&1 | nl -b a
 1
 2  WARNING: apt does not have a stable CLI interface. Use with caution in 
scripts.
 3
 4  Package: twitter-bootstrap
 5  State: not a real package (virtual)
$ apt show twitter-bootstrap | nl -b a

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

 1  Package: twitter-bootstrap
 2  State: not a real package (virtual)

Aptitude is much more consistent,

$ aptitude show twitter-bootstrap | nl -b a
 1  Package: twitter-bootstrap
 2  State: not a real package
 3  Provided by: libjs-twitter-bootstrap (2.0.2+dfsg-10)
$ aptitude show twitter-bootstrap
Package: twitter-bootstrap
State: not a real package
Provided by: libjs-twitter-bootstrap (2.0.2+dfsg-10)

Anyway your idea of a tty is fine for you. But not for how many users
will use these programs. Thanks.

Bug#927991: amarok: FTBFS: mysql_config --libmysqld-libs unrecognized

[Aaron M. Ucko]

Source: amarok
Version: 2.9.0-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

Builds of amarok against current unstable (including in particular
rebuilds for library transitions) have been failing lately with the
error

  
src/core-impl/storage/sql/mysqlestorage/CMakeFiles/amarok_storage-mysqlestorage.dir/build.make:133:
 *** target pattern contains no '%'.  Stop.

The relevant line reads

  lib/amarok_storage-mysqlestorage.so: /usr/bin/mysql_config:\ unrecognized\ 
option\ '--libmysqld-libs'\ -lpthread

... presumably stemming from obsolete usage in
cmake/modules/FindMySQLAmarok.cmake.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#927940: [Windows Subsystem for Linux] Applications cannot find libQt5Core.so.5

[Ryo IGARASHI]

Hi, Bernhard,

Thank you for the workaround. Now that I can launch QT application on
my machine.

As this issue only affects WSL environment, I don't think this is an
RC bug, but I will
let the maintainers set the proper severities.

Maybe do we need a comment about this issue on the buster release notes?

2019年4月26日(金) 1:37 Bernhard Übelacker :
>
> Control: retitle 927940 [Windows Subsystem for Linux] Applications cannot 
> find libQt5Core.so.5
>
>
> Hello Ryo,
>
> > I encountered this problem with my WSL environment.Not quite the usual 
> > kernel ... ;-)
>
> A google search leads to this information [1]
> and this bug [2].
>
> There a workaround is provided by stripping
> the section .note.ABI-tag from the file.
>
> Kind regards,
> Bernhard
>
> [1] 
> https://superuser.com/questions/1347723/arch-on-wsl-libqt5core-so-5-not-found-despite-being-installed
> [2] https://github.com/Microsoft/WSL/issues/3023



-- 
Ryo IGARASHI, Ph.D.
rigar...@gmail.com

Bug#927911: systemd: Does not expand %h identifier in ExecStart

[Norbert Preining]

Hi

> The man pages say that %h and %u are resolved to the root user if you
> are using the system instance (PID 1).
> That is consistent with the behaviour you are getting.
> If I missed a part which mentions the contrary, could you quote the
> relevant bits from the documentation, so it can be fixed?

Unit files can be parameterized by a single argument called the
"instance name". The unit is then constructed based on a "template file"
which serves as the definition of multiple services or other units.
A template unit must have a single "@" at the end of the name (right
before the type suffix). The name of the full unit is formed by 
inserting
the instance name between "@" and the unit type suffix. In the unit file
itself, the instance parameter may be referred to 
using "%i" and other specifiers, see below.
   ^^

There is no real indication what means "below", but the somehow for me
logical reference is the section
Specifiers

Many settings resolve specifiers which may be used to write generic
unit files referring to runtime or unit parameters that are replaced
when the unit files are loaded. Specifiers must be known and resolvable
for the setting to be valid. The following specifiers are understood:

Table 4. Specifiers available in unit files
...

In my reading that says:
You can use %i and other specifiers **as laid out in the secion
"Specifiers" in the Unit file** 

I searched all occurrences of % in the man page, and that is all that is
said.

> That said, I do acknowledge that the systemd.unit(5) man page could be
> clearer what effect it has on %h and %u when setting `User=` when

I am not sure how this relates to my question.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#927990: sway: possibly missing libgl1-mesa-dri dependency

[Linda Lapinlampi]

Source: sway
Version: 1.0~rc3-1
Severity: normal
Tags: experimental

Dear Maintainer,

an issue was reported on upstream's issue tracker about this Debian
package not working out of the box on Intel GMA950 graphics:
https://github.com/swaywm/sway/issues/4061

libgl1-mesa-dri may be missing from this Debian package's runtime
dependencies, although I've not attempted to reproduce the issue myself
yet. (This may be an issue for wlroots package instead.)

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

[Adrian Immanuel Kiess]

Dear Bernhard,

after some updates to Debian/testing the old bug went away.

I try to login with my user guest with a clean home directory.

Now the error is:

Apr 26 03:39:35 g6 gnome-session-binary[9035]: Entering running state
Apr 26 03:39:35 g6 gnome-session[9035]: Unable to init server: Could
not connect: Connection refused
Apr 26 03:39:35 g6 gnome-session-f[9128]: Cannot open display:

Logging in into amiwm works fine though!

I also can't use a session created through xdm or a login manager
because a lot of GNOME and GTK complain or even seqfault and won't
start after creating a session through xdm.

Using a console login and startx, everything works fine though.

I suspect this is a general bug with login manager created X sessions.

I also have to note, this is is a installation from the year 2010,
always kept updated to newest Debian/testing. 

Maybe something broke meanwhile.

Does this read any package maintainer?

What could be the issue GNOME and GTK applications have when run
through a login manager session in current Debian/testing.

I also tried googling for this topic, but couldn't find any solution.

Here is the log from syslog:

Apr 26 03:39:34 g6 systemd[1]: Started User Manager for UID 10003.
Apr 26 03:39:34 g6 NetworkManager[917]: ((src/settings/nm-settings-
connection.c:361)): assertion '' f
ailed
Apr 26 03:39:34 g6 systemd[1]: Started Session 7 of user guest.
Apr 26 03:39:34 g6 NetworkManager[917]: ((src/settings/nm-settings-
connection.c:361)): assertion '' f
ailed
Apr 26 03:39:34 g6 NetworkManager[917]: ((src/settings/nm-settings-
connection.c:361)): assertion '' f
ailed
Apr 26 03:39:34 g6 systemd[9021]: Started D-Bus User Message Bus.
Apr 26 03:39:35 g6 dbus-daemon[9043]: [session uid=10003 pid=9043]
Activating via systemd: service name='org.a
11y.Bus' unit='at-spi-dbus-bus.service' requested by ':1.7' (uid=10003
pid=9098 comm="/usr/lib/gnome-session/g
nome-session-check-acceler")
Apr 26 03:39:35 g6 systemd[9021]: Starting Accessibility services
bus...
Apr 26 03:39:35 g6 dbus-daemon[9043]: [session uid=10003 pid=9043]
Successfully activated service 'org.a11y.Bu
s'
Apr 26 03:39:35 g6 systemd[9021]: Started Accessibility services bus.
Apr 26 03:39:35 g6 at-spi-bus-launcher[9107]: dbus-daemon[9112]:
Activating service name='org.a11y.atspi.Regis
try' requested by ':1.0' (uid=10003 pid=9098 comm="/usr/lib/gnome-
session/gnome-session-check-acceler")
Apr 26 03:39:35 g6 at-spi-bus-launcher[9107]: dbus-daemon[9112]:
Successfully activated service 'org.a11y.atsp
i.Registry'
Apr 26 03:39:35 g6 at-spi-bus-launcher[9107]: SpiRegistry daemon is
running with well-known name - org.a11y.at
spi.Registry
Apr 26 03:39:35 g6 gnome-session-binary[9035]: Entering running state
Apr 26 03:39:35 g6 gnome-session[9035]: Unable to init server: Could
not connect: Connection refused
Apr 26 03:39:35 g6 gnome-session-f[9128]: Cannot open display:

Thank you very much,

Adrian

-- 
With many greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Gothaer Straße 34
D-04155 Leipzig

Administrator & programmer
Unix ∧ Perl ∧ Java ∧ LaTeX

 — < adr...@kiess.onl >
 — https://www.kiess.onl
☕ — https://arosusi.kiess.onl
 — https://jexercise.kiess.onl

--SYSTEM--
echo "Your fortune cookie: " && /usr/games/fortune -c -s
> (men-women) % A beautiful woman is a blessing from Heaven, but a good cigar 
> is a smoke. -- Kipling

echo "KIESS.ONL uptime: " && /usr/bin/uptime
> 03:40:50 up 5 min, 3 users, load average: 1.43, 0.87, 0.40


On Mon, 2019-04-08 at 17:25 +0200, Bernhard Übelacker wrote:
> Hello Adrian,
> 
> > I don't have any of those old GNOME applications installed, you
> > mentioned.
> 
> Then these files should not be there I guess like e.g.:
> /usr/share/glib-2.0/schemas/org.gnome.EasyTAG.gschema.xml
> 
> On a system where e.g. easytag is installed a 'dpkg -S' returns this:
> $ dpkg -S /usr/share/glib-2.0/schemas/org.gnome.EasyTAG.gschema.xml
> easytag: /usr/share/glib-2.0/schemas/org.gnome.EasyTAG.gschema.xml
> 
> 
> However, if you suspect something of the environment may be wrong,
> you could try this:
> 
> - login through sddm
> env | sort > /home/user/env-enlightment.txt
> 
> - login through another login manager
> env | sort > /home/user/env-other.txt
> 
> - compare:
> diff -Nurp /home/user/env-other.txt /home/user/env-
> enlightment.txt
> 
> - then you may search if GSETTINGS_SCHEMA_DIR in the differences
> shown.
> 
> - or set the different variables one by one in a terminal by
> export VAR=value
> (call from there one of the crashing programs)
>   and check if that changes behaviour.
> 
> Kind regards,
> Bernhard
> 


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

Bug#925457: python-jwcrypto: FTBFS ('module' object has no attribute 'decode_rfc6979_signature')

[Emmanuel Arias]

I can confirm that the bug is solved in the last version of the
package.

But we are jumping from 0.4.2 to 0.6.0

CC to Santiago





signature.asc
Description: OpenPGP digital signature

Bug#927989: RFA: terminaltables

[Carl Suster]

Package: wnpp
Severity: normal

I am no longer interested in maintaining terminaltables in Debian. I initially
packaged it as a dependency for a now-abandoned ITP. In the meantime it has
picked up rdeps independently. I have included the maintainers of these rdeps
in CC in case they are able to help out.

The package is currently team-maintained in DPMT, however I have not yet had
a response for my request for new uploaders there
(https://lists.debian.org/debian-python/2019/04/msg00015.html).
The package is currently in good shape and is up-to-date with upstream, which
has not seen a new release in a while.

Bug#927988: RM: rpyc -- ROM; RC buggy leaf package

[Carl Suster]

Package: ftp.debian.org
Severity: normal

I initially packaged rpyc as a dependency for FlexGet. I no longer intend to
package FlexGet and therefore rpyc is no longer needed. It has no rdeps, and
has a FTBFS bug related to a test suite failure that I couldn't work out.

Bug#927987: Don't tell users to use ext3

[積丹尼 Dan Jacobson]

Package: www.debian.org

https://www.debian.org/releases/stretch/amd64/apcs03.html.en says

a single / partition (plus swap) is probably the easiest, simplest way
to go. However, if your partition is larger than around 6GB, choose ext3
as your partition type.

OK, the installer proposed ext4, but as you wish, OK, we will choose ext3.

 Ext2 partitions need periodic file system integrity checking, and this
 can cause delays during booting when the partition is large.


That is nice to know but what about ext4?

In fact no need to mention any ext[234] in this whole document anymore.

Bug#914109: xscreensaver-data: looks for image files to display even though it is told not to

[Francesco Potortì]

>Well, there's no way for glitchpeg to work on your desktop image, because your 
>desktop is not a jpeg...

Glitchpeg or xscreensaver could convert the desktop image to jpeg, but
that would be a feature request.

>From a user point of view, if I say that you should not look for image
files to display, you should just not do that.  This is a bug in
Xscreensaver.  There is no good reason why it should give an error.

-- 
IPIN'19 http://ipin2019.isti.cnr.itVoice:  +39.050.621.3058
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - Area della ricerca CNR  Skype:  wnlabisti
via G. Moruzzi 1, I-56124 Pisa Web:http://fly.isti.cnr.it

Bug#927986: /var/cache/fontconfig growing

[積丹尼 Dan Jacobson]

Package: fontconfig
Version: 2.13.1-2
Severity: wishlist

Today I discovered six years of files, hundreds, several megabytes, in
/var/cache/fontconfig . Nothing is cleaning them up.

Also no owner of /var/cache/fontconfig has been declared, in contrast to
$ dlocate /var/cache$
xfstt: /var/cache
debconf: /var/cache
base-files: /var/cache
locate: /var/cache
apt: /var/cache
dictionaries-common: /var/cache
apt-show-versions: /var/cache
man-db: /var/cache
dbconfig-common: /var/cache
apache2: /var/cache
tex-common: /var/cache

Bug#927985: gnome-gmail sometimes deletes message body

[Dave Steele]

Package: gnome-gmail
Severity: normal
thanks

There is a bug in gnome-gmail that causes message bodies to be absent when
the capitalized "BODY" tag is used in the mailto query string. This has
caused "Send Link" messages from browsers to have no links in the resulting
messages.

Bug#924554: SUCCESS messages: significant behaviour change

[Jan Wagner]

Hi there,

Am 25.04.19 um 21:53 schrieb Sébastien Villemot:
> On Thu, 18 Apr 2019 17:18:45 + Balint Reczey  wrote:
> 
>>* Skip sending email when no package had to be installed, upgraded or 
>> removed
>>  (LP: #1821103) (Closes: #924554)
> 
> Any chance to have this issue fixed in buster?

can we please backport this fix to buster? This is a significant
behavior change (I would call it regression).

Many thanks, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#927968: xmount: better description

[Justin B Rye]

Xavier Brochard wrote:
> Dear Maintainer,

(I'm not the maintainer; I just happened to notice the bug report.)

> I suggest to change a bit the package description putting the last sentence 
> at first :
> from
> xmount allows you to convert on-the-fly ...
> to
> xmount allows to boot acquired harddisk images using QEMU, KVM, VirtualBox, 
> VMware or alike. It will convert on-the-fly ...
 ^
"Allows you to boot" is grammatical; "allows booting" is grammatical;
but "allows to boot" without a direct object isn't allowed.  Mind you,
most of the time there's no need to use the verb "allow" at all -
xmount doesn't grant permission to boot images, it just boots them.
 
The package description for xmount does look as if it needs some work,
as the upstream homepage has what looks like an updated version of the
same text with a couple of changes in claimed capabilities.  You might
want to just change over to that, but here's a detailed review:

# xmount allows you to convert on-the-fly between multiple input and
   ==
This is a bit clearer than the current version that just repeats the
synopsis by saying it allows you to "crossmount" them - it may be the
reason for the name "xmount", but when I Google the word I only get
placenames and alarming dentistry techniques!

# output harddisk image types. xmount creates a virtual file system
 
(These constant references to "harddisk" images are a relic of the
"spinning rust" era - we should probably be saying "disk image".)

# using FUSE (Filesystem in Userspace) that contains a virtual
# representation of the input image. The virtual representation can be
 ^^
This is getting a bit repetitive.

# in raw DD, DMG, VHD, VirtualBox's virtual disk file format or in
 ===  ===
(DMG is new; VHD on the other hand is for some reason no longer
expanded as "Microsoft's Virtual Hard Disk Image format", and the
VirtualBox format is for some reason no longer called VDI - personally
I would take out the repetition of "virtual disk file format", not the
"VDI" part.)

# VmWare's VMDK file format. Input images can be raw DD, EWF (Expert
# Witness Compression Format) or AFF (Advanced Forensic Format) files.
# In addition, xmount also supports virtual write access to the output
  ^^^ 
("In addition... also" is mildly redundant.)

# files that is redirected to a cache file. This makes it possible to
# boot acquired harddisk images using QEMU, KVM, VirtualBox, VmWare or
    

If you've *got* them, they must necessarily have been acquired.  I
presume this is trying to say that xmount can be used for booting
*forensically* acquired images!

# alike.
  ^
("Or alike" is unidiomatic; we could say "or the like", but this also
makes the "for example" a bit redundant.)

Moving the last sentence to the top would be tricky, since it breaks
the connection to the previous few lines that's being made with the
phrase "This makes it possible to...".  However, we might achieve some
of the same effect of highlighting the sentence just by making it a
freestanding paragraph:

  .
  In addition, xmount supports virtual write access to the output
  files that is redirected to a cache file. This makes it possible to
  boot forensically acquired disk images using QEMU, KVM, VirtualBox,
  VmWare or the like.

(Mind you, I'm not sure what it means to talk about "output files" if
the point is that you aren't writing to them...)

Oh, and the package synopsis:

> Description: tool to crossmount between multiple input and output harddisk 
> images

That's a bit long (in a synopsis, several of these words are
unnecessary), and not even really accurate - it isn't for converting
between *images*, it's for converting between *formats*.


Here's a suggested thoroughly rewritten version:


 Description: tool for crossmounting between disk image formats
  xmount converts between multiple input and output disk image types
  on the fly, using FUSE (Filesystem in Userspace) to create a virtual
  file system representing the input image. The virtual representation
  can be in raw DD, DMG, VirtualBox VDI format, Microsoft VHD format, or
  VMware VMDK format; input images can be raw DD, EWF (Expert Witness
  Compression Format), or AFF (Advanced Forensic Format) files.
  .
  xmount can be used to boot forensic disk images with QEMU, KVM,
  VirtualBox, VmWare, or the like, since it supports virtual write
  access with redirection to a cache file.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- description.old	2019-04-25 22:23:56.073003006 +0100
+++ description.new	2019-04-25 23:21:15.533054835 +0100
@@ -1,13 +1,11 @@
-Description: tool to crossmount between multiple input and output harddisk images
- xmount allows you to convert on-the-fly between multiple 

Bug#927450: fixed in debian-security-support 2019.04.25

[Christoph Anton Mitterer]

Control: reopen -1

As if I wouldn't have written it before... o.O

Now all that was done is changing the value from 9 to 10 and it will
break again in xx months when the next-stable arrives an no one will
remember by then that this must be adapted...

Can't you just set a Conflicts/Breaks against base-files >10 ... and
people won't again fall into that trap in the future?


Cheers,,
Chris.

Bug#927984: unblock: lxqt-qtplugin/0.14.0-3

[Alf Gaida]

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

Please unblock package lxqt-qtplugin

lxqt-qtplugin try to load libfm-qt.so instead of libfm-qt.so.6.
(Closes: #927905)

>From 9f3a044c94b042d41e88d0b9aed9b2f043de8231 Mon Sep 17 00:00:00 2001
From: Alf Gaida 
Date: Wed, 24 Apr 2019 23:05:32 +0200
Subject: [PATCH] Try to load the versioned libfm-qt.so.6 instead of
 libfm-qt.so

(Closes: #927905)

---
 debian/changelog |  7 +++
 debian/patches/load-versioned-libfm-qt.patch | 20 
 debian/patches/series|  1 +
 3 files changed, 28 insertions(+)
 create mode 100644 debian/patches/load-versioned-libfm-qt.patch
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index d59d042..0282597 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+lxqt-qtplugin (0.14.0-3) unstable; urgency=medium
+
+  * Try to load the versioned libfm-qt.so.6 instead of libfm-qt.so
+(Closes: #927905) 
+
+ -- Alf Gaida   Wed, 24 Apr 2019 23:05:04 +0200
+
 lxqt-qtplugin (0.14.0-2) unstable; urgency=medium
 
   * Added missed direct dependency libqt5xdgiconloader-dev, the new
diff --git a/debian/patches/load-versioned-libfm-qt.patch 
b/debian/patches/load-versioned-libfm-qt.patch
new file mode 100644
index 000..c83378d
--- /dev/null
+++ b/debian/patches/load-versioned-libfm-qt.patch
@@ -0,0 +1,20 @@
+Description: Load the versioned library
+ Loading libfm-qt.so would not be wise, it would introduce a dependency
+ to libfm-qt-dev. So hard patching to libfm-qt.so.6 will be fine for 
+ Buster - we will find a better solution upstream for the next release.
+Author: Alf Gaida 
+
+---
+Bug-Debian: https://bugs.debian.org/927905
+
+--- lxqt-qtplugin-0.14.0.orig/src/lxqtplatformtheme.cpp
 lxqt-qtplugin-0.14.0/src/lxqtplatformtheme.cpp
+@@ -239,7 +239,7 @@ QPlatformDialogHelper *LXQtPlatformTheme
+ // The createFileDialogHelper() method is dynamically loaded from 
libfm-qt on demand
+ if(createFileDialogHelper == nullptr) {
+ // try to dynamically load libfm-qt.so
+-QLibrary libfmQtLibrary{QLatin1String("libfm-qt")};
++QLibrary libfmQtLibrary{QLatin1String("libfm-qt.so.6")};
+ libfmQtLibrary.load();
+ if(!libfmQtLibrary.isLoaded()) {
+ return nullptr;
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..231d243
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+load-versioned-libfm-qt.patch
-- 
2.20.1

unblock lxqt-qtplugin/0.14.0-3

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

Kernel: Linux 5.0.9-towo.4-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#927983: chromium: "Open all" no longer works

[Salvo Tomaselli]

Package: chromium
Version: 74.0.3729.108-1
Severity: normal

Dear Maintainer,

middle clicking on a bookmark directory used to open all of the items in
tabs. This no longer works.

Also, right clicking and selecting "Open all" used to do the same. The menu
is still there, but it does nothing.

Best

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

Kernel: Linux 4.20.5 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  chromium-common  74.0.3729.108-1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libatomic1   8.3.0-6
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1.1-1
ii  libavformat587:4.1.1-1
ii  libavutil56  7:4.1.1-1
ii  libc62.28-8
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.2.10-6
ii  libdbus-1-3  1.12.12-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42.1-1
ii  libopenjp2-7 2.3.0-2
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpci3  1:3.5.2-5
ii  libpng16-16  1.6.36-6
ii  libpulse012.2-4
ii  libre2-5 20190101+dfsg-2
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.3.0-6
ii  libva2   2.4.0-1
ii  libvpx5  1.7.0-3
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  74.0.3729.108-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox74.0.3729.108-1
ii  fonts-liberation1:1.07.4-9
ii  libgl1-mesa-dri 18.3.6-1
pn  libu2f-udev 
ii  plasma-workspace [notification-daemon]  4:5.14.5.1-1
ii  upower  0.99.10-1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  8.3.0-6
ii  libc6   2.28-8
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6

-- no debconf information

Bug#395573: Dear friend

[BEN W. JAMES]

Dear friend,

Good day to you and your family.

Please, I need to know if your email is still valid?. I have a very
important proposal for you in regarding a fund with your name in a
financial company, I cannot disclose more about this funds until i hear
from you again, sir.

Once I hear from you, I will furnish you with more information's. Get back
to me with your name and telephone number urgent.

I hope to hear from you soon.

Mr. James Ben White & Will Chen.
538 Rush Green Road,
Romford RM7 0LX. UK

Bug#923322: plasma-browser-integration: Incorrect installation directory for chrome config file

[Dmitry Shachnev]

Hi David and all,

On Tue, Feb 26, 2019 at 12:50:43PM +, David Edmundson wrote:
> Plasma browser integration needs to install a file to /etc/opt
>
> Upstream does this.
>
> There was a concious decision in debian packaging to do something else,
> but the move to break it cites a rule about installing into /opt
> This does not apply as it refers to a completely different directory.
> Note the /etc prefix.

It was brought to my attention that the Plasma Integration extension for
Chrome [1] has this note in its description:

  NOTE: This extension is not supported on Debian.

As far as I understand, this extension works fine with Chromium from
our repository, but does not work (out of the box) with Google Chrome
when it is installed from Google's repository.

On one hand, Debian's packages are not obliged to be compatible with
third-party packages. On the other hand, people who use Google's builds
may blame Debian if things are not working for them.

> A solution has been found for chrome-gnome-shell using postinst/postrm 
> to copy the file into the correct location.
>
> Can we have the same system used here please.

That system is a bit more complex than it sounds, as the postrm script
actually needs to *recreate* /etc/opt directory after dpkg deletes it.
See the bug [2] for details.

The good news is that chrome-gnome-shell maintainers have already done
the hard work, so we can just copy their logic (with the json file name
changed, obviously) if we decide to go that way.

Maxy, Scarlett, what do you think about this?

I do not think we should fix this for Buster, as the fix would be quite
tricky and if I were the release team I would not like it :)

Also, users who are affected may follow the instruction that we ship in
/usr/share/doc/plasma-browser-integration/README.Debian [1] and add the
symlink manually. I wonder if maybe the extension description can mention
that instruction (instead of just saying Debian is not supported)?

[1]: 
https://chrome.google.com/webstore/detail/plasma-integration/cimiefiiaegbelhefglklhhakcgmhkai
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888549
[3]: 
https://salsa.debian.org/qt-kde-team/kde/plasma-browser-integration/blob/master/debian/README.Debian

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#926330: RFS: cuba/4.2-1 [ITP]

[Francesco Montanari]

Hi Sébastien,

Thanks for taking the time to review the package.

On 4/17/19 2:55 PM, Sébastien Villemot wrote:

— The autopkgtest does not work. I get:

autopkgtest [14:48:10]: test cuba: [---
make: *** No rule to make target 'check'.  Stop.
autopkgtest [14:48:11]: test cuba: ---]
autopkgtest [14:48:11]: test cuba:  - - - - - - - - - - results - - - - - - - - 
- -
cuba FAIL non-zero exit status 2



I misunderstood how autopkgtest works. Now the test is a simple compile, 
link and run check. I checked that it succeeds adding the B20autopkgtest 
hook to pbuilder.



— I think there is a typo in the long description of libcuba4. It talks
about “libuba4-dev”, while I guess you meant “libcuba-dev”.


Fixed, thanks.


— In debian/changelog, you should keep the three former entries
corresponding to the previous version of the package. Keeping the whole
history of the package will facilitate the long-term maintenance.

See https://tracker.debian.org/media/packages/c/cuba/changelog-3.0%2B2024-2


That's a doubt I still had, thanks for bringing it up. I added back the 
old entries and more details about differences with the old package.


Best,
Francesco

Bug#927300: /etc/mime.types should know about .mjs extension for JavaScript modules

[Charles Plessy]

Le Thu, Apr 25, 2019 at 04:27:04PM +0200, Basile Starynkevitch a écrit :
> 
> Or are you suggesting that both Chrome and FireFox are buggy, because they
> accept wrongly (and work well in practice) JavaScript /modules/ with .mjs
> associated to text/javascript (and that works /as documented/ here
> ).

Hi Basile,

just for the record, would your application work with
application/javascript instead of text/javascript ?  If this is the
case, then I can add the mjs file extension under the
application/javascript media type and therefore respect the RFC.

Have a nice day,

-- 
Charles

Bug#927982: chromium: native messaging issues

[sergio]

Package: chromium
Version: 74.0.3729.108-1
Severity: normal

Dear Maintainer,

with the last chromium update to 74.0.3729.108-1 browserpass-extension freezes 
on
native messaging communication with "Loading available logins.."

related browserpass-extension issue:
https://github.com/browserpass/browserpass-extension/issues/137

Bug#927981: golang-github-seccomp-libseccomp-golang: CVE-2017-18367

[Salvatore Bonaccorso]

Source: golang-github-seccomp-libseccomp-golang
Version: 0.9.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/seccomp/libseccomp-golang/issues/22

Hi,

The following vulnerability was published for 
golang-github-seccomp-libseccomp-golang.

CVE-2017-18367[0]:
| libseccomp-golang 0.9.0 and earlier incorrectly generates BPFs that OR
| multiple arguments rather than ANDing them. A process running under a
| restrictive seccomp filter that specified multiple syscall arguments
| could bypass intended access restrictions by specifying a single
| matching argument.


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-2017-18367
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18367
[1] https://github.com/seccomp/libseccomp-golang/issues/22
[2] 
https://github.com/seccomp/libseccomp-golang/commit/06e7a29f36a34b8cf419aeb87b979ee508e58f9e
[3] http://www.openwall.com/lists/oss-security/2019/04/25/6

Regards,
Salvatore

Bug#927797: unblock: debian-archive-keyring/2019.1

[Cyril Brulebois]

Hi Niels,

Niels Thykier  (2019-04-23):
> Package: release.debian.org
> Severity: normal
> Tags: d-i
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package debian-archive-keyring, which includes the new
> signing keys for buster.
> 
> """
> debian-archive-keyring (2019.1) unstable; urgency=medium
> 
>   [ Adam D. Barratt ]
>   * Ensure separated keyrings for Wheezy's keys are removed.  Thanks
> to Sven Joachim.
> (Closes: #912214)
> 
>   [ Jonathan Wiltshire ]
>   * Add my own key to the team-members keyring
>   * Add Debian Stable Release key (10/buster) (ID: DCC9EFBF77E11517)
> (Closes: #917536)
>   * Add Debian Archive Automatic Signing Key (10/buster)
> (ID: BCDDDC30D7C23CBBABEE) and Debian Security Archive Automatic
> Signing Key (10/buster) (ID: C5FF4DFAB270CAA96DFA)
> (Closes: #917535)
>   * Refresh the signature over keyrings/debian-archive-keyring.gpg
> 
>   [ Niels Thykier ]
>   * Add myself as uploader (Closes: #927765)
> 
>  -- Niels Thykier   Tue, 23 Apr 2019 13:42:28 +0200
> """
> 
> A diffstat:
> 
> """
> 
> $ diffstat debian-archive-keyring.debdiff
>  active-keys/add-buster-automatic  |  179 +++
>  active-keys/add-buster-security-automatic |  179 +++
>  active-keys/add-buster-stable |   58 
>  active-keys/index |3 
>  active-keys/index.gpg |   21 +
>  debian/changelog  |   22 +
>  debian/control|1 
>  debian/debian-archive-keyring.maintscript |2 
>  keyrings/debian-archive-keyring.gpg.asc   |   21 +
>  team-members/add-5394479DD3524C51 |  357 
> ++
>  team-members/index|1 
>  team-members/index.gpg|   21 +
>  12 files changed, 841 insertions(+), 24 deletions(-)
> """

That'd be the usual source debdiff, but that doesn't account for this
change in the udeb (which I wasn't expecting from the changelog
entries):

$ debdiff debian-archive-keyring-udeb_2018.1_all.udeb 
debian-archive-keyring-udeb_2019.1_all.udeb
[…]
Files in second .deb but not in first
-
-rw-r--r--  root/root 
/usr/share/keyrings/debian-archive-buster-automatic.gpg
-rw-r--r--  root/root 
/usr/share/keyrings/debian-archive-buster-security-automatic.gpg
-rw-r--r--  root/root /usr/share/keyrings/debian-archive-buster-stable.gpg
[…]

Having those extra files around shouldn't hurt (and doesn't seem to,
based on some quick tests using a brand new netboot-gtk image built
against sid), but I thought I'd mention it anyway.


No objections, feel free to unblock.


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


signature.asc
Description: PGP signature

Bug#927977: Split dc_other_hostnames when presenting them to the user in dpkg-reconfigure

[積丹尼 Dan Jacobson]

Or just add "any of" in
>> │ system. If this option is chosen, 'jidanni.org', 'localhost' and **ANY OF**
>> │ 
>> 'jidanni2.jidanni.org;jidanni5.jidanni.org;jidanni7.jidanni.org;jidanni8.jidanni.org'
>>  in From,
if semicolon is detected.

Bug#927922: SSL error: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol

[積丹尼 Dan Jacobson]

retitle 927922 Ask user if really he wants to proceed to a dangerous site. 
Don't just quit
thanks

All I know is in such cases
$ w3m some_site.com
should say

  some_site.com is using dangerous software.
  (ERR: SSL v... v... )
  Please ask the site owner to fix it.

  [QUIT] [Proceed anyway to some_site.com despite all the risks]

just like all other browsers do.

(In fact all the other browsers don't consider this site bad.)

Bug#927977: Split dc_other_hostnames when presenting them to the user in dpkg-reconfigure

[Marc Haber]

On Fri, Apr 26, 2019 at 03:20:00AM +0800, 積丹尼 Dan Jacobson wrote:
> dpkg-reconfigure exim4-config says
> 
>  Mail Server configuration ├──┐
>   │   
>   │
>   │ The headers of outgoing mail can be rewritten to make it appear to have 
> been generated on a different   │
>   │ system. If this option is chosen, 'jidanni.org', 'localhost' and  
>   │
>   │ 
> 'jidanni2.jidanni.org;jidanni5.jidanni.org;jidanni7.jidanni.org;jidanni8.jidanni.org'
>  in From,  │
>   │ Reply-To, Sender and Return-Path are rewritten.   
>   │
>   │   
>   │
>   │ Hide local mail name in outgoing mail?
> 
> Shouldn't
>
> 'jidanni2.jidanni.org;jidanni5.jidanni.org;jidanni7.jidanni.org;jidanni8.jidanni.org'
> be written
>'jidanni2.jidanni.org' and 'jidanni5.jidanni.org' and 
> 'jidanni7.jidanni.org' and 'jidanni8.jidanni.org'
> 
> I mean nobody is going to have
> From: jidanni2.jidanni.org;jidanni5.jid...
> in their mail.
> 
> So you need to split dc_other_hostnames when presenting them to the user
> in this message.

Send a tested and documented patch please.

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#927862: youtube-dl: please update to 2019.04.24

[Thorsten Glaser]

Package: youtube-dl
Version: 2019.01.17-1
Followup-For: Bug #927862
Control: severity -1 grave
Control: retitle -1 youtube-dl: needs upstream version update to continue 
working

It now doesn’t work at all any more, however, the upstream version does:

$ youtube-dl -f 18 U2n5aGqou9E
[youtube] U2n5aGqou9E: Downloading webpage
ERROR: U2n5aGqou9E: "token" parameter not in video info for unknown reason; 
please report this issue on https://yt-dl.org/bug . Make sure you are using the 
latest version; see  https://yt-dl.org/update  on how to update. Be sure to 
call youtube-dl with the --verbose flag and include its complete output.
1|tglase@tglase:~ $ Youtube-dl -f 18 U2n5aGqou9E
[youtube] U2n5aGqou9E: Downloading webpage
[download] Destination: U2n5aGqou9E.mp4
[download] 100% of 29.43MiB in 00:08
tglase@tglase:~ $ dpkg -l youtube-dl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  youtube-dl 2019.01.17-1 all  downloader of videos from YouTube 
and other sites
tglase@tglase:~ $ Youtube-dl --version
2019.04.24


I’m sure you have a procedure in place to get freeze exceptions, too.

-- System Information:
Debian Release: 10.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages youtube-dl depends on:
ii  python33.7.3-1
ii  python3-pkg-resources  40.8.0-1

Versions of packages youtube-dl recommends:
ii  ca-bundle [ca-certificates]  20181220tarent1
ii  curl 7.64.0-2
ii  ffmpeg   7:4.1.1-1
ii  mplayer  2:1.3.0-8+b3
pn  phantomjs
pn  python3-pyxattr  
pn  rtmpdump 
ii  wget 1.20.1-1.1

youtube-dl suggests no packages.

-- no debconf information

Bug#927970: lintian: false positives for missing-systemd-timer-for-cron-script?

[Francesco Poli]

On Thu, 25 Apr 2019 13:43:23 -0400 Chris Lamb wrote:

[...]
> You are, of course, entirely right. Fixed in Git, now pending upload

I am glad to help!   :-)

Thanks for your prompt reaction.
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2AIFhkAbOQ.pgp
Description: PGP signature

Bug#927944: [Pkg-javascript-devel] Bug#927944: node-unicode-data: FTBFS with unicode-data >= 12.0.0

[Julien Puydt]

Hi,

On 25/04/2019 10:55, Alastair McKinstry wrote:
> Source: node-unicode-data
> Version: 0~20181101+gitaddfb440-1
> Severity: serious
> Justification: Policy 4.2
> 
> node-unicode-data FTBFS with unicode-data 12.0.0 and needs to be updated.
> 

There is a newer version in NEW which is supposed to fix this.

Perhaps you can check from the git repo?

Thanks,

JP

Bug#927395: Do not touch(1) update-exim4.conf.conf for no good reason

[積丹尼 Dan Jacobson]

retitle 927395 Add a update-exim4.conf.conf.local to avoid edit conflicts
thanks

Well all I know is
/etc/exim4/exim4.conf.localmacros
is the safe place for macros, so there also should be a safe place for
things that would go in
/etc/exim4/update-exim4.conf.conf too.

By safe I mean guaranteed that you and I are not trying to edit the same
file.

I mean the package generates lots of files, some with warnings "DO NOT
EDIT, autogenerated", some with warnings "automatic changes to this file
may happen".

Well, certainly you could be so kind as your are with
/etc/exim4/update-exim4.conf.localmacros by just reading an additional
file in if found.

That's the whole idea behind the ...d/* where we could just drop in a
./000_my_stuff , but alas all there is is just a monolithic
/etc/exim4/update-exim4.conf.conf .

Bug#927980: unblock: librsvg/2.44.10-2.1 (pre-approval)

[Boyuan Yang]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: pkg-gnome-maintain...@lists.alioth.debian.org
927...@bugs.debian.org

Hello all,

I have prepared an NMU to fix bug https://bugs.debian.org/927886 .
This bug in librsvg caused deepin-image-viewer to crash on startup.
The patch is picked
from upstream git trunk. The full debdiff is pasted in this mail.

I have confirmed that deepin-image-viewer will no longer crash with this patch.

The upload hasn't been made yet. Please let me know if it looks okay
to you and I'll upload the NMU later.

--
Thanks,
Boyuan Yang

diff -Nru librsvg-2.44.10/debian/changelog librsvg-2.44.10/debian/changelog
--- librsvg-2.44.10/debian/changelog2019-04-11 04:29:30.0 -0400
+++ librsvg-2.44.10/debian/changelog2019-04-25 15:55:18.0 -0400
@@ -1,3 +1,12 @@
+librsvg (2.44.10-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * debian/patches/keep-positive-radii.patch: backport an upstream fix for
+an assertion error where radii should always be positive
+(Closes: #927886)
+
+ -- Boyuan Yang   Thu, 25 Apr 2019 15:55:18 -0400
+
 librsvg (2.44.10-2) unstable; urgency=medium

   * debian/patches/typenum-i386-ftbfs.patch: backport an upstream fix for a
diff -Nru librsvg-2.44.10/debian/patches/keep-positive-radii.patch
librsvg-2.44.10/debian/patches/keep-positive-radii.patch
--- librsvg-2.44.10/debian/patches/keep-positive-radii.patch
1969-12-31 19:00:00.0 -0500
+++ librsvg-2.44.10/debian/patches/keep-positive-radii.patch
2019-04-25 15:52:27.0 -0400
@@ -0,0 +1,33 @@
+From: Federico Mena Quintero 
+Date: Sat, 29 Dec 2018 12:32:08 -0600
+Subject: Morphology needs positive radii even after the transformation
+
+This is the same pattern as in gaussian_blur.rs; the paffine
+transformation can leave us with negative radii, so take their
+absolute value after the transformation.
+
+This fixes assertion error (crashing) when nagative r takes place.
+
+Forwarded: https://gitlab.gnome.org/GNOME/librsvg/issues/395
+Applied-Upstream:
https://gitlab.gnome.org/GNOME/librsvg/commit/4ef7f198fceb8fb4a544f4768174af5b11fc9bcc
+Bug-Debian: https://bugs.debian.org/927886
+Signed-off-by: Boyuan Yang 
+---
+ rsvg_internals/src/filters/morphology.rs | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/rsvg_internals/src/filters/morphology.rs
b/rsvg_internals/src/filters/morphology.rs
+index 60fbcef..7de1a0d 100644
+--- a/rsvg_internals/src/filters/morphology.rs
 b/rsvg_internals/src/filters/morphology.rs
+@@ -95,6 +95,10 @@ impl Filter for Morphology {
+ let (rx, ry) = self.radius.get();
+ let (rx, ry) = ctx.paffine().transform_distance(rx, ry);
+
++// The radii can become negative here due to the transform.
++let rx = rx.abs();
++let ry = ry.abs();
++
+ let operator = self.operator.get();
+
+ let mut output_surface = ImageSurface::create(
diff -Nru librsvg-2.44.10/debian/patches/series
librsvg-2.44.10/debian/patches/series
--- librsvg-2.44.10/debian/patches/series2019-04-11 04:29:30.0 -0400
+++ librsvg-2.44.10/debian/patches/series2019-04-25 15:54:21.0 -0400
@@ -1,3 +1,4 @@
 10_rsvg-gz.patch
 typenum-i386-ftbfs.patch
 i386-rounding-errors.patch
+keep-positive-radii.patch

Bug#927972: jitterentropy_rng.ko never loads

[Ben Hutchings]

Control: reassign -1 jitterentropy-rngd
Control: severity -1 wishlist

There is no dependency between the user-space daemon and the kernel
module.  And I don't see any kernel bug here, but this might be a
wishlist item for the user-space package.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.




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

Bug#927979: openstack-pkg-tools switch admin endpoint port 35357 to 5000

[Michal Arbet]

Package: openstack-pkg-tools
Version: 98

Hi,

Openstack-pkg-tools are used for generating postints for other openstack
projects, for example creating users, register endpoints, create services
 etc. , and this imported blocks of code from openstack-pkg-tools iin
postinsts are using keystone admin endpoint on port 35357 to do this.

Admin endpoint 35357 was removed from keystone and was replaced by public
endpoint port which is listening on 5000.

Because of this it's needed to replace 35357 -> 5000 and rebuild all
openstack service packages.

Thanks,
Michal Arbet ( kevko )

Bug#865607: gdb: CVE-2017-9778: Fail to detect invalid FDE header, can exhaust gdb process's virtual memory and terminate debug session

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream

Hi,

https://sourceware.org/bugzilla/show_bug.cgi?id=21600#c11 references
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=723adb650a31859d7cc45832cb8adca0206455ed
as the commit adressing this issue.

Regards,
Salvatore

Bug#927977: Split dc_other_hostnames when presenting them to the user in dpkg-reconfigure

[積丹尼 Dan Jacobson]

Package: exim4-config
Version: 4.92-6
Severity: minor

dpkg-reconfigure exim4-config says

 Mail Server configuration ├──┐
  │ 
│
  │ The headers of outgoing mail can be rewritten to make it appear to have 
been generated on a different   │
  │ system. If this option is chosen, 'jidanni.org', 'localhost' and
│
  │ 
'jidanni2.jidanni.org;jidanni5.jidanni.org;jidanni7.jidanni.org;jidanni8.jidanni.org'
 in From,  │
  │ Reply-To, Sender and Return-Path are rewritten. 
│
  │ 
│
  │ Hide local mail name in outgoing mail?

Shouldn't
   
'jidanni2.jidanni.org;jidanni5.jidanni.org;jidanni7.jidanni.org;jidanni8.jidanni.org'
be written
   'jidanni2.jidanni.org' and 'jidanni5.jidanni.org' and 'jidanni7.jidanni.org' 
and 'jidanni8.jidanni.org'

I mean nobody is going to have
From: jidanni2.jidanni.org;jidanni5.jid...
in their mail.

So you need to split dc_other_hostnames when presenting them to the user
in this message.

Bug#927978: gst-plugins-base1.0: CVE-2019-9928: Buffer overflow in RTSP parsing

[Salvatore Bonaccorso]

Source: gst-plugins-base1.0
Version: 1.14.4-1
Severity: grave
Tags: security upstream
Forwarded: 
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/157

Hi,

The following vulnerability was published for gst-plugins-base1.0.

CVE-2019-9928[0]:
| GStreamer before 1.16.0 has a heap-based buffer overflow in the RTSP
| connection parser via a crafted response from a server, potentially
| allowing remote code execution.


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-9928
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9928
[1] https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/157
[2] https://gstreamer.freedesktop.org/security/sa-2019-0001.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#924554: fixed in unattended-upgrades 1.12

[Sébastien Villemot]

On Thu, 18 Apr 2019 17:18:45 + Balint Reczey  wrote:

>* Skip sending email when no package had to be installed, upgraded or 
> removed
>  (LP: #1821103) (Closes: #924554)

Any chance to have this issue fixed in buster?

Thanks,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org



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

Bug#927976: gcc-8: FTBFS on ia64 due to bootstrap comparison failure

[James Clarke]

Source: gcc-8
Version: 8-20180308-1
Severity: important
Tags: upstream patch
Forwarded: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg01000.html
X-Debbugs-Cc: debian-i...@lists.debian.org

Hi,
A bug in a new GCC 8.1 feature was exposed by an updated binutils with
debug_view support, which causes gcc-8 to FTBFS on ia64 with a bootstrap
comparison failure. Please include the above patch to fix this (possibly
only enabled on ia64 if you want to be conservative, as it has not been
widely tested on other architectures).

Thanks,
James

Bug#925941: nvenc not in ffmpeg

[Christoph Döpmann]

I'd like to second that request. For me, too, it's very unfortunate that 
the nvenc codecs are not compiled into ffmpeg in buster, anymore. Any 
chance this could be fixed? Or is there any particular reason why one 
would not want to have nvenc in ffmpeg?

Bug#927913: Second chromium kills the first one, and we see "Restore pages?"

[Jürgen Göricke]

Dear Maintainer,

   * What led up to the situation?

I started a chromium window and wanted to open one more.
This error has occurred since the update to version 74.0.3729.108-1.

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

As already described, I wanted to open another chromium window.

   * What was the outcome of this action?

The first Chromium window was closed with the following error message.
For error diagnosis I started Chromium via command line interface and could see 
this error message.

[2195:2195:0425/202122.818950:ERROR:vaapi_wrapper.cc(335)] vaInitialize failed: 
unknown libva error
[2195:2195:0425/202122.841660:ERROR:sandbox_linux.cc(368)] InitializeSandbox() 
called with multiple threads in process gpu-process.
[2195:2195:0425/202142.935237:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2195:2195:0425/202211.279588:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2195:2195:0425/202629.954596:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2195:2195:0425/202859.748973:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2195:2195:0425/203531.165889:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[2195:2195:0425/203557.201811:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command

   * What outcome did you expect instead?

I expected to be able to open multiple Chromium windows without crashing the 
opened instance.




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

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

Versions of packages chromium depends on:
ii  chromium-common  74.0.3729.108-1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libatomic1   8.3.0-6
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1.1-1
ii  libavformat587:4.1.1-1
ii  libavutil56  7:4.1.1-1
ii  libc62.28-8
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.2.10-6
ii  libdbus-1-3  1.12.12-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42.1-1
ii  libopenjp2-7 2.3.0-2
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpci3  1:3.5.2-5
ii  libpng16-16  1.6.36-6
ii  libpulse012.2-4
ii  libre2-5 20190101+dfsg-2
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.3.0-6
ii  libva2   2.4.0-1
ii  libvpx5  1.7.0-3
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  74.0.3729.108-1

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n74.0.3729.108-1
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox 74.0.3729.108-1
ii  fonts-liberation 1:1.07.4-9
ii  libgl1-mesa-dri

Bug#927397: u-boot: Very poor ethernet performance on A20 OLinuXino Lime2 Rev.G2

[Sunil Mohan Adapa]

>
> It seems you forgot to attach the mentioned Olimex report.

The report is in the inline section "Report from Olimex team (with
Rev.G2)". I used term 'attached' loosely.

>
> Do I understand you correctly that the attached patch is what Olimex
> propose but that you do *not* recommended to use it as-is because it
> badly affects older boards?

Olimex has kindly provided us the patch so that we can create a fully
working u-boot build for Lime2 Rev.G2 board. They did not imply that the
patch was suitable for other boards as well.

>
> Were your Lime2 boards connected with a cross-over cable or via a switch
> during those tests?

Lime2 was connected to a laptop via a cross-over cable (actually regular
cable but the hardware actually detects cross-over setup and
automatically swaps TX/RX).

[...]

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#926032: [chromium] Buggy / Solarized videos

[victor . boyau]

Hello,

Unfortunately the new release 74.0.3729.108-1 does not fix anything regarding 
this issue. As soon as I disabled the workaround we discussed earlier in order 
to use hardware decoding again, solarized videos came back on many web sites.

Regards

V.B.

Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)

[Aurelien Jarno]

On 2019-04-25 14:50, Aurelien Jarno wrote:
> On 2019-04-23 22:16, Aurelien Jarno wrote:
> > Source: linux
> > Version: 4.19.28-2
> > Severity: important
> > 
> > After upgrading hartmann.debian.org (an armhf buildd using an Armada XP
> > GP board) from buster to stretch, the ethernet device is not working
> 
> More precisely the board is a "Marvell Armada XP Development Board
> DB-MV784MP-GP"
> 
> > anymore. Using tcpdump on both the buildd and a remote host, it appears
> > that the packets correctly leave the board and that the reception side
> > fails.
> > 
> > The module used for the ethernet device is mvneta. The corresponding DT
> > compatible entry is "marvell,armada-xp-neta".
> >
> 
> I have started a "bisection" with the kernels from snapshot. This is
> what I have found so far:
> 
> This one works:
> - linux-image-4.19.0-rc6-armmp-lpae_4.19~rc6-1~exp1_armhf.deb 
> 
> The following ones don't:
> - linux-image-4.19.0-rc7-armmp-lpae_4.19~rc7-1~exp1_armhf.deb
> - linux-image-5.0.0-trunk-armmp_5.0.2-1~exp1_armhf.deb
> 
> My guess (I don't have time to try more now) is that the issue is caused
> by the following change:
> 
> |  [ Uwe Kleine-König ]
> |  * [armhf] enable MVNETA_BM_ENABLE and CAN_FLEXCAN as a module
> 

I confirm this is the issue. Disabling MVNETA_BM_ENABLE on kernel 
4.19.28-2 fixes the issue. Note that it breaks the ABI.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#927862: youtube-dl: please update to 2019.04.24

[pavi]

> I have to add that not only playlists but playing some individual videos

> also doesn't work. 
+1 none of the youtube videos are working with current unstable version
> Maybe this bug should be marked as "serious".

+1 its a broken package as of now.

Regards,
Pavi

Bug#927862: youtube-dl: please update to 2019.04.24

[Holger Levsen]

control: severity -1 serious
# justification: this indeed breaks download of youtube videos

On Fri, Apr 26, 2019 at 12:30:27AM +0530, Joseph Nuthalapati wrote:
> I have to add that not only playlists but playing some individual videos
> also doesn't work.
> 
> Maybe this bug should be marked as "serious".

yes, thanks.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#927975: ITP: r-bioc-rhdf5lib -- GNU R hdf5 library

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-rhdf5lib -- GNU R hdf5 library
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-rhdf5lib
  Version : 1.4.3
  Upstream Author : Mike Smith
* URL : https://bioconductor.org/packages/Rhdf5lib/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : GNU R hdf5 library
 This GNU R package provides an interface to the
 C and C++ hdf5 libraries.
 .
 HDF5 is a file format and library for storing scientific data.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5lib

Bug#927862: youtube-dl: please update to 2019.04.24

[Joseph Nuthalapati]

I have to add that not only playlists but playing some individual videos
also doesn't work.

Maybe this bug should be marked as "serious".


Error log:

[ytdl_hook] ERROR: Ax0v4i3arrw: "token" parameter not in video info for
unknown reason; please report this issue on https://yt-dl.org/bug . Make
sure you are using the latest version; see  https://yt-dl.org/update  on
how to update. Be sure to call youtube-dl with the --verbose flag and
include its complete output.
[ytdl_hook] youtube-dl failed: unexpected error ocurred
Failed to recognize file format.


Exiting... (Errors when loading file)

-- 
Regards,
Joseph Nuthalapati




signature.asc
Description: OpenPGP digital signature

Bug#927397: u-boot: Very poor ethernet performance on A20 OLinuXino Lime2 Rev.G2

[Sunil Mohan Adapa]

The following is the patch Olimex has applied on u-boot for the images
that they build. It is meant to work for all hardware revisions of Lime2.

https://github.com/OLIMEX/OLINUXINO/blob/master/SOFTWARE/A20/A20-build-3.4.103-release-7/a20-phy_1000_100-dram.patch

It does not seem suitable for non-Lime2 boards and may need changes to
before it can be submitted upstream (or Debian).

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#927974: jitterentropy_rng.ko never loads: jitternentropy-rngd doesn't complain

[proc...@riseup.net]

Package: jitterentropy-rngd
Version: 1.0.8-3
Severity: important

Dear Maintainer,

As part of my work on a downstream privacy distro, I tested jitternentropy-rngd 
while integrating it and discovered the complementing kernel module 
jitterentropy_rng.ko never loads on boot as it is supposed to when the 
userspace jitterentropy daemon is installed. As a VM based OS a reliable 
entropy source that guarantees /dev/urandom is safely seeded is a priority. To 
test if it works one would see the signs described by the jitter dev Stephan 
Mueller [0]. I've confirmed that oddly no dmesg messages appear and the 
userspace service churns along fine despite the module silently never loading. 
Please try to fix this when possible. I have reported this problem against the 
kernel package too.

TIA 

[0] https://www.whonix.org/pipermail/whonix-devel/2019-April/001365.html
[1] https://www.whonix.org/pipermail/whonix-devel/2019-April/001366.html

Bug#927973: ncurses-base: Please move tmux and tmux-256color to ncurses-base

[Stephen Gelman]

Package: ncurses-base
Version: 6.1+20181013-2
Severity: wishlist

Tmux has gotten very popular and seems to be at a similar level of
popularity as screen (which is already in ncurses-base). We currently
have to install ncurses-term on all our servers because of this which
seems like overkill for this.

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

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

-- no debconf information

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

Package: linux-image-amd64
Version: 4.19+104
Severity: important

Dear Maintainer,

As part of my work on a downstream privacy distro, I tested jitternentropy-rngd 
while integrating it and discovered the complementing kernel module 
jitterentropy_rng.ko never loads on boot as it is supposed to when the 
userspace jitterentropy daemon is installed. As a VM based OS a reliable 
entropy source that guarantees /dev/urandom is safely seeded is a priority. To 
test if it works one would see the signs described by the jitter dev Stephan 
Mueller [0]. I;ve confirmed that oddly no dmesg messages appear and the 
userspace service churns along fine despite the module silently never loading. 
Please try to fix this when possible. I will report this problem against the 
jitter package too.

TIA 

[0] https://www.whonix.org/pipermail/whonix-devel/2019-April/001365.html
[1] https://www.whonix.org/pipermail/whonix-devel/2019-April/001366.html

Bug#926857: mesa-vdpau-drivers: broken symlink: /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_gallium.so -> libvdpau_gallium.so.1.0.0

[Fabio Pedretti]

See https://bugs.freedesktop.org/show_bug.cgi?id=110356

Bug#927289: [debian-mysql] Bug#927289: mariadb-server-10.3: SSL error: Unable to get private key

[Olaf van der Spek]

Op wo 17 apr. 2019 om 19:45 schreef Otto Kekäläinen :
>
> > > Try making the overly broad permissions of
> > > /etc/mysql/ssl/server-key.pem -rwxr-xr-x
> > > to something less world-readable.
> >
> > # chmod 700 server-cert.pem
> > # service mysql restart
> >
> > error.log:
> > SSL error: Unable to get certificate from '/etc/mysql/ssl/server-cert.pem'
> > 2019-04-17 14:41:29 0 [Warning] Failed to setup SSL
> > 2019-04-17 14:41:29 0 [Warning] SSL error: Unable to get certificate
>
> Maybe you need to seek out for SSL experts on what the correct file
> permissions or other settings are supposed to be. Based on the info
> provided there is nothing I can debug or fix, sorry.

The documentation could be improved. I've created a ticket upstream @
https://jira.mariadb.org/browse/MDEV-19268


-- 
Olaf

Bug#918520: Lack of thread safety (in eatmydata_init?) causes non-deterministic behaviour

[Chris Lamb]

reassign 918520 src:libeatmydata
thanks

Actually re-assigning to libeatmydata…


Regards,

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

Bug#927970: lintian: false positives for missing-systemd-timer-for-cron-script?

[Chris Lamb]

tags 927970 + pending
thanks

> I have a question: is the following line
>
>return if any { m,^/lib/systemd/system/\.timer$, } $info->sorted_index;
>
> missing something in the regexp?

You are, of course, entirely right. Fixed in Git, now pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/591f36e58ed56b289c4cee34f736f39f91a65fc9

  checks/systemd.pm | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)


Regards,

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

Bug#927971: tomcat9: split policy files and libexec scripts so that pki-server can use them

[Timo Aaltonen]

Source: tomcat9
Severity: normal

Hi,

I'd like to use the libexec scripts and policy files from the pki-server 
systemd service file, but installing 'tomcat9' will start an instance and then 
'pkispawn' would fail because the (default) port is already used. So I can't 
just depend on tomcat9, but maybe these files could be moved to -common or 
-user?

Bug#927860: RM: jboss-annotations-1.2-api/1.0.0-1

[Timo Aaltonen]

On 25.4.2019 20.04, Paul Gevers wrote:
> Control: reassign -1 ftp.debian.org
> Control: retitle -1 RM: jboss-annotations-1.2-api -- ROM; duplicate
> 
> On 24-04-2019 11:18, Paul Gevers wrote:
>> Hi Timo,
>>
>> On 24-04-2019 10:28, Timo Aaltonen wrote:
>>> Dogtag-pki needed this, but I wasn't aware that another version
>>> was already being packaged by pkg-java (geronimo-annotation-1.3-spec), and
>>> that version is fine for Dogtag too. So, please remove 
>>> jboss-annotations-1.2-api
>>> which is essentially duplicate of geronimo-annotations.
>>
>> Do you also want it removed from unstable? Then the bug should be
>> reassigned to ftp.debian.org. To avoid delay, I have already hinted it
>> for removal in testing.
> 
> Reassigning now as there nothing more here for the release team to be
> done, and assuming I understood you correctly.

Yes, sorry.. you were right and it should've been filed against
ftp.debian.org in the first place.

thanks!


-- 
t

Bug#927954: konqueror: Exit when opening http https' ftps' links

[Bernhard Übelacker]

Hello Osama Nasr,


> By the way, I've installed GIMP, although there was a bug
> (libmypaint-common #906144).
> I don't know if that have a relation or not.

On a short look I guess this is not related.



> konqueror: ../nouveau/pushbuf.c:723: nouveau_pushbuf_data: Assertion 
> `kref' failed.
> Received signal 6
> #0 0x7f73c396cbde 
> #1 0x7f73c396ccf0 
> #2 0x7f73c396d327 
> #3 0x7f73f7a1f940 
> #4 0x7f73f7a1f8bb gsignal
> #5 0x7f73f7a0a535 abort
> #6 0x7f73f7a0a40f 
> #7 0x7f73f7a180f2 __assert_fail
> #8 0x7f73ee7a059f nouveau_pushbuf_data
> #9 0x7f73ee7a0503 nouveau_pushbuf_data
> #10 0x7f73ee7a062f 
> #11 0x7f73ee7a0a7f 
> #12 0x7f73ee7a1670 nouveau_pushbuf_kick
> #13 0x7f73ed89dbc6 
> #14 0x7f73ed9c5faf 
> #15 0x7f73ed5a0b37 
> #16 0x7f73ee77b243 
> #17 0x7f73effa8146 
> #18 0x7f73f60b6c4b QOpenGLContext::swapBuffers()
> ...

I guess this is the most interesting part and points to
an error in the nouveau driver.

This bug might be related:

https://bugs.freedesktop.org/show_bug.cgi?id=91632

It may help if you also add the output of this command, if installed:

glxinfo -B


Kind regards,
Bernhard

Bug#927860: RM: jboss-annotations-1.2-api/1.0.0-1

[Paul Gevers]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: jboss-annotations-1.2-api -- ROM; duplicate

On 24-04-2019 11:18, Paul Gevers wrote:
> Hi Timo,
> 
> On 24-04-2019 10:28, Timo Aaltonen wrote:
>> Dogtag-pki needed this, but I wasn't aware that another version
>> was already being packaged by pkg-java (geronimo-annotation-1.3-spec), and
>> that version is fine for Dogtag too. So, please remove 
>> jboss-annotations-1.2-api
>> which is essentially duplicate of geronimo-annotations.
> 
> Do you also want it removed from unstable? Then the bug should be
> reassigned to ftp.debian.org. To avoid delay, I have already hinted it
> for removal in testing.

Reassigning now as there nothing more here for the release team to be
done, and assuming I understood you correctly.

Paul

Bug#927954: konqueror: Exit when opening http https' ftps' links

[Bernhard Übelacker]

Hello Osama Nasr,

please use the "reply all" to answer - that way the information
is automatically stored also in the bugs web site:

https://bugs.debian.org/927954

Kind regards,
Bernhard




Am 25.04.19 um 18:19 schrieb Osama Nasr:
> By the way, I've installed GIMP, although there was a bug
> (libmypaint-common #906144).
> I don't know if that have a relation or not.
> 
> On Thu, 25 Apr 2019, 6:01 pm Osama Nasr,  > wrote:
> 
> osama@debian:~$ konqueror
> Illegal icon group:  7
>  HTML :  "\n PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n   
> \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\
> ">\n\n xmlns=\"http://www.w3.org/1999/xhtml\
> ">\n\n\t HREF=\"file:/usr/share/konqueror/about/\">\n\n   name=\"generator\" content=\n  \"HTML Tidy for Linux/x86 (vers 1st
> August 2004), see www.w3.org \" />\n\n   type=\"text/css\">\n  /* \"file:///usr/share/kf5/infopage/kde_infopage.css\"; /*
> kde_infopage.css */\n /* maybe @import \"kde_infopage_rtl.css\";
> */\n    @import \"konq.css\";\n  /*]]>*/\n  \n\n  Be
> free.\n\n\n\n  \n     id=\"headerL\">\n    \n\n     id=\"title\">\n  Konqueror \n    \n\n   
> \n  Be free. \n    \n 
> \n\n  \n  \n     id=\"barT\"> id=\"barTC\">\n    \n   id=\"barR\">\n     class=\"bar_text\">\n  Konqueror is a web browser, file
> manager and universal document viewer.\n  \n  \n     class=\"selected\">Starting
> Points\n     href=\"about:konqueror/intro\">Introduction\n     href=\"about:konqueror/tips\">Tips\n   
> Specifications\n  \n    \n  \n   
> \n     id=\"barBR\">\n  \n\n 
> \n   id=\"boxTL\"> id=\"boxTC\">\n    \n   id=\"boxR\">\n    \n\t align=\"center\">\n\t  \n\t  \n\t\t href=\"file:///home/osama\"> src=\"file:///usr/share/icons/Adwaita/48x48/places/user-home.png\"
> height=\"48\" width=\"48\" />\n\t\t\n\t   valign=\"bottom\" style=\"padding-bottom: 4px; padding-left:
> 6px;\">\n\t\t  Home
> FolderYour personal
> files\n\t\t\n     
> nowrap>\n\t\t\n\t\t  
>  
>  src=\"file:///usr/share/icons/Adwaita/48x48/status/user-trash-full.png\"
> height=\"48\" width=\"48\" />\n\t\t\n\t   valign=\"bottom\" style=\"padding-bottom: 4px; padding-left:
> 6px;\">\n\t\t    Trash id=\"subtext\">Browse and restore the trash\n\t\t 
> \n  \n   height=\".25em\">\n\t  \n\t\t\n\t\t   href=\"remote:/\"> src=\"file:///usr/share/icons/Adwaita/48x48/places/folder-remote.png\"
> height=\"48\" width=\"48\" />\n\t\t\n\t   valign=\"bottom\" style=\"padding-bottom: 4px; padding-left:
> 6px;\">\n\t\t  Network Folders id=\"subtext\">Shared files and folders\n\t\t 
> \n    \n\t\t   
> \n\t\t   width=\"48\" />\n    \n\t   valign=\"bottom\" style=\"padding-bottom: 4px; padding-left:
> 6px;\">\n\t\t   Bookmarks id=\"subtext\">Quick access to your
> bookmarks\n\t\t  \n\t\t\n   colspan=\"5\" height=\".25em\">\n\t\t   
> \n\t\t     href=\"about:konqueror/intro\"> src=\"file:///usr/share/icons/Adwaita/16x16/actions/go-next.png\"
> width=\"16\" height=\"16\">Next: An Introduction to
> Konqueror\n\t\t\t\n\n    \n 
> \n    \n     id=\"boxBL\"> id=\"boxBC\">\n  \n\n   id=\"footerL\"> id=\"footerR\">\n\n\n\n"
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: Should no longer be called
> QPainter::begin: Paint device returned engine == 0, type: 1
> QPainter::translate: Painter not active
> QPainter::setClipRect: Painter not active
> QWidget::paintEngine: Should no longer be called
> QWidget::paintEngine: 

Bug#927879: ca-certificates should not hardcode QuoVadis certificate authorities in /etc/ca-certificates.conf

[Kurt Roeckx]

On Wed, Apr 24, 2019 at 06:22:04PM -0400, Soppy bear wrote:
> omg... i cant believe u just closed that ticket... :u
> 
> pls let me explain.
> 
> 1. This is a Debian problem because the end user should be able to use TLS 
> without having
> to import/use certificates without any practical use for normal operations. 

I'm not sure what you mean with the "without any practical use for
normal operations".

There is no way to use TLS without having a list of trusted
certificates. Without that list, you should not be able to
make a single secure connection, or the software is broken.

So far "normal use", we install the list as provided
by Mozilla as the default. 


Kurt

Bug#927940: [Windows Subsystem for Linux] Applications cannot find libQt5Core.so.5

[Bernhard Übelacker]

Control: retitle 927940 [Windows Subsystem for Linux] Applications cannot find 
libQt5Core.so.5


Hello Ryo,

> I encountered this problem with my WSL environment.Not quite the usual kernel 
> ... ;-)

A google search leads to this information [1]
and this bug [2].

There a workaround is provided by stripping
the section .note.ABI-tag from the file.

Kind regards,
Bernhard

[1] 
https://superuser.com/questions/1347723/arch-on-wsl-libqt5core-so-5-not-found-despite-being-installed
[2] https://github.com/Microsoft/WSL/issues/3023

Bug#927970: lintian: false positives for missing-systemd-timer-for-cron-script?

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.12.0
Severity: normal

Hello,
on last Monday (April, the 22nd) I rebuilt my package (apt-listbugs)
inside a pbuilder-managed sid chroot environment and checked the
result with lintian/2.12.0 (that was the version available from sid
on that day: however, it seems to me that nothing relevant has
changed in version 2.13.0).

I got a new complaint from "lintian -EviIL +pedantic" :
missing-systemd-timer-for-cron-script

Well, nothing to say, that's true: apt-listbugs currently lacks
any systemd timer, but ships a cron.daily script.

Hence, I began doing some research on the proper way to ship a
systemd timer along with an equivalent cron script (while avoiding
conflicts between the two).
I looked for examples in other packages which seem to have already
done this. I think two examples could be man-db and logrotate,
is that correct?

  $ dpkg -L man-db | grep 'cron\|systemd\/system\/[^\/]\+\.timer'
  /etc/cron.daily
  /etc/cron.daily/man-db
  /etc/cron.weekly
  /etc/cron.weekly/man-db
  /lib/systemd/system/man-db.timer
  $ dpkg -L logrotate | grep 'cron\|systemd\/system\/[^\/]\+\.timer'
  /etc/cron.daily
  /etc/cron.daily/logrotate
  /lib/systemd/system/logrotate.timer

I even looked inside these files, and it seems to me that the systemd
timer is really equivalent to the cron script (in both cases).

But, to my great surprise, I see that lintian [complains] [about] those
two packages, as well!

[complains]: 

[about]: 


Are these false positives?

I took a look at the [code] that implements the check.

[code]: 

I have a question: is the following line

return if any { m,^/lib/systemd/system/\.timer$, } $info->sorted_index;

missing something in the regexp?
Should it be

return if any { m,^/lib/systemd/system/[^\/]+\.timer$, } 
$info->sorted_index;

or anyway something able to catch some characters between
"system/" and ".timer" ?

I am not sure this is the cause of the false positives, though.

Of course, I can well be completely off-track, so please bear with me!

Please clarify.
Thanks for your time!




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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-16
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.6
ii  dpkg-dev   1.19.6
ii  file   1:5.35-4
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcapture-tiny-perl   0.48-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.6
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libpath-tiny-perl  0.108-1
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  libtry-tiny-perl   0.30-1
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-2
ii  patchutils 0.3.4-2
ii  perl   5.28.1-6
ii  t1utils1.41-3
ii  xz-utils   5.2.4-1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#927968: xmount: better description

[Xavier Brochard]

Package: xmount
Severity: wishlist

Dear Maintainer,

I suggest to change a bit the package description putting the last sentence at 
first :
from
xmount allows you to convert on-the-fly ...
to
xmount allows to boot acquired harddisk images using QEMU, KVM, VirtualBox, 
VMware or alike. It will convert on-the-fly ...

That will help to quickly understand purpose of this software.

Regards
Xavier

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

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

Versions of packages xmount depends on:
pn  libafflib0v5  
ii  libc6 2.28-8
pn  libewf2   
ii  libfuse2  2.9.9-1
ii  zlib1g1:1.2.11.dfsg-1

xmount recommends no packages.

xmount suggests no packages.

Bug#927967: ITP: nim-unicodedb -- unicode support for nim

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: nim-unicodedb
  Version : 0.6.0
* URL : https://github.com/nitely/nim-unicodedb
* License : MIT
  Programming Lang: nim
  Description : unicode support for nim

The package is to be team-maintained on 
https://salsa.debian.org/nim-team/nim-unicodedb

Bug#927852: Info received (Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470))

[Michel Dänzer]

On 2019-04-25 5:06 p.m., - wrote:
> 
> So what would be your suggestion on how to proceed? Are there any
> promising paths I could follow to narrow down the issues?

You should probably file a separate report against the chromium package
about the chromium crash.


-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#927954: konqueror: Exit when opening http https' ftps' links

[Bernhard Übelacker]

Hello Osama Nasr,
I tried to reproduce this issue in a minimal Unstable VM
with plasma-desktop and konqueror installed.
But could not reproduce it.

Could you try to start it from a konsole and forward
the output you get there after you hit this bug?

And have you configured something non-default in
  systemsettings - applications - Web Browser

Does it happen if you create a new user and login there too?

Kind regards,
Bernhard

Bug#926547: insserv: tests/run-tests are not used

[Jesse Smith]

Thanks for the ping, I did not see this one come in for some reason.

I have added the testsuite to the Makefile's "check" target and
addressed the unset variable issue.

Going through the tests, figuring out which ones are failing and why
will take a little longer. Or, for that matter, there may be cases where
failing is a good thing as some of the tests seem to be dealing with
situations where the data is problematic and we need to bomb out. I'll
check.

- Jesse

Bug#927852: Info received (Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470))

[-]

> > 
> > I installed auditd and added the following rule:
> > 
> > -a always,exit -F arch=b64 -S kill
> > 
> > Now there are more detailed log entries in journalctl.
> > Do they help to narrow down who is terminating the processes? I am
> > not
> > able to interpret them, therefore I am asking.
> 
> Looks like that was a red herring, in the form of GDM terminating its
> own GNOME session for the login screen while another VT is active.
> 

So what would be your suggestion on how to proceed? Are there any
promising paths I could follow to narrow down the issues? Or is there
anything interesting/critical errors in the log files I have posted
which could help?

best regards

Christian Höffer 

Bug#927961: strongswan Apparmor profiles are missing the setpcap capability

[Simon Deziel]

On 2019-04-25 9:41 a.m., Simon Deziel wrote:
> I'll soon be proposing a fix via salsa.

https://salsa.debian.org/debian/strongswan/merge_requests/4



signature.asc
Description: OpenPGP digital signature

Bug#927966: kdiff3: Outdated Homepage: field in debian/control

[Alberto Luaces]

Package: kdiff3
Version: 1.7.90-3
Severity: minor

Dear Maintainer,

the Homepage field in d/control is outdated, pointing to the
sourceforge respository which got stalled at version 0.9.98
(2014-07-04).

In the same spirit as the current update of d/copyright for the same
reason, I think it would be sensible to also set that field to
https://kde.org/applications/development/kdiff3 .

Bug#927852: Info received (Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470))

[Michel Dänzer]

On 2019-04-25 1:26 p.m., - wrote:
>>
>> Signal 15 is SIGTERM, so this looks like something terminates a lot
>> (most / all?) of processes in your session. Maybe Xwayland is another
>> victim of that. There is no evidence here of anything going wrong in
>> Xwayland itself.
>>
> 
> I installed auditd and added the following rule:
> 
> -a always,exit -F arch=b64 -S kill
> 
> Now there are more detailed log entries in journalctl.
> Do they help to narrow down who is terminating the processes? I am not
> able to interpret them, therefore I am asking.

Looks like that was a red herring, in the form of GDM terminating its
own GNOME session for the login screen while another VT is active.


-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#927938: openscap: Can't parse recent Debian OVAL files

[Kevin Tanguy]

Additional information:

The definition file for stretch still somehow works with oscap oval eval 
--skip-valid
However openscap versions for wheezy and jessie cannot handle the new 
definition files format at all, on jessie:


/usr/bin/oscap oval eval --skip-valid --results 
"/tmp/oval-definitions-jessie.result.xml" 
"/tmp/oval-definitions-jessie.xml"  2>&1 | grep -c error

1545

And that type of trace too:
Invalid type of operation in string evaluation: 8. 
[../../../../src/OVAL/results/oval_cmp_basic.c:194]


Would not it make sense to generate oval files with schema matching the 
distribution openscap version?

Bug#927955: [Debichem-devel] Bug#927955: python-rdkit: missing module pyAvalonTools

[merkys]

On 2019-04-25 15:36, fc wrote:
> there should be a module pyAvalonTools in module Avalon,
> as it is imported also at several places in the module itself.

This should be fixed by adding '-DRDK_BUILD_AVALON_SUPPORT=ON' to
'override_dh_auto_configure' in debian/rules. I tried it myself, but
couldn't build the package from what is now on Salsa due to missing
'upstream/201809.1+dfsg' GIT tag and inapplicable patches - could
someone familiar give it a look?

Best,
Andrius

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

Bug#927940: libqt5core5a: Applications rely on libQt5Core.so.5 cannot find libQt5Core.so.5

[Bernhard Übelacker]

Hello Ryo IGARASHI,
I just trying to triage this bug, and have in a minimal
Buster amd64 VM installed just paraview installed and
could not reproduce the issue.

Could you please check the output in your system for any
differences to the outputs below:

dpkg -l | grep -E "paraview|libqt5core5a"
md5sum /usr/lib/x86_64-linux-gnu/libQt5Core.so.5* 
/usr/lib/paraview/paraview 
env | grep -E "^LD"

If they are equal, maybe the output of following call
could give a hint?

LD_DEBUG=libs ldd /usr/lib/paraview/paraview
LD_DEBUG=files ldd /usr/lib/paraview/paraview

Kind regards,
Bernahrd


PS.: I received following in my VM:

root@debian:~# dpkg -l | grep -E "paraview|libqt5core5a"
ii  libqt5core5a:amd64   5.11.3+dfsg1-1   amd64 
   Qt 5 core module
ii  paraview 5.4.1+dfsg4-3.1+b2   amd64 
   Parallel Visualization Application
ii  paraview-doc 5.4.1+dfsg4-3.1  all   
   Parallel Visualization Application. Comprehensive documentation
ii  paraview-python  5.4.1+dfsg4-3.1+b2   amd64 
   Parallel Visualization Application. python-support

root@debian:~# md5sum /usr/lib/x86_64-linux-gnu/libQt5Core.so.5* 
/usr/lib/paraview/paraview   
4acffc4ba6ef46508773294c59849734  /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
4acffc4ba6ef46508773294c59849734  
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11
4acffc4ba6ef46508773294c59849734  
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3
bd7619e0e0a906543e62ec737aa7ba10  /usr/lib/paraview/paraview

root@debian:~# env | grep -E "^LD"
root@debian:~#

Bug#926717: linux-image-4.19.0-4-amd64: Size of DVD in external drive not recognised properly

[Jan]

Short addendum after additional tests:

Apr 9, 2019, 5:00 PM by bug-repor...@tuta.io:

> Connecting the LG drive to the laptop (direct connection, no hubs
> involved) and inserting a DVD will report that DVD's total size to
> be about 1GiB.
>
This applies only to *video* DVDs, no matter whether they are tainted by DRM or 
not. Data DVDs work without problems so far.


> The LG drive works well so far for CDs. But if I insert a CD first, use it
> and replace it with a DVD, the output of 'blockdev' still shows the
> values it had for the CD and the “available size” of the DVD is limited to
> that of the CD.
>
Here as well, replace “CD” with “data DVD”. That means after inserting 
(mounting or reading is irrelevant), Video DVDs also work if the previously 
inserted DVD was as large or larger. While this provides some workaround that 
original problem persists.

I'm at a loss of ideas what the trigger could be. AFAIK video DVD *are* 
ordinary data DVDs with some predefined file layout.


Regards, Jan

Bug#910696: openjdk-11-jdk-headless:x32: broken-symlink /usr/lib/jvm/java-11-openjdk-x32/src.zip (and one more)

[Thorsten Glaser]

Package: openjdk-11-jdk-headless
Version: 11.0.3+7-2
Followup-For: Bug #910696

openjdk-11-jdk-headless:x32: broken-symlink 
/usr/lib/jvm/java-11-openjdk-x32/src.zip -> ../openjdk-11/src.zip

tglase@tglase:~ $ ll /usr/lib/jvm/java-11-openjdk-x32/src.zip
lrwxrwxrwx 1 root root 21 Apr 18 04:54 /usr/lib/jvm/java-11-openjdk-x32/src.zip 
-> ../openjdk-11/src.zip
tglase@tglase:~ $ ll /usr/lib/jvm/openjdk-11/
total 4
drwxr-xr-x 2 root root 4096 Apr 25 16:15 lib/
tglase@tglase:~ $ ll /usr/lib/jvm/openjdk-11/lib/
total 56492
-rw-r--r-- 1 root root 57847800 Apr 18 04:54 src.zip

So this is missing the /lib/ subdirectory.


Furthermore:

openjdk-11-jre-headless:x32: broken-symlink 
/usr/lib/debug/usr/lib/jvm/java-1.11.0-openjdk-x32 -> java-11-openjdk-x32

tglase@tglase:~ $ ll /usr/lib/debug/usr/lib/jvm
total 0
lrwxrwxrwx 1 root root 19 Apr 18 04:54 java-1.11.0-openjdk-x32 -> 
java-11-openjdk-x32

So this is, unfortunately, true. (Perhaps the symlink must be moved to the
package that actually ships the debug info?)


-- System Information:
Debian Release: 10.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages openjdk-11-jdk-headless depends on:
ii  libc62.28-8
ii  openjdk-11-jre-headless  11.0.3+7-2
ii  zlib1g   1:1.2.11.dfsg-1

openjdk-11-jdk-headless recommends no packages.

Versions of packages openjdk-11-jdk-headless suggests:
pn  openjdk-11-demo
ii  openjdk-11-source  11.0.3+7-2

-- no debconf information

Bug#927300: /etc/mime.types should know about .mjs extension for JavaScript modules

[Basile Starynkevitch]

On 4/25/19 3:35 PM, Charles Plessy wrote:

Le Wed, Apr 17, 2019 at 05:53:18PM +0200, Basile Starynkevitch a écrit :

Most recent web browsers support JavaScript modules (their file extension is 
usually .mjs). See 
https://developers.google.com/web/fundamentals/primers/modules
The conventional MIME type should be text/javascript for .mjs files.

Hi Basile,

the IANA website lists text/javascript as obsolete, and points to
RFC4329, which does not refer to the mjs file extension (obviously since
it is from 2006).

Would it be possible that you, Google, or somebody else sorts this out
with the IANA ?

In any case, we have time sinze Debian is frozen :)



Sorry. I am not that motivated. Contacting Google or IANA or an RFC 
author is well beyond what I could accept to do. I know nobody there.


I am just observing that without such a trivial patch to 
/etc/mimes.type, my bismon  
software does not work. And my understanding so far is that the bug is 
not mine.


And the mjs extension is mentioned in 
https://developers.google.com/web/fundamentals/primers/modules and that 
is /exactly/ the reason I am using it.


If you know some more authoritative source about MIME types or file 
extensions of JavaScript modules (as seen from a browser) please share 
it with me.


*Regarding web technologies in general, I am really a newbie.* My 
expertise is elsewhere (persistent systems, static source code analysis, 
compilation - I did contribute to GCC in the past, related to  its 
plugin infrastructure). Since I will be retired in 3 or 4 years, I won't 
even have time to become professionally an expert in web technologies.


I am surprised by your analysis. AFAIK, the mjs extension is unusual 
(since quite new, and was not used for other usages before). You 
practically won't break things by putting it in /etc/mime.types, because 
that extension is rarely used. I am sure that in 2019 there are lots of 
extensions still figuring in /etc/mime.types which do not matter anymore 
(because they are related to obsolete or rarely used software, e.g. uls 
- in my understanding it is MicroSoft specific) in practice/. /However, 
that .mjs extension and its mime type is understood by major /recent/ 
web browsers (e.g. both Chrome & FireFox).


Or are you suggesting that both Chrome and FireFox are buggy, because 
they accept wrongly (and work well in practice) JavaScript /modules/ 
with .mjs associated to text/javascript (and that works /as documented/ 
here ). 
Do you suggest me to open a bug on FireFox? Maybe it is one, but as I am 
explaining, I am a web technology newbie, and I am just relating you my 
very limited experience.


Regards

--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France

Bug#923478: [Pkg-shadow-devel] Bug#923478: initscripts use unsafe `: >` shell command to create files

[Dmitry Bogatov]

[2019-04-22 09:18] "Serge E. Hallyn" 
> > [ Dmitry Bogatov ]
> > Dear login maintainers, currently we have following core executed during
> > boot:
> > 
> > # Create /var/run/utmp so we can login.
> > true > /var/run/utmp
> > if grep -q ^utmp: /etc/group
> > then
> > chmod 664 /var/run/utmp
> > chgrp utmp /var/run/utmp
> > fi
> > 
> > It seems that system boots and works just fine without it. Are there any
> > subtle reasons to keep creating /var/run/utmp in initscripts?
>
> Is the above pseudocode?  If not, where is that code precisely?

It is from /etc/init.d/bootmisc.sh from initscripts=2.94-3, lines 28-34.

> Near as I can tell, if you do not create it, it will never exist,
> and pututent entries will not be saved.

According my experiments, it will. Even if I remove this code, something
(login/getty, maybe?) still creates /var/run/utmp, root:root.

Thus I am asking your advice, whether it is safe to not create
/var/run/utmp in initscripts.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#926547: insserv: tests/run-tests are not used

[Dmitry Bogatov]

[2019-04-06 19:14] Dmitry Bogatov 
> Package: insserv
> Version: 1.18.0-2
> Severity: normal
>
> Dear upstream maintainer,
>
> during preparation of debian package of insserv=1.19.0 I discovered
> issue with test suite (tests/run-tests), which was imported from
> `debian/run-tests'.
> [...]

Friendly ping, Jesse. There is no urgency, but uploading insserv=1.19.0
requires getting it fixed.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

[Dmitry Bogatov]

[2019-04-22 19:07] Alessandro Vesely 
> > On Mon 22/Apr/2019 11:55:55 +0200 Dmitry Bogatov wrote:
> > I agree, better not to break things if we don't need to, but introducing
> > complexity to support broken setup?
> I thought that script was way less complex than insserv...

Hm, seems I was prejudced. Sorry. Probably `insserv` really could be
simplified by replacing with high-level language implementation; but it
is not for me to decide.

Probably you want to propose such change to insserv's upstream.  He is
subscribed to this list, I believe, but you may wish to report it
separately.

History knows precendends: TexInfo >= 5.0 was succesfully reimplemented
in Perl instead of C.

> > Cycled dependencies or otherwise incoherent dependencies is broken
> > setup.  Fix it. We already discussed how to fix it. Asking to support it
> > is like asking to support  situation, when dependency of your package is
> > removed by `dpkg -r'.
>
> Let me just note, in passing, that you're assuming any script belongs to
> some package.  What if a simple-minded user wants to write "Hello world"
> on every boot?

Normally,

$ cat /etc/rc.local
#!/bin/sh
echo "Hello world"

but also you can modify any script in /etc/init.d/, so you will get your
"Hello world" text printed at any moment of boot process. Modifications
will be preserved between upgrades, and you will even have option to
merge your changes and Debian ones.

> Similarly, LSB defines installation of scripts, and casually mentions rc
> as an example implementation.  Given that the implementation can
> actually host more than the specification assumes, why artificially
> limit it?

Not artificially, just keeping scope of program in check.

> I'd never complicate things in order to support unspecified martians.
> The point is building every time from scratch, rigidly enjoining specs,
> like it or lump it, versus an incremental, tolerant, minimal changes
> operation.

What is the point of "incremental, tolerant, minimal changes operation"?

C compiler always builds .o file from source file always afresh, and it
reduces its complexity, and insserv(8) can be seen as compiler from
content of /etc/init.d/, /etc/insserv/ and /etc/insserv.conf to
/etc/rc[0-6].d

The only possible reason to attempt reusing existing content of
/etc/rc[0-6].d is perfomance, and it does not apply.

I argue, that isserv(8) is compiler, not build tool like make(1), since
it is impossible to separate processing of any individual file from rest
of them: /etc/init.d/, /etc/insserv/ and /etc/insserv.conf together
are single input. It is possible to consider each /etc/rc[0-6].d as
separate output, but it is useless.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#927963: fails to detect updates in dhclient/libisc-export1100

[Antoine Beaupre]

Package: needrestart
Version: 3.4-3
Severity: normal

Hi,

I have found another problem where our tool detected a program needing
restart that needrestart didn't find. It's different from #927168 in
that it's not covered by any parent processes: in fact, needrestart is
totally silent on the box.

Here's the needrestart output:

# needrestart -v
[main] eval /etc/needrestart/needrestart.conf
[main] needrestart v3.4
[main] running in root mode
[Core] Using UI 'NeedRestart::UI::stdio'...
[main] systemd detected
[main] vm detected
[Core] #659 is a NeedRestart::Interp::Python
[Python] #659: source=/usr/share/unattended-upgrades/unattended-upgrade-shutdown
[Core] #3920 is a NeedRestart::Interp::Python
[Python] #3920: source=/usr/sbin/mandos
[Core] #3923 is a NeedRestart::Interp::Python
[Python] #3923: source=/usr/sbin/mandos
[Python] #3923: use cached file list
[main] inside container or vm, skipping microcode checks
[Kernel] Linux: kernel release 4.19.0-4-amd64, kernel version #1 SMP Debian 
4.19.28-2 (2019-03-15)
[Kernel/Linux] /boot/vmlinuz-4.19.0-4-amd64 => 4.19.0-4-amd64 
(debian-ker...@lists.debian.org) #1 SMP Debian 4.19.28-2 (2019-03-15) 
[4.19.0-4-amd64]*
[Kernel/Linux] Expected linux version: 4.19.0-4-amd64

Running kernel seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

And here's DSA's check libs:

# dsa-check-libs --verbose
Running /usr/bin/lsof -F0 -n
adding dhclient(976) because of 
[/lib/x86_64-linux-gnu/libisc-export.so.1100.0.0]:
fDELa l tREGD0xfe00i917519n/lib/x86_64-linux-gnu/libisc-export.so.1100.0.0
adding dhclient(976) because of 
[/lib/x86_64-linux-gnu/libdns-export.so.1104.0.2]:
fDELa l tREGD0xfe00i917788n/lib/x86_64-linux-gnu/libdns-export.so.1104.0.2
The following processes have libs linked that were upgraded: root: dhclient 
(976)

Again, the source for that script is here:

https://salsa.debian.org/dsa-team/mirror/dsa-nagios/blob/master/dsa-nagios-checks/checks/dsa-check-libs

Those maps are executable:

# cat /proc/976/maps | grep -i libisc
7f92aa93f000-7f92aa951000 r--p  fe:00 917519 
/lib/x86_64-linux-gnu/libisc-export.so.1100.0.0 (deleted)
7f92aa951000-7f92aa993000 r-xp 00012000 fe:00 917519 
/lib/x86_64-linux-gnu/libisc-export.so.1100.0.0 (deleted)
7f92aa993000-7f92aa9ab000 r--p 00054000 fe:00 917519 
/lib/x86_64-linux-gnu/libisc-export.so.1100.0.0 (deleted)
7f92aa9ab000-7f92aa9ac000 ---p 0006c000 fe:00 917519 
/lib/x86_64-linux-gnu/libisc-export.so.1100.0.0 (deleted)
7f92aa9ac000-7f92aa9ae000 r--p 0006c000 fe:00 917519 
/lib/x86_64-linux-gnu/libisc-export.so.1100.0.0 (deleted)
7f92aa9ae000-7f92aa9af000 rw-p 0006e000 fe:00 917519 
/lib/x86_64-linux-gnu/libisc-export.so.1100.0.0 (deleted)

... so I believe the program should be marked as needing
restart. Naturally, it might not be safe to do so, but it should at
least warn. The program is part of the ifup@eth0.service:

   CGroup: /system.slice/ifup@eth0.service
   └─976 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf 
/var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases 
eth0

In my tests, "systemctl restart ifup@eth0.service" safely returned,
when running under "screen".

Bug#927964: Enable git buildpackage to pass jobserver file-descriptors to builder

[Kristofer Hansson]

Package: git-buildpackage
Version: 0.9.14
Severity: wishlist
Tags: patch

GNU make, since version 4.2
https://lists.gnu.org/archive/html/info-gnu/2016-05/msg00013.html,
officially supports the file descriptors of the jobserver to subporcess,
but gbp will close those file-descriptors since it uses the default
settings of the subprocess module (which is to close all file descriptors
except standard-in, -out, and -error).

I created a patch that in buildpackages looks for the
'--jobserver-auth=,' flag in the environment variable $MAKEFLAGS, if
that exists it sets those file descriptors as bein passed to the subprocess
module. Below is the patch generated.

The reason this is useful is because it enables multiple gbp jobs that are
spawned from make to run in parallel and share a job-server. Note that this
patch in itself will not enable this since the builder needs to support it
as well.

diff -Nru git-buildpackage-0.9.14/debian/changelog
git-buildpackage-0.9.14+nmu1/debian/changelog
--- git-buildpackage-0.9.14/debian/changelog2019-03-21
09:33:34.0 +
+++ git-buildpackage-0.9.14+nmu1/debian/changelog   2019-04-25
10:25:15.0 +
@@ -1,3 +1,11 @@
+git-buildpackage (0.9.14+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Made gbp buildpackage able to pass file-descriptors of an existing
+GNU Make job-server.
+
+ -- Kristofer Hansson   Thu, 25 Apr 2019
10:25:15 +
+
 git-buildpackage (0.9.14) unstable; urgency=medium

   [ Michael Prokop ]
diff -Nru git-buildpackage-0.9.14/gbp/command_wrappers.py
git-buildpackage-0.9.14+nmu1/gbp/command_wrappers.py
--- git-buildpackage-0.9.14/gbp/command_wrappers.py 2019-01-08
19:15:13.0 +
+++ git-buildpackage-0.9.14+nmu1/gbp/command_wrappers.py2019-04-25
10:25:15.0 +
@@ -75,7 +75,7 @@

 If cmd doesn't contain a path component it will be looked up in $PATH.
 """
-def __init__(self, cmd, args=[], shell=False, extra_env=None, cwd=None,
+def __init__(self, cmd, args=[], shell=False, extra_env=None,
cwd=None, pass_fds=(),
  capture_stderr=False,
  capture_stdout=False):
 self.cmd = cmd
@@ -86,6 +86,7 @@
 self.capture_stdout = capture_stdout
 self.capture_stderr = capture_stderr
 self.cwd = cwd
+self.pass_fds = pass_fds
 if extra_env is not None:
 self.env = os.environ.copy()
 self.env.update(extra_env)
@@ -145,7 +146,8 @@
  env=self.env,
  preexec_fn=default_sigpipe,
  stdout=stdout_arg,
- stderr=stderr_arg)
+ stderr=stderr_arg,
+ pass_fds=self.pass_fds)
 (self.stdout, self.stderr) = popen.communicate()
 if self.stdout is not None:
 self.stdout = self.stdout.decode()
diff -Nru git-buildpackage-0.9.14/gbp/scripts/buildpackage.py
git-buildpackage-0.9.14+nmu1/gbp/scripts/buildpackage.py
--- git-buildpackage-0.9.14/gbp/scripts/buildpackage.py 2019-01-08
19:15:13.0 +
+++ git-buildpackage-0.9.14+nmu1/gbp/scripts/buildpackage.py2019-04-25
10:25:15.0 +
@@ -335,6 +335,20 @@
 return branch


+def get_job_fds_from_env():
+makeflags = None
+try:
+makeflags = os.environ['MAKEFLAGS']
+except KeyError:
+return ()
+
+for flag in makeflags.split(' '):
+if flag.startswith('--jobserver-auth='):
+return tuple(flag.split('=')[1].split(','))
+else:
+return ()
+
+
 def build_parser(name, prefix=None):
 try:
 parser = GbpOptionParserDebian(command=os.path.basename(name),
prefix=prefix)
@@ -510,6 +524,7 @@
 export_dir = os.path.join(output_dir, "%s-%s" %
(source.sourcepkg, major))
 build_dir = export_dir if options.export_dir else repo.path
 changes_file = changes_file_name(source, build_dir,
options.builder, dpkg_args)
+job_fds = get_job_fds_from_env()

 # Run preexport hook
 if options.export_dir and options.preexport:
@@ -563,6 +578,7 @@
 RunAtCommand(options.builder,
  [pipes.quote(arg) for arg in dpkg_args],
  shell=True,
+ pass_fds=job_fds,
  extra_env=Hook.md(build_env,
{'GBP_BUILD_DIR': build_dir})
  )(dir=build_dir)

Bug#927962: bind9: re-enable eddsa once openssl 1.1.1 is default

[Andreas Hasenack]

Package: bind9
Version: 1:9.11.5.P4+dfsg-3
Severity: Normal

Dear Maintainer,

please re-enable eddsa support once openssl 1.1.1 is the default. It
was temporarily disabled in
https://salsa.debian.org/dns-team/bind9/commit/94c7cd6f039b971e9cd9f0cde0a1ec17774aa6f8

Bug#903393: [initramfs-tools] update-initramfs -u warns: Unknown X keysym "dead_belowmacron"

[at46]

Seems the warnings are gone. Neither with update-initramfs nor with 
setupcon I get the "WARNING: Unknown X keysym "dead_belowmacron"" 
messages anymore.


Axel

Bug#927961: strongswan Apparmor profiles are missing the setpcap capability

[Simon Deziel]

Package: strongswan
Version: 5.7.1-1

Hello,

A user on Ubuntu reported [1] that Strongswan 5.7.1-1 no longer worked
with privilege downgrade. He also traced the root cause to a missing
capability: CAP_SETPCAP.

I'll soon be proposing a fix via salsa.

Thanks,
Simon

1: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1826238



signature.asc
Description: OpenPGP digital signature

Bug#927960: flameshot: Flameshot does not integrate with latest gnome system tray

[Svjatoslav Agejenko]

Package: flameshot
Version: 0.6.0-11
Severity: important

Dear Maintainer,

When installed in Debian Buster with Gnome desktop environment,
system tray icon does not work out of the box for Gnome desktop environment.
That is, no icon is displayed.

At times I got it working by installing various unofficial compatibility Gnome
system tray
extensions/solutions.

I suspect that Gnome API for system tray is changed and Flameshot is still
using the old API.





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

Kernel: Linux 5.0.8-xanmod5 (SMP w/4 CPU cores; PREEMPT)
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.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 flameshot depends on:
ii  libc6   2.28-8
ii  libgcc1 1:8.3.0-6
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5dbus5 5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5network5  5.11.3+dfsg1-1
ii  libqt5svg5  5.11.3-2
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libstdc++6  8.3.0-6

flameshot recommends no packages.

Versions of packages flameshot suggests:
ii  ca-certificates  20190110
ii  openssl  1.1.1b-2

-- no debconf information

Bug#927956: systemd-sysv: /var/run/postgresql is owned by root - postgres does not start after a reboot

[Dominic Mason]

Package: systemd-sysv
Followup-For: Bug #927956

Dear Maintainer,


This appears to have been fixed in 215-17+deb8u13 of the following packages

Get:1 http://security.debian.org/ jessie/updates/main libudev1 amd64
215-17+deb8u13 [58.8 kB]
Get:2 http://security.debian.org/ jessie/updates/main udev amd64 215-17+deb8u13
[878 kB]
Get:3 http://security.debian.org/ jessie/updates/main libsystemd0 amd64
215-17+deb8u13 [90.5 kB]
Get:4 http://security.debian.org/ jessie/updates/main libpam-systemd amd64
215-17+deb8u13 [127 kB]
Get:5 http://security.debian.org/ jessie/updates/main systemd amd64
215-17+deb8u13 [2,555 kB]
Get:6 http://security.debian.org/ jessie/updates/main systemd-sysv amd64
215-17+deb8u13 [37.5 kB]
Get:7 http://security.debian.org/ jessie/updates/main libgudev-1.0-0 amd64
215-17+deb8u13 [43.5 kB]


Obviously, people that have not updated those package and do a reboot, will
need to either fix the
permissions on /var/run/postgresql manually, or update those packages


NB in my previous post I suggested that running

sudo sh /usr/share/postgresql-common/init.d-functions

would fix the ownership of /var/run/postgresql

and that appears not to be the case, anyway. Sorry


Regards



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

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

Versions of packages systemd-sysv depends on:
ii  systemd  215-17+deb8u13

systemd-sysv recommends no packages.

systemd-sysv suggests no packages.

-- no debconf information

Bug#927300: /etc/mime.types should know about .mjs extension for JavaScript modules

[Charles Plessy]

Le Wed, Apr 17, 2019 at 05:53:18PM +0200, Basile Starynkevitch a écrit :
> 
> Most recent web browsers support JavaScript modules (their file extension is 
> usually .mjs). See 
> https://developers.google.com/web/fundamentals/primers/modules
> The conventional MIME type should be text/javascript for .mjs files.

Hi Basile,

the IANA website lists text/javascript as obsolete, and points to
RFC4329, which does not refer to the mjs file extension (obviously since
it is from 2006).

Would it be possible that you, Google, or somebody else sorts this out
with the IANA ?

In any case, we have time sinze Debian is frozen :)

Have a nice day,

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

Bug#927959: unblock: node-fresh/0.2.0-2

[Xavier Guimard]

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

Please unblock package node-fresh

Hi all,

node-fresh is vulnerable to CVE-2017-16119 (#927715). Vulnerability is
due to Node.js regexp parsing DDOS. I imported and adapted upstream
patch to workaround this issue and enabled upstream tests in both build
and autopkgtest. Full changes:
  * Declare compliance with policy 4.3.0
  * Change section to javascript
  * Change priority to optional
  * Add upstream/metadata
  * Add patch to fix regexp ddos (Closes: #927715, CVE-2017-16119)
  * Fix and enable upstream test using pkg-js-tools
  * Fix VCS fields
  * Fix copyright format URL

Reverse dependencies:
 - node-serve-favicon
 - node-send -+
   +-> node-serve-static -+
 - node-express <-+

I enabled upstream test to verify that there is no regression and tested
build and tests of node-serve-static, node-send and node-express (using
additional needed modules). I plan to upload a new node-express in
experimental with tests enabled to see autopkgtest regression if any.

Cheers,
Xavier

unblock node-fresh/0.2.0-2
diff --git a/debian/changelog b/debian/changelog
index e827b8b..6a067b4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+node-fresh (0.2.0-2) unstable; urgency=medium
+
+  * Team upload
+  * Declare compliance with policy 4.3.0
+  * Change section to javascript
+  * Change priority to optional
+  * Add upstream/metadata
+  * Add patch to fix regexp ddos (Closes: #927715, CVE-2017-16119)
+  * Fix and enable upstream test using pkg-js-tools
+  * Fix VCS fields
+  * Fix copyright format URL
+
+ -- Xavier Guimard   Thu, 25 Apr 2019 12:23:28 +0200
+
 node-fresh (0.2.0-1) unstable; urgency=low
 
   * Initial release (Closes: #727797)
diff --git a/debian/control b/debian/control
index ebd5a5e..efddc65 100644
--- a/debian/control
+++ b/debian/control
@@ -1,16 +1,19 @@
 Source: node-fresh
-Section: web
-Priority: extra
+Section: javascript
+Priority: optional
 Maintainer: Debian Javascript Maintainers 

 Uploaders: Jérémy Lal 
+Testsuite: autopkgtest-pkg-nodejs
 Build-Depends:
  debhelper (>= 8.0.0)
  , dh-buildinfo
+ , mocha
  , nodejs
-Standards-Version: 3.9.4
+ , pkg-js-tools
+Standards-Version: 4.3.0
+Vcs-Browser: https://salsa.debian.org/js-team/node-fresh
+Vcs-Git: https://salsa.debian.org/js-team/node-fresh.git
 Homepage: https://github.com/visionmedia/node-fresh
-Vcs-Git: git://anonscm.debian.org/collab-maint/node-fresh.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/node-fresh.git
 
 Package: node-fresh
 Architecture: all
@@ -23,4 +26,3 @@ Description: Check client cache staleness using HTTP headers 
- Node.js module
  determine if the client requesting the resource has a stale or fresh cache.
  .
  Node.js is an event-based server-side javascript engine.
-
diff --git a/debian/copyright b/debian/copyright
index 0c7fd09..af7dcf0 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: fresh
 
 Files: *
@@ -25,4 +25,3 @@ License: Expat
  ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  SOFTWARE.
-
diff --git a/debian/patches/CVE-2017-16119.diff 
b/debian/patches/CVE-2017-16119.diff
new file mode 100644
index 000..6461542
--- /dev/null
+++ b/debian/patches/CVE-2017-16119.diff
@@ -0,0 +1,85 @@
+Description: Fix for CVE-2017-16119
+Author: Xavier Guimard 
+Origin: upstream, 
https://github.com/jshttp/fresh/commit/21a0f0c2a5f447e0d40bc16be0c23fa98a7b46ec
+Bug: https://www.npmjs.com/advisories/526
+Bug-Debian: https://bugs.debian.org/927715
+Forwarded: not-needed
+Last-Update: 2019-04-25
+
+--- a/index.js
 b/index.js
+@@ -36,11 +36,27 @@
+   // check for no-cache cache request directive
+   if (cc && cc.indexOf('no-cache') !== -1) return false;  
+ 
+-  // parse if-none-match
+-  if (noneMatch) noneMatch = noneMatch.split(/ *, */);
++  // parse if-none-match and etag
++  if (noneMatch && noneMatch !== '*') {
+ 
+-  // if-none-match
+-  if (noneMatch) etagMatches = ~noneMatch.indexOf(etag) || '*' == 
noneMatch[0];
++if (!etag) {
++  return false
++}
++
++var etagStale = true
++var matches = parseTokenList(noneMatch)
++for (var i = 0; i < matches.length; i++) {
++  var match = matches[i]
++  if (match === etag || match === 'W/' + etag || 'W/' + match === etag) {
++etagStale = false
++break
++  }
++}
++
++if (etagStale) {
++  return false
++}
++  }
+ 
+   // if-modified-since
+   if (modifiedSince) {
+@@ -50,4 +66,40 @@
+   }
+ 
+   return !! (etagMatches && notModified);
+-}
+\ No newline at end of file
++}
++
++/**
++ * Parse a HTTP token list.
++ *
++ * @param {string} str
++ * @private
++ */
++
++function 

Bug#927958: [pre-a] unblock: utf8proc/2.3.0-1

[Mo Zhou]

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

Please unblock package utf8proc

(explain the reason for the unblock here)

I'm astonished that the unicode (11.* -> 12.*) transition happend at
such a deep freeze stage. utf8proc is tightly coupled with the
unicode-data version, and the new unicode-data version incured FTBFS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927941

The simplest way to fix this bug is to bump utf8proc to 2.3.0

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

According to upstream NEWs/changelog
https://github.com/JuliaStrings/utf8proc/commit/eb39b060e7e518941a912e1f51bae1cc6316f547
And the commit history (97ef668 -> 454f601)
https://github.com/JuliaStrings/utf8proc/commits/master
The major change from 2.2.0 (testing) to 2.3.0 (not yet packaged)
is the support for unicode-data (= 12). There is no breaking change.
So I request an unblock for 2.3.0-1

unblock utf8proc/2.3.0-1

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

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

Bug#927957: bash uses 100% CPU when ssh is disconnected

[David Bremner]

Package: bash
Version: 4.4-5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm seeing symptoms on stretch that look a lot like a bug reported to
Red Hat [1].

A bash process that is no longer associated with a TTY, but looks like
it was once interactive, pegs the CPU at 100%. Since the server in
question is headless, that suggests pretty strongly an orphaned SSH
session.

Apparently this was fixed in bash snapshots in 2017 [2], although I'm
not sure how those relate to actual versions.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1589343
[2] 
http://git.savannah.gnu.org/cgit/bash.git/commit/lib/readline/search.c?id=8b6b8f6094f95c4282c84924d12ec411a64a1ca7


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

Kernel: Linux 4.19.0-0.bpo.2-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 bash depends on:
ii  base-files   9.9+deb9u8
ii  dash 0.5.8-2.4
ii  debianutils  4.8.1.1
ii  libc62.24-11+deb9u4
ii  libtinfo56.0+20161126-1+deb9u2

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
pn  bash-doc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlzBsWAACgkQ8gKXHaSn
nixg8wv/dEdaihGdUV0oSm1J/tDpbjR1aC5C8w+gtPG4YUvkKpNX6SeIo9tHT4dT
ZwzlslGVSwCbn3fNCLDsgODDD+tiOKHGTv2apMLei+SKyY5Tpm2+vF/UDkGO64SV
rAOtVChgMnxq+wH5MJYj0D/otXWl1IAPYrMvyiG9q4zhfQ54w7Z63/mI6Vsipmoj
n6G+TL5PnKtxIxj5N/wAst+SqGJgs4Tfh/KdsxE0YMUaCfQCFUrOgLvcZlNskNZW
44JynhGCb/Vhu9kcqdre6MPAcFTqnD6Q19WUQsZ1GnyBNSS6Ha6PVpIF3BV6II/h
Kbjuv0JBE1f5s2B+p+Y7foCrx/lBwb8YmevAl/FtT2cUHZprjOkzpC66ongjFP5M
7CigsCisn8+OJIkH67rfNqlV57x33dR1u8N0uqAc7DN779+37XozqZ27ZkjnlgIR
g8JhyIZ27OluYHgnQGxv/n4N6zOp3kSaTRRA/MwATkdS9L+CTosfaviUhPmnHyAS
sRGvDQv3
=fSpQ
-END PGP SIGNATURE-

Bug#927884: Update on GDBus error

[Francisco M Neto]

After running apt update this morning, the error 

"GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit -.mount is masked."

happened again. That makes me believe it is unrelated to this particular
bug, but I'm not sure where that is coming from.
-- 
[]'s,

Francisco M Neto

GPG: 4096R/D692FBF0


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

Bug#927397: u-boot: Very poor ethernet performance on A20 OLinuXino Lime2 Rev.G2

[Jonas Smedegaard]

It seems mainline u-boot bootstrao all lime2 devices equally, whereas 
Olimex fork of u-boot treats "newer than G and "newer than E" specially: 
https://github.com/OLIMEX/u-boot/commit/6c32a3c9d31432884751966fcb0f15b1fd930446

  * Realtek rev.C PHY (board rev.C) get no tweak (but see bug#845128)
  * Realtek rev.E PHY (board rev.G,G1,G2) get TX_DELAY=2
  * Micrel PHY (board rev.H,K) get TX_DELAY=4

...as pointed out on irc up until here: 
https://freenode.irclog.whitequark.org/linux-sunxi/2019-04-25#24483567


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature