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

[Adrian Immanuel Kiess]

Hello Bernhard,

I get dropped back to xdm or sddm when I try to login to gnome-session. 

Attached to this message is the .xsession-errors log file of my guest
user.

Xorg.log says nothing special.

The error now seems to be that gnome-session can't find the DISPLAY
variable or the DISPLAY variable does not get set for gnome-session.

As I wrote before, login to other window managers as amiwm do actually
work.

But as I wrote before, all GTK and GNOME applications have issues or
errors after login was created through a display manager on my machine.

I have had a look into alle config files in /etc/X11 and the only thing
could be an old config file in /etc/X11/Xsession.d.

Here is the whole login of /var/log/syslog:

Apr 27 06:09:29 g6 systemd[1]: Created slice User Slice of UID 10003.
Apr 27 06:09:29 g6 systemd[1]: Starting User Runtime Directory
/run/user/10003...
Apr 27 06:09:29 g6 NetworkManager[917]: ((src/settings/nm-settings-
connection.c:361)): assertion '' f
ailed
Apr 27 06:09:29 g6 NetworkManager[917]: ((src/settings/nm-settings-
connection.c:361)): assertion '' f
ailed
Apr 27 06:09:29 g6 NetworkManager[917]: ((src/settings/nm-settings-
connection.c:361)): assertion '' f
ailed
Apr 27 06:09:29 g6 systemd[1]: Started User Runtime Directory
/run/user/10003.
Apr 27 06:09:29 g6 systemd[1]: Starting User Manager for UID 10003...
Apr 27 06:09:29 g6 systemd[22703]: Listening on GnuPG cryptographic
agent (ssh-agent emulation).
Apr 27 06:09:29 g6 systemd[22703]: Starting D-Bus User Message Bus
Socket.
Apr 27 06:09:29 g6 systemd[22703]: Listening on GnuPG cryptographic
agent and passphrase cache (restricted).
Apr 27 06:09:29 g6 systemd[22703]: Listening on GnuPG cryptographic
agent and passphrase cache (access for web
 browsers).
Apr 27 06:09:29 g6 systemd[22703]: Reached target Timers.
Apr 27 06:09:29 g6 systemd[22703]: Listening on Sound System.
Apr 27 06:09:29 g6 systemd[22703]: Listening on GnuPG network
certificate management daemon.
Apr 27 06:09:29 g6 systemd[22703]: Listening on GnuPG cryptographic
agent and passphrase cache.
Apr 27 06:09:29 g6 systemd[22703]: Reached target Paths.
Apr 27 06:09:29 g6 systemd[22703]: Listening on D-Bus User Message Bus
Socket.
Apr 27 06:09:29 g6 systemd[22703]: Reached target Sockets.
Apr 27 06:09:29 g6 systemd[22703]: Reached target Basic System.
Apr 27 06:09:29 g6 systemd[22703]: Reached target Default.
Apr 27 06:09:29 g6 systemd[22703]: Startup finished in 128ms.
Apr 27 06:09:29 g6 systemd[1]: Started User Manager for UID 10003.
Apr 27 06:09:29 g6 NetworkManager[917]: ((src/settings/nm-settings-
connection.c:361)): assertion '' f
ailed
Apr 27 06:09:29 g6 systemd[1]: Started Session 494 of user guest.
Apr 27 06:09:29 g6 NetworkManager[917]: ((src/settings/nm-settings-
connection.c:361)): assertion '' f
ailed
Apr 27 06:09:29 g6 NetworkManager[917]: ((src/settings/nm-settings-
connection.c:361)): assertion '' f
ailed
Apr 27 06:09:29 g6 systemd[22703]: Started D-Bus User Message Bus.
Apr 27 06:09:29 g6 dbus-daemon[22725]: [session uid=10003 pid=22725]
Activating via systemd: service name='org
.a11y.Bus' unit='at-spi-dbus-bus.service' requested by ':1.7'
(uid=10003 pid=22780 comm="/usr/lib/gnome-sessio
n/gnome-session-check-acceler")
Apr 27 06:09:29 g6 systemd[22703]: Starting Accessibility services
bus...
Apr 27 06:09:29 g6 dbus-daemon[22725]: [session uid=10003 pid=22725]
Successfully activated service 'org.a11y.
Bus'
Apr 27 06:09:29 g6 systemd[22703]: Started Accessibility services bus.
Apr 27 06:09:29 g6 at-spi-bus-launcher[22788]: dbus-daemon[22793]:
Activating service name='org.a11y.atspi.Reg
istry' requested by ':1.0' (uid=10003 pid=22780 comm="/usr/lib/gnome-
session/gnome-session-check-acceler")
Apr 27 06:09:29 g6 at-spi-bus-launcher[22788]: dbus-daemon[22793]:
Successfully activated service 'org.a11y.at
spi.Registry'
Apr 27 06:09:29 g6 at-spi-bus-launcher[22788]: SpiRegistry daemon is
running with well-known name - org.a11y.a
tspi.Registry
Apr 27 06:09:29 g6 gnome-session-binary[22717]: Entering running state
Apr 27 06:09:30 g6 gnome-session[22717]: Unable to init server: Could
not connect: Connection refused
Apr 27 06:09:30 g6 gnome-session-f[22809]: Cannot open display:
Apr 27 06:09:30 g6 systemd[22703]: Stopping D-Bus User Message Bus...
Apr 27 06:09:30 g6 at-spi2-registr[22795]: Failed to send session
response The connection is closed
Apr 27 06:09:30 g6 systemd[22703]: at-spi-dbus-bus.service: Succeeded.
Apr 27 06:09:30 g6 systemd[22703]: dbus.service: Succeeded.
Apr 27 06:09:30 g6 systemd[22703]: Stopped D-Bus User Message Bus.
Apr 27 06:09:30 g6 systemd[22703]: Started D-Bus User Message Bus.
Apr 27 06:09:30 g6 NetworkManager[917]: ((src/settings/nm-settings-
connection.c:361)): assertion '' f
ailed

Thank you very much for your kind attention.

Yours sincerely,

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 >

Bug#928043: installation-reports: cryptsetup does not accept password on fresh install (testing)

[Cyril Brulebois]

Hi,

Evgeny Badin  (2019-04-26):
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> For several weeks or even months I've been unable to use Debian Testing after
> installation (I could only install Stable and upgrade to Testing manually).
> Installation goes fine (I use daily unofficial builds that include
> firmware, including buster_di_rc1+nonfree), I choose full disk encryption with
> LVM, after reboot I need to enter cryptsetup password, but it won't accept it,
> (even though I'm sure I enter the right one)

First guess: Are you trying to use GRUB's cryptodisks support?

Second guess: Keymap issues?


Guided partitioning with encrypted LVM reliably works in e.g. a French
environment; that's tested before every release.


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


signature.asc
Description: PGP signature

Bug#928056: dhcpcd5: Open security issues in dhcpcd5 prior to 7.2.1 affecting all versions found in Debian

[Timo Sigurdsson]

Package: dhcpcd5
Version: any
Severity: serious

Dear Maintainer,

upstream released a new version of dhcpcd5 fixing three security issues. All 
versions currently found in Debian (jessie, stretch, buster, sid) are 
vulnerable to at least two of these issues, according to the announcement on 
upstreams's mailinglist [1].

The fixed issues are (copied from upstream's announcement):
  *  auth: Use consttime_memequal to avoid latency attack consttime_memequal is 
supplied if libc does not support it
 dhcpcd >=6.2 <7.2.1 are vulnerable

  *  DHCP: Fix a potential 1 byte read overflow with DHO_OPTSOVERLOADED
 dhcpcd >=4 <7.2.1 are vulnerable

  *  DHCPv6: Fix a potential buffer overflow reading NA/TA addresses
 dhcpcd >=7 <7.2.1 are vulnerable


Upstream provides a patch series for version 7 which would be relevant for 
buster and sid [2]. In addition, version 6.10.6 was released with backported 
fixes for the first two issues [3][4]. These might be useful for backporting to 
stretch and wheezy as they ship versions 6.10.1 and 6.0.5.

Please consider applying/backporting those patches to the dhcpcd versions found 
in Debian. I have not checked the exploitability of these issues, so the 
severity might not be as serious. But I marked it serious anyway to make sure 
this issue doesn't fly under the radar.


Thanks and regards,

Timo

[1] https://roy.marples.name/archives/dhcpcd-discuss/0002415.html
[2] 
https://roy.marples.name/git/dhcpcd.git/patch/?id=23525884a346ed81c808c1ed90e3c56a8bf0cc68
[3] 
https://roy.marples.name/git/dhcpcd.git/patch/?id=3ad25d3b306c890df8a15250f5ded70764075aa8
[4] 
https://roy.marples.name/git/dhcpcd.git/patch/?id=b6605465e1ab8f9cb82bf6707c517505991f18a4

Bug#926979: munin: autopkgtest compatibility for systemd-only derivatives

[devel]

Hello Steve,


Am Fri, 12 Apr 2019 22:28:21 -0700
schrieb Steve Langasek :

> Package sysvinit-core is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> However the following packages replace it:
>   systemd-sysv
> 
> autopkgtest [20:35:15]: test master-sysvinit-cron: ---]
> master-sysvinit-cron FAIL non-zero exit status 100
> [...]
> 
>   
> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/m/munin/20190412_204534_b9ff8@/log.gz)
> 
> It seems to me this could be sidestepped by having the test declare a
> dependency on sysvinit-core instead of installing it as part of the test,
> and also using Restrictions: skip-not-installable.

Thank you for this suggestion!

After taking a quick look at my comments in the test scripts, I am afraid, that
the test dependency may not work without further changes:
 
https://salsa.debian.org/debian/munin/blob/debian/debian/tests/enable_sysvinit.inc#L8

I will take a closer look at this issue after the release of Buster.

Cheers,
Lars

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

[Michael Gilbert]

control: tag -1 moreinfo, unreproducible
control: severity -1 minor

On Thu, Apr 25, 2019 at 6:33 PM Salvo Tomaselli wrote:
> 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.

I am not able to reproduce either of these.  However I just created a
new Bookmark Directory.  Maybe it only affects directories created
before 74?

Best wishes,
Mike

Bug#927770: lios does not work properly on KDE

[gcab_dzan]

Thanks, Samuel, for the reply.
I am attaching the warning provided as soon as I launch Lios from KDE 
Applications, and what I get after trying to load an image, which appears as an 
icon on the left, but could not expand in the central pane, although I could 
launch the "recognize" by right clicking on it.

I am going to try the version you indicated, and will let you know.

> Il 23 aprile 2019 alle 10.36 Samuel Thibault  ha 
> scritto:
> 
> 
> Hello,
> 
> gcab_d...@libero.it, le mar. 23 avril 2019 01:10:38 +0200, a ecrit:
> > Launching it graphically, it pops an advise that cannot find the hunspell/ 
> > etc.
> > language pack which is instead installed.
> 
> I don't have the issue, could you send a picture of the advice?
> 
> > Launching it from terminal I get the warning reported in the attached. 
> 
> Most warnings should be harmless except
> 
> >   File "/usr/lib/python3/dist-packages/lios/main.py", line 1300, in 
> > ocr_selected_areas
> > progress_step = 1/len(self.imageview.get_selection_list());
> > ZeroDivisionError: division by zero
> 
> which is a no-go :)
> 
> Could you try the package from
> http://people.debian.org/~sthibault/tmp/buster-tmp/lios_2.7-3~0_all.deb
> ?
> 
> Samuel

Bug#927093: the netstat plugin fails with current versions of netstat

[devel]

Hello Marco,

thank you for your bug report!


Am Mon, 15 Apr 2019 04:26:28 +0200
schrieb Marco d'Itri :

> Package: munin-plugins-core
> Version: 2.0.47-1
> Severity: normal
> Tags: upstream newcomer patch
> 
> The netstat plugin does not report anymore the value of active.value 
> because the output of netstat has changed.
> 
> Pseudo-patch:
> 
> -/active connections ope/  { print "active.value " $1 }
> +/active connections? ope/  { print "active.value " $1 }

Are you sure, that you encountered this with the current munin package?

The above issue should have been fixed in munin 2.0.35 [1].

Cheers,
Lars


[1] 
https://github.com/munin-monitoring/munin/commit/f2094f8f8e00d77e3fe3285d5e5c870e2aa4bedd

Bug#926980: Want to close this thread; no env anymore, and another related report.

[hoxp18]

Dear maintainers,

I did clean install on this box,
and reported the HDMI LOS issues on that new report

SEE ALSO: Bug#927788

So I think I should close this thread.
I will send "done" email on this ASAP.

Regards.

Bug#927912: unblock: gcalcli/4.0.4-2 (pre-approval)

[Unit 193]

Control: tags -1 moreinfo

Howdy,

I've uploaded the package and it should be in unstable now.


~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

On Fri, 26 Apr 2019, Niels Thykier wrote:


Control: tags -1 moreinfo confirmed

Unit 193:

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

Howdy,

Pending approval, I'm uploading a version of gcalcli which contains an upstream 
patch to fix the reliance on the Google shortening service.

If a user invokes one of the subcommands with '--details url', the application 
hits traceback issues as the service has been shut down.

See https://github.com/insanum/gcalcli/issues/440 for more details of the 
problem.


The changelog reads:

gcalcli (4.0.4-2) unstable; urgency=medium

  * d/p/remove_url_shortening.patch: Remove the deprecated goo.gl service.

 -- Unit 193   Wed, 24 Apr 2019 19:46:16 -0400


And debdiff:

[...]



Please go ahead with the upload and remove the moreinfo tag when it is
in unstable and ready to be unblocked.

Thanks,
~Niels

Bug#928055: change "disable-pings" to "no-pings"?

[ilf]

Package: chromium
Version: 74.0.3729.108-1

The HTML Living Standard of the Web Hypertext Application Technology 
Working Group specifies Hyperlink auditing AKA "pinging": 
https://html.spec.whatwg.org/multipage/links.html#hyperlink-auditing


The Debian chromium package tries to disable this by default:

# Disable pinging 
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --disable-pings"


https://salsa.debian.org/chromium-team/chromium/raw/master/debian/etc/default-flags

However, the upstream source code uses "no-pings", not "disable-pings":


// Don't send hyperlink auditing pings
const char kNoPings[]   = "no-pings";


https://cs.chromium.org/chromium/src/chrome/common/chrome_switches.cc?q=kNoPings=package:chromium=cs=438

This is also echoed by a Google Software Engineer working on Google, 
Chrome & Android:



--no-pings
Don't send hyperlink auditing pings


https://peter.sh/experiments/chromium-command-line-switches/#no-pings

So either I am missing something here, or the Debian package 
default-flags should replace "disable-pings" with "no-pings".


--
ilf

If you upload your address book to "the cloud", I don't want to be in it.


signature.asc
Description: PGP signature

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

On 4/26/19 4:55 PM, Luca Boccassi wrote:
> On Fri, 2019-04-26 at 16:47 +, proc...@riseup.net wrote:
>> OK. I found out this is not a problem on Fedora stations likely
>> because
>> they have the module built with 'y' instead of 'm'. Can you please
>> add
>> this to your next point release?
> If you want the module to always load, you can simply list it in
> /etc/modules - have you tried that?
>
Update:

According to jitter's author Stephan Mueller, the kernel module has no
effect on the quality of entropy injected in /dev/?random (it only
handles the kernel DRBG). /dev/?random entropy is only in the domain of
the userspace jitternetropy-rngd service which already works for us:

Quote from Stephan:

"As I tried to outline in the previous email: the /dev/random or /dev/urandom 
will NOT benefit from the in-kernel Jitter RNG. Only the user space 
jitterentropy-rngd from user space would inject entropy into /dev/random / /
de/urandom.

Therefore, I do not think that inserting the jitterentropy KO will help you 
for your goal."


You can close both tickets I guess. Thanks for everyone's input.



signature.asc
Description: OpenPGP digital signature

Bug#608121: FW: Grant

[Escuela 263, Min Adolfo Barbeito]

-Original Message-
From: Escuela 263, Min Adolfo Barbeito
Sent: Fri 4/26/2019 6:31 PM
To: i...@mail.com
Subject: Re: Grant
 

I, Mikhail Fridman picked you Reply To jb5406...@gmail.com for more details

Bug#927968: xmount: better description

[Xavier Brochard]

Le vendredi 26 avril 2019, 10:03:12 CEST Michael Prokop a écrit :
> Hi!
> 
> * Justin B Rye [Thu Apr 25, 2019 at 11:49:28PM +0100]:
> > Xavier Brochard wrote:
> [...]
> 
> > > 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.

I would put this last sentence at first, it will ease to understand what the 
primary purpose of xmount is. xmount is not the right tool if one need a 
virtual FS for running a VM at work like a virtual server.

-- 
Librement,
Xavier Brochard
« La liberté est à l'homme ce que les ailes sont à l'oiseau » 
(Jean-Pierre Rosnay)

Bug#928046: dosbox: input issues under Wayland (some keys not behaving)

[Stephen Kitt]

Hi Jonathan,

On Fri, 26 Apr 2019 20:05:34 +0100, Jonathan Dowland  wrote:
> Under GNOME/Wayland, when I launch DOOM2.EXE under DOSBOX, the arrow keys
> are not recognised. Other keys are (ESC in particular works) and I can type
> alphanumeric keys w/o error. DOOM relies upon raw keyboard input from DOS.
> 
> Logging into GNOME/Xorg and the problem goes away.

Thanks for the bug report. Does setting

usescancodes=false

in dosbox-0.74-2.conf help?

Regards,

Stephen


pgp78jAdRj__H.pgp
Description: OpenPGP digital signature

Bug#928053: CVE-2019-11387 CVE-2019-11388 CVE-2019-11389 CVE-2019-11390 CVE-2019-11391

[Moritz Muehlenhoff]

Package: modsecurity-crs
Severity: grave
Tags: security

These are still being assessed upstream ATM:

CVE-2019-11391
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1357

CVE-2019-11390
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1358

CVE-2019-11389
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1356

CVE-2019-11388
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1354

CVE-2019-11387
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1359

Cheers,
Moritz

Bug#928054: CVE-2019-11461

[Moritz Muehlenhoff]

Source: nautilus
Severity: important
Tags: security

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11461

Cheers,
Moritz

Bug#928052: CVE-2019-11502 CVE-2019-11503

[Moritz Muehlenhoff]

Source: snapd
Severity: grave
Tags: security

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11502
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11503

Cheers,
Moritz

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

On 4/26/19 4:55 PM, Luca Boccassi wrote:
> On Fri, 2019-04-26 at 16:47 +, proc...@riseup.net wrote:
>> OK. I found out this is not a problem on Fedora stations likely
>> because
>> they have the module built with 'y' instead of 'm'. Can you please
>> add
>> this to your next point release?
> If you want the module to always load, you can simply list it in
> /etc/modules - have you tried that?
>
Yes I've added a conf at /etc/modules-load.d/jitterentropy_rng.conf and
it loads as expected.

My suggestion was so that it would work in general on a default system
for users who don't know this is needed for the jitter service to be
effective.




signature.asc
Description: OpenPGP digital signature

Bug#928051: unblock: chromium/74.0.3729.108-1

[Moritz Muehlenhoff]

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

Please unblock package chromium. It fixes the recent security issues and
we're also following upstream releases in stable.

unblock chromium/74.0.3729.108-1

Cheers,
Moritz

Bug#928050: wireguard: Remove debhelper-compat-12 dependency. Replace with debian/compat level=5

[Anthony Metzidis]

Package: wireguard
Version: 0.0.20190406-1tonymet1
Severity: normal
Tags: patch

Dear Maintainer,

   * Upon attempting a build on raspbian-stretch, the build failed due to
missing debhelper-compat=12 . debhelper-compat=12 is not available on
raspbian
   * As a workaround, I removed the debhelper-compat=12 dependency, and set
debian/compat level=5
   * Without the change, naturally build failed.
   * With this change the build completed, and the binary package installed
properly

To improve compatibility can we make these changes:
* remove dep debhelper-compat=12 from debian/control
* echo 5 > debian/compat


// here is a patch


diff -ur wireguard-0.0.20190406/debian/changelog
../build-20190426-1250/wireguard-0.0.20190406/debian/changelog
--- wireguard-0.0.20190406/debian/changelog 2019-04-08 14:09:41.0
-0700
+++ ../build-20190426-1250/wireguard-0.0.20190406/debian/changelog
2019-04-26 12:33:42.587146169 -0700
@@ -1,3 +1,9 @@
+wireguard (0.0.20190406-1tonymet1) UNRELEASED; urgency=medium
+
+  * built on pi 3b+ for pi zero
+
+ --Fri, 26 Apr 2019 12:33:13 -0700
+
 wireguard (0.0.20190406-1) unstable; urgency=medium

   * New upstream version
Only in ../build-20190426-1250/wireguard-0.0.20190406/debian: compat
diff -ur wireguard-0.0.20190406/debian/control
../build-20190426-1250/wireguard-0.0.20190406/debian/control
--- wireguard-0.0.20190406/debian/control 2019-01-28 12:30:00.0
-0800
+++ ../build-20190426-1250/wireguard-0.0.20190406/debian/control 2019-04-26
12:41:51.061495718 -0700
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Daniel Kahn Gillmor 
 Build-Depends:
- debhelper-compat (= 12),
+ debhelper,
  dkms,
  libmnl-dev,
  pkg-config,
@@ -12,7 +12,6 @@
 Homepage: https://www.wireguard.com
 Vcs-Git: https://salsa.debian.org/debian/wireguard.git
 Vcs-Browser: https://salsa.debian.org/debian/wireguard
-Rules-Requires-Root: no

 Package: wireguard
 Architecture: all


-- System Information:
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.8 (stretch)
Release: 9.8
Codename: stretch
Architecture: armv7l

Kernel: Linux 4.14.98-v7+ (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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wireguard depends on:
ii  wireguard-dkms   0.0.20190406-1tonymet1
ii  wireguard-tools  0.0.20190406-1tonymet1

wireguard recommends no packages.

wireguard suggests no packages.

-- no debconf information

Bug#924105: Need to add group creation to postinst script

[Shane Spencer]

addgroup --force-bad-name --system _kea
adduser ...
adduser _kea _kea

That way kea is run as _kea.nogroup with access to _kea group.

Not sure about those names either.  Is that standard for kea installs?

Shane Spencer
about.me/ShaneSpencer

Bug#926481: stretch-pu: package open-vm-tools/2:10.1.5-5055683-4+deb9u2

[Salvatore Bonaccorso]

Hi Bernd,

On Sat, Apr 13, 2019 at 09:56:16PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2019-04-05 at 23:15 +0200, Bernd Zeimetz wrote:
> > as discuassed with the security team, I'd like to fix #925959
> > with the next stable pointrelease. The proposed debdiff is attached.
> > 
> 
> Please go ahead.

Did you saw the the ack from Adam? It is now unfortunately too late
for this upcoming point release, but would then be possible for the
next one.

Regards,
Salvatore

Bug#928049: sosreport: new sosreport upstream version (v3.7)

[Eric Desrochers]

Package: sosreport
Version: 3.7-1
Severity: normal

Dear Maintainer,

A new sosreport version (3.7) upstream got recently released.

Major enhancements to core features and existing plugins:

- New distribution policies for CentOS and Amazon Linux
- 19 new plugins:
- Obsolete IPSec plugin removed (in favour of OpenSwan)
- Support for passphrase and key based encryption of the report archive
- Improved handling of paths containing directory symbolic links (for e.g. /sys)
- New InitSystem abstraction
- LVM2 plugin enhancements
- Append plugin exceptions to sos_logs/*-plugin-exception.txt
- Dry run mode (--dry-run)
- Plugin API enhancements
- Significant enhancements to core features and existing plugins

Further release information and tarballs are available at:
https://github.com/sosreport/sos/releases/tag/3.7

I'm currently working at planning/preparing the upload of a new sosreport 
(3.7-1).

Bug#928048: RM: htslib [hurd-i386 i386 kfreebsd-i386] -- ROM; htslib is not supported on i386

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Control: tags 927850 - moreinfo

Hi ftpmasters,

as discussed in the unblock bug for htslib[1] the migration to testing
can only happen if the i386 architectures are removed.  So please remove
any-i386 from the archive.

Kind regards

   Andreas.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927850#15

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

[Xavier]

Le 26/04/2019 à 17:43, Xavier a écrit :
> Le 26/04/2019 à 17:41, Xavier a écrit :
>> Le 25/04/2019 à 15:35, Xavier Guimard a écrit :
>>> 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
>>
>> node-express builds well with upstream tests enabled and node-fresh
>> 0.2.0-2 (see
>> https://tests.reproducible-builds.org/debian/rb-pkg/experimental/arm64/node-express.html)
> 
> NB: test timeout is too short, so build2 failed sometimes.

autopkgtest succeeds also:
https://ci.debian.net/data/autopkgtest/unstable/amd64/n/node-express/2303232/log.gz
[node-express from experimental with node-fresh 0.2.0-2]

Bug#885069: stretch-pu: package open-iscsi/2.0.874-3~deb9u1

[Salvatore Bonaccorso]

Hi Christian,

On Fri, Nov 09, 2018 at 06:53:07AM +0100, Salvatore Bonaccorso wrote:
> Hi Christian,
> 
> On Sat, Feb 10, 2018 at 10:15:48AM +0100, Julien Cristau wrote:
> > Control: tag -1 moreinfo
> > 
> > On Sat, Dec 23, 2017 at 13:40:43 +0100, Christian Seiler wrote:
> > 
> > > diff -Nru 
> > > open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
> > >  
> > > open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
> > > --- 
> > > open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
> > > 1970-01-01 01:00:00.0 +0100
> > > +++ 
> > > open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
> > > 2017-12-23 13:09:13.0 +0100
> > > @@ -0,0 +1,122 @@
> > > +From e313bd648a4c8a9526421e270eb597a5de1e0c7f Mon Sep 17 00:00:00 2001
> > > +From: Lee Duncan 
> > > +Date: Fri, 15 Dec 2017 10:36:11 -0800
> > > +Subject: [PATCH 1/8] Check for root peer user for iscsiuio IPC
> > > +
> > > +This fixes a possible vulnerability where a non-root
> > > +process could connect with iscsiuio. Fouund by Qualsys.
> > > +---
> > > + iscsiuio/src/unix/Makefile.am  |  3 ++-
> > > + iscsiuio/src/unix/iscsid_ipc.c | 47 
> > > ++
> > > + 2 files changed, 49 insertions(+), 1 deletion(-)
> > > +
> > [...]
> > > +@@ -1029,6 +1035,40 @@ static void iscsid_loop_close(void *arg)
> > > + LOG_INFO(PFX "iSCSI daemon socket closed");
> > > + }
> > > + 
> > > ++/*
> > > ++ * check that the peer user is privilidged
> > > ++ *
> > 
> > This function doesn't actually do that.
> > 
> > > ++ * return 1 if peer is ok else 0
> > > ++ *
> > > ++ * XXX: this function is copied from iscsid_ipc.c and should be
> > > ++ * moved into a common library
> > > ++ */
> > > ++static int
> > > ++mgmt_peeruser(int sock, char *user)
> > > ++{
> > > ++struct ucred peercred;
> > > ++socklen_t so_len = sizeof(peercred);
> > > ++struct passwd *pass;
> > > ++
> > > ++errno = 0;
> > > ++if (getsockopt(sock, SOL_SOCKET, SO_PEERCRED, ,
> > > ++_len) != 0 || so_len != sizeof(peercred)) {
> > > ++/* We didn't get a valid credentials struct. */
> > > ++LOG_ERR(PFX "peeruser_unux: error receiving 
> > > credentials: %m");
> > > ++return 0;
> > > ++}
> > > ++
> > > ++pass = getpwuid(peercred.uid);
> > > ++if (pass == NULL) {
> > > ++LOG_ERR(PFX "peeruser_unix: unknown local user with uid 
> > > %d",
> > > ++(int) peercred.uid);
> > > ++return 0;
> > > ++}
> > > ++
> > > ++strlcpy(user, pass->pw_name, PEERUSER_MAX);
> > > ++return 1;
> > > ++}
> > > ++
> > > + /**
> > > +  *  iscsid_loop() - This is the function which will process the 
> > > broadcast
> > > +  *  messages from iscsid
> > > +@@ -1038,6 +1078,7 @@ static void *iscsid_loop(void *arg)
> > > + {
> > > + int rc;
> > > + sigset_t set;
> > > ++char user[PEERUSER_MAX];
> > > + 
> > > + pthread_cleanup_push(iscsid_loop_close, arg);
> > > + 
> > > +@@ -1077,6 +1118,12 @@ static void *iscsid_loop(void *arg)
> > > + continue;
> > > + }
> > > + 
> > > ++if (!mgmt_peeruser(iscsid_opts.fd, user) || 
> > > strncmp(user, "root", PEERUSER_MAX)) {
> > > ++close(s2);
> > > ++LOG_ERR(PFX "Access error: non-administrative 
> > > connection rejected");
> > > ++break;
> > > ++}
> > > ++
> > > + process_iscsid_broadcast(s2);
> > > + close(s2);
> > > + }
> > 
> > The above makes little sense to me.  We find out the peer uid, then
> > instead of just comparing that against 0 we turn it into a struct passwd
> > and compare pw_name against "root".  Why?
> 
> Did you had any chance to look at Julien's concerns/questions back on
> this proposed update for stretch?

Friendly ping :)

Regards,
Salvatore

Bug#928047: advanced install doesn't set root nor installer passwords

[CJ Fearnley]

Package: installation-reports

I booted off today's daily snapshot:
http://cdimage.debian.org/cdimage/daily-builds/daily/20190426-3/amd64/iso-cd/debian-testing-amd64-netinst.iso

I selected advanced install, I choose net install via ssh. The password
for the installer user did not work. Looking at /etc/shadow there was
an * in the password field for user installer. So the installer failed
to set the password which it prompted for.

When I did the install manually, everything went smoothly until I
rebooted.  There was no setting of the root password. I needed to reboot
the installer and use rescue mode to root the box in order to log in.

Everything except the passwords was smooth and bug free (so far as I
could tell).

-- 
CJ Fearnley |   LinuxForce Inc.
c...@linuxforce.net  |   IT Projects & Systems Maintenance
http://www.LinuxForce.net   |   http://blog.remoteresponder.net

Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

[Ross Vandegrift]

Control: Tags -1 unreproducible

On Wed, Apr 24, 2019 at 05:43:40AM +0300, sergio wrote:
> The real setup is:
> 
> % readlink .cache
> /tmp/sergio_cache
> 
> +
> 
> mkdir $(readlink ~/.cache)
> in .xsession
> 
> 
> And I have the issue every reboot, so I'm absolutely sure efreetd is
> restarted.
> 
> 
> Really I was wrong a bit: the cache (and
> .cache/efreet/icons_Adwaita_transient.eet exactly) is recreated, but
> pavucontrol has no icon untill I choose the theme again.

With a fresh efreetd, I cannot reproduce this issue.

1) Application Theme -> Icons, choose Adwaita icon theme.
2) rm ~/.cache/efreet/icons_Adwaita_*
3) log out and back in
4) check pavucontrol icon in everything & menus

Ross

Bug#928046: dosbox: input issues under Wayland (some keys not behaving)

[Jonathan Dowland]

Package: dosbox
Version: 0.74-2-3
Severity: normal

Under GNOME/Wayland, when I launch DOOM2.EXE under DOSBOX, the arrow keys are
not recognised. Other keys are (ESC in particular works) and I can type
alphanumeric keys w/o error. DOOM relies upon raw keyboard input from DOS.

Logging into GNOME/Xorg and the problem goes away.

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

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

Versions of packages dosbox depends on:
ii  libasound2   1.1.8-1
ii  libc62.28-8
ii  libgcc1  1:8.3.0-6
ii  libgl1   1.1.0-1
ii  libpng16-16  1.6.36-5
ii  libsdl-net1.21.2.8-6
ii  libsdl-sound1.2  1.0.3-9
ii  libsdl1.2debian  1.2.15+dfsg2-4
ii  libstdc++6   8.3.0-6
ii  libx11-6 2:1.6.7-1
ii  zlib1g   1:1.2.11.dfsg-1

dosbox recommends no packages.

dosbox suggests no packages.

-- no debconf information
# This is the configurationfile for DOSBox 0.74. (Please use the latest version 
of DOSBox)
# Lines starting with a # are commentlines and are ignored by DOSBox.
# They are used to (briefly) document the effect of each option.

[sdl]
#   fullscreen: Start dosbox directly in fullscreen. (Press ALT-Enter to go 
back)
#   fulldouble: Use double buffering in fullscreen. It can reduce screen 
flickering, but it can also result in a slow DOSBox.
#   fullresolution: What resolution to use for fullscreen: original or fixed 
size (e.g. 1024x768).
# Using your monitor's native resolution with aspect=true 
might give the best results.
# If you end up with small window on a large screen, try an 
output different from surface.
# windowresolution: Scale the window to this size IF the output device supports 
hardware scaling.
# (output=surface does not!)
#   output: What video system to use for output.
#   Possible values: surface, overlay, opengl, openglnb.
# autolock: Mouse will automatically lock, if you click on the screen. 
(Press CTRL-F10 to unlock)
#  sensitivity: Mouse sensitivity.
#  waitonerror: Wait before closing the console if dosbox has an error.
# priority: Priority levels for dosbox. Second entry behind the comma 
is for when dosbox is not focused/minimized.
# pause is only valid for the second entry.
#   Possible values: lowest, lower, normal, higher, highest, 
pause.
#   mapperfile: File used to load/save the key/event mappings from. 
Resetmapper only works with the defaul value.
# usescancodes: Avoid usage of symkeys, might not work on all operating 
systems.

fullscreen=false
fulldouble=true
fullresolution=original
windowresolution=1024x768
output=opengl
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-0.74.map
usescancodes=true

[dosbox]
# language: Select another language file.
#  machine: The type of machine tries to emulate.
#   Possible values: hercules, cga, tandy, pcjr, ega, vgaonly, svga_s3, 
svga_et3000, svga_et4000, svga_paradise, vesa_nolfb, vesa_oldvbe.
# captures: Directory where things like wave, midi, screenshot get captured.
#  memsize: Amount of memory DOSBox has in megabytes.
# This value is best left at its default to avoid problems with 
some games,
# though few games might require a higher value.
# There is generally no speed advantage when raising this value.

language=
machine=svga_s3
captures=capture
memsize=16

[render]
# frameskip: How many frames DOSBox skips before drawing one.
#aspect: Do aspect correction, if your output method doesn't support 
scaling this can slow things down!.
#scaler: Scaler used to enlarge/enhance low resolution modes.
#  If 'forced' is appended, then the scaler will be used even if 
the result might not be desired.
#Possible values: none, normal2x, normal3x, advmame2x, advmame3x, 
advinterp2x, advinterp3x, hq2x, hq3x, 2xsai, super2xsai, supereagle, tv2x, 
tv3x, rgb2x, rgb3x, scan2x, scan3x.

frameskip=0
aspect=false
scaler=normal2x

[cpu]
#  core: CPU Core used in emulation. auto will switch to dynamic if 
available and appropriate.
#Possible values: auto, dynamic, normal, simple.
#   cputype: CPU Type used in emulation. auto is the fastest choice.
#Possible values: auto, 386, 386_slow, 486_slow, pentium_slow, 
386_prefetch.
#cycles: Amount of instructions DOSBox tries to emulate each millisecond.
#Setting this value too high results in sound dropouts and lags.
#Cycles can be set in 3 ways:
#  

Bug#927850: unblock: htslib/1.9-11

[Niels Thykier]

Control: tags -1 moreinfo

Andreas Tille:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package htslib
> 
> 
> [...]
> 
> 
> unblock htslib/1.9-11
> 
> [...]
Hi,

Please file a bug against ftp.debian.org requesting the removal of
htslib on i386.  Without this removal, htslib cannot migrate to testing
regardless of whether we unblock it or not.

Please include the bug id of that removal bug in a follow up and remove
the moreinfo bug when the removal bug has been filed.

Thanks,
~Niels

Bug#927716: [Pkg-javascript-devel] Bug#927716: CVE-2018-1109

[Salvatore Bonaccorso]

Control: notfound 927716 2.0.2-2

Hi Xavier,

On Fri, Apr 26, 2019 at 07:52:55PM +0200, Xavier wrote:
> Le 26/04/2019 à 19:40, Xavier a écrit :
> > [...]
> > Hello,
> > 
> > The regex that causes CVE-2018-1109 was introduced in upstream version
> > 2.2.0, commit dcc1acab [1]. So Buster node-braces seems not concerned by
> > this CVE.
> > 
> > https://snyk.io/vuln/npm:braces:20180219 extract :
> > 
> >> braces is a Bash-like brace expansion, implemented in JavaScript.
> >>
> >> Affected versions of this package are vulnerable to Regular Expression
> >> Denial of Service (ReDoS) attacks. It used a regular expression
> >> (^\{(,+(?:(\{,+\})*),*|,*(?:(\{,+\})*),+)\}) in order to detects empty
> >> braces. This can cause an impact of about 10 seconds matching time for
> >> data 50K characters long.
> > 
> >  [...]
> > 
> > No regexp in 2.0.2 contains such expression.
> > 
> > Time to close this issue ?
> > 
> > Cheers,
> > Xavier
> > 
> > [1]:
> > https://github.com/micromatch/braces/commit/dcc1acab4de9a43e86ab4be4acde209ff1dca113
> > [2]:
> > https://github.com/micromatch/braces/commit/abdafb0cae1e0c00f184abbadc692f4eaa98f451
> 
> Confirmed by https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1109

Thanks for the troughfully analysis of the issue! Agreed then we can
close the bugreport. I have updated the security-tracker accordingly
in
https://salsa.debian.org/security-tracker-team/security-tracker/commit/02a96c8eab5fc8f7bb8ddcdfed28fb8cf3d03d4f
.

Regards,
Salvatore

Bug#927912: unblock: gcalcli/4.0.4-2 (pre-approval)

[Niels Thykier]

Control: tags -1 moreinfo confirmed

Unit 193:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Howdy,
> 
> Pending approval, I'm uploading a version of gcalcli which contains an 
> upstream patch to fix the reliance on the Google shortening service.
> 
> If a user invokes one of the subcommands with '--details url', the 
> application hits traceback issues as the service has been shut down.
> 
> See https://github.com/insanum/gcalcli/issues/440 for more details of the 
> problem.
> 
> 
> The changelog reads:
> 
> gcalcli (4.0.4-2) unstable; urgency=medium
> 
>   * d/p/remove_url_shortening.patch: Remove the deprecated goo.gl service.
> 
>  -- Unit 193   Wed, 24 Apr 2019 19:46:16 -0400
> 
> 
> And debdiff:
> 
> [...]
> 

Please go ahead with the upload and remove the moreinfo tag when it is
in unstable and ready to be unblocked.

Thanks,
~Niels

Bug#920759: workaround

[franckr]

Control: retitle -1 (with workaround) amdgpu+linux-images 4.9 & 4.19 crash 
randomly & always after X started, when dpm is enabled

Workaround: disable dynamic power management
  ex: put in /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet amdgpu.dpm=0"

Mechanism guess:
As behavior (works or crashes) depends of linux-image package (see below), and 
seems to evolve randomly across package versions (an older package version 
works, then a newer crashes, then a newer newer works again):
This suggests that a variable/structure is not properly initialized inside 
amdgpu dynamic power management code. Then depending of the RAM content during 
package compilation, a good value (=> package will work) or a bad value (=> 
will crash) is built-in inside the package.
This could explain the apparent random behavior across package versions.

  Work  = (C) + (B) + linux-image-4.19.0-0.bpo.4-amd64-unsigned 
4.19.28-2~bpo9+1 = upstream 10-Mar-2019
  Crash =   (B) + linux-image-4.19.0-0.bpo.4-amd64-unsigned 
4.19.28-2~bpo9+1 = upstream 10-Mar-2019
  Work  =   (B) + linux-image-4.19.0-0.bpo.2-amd64-unsigned 
4.19.16-1~bpo9+1 = upstream 16-Jan-2019
  Crash =   (B) + linux-image-4.9.0-9-amd64 4.9.161-1 = 
upstream 27-Feb-2019
  Crash =   (A) + linux-image-4.9.0-8-amd64 4.9.144-1 = 
upstream 08-Dec-2018 
  Work  =   (A) + linux-image-4.9.0-8-amd64 4.9.135-1 = 
upstream 20-Oct-2018

  (C) = disabled dynamic power management
  (B) = (firmware-amd-graphics   20190114-1) + (1920x1200 59.95Hz 8bit per RGB 
= nothing special)
  (A) = (firmware-amd-graphics   20161130-4)

Kind Regards,
Franck

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

[Niels Thykier]

Control: tags -1 moreinfo

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
> 
> [...]
> 

Please include a full debdiff of the changes.  The link to a master
branch with no clear marking of start/end commits makes it too time
consuming for us to evaluate the request.

Thanks,
~Niels

Bug#918535: smartmontools: New upstream release (7.0)

[Christian Franke]

Dear Maintainer (or NMUploader),

if possible, please also include the attached patch to a 
smartmontools-7.0 package.

Details: https://www.smartmontools.org/ticket/1154

Thanks,
Christian
smartmontools.org

Index: ataprint.cpp
===
--- ataprint.cpp(revision 4883)
+++ ataprint.cpp(revision 4889)
@@ -704,7 +704,8 @@
 else
   jout("Form Factor:  Unknown (0x%04x)\n", word168);
 jglb["form_factor"]["ata_value"] = word168;
-jglb["form_factor"]["name"] = form_factor;
+if (form_factor)
+  jglb["form_factor"]["name"] = form_factor;
   }
 
   // See if drive is recognized

Bug#924616: RFT and RFC: Updates for evolution{,-data-server}

[Jonas Meurer]

Hi Mike,

Mike Gabriel:
> On  Mi 24 Apr 2019 12:56:18 CEST, Jonas Meurer wrote:
> 
>> Jonas Meurer:
>>> With evolution-data-server, the situation is slightly more complicated.
>>> I'm still debugging issues with the patches[5] that are supposed to fix
>>> the "[GPG] Mails that are not encrypted look encrypted" issue.
>>>
>>> [5] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/93306a29
>>> and https://gitlab.gnome.org/GNOME/evolution-data-server/commit/accb0e24
>>>
>>> My question: do you agree that these fixes are within the scope of
>>> CVE-2018-15587? If so, then I will continue working on the issue and
>>> upload both of evolution and evolution-data-server in a batch once I got
>>> the issues sorted out.
>>>
>>> Another option would be to upload evolution to jessie-security right now
>>> and decide that evolution-data-server is not affected by CVE-2018-15587,
>>> since it's only prone to "encrypted message spoofing", not to "signature
>>> spoofing". But in my eyes, that would be a sham.
>>
>> Looking more into the core issue[1] of "[GPG] Mails that are not
>> encrypted look encrypted", it became clear that a lot of applications
>> (GnuPG[2], Enigmail[3], Mutt[4]) are affected and it's not tracked as
>> security issue for any of them.
> 
> Is it required to coordinate an according update of those CVEs in
> data/CVE/list with the security team? Sounds like it.

Yep, you're correct. The Security Team is in the loop now and basically
agrees with my evaluation.

>> In fact it's tracked for evolution{,-data-server} in the debian security
>> tracker only because the issue is mentioned in the CVE-2018-15587
>> bugreport[5].
>>
>> Besides, I agree with the bug author that "this bug is certainly not in
>> the same category as a serious security vulnerability, such as a
>> plaintext leak or a signature spoof"[1].
>>
>> So I changed my mind and decided to ignore the "encryption spoofing" bug
>> and only care about "signature spoofing". This means that
>> evolution-data-server is unaffected and only evolution needs to be fixed.
> 
> Your choice of priority sounds good to me.

Thanks a lot for your comments! I just went ahead and uploaded a fixed
evolution to jessie-security. I also consequently removed
evolution-data-server from data/dla-needed.txt.

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

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

[Niels Thykier]

Control: tags -1 moreinfo confirmed

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
> 
> [...]

Please go ahead with the upload and remove the moreinfo tag when the
upload is in unstable and ready to be unblocked.

Thanks,
~Niels

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

[Harald Dunkel]

metoo

Using upstream's google-chrome 74.0.3729.108 there is no such 
problem.

Bug#928044: libwebkit2gtk-4.0-37: version 2.24.1-1 does not play some streams

[richard lucassen]

Note: the version mentioned is the *downgraded* version!

Version: 2.22.7-1 (downgraded version that one works)

must be

Version: 2.24.1-1 (latest, works partially)

R.

-- 
richard lucassen
http://contact.xaq.nl/

Bug#886481: RFP: herbie -- Synthesis for floating-point expressions

[Nicolas Braud-Santoni]

Control: clone -1 -2
Control: retitle -2 ITP: herbie -- Synthesis for floating-point expressions
Control: owner -2 !
Control: block -1 by -2

Hi Roman,

I also have interest and use for Herbie being packaged into Debian.

I intent to publish a package for it in the near future (started the packaging
work earlier today), and I would be happy to collaborate with you on 
maintainance
if that's something you would be interested in helping with.


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#928044: libwebkit2gtk-4.0-37: version 2.24.1-1 does not play some streams

[Richard Lucassen]

Package: libwebkit2gtk-4.0-37
Version: 2.22.7-1
Severity: normal

Dear Maintainer,

After an upgrade from 2.22.7 to 2.24.1-1, libwebkit2gtk refuses to play some 
radio streams. Downgrade to 2.22.7 resolves the problem. Seen on 4 different 
machines. The browser I use is "surf". The audio system is ALSA.

1) Go to http://radio.dos.nl/

2) Go to settings (drop down in right top corner)

3) Click "Choose protocol" until it shows HLS

4) Click on arrow (back to radio)

5) Click on "Page menu" (bottom left corner) and choose "news"

6) Click "France Info", network stream starts, no audio (protocol: AAC)

7) Click "France Culture": works (same protocol: AAC)

Downgrade to 2.22.7 (I also needed to downgrade libjavascriptcoregtk 2.22.7-1 
as well)

Now all stations work. Note that the networkstream is there, there is simply no 
sound. There is also another difference: HLS streams start quicker under 2.22.7 
than under 2.24.1-1. E.g. BBC5 on the same page is an HLS stream.

Richard.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libwebkit2gtk-4.0-37 depends on:
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-8
ii  libcairo2   1.16.0-4
ii  libegl1 1.1.0-1
ii  libenchant1c2a  1.6.0-11.1+b1
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3
ii  libgcc1 1:8.3.0-6
ii  libgcrypt20 1.8.4-5
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libgl1  1.1.0-1
ii  libglib2.0-02.58.3-1
ii  libgstreamer-gl1.0-01.14.4-1
ii  libgstreamer-plugins-base1.0-0  1.14.4-1
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libharfbuzz-icu02.3.1-1
ii  libharfbuzz0b   2.3.1-1
ii  libhyphen0  2.8.8-7
ii  libicu6363.1-6
ii  libjavascriptcoregtk-4.0-18 2.22.7-1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libnotify4  0.7.7-4
ii  libpango-1.0-0  1.42.4-6
ii  libpng16-16 1.6.36-5
ii  libsecret-1-0   0.18.7-1
ii  libsoup2.4-12.64.2-2
ii  libsqlite3-03.27.2-2
ii  libstdc++6  8.3.0-6
ii  libtasn1-6  4.13-3
ii  libwayland-client0  1.16.0-1
ii  libwayland-egl1 1.16.0-1
ii  libwayland-server0  1.16.0-1
ii  libwebp60.6.1-2
ii  libwebpdemux2   0.6.1-2
ii  libwoff11.0.2-1
ii  libx11-62:1.6.7-1
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3+b3
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxslt1.1  1.1.32-2
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages libwebkit2gtk-4.0-37 recommends:
ii  gstreamer1.0-alsa  1.14.4-1
ii  gstreamer1.0-gl1.14.4-1
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  libgl1-mesa-dri18.3.4-2

Versions of packages libwebkit2gtk-4.0-37 suggests:
pn  libwebkit2gtk-4.0-37-gtk2  

-- debconf-show failed

Bug#928043: installation-reports: cryptsetup does not accept password on fresh install (testing)

[Evgeny Badin]

Package: installation-reports
Severity: important

Dear Maintainer,

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

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

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

For several weeks or even months I've been unable to use Debian Testing after
installation (I could only install Stable and upgrade to Testing manually).
Installation goes fine (I use daily unofficial builds that include
firmware, including buster_di_rc1+nonfree), I choose full disk encryption with
LVM, after reboot I need to enter cryptsetup password, but it won't accept it,
(even though I'm sure I enter the right one)

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

Bug#928042: pikepdf: flaky autopkgtest: random input results in failing test sometimes

[Paul Gevers]

Source: pikepdf
Version: 1.0.5+dfsg-2
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainers,

With a recent upload of glibc the autopkgtest of pikepdf fails in
testing when that autopkgtest is run with the binary packages of glibc
from unstable. However, when I triggered a retry, the test passed. I
looked into the history of your autopkgtest and it fails once in a while
with the same error every time (as far as I checked). The failing test
*seems* to be using some random input. I suspect there are possible
inputs that result in the failure.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are wasting peoples time. Please either fix the test to be more robust,
or mark the test as "flaky".

I copied some of the output at the bottom of this report.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pikepdf/2299297/log.gz

=== FAILURES
===
__ test_random_dates
___

@given(
>   integers(-, ),
integers(0, 99),
integers(0, 99),
integers(0, 99),
integers(0, 99),
integers(0, 99),
)
def test_random_dates(year, month, day, hour, mins, sec):

tests/test_metadata.py:248:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/hypothesis/core.py:519: in execute
result = self.test_runner(data, run)
/usr/lib/python3/dist-packages/hypothesis/executors.py:58: in
default_new_style_executor
return function(data)
/usr/lib/python3/dist-packages/hypothesis/core.py:517: in run
return test(*args, **kwargs)
tests/test_metadata.py:248: in test_random_dates
integers(-, ),
/usr/lib/python3/dist-packages/hypothesis/core.py:464: in test
result = self.test(*args, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

year = 1, month = 1, day = 1, hour = 0, mins = 0, sec = 0

@given(
integers(-, ),
integers(0, 99),
integers(0, 99),
integers(0, 99),
integers(0, 99),
integers(0, 99),
)
def test_random_dates(year, month, day, hour, mins, sec):
date_args = year, month, day, hour, mins, sec
xmp = '{:04d}-{:02d}-{:02d}T{:02d}:{:02d}:{:02d}'.format(*date_args)
docinfo = '{:04d}{:02d}{:02d}{:02d}{:02d}{:02d}'.format(*date_args)

try:
converted = DateConverter.docinfo_from_xmp(xmp)
except ValueError:
pass
else:
>   assert converted == docinfo
E   AssertionError: assert '1010100' == '0001010100'
E - 1010100
E + 0001010100
E ? +++

tests/test_metadata.py:265: AssertionError
-- Hypothesis
--
Falsifying example: test_random_dates(year=1, month=1, day=1, hour=0,
mins=0, sec=0)



signature.asc
Description: OpenPGP digital signature

Bug#928031: Preseed on buster have problems

[Jose M Calhariz]

On Fri, Apr 26, 2019 at 06:06:37PM +0100, Jose M Calhariz wrote:
> On Fri, Apr 26, 2019 at 05:42:36PM +0200, Cyril Brulebois wrote:
> > Thanks for the follow-up.
> > 
> > Jose M Calhariz  (2019-04-26):
> > > On Fri, Apr 26, 2019 at 03:09:31PM +0200, Cyril Brulebois wrote:
> > > > Jose M Calhariz  (2019-04-26):
> > > > > I am doing this report because I wanted test preseed on buster.
> > > > > I found some problems, by order of priority:
> > > > > 
> > > > >   - The installation using preseed, ends with an incomplete
> > > > > /etc/apt/sources.list that prevents to install more software after
> > > > > the instalation.
> > > > 
> > > > Can you please share more details about that?
> > > 
> > > This is the /etc/apt/sources.list that I get when using preseed:
> > > 
> > > # 
> > > 
> > > # deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 
> > > NETINST 20190411-22:32]/ buster main
> > > 
> > > deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 
> > > NETINST 20190411-22:32]/ buster main
> > 
> > This seems consistent with your settings (excerpt from [1]):
> > 
> > # Uncomment this if you don't want to use a network mirror.
> > d-i apt-setup/use_mirror boolean false
> > # Select which update services to use; define the mirrors to be used.
> > # Values shown below are the normal defaults.
> > d-i apt-setup/services-select multiselect
> > #d-i apt-setup/security_host string security.debian.org
> > 
> >  1. http://web.ist.utl.pt/ist24403/preseed.cfg
> > 
> > since apt-setup/use_mirror=false means the cdrom: URI will be kept and
> > no network mirror is to be used?
> 
> My original preseed included references for a modified local mirror of
> Debian that the upper management did not authorize to make public the
> URL yet.  In my defence the original preseed works with stretch and I
> am trying to understand why it fails for buster.  So one more
> question, during instalation of base and tasks, like openssh-server,
> where is the sources.list that is being used.  It is not in
> /target/etc/apt/sources.list

I found some interesting bits:

Main problem is in my original preseed, I have not updated enough for
buster.  Done that the installation now goes to the end.  The
sources.list is still broken, with the same content has previously
shown.  The same rough preseed works as desired on stretch, minus the
replacement of words stretch and buster.  So maybe "d-i
apt-setup/use_mirror boolean false" have a change in behaviour between
stretch and buster.

What I want in the end is a sources.list with the repositories from
"d-i apt-setup/local[0-9]/repository ..." and not the original mirror
from installation.  I can explain why in another email.

> 
> > 
> > > > >   - The text installer show a black screen, I need to use "fb=false".
> > > > 
> > > > We would probably need to know more about your hardware here.
> > > 
> > > Right, I missed that I am using virtio as display, my command line is:
> > > 
> > > kvm -m 4096 -localtime -drive file=debian.qcow2,if=virtio 
> > > -usbdevice tablet -k en-gb -vga virtio -cdrom 
> > > /srv/software/debian-buster-DI-rc1-amd64-netinst.iso -boot d
> > 
> > Hopefully somebody else will pick up this specific part.
> > 
> > 
> > Cheers,
> 
> Kind regards
> Jose M Calhariz
> 


Kind regards
Jose M Calhariz

-- 
--
Uma consciência que já foi comprada uma vez pode ser
comprada de novo.
-- Norbert Wiener


signature.asc
Description: PGP signature

Bug#922550: Same problem here

[Quentin Caillard]

@debian:~$ sudo systemd-analyze blame
  5min 804ms ifupdown-wait-online.service
  5.515s sickrage.service
  3.448s NetworkManager-wait-online.service
  1.128s systemd-udev-settle.service
  1.005s alsa-restore.service

Bug#927716: [Pkg-javascript-devel] Bug#927716: CVE-2018-1109

[Xavier]

Le 26/04/2019 à 19:40, Xavier a écrit :
> [...]
> Hello,
> 
> The regex that causes CVE-2018-1109 was introduced in upstream version
> 2.2.0, commit dcc1acab [1]. So Buster node-braces seems not concerned by
> this CVE.
> 
> https://snyk.io/vuln/npm:braces:20180219 extract :
> 
>> braces is a Bash-like brace expansion, implemented in JavaScript.
>>
>> Affected versions of this package are vulnerable to Regular Expression
>> Denial of Service (ReDoS) attacks. It used a regular expression
>> (^\{(,+(?:(\{,+\})*),*|,*(?:(\{,+\})*),+)\}) in order to detects empty
>> braces. This can cause an impact of about 10 seconds matching time for
>> data 50K characters long.
> 
>  [...]
> 
> No regexp in 2.0.2 contains such expression.
> 
> Time to close this issue ?
> 
> Cheers,
> Xavier
> 
> [1]:
> https://github.com/micromatch/braces/commit/dcc1acab4de9a43e86ab4be4acde209ff1dca113
> [2]:
> https://github.com/micromatch/braces/commit/abdafb0cae1e0c00f184abbadc692f4eaa98f451

Confirmed by https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1109

Bug#927716: CVE-2018-1109

[Xavier]

Le 25/04/2019 à 13:41, Xavier a écrit :
> Control: tags -1 + moreinfo
> 
> Le 22/04/2019 à 07:38, Xavier a écrit :
>> Le 21/04/2019 à 22:33, Moritz Muehlenhoff a écrit :
>>> Package: node-braces
>>> Severity: important
>>> Tags: security
>>>
>>> Please see https://snyk.io/vuln/npm:braces:20180219
>>>
>>> Patch:
>>> https://github.com/micromatch/braces/commit/abdafb0cae1e0c00f184abbadc692f4eaa98f451
>>>
>>> Cheers,
>>> Moritz
>>
>> Buster version (2.0.2) seems not easily to patch.
> 
> It seems that the vulnerable regexp doesn't exist in node-braces 2.0.2.
> I can't find any exploit to verify this. Could someone help here ?

Hello,

The regex that causes CVE-2018-1109 was introduced in upstream version
2.2.0, commit dcc1acab [1]. So Buster node-braces seems not concerned by
this CVE.

https://snyk.io/vuln/npm:braces:20180219 extract :

> braces is a Bash-like brace expansion, implemented in JavaScript.
>
> Affected versions of this package are vulnerable to Regular Expression
> Denial of Service (ReDoS) attacks. It used a regular expression
> (^\{(,+(?:(\{,+\})*),*|,*(?:(\{,+\})*),+)\}) in order to detects empty
> braces. This can cause an impact of about 10 seconds matching time for
> data 50K characters long.

Commit dcc1acab [1]:

  ...lib/parser.js
  +/**
  + * Empty braces (we capture these early to
  + * speed up processing in the compiler)
  + */
  +
  +.set('multiplier', function() {
  +  var pos = this.position();
  +  var m = this.match(/^\{(,+(?:(\{,+\})*),*|,*(?:(\{,+\})*),+)\}/);
  +  if (!m) return;
  +
  +  this.multiplier = true;
  +  var prev = this.prev();
  +  var node = pos(new Node({
  +type: 'text',
  +multiplier: 1,
  +match: m,
  +val: m[0]
  +  }));
  +
  +  return concatNodes.call(this, pos, node, prev, options);
  ...

and the fix is [2]:

  ...lib/parsers.js
  @@ -127,7 +127,7 @@ module.exports = function(braces, options) {
 .set('multiplier', function() {
   var isInside = this.isInside('brace');
   var pos = this.position();
  -var m = this.match(/^\{(,+(?:(\{,+\})*),*|,*(?:(\{,+\})*),+)\}/);
  +var m = this.match(/^\{((?:,|\{,+\})+)\}/);
   if (!m) return;

  this.multiplier = true;

No regexp in 2.0.2 contains such expression.

Time to close this issue ?

Cheers,
Xavier

[1]:
https://github.com/micromatch/braces/commit/dcc1acab4de9a43e86ab4be4acde209ff1dca113
[2]:
https://github.com/micromatch/braces/commit/abdafb0cae1e0c00f184abbadc692f4eaa98f451

Bug#928031: Preseed on buster have problems

[Jose M Calhariz]

On Fri, Apr 26, 2019 at 05:42:36PM +0200, Cyril Brulebois wrote:
> Thanks for the follow-up.
> 
> Jose M Calhariz  (2019-04-26):
> > On Fri, Apr 26, 2019 at 03:09:31PM +0200, Cyril Brulebois wrote:
> > > Jose M Calhariz  (2019-04-26):
> > > > I am doing this report because I wanted test preseed on buster.
> > > > I found some problems, by order of priority:
> > > > 
> > > >   - The installation using preseed, ends with an incomplete
> > > > /etc/apt/sources.list that prevents to install more software after
> > > > the instalation.
> > > 
> > > Can you please share more details about that?
> > 
> > This is the /etc/apt/sources.list that I get when using preseed:
> > 
> > # 
> > 
> > # deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 
> > NETINST 20190411-22:32]/ buster main
> > 
> > deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 
> > NETINST 20190411-22:32]/ buster main
> 
> This seems consistent with your settings (excerpt from [1]):
> 
> # Uncomment this if you don't want to use a network mirror.
> d-i apt-setup/use_mirror boolean false
> # Select which update services to use; define the mirrors to be used.
> # Values shown below are the normal defaults.
> d-i apt-setup/services-select multiselect
> #d-i apt-setup/security_host string security.debian.org
> 
>  1. http://web.ist.utl.pt/ist24403/preseed.cfg
> 
> since apt-setup/use_mirror=false means the cdrom: URI will be kept and
> no network mirror is to be used?

My original preseed included references for a modified local mirror of
Debian that the upper management did not authorize to make public the
URL yet.  In my defence the original preseed works with stretch and I
am trying to understand why it fails for buster.  So one more
question, during instalation of base and tasks, like openssh-server,
where is the sources.list that is being used.  It is not in
/target/etc/apt/sources.list

> 
> > > >   - The text installer show a black screen, I need to use "fb=false".
> > > 
> > > We would probably need to know more about your hardware here.
> > 
> > Right, I missed that I am using virtio as display, my command line is:
> > 
> > kvm -m 4096 -localtime -drive file=debian.qcow2,if=virtio 
> > -usbdevice tablet -k en-gb -vga virtio -cdrom 
> > /srv/software/debian-buster-DI-rc1-amd64-netinst.iso -boot d
> 
> Hopefully somebody else will pick up this specific part.
> 
> 
> Cheers,

Kind regards
Jose M Calhariz

-- 
--
Uma consciência que já foi comprada uma vez pode ser
comprada de novo.
-- Norbert Wiener


signature.asc
Description: PGP signature

Bug#928041: systemd: please document the recommended way to add a systemd timer to a package

[Francesco Poli (wintermute)]

Package: systemd
Version: 241-3
Severity: normal

Hello,
the other day I noticed that lintian pointed out a new missing piece
in my package (apt-listbugs):
missing-systemd-timer-for-cron-script

Basically, it alerts me that my package ships a cron.daily script,
without shipping a corresponding systemd timer.

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 (such as man-db and
logrotate).
I am starting to get an idea of how to set this up, but some aspects
are still unclear.

My main needs are:

 a) the script (to be executed by the systemd timer) may generate
output: this output should be sent to root@localhost via local
mail (if a sendmail-compatible MTA is installed and able to
deliver local mail)
 
 b) the cron.daily job should not run, if systemd is installed
and used as PID 1

I searched for documentation about the recommended Debian way to add a
systemd timer to a package, but failed to find much.

The Debian Policy manual talks about [cron jobs], but does not seem
to mention systemd timers. There seems to be an [open bug report]
about this, which also [mentions] the need to avoid running cron jobs
which are superseded by systemd timers.

I found some information about the need to send local mail on
the [archlinux wiki], but the suggested workaround looks inconvenient
(since it requires writing a dedicated script for something
that cron provides out of the box!) and suitable for failing
jobs only (while I need to send local mail, whenever the job generates
output)...

[cron jobs]: 

[open bug report]: 
[mentions]: 
[archlinux wiki]: 


Could you please document the recommended Debian way to add a
systemd timer to a package, which also ships a cron job?

Thanks for your time and for any help you may provide.
Bye.

Bug#927972: jitterentropy_rng.ko never loads

[Luca Boccassi]

On Fri, 2019-04-26 at 16:47 +, proc...@riseup.net wrote:
> OK. I found out this is not a problem on Fedora stations likely
> because
> they have the module built with 'y' instead of 'm'. Can you please
> add
> this to your next point release?

If you want the module to always load, you can simply list it in
/etc/modules - have you tried that?

-- 
Kind regards,
Luca Boccassi


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

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

[Bernhard Übelacker]

Hello Adrian,


> Using a console login and startx, everything works fine though.
> 
> 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.
> 
> 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.

So I have installed in a minimal Buster amd64 VM these packages:
xdm gnome
And configured xdm as default.
With that I could login just fine, so this seems not an issue
in a fresh installation.


In this configuration it looks like gnome is running with xorg.
Therefore you might also have a look into $HOME/.xsession-errors
and /var/log/Xorg.0.log or /var/log/Xorg.1.log.

Do you get dropped back to xdm immediately or do you stay at e.g. a
black screen?

Is there anything in the syslog above the "Started User Manager for..."
message in the same second and a few before?


> Does this read any package maintainer?

Currently this bug is assigned to package sddm, so just
sddm maintainer might have this on the screen.
Also your last email describes kind of a different issue,
with not even sddm involved.

Because you say this can be seen with sddm and xdm I guess
the problem might not be in these packages, therefore reassigning
to gnome-session might attract the right people?

Kind regards,
Bernhard

Bug#928040: lprng: fails to install

[Simon Richter]

Package: lprng
Version: 3.8.B-2.1
Severity: grave
Justification: renders package unusable

Hi,

lprng fails to upgrade from stretch to buster, and also fails to install on
top of itself:

# LC_ALL=C dpkg -i /var/cache/apt/archives/lprng_3.8.B-2.1_amd64.deb 
(Reading database ... 634188 files and directories currently installed.)
Preparing to unpack .../lprng_3.8.B-2.1_amd64.deb ...
start-stop-daemon: matching only on non-root pidfile /var/run/lprng/lpd.515 is 
insecure
invoke-rc.d: initscript lprng, action "stop" failed.
dpkg: warning: old lprng package pre-removal script subprocess returned error 
exit status 1
dpkg: trying script from the new package instead ...
start-stop-daemon: matching only on non-root pidfile /var/run/lprng/lpd.515 is 
insecure
invoke-rc.d: initscript lprng, action "stop" failed.
dpkg: error processing archive 
/var/cache/apt/archives/lprng_3.8.B-2.1_amd64.deb (--install):
 new lprng package pre-removal script subprocess returned error exit status 1
invoke-rc.d: initscript lprng, action "start" failed.
dpkg: error while cleaning up:
 installed lprng package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/lprng_3.8.B-2.1_amd64.deb

   Simon

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/8 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: sysvinit (via /sbin/init)

Versions of packages lprng depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-8
ii  libcomerr2 1.44.5-1
ii  libk5crypto3   1.17-2
ii  libkrb5-3  1.17-2
ii  libssl1.1  1.1.1b-2
ii  lsb-base   10.2019031300

lprng recommends no packages.

Versions of packages lprng suggests:
pn  lprng-doc
pn  magicfilter  

-- debconf information:
  lprng/setuid_tools: false
  lprng/start_lpd: true
  lprng/twolpd_conf:
  lprng/twolpd_perms:

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

OK. I found out this is not a problem on Fedora stations likely because
they have the module built with 'y' instead of 'm'. Can you please add
this to your next point release?

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

[積丹尼 Dan Jacobson]

Maybe the document should say "don't worry, the installer process will walk you
through this.

/tmp: well I just use tmpfs.

Also the worst thing is if one searches on Google for /var /home vs.
just / Debian articles, he will find ../jessie/.. and has to put in the
word ../stretch/.. in the URL to get the newer version.

So even if he knew which name is newer, Google doesn't so gives them all
the same priority for search results... in fact backward priority.

So even if you make a spanking new version, people will still find the
older version.

Anyway you might want to just merge the document with the installer documents.

Bug#927348: unblock: salt/2018.3.4+dfsg1-2

[Benjamin Drung]

retitle 927348 unblock: salt/2018.3.4+dfsg1-4
thanks

Hi,

two more uploads for salt were needed: The first for repairing the
documentation (correct JavaScript symlinks and making the search work
again). The second for fixing the autopkgtest when using systemd 241-3. 
A debdiff between salt 2018.3.4+dfsg1-2 and 2018.3.4+dfsg1-4 is
attached.

unblock salt/2018.3.4+dfsg1-4

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet
diff -Nru salt-2018.3.4+dfsg1/debian/changelog salt-2018.3.4+dfsg1/debian/changelog
--- salt-2018.3.4+dfsg1/debian/changelog	2019-04-17 20:26:11.0 +0200
+++ salt-2018.3.4+dfsg1/debian/changelog	2019-04-26 16:38:39.0 +0200
@@ -1,3 +1,26 @@
+salt (2018.3.4+dfsg1-4) unstable; urgency=medium
+
+  * Cherry-pick upstream patch to fix retrieving systemd version (for 241-3)
+
+ -- Benjamin Drung   Fri, 26 Apr 2019 16:38:39 +0200
+
+salt (2018.3.4+dfsg1-3) unstable; urgency=medium
+
+  [ Benjamin Drung ]
+  * tests: Drop copying missing templates directory
+  * salt-doc: Install favicon in document root and do not compress it
+  * salt-doc: Fix JavaScript symlinks to bootstrap (Closes: #919849)
+  * doc: Set script type explicitly to text/javascript
+  * Use jquery.js from sphinx
+  * Symlink vendor JavaScript files before building
+  * Use dh_sphinxdoc
+
+  [ Steffen Kockel ]
+  * doc: Fix logo link to point to contents.html
+  * doc: Ensure searchtools.js gets included (to fix the search)
+
+ -- Benjamin Drung   Thu, 25 Apr 2019 13:39:10 +0200
+
 salt (2018.3.4+dfsg1-2) unstable; urgency=medium
 
   * Fix test_xen_virtual on kernels with no Xen support (Closes: #922352)
diff -Nru salt-2018.3.4+dfsg1/debian/control salt-2018.3.4+dfsg1/debian/control
--- salt-2018.3.4+dfsg1/debian/control	2019-04-05 14:43:18.0 +0200
+++ salt-2018.3.4+dfsg1/debian/control	2019-04-25 17:08:50.0 +0200
@@ -11,6 +11,8 @@
debhelper (>= 11),
dh-python,
dpkg-dev (>= 1.16.2),
+   libjs-bootstrap,
+   libjs-modernizr,
python3,
python3 (>= 3.6) | python3-mock,
python3-augeas,
@@ -52,6 +54,7 @@
python3-twilio,
python3-yaml,
python3-zmq (>= 13.1.0),
+   sphinx-common,
virtualenv
 Build-Depends-Indep: python3-doc, python3-sphinx (>= 1.3.5)
 Standards-Version: 4.3.0
@@ -219,11 +222,11 @@
 Package: salt-doc
 Architecture: all
 Section: doc
+Built-Using: ${sphinxdoc:Built-Using}
 Depends: libjs-bootstrap,
- libjs-jquery,
  libjs-modernizr,
- libjs-sphinxdoc,
- ${misc:Depends}
+ ${misc:Depends},
+ ${sphinxdoc:Depends}
 Breaks: salt-common (<< 2016.11.5)
 Replaces: salt-common (<< 2016.11.5)
 Description: additional documentation for salt, the distributed remote execution system
diff -Nru salt-2018.3.4+dfsg1/debian/patches/doc-fix-logo-link.patch salt-2018.3.4+dfsg1/debian/patches/doc-fix-logo-link.patch
--- salt-2018.3.4+dfsg1/debian/patches/doc-fix-logo-link.patch	1970-01-01 01:00:00.0 +0100
+++ salt-2018.3.4+dfsg1/debian/patches/doc-fix-logo-link.patch	2019-04-25 17:09:29.0 +0200
@@ -0,0 +1,27 @@
+From 5c3036d248c4ae76d2fa7598cde179294aa4b2bb Mon Sep 17 00:00:00 2001
+From: Steffen Kockel 
+Date: Tue, 23 Apr 2019 17:45:00 +0200
+Subject: [PATCH] doc: Fix logo link
+
+The link on the brand image was pointing to index.html which does not
+exist. The index file seems to be contents.html.
+---
+ doc/_themes/saltstack/layout.html | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/doc/_themes/saltstack/layout.html b/doc/_themes/saltstack/layout.html
+index 85e0a3cf..d5ff2cd6 100644
+--- a/doc/_themes/saltstack/layout.html
 b/doc/_themes/saltstack/layout.html
+@@ -181,7 +181,7 @@
+ 
+ 
+ 
+-
++
+ 
+ {%- block relbar1 %}{{ relbar() }}{% endblock %}
+ 
+-- 
+2.17.1
+
diff -Nru salt-2018.3.4+dfsg1/debian/patches/doc-Set-script-type-explicitly-to-text-javascript.patch salt-2018.3.4+dfsg1/debian/patches/doc-Set-script-type-explicitly-to-text-javascript.patch
--- salt-2018.3.4+dfsg1/debian/patches/doc-Set-script-type-explicitly-to-text-javascript.patch	1970-01-01 01:00:00.0 +0100
+++ salt-2018.3.4+dfsg1/debian/patches/doc-Set-script-type-explicitly-to-text-javascript.patch	2019-04-25 17:09:29.0 +0200
@@ -0,0 +1,52 @@
+From e22e49d974937ed9107cf33c679799c914f2 Mon Sep 17 00:00:00 2001
+From: Benjamin Drung 

Bug#922696: Allow ppc64el

[Frédéric Bonnard]

Control: tags -1 patch

--

Hi,
testing a simple change in build_core/SConscript and the package built
on ppc64el.
Maybe more would follow later, but so far so good.
"any" is already there.
I sent a merge request :

https://salsa.debian.org/debian-iot-team/alljoyn/alljoyn-services-1604/merge_requests/1

Regards,

F.


pgpOTeAMU1iqU.pgp
Description: PGP signature

Bug#928039: sudo: segfault/core dump after a plugin init fails

[Richard Fuchs]

Package: sudo
Version: 1.8.19p1-2.1
Severity: important
Tags: patch

Dear Maintainer,

When sssd is in use, and a configured I/O plugin fails to initialize,
sudo segfaults/dumps core with a use-after-free and/or double-free
violation.

This is caused by sudo_sss_close() being called multiple times (via
various code paths, e.g. sudoers_policy_check -> sudoers_policy_main ->
sudo_sss_close; or policy_check -> sudo_fatalx_nodebug_v1 -> do_cleanup
-> sudoers_cleanup), which frees nss->handle but does not set the
pointer to NULL.

Output is as follows:

$ sudo -i
sudo: error initializing I/O plugin ngcp_plugin
*** Error in `sudo': double free or corruption (!prev):
0x560e35fda750 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7f1d2fc15bfb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7f1d2fc1bfc6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7780e)[0x7f1d2fc1c80e]
/usr/lib/sudo/sudoers.so(+0x20bcd)[0x7f1d2e090bcd]
/usr/lib/sudo/sudoers.so(+0x1a7f6)[0x7f1d2e08a7f6]
/usr/lib/sudo/libsudo_util.so.0(+0x4e6d)[0x7f1d3014ce6d]
/usr/lib/sudo/libsudo_util.so.0(sudo_fatalx_nodebug_v1+0xa3)[0x7f1d3014d2b3]
sudo(+0x5521)[0x560e345f6521]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f1d2fbc52e1]
sudo(+0x671a)[0x560e345f771a]

Valgrind reports:

# valgrind ./sudo -i
==45182== Memcheck, a memory error detector
==45182== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et
al.
==45182== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for
copyright info
==45182== Command: ./sudo -i
==45182== 
sudo: error initializing I/O plugin ngcp_plugin
==45182== Invalid read of size 8
==45182==at 0x6F36BBB: sudo_sss_close (sssd.c:482)
==45182==by 0x6F307F5: sudoers_cleanup (sudoers.c:1193)
==45182==by 0x548FE6C: do_cleanup (fatal.c:61)
==45182==by 0x54902B2: sudo_fatalx_nodebug_v1 (fatal.c:86)
==45182==by 0x10D520: policy_check (sudo.c:1333)
==45182==by 0x10D520: main (sudo.c:261)
==45182==  Address 0x6328aa0 is 32 bytes inside a block of size 80
free'd
==45182==at 0x4C2CDDB: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==45182==by 0x6F36BCC: sudo_sss_close (sssd.c:483)
==45182==by 0x6F3282A: sudoers_policy_main (sudoers.c:528)
==45182==by 0x6F2B9EE: sudoers_policy_check (policy.c:754)
==45182==by 0x10CED1: policy_check (sudo.c:1337)
==45182==by 0x10CED1: main (sudo.c:261)
==45182==  Block was alloc'd at
==45182==at 0x4C2BBAF: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==45182==by 0x6F36C50: sudo_sss_open (sssd.c:388)
==45182==by 0x6F3108B: sudoers_policy_init (sudoers.c:192)
==45182==by 0x6F2BEC6: sudoers_policy_open (policy.c:679)
==45182==by 0x10D073: policy_open (sudo.c:1283)
==45182==by 0x10D073: main (sudo.c:225)
==45182== 
==45182== Invalid read of size 1
==45182==at 0x4015571: _dl_close (dl-close.c:817)
==45182==by 0x400F643: _dl_catch_error (dl-error.c:187)
==45182==by 0x56A0530: _dlerror_run (dlerror.c:163)
==45182==by 0x569FFDE: dlclose (dlclose.c:46)
==45182==by 0x6F36BC3: sudo_sss_close (sssd.c:482)
==45182==by 0x6F307F5: sudoers_cleanup (sudoers.c:1193)
==45182==by 0x548FE6C: do_cleanup (fatal.c:61)
==45182==by 0x54902B2: sudo_fatalx_nodebug_v1 (fatal.c:86)
==45182==by 0x10D520: policy_check (sudo.c:1333)
==45182==by 0x10D520: main (sudo.c:261)
==45182==  Address 0x6328f54 is 980 bytes inside a block of size 1,209
free'd
==45182==at 0x4C2CDDB: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==45182==by 0x4014D95: _dl_close_worker (dl-close.c:747)
==45182==by 0x401558D: _dl_close (dl-close.c:840)
==45182==by 0x400F643: _dl_catch_error (dl-error.c:187)
==45182==by 0x56A0530: _dlerror_run (dlerror.c:163)
==45182==by 0x569FFDE: dlclose (dlclose.c:46)
==45182==by 0x6F36BC3: sudo_sss_close (sssd.c:482)
==45182==by 0x6F3282A: sudoers_policy_main (sudoers.c:528)
==45182==by 0x6F2B9EE: sudoers_policy_check (policy.c:754)
==45182==by 0x10CED1: policy_check (sudo.c:1337)
==45182==by 0x10CED1: main (sudo.c:261)
==45182==  Block was alloc'd at
==45182==at 0x4C2DBC5: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==45182==by 0x400B215: _dl_new_object (dl-object.c:75)
==45182==by 0x400587C: _dl_map_object_from_fd (dl-load.c:1000)
==45182==by 0x400874B: _dl_map_object (dl-load.c:2470)
==45182==by 0x4013B13: dl_open_worker (dl-open.c:237)
==45182==by 0x400F643: _dl_catch_error (dl-error.c:187)
==45182==by 0x4013608: _dl_open (dl-open.c:660)
==45182==by 0x569FEE8: dlopen_doit (dlopen.c:66)
==45182==by 0x400F643: _dl_catch_error (dl-error.c:187)
==45182==by 0x56A0530: _dlerror_run (dlerror.c:163)
==45182==by 0x569FF81: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==45182==by 0x6F36C6D: sudo_sss_open (sssd.c:395)
==45182== 
...


Patch is as follows:

--- sudo-1.8.19p1.orig/plugins/sudoers/sssd.c
+++ sudo-1.8.19p1/plugins/sudoers/sssd.c
@@ 

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

[Bernhard Übelacker]

Hello Osama Nasr,


> Thanks a lot for your help, but actually i don't need that app, I just
> was reporting this bug.

I am also not involved in packaging konqueror, just tried to collect
some more information, for the maintainers to work with.


> Do you need me to install proprietary drivers and test it ?

I think this would gain not much for this bug, it would just be
a workaround, but as far as other applications are working for you
this might not be neccessary.


What might be interesting would be a backtrace with debug symbols
installed like described in [1].

Following steps should produce such a file that might be useful
for the maintainer and could be forwarded to this bug:

- Install packages: gdb konqueror-dbgsym libgl1-mesa-dri-dbgsym

- Start konqueror as usual

- Attach gdb to it with this command line:
script -a gdb_konqueror_$(date +%Y-%m-%d_%H-%M-%S).log -c "gdb -q -batch 
-ex 'set width 0' -ex 'set pagination off' -ex 'cont' -ex 'display/i $pc' -ex 
'bt' -ex 'info share' -ex 'info reg' -ex 'bt full' --pid $(pidof konqueror)"

- Then open the ususal webpage to trigger the crash.


Kind regards,
Bernhard


[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Bug#928031: Preseed on buster have problems

[Cyril Brulebois]

Thanks for the follow-up.

Jose M Calhariz  (2019-04-26):
> On Fri, Apr 26, 2019 at 03:09:31PM +0200, Cyril Brulebois wrote:
> > Jose M Calhariz  (2019-04-26):
> > > I am doing this report because I wanted test preseed on buster.
> > > I found some problems, by order of priority:
> > > 
> > >   - The installation using preseed, ends with an incomplete
> > > /etc/apt/sources.list that prevents to install more software after
> > > the instalation.
> > 
> > Can you please share more details about that?
> 
> This is the /etc/apt/sources.list that I get when using preseed:
> 
> # 
> 
> # deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 
> NETINST 20190411-22:32]/ buster main
> 
> deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 
> NETINST 20190411-22:32]/ buster main

This seems consistent with your settings (excerpt from [1]):

# Uncomment this if you don't want to use a network mirror.
d-i apt-setup/use_mirror boolean false
# Select which update services to use; define the mirrors to be used.
# Values shown below are the normal defaults.
d-i apt-setup/services-select multiselect
#d-i apt-setup/security_host string security.debian.org

 1. http://web.ist.utl.pt/ist24403/preseed.cfg

since apt-setup/use_mirror=false means the cdrom: URI will be kept and
no network mirror is to be used?

> > >   - The text installer show a black screen, I need to use "fb=false".
> > 
> > We would probably need to know more about your hardware here.
> 
> Right, I missed that I am using virtio as display, my command line is:
> 
> kvm -m 4096 -localtime -drive file=debian.qcow2,if=virtio -usbdevice 
> tablet -k en-gb -vga virtio -cdrom 
> /srv/software/debian-buster-DI-rc1-amd64-netinst.iso -boot d

Hopefully somebody else will pick up this specific part.


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


signature.asc
Description: PGP signature

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

[Xavier]

Le 25/04/2019 à 15:35, Xavier Guimard a écrit :
> 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

node-express builds well with upstream tests enabled and node-fresh
0.2.0-2 (see
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/arm64/node-express.html)

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

[Xavier]

Le 26/04/2019 à 17:41, Xavier a écrit :
> Le 25/04/2019 à 15:35, Xavier Guimard a écrit :
>> 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
> 
> node-express builds well with upstream tests enabled and node-fresh
> 0.2.0-2 (see
> https://tests.reproducible-builds.org/debian/rb-pkg/experimental/arm64/node-express.html)

NB: test timeout is too short, so build2 failed sometimes.

Bug#928031: Preseed on buster have problems

[Jose M Calhariz]

On Fri, Apr 26, 2019 at 03:09:31PM +0200, Cyril Brulebois wrote:
> Hi Jose,
> 
> Jose M Calhariz  (2019-04-26):
> > I am doing this report because I wanted test preseed on buster.  I
> > found some problems, by order of priority:
> > 
> >   - The installation using preseed, ends with an incomplete
> > /etc/apt/sources.list that prevents to install more software after
> > the instalation.
> 
> Can you please share more details about that?

This is the /etc/apt/sources.list that I get when using preseed:

# 

# deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 
NETINST 20190411-22:32]/ buster main

deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 NETINST 
20190411-22:32]/ buster main



> 
> >   - The text installer show a black screen, I need to use "fb=false".
> 
> We would probably need to know more about your hardware here.

Right, I missed that I am using virtio as display, my command line is:

kvm -m 4096 -localtime -drive file=debian.qcow2,if=virtio -usbdevice 
tablet -k en-gb -vga virtio -cdrom 
/srv/software/debian-buster-DI-rc1-amd64-netinst.iso -boot d


> 
> >   - By default the installer is still calling
> > http://$host/d-i/stretch/preseed.cfg instead of
> > http://$host/d-i/buster/preseed.cfg
> 
> Good catch, I've just pushed a new preseed upload with this change:
>   
> https://salsa.debian.org/installer-team/preseed/commit/10daa285644dc8061d65da60e28bd11000c893c3
> 
> I've also noted locally to add this package to a post-release checklist,
> so that it has higher chances of getting an update next time.
> 
> 
> Cheers,


Kind regards
Jose M Calhariz


-- 
--
Uma consciência que já foi comprada uma vez pode ser
comprada de novo.
-- Norbert Wiener


signature.asc
Description: PGP signature

Bug#770064: Good day

[John Albert]

Dear Friend,
I am a lawyer by profession here in my country Togo in west Africa,
one of my client from your country who worked with shell development
company here in Republic of Togo. My client, his wife and their only
daughter were involved in auto crash here in my country. I decided to
contact you so that the $10.5M Dollars he left behind in a bank here
will be transferred to your bank account immediately. For more details
(johnalbertt...@gmail.com)
Best regards.
Barrister Albert John

Bug#928038: libfaac-dev: faac.h refers to type int32_t without defining it

[Juhani Numminen]

Package: libfaac-dev
Version: 1.29.9.2-2
Severity: important

This was originally reported to Ubuntu,
https://bugs.launchpad.net/ubuntu/+source/faac/+bug/1825557.
It also affects Debian.

Quoting Henrik Storner
> This simple program does not compile:
> 
> #include 
> int main(int argc, char **argv) { return 0; }
>
> /usr/include/faac.h:82:51: error: unknown type name ‘int32_t’
>  int FAACAPI faacEncEncode(faacEncHandle hEncoder, int32_t * inputBuffer, 
> unsigned int samplesInput,
>
> I think faac.h is missing an
>
> #include 
>
> to define the system datatypes.


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

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

Versions of packages libfaac-dev depends on:
ii  libfaac0  1.29.9.2-2

libfaac-dev recommends no packages.

libfaac-dev suggests no packages.

-- no debconf information

Bug#812609: tracker.debian.org: wrong versioned links for security versions

[Salman Mohammadi]

On Mon, 25 Jan 2016 16:43:38 +0100 Ricardo Mones  wrote:
>
> The links to .dsc file wich appear on versioned links panel for security
> versions are using httpredir.d.o, which always gives 40x errors for those
> package versions. Example: https://tracker.debian.org/pkg/claws-mail
> (3.8.1-2+deb7u1 and 3.11.1-3+deb8u1 dsc links)
>

Dear Recardo,

I couldn't reproduce this bug in the package that you have mentioned.
Are there any other packages that have this issue?

Bug#927901: unblock: lucene-solr/3.6.2+dfsg-19

[Markus Koschany]

Control: tags -1 - moreinfo

Am 24.04.19 um 23:08 schrieb Niels Thykier:
[...]
> Hi,
> 
> Thanks for working to improve buster.
> 
> I suspect this change is missing an "rm_conffile" for this misplaced
> configuration file (everything in /etc is by default tagged as a
> conffile for anything built with debhelper).  Could you please have a
> look at that and ensure this part is handled correctly?
> 
> (otherwise, I think the changes look good)
> 
> Thanks,
> ~Niels

Hi Niels,

thanks, you are right. I have uploaded a new revision, -20, that removes
the obsolete conf file with solr-tomcat.maintscript now.

Regards,

Markus
diff -Nru lucene-solr-3.6.2+dfsg/debian/changelog 
lucene-solr-3.6.2+dfsg/debian/changelog
--- lucene-solr-3.6.2+dfsg/debian/changelog 2019-04-19 00:39:36.0 
+0200
+++ lucene-solr-3.6.2+dfsg/debian/changelog 2019-04-25 16:39:14.0 
+0200
@@ -1,3 +1,10 @@
+lucene-solr (3.6.2+dfsg-20) unstable; urgency=medium
+
+  * Team upload.
+  * Remove now obsolete solr-permissions.conf in 
/etc/systemd/system/tomcat9.d/.
+
+ -- Markus Koschany   Thu, 25 Apr 2019 16:39:14 +0200
+
 lucene-solr (3.6.2+dfsg-19) unstable; urgency=medium
 
   * Team upload.
diff -Nru lucene-solr-3.6.2+dfsg/debian/solr-tomcat.maintscript 
lucene-solr-3.6.2+dfsg/debian/solr-tomcat.maintscript
--- lucene-solr-3.6.2+dfsg/debian/solr-tomcat.maintscript   1970-01-01 
01:00:00.0 +0100
+++ lucene-solr-3.6.2+dfsg/debian/solr-tomcat.maintscript   2019-04-25 
16:39:14.0 +0200
@@ -0,0 +1,2 @@
+rm_conffile /etc/systemd/system/tomcat9.d/solr-permissions.conf 3.6.2+dfsg-20~
+


signature.asc
Description: OpenPGP digital signature

Bug#767239:

[Kley Raymond]

Grüße, ich bin Kley Raymond aus Großbritannien. Ich brauche Ihre dringende
Hilfe in Bezug auf die Gelder meines verstorbenen Kunden, die denselben
Namen bei sich tragen.

Bug#859509:

[Weller, Lennart]

I can confirm this bug still exists with the most recent stretch
version as well as the testing version of buster rc1.

I ran into this issue when I was provisioning a HP DL380p G8 with a HP
Smart Array P420i RAID Controller. I was provisioning the machine with
a live boot initrd + kernel. Both OS versions with firmware cpio.gz
appended to the initramfs. The RAID controller is configured to only
expose a single device (showing up as /dev/sda in the installer shell).

Manually formatting the machine in the installer was not an option and
the installer cannot be continue at this point unless you manually
partition the drive in the shell.

Provisioning Ubuntu 18.04 and 19.04 on the same machine worked just
fine with the exact same method.

Bug#923181: Please add support for reporting mouse button presses to console programs which support mouse trackingo

[Bill Allombert]

On Thu, Apr 04, 2019 at 06:52:04PM +, Daniel Abrecht wrote:
> On 22/03/2019 21.33, Bill Allombert wrote:
> >> I'm not sure what the best course of action is. Some possibilities are:
> >>  * If it isn't too much of a problem, we could just leave it how it is.
> >>  * We could disable selections while mouse tracking is active
> > 
> > If this can be done on a per tty basis, this might be the best course of
> > action.
> 
> Ok, I've now created patch for this. This time, I've based the patch on
> the current master branch (commit
> c12a8c2d0cf72a340b13b00e6d4b98bfed57ce01) of the salsa.debian.org git repo.

This version seems to work much better when reporting.
Thanks!

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#928037: mailcap(5): please document security considerations about %-escapes

[Marriott NZ]

Package: mime-support
Version: 3.60
Severity: normal

Dear Maintainer,

Please clarify how %-escapes in mailcap rules should be handled, because 
RFC-1524 is unclear about it, and this is leading to differences in 
implementations and security problems.

For example in gnu mailutils, you can do shell command injection form email 
headers (bug #927836[1]):

# mailcap rule (shipped with debian):
text/html; /usr/bin/w3m -I %{charset} -dump -T text/html %s

# malicious header:
Content-Type: text/html; charset="$(rm -rf ~/*)"

In s-nail, they are planning[2] to pre-quote %-escapes expansions (kind of like 
bash printf %q), and they are telling users not to add quotes around %-escapes 
in mailcap rules because they would interfere with the automatic quotes in the 
expansion.
This is a good solution, but quoted %-escapes in debian mailcap rules are 
common, and they would break, for example:

text/plain; less '%s'; needsterminal

Please note that no amount of quotes in a mailcap rule can prevent command 
injection (for example -I '%{charset}' could be exploited with charset="' & rm 
-rf ~/* '").

RFC-1524 is unclear:
> The two characters "%s", if used, will be replaced by the name
> of a file for the actual mail body data. [...] Furthermore, any
> occurrence of "%t" will be replaced by the content-type and
> subtype specification. [...] A literal % character may be quoted
> as \%. Finally, named parameters from the Content-type field may
> be placed in the command execution line using "%{" followed by
> the parameter name and a closing "}" character. The entire
> parameter should appear as a single command line argument,
> regardless of embedded spaces.

The command is run by the bourne shell, which takes it as a single lump of 
code, therefore the only way to fulfill that last condition ("The entire 
parameter should appear as a single command line argument") is to pre-quote the 
replacement (as s-nail is planning to do).
But that doesn't seem to be the common practice (well, my knowledge of the 
common practice is limited because I managed to avoid mailcap since now).

Perhaps a less breaking solution would be to require implementers to filter out 
*any* shell-special punctuation from the replacement of any mailcap %-escape.

Anyway, I think having a better definition here would provide a needed 
guideline for programs using mailcap.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927836
[2] 
https://manpages.debian.org/unstable/s-nail/s-nail.1.en.html#The_Mailcap_files

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

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

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  bzip2 1.0.6-8.1
ii  file  1:5.30-1+deb9u2
ii  xz-utils  5.2.2-1.2+b1

mime-support suggests no packages.

-- no debconf information

Bug#928036: geary: please provide virtual package mail-reader

[Jonas Smedegaard]

Package: geary
Version: 0.12.4-4
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Geary is missed when looking for mail-reader packages.

Please add Provides: mail-reader

- - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlzDF2cACgkQLHwxRsGg
ASEH4g/+PXZvmh0j2xBxhxLns3gwcnQ2g/4Gz0KOSoEm6c0tq5J30tNXlSB8ysV5
hiWdn+bFYYcwsAYNw9DSIGU5e6CYy5u/8dGxCrMOh9vKqe41Jxskfvkv1Zxz/KTq
G3waAiqdlboDXiVXWQekw18EUnanPCCa4jxIQcZhkmFBS3KdWiyg0Wp2Nt5FSDoc
Pgy6j2MApbDytiXUaKJR/QLz2bp2yi7XPKUnAgInxNs5L7MLZDRhrWZ7ZzVM76C2
jo6Q3FVhSpKlHAgzAys9VnET80i/nWD58z6FJ1rqxagbrZ9H808N1/hzld4Lfz5u
0krpNlgEYLghCOBo1DkIuwrl6If5svn9qYq6z2Qs7c8uPFDnz9ocuIqSeOF/2yJe
xO1ncEqpKYsSFTB0Fnnco2ixVtPiMy/spW8ke81zNxMkygwBCTq4Z8Bx6Ylxdkh5
kBAxcRiQCNwjqRbxZwPuB07jRhgKkPV3bCHfTNM2vFz9v5fHtJPj3u4basYFYKEF
szeyESYKXrgALJBGz+j8ArmB82gdc++/cv3pfH3YPh3lWWtsrq2XkC+AgJkUOKc0
nG4YwidT7eiGnedx0oxgQwzO1uR1dj4vDPHwn7puSGXkeSFJKVZRtM+SXgNplqQo
vojX8jq20BgYJ+Y/K711emFDaFQ398M/DkqxPOw3c+hhqm20+Dc=
=N8xb
-END PGP SIGNATURE-

Bug#928035: gcc-9 patches no longer applies

[Helmut Grohne]

Package: cross-gcc-dev
Version: 226
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

This bug is the second half of #925950. The bug was fixed for gcc-8, but
not for gcc-9. Filing a new one at non-rc severity now. The fix is:

sed -i -e 's/\(`TARGET\))/\1/' patches/gcc-9/*-now-depend-on-cpp-*

Helmut

Bug#875643: firefox-esr: Can't specify external viewer like /usr/bin/emacsclient

[Stefan Monnier]

Ping?


Stefan


Stefan Monnier  writes:

> Ping?
>
> Still seems to be the case with version 52.8.0
>
>
> Stefan
>
>
> Stefan  writes:
>
>> Package: firefox-esr
>> Version: 52.3.0esr-2
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> In older versions of Firefox, the dialog box which asked me whether
>> I want to downoload the file or pass it to some external viewer
>> let me choose the viewer via a file-selector, so I could very easily
>> specify a viewer such as /usr/bin/emacsclient.
>>
>> Now I can't see to be able to do this any more.  All I can do is choose
>> among a bunch of applications listed with their icons, emacsclient
>> is not among them and I can't see any way to specify the application
>> I want by giving its full file name.  This severely restricts the
>> choice of external viewer for some file types.

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

[積丹尼 Dan Jacobson]

> "JAK" == Julian Andres Klode  writes:
JAK> Enabling that for non-interactive users can break stuff, so I'm not sure 
we want to change this.

Well at least have a /etc/apt/apt.conf.d variable we can set to send
them to STDERR instead of nowhere. That way if we break something it
would be our own fault, not yours. Thanks.

Bug#928034: lightdm: acknowledge of shutdown is not visible immediately

[Vincent Lefevre]

Package: lightdm
Version: 1.26.0-4
Severity: minor

I have the following issue with a machine using sysvinit (I don't
think that sysvinit is the culprit, just that it makes the problem
visible). This has occurred for several months now (perhaps after
the upgrade from 1.18.3 to 1.26, but I'm not sure).

When I click on "Restart", I get a dialog box to confirm, which I do,
but then nothing seems to occur. I had the habit to do the same thing
again, which had the effect to effectively restart immediately. So,
I thought that the first Restart was not taken into account.

But what actually occurs is that the shutdown starts, and I can see
the end of the shutdown once lightdm is killed as a consequence of
the shutdown.

So the fact that nothing seems to occur is bad information given
to the user. I suspect that this issue does not occur with systemd
because the shutdown with systemd is much faster as parallelized
(though I'm wondering what would occur is specific shutdown
dependencies would temporarily block it before lightdm is killed).

Shouldn't lightdm quit when the shutdown is started? This would
probably solve this issue and allow the user to see the first
shutdown messages. Or would there be drawbacks?

Alternatively, lightdm (or the greeter?) could display a message
saying that a shutdown was initiated, but if something blocks the
shutdown, the user would not be able to see that.

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

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

Versions of packages lightdm depends on:
ii  adduser3.118
ii  consolekit 0.4.6-6
ii  dbus   1.12.12-1
ii  debconf [debconf-2.0]  1.5.71
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-9
ii  libgcrypt201.8.4-5
ii  libglib2.0-0   2.58.3-1
ii  libpam0g   1.3.1-5
ii  libxcb11.13.1-2
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.6-1
ii  lsb-base   10.2019031300

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
pn  accountsservice  
ii  upower   0.99.10-1
ii  xserver-xephyr   2:1.20.4-1

-- Configuration Files:
/etc/lightdm/lightdm.conf changed:
[LightDM]
[Seat:*]
greeter-hide-users=false
[XDMCPServer]
[VNCServer]


-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm

Bug#928033: Inconsistent number of newlines at the end of "show": 0, 1, 2

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.8.11-7
Severity: minor

If a user does
$ aptitude show package1 package2...
and one of them is a virtual package, it "glues itself onto the header of
the following package", because it is missing its blank line at bottom.

# aptitude show twitter-bootstrap libtwitter-api-perl | colrm 14 | head
Package: twit
State: not a
Provided by:
Package: libt
Version: 1.00
State: not in
Priority: opt
Section: perl
Maintainer: D
Architecture:

So it takes a skilled eye to realize that they are actually looking at
two packages. So please add the newline.

Let's look at the newline situation at the bottom of various packages listings,

# for i in tw... ; do echo = $i; aptitude show $i|nl -b a|tail -n 3; done
= twittering-mode
34  Homepage: http://twmode.sf.net/
35
36
= twitterwatch
19  Homepage: https://github.com/chaica/twitterwatch
20
21
= twitter-bootstrap
 1  Package: twitter-bootstrap
 2  State: not a real package
 3  Provided by: libjs-twitter-bootstrap (2.0.2+dfsg-10)
= libtwitter-api-perl
38  Homepage: https://metacpan.org/release/Twitter-API
39
40
= libnet-twitter-perl
23  Homepage: https://metacpan.org/release/Net-Twitter
24  Tags: devel::lang:perl, devel::library, implemented-in::perl, 
role::shared-lib, web::microblog
25

In fact from our small sample we see if there are no e.g., Tags, an
inconsistent second newline is appended to the bottom too!

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

[Charles Plessy]

Le Fri, Apr 26, 2019 at 07:49:28AM +0200, Basile Starynkevitch a écrit :
> 
> A big thanks for that interesting discussion. I still hope that
> /etc/mimes.type will eventually get improved.

Thanks to you as well / merci aussi / for requesting this change.  I
have added the mjs suffix to the existing application/javascript entry.
The package will be uploaded after the release of Buster.

Have a nice week-end,

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

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

[Christoph Anton Mitterer]

On Fri, 2019-04-26 at 09:26 +, Holger Levsen wrote:
> I'm not really impressed by this fix either, cause it will also cause
> breakage in xx months when the next stable arrives...

Admittedly I haven't read the code in too much detail, but conceptually
I'd expect the following:
- either d-s-s is not so much dependant on the debian version, then
this should simply not cause such bad failure (but rather give a
warning or so)

- or it in fact is strongly dependant (either semantically or
technically), but then a Breaks/Conflichts/whatever is really justified
as it would strongly need the "older" version of Debian.


> IMO the code should deal more gracefully with this situation, but
> such a
> change would probably be to invasive now.
At least the above with the deps would probably solve the problem for
people upgrading to buster,... cause I guess they could still be hit by
base-files being upgraded first and then their old d-s-s failing
immediately.


Cheers,
Chris.

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

[Holger Levsen]

On Fri, Apr 26, 2019 at 03:31:42PM +0200, Christoph Anton Mitterer wrote:
> Oh and btw: it still does fail on upgrade for systems which have the
> old base-files and the old d-s-s, namely when apt upgrades base-files
> before.

I think I would prefer a new bug for this. Also suggestions how to fix
this are welcome.


-- 
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#927450: fixed in debian-security-support 2019.04.25

[Christoph Anton Mitterer]

Oh and btw: it still does fail on upgrade for systems which have the
old base-files and the old d-s-s, namely when apt upgrades base-files
before.

Cheers,
Chris.

Bug#928031: Preseed on buster have problems

[Cyril Brulebois]

Hi Jose,

Jose M Calhariz  (2019-04-26):
> I am doing this report because I wanted test preseed on buster.  I
> found some problems, by order of priority:
> 
>   - The installation using preseed, ends with an incomplete
> /etc/apt/sources.list that prevents to install more software after
> the instalation.

Can you please share more details about that?

>   - The text installer show a black screen, I need to use "fb=false".

We would probably need to know more about your hardware here.

>   - By default the installer is still calling
> http://$host/d-i/stretch/preseed.cfg instead of
> http://$host/d-i/buster/preseed.cfg

Good catch, I've just pushed a new preseed upload with this change:
  
https://salsa.debian.org/installer-team/preseed/commit/10daa285644dc8061d65da60e28bd11000c893c3

I've also noted locally to add this package to a post-release checklist,
so that it has higher chances of getting an update next time.


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


signature.asc
Description: PGP signature

Bug#928031: Preseed on buster have problems

[Jose M Calhariz]

Package: installation-reports

Boot method: CD
Image version: debian-buster-DI-rc1-amd64-netinst.iso
Date: 2019/04/26 12:00

Machine: KVM on Debian stretch
Partitions: Used auto partition into 1 big partition for data


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[E]

Comments/Problems:

I am doing this report because I wanted test preseed on buster.  I
found some problems, by order of priority:

  - The installation using preseed, ends with an incomplete
/etc/apt/sources.list that prevents to install more software after
the instalation.

  - The text installer show a black screen, I need to use "fb=false".
  
  - By default the installer is still calling
http://$host/d-i/stretch/preseed.cfg instead of
http://$host/d-i/buster/preseed.cfg


To perform my tests, and to reproduce the problems I am using the
following line on the installer:

install fb=false auto url=http://web.ist.utl.pt/ist24403/preseed.cfg

Kind regards
Jose M Calhariz

-- 

Uma consciência que já foi comprada uma vez pode ser
comprada de novo.
-- Norbert Wiener


hardware-summary.gz
Description: application/gzip


syslog.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#904309: appropriate priority for bugs under Wayland?

[Jonathan Dowland]

severity 904309 normal
thanks

Folks, I've seen a few occurences now of bugs like this which are being given
RC severity because Wayland is currently the default desktop technology for
Buster. The consequence of this is that the software (here tilda, elsewhere
synaptic, and perhaps others) are at risk of being dropped from Buster
entirely due to incompatibility under Wayland, despite working fine under X.

I'm not sure that this is fair or the right way to address issues of Wayland
compatibility with other (longer established) software. I'm directing this at
-release to ask the Release Team whether they have a position on the matter.
Thanks!

Related I'm not sure that Wayland is a suitable choice for the default desktop
technology yet either (see Bug #927667 for discussion of that, as well as a
subset of these bugs[1]). Please direct any thoughts on *that* to #927667
rather than here.

[1] 
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=wayland=pkg-gnome-maintainers%40lists.alioth.debian.org


Best wishes

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#880199: Packaging blockers

[Cirujano Cuesta, Silvano]

Hi,

> 2019/01/09 06:54:27 Build-Dependency "github.com/opencontainers/image-tools"
> is not yet available in Debian, or has not yet been converted to use
> XS-Go-Import-Path in debian/control
> The latter one is #900900, the first two don't seem to be worked on yet.

The build dependency "github.com/opencontainers/image-tools" is being declared 
as "golang-github-opencontainers-image-tools-image-dev" [1], right?

But the mentioned ITP Bug #900900 [2] is not providing any package under that 
name [3]...
And I cannot find any package, ITP or RFP providing 
"golang-github-opencontainers-image-tools-image-dev".

I'm really puzzled... Am I missing something?

  Silvano

[1] 
https://salsa.debian.org/go-team/packages/skopeo/blob/master/debian/control#L13
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900900
[3] 
https://salsa.debian.org/go-team/packages/oci-image-tools/blob/master/debian/control

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

[Santiago Vila]

Thanks for keeping this open.

Packages should really not contain "time-bombs" like this.

On Fri, 26 Apr 2019, Holger Levsen wrote:

> control: severity -1 normal
> control: retitle -1 debian-security-support needs to be adapted to each new 
> Debian release
> thanks
> 
> On Fri, Apr 26, 2019 at 12:34:44AM +0200, Christoph Anton Mitterer wrote:
> > As if I wouldn't have written it before... o.O
> 
> talk is cheap, show me the code ;)

Just make the error to be non-fatal instead of exiting with error and
breaking the whole packaging system.

Only as a proof of concept, I believe the patch below would be better
than nothing, but of course you might want to do it with gettext and
debconf to do it properly.

Thanks.

--- a/check-support-status.in
+++ b/check-support-status.in
@@ -22,7 +22,9 @@ fi
 
 if [ "$DEBIAN_VERSION" -lt "$DEB_LOWEST_VER_ID" ] || [ "$DEBIAN_VERSION" -gt 
"$DEB_NEXT_VER_ID" ] ; then
 eval_gettext "Unknown DEBIAN_VERSION \$DEBIAN_VERSION. Valid values from 
\$DEB_LOWEST_VER_ID and \$DEB_NEXT_VER_ID"; echo
-exit 1
+echo "Warning: This package does nothing with the current installed 
version of Debian"
+sleep 5
+exit 0
 fi
 
 LIST=

Bug#922842: ITP: golang-github-containers-image -- Work with containers' images

[Cirujano Cuesta, Silvano]

Build is failing. If I'm right, fetching the vendor components is missing. But 
I don't know how to get it in...

BTW, please make sure that your packaging is not affected by issue 620 [1] of 
containers/image. The environment where I'm testing is, on purpose, a pristine 
Debian installation where GOBIN is not part
of PATH.

[1] https://github.com/containers/image/issues/620

  Silvano

This is the error message:

dh_auto_build -O--buildsystem=golang -- -tags "containers_image_ostree_stub"
cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src\"
 -asmflags=all=\"-trimpath=/debian-packages/golang-
github-containers-image/obj-x86_64-linux-gnu/src\" -v -p 4 -tags 
containers_image_ostree_stub github.com/containers/image 
github.com/containers/image/copy github.com/containers/image/directory
github.com/containers/image/directory/explicitfilepath 
github.com/containers/image/docker github.com/containers/image/docker/archive 
github.com/containers/image/docker/daemon
github.com/containers/image/docker/policyconfiguration 
github.com/containers/image/docker/reference 
github.com/containers/image/docker/tarfile github.com/containers/image/image
github.com/containers/image/internal/testing/explicitfilepath-tmpdir 
github.com/containers/image/internal/testing/mocks 
github.com/containers/image/internal/tmpdir github.com/containers/image/manifest
github.com/containers/image/oci github.com/containers/image/oci/archive 
github.com/containers/image/oci/internal github.com/containers/image/oci/layout 
github.com/containers/image/openshift
github.com/containers/image/ostree 
github.com/containers/image/pkg/blobinfocache 
github.com/containers/image/pkg/compression 
github.com/containers/image/pkg/docker/config
github.com/containers/image/pkg/strslice 
github.com/containers/image/pkg/sysregistries 
github.com/containers/image/pkg/sysregistriesv2 
github.com/containers/image/pkg/tlsclientconfig
github.com/containers/image/signature github.com/containers/image/storage 
github.com/containers/image/tarball github.com/containers/image/transports
github.com/containers/image/transports/alltransports 
github.com/containers/image/types github.com/containers/image/version
src/github.com/containers/image/signature/mechanism_gpgme.go:11:2: cannot find 
package "github.com/mtrmac/gpgme" in any of:
/usr/lib/go-1.11/src/github.com/mtrmac/gpgme (from $GOROOT)

/debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src/github.com/mtrmac/gpgme
 (from $GOPATH)
src/github.com/containers/image/openshift/openshift-copies.go:23:2: cannot find 
package "k8s.io/client-go/util/homedir" in any of:
/usr/lib/go-1.11/src/k8s.io/client-go/util/homedir (from $GOROOT)

/debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src/k8s.io/client-go/util/homedir
 (from $GOPATH)
dh_auto_build: cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src\"
 -asmflags=all=\"-trimpath=/debian-
packages/golang-github-containers-image/obj-x86_64-linux-gnu/src\" -v -p 4 
-tags containers_image_ostree_stub github.com/containers/image 
github.com/containers/image/copy
github.com/containers/image/directory 
github.com/containers/image/directory/explicitfilepath 
github.com/containers/image/docker github.com/containers/image/docker/archive
github.com/containers/image/docker/daemon 
github.com/containers/image/docker/policyconfiguration 
github.com/containers/image/docker/reference 
github.com/containers/image/docker/tarfile
github.com/containers/image/image 
github.com/containers/image/internal/testing/explicitfilepath-tmpdir 
github.com/containers/image/internal/testing/mocks 
github.com/containers/image/internal/tmpdir
github.com/containers/image/manifest github.com/containers/image/oci 
github.com/containers/image/oci/archive 
github.com/containers/image/oci/internal github.com/containers/image/oci/layout
github.com/containers/image/openshift github.com/containers/image/ostree 
github.com/containers/image/pkg/blobinfocache 
github.com/containers/image/pkg/compression
github.com/containers/image/pkg/docker/config 
github.com/containers/image/pkg/strslice 
github.com/containers/image/pkg/sysregistries 
github.com/containers/image/pkg/sysregistriesv2
github.com/containers/image/pkg/tlsclientconfig 
github.com/containers/image/signature github.com/containers/image/storage 
github.com/containers/image/tarball github.com/containers/image/transports
github.com/containers/image/transports/alltransports 
github.com/containers/image/types github.com/containers/image/version returned 
exit code 1
make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1

On Thu, 2019-02-21 at 06:49 -0500, Reinhard Tartler wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Reinhard Tartler 
> 
> * Package name: golang-github-containers-image
>   Version : 

Bug#782886: [git-buildpackage/master] import_dsc: Support upstream-vcs-tag

[Guido Günther]

tag 782886 pending
thanks

Date:   Fri Apr 26 13:44:27 2019 +0200
Author: Guido Günther 
Commit ID: 61757c03f0d728897e9b0cd66e313851122125bd
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=61757c03f0d728897e9b0cd66e313851122125bd
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=61757c03f0d728897e9b0cd66e313851122125bd

import_dsc: Support upstream-vcs-tag

Closes: #782886

  

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

[cyrille]

Of course. 

But that page relies on lot of folk remedies imho. So, I believe the best is to 
have some chat about it.

For examples:

1) "For multi-user systems or systems with lots of disk space, it's best to put 
/var, /tmp, and /home each on their own partitions separate from the / 
partition. "

In my experience of more than 10 years administrating Linux servers, creating 
separate /var and /tmp partitions always created more problems than it solved: 
For example, usually, applications crashes when they can't write their logs 
because there's no more space on the /var partition. So you usually end up with 
more downtime when creating a separate /var partition than putting everything 
in /.

(Note though that puttin everything in / may makes the problem more difficult 
to solve if you can't access your server remotely as root - because in such 
case you don't directly have access to the 5% disk space reserved for root-. So 
you might not be able to log in remotely in such case)

OTOH, putting the /home folder on a separate partition still makes some sense 
to me.

2) "You might need a separate /usr/local partition if you plan to install many 
programs that are not part of the Debian distribution."

Why?

3) "Often, putting /tmp on its own partition, for instance 20–50MB, is a good 
idea"

20-50MB!?! seriously?!?

4) The paragraph related to the swap don't really makes sense to me. For me the 
rule of thumb is that people should try not to use swap (ie: by putting enough 
RAM in you system) because using swap usually slows down your system to a 
crawl. That being said, I've never tried to run a system without swap. So, my 
point is not to say that a swap partition is not needed. Though, the figures in 
this paragraph (eg: 256MB memory) seems to date from last century. Also my 
point about how using the swap slows down the system might not stand so well in 
these days of SSD drives...

5) "On some 32-bit architectures..."

Do we really need to speak about 32bits architectures on an amd64 targeted 
document? 

6) "As an example, an older home machine might have 32MB of RAM and a 1.7GB IDE 
drive on /dev/sda. There might be a 500MB partition for another operating 
system on /dev/sda1, a 32MB swap partition on /dev/sda3 and about 1.2GB on 
/dev/sda2 as the Linux partition. "

Last century figures.

=

Summary: Here's my proposal for this page:

For new users, personal Debian boxes, home systems, and other single-user 
setups, a single / partition (plus swap) is probably the easiest, simplest way 
to go."

If your machine will be a mail server, you might want to make /var/mail a 
separate partition. If you are setting up a server with lots of user accounts, 
it's generally good to have a separate, large /home partition. In general, the 
partitioning situation varies from computer to computer depending on its uses.

For very complex systems, you should see the Multi Disk HOWTO (Old document 
though). This contains in-depth information, mostly of interest to ISPs and 
people setting up servers.

With respect to the issue of swap partition size, there are many views. 
However, your best bet is always to try to avoid your system to swap by putting 
enough RAM for your usage.

For an idea of the space taken by tasks you might be interested in adding after 
your system installation is complete, check Section D.2, “Disk Space Needed for 
Tasks”. 

Carsten Schoenert – Fri, 26. April 2019 10:03
> Hi,
> 
> Am 26.04.19 um 09:11 schrieb cyri...@bollu.be:
> > 
> > woaw, this page is severely outdated!
> 
> a patch, or at least a rephrased text with the required updates and
> changes would be more helpful.
> 
> -- 
> Regards
> Carsten Schoenert

Bug#928022: ITP: modernize -- Modernizes Python code for eventual Python 3 migration

[Jonas Smedegaard]

Quoting Benjamin Drung (2019-04-26 13:20:31)
> Am Freitag, den 26.04.2019, 13:11 +0200 schrieb Jonas Smedegaard:
> > Quoting Benjamin Drung (2019-04-26 12:15:51)
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Benjamin Drung 
> > > 
> > > * Package name: modernize
> > >   Version : 0.7
> > >   Upstream Author : Armin Ronacher
> > > * URL : https://pypi.org/project/modernize
> > > * License : BSD-3-clause plus some PSF-2
> > >   Programming Lang: Python
> > >   Description : Modernizes Python code for eventual Python 3
> > > migration
> > > 
> > > This library is a very thin wrapper around lib2to3 to utilize it 
> > > to make Python 2 code more modern with the intention of eventually 
> > > porting it over to Python 3.
> > > 
> > > The source will produce the binary packages modernize and 
> > > python3-libmodernize. This package is a dependency for 
> > > salt-pylint, which I intent to package.
> > > 
> > > I plan to maintain that package as part of the Debian Python 
> > > Modules Team.
> > 
> > Please pretty please name this as python-modernize or modernize- 
> > python - unless the plan is to extend to cover perl5-to-perl6 and 
> > Haskell-to- Rust or similar.
> 
> Are there other tools named modernize or do you consider 'modernize' 
> to be too generic?

The latter.  Sorry I wasn't clear about that in my previous post.


 - 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

Bug#928021: opendnssec-enforcer: AllowExtraction should be supported but startup fails with it

[Timo Aaltonen]

On 26.4.2019 14.33, Mathieu Mirmont wrote:
> control: tags -1 +confirmed
> 
> On Fri, Apr 26, 2019 at 01:09:33PM +0300, Timo Aaltonen wrote:
>> While testing FreeIPA, I noticed that enforcer startup fails if conf.xml has 
>>  on it. The feature was forward-ported to 2.1 from 1.4, so 
>> it should work in theory but instead I get this on startup:
>>
>> /etc/opendnssec/conf.xml:11: element AllowExtraction: Relax-NG validity 
>> error : Element Repository has extra content: AllowExtraction
>> /etc/opendnssec/conf.xml:7: element Repository: Relax-NG validity error : 
>> Element RepositoryList has extra content: Repository
> 
> Hmm yeah. I can't imagine that this can have anything to do with the way
> the package is made. I'll have a look at the code and see if I can fix
> it myself (and send the patch upstream of course), otherwise I'll just
> report it upstream.

Right, the upstream wiki is down so I didn't know where to send it..


-- 
t

Bug#928021: opendnssec-enforcer: AllowExtraction should be supported but startup fails with it

[Mathieu Mirmont]

control: tags -1 +confirmed

On Fri, Apr 26, 2019 at 01:09:33PM +0300, Timo Aaltonen wrote:
> While testing FreeIPA, I noticed that enforcer startup fails if conf.xml has 
>  on it. The feature was forward-ported to 2.1 from 1.4, so 
> it should work in theory but instead I get this on startup:
> 
> /etc/opendnssec/conf.xml:11: element AllowExtraction: Relax-NG validity error 
> : Element Repository has extra content: AllowExtraction
> /etc/opendnssec/conf.xml:7: element Repository: Relax-NG validity error : 
> Element RepositoryList has extra content: Repository

Hmm yeah. I can't imagine that this can have anything to do with the way
the package is made. I'll have a look at the code and see if I can fix
it myself (and send the patch upstream of course), otherwise I'll just
report it upstream.

-- 
Mathieu Mirmont 


signature.asc
Description: PGP signature

Bug#782886: git-import-dsc to support --upstream-vcs-tag

[Guido Günther]

Hi,
On Sun, Apr 19, 2015 at 09:37:02PM +0900, Osamu Aoki wrote:
> Package: git-buildpackage
> Version: 0.6.22
> Severity: wishlist
> 
> The --upstream-vcs-tag for git-import-orig is nice.  Thanks.
> 
> Also pending fix to #700411 "git-import-orig should filter the upstream
> debian director" is also nice.
> 
> What about git-import-dsc to support --upstream-vcs-tag.

That would indeed be nice and a patch for that would be welcome to tie
in the upstream history same as import-orig does.
 -- Guido

Bug#928030: gnome: GNOME/Wayland + GDM3 die if the root disk fills up

[Jonathan Dowland]

Package: gnome
Version: 1:3.30+1
Severity: important

If the root disk fills up*, the desktop session dies and so does GDM3,
which does not come back up if restarted via systemctl etc. until the
/ partition has some space restored to it.

This does not happen with GNOME/Xorg: the desktop session persists,
although upon logging out and returning to GDM3 it does not come up.

*  tested and reproduced in a VM with simple partitioning; everything in /.
   The bit that matters might be a sub-component of / e.g. /var

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

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

Versions of packages gnome depends on:
ii  avahi-daemon 0.7-4+b1
ii  cheese   3.31.90-1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 10.0.2
ii  evolution3.30.5-1
ii  evolution-plugins3.30.5-1
ii  file-roller  3.30.1-2
ii  gedit-plugins3.30.1-3
ii  gnome-calendar   3.30.1-2
ii  gnome-clocks 3.30.1-2
ii  gnome-color-manager  3.30.0-2
ii  gnome-core   1:3.30+1
ii  gnome-documents  3.31.92-1
ii  gnome-getting-started-docs   3.30.0-1
ii  gnome-maps   3.30.3-1
ii  gnome-music  3.30.2-1
ii  gnome-screenshot 3.30.0-2
ii  gnome-sound-recorder 3.28.2-1
ii  gnome-todo   3.28.1-2
ii  gnome-tweaks 3.30.2-1
ii  gnome-weather3.26.0-5
ii  gstreamer1.0-libav   1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-ugly1.14.4-1
ii  libgsf-bin   1.14.45-1
ii  libproxy1-plugin-networkmanager  0.4.15-5
ii  libreoffice-calc 1:6.1.5-2
ii  libreoffice-gnome1:6.1.5-2
ii  libreoffice-impress  1:6.1.5-2
ii  libreoffice-writer   1:6.1.5-2
ii  nautilus-sendto  3.8.6-3
ii  network-manager-gnome1.8.20-1
ii  orca 3.30.1-1
ii  rhythmbox3.4.3-2
ii  rhythmbox-plugin-cdrecorder  3.4.3-2
ii  rhythmbox-plugins3.4.3-2
ii  rygel-playbin0.36.2-4
ii  rygel-tracker0.36.2-4
ii  seahorse 3.30.1.1-1
ii  shotwell 0.30.1-1
ii  simple-scan  3.30.1.1-1+b1
ii  totem-plugins3.30.0-4
ii  vinagre  3.22.0-6
ii  vino 3.22.0-5
ii  xdg-user-dirs-gtk0.10-3

Versions of packages gnome recommends:
ii  gnome-games 1:3.30+1
ii  nautilus-extension-brasero  3.12.2-5
ii  transmission-gtk2.94-2

Versions of packages gnome suggests:
pn  alacarte 
pn  empathy  
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  gnome-remote-desktop 
pn  goobox | sound-juicer
ii  polari   3.30.2-1
pn  webext-ublock-origin 

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.30.1-1
ii  at-spi2-core  2.30.0-7
ii  baobab3.30.0-2
ii  caribou   0.4.21-7
ii  dconf-cli 0.30.1-2
ii  dconf-gsettings-backend   0.30.1-2
ii  eog   3.28.4-2+b1
ii  evince3.30.2-3
ii  evolution-data-server 3.30.5-1
ii  firefox   66.0.1-1
ii  firefox-esr   60.6.1esr-1
ii  fonts-cantarell   0.111-2
ii  gdm3  3.30.2-3
ii  gedit 3.30.2-2
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.58.0-2
ii  gnome-backgrounds 3.30.0-1
ii  gnome-bluetooth   3.28.2-3
ii  gnome-calculator  3.30.1-2
ii  gnome-characters  3.30.0-2
ii  gnome-contacts3.30.2-1
ii  gnome-control-center  1:3.30.3-1
ii  gnome-disk-utility3.30.2-3
ii  gnome-font-viewer 3.30.0-2
ii  gnome-keyring 3.28.2-5
ii  gnome-logs3.30.0-2
ii  gnome-menus   3.31.4-3
ii  gnome-online-accounts 3.30.1-2
ii  gnome-online-miners   3.30.0-2
ii  gnome-session 3.30.1-2
ii  gnome-settings-daemon 3.30.2-3
ii  

Bug#927998: opendnssec: zonelist export fails

[Mathieu Mirmont]

control: tags -1 +pending

On Fri, Apr 26, 2019 at 12:11:03PM +0300, Timo Aaltonen wrote:
> On 26.4.2019 12.09, Mathieu Mirmont wrote:
> > control: tags -1 +confirmed
> > 
> > On Fri, Apr 26, 2019 at 11:44:41AM +0300, Timo Aaltonen wrote:
> >> Source: opendnssec
> >> Severity: important
> >>
> >> Hi, 'ods-enforcer zonelist export' fails, because 'opendnssec' has no 
> >> permission
> >> to write to /etc/opendnssec, so the permissions of the dir should be set to
> >> 0770 in postinst.
> > 
> > Thanks, I can confirm this. Bummer, but the fix is trivial.
> > 
> > Do you think it is worth bothering the release team trying to get this
> > through the freeze?
> 
> Well, I don't need it in buster.. noticed it while testing freeipa on
> experimental/ubuntu eoan.

I fixed the postinst script in this commit:
https://salsa.debian.org/debian/opendnssec/commit/11237c7706efaecc8cd897a52841da4cefdfa2b1

Let me know if an upload to experimental would be useful.

-- 
Mathieu Mirmont 


signature.asc
Description: PGP signature

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

[Chris Hofstaedtler]

* Dmitry Bogatov  [190425 16:13]:
> [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.

Which init was used in your experiments?

If it was systemd or anything else honoring tmpfiles.d,
/lib/tmpfiles.d/systemd.conf has:

F! /run/utmp 0664 root utmp -

> Thus I am asking your advice, whether it is safe to not create
> /var/run/utmp in initscripts.

Depending on the init, removing initscripts is already allowed, and
it's likely that fresh installs do not even get it installed
anymore.

Chris

Bug#928022: ITP: modernize -- Modernizes Python code for eventual Python 3 migration

[Benjamin Drung]

Am Freitag, den 26.04.2019, 13:11 +0200 schrieb Jonas Smedegaard:
> Quoting Benjamin Drung (2019-04-26 12:15:51)
> > Package: wnpp
> > Severity: wishlist
> > Owner: Benjamin Drung 
> > 
> > * Package name: modernize
> >   Version : 0.7
> >   Upstream Author : Armin Ronacher
> > * URL : https://pypi.org/project/modernize
> > * License : BSD-3-clause plus some PSF-2
> >   Programming Lang: Python
> >   Description : Modernizes Python code for eventual Python 3
> > migration
> > 
> > This library is a very thin wrapper around lib2to3 to utilize it to
> > make
> > Python 2 code more modern with the intention of eventually porting
> > it
> > over to Python 3.
> > 
> > The source will produce the binary packages modernize and
> > python3-libmodernize. This package is a dependency for salt-pylint,
> > which I intent to package.
> > 
> > I plan to maintain that package as part of the Debian Python
> > Modules
> > Team.
> 
> Please pretty please name this as python-modernize or modernize-
> python - 
> unless the plan is to extend to cover perl5-to-perl6 and Haskell-to-
> Rust 
> or similar.

Are there other tools named modernize or do you consider 'modernize' to
be too generic?

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#928029: planner: segfaulted; now segfaults on every start-up

[Jonathan Dowland]

Package: planner
Version: 0.14.6-7
Severity: important

planner segfaulted me shortly after starting it for the first time
(upon inserting a new task); now, it segfaults upon each attempt to
start it.

▶ planner
Gtk-Message: 12:10:14.171: Failed to load module "canberra-gtk-module"

(planner:13551): GLib-GObject-CRITICAL **: 12:10:14.318: g_object_ref: 
assertion 'G_IS_OBJECT (object)' failed

(planner:13551): GLib-GObject-WARNING **: 12:10:14.319: invalid unclassed 
pointer in cast to 'GDelayedSettingsBackend'

(planner:13551): GLib-GObject-WARNING **: 12:10:14.319: invalid unclassed 
pointer in cast to 'GSettingsBackend'

(planner:13551): GLib-GIO-CRITICAL **: 12:10:14.319: 
g_settings_backend_path_changed: assertion 'G_IS_SETTINGS_BACKEND (backend)' 
failed

(planner:13551): GLib-GObject-CRITICAL **: 12:10:14.319: g_object_unref: 
assertion 'G_IS_OBJECT (object)' failed
**
GLib-GObject:ERROR:../../../gobject/gobject.c:4447:g_weak_ref_set: assertion 
failed: (weak_locations != NULL)
Aborted (core dumped)

▶ gdb $(which planner) core
GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/planner...Reading symbols from 
/usr/lib/debug/.build-id/9c/0b4d0a054dc7d4d8e82b55d1663930716ae3f9.debug...done.
done.
[New LWP 13554]
[New LWP 13551]
[New LWP 13553]
[New LWP 13552]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `planner'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7fc3e7ed98bb in raise () from /lib/x86_64-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0x7fc3e20cd700 (LWP 13554))]
(gdb) bt
#0  0x7fc3e7ed98bb in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fc3e7ec4535 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7fc3e8222dc3 in g_assertion_message (domain=, 
file=, line=, 
func=0x7fc3e83662e8 <__FUNCTION__.15331> "g_weak_ref_set", 
message=) at ../../../glib/gtestutils.c:2596
#3  0x7fc3e827c68a in g_assertion_message_expr 
(domain=domain@entry=0x7fc3e8363078 "GLib-GObject", 
file=file@entry=0x7fc3e836528e "../../../gobject/gobject.c", 
line=line@entry=4447, 
func=func@entry=0x7fc3e83662e8 <__FUNCTION__.15331> "g_weak_ref_set", 
expr=expr@entry=0x7fc3e836570a "weak_locations != NULL") at 
../../../glib/gtestutils.c:2619
#4  0x7fc3e8341b26 in g_weak_ref_set (weak_ref=0x55e169ffe290, object=0x0) 
at ../../../gobject/gobject.c:4447
#5  0x7fc3e8341b7b in g_weak_ref_clear (weak_ref=0x55e169ffe290) at 
../../../gobject/gobject.c:4350
#6  0x7fc3e84a6217 in g_settings_backend_invoke_closure 
(user_data=0x7fc3d806c040) at ../../../gio/gsettingsbackend.c:275
#7  0x7fc3e84a6370 in g_settings_backend_dispatch_signal 
(backend=0x55e169c595d0, function_offset=8, 
name=0x55e169fec000 "/org/gnome/planner/views/task-view/wbs/", 
origin_tag=0x0, names=0x0)
at ../../../gio/gsettingsbackend.c:334
#8  0x7fc3e3657f09 in dconf_engine_watch_established (reply=, error=, 
handle=0x55e169fbf910, engine=0x55e169be6140) at 
../engine/dconf-engine.c:963
#9  dconf_engine_watch_established (engine=0x55e169be6140, 
handle=0x55e169fbf910, reply=, 
error=) at ../engine/dconf-engine.c:938
#10 0x7fc3e365abec in dconf_gdbus_method_call_done (source=, 
result=, 
user_data=user_data@entry=0x55e169fbf910) at 
../gdbus/dconf-gdbus-thread.c:254
#11 0x7fc3e8469719 in g_task_return_now (task=0x7fc3d80588d0) at 
../../../gio/gtask.c:1148
#12 0x7fc3e846a196 in g_task_return (task=0x7fc3d80588d0, type=) at ../../../gio/gtask.c:1206
#13 0x7fc3e84bfb1a in g_dbus_connection_call_done (source=, 
result=0x7fc3d8009930, 
user_data=user_data@entry=0x7fc3d80588d0) at 
../../../gio/gdbusconnection.c:5715
#14 0x7fc3e8469719 in g_task_return_now (task=0x7fc3d8009930) at 
../../../gio/gtask.c:1148
#15 0x7fc3e8469759 in complete_in_idle_cb (task=0x7fc3d8009930) at 
../../../gio/gtask.c:1162
#16 0x7fc3e8254dd8 in g_main_dispatch (context=0x55e169c6c160) at 
../../../glib/gmain.c:3182
#17 g_main_context_dispatch (context=context@entry=0x55e169c6c160) at 
../../../glib/gmain.c:3847
#18 0x7fc3e82551c8 in g_main_context_iterate 
(context=context@entry=0x55e169c6c160, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at 

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

[Osama Nasr]

Thanks a lot for your help, but actually i don't need that app, I just was
reporting this bug.
Do you need me to install proprietary drivers and test it ?

On Thu, 25 Apr 2019, 7:07 pm Bernhard Übelacker, 
wrote:

> 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#928022: ITP: modernize -- Modernizes Python code for eventual Python 3 migration

[Jonas Smedegaard]

Quoting Benjamin Drung (2019-04-26 12:15:51)
> Package: wnpp
> Severity: wishlist
> Owner: Benjamin Drung 
> 
> * Package name: modernize
>   Version : 0.7
>   Upstream Author : Armin Ronacher
> * URL : https://pypi.org/project/modernize
> * License : BSD-3-clause plus some PSF-2
>   Programming Lang: Python
>   Description : Modernizes Python code for eventual Python 3 migration
> 
> This library is a very thin wrapper around lib2to3 to utilize it to make
> Python 2 code more modern with the intention of eventually porting it
> over to Python 3.
> 
> The source will produce the binary packages modernize and
> python3-libmodernize. This package is a dependency for salt-pylint,
> which I intent to package.
> 
> I plan to maintain that package as part of the Debian Python Modules
> Team.

Please pretty please name this as python-modernize or modernize-python - 
unless the plan is to extend to cover perl5-to-perl6 and Haskell-to-Rust 
or similar.


 - 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

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

[Laura Arjona Reina]

reassign 927987 installation-guide
Thanks

Hi all
This documentation is handled via the package installation-guide. Reassigning.

Kind regards

--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

El 26/4/19 a las 2:18, 積丹尼 Dan Jacobson escribió:

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.