Bug#805821: systemd does not see existing dmraid volumes

[Nikita Youshchenko]

>>> Could you send us a "udevadm info" dump for those devices.
>>
>> root@nyws:~# udevadm info /dev/mapper/jmicron_Main
> 
> [snip]
> 
> Those udevadm info dumps look ok to me. I don't see anything that would
> obviously be wrong.
> 
> Can you still reproduce the issue?
> Would be great if you can check again on a buster system.

Unfortunately that system block no longer exists.



signature.asc
Description: OpenPGP digital signature

Bug#924372: O: x4d-icons -- X4D Icon set for various online document types

[Dimitri John Ledkov]

Package: wnpp
Severity: normal

I intend to orphan the x4d-icons package.

The package description is:
 Icon set indicating document types and target versions of those
 specifications e.g. HTML, XHTML, CSS, MathML, etc. These are metric
 compatible & naming scheme compatible with other logos used for
 similar purposes.

These are "free" unlike the old w3c ones used in many docs.

Bug#924371: RM: libinotify-kqueue -- ROM; FTBFS, never built, not interested

[Dimitri John Ledkov]

Package: ftp.debian.org
Severity: normal

as per subject.

Bug#924279: sbuild-debian-developer-setup fails within docker

[Tong Sun]

On Mon, Mar 11, 2019 at 9:00 PM Johannes Schauer wrote:
>
> Quoting Tong Sun (2019-03-12 01:38:06)
> > OH! I found I have to read your comment a second time before realizing what
> > you were saying.
> >
> > OK, going pass that now I'm facing another problem:
> >
> > $ sudo /usr/bin/sbuild-debian-developer-setup
> > . . .
> > I: SUITE: unstable
> > I: TARGET: /srv/chroot/unstable-amd64-sbuild
> > I: MIRROR: http://localhost:3142/deb.debian.org/debian
> > I: Running debootstrap --arch=amd64 --variant=buildd --verbose
> > --include=fakeroot,build-essential,eatmydata --components=main
> > --resolve-deps --no-merged-usr unstable
> > /srv/chroot/unstable-amd64-sbuild
> > http://localhost:3142/deb.debian.org/debian
> > I: Target architecture can be executed
> > I: Retrieving InRelease
> > I: Retrieving Release
> > E: Failed getting release file
> > http://localhost:3142/deb.debian.org/debian/dists/unstable/Release
> > E: Error running debootstrap at /usr/bin/sbuild-createchroot line 424.
> > sbuild-createchroot failed:  at /usr/bin/sbuild-debian-developer-setup line 
> > 53.
> >
> > It failed getting release file.
> >
> > Is it only me getting above? Thx
>
> the package sbuild-debian-developer-setup depends on apt-cacher-ng or
> apt-cacher. Both are apt caching services which provide a local http mirror at
> http://localhost:3142. The error you are getting sounds as if you disabled the
> services after installing them.

Ah, yes!

somehow the apt-cacher-ng service is not started under docker

thanks for your help Johannes!

Bug#924370: O: libica

[Dimitri John Ledkov]

Package: wnpp
Severity: normal

Description: hardware cryptography support for IBM System z hardware
 libica library provides hardware acceleration for cryptographic
 functions and is part of the openCryptoki project.

I shall continue to maintain this in Ubuntu, most likely.

Regards,

Dimitri.

Bug#924369: O: friendly-recovery -- Make recovery boot mode more user-friendly

[Dimitri John Ledkov]

Package: wnpp
Severity: normal

I intend to orphan the friendly-recovery package from Debian.

Ubuntu Developer will probably continue to maintain this package in
Ubuntu, as it is used there by default.

The package description is:
 Make the recovery boot mode more user-friendly by providing a menu
 with pluggable options.

Bug#924047: FTBFS: package don't build successful after new GCC version

[أحمد المحمودي]

On Sun, Mar 10, 2019 at 08:03:57AM +0100, Carsten Schoenert wrote:
> That's the last option in my eyes as it's a step backwards and is
> absolutely not needed as I fixed the problem already.
---end quoted text---

Yes, but this needs to be done for every gcc update ! I tried unmangling 
the c++ symbols and using c++ tag in symbols file (see c++sym branch), 
but that failed too.

Anyways, I updated std ver to 4.3.0, amd pushed 2.3.3-2, here's the 
changelog entry:

systemc (2.3.3-2) unstable; urgency=medium

  [ أحمد المحمودي (Ahmed El-Mahmoudy) ]
  * [625f662] Revert "uscan: update watch file to catch new versions"
This reverts commit 83ab9e15a4138b76fadd9d6ada5d0893a12f0ae8.
  * [3886a0b] Bumped standards version to 4.3.0, no changes needed

  [ Carsten Schoenert ]
  * [d3c60cd] libsystemc.symbols: update after GCC update


-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#924367: O: mdadm -- tool to administer Linux MD arrays (software RAID)

[Dimitri John Ledkov]

Package: wnpp
Severity: normal

I intend to orphan the mdadm package.

The package description is:
 The mdadm utility can be used to create, manage, and monitor MD
 (multi-disk) arrays for software RAID or multipath I/O.
 .
 This package automatically configures mdadm to assemble arrays during the
 system startup process. If not needed, this functionality can be disabled.

Regards,

Dimitri.

Bug#924368: O: btrfs-progs -- Checksumming Copy on Write Filesystem utilities

[Dimitri John Ledkov]

Package: wnpp
Severity: normal

I intend to orphan the btrfs-progs package.

The package description is:
 Btrfs is a new copy on write filesystem for Linux aimed at implementing
 advanced features while focusing on fault tolerance, repair and easy
 administration.
 .
 This package contains utilities (mkfs, fsck) used to work with btrfs
 and an utility (btrfs-convert) to make a btrfs filesystem from an ext3.

Regards,

Dimitri.

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Richard Laager]

On 3/11/19 9:50 PM, Rick Thomas wrote:
> Would unplugging/replugging the ethernet cable work for steps 2 and 4…

Sure, that'd be another option.

-- 
Richard

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Thanks Richard, I’ll see if I can set up that experiment(s) and report back 
ASAP.

Would unplugging/replugging the ethernet cable work for steps 2 and 4…

Enjoy!
Rick

> On Mar 11, 2019, at 2:53 PM, Richard Laager  wrote:
> 
> Can we narrow this down to a reproducer? It sounds like something like
> this would work:
> 
> 
> 
> 0) Configure two different pools where you can tell the servers apart.
> 1) Stop ntpd.
> 2) Break your DNS.
> 3) Start ntpd. Wait a few seconds for it to try to resolve and fail.
> 4) Fix your DNS.
> 
> Expected results:
> ntpd recovers (successfully resolves the pools' DNS records) relatively
> quickly. Most importantly, when ntpd recovers, it recovers for both
> pools equally.
> 
> Actual results:
> Only the last configured pool recovers right away. The other one takes 5
> or 10 minutes.
> 
> 
> 
> Can you try a few more things:
> 
> 1) Does deleting the nameservers in /etc/resolv.conf work for step 2, or
> more to the point, does putting them back in /etc/resolv.conf work for
> step 4?
> 
> 2) I doubt it matters, but can you set the poll intervals the same on
> the two pools, to eliminate that variable?
> 
> 3) If you reduce minsane to 4, what happens? Does it do the same thing,
> never spin up the second pool, or (far less likely) spin them both up
> normally? I wonder if ntpd is only "recovering" the second pool because
> it is below minsane.
> 
> -- 
> Richard

Bug#802210: systemd: Shutdown delay waiting for stop events

[Michael Biebl]

Control: tags -1 + moreinfo

On Sun, 18 Oct 2015 14:52:12 +0300 Aryeh Leib Taurog 
wrote:
> Package: systemd
> Version: 215-17+deb8u2
> Severity: normal
> 
> Dear Maintainer,
> 
> I just recently upgraded from wheezy to jessie.  The /home partition 
> is LUKS encrypted.
> 
> Shutdown always takes 90s while waiting for various stop events to 
> time out.  At first these seemed not always to be the same, but the 
> last several times I shut down, the culprits were:
> 
> * Monitoring of LVM2 mirrors
> * Device Mapper event daemon
> 
> I have a number of lvm volumes, but I don't think I actually have any 
> mirrors.  Can the first of these be disabled altogether?
> 


Is this still a problem on an up-to-date stretch or buster system?

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#800707: systemd: Sytem hangs on shutdown when nfs-shares are mounted via autofs

[Michael Biebl]

Control: tags -1 + moreinfo

On Fri, 02 Oct 2015 21:01:07 +0200 =?utf-8?q?J=C3=BCrgen_Bausa?=
 wrote:
> Package: systemd
> Version: 215-17+deb8u2
> Severity: normal
> 
> Dear Maintainer,
> 
> I am running jessie on a laptop with wlan (Networkmanager) and want to use
> autofs to mount nfs shares, as the shares are only available, when I am at
> home.
> 
> The problem is, that when I am actually accessing the share (and it is
> therefore mounted by autofs), the system hangs on shutdown. At first I get the
> message
> 
>   [*]A stop job is running for /mnt/nfs/share (xxs / 1mn 30s)
> 
> and the systems counts down 90 s. After that I see som more messages which end
> up with
> 
>   Reached target shutdown
> 
> After that, the system hangs forever (at least for a long time, I think I
> waited some minutes).
> 
> When I am not accessing an nfs share during the session, and autofs does not
> need to actually mount it, shutdown works fine.
> 
> I think the reason for this problem is, that systemd stops Networkmanager
> before autofs had a chance to unmount the shares. After that unmounting doesnt
> work and later stopping autofs also fails. Thats my theory.

Is this still an issue with stretch or buster?
Can you share more details about your network configuration, (wifi,
ethernet,...)

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



signature.asc
Description: OpenPGP digital signature

Bug#827000: systemd: Shutdown / reboot fails on discless system (booting from iscsitarget)

[Michael Biebl]

Control: reassign -1 open-iscsi

On Sat, 11 Jun 2016 05:35:52 +0200 Klaus Pieper  wrote:
> Package: systemd
> Version: 230-2
> Severity: normal
> 
> Dear Maintainer,
> 
> * installed on iscsi target with the beta installer which worked perfectly.
> Could boot up without any further configuration.
> * After shutdown / reboot (from command line or gnome or ctrl-alt-del) I get
> messages on the console "connection:0: timeout after 5 secs..", the commands 
> do
> not terminate.
> * Can't find more information in /var/log/messages or journalctl.
> 

Since I have absolutely no idea about iscsi and how to debug it, I'm
going to reassigning this bug report to open-iscsi, hoping that its
maintainers can help you with diagnosing this issue.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#813176: "Checking in progress on 1 disk. (0.0%)" doesn't update

[Michael Biebl]

Control: tags -1 + moreinfo

On Sun, 3 Mar 2019 22:57:29 + (UTC) Pierre Ynard
 wrote:
> reassign 813176 systemd
> thanks
> 
> This line is, or was, part of the systemd-fsckd source code:
> 
> https://github.com/systemd/systemd/blob/e7a3aa3df640993ce9aace39b946543305f3af53/src/fsckd/fsckd.c#L343
> 
> Reassigning to systemd maintainers, they will be better able to answer
> about these progress reporting issues.
> 

Dan, is this problem still reproducible on an up-to-date stretch or
buster system?
If so, could you attach the output of
reportbug --template systemd


Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#812916: systemd-ask-password related log messages

[Michael Biebl]

Control: tags -1 + moreinfo

On Sat, 26 Mar 2016 13:10:45 -0500 "Karl O. Pinc"  wrote:
> Hi,
> 
> I got the following 2 (contiguous) log messages in /var/log/daemon
> that may be useful and seem related to the problem.
> They occurred when messages were broadcast to all ttys (excepting
> the one tty which was starting the openvpn service.)
> 
> 
> Mar 26 12:37:49 example systemctl[30630]: Failed to stop
> systemd-ask-password-plymouth.path: Unit
> systemd-ask-password-plymouth.path not loaded. 
> 
> Mar 26 12:37:49 example
> systemctl[30630]: Failed to stop systemd-ask-password-plymouth.service:
> Unit systemd-ask-password-plymouth.service not loaded.

Sorry for not getting back to you earlier.

Is this problem still reproducible on an up-to-date stretch or buster
system?

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#805821: systemd does not see existing dmraid volumes

[Michael Biebl]

Control: tags -1 moreinfo

On Mon, 23 Nov 2015 23:17:12 +0300 Nikita Youshchenko 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> > Could you send us a "udevadm info" dump for those devices.
> 
> root@nyws:~# udevadm info /dev/mapper/jmicron_Main

[snip]

Those udevadm info dumps look ok to me. I don't see anything that would
obviously be wrong.

Can you still reproduce the issue?
Would be great if you can check again on a buster system.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#794547: Fwd: cryptsetup: "Operation was cancelled" after LUKS volume hotplug, but mounts successfully

[Michael Biebl]

Control: tags -1 + moreinfo

Hi Matvey,

sorry for not getting back to you earlier.
Can you still reproduce the issue on an up-to-date buster system with
systemd v241?


On Tue, 4 Aug 2015 05:50:55 -0400 Matvey Soloviev
 wrote:
> Package: systemd
> Version: 222-2
> Severity: normal
> 
> Dear Maintainer,
> 
> When hotplugging an external HDD with a LUKS volume, after entering the
> password, I consistently get an error message saying: "Unable to mount 1.0 TB
> Encrypted"/"Operation was cancelled". However, the volume itself is mounted
> successfully. After the timeout set in /etc/crypttab options expires, an error
> message like the following is generated in the journal:
> 
> Aug 04 04:51:55 luminous systemd[1]: dev-disk-by\x2duuid-
> 82eaf8eb\x2da748\x2d4d55\x2da7de\x2d3fdb4d8504f6.device: Job dev-disk-by
> \x2duuid-82eaf8eb\x2da748\x2d4d55\x2da7de\x2d3fdb4d8504f6.device/start timed
> out.
> Aug 04 04:51:55 luminous systemd[1]: Timed out waiting for device
> Elements_1048.
> Aug 04 04:51:55 luminous systemd[1]: Dependency failed for Cryptography Setup
> for d4.
> Aug 04 04:51:55 luminous systemd[1]: systemd-cryptsetup@d4.service: Job
> systemd-cryptsetup@d4.service/start failed with result 'dependency'.
> Aug 04 04:51:55 luminous systemd[1]: dev-disk-by\x2duuid-
> 82eaf8eb\x2da748\x2d4d55\x2da7de\x2d3fdb4d8504f6.device: Job dev-disk-by
> \x2duuid-82eaf8eb\x2da748\x2d4d55\x2da7de\x2d3fdb4d8504f6.device/start failed
> with result 'timeout'.
> 
> The relevant /etc/crypttab line is:
> 
> d4 UUID=82eaf8eb-a748-4d55-a7de-3fdb4d8504f6 none 
> luks,nofail,x-systemd.device-
> timeout=200
> 
> Same for /etc/fstab:
> 
> /dev/mapper/d4  /d4 ext4rw,nofail   0   2
> 
> The above journal.txt lines are preceded by the following corresponding 
> reports
> of success:
> 
> Aug 04 04:48:26 luminous kernel: sd 11:0:0:0: [sdc] 1953519616 512-byte 
> logical
> blocks: (1.00 TB/931 GiB)
> Aug 04 04:48:26 luminous kernel: sd 11:0:0:0: [sdc] Write Protect is off
> Aug 04 04:48:26 luminous kernel: sd 11:0:0:0: [sdc] Mode Sense: 47 00 10 08
> Aug 04 04:48:26 luminous kernel: sd 11:0:0:0: [sdc] No Caching mode page found
> Aug 04 04:48:26 luminous kernel: sd 11:0:0:0: [sdc] Assuming drive cache: 
> write
> through
> Aug 04 04:48:26 luminous kernel: sd 11:0:0:0: [sdc] Attached SCSI disk
> Aug 04 04:48:34 luminous systemd[1]: Found device /dev/disk/by-
> uuid/3ce8740e-b413-44e2-ab44-c09a2f98.
> Aug 04 04:48:34 luminous systemd[1]: Found device /dev/disk/by-id/dm-uuid-
> CRYPT-LUKS1-82eaf8eba7484d55a7de3fdb4d8504f6-d4.
> Aug 04 04:48:34 luminous systemd[1]: Found device /dev/disk/by-id/dm-name-d4.
> Aug 04 04:48:34 luminous systemd[1]: Found device /dev/dm-1.
> Aug 04 04:48:34 luminous systemd[1]: Found device
> /sys/devices/virtual/block/dm-1.
> Aug 04 04:48:34 luminous systemd[1]: Starting File System Check on
> /dev/mapper/d4...
> Aug 04 04:48:34 luminous systemd[1]: Started File System Check Daemon to 
> report
> status.
> Aug 04 04:48:34 luminous systemd[1]: Starting File System Check Daemon to

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



signature.asc
Description: OpenPGP digital signature

Bug#924366: natural sort output on cpuspeed plugin

[Craig Sanders]

Package: munin-plugins-core
Version: 2.0.47-1
Control: severity -1 wishlist

The output of several plugins (including cpusped) is not sorted at all, and a
simple numeric iteration (e.g. of cpu cores or network interfaces) results in
incorrect sorting (1, 10, 11, 12, ..., 2, 20, 21, etc).

I fixed this on my system by replacing the /etc/munin/plugins/cpuspeed symlink
(to /usr/share/munin/plugins/cpuspeed) with a copy of the plugin and making
the following one line change to use sort's -V version-sort aka natural sort
option:


# diff -u /usr/share/munin/plugins/cpuspeed /etc/munin/plugins/cpuspeed
--- /usr/share/munin/plugins/cpuspeed   2019-03-01 02:06:07.0 +1100
+++ /etc/munin/plugins/cpuspeed 2019-03-12 12:25:17.239713453 +1100
@@ -141,7 +141,7 @@
 print_warning "cpu$N"
 print_critical "cpu$N"
 
-done
+done | sort -V
 if [ "${MUNIN_CAP_DIRTYCONFIG:-0}" != 1 ]; then exit 0; fi
 fi
 


There are probably several other plugins that would benefit from adding "sort
-V" - anything likely to have 10 or more similar values (e.g. there's a 9 year
old ticket http://munin-monitoring.org/ticket/919 reporting the same issue
with network interfaces).  Please forward this upstream.

e.g. on my 1950x threadripper (16 core/32 thread) system, i was getting:

# munin-run cpuspeed
cpu0.value 284378906000
cpu1.value 284676376000
cpu10.value 286158358000
cpu11.value 285770772000
cpu12.value 286035834000
cpu13.value 286069598000
cpu14.value 28612385
cpu15.value 286026202000
cpu16.value 28460602
cpu17.value 28463332
cpu18.value 28462524
cpu19.value 284638744000
cpu2.value 284703898000
cpu20.value 285276808000
cpu21.value 285240678000
cpu22.value 284850692000
cpu23.value 285244496000
cpu24.value 28612616
cpu25.value 286147946000
cpu26.value 286171272000
cpu27.value 28606225
cpu28.value 286091928000
cpu29.value 28610440
cpu3.value 284666958000
cpu30.value 286057878000
cpu31.value 286207444000
cpu4.value 286922096000
cpu5.value 286545698000
cpu6.value 286363752000
cpu7.value 28627602
cpu8.value 286119812000
cpu9.value 28603790


Now I'm getting this, so the graphs on my munin web page are properly sorted:

cpu0.value 284391408000
cpu1.value 284688894000
cpu2.value 284716416000
cpu3.value 284679476000
cpu4.value 286934664000
cpu5.value 286558216000
cpu6.value 28637627
cpu7.value 28628858
cpu8.value 286132378000
cpu9.value 286050418000
cpu10.value 286170884000
cpu11.value 285783268000
cpu12.value 286048376000
cpu13.value 28608223
cpu14.value 286136368000
cpu15.value 28603878
cpu16.value 284618538000
cpu17.value 284645838000
cpu18.value 284637736000
cpu19.value 284651262000
cpu20.value 285289428000
cpu21.value 285253196000
cpu22.value 284863188000
cpu23.value 285257014000
cpu24.value 286138678000
cpu25.value 28616061
cpu26.value 28618379
cpu27.value 286074776000
cpu28.value 286104446000
cpu29.value 286116918000
cpu30.value 286070438000
cpu31.value 286219946000



thanks,

craig

--
craig sanders 

Bug#915706: 9.6.0 DVD and XFCE CD for mipsel are actually netinst

[YunQiang Su]

e.

Assign to me...

Steve McIntyre  于2019年3月10日周日 上午7:36写道：
>
> Control: reassign -1 cdimage.debian.org
> Control: severity -1 important
>
> On Thu, Dec 06, 2018 at 05:54:51PM +0800, seam...@debian.org wrote:
> >Package: debian-installer
> >Severity: serious
> >
> >I tried "debian-9.6.0-mipsel-xfce-CD-1.iso" and 
> >"debian-9.6.0-mipsel-DVD-1.iso" on QEMU and found that both images are 
> >actually "netinst" variant. After I chose my country and defined the 
> >hostname, the installer forced me to choose a mirror. After that it started 
> >downloading components of the installer from the mirror and ignores the many 
> >preloaded packages inside the CD/DVD.
> >
> >This should be consider "unusable" because the nature of the artifacts has 
> >changed.
>
> Hi!
>
> How did you make this work with qemu on mipsel? I've tried a little
> and I can't get very far. We've not had useful installation media for
> mipsel for a very long time - patches welcome...
>
> --
> Steve McIntyre, Cambridge, UK.st...@einval.com
> "Since phone messaging became popular, the young generation has lost the
>  ability to read or write anything that is longer than one hundred and sixty
>  characters."  -- Ignatios Souvatzis
>


-- 
YunQiang Su

Bug#924357: dillo: ddg search string in dillorc results in non-useful links

[Axel Beckert]

Hi,

liftof+d...@gmail.com wrote:
> When Dillo's search function is used with duckduckgo.com, the
> resulting links lead to a blank page.
> 
> By slightly modifying dillorc, the problem is eliminated:
> 
> search_url="dd DuckDuckGo (https) https://duckduckgo.com/lite/?kp=-1=%s;
> 
> needs to be:
> 
> search_url="dd DuckDuckGo (https) 
> https://duckduckgo.com/lite/?kp=-1=%s=-1;

Thanks! Fixed in the packaging git repository:
https://salsa.debian.org/debian/dillo/commit/ffbd4fc0e6cf94b3947d02766224c0e80344a017

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

Bug#924161: unblock: lirc/0.10.1-5.1

[Nicolas Braud-Santoni]

Hi abe,


On Mon, Mar 11, 2019 at 12:31:42AM +0100, Andreas Beckmann wrote:
> This needs a lot of more work :-(
> 
> * is this usage of --link-doc valid? the packages don't have a strictly
> versioned Depends: lirc (= ${binary:version}), so I can install *only*
> liblirc0 and have a dangling /usr/share/doc/liblirc0 and e.g. no
> copyright file

Right, that should have been liblirc0 (which they all depend on, transitively,
except for lirc-doc). However, I now noticed an interaction with lirc-doc which
makes --link-doc particularly unadvisable (see below).

Note to self: see if it's possible to detect that error automatically in 
lintian.


> * in all the *.maintscript files, add 0.10.1-5.1~ as 'prior-version'
> argument - you don't want to run this stuff again on *every* upgrade
> 
> * lirc.maintscript has typos: /etx/...

Thanks :)

I didn't get yelled at by piuparts, so it went right through my testing...


> * does the override_dh_installdocs target work with
>   dpkg-buildpackage -A/-B (i.e. building arch and indep packages separately)

Yes, I tested that, build went fine  :)

(To be precise, sbuild --no-arch-all --arch-any && sbuild --arch-all 
--no-arch-any)


> * lirc.postinst: using wildcards looks very fragile

I tried using `-p lirc` but that didn't work, probably for the same reason
dh-python wasn't doing it automatically in the first place.

Would you prefer leaving #924158 open and not doing manually?


> * lirc.posztrm: why do you manually delete conffiles on purge? dpkg does
> that already. (If they are not conffiles, you can't use
> dpkg-maintscript-helper on them.)

The package was previously doing that, and I didn't touch that part of the
postrm script, but I could remove the unecessary conffile handling if you'd
like.

I suspect that's the because the package previously installed the conffiles with
a spurious .dist extension, and copied them to the right location during
postinst, for some unscrutable reason.

debian/rules had a comment saying it was “not to overwrite conffiles” but that
makes little sense: dpkg won't overwrite user-modified conffiles by default.


> PS: I hate cleaning up after misuse of --link-doc. Save brain cycles,
> not bits on disks. Right now I'm afraid that you are turning a mess into
> a greater mess.

I'm not super keen on --link-doc either, but I didn't want to completely ignore
the original package maintainer's intent. However, I just noticed additional
complications -- lirc-doc shipping things in /usr/share/doc/lirc -- which make
it a bad idea (or at least more annoying to implement than I care to), so I just
reverted the change.

On the other hand, I can agree this is a mess and I might not have a mop large
enough...


> PPS: I only looked at the debdiff, not at the package itself

Appreciated regardless.  :)


Here is the diff compared to the previous proposed version, the full debdiff is
attached:

  diff --git c/debian/changelog w/debian/changelog
  index 4681945..32b2dc1 100644
  --- c/debian/changelog
  +++ w/debian/changelog
  @@ -3,16 +3,19 @@ lirc (0.10.1-5.1) unstable; urgency=medium
 * Non-maintainer upload
   
 * debian/rules
  -+ Replace rdfind-based dedup with dh_installdocs --link-doc
  -  - This achieves the same effect (copyright, changelog, ... aren't
  -duplicated) cleanly and without RC-buggyness.  (Closes: #919843)
  -  - Add missing maintscripts for dir-to-symlink migration.
  -Thanks to Niels Thykier for spotting the bug.
  ++ Remove rdfind-based dedup (Closes: #919843)
  +  Using dh_installdocs --link-docs was investigated, and rejected due to
  +  - limited benefits;
  +  - interactions between lirc-docs shipping files under 
/usr/share/doc/lirc,
  +but liblirc0 being the obvious candidate due to dependencies.
   
   + Do not install conffiles in a dummy location
 dpkg will, by default, not overwrite users' conffiles,
 so shipping them in a different location is superfluous.
   
  +  * Removed liblircclient{0,-dev}
  +They were obsolete transitional packages that predated the stretch 
release.
  +
 * Rename debian/post{inst,rm} to lirc.post{inst,rm}
 * debian/lirc.{postinst,prerm}: Recompile and remove Python bytecode as 
needed
   Closes: #924158
  @@ -23,7 +26,7 @@ lirc (0.10.1-5.1) unstable; urgency=medium
   
 * debian/changelog: Fix spelling in v0.10.1-4
   
  - -- Nicolas Braud-Santoni   Sun, 10 Mar 2019 00:28:01 +0100
  + -- Nicolas Braud-Santoni   Tue, 12 Mar 2019 01:33:40 +0100
   
   lirc (0.10.1-5) unstable; urgency=medium
   
  diff --git c/debian/control w/debian/control
  index 1fc9231..8711007 100644
  --- c/debian/control
  +++ w/debian/control
  @@ -34,6 +34,7 @@ Build-Depends:
xsltproc
   # libjs-jquery
   
  +
   Package: lirc
   Architecture: any
   Depends:
  @@ -104,24 +105,6 @@ Description: Infra-red remote control support - Run-time 
libraries
LIRC applications (lirc_private.so*)
   
   
  -Package: 

Bug#923273: [pkg-apparmor] Bug#923273: Bug#923273: apparmor: nvidia_modprobe named profile is shipped in complain mode

[Seth Arnold]

On Fri, Mar 08, 2019 at 06:57:14PM +0200, Vincas Dargis wrote:
> Since LibreOffice is in complain mode by default, so I doubt this issue

I strongly dislike the idea of shipping any profiles in complain mode. I
would rather the profiles in question be disabled entirely.

Complain mode profiles can chew up essentially unlimited amounts of
non-swappable kernel memory.

Complain mode profiles can chew up a huge amount of disk IO bandwidth
logging ALLOWED messages. All those messages can take a huge amount
of storage.

Complain mode profiles as a default is a very poor user experience.

Thanks


signature.asc
Description: PGP signature

Bug#924279: sbuild-debian-developer-setup fails within docker

[Johannes Schauer]

Quoting Tong Sun (2019-03-12 01:38:06)
> OH! I found I have to read your comment a second time before realizing what
> you were saying.
> 
> OK, going pass that now I'm facing another problem:
> 
> $ sudo /usr/bin/sbuild-debian-developer-setup
> . . .
> I: SUITE: unstable
> I: TARGET: /srv/chroot/unstable-amd64-sbuild
> I: MIRROR: http://localhost:3142/deb.debian.org/debian
> I: Running debootstrap --arch=amd64 --variant=buildd --verbose
> --include=fakeroot,build-essential,eatmydata --components=main
> --resolve-deps --no-merged-usr unstable
> /srv/chroot/unstable-amd64-sbuild
> http://localhost:3142/deb.debian.org/debian
> I: Target architecture can be executed
> I: Retrieving InRelease
> I: Retrieving Release
> E: Failed getting release file
> http://localhost:3142/deb.debian.org/debian/dists/unstable/Release
> E: Error running debootstrap at /usr/bin/sbuild-createchroot line 424.
> sbuild-createchroot failed:  at /usr/bin/sbuild-debian-developer-setup line 
> 53.
> 
> It failed getting release file.
> 
> Is it only me getting above? Thx

the package sbuild-debian-developer-setup depends on apt-cacher-ng or
apt-cacher. Both are apt caching services which provide a local http mirror at
http://localhost:3142. The error you are getting sounds as if you disabled the
services after installing them.


signature.asc
Description: signature

Bug#924365: www.debian.org: FTBFS in buster: turkish vs. tr_TR locale

[Cyril Brulebois]

Package: www.debian.org
Severity: normal
User: www.debian@packages.debian.org
Usertags: scripts

Hi,

While working on rebuilding the website within stretch and buster, I've
noticed the following.

The turkish subdirectory doesn't build in buster, apparently due to
possible locale issues:

(buster-amd64-webwml)kibi@wodi:~/debian-www/buster/webwml$ make -j1 -C 
turkish STRICT_ERROR_CHECKS=1 USE_SAMPLE_FILES=1
make: Entering directory '/home/kibi/debian-www/buster/webwml/turkish'
make -C po install
make[1]: Entering directory '/home/kibi/debian-www/buster/webwml/turkish/po'
make[1]: Leaving directory '/home/kibi/debian-www/buster/webwml/turkish/po'
wml -q -D CUR_YEAR=2019 -o UNDEFuTR:index.tr.html@g+w   index.wml
ePerl:Error: Perl runtime error (interpreter rc=0)

 Contents of STDERR channel: -
Locale 'tr_TR' may not work well.
The following characters (and maybe others) may not have the same meaning 
as the Perl program expects:
I i
; codeset=ISO-8859-9
--
** WML:Break: Error in Pass 3 (rc=1).
Died at /usr/share/wml/TheWML/Frontends/Wml/Runner.pm line 403.

TheWML::Frontends::Wml::Runner::_run_pass(TheWML::Frontends::Wml::Runner=HASH(0x55db148af458),
 3, SCALAR(0x55db14e351b8), SCALAR(0x55db14e35188), SCALAR(0x55db14e351a0)) 
called at /usr/share/wml/TheWML/Frontends/Wml/Runner.pm line 441

TheWML::Frontends::Wml::Runner::_passes_loop(TheWML::Frontends::Wml::Runner=HASH(0x55db148af458))
 called at /usr/share/wml/TheWML/Frontends/Wml/Runner.pm line 726

TheWML::Frontends::Wml::Runner::_output_and_cleanup(TheWML::Frontends::Wml::Runner=HASH(0x55db148af458))
 called at /usr/share/wml/TheWML/Frontends/Wml/Runner.pm line 930

TheWML::Frontends::Wml::Runner::run_with_ARGV(TheWML::Frontends::Wml::Runner=HASH(0x55db148af458),
 HASH(0x55db14908ff8)) called at /usr/bin/wml line 47
make: *** [/home/kibi/debian-www/buster/webwml/english/Makefile:43: 
index.tr.html] Error 2
make: Leaving directory '/home/kibi/debian-www/buster/webwml/turkish'


Many languages are using UTF-8 locales, exceptions are the following ones:

$ git grep CUR_LOCALE -- */.wmlrc|grep -v UTF-8$|grep -v utf8$
armenian/.wmlrc:-D CUR_LOCALE=hy_AM
bulgarian/.wmlrc:-D CUR_LOCALE=bg_BG
dutch/.wmlrc:-D CUR_LOCALE=nl_NL
hungarian/.wmlrc:-D CUR_LOCALE=hu_HU
lithuanian/.wmlrc:-D CUR_LOCALE=lt_LT
persian/.wmlrc:-D CUR_LOCALE=fa_IR
romanian/.wmlrc:-D CUR_LOCALE=ro_RO
slovak/.wmlrc:-D CUR_LOCALE=sk_SK
slovene/.wmlrc:-D CUR_LOCALE=sl_SI
turkish/.wmlrc:-D CUR_LOCALE=tr_TR

I suppose contacting translators and checking with them whether ISO-8859-9
is the right encoding to use in our source files, and whether there might
be some issues with Perl, would be a starting point?


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

Bug#924364: unblock: owasp-java-html-sanitizer/0.1+r88-2

[Markus Koschany]

Please find attached the debdiff.

diff -Nru owasp-java-html-sanitizer-0.1+r88/debian/changelog 
owasp-java-html-sanitizer-0.1+r88/debian/changelog
--- owasp-java-html-sanitizer-0.1+r88/debian/changelog  2012-03-22 
04:54:45.0 +0100
+++ owasp-java-html-sanitizer-0.1+r88/debian/changelog  2019-03-12 
01:25:43.0 +0100
@@ -1,3 +1,12 @@
+owasp-java-html-sanitizer (0.1+r88-2) unstable; urgency=medium
+
+  * Team upload.
+  * Remove obsolete DM-uploads-allowed field.
+  * Do not build-depend on libjsr305-java-doc anymore because it is gone.
+(Closes: #923654)
+
+ -- Markus Koschany   Tue, 12 Mar 2019 01:25:43 +0100
+
 owasp-java-html-sanitizer (0.1+r88-1) unstable; urgency=low
 
   * Initial Debian release (Closes: #664055)
diff -Nru owasp-java-html-sanitizer-0.1+r88/debian/control 
owasp-java-html-sanitizer-0.1+r88/debian/control
--- owasp-java-html-sanitizer-0.1+r88/debian/control2012-03-22 
04:54:45.0 +0100
+++ owasp-java-html-sanitizer-0.1+r88/debian/control2019-03-12 
01:25:43.0 +0100
@@ -3,14 +3,12 @@
 Priority: optional
 Maintainer: Debian Java Maintainers 

 Uploaders: James Page 
-DM-Upload-Allowed: yes
 Build-Depends: cdbs, debhelper (>= 7), default-jdk, maven-debian-helper (>= 
1.5)
 Build-Depends-Indep:
  default-jdk-doc,
  libguava-java,
  libguava-java-doc,
  libjsr305-java,
- libjsr305-java-doc,
  libmaven-javadoc-plugin-java
 Standards-Version: 3.9.3
 Homepage: http://code.google.com/p/owasp-java-html-sanitizer


signature.asc
Description: OpenPGP digital signature

Bug#924364: unblock: owasp-java-html-sanitizer/0.1+r88-2

[Markus Koschany]

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

Please unblock package owasp-java-html-sanitizer

The libjsr305-java-doc package was removed from Debian but it is not
really required to build owasp-java-html-sanitizer.

unblock owasp-java-html-sanitizer/0.1+r88-2

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#924279: sbuild-debian-developer-setup fails within docker

[Tong Sun]

On Sun, Mar 10, 2019 at 11:13 PM Johannes Schauer wrote:
>
> Quoting Tong Sun (2019-03-10 23:57:17)
> > When I run sbuild-debian-developer-setup within docker, this is what I'll 
> > get:
> >
> > root/# sbuild-debian-developer-setup
> > Please run sudo /usr/bin/sbuild-debian-developer-setup at
> > /usr/bin/sbuild-debian-developer-setup line 40.
> > root/# /usr/bin/sbuild-debian-developer-setup
> > Please run sudo /usr/bin/sbuild-debian-developer-setup at
> > /usr/bin/sbuild-debian-developer-setup line 40.
> >
> > A quick web search reveals that sbuild-debian-developer-setup has been
> > working within docker before so please consider fixing it.
>
> did you consider following the instruction that you see twice in the output
> above?

OH! I found I have to read your comment a second time before realizing
what you were saying.

OK, going pass that now I'm facing another problem:

$ sudo /usr/bin/sbuild-debian-developer-setup
. . .
I: SUITE: unstable
I: TARGET: /srv/chroot/unstable-amd64-sbuild
I: MIRROR: http://localhost:3142/deb.debian.org/debian
I: Running debootstrap --arch=amd64 --variant=buildd --verbose
--include=fakeroot,build-essential,eatmydata --components=main
--resolve-deps --no-merged-usr unstable
/srv/chroot/unstable-amd64-sbuild
http://localhost:3142/deb.debian.org/debian
I: Target architecture can be executed
I: Retrieving InRelease
I: Retrieving Release
E: Failed getting release file
http://localhost:3142/deb.debian.org/debian/dists/unstable/Release
E: Error running debootstrap at /usr/bin/sbuild-createchroot line 424.
sbuild-createchroot failed:  at /usr/bin/sbuild-debian-developer-setup line 53.

It failed getting release file.

Is it only me getting above? Thx

Bug#923573: more example

[sergio]

openwrt% make menuconfig
Checking ... ok.
...
Checking ... ok.

Build dependency: Please build with umask 022 - other values produce 
broken packages


--
sergio.

Bug#894174: gcalcli: --nodeclined error

[Unit 193]

Howdy,

Can you take a look and see if you can still reproduce this issue with 4.0.4-1? 
This looks to me as if it should be fixed, and I did not get any traceback when 
I tried using the aforementioned option.


~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

Bug#924363: wget: segfault when using --convert-links [stretch only]

[Christoph Biedl]

Package: wget
Version: 1.18-5+deb9u2
Severity: important
Tags: security
Tags: patch
Fixed: 1.20.1-1

Dear maintainer,

the 09-stretch version of wget --convert-links fails if when
encountering an embedded image and trying to parse this as a link.


How to repeat

Save the following file as "index.html" in the webroot of a web server
under your control. In the given example it's "localhost".




title







Run "wget --convert-links http://localhost/index.html --debug"


Observed:

| (...)
| Length: 161 [text/html]
| Saving to: ‘index.html’
| 
| index.html  100%[=>]  
   161  --.-KB/sin 0s  
| 
| 2019-03-12 00:00:00 (12,1 MB/s) - ‘index.html’ saved [161/161]
| 
| Scanning index.html (from http://localhost/index.html)
| Loaded index.html (size 161).
| URI encoding = ‘UTF-8’
| index.html: merge(‘http://localhost/index.html’, 
‘data:image/gif;base64,’)
 -> 
data:image/gif;base64,
| index.html: merged link 
"data:image/gif;base64,"
 doesn't parse.
| Segmentation fault


Expected:

| (...)
| Length: 161 [text/html]
| Saving to: ‘index.html’
| 
| index.html  100%[=>]  
   161  --.-KB/sin 0s  
| 
| 2019-03-12 00:00:00 (16,4 MB/s) - ‘index.html’ saved [161/161]
| 
| Scanning index.html (from http://localhost/index.html)
| Loaded index.html (size 161).
| URI encoding = ‘UTF-8’
| index.html: merge(‘http://localhost/index.html’, 
‘data:image/gif;base64,’)
 -> 
data:image/gif;base64,
| index.html: merged link 
"data:image/gif;base64,"
 doesn't parse.
| no-follow in index.html: 0
| Converting links in index.html... nothing to do.
| Converted links in 1 files in 0,001 seconds.

This was fixed in 10-buster/sid (1.20), and the change is fairly
simple, see attached patch. Please apply when convenient.

The 08-jessie version is not affected.

Cheers,
Christoph


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

Kernel: Linux 4.19.26 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages wget depends on:
ii  libc62.24-11+deb9u4
ii  libgnutls30  3.5.8-5+deb9u4
ii  libidn11 1.33-1
ii  libnettle6   3.3-1+b2
ii  libpcre3 2:8.39-3
ii  libpsl5  0.17.0-3
ii  libuuid1 2.29.2-1+deb9u1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages wget recommends:
ii  ca-certificates  20161130+nmu1+deb9u1

wget suggests no packages.

-- no debconf information

--- a/src/html-url.c
+++ b/src/html-url.c
@@ -729,8 +729,11 @@
 srcset + url_end);
   struct urlpos *up = append_url (url_text, base_ind + url_start,
   url_end - url_start, ctx);
-  up->link_inline_p = 1;
-  up->link_noquote_html_p = 1;
+  if (up)
+{
+  up->link_inline_p = 1;
+  up->link_noquote_html_p = 1;
+}
   xfree (url_text);
 }
 


signature.asc
Description: PGP signature

Bug#924362: package fails to configure (postinst)

[Adam Di Carlo]

Package: chkrootkit
Version: 0.52-3
Severity: important

On a system running buster, I just had a failure upgrading the package.

I put 'set -x' in chkrootkit.postinst so that we can see where its
failing.  Here's the output:

Setting up chkrootkit (0.52-3) ...
+ . /usr/share/debconf/confmodule
+ [ !  ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [  ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/chkrootkit.postinst 
configure 0.52-2
dpkg: error processing package chkrootkit (--configure):
 installed chkrootkit package post-installation script subprocess returned 
error exit status 128

With or without that 'set -x' in the postinst, debconf/frontend is
barfing out silently:

# /usr/share/debconf/frontend /var/lib/dpkg/info/chkrootkit.postinst configure 
0.52-2
# echo $?
128

I'm not clear how to further debug this but please let me know if I
can help in any way.

--
...Adam Di Carlo...

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

Kernel: Linux 4.19.0-2-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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chkrootkit depends on:
ii  binutils   2.31.1-15
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-8
ii  net-tools  1.60+git20180626.aebd88e-1
ii  openssh-client 1:7.9p1-6
ii  procps 2:3.3.15-2

chkrootkit recommends no packages.

chkrootkit suggests no packages.

-- debconf information:
* chkrootkit/diff_mode: true
* chkrootkit/run_daily: true
* chkrootkit/run_daily_opts: -q -n

Bug#921159: Can't enter second option

[Gabriel F. T. Gomes]

On Sun, Mar 10 2019, Gabriel F. T. Gomes wrote:
> 
> https://github.com/scop/bash-completion/pull/291

Fixed upstream [1]. When a new upstream version gets released, I'll
close this bug report.

[1] 
https://github.com/scop/bash-completion/commit/dd80f35279afd4f056dc191767b9869c9649d476

Bug#924361: smcroute: racy systemd unit start (and autopkgtest failure)

[Steve Langasek]

Source: smcroute
Version: 2.4.2-4
Severity: important
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco

Hi Joachim,

Thanks for the fixes to the smcroute autopkgtests in 2.4.2-4.  I've synced
this new version into Ubuntu, and the autopkgtests have now passed on all
architectures *except* for i386:

autopkgtest [11:06:00]: test daemon-init-scripts: [---
1..11
ok 1 - Starting smcroute (via systemctl): smcroute.service.
# 
ok 2 - smcroute is running (pid 888)
ok 3 - stopping smcroute
ok 4 - smcroute is really stopped
ok 5 - stopping smcroute twice in a row
ok 6 - smcroute is really stopped
ok 7 - starting smcroute
not ok 8 - smcroute is really running
#   Failed test 'smcroute is really running'
#   at /tmp/autopkgtest.Fz4BvX/build.HSu/src/debian/tests/daemon-init-scripts 
line 36.
#  got: '1'
# expected: '0'
ok 9 - smcroute pid changed ( != 888)
ok 10 - starting smcroute twice in a row
ok 11 - smcroute is really running (pid 1147)
# Looks like you failed 1 test of 11.
autopkgtest [11:06:01]: test daemon-init-scripts: ---]

  (http://autopkgtest.ubuntu.com/packages/s/smcroute/disco/i386)

Considering that the behavior of the tests here is to: check whether
smcroute is running, then restart it, then check again if it's running; and
only the first check fails; this looks to me like it might be a startup
race.

Examining the systemd unit for this service, I see that there is definitely
a startup race present.  smcroute.service.in has:

[Service]
Type=simple
ExecStart=@SBINDIR@/smcrouted -n -s

And systemd.service(5) has this to say about Type=simple:

   In this mode, if the process offers functionality to other
   processes on the system, its communication channels should be
   installed before the daemon is started up (e.g.  sockets set up
   by systemd, via socket activation), as systemd will immediately
   proceed starting follow-up units.

So, since you are starting the service and then immediately checking if the
service is running (using pgrep), it's possible that this is running into a
race because systemd is returning success immediately.  But even if that's
not the cause of the autopkgtest failure, since smcrouted is a daemon that
provides a socket IPC interface, this would still be a bug (race condition)
in the startup of the service since systemd can definitely return before
smcrouted is listening on the socket.

If on the other hand this is NOT the cause of the i386 test failure, then I
think the tests will need to have their verbosity increased in order to
debug it.  Perhaps checking the output of 'service smcrouted status' would
be useful here.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#924309: RM: passenger/5.0.30-1

[Nicolas Braud-Santoni]

On Mon, Mar 11, 2019 at 07:53:44PM +0100, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi Nicolas

Hi Paul,

> On 11-03-2019 13:29, Nicolas Braud-Santoni wrote:
> > Passenger has had an open, grave security bug open since December 2017 
> > (#884463)
> > and hasn't been uploaded to since August 2016.
> > 
> > As far as I can tell, no other package will be adversely impacted by the
> > removal.
> 
> passenger ships libapache2-mod-passenger
> puppet-master-passenger depends on libapache2-mod-passenger
> puppet-master-passenger is build by puppet

Indeed! I misread while checking, saw -passenger, thought that was a passenger
package...

Thanks for the correction!


> DSA uses puppet to control our infrastructure

I'm aware  :)

Generally, there are probably quite a few users of Puppet in Debian,
it's a popular config management system.


> I don't think we can remove passenger without work. How did you come to
> the conclusion that no other packages are impacted?

Is there no way to run the puppet master without passenger?

If so, then we probably /have to/ fix Passenger for Buster. In that case I can
package an up-to-date version to fix the security issue, but I'm not
volunteering to maintain it permanently.


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#924053: Find /.disk/info patch

[adrian15]

I attach a patch that makes Secure Boot minimal image minimal grub.cfg
to seach for /disk/.info instead of /live/vmlinuz.

This fixes unbootable Secure Boot (even if you boot with Secure Boot
turned off) when live-build is setup to build with more than one linux
kernel flavour.

This has been tested in:
* HP250 G6 2X60EA with UEFI Boot and Secure Boot turned off (Boot from
UEFI USB)
* Tianacore (Boot from UEFI CDROM)

( Note: The actual test had this additional patch:
https://github.com/rescatux/live-build/commit/ad11d1c44909466baa259c2716d126dc9bc54080.patch
applied to it.

This enables the final user to use:
--linux-flavours "686 amd64:amd64"
)

Thus I conclude it works in binary_iso outputs.
The same thing that happens with grub-efi enabled outputs.

I never added added grub-efi support for either binary_hdd or
binary_netboot and it seems nobody else added it.

So I guess, as long as we only support binary_iso it's fine for now to
rely on /disk/.info (only generated by xorriso) till we find a better
method (like the one suggested by Thomas).


Thank you.


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>From 8e5f36048559a00abbd7102ab0f7ecb2f278bf4f Mon Sep 17 00:00:00 2001
From: adrian15 
Date: Sat, 9 Mar 2019 14:49:01 +0100
Subject: [PATCH] Detect device media by its /.disk/info file. This fixes
 Secure Boot boot when internal hard disks have /live/vmlinuz files in it.

---
 scripts/build/binary_grub-efi | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/scripts/build/binary_grub-efi b/scripts/build/binary_grub-efi
index 7afa07eb7..6e402683d 100755
--- a/scripts/build/binary_grub-efi
+++ b/scripts/build/binary_grub-efi
@@ -215,12 +215,11 @@ esac
 # look in that partition for a grub.cfg file, and even if it finds it
 # it will not be able to find the vmlinuz and initrd.
 # Drop a minimal grub.cfg in the EFI partition that sets the root and prefix
-# to whatever partition holds the /live/vmlinuz image, and load the grub
+# to whatever partition holds the /.disk/info file, and load the grub
 # config from that same partition.
-# This is what the Ubuntu livecd already does.
 mkdir -p ${_CHROOT_DIR}/grub-efi-temp-cfg
 cat >${_CHROOT_DIR}/grub-efi-temp-cfg/grub.cfg <

Bug#924360: xen-hypervisor-4.11-amd64: HVM Boot failure: "ERR: Bootloader shutdown EFI x64 boot services!"

[Henning]

Package: xen-hypervisor-4.11-amd64
Version: 4.11.1+26-g87f51bf366-3
Severity: important

Dear Maintainer,

   * What led up to the situation?

unfortunately xen hypervisor does not boot on my machine (Asus Prime B360M-C 
Mainboard, in Setup only EFI enabled, Intel VMX Virtalization Technology is 
enabled, too). Installation was done according to https://wiki.debian.org/Xen .

With a serial connection, I get the boot messages (the last line is not visible 
on the HDMI screen):

Loading Xen 4.11-amd64 ...
Loading Linux 4.19.0-2-amd64 ...
Loading initial ramdisk ...
error: no suitable video mode found.
ERR: Bootloader shutdown EFI x64 boot services!

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

"Normal" Linux (intended as dom0) boots perfectly.
By providing load_video on grub2 commandline I do not have the line "error: no 
suitable video mode found." any more. However, the last error line stays the 
same and only reset is possible.
After installing stable first I tried to upgrade/dist-upgrade to testing but 
the problem stays the same.
I already tried to find something with Google related to the error but could 
not find anything.

Kind regards,
Henning


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

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

xen-hypervisor-4.11-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.11-amd64 recommends:
ii  xen-hypervisor-common  4.11.1+26-g87f51bf366-3
ii  xen-utils-4.11 4.11.1+26-g87f51bf366-3

xen-hypervisor-4.11-amd64 suggests no packages.

-- no debconf information

Bug#924359: augustus: hardcoded built-using

[Ivo De Decker]

package: augustus
version: 3.3.2+dfsg-1
severity: serious

Hi,

Augustus has hardcoded built-using:

https://sources.debian.org/src/augustus/3.3.2+dfsg-1/debian/control/?hl=31#L31

"Built-Using: samtools-legacy (= 0.1.19-2)"

The built-using information should be determined based on the version that was
used during the build, not some hardcoded version.

Thanks,

Ivo

Bug#924358: Dependency problems with logind | consolekit

[Christopher Obbard]

Package: lightdm
Version: 1.26.0-4

Depends: logind [linux-any] | consolekit

these packages are not in the buster/sid archives.

Bug#923465: Update alternatives fixes problem

[Robert LeBlanc]

I followed what John did, except I did not uninstall freecad-python2 and
did not install freecad-python3. Running update-alternatives was enough to
resolved the issue. If the new package was supposed to do that, I don't
think it worked, at least upgrading from -4.

rleblanc@riker:~/code$ dpkg -l "*freecad*"
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion   Architecture Description
+++-===-=--===

ii  freecad 0.18~pre1+dfsg1-5 all  Extensible Open
Source CAx program
ii  freecad-common  0.18~pre1+dfsg1-4 all  Extensible Open
Source CAx program - common files
un  freecad-doc(no description
available)
ii  freecad-python2 0.18~pre1+dfsg1-4 amd64Extensible Open
Source CAx program - Python 2 binaries
un  freecad-python3(no description
available)
ii  freecad-runtime 0.18~pre1+dfsg1-4 all  Extensible Open
Source CAx program - runtime files
ii  libfreecad-python2-0.18 0.18~pre1+dfsg1-4 amd64Extensible Open
Source CAx program - Python 2 library files
rleblanc@riker:~/code$ sudo update-alternatives --config freecad
There is only one alternative in link group freecad (providing
/usr/bin/freecad): /usr/lib/freecad/bin/freecad-python2
Nothing to configure.
update-alternatives: warning: forcing reinstallation of alternative
/usr/lib/freecad/bin/freecad-python2 because link group freecad is broken
rleblanc@riker:~/code$ freecad
FreeCAD 0.18, Libs: 0.18R
© Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2019
 #   ###   
 ##  # #   #   #
 # ##     # #   #  #   #
   # # #  # #  #  # #  #   #
 # #      ## # #   #
 # #   ## ## # #   #  ##  ##  ##
 # #       ### # #    ##  ##  ##

(2, 'No such file or directory', '/usr/share/freecad/examples')


Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1

Bug#923465: fixed in freecad 0.18~pre1+dfsg1-5

[Robert LeBlanc]

On Sat, 02 Mar 2019 10:20:00 + Kurt Kremitzki  wrote:
> Source: freecad
> Source-Version: 0.18~pre1+dfsg1-5
>
> We believe that the bug you reported is fixed in the latest version of
> freecad, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 923...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Kurt Kremitzki  (supplier of updated freecad package)

I installed the freecad package from unstable, but I'm still getting the
error

rleblanc@riker:~/code$ sudo apt -t unstable install freecad
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
 libdav1d0 liblivemedia65
Use 'sudo apt autoremove' to remove them.
Suggested packages:
 freecad-doc povray
Recommended packages:
 calculix-ccx graphviz
The following packages will be upgraded:
 freecad
1 upgraded, 0 newly installed, 0 to remove and 259 not upgraded.
Need to get 32.9 kB of archives.
After this operation, 4,096 B of additional disk space will be used.
Get:1 http://mirrors.xmission.com/debian unstable/main amd64 freecad all
0.18~pre1+dfsg1-5 [32.9 kB]
Fetched 32.9 kB in 0s (90.3 kB/s)
Reading changelogs... Done
(Reading database ... 401462 files and directories currently installed.)
Preparing to unpack .../freecad_0.18~pre1+dfsg1-5_all.deb ...
Unpacking freecad (0.18~pre1+dfsg1-5) over (0.18~pre1+dfsg1-4) ...
Setting up freecad (0.18~pre1+dfsg1-5) ...
Processing triggers for shared-mime-info (1.10-1) ...
rleblanc@riker:~/code$ freecad
FreeCAD 0.18, Libs: 0.18R
© Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2019
 #   ###   
 ##  # #   #   #
 # ##     # #   #  #   #
   # # #  # #  #  # #  #   #
 # #      ## # #   #
 # #   ## ## # #   #  ##  ##  ##
 # #       ### # #    ##  ##  ##

No module named StartGui
Traceback (most recent call last):


 File "", line 43, in Initialize




rleblanc@riker:~/code$ dpkg -l freecad
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--==

ii  freecad0.18~pre1+dfsg1-5 all  Extensible Open Source
CAx program

Bug#924357: dillo: ddg search string in dillorc results in non-useful links

[liftof+dbug]

Package: dillo
Version: 3.0.4-2+b1
Severity: normal

Dear Maintainer,

When Dillo's search function is used with duckduckgo.com, the
resulting links lead to a blank page.

By slightly modifying dillorc, the problem is eliminated:

search_url="dd DuckDuckGo (https) https://duckduckgo.com/lite/?kp=-1=%s;

needs to be:

search_url="dd DuckDuckGo (https) https://duckduckgo.com/lite/?kp=-1=%s=-1;


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

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

Versions of packages dillo depends on:
ii  libc62.19-18+deb8u10
ii  libfltk1.3   1.3.2-6+b1
ii  libgcc1  1:4.9.2-10+deb8u2
ii  libjpeg62-turbo  1:1.3.1-12+deb8u1
ii  libpng12-0   1.2.50-2+deb8u3
ii  libssl1.0.0  1.0.1t-1+deb8u11
ii  libstdc++6   4.9.2-10+deb8u2
ii  libx11-6 2:1.6.2-3+deb8u2
ii  wget 1.16-1+deb8u5
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages dillo recommends:
ii  perl  5.20.2-3+deb8u12

dillo suggests no packages.

-- no debconf information

Bug#924356: google-authenticator: FTBFS

[peterc]

Source: google-authenticator
Version: 20170702-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

I do:
   apt-get source google-authenticator
   cd google-authenticator-20170702
   fakeroot make -f debian/rules binary

and see ...

make[3]: Entering directory 
'/home/peterc/src/work/oauth/google-authenticator-20170702/libpam'
FAIL: tests/pam_google_authenticator_unittest
=
   google-authenticator 1.03: ./test-suite.log
=

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/pam_google_authenticator_unittest
=

pam_google_authenticator_unittest: 
tests/pam_google_authenticator_unittest.c:335: main: Assertion 
`num_prompts_shown == (expected_bad_prompts_shown)' failed.
Secret file "/tmp/.google_authenticator_GjoQkr" must be owned by "peterc"
FAIL tests/pam_google_authenticator_unittest (exit status: 1)


Testsuite summary for google-authenticator 1.03

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to hab...@google.com

make[3]: *** [Makefile:1283: test-suite.log] Error 1



It turns out you can't build the whole thing in one step

I needed to do:
  make -f debian/rules binary
  
  create-stamp debian/debhelper-build-stamp
  dh_testroot -O--sourcedirectory=libpam
  dh_testroot: You must run this as root (or use fakeroot).
make: *** [debian/rules:13: binary] Error 255

then repeat with
  fakeroot make -f debian/rules binary


Peter C
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, armel, i386, powerpc, arm64, riscv64

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

Bug#924060: Serious regression in systemd 215-17+deb8u10

[Michael Biebl]

Am 11.03.19 um 19:17 schrieb Markus Koschany:
> 
> Am 11.03.19 um 15:51 schrieb Dan Poltawski:
>> Thanks for your responses. One of my colleagues has been looking into this 
>> trying to get the bottom of it and we do seem to have identified a memory 
>> leak which isn't present on stretch. I note the report posted to the list 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924060.
> 
> [...]
> 
> Thank you for sharing your analysis with us. I will prepare a regression 
> update shortly.
> It appears the confusion stems from the fact that CVE-2018-16864 was already 
> addressed
> by version 215-17+deb8u9. Thus nobody saw a connection between the memory 
> leak and the recent
> upload which deals with another issue.

Thanks, Markus.

Also big thanks to the debian-lts team in general for backporting those
security fixes for the systemd package in old-stable.

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

Bug#924355: RM: cuyo/2.0.0brl1-3

[Bernhard R. Link]

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

Please consider removing cuyo from buster. The version in testing
currently is an old forked version that is in no good shape.
While there is an ITA for it (#916692), that didn't got to a new upload
before the freeze.

Also given that it is only some small game there should be no harm in
having one Debian release without it.

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC

Bug#924354: unblock: php7.3/7.3.3-1

[Moritz Muehlenhoff]

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

Please unblock package php7.3

It fixes the recent security issues by following 7.3.x (we'll also
follow 7.3.x releases in buster-security as we did with 7.0.x in
stretch-security).

unblock php7.3/7.3.3-1

Cheers,
Moritz

Bug#924352: CVE-2018-16384

[Moritz Muehlenhoff]

Package: modsecurity-crs
Severity: normal

Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16384

(It seems questionable to assign a CVE ID to modsecurity-crs for this from my 
POV)

Cheers,
Moritz

Bug#924353: CVE-2018-20593

[Moritz Muehlenhoff]

Source: mxml
Severity: important
Tags: security

Please see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20592
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20593
https://github.com/michaelrsweet/mxml/issues/237

Cheers,
Moritz

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Richard Laager]

Can we narrow this down to a reproducer? It sounds like something like
this would work:



0) Configure two different pools where you can tell the servers apart.
1) Stop ntpd.
2) Break your DNS.
3) Start ntpd. Wait a few seconds for it to try to resolve and fail.
4) Fix your DNS.

Expected results:
ntpd recovers (successfully resolves the pools' DNS records) relatively
quickly. Most importantly, when ntpd recovers, it recovers for both
pools equally.

Actual results:
Only the last configured pool recovers right away. The other one takes 5
or 10 minutes.



Can you try a few more things:

1) Does deleting the nameservers in /etc/resolv.conf work for step 2, or
more to the point, does putting them back in /etc/resolv.conf work for
step 4?

2) I doubt it matters, but can you set the poll intervals the same on
the two pools, to eliminate that variable?

3) If you reduce minsane to 4, what happens? Does it do the same thing,
never spin up the second pool, or (far less likely) spin them both up
normally? I wonder if ntpd is only "recovering" the second pool because
it is below minsane.

-- 
Richard

Bug#924351: CVE-2018-16647 CVE-2018-16648

[Moritz Muehlenhoff]

Package: mupdf
Version: 1.14.0+ds1-3
Severity: grave
Tags: security

CVE-2018-16648:
https://bugs.ghostscript.com/show_bug.cgi?id=699685
http://www.ghostscript.com/cgi-bin/findgit.cgi?38f883fe129a5e89306252a4676eaaf4bc968824

CVE-2018-16647:
https://bugs.ghostscript.com/show_bug.cgi?id=699686
http://www.ghostscript.com/cgi-bin/findgit.cgi?351c99d8ce23bbf7099dbd52771a095f67e45a2c

Cheers,
Moritz
 

 

Bug#924312: stunnel4: Fails to stop with sysvinit: start-stop-daemon: matching only on non-root pidfile /var/lib/stunnel4///stunnel4.pid is insecure

[Axel Beckert]

Hi Peter,

Peter Pentchev wrote:
> > […], this looks like a bug in lsb-base. And indeed, it is and
> > is also already reported: https://bugs.debian.org/921558
> > 
> > Reassigning accordingly.
> 
> Thanks for reporting this and for your analysis!

You're welcome.

> I came up with the same result […] To be honest, I don't think I
> should upload stunnel with a patch that makes the init script use
> the LSB start_daemon function to start the process and then uses
> start-stop-daemon directly to stop it; […] I would prefer some kind
> of change in init-functions that would let me continue to use the
> LSB shell functions.

*nod* I submitted a patch to #921558 which seems to fix the issue for
at least stunnel, but I think it should get some more testing before
uploading that as a fix.

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

Bug#924350: libofx: CVE-2019-9656

[Salvatore Bonaccorso]

Source: libofx
Version: 1:0.9.14-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libofx/libofx/issues/22

Hi,

The following vulnerability was published for libofx.

CVE-2019-9656[0]:
| An issue was discovered in LibOFX 0.9.14. There is a NULL pointer
| dereference in the function OFXApplication::startElement in the file
| lib/ofx_sgml.cpp, as demonstrated by ofxdump.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9656
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9656
[1] https://github.com/libofx/libofx/issues/22

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#924349: linux-image-4.19.0-2-amd64: IPv6 reverse path filtering incorrectly removes IPv6 traffic from bridge

[Ralf Jung]

Package: src:linux
Version: 4.19.16-1
Severity: normal

Dear Maintainer,

since a recent update, IPv6 communication between two of my VMs stopped working.
You can see some of the debugging effort at
.  It turned out that
setting IPv6_rpfilter=no in /etc/firewalld/firewalld.conf fixes the problem---so
the ip6tables reverse path filtering is incorrectly dropping packets here.

A self-compiled upstream 4.20.14 kernel does not show this problem, but the
latest kernel in testing still does.

Kind regards,
Ralf

-- Package-specific info:
** Version:
Linux version 4.19.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-14)) #1 SMP Debian 4.19.16-1 (2019-01-17)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-2-amd64 root=/dev/mapper/vg-root ro quiet splash

** Tainted: UOE (12352)
 * Userspace-defined naughtiness.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20ENCTO1WW
product_version: ThinkPad P50
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N1EET79W (1.52 )
board_vendor: LENOVO
board_name: 20ENCTO1WW
board_version: Not Defined

** Loaded modules:
nfnetlink_queue
nfnetlink_log
vhost_net
vhost
tap
xt_CHECKSUM
tun
ipt_MASQUERADE
nf_conntrack_netlink
xfrm_user
xfrm_algo
xt_addrtype
iptable_filter
br_netfilter
bridge
stp
llc
overlay
pci_stub
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
ctr
ccm
xt_tcpudp
ip6t_rpfilter
ip6t_REJECT
nf_reject_ipv6
ipt_REJECT
nf_reject_ipv4
xt_conntrack
nft_counter
devlink
nft_chain_nat_ipv6
nf_nat_ipv6
nft_chain_route_ipv6
nft_chain_nat_ipv4
nf_nat_ipv4
nf_nat
nft_chain_route_ipv4
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
ip6_tables
nft_compat
ip_set
nf_tables
nfnetlink
bnep
binfmt_misc
nls_ascii
arc4
nls_cp437
vfat
fat
btusb
btrtl
btbcm
btintel
bluetooth
uvcvideo
videobuf2_vmalloc
iwlmvm
videobuf2_memops
intel_rapl
videobuf2_v4l2
videobuf2_common
x86_pkg_temp_thermal
intel_powerclamp
drbg
mac80211
videodev
ansi_cprng
snd_hda_codec_realtek
snd_hda_codec_generic
media
coretemp
ecdh_generic
kvm_intel
snd_hda_intel
kvm
snd_hda_codec
iwlwifi
snd_hda_core
irqbypass
tpm_tis
snd_hwdep
tpm_tis_core
efi_pstore
rtsx_pci_ms
joydev
tpm
snd_pcm
intel_cstate
thinkpad_acpi
snd_timer
cfg80211
intel_uncore
serio_raw
memstick
wmi_bmof
nvram
mei_me
intel_rapl_perf
iTCO_wdt
iTCO_vendor_support
sg
mei
efivars
pcspkr
intel_pch_thermal
ie31200_edac
rng_core
snd
soundcore
rfkill
ac
battery
evdev
pcc_cpufreq
nfsd
cuse
fuse
auth_rpcgss
nfs_acl
parport_pc
lockd
ppdev
grace
lp
sunrpc
parport
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
btrfs
zstd_decompress
zstd_compress
xxhash
algif_skcipher
af_alg
dm_crypt
dm_mod
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
hid_cherry
hid_generic
usbhid
hid
sd_mod
nouveau
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
pcbc
i915
rtsx_pci_sdmmc
mmc_core
mxm_wmi
ttm
ahci
i2c_algo_bit
libahci
xhci_pci
drm_kms_helper
rtsx_pci
psmouse
xhci_hcd
libata
aesni_intel
aes_x86_64
drm
usbcore
e1000e
crypto_simd
cryptd
scsi_mod
glue_helper
i2c_i801
usb_common
thermal
wmi
video
button

** Network interface configuration:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp0s31f6:  mtu 1500 qdisc pfifo_fast 
state DOWN group default qlen 1000
link/ether c8:5b:76:1b:c1:50 brd ff:ff:ff:ff:ff:ff
3: wlp2s0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether e4:a4:71:65:d2:a4 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.30/24 brd 192.168.178.255 scope global dynamic 
noprefixroute wlp2s0
   valid_lft 863824sec preferred_lft 863824sec
inet6 2a01:c23:7c45:b400:8f5e:4a73:f0b5:5280/64 scope global dynamic 
noprefixroute 
   valid_lft 7126sec preferred_lft 3526sec
inet6 fe80::bcf2:b485:9f96:e957/64 scope link noprefixroute 
   valid_lft forever preferred_lft forever
4: docker0:  mtu 1500 qdisc noqueue state 
DOWN group default 
link/ether 02:42:d6:da:98:4e brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
   valid_lft forever preferred_lft forever
5: virbr0:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
link/ether 52:54:00:f5:09:38 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
   valid_lft forever preferred_lft forever
6: virbr0-nic:  mtu 1500 qdisc pfifo_fast master virbr0 
state 

Bug#924348: CVE-2019-7629

[Moritz Muehlenhoff]

Package: tintin++
Severity: grave
Tags: security

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

Cheers,
Moritz

Bug#924347: ITP: golang-github-hashicorp-go-safetemp -- Functions for working safely with temporary files and directories.

[Aman Verma]

Package: wnpp
Severity: wishlist
Owner: Aman Verma 

* Package name: golang-github-hashicorp-go-safetemp
  Version : 1.0.0-1
  Upstream Author : HashiCorp
* URL : https://github.com/hashicorp/go-safetemp
* License : MPL-2.0
  Programming Lang: Go
  Description : Functions for working safely with temporary files and
directories.
 Functions for safely working with temporary directories and files.The Go
standard
 library provides the excellent ioutil package for working with temporary
directories
 and files. This library builds on top of that to provide safe abstractions
above that.

TODO: I will maintain this package under Debian-Go team

Bug#918754: Update

[Andrew Latham]

Escalation from 'su' lacked the path. I was able to 'su -' and access the
correct paths from the user ENVIRONMENT.

-- 
- Andrew "lathama" Latham -

Bug#923782: Relax dependency on faraday to allow updating ruby-faraday

[Vincent Bernat]

Package: ruby-puppet-forge
Followup-For: Bug #923782

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

With the provided patch, I am able to use librarian-puppet without any
issue. Unless someone protests, I'll do a NMU next week to fix this
bug.

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

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

Versions of packages ruby-puppet-forge depends on:
ii  ruby 1:2.5.1
ii  ruby-faraday 0.15.4-3
ii  ruby-faraday-middleware  0.12.2-1
ii  ruby-gettext-setup   0.30-2
ii  ruby-minitar 0.6.1-1
ii  ruby-semantic-puppet 1.0.2-1

ruby-puppet-forge recommends no packages.

ruby-puppet-forge suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlyG0dsSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX50hsP/2mkf0f5yvdlrXBQk/lVQKoNNEKpqUGV
Gm2dyXPENL5dUrbq6L/5R6T8RpqIYmTbjs5Y2/AYl73DJflFI3veeHZ/VLly36QN
QDeHMyIVwLxA0n002Gj7jTOsRkHzfgAxgGYkplyg6OObYA4ol4Jw8VMyOt2a3DLj
29kYKTmR8MXvuAGBSiedj9cp7wcsk61jaYlB+4NGko/BDHIzjG2rTr/xTwMyBI8r
nREX3uNtsCx3OEJMujedZsksZ2lq0bNA5pihnSkZTOWC6rzjMvei13pN+3iHA3GW
nXRq07u9yh2AR5jPBvv75T7gFfRwI+qpi5QXWHieho+LOvg8Usn0NoMIpiywEITN
a1D/0WO8Cxkc8h7UXENv5L9wUtMGbqdF64qO/e4ryWw9AtkcySI+WECDzXjXL0cz
3brEywRCOnyjGKZuzZNgaFgh9Ml0R2iv1WrAskx5TsO/VUQYvHdj06Pa6W+lB+1X
gRke6GlZh7RK3DsZf34+fLNqx4oz/S47PO/pfs9i/M+r/AeytdCovb0hBIV2KDK9
cRnPq9HNEMtD4IFnN3Pquw9yAegmkb4Qctva11sCj66muY7lEYs3onF3pPxfJ4rB
wv90TSpDALJ4Do9ZPH2hk8ZkYob/NZ5C5ThX7rvTfUpDKKa9H5iK94mWFNY/rOJl
zwWAAw6WfAxj
=wiVz
-END PGP SIGNATURE-

Bug#922938: RFS: python-css-parser/1.0.4-1~bpo9+1

[Nicholas D Steeves]

Hi Chris,

If you have a minute would you please sponsor this backport and/or
grant me DM permissions for it?  I maintain it on the DPMT and my key
is E2A6261E3900AED7CDC667085A8830475F7D1061

A stretch-backport of python-css-parser is needed to update the bpo of
calibre, and a recent version of calibre is needed to support users
who upgraded their Kobos (probably also affects Kindles) to late 2018
firmware.

Link to the dsc is at the bottom of this email.

On Thu, Feb 21, 2019 at 09:15:08PM -0700, Nicholas D Steeves wrote:
> Package: sponsorship-requests
> Severity: normal
> Justification: necessary for to update the bpo for Calibre
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "python-css-parser"
> 
> Package name: python-css-parser
> Version : 1.0.4-1~bpo9+1
> Upstream Author : Christof Hoeke, Walter Doerwald,
>   and Kovid Goyal 
> URL : https://github.com/ebook-utils/css-parser
> License : LGPL-3+
> Section : python
> 
> It builds these binary packages:
> 
>   python-css-parser - CSS related utilities (parsing, serialization, etc) for 
> Python 2
>   python3-css-parser - CSS related utilities (parsing, serialization, etc) 
> for Python 3
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/python-css-parser
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/p/python-css-parser/python-css-parser_1.0.4-1~bpo9+1.dsc
> 

Thanks!
Nicholas


signature.asc
Description: PGP signature

Bug#862373: The State of the YAML

[gregor herrmann]

On Mon, 11 Mar 2019 22:14:13 +0100, Ivo De Decker wrote:

> Control: tags -1 buster-ignore

Thanks.
 
> > So I guess we have to consider if we're happy with the ability to
> > turn off loading objects and recommend it to consumers and close the
> > bugs; or if we want to change the defaults, which means setting
> > $YAML::LoadBlessed to 0 in all three packages.
> I guess it might be best to change the default, but that's obviously too late
> for buster. If this options is chosen, it should probably be done soon after
> the buster release, to allow for plenty of time for issues to be discovered
> (and fixed) for bullseye.

Ack; we discussed this on IRC some time ago, and I also had a talk
with one of the upstream developers in August (about an upstream
change of the default), but apparently this slipped off of
everybody's radar afterwards; and we should indeed fix this quickly
in the bullseye cycle.

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Chavela Vargas: Toda Una Vida


signature.asc
Description: Digital Signature

Bug#918754: bash: $PATH in bash does not include /sbin and /usr/sbin

[Andrew Latham]

I just hit this on a fresh install. I was concerned something changed but
found the usermod tool in /usr/sbin/ when needing to append a group.

-- 
- Andrew "lathama" Latham -

Bug#862475: The State of the YAML

[Ivo De Decker]

Control: tags -1 buster-ignore

Hi,

On Fri, May 18, 2018 at 11:09:23AM +0200, gregor herrmann wrote:
> Quick status update on the perl YAML modules and the problem of
> instantiating objects:
> 
> * libyaml-syck-perl has $YAML::LoadBlessed since a long time
> * libyaml-libyaml-perl since 0.69 and libyaml-perl since 1.25 have
>   added $YAML::LoadBlessed as well
> * all three by default set it to 1 
> 
> (and YAML::Tiny is not affected as far as I know)
> 
> So I guess we have to consider if we're happy with the ability to
> turn off loading objects and recommend it to consumers and close the
> bugs; or if we want to change the defaults, which means setting
> $YAML::LoadBlessed to 0 in all three packages.

I guess it might be best to change the default, but that's obviously too late
for buster. If this options is chosen, it should probably be done soon after
the buster release, to allow for plenty of time for issues to be discovered
(and fixed) for bullseye.

Thanks,

Ivo

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Hi Richard,

My observations follow your quote…

> On Mar 11, 2019, at 12:30 PM, Richard Laager  wrote:
> 
> On 3/10/19 4:11 AM, Rick Thomas wrote:
>> If ntpsec implemented the "preempt" option on "peer" directives, the
>> first "peer" would be revisited after a few minutes and all would be
>> well.  But it doesn't.  So the first "peer" is as if it never existed.
> 
> What leads you to this conclusion, specifically about preempt? The way
> pool directives work is that they are re-evaluated until it reaches
> maxclock:
> https://docs.ntpsec.org/latest/discover.html
> 
> I'm not 100% sure how multiple independent pools (like you have here)
> will intersect. It's possible that ntpd is spinning up all the
> associations from the public pool. If only for testing, what happens if
> you comment out the public pool? Does it behave correctly then?
> 
> On 3/11/19 2:46 AM, Rick Thomas wrote:
>> Edited /lib/systemd/system/ntpsec-systemd-netif.path
> 
> As you figured out, this is the wrong place. You want ntpsec.service.
> 
>>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_probe: us.pool.ntp.org, 
>>> cast_flags:8, flags:101
>>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: processing us.pool.ntp.org, 
>>> 8, 101
>>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary 
>>> failure in name resolution
>>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_take_status: 
>>> us.pool.ntp.org=>temp, 9
>>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, 
>>> cast_flags:8, flags:121
>>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: processing 
>>> pool.rcthomas.org, 8, 121
>>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary 
>>> failure in name resolution
>>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_take_status: 
>>> pool.rcthomas.org=>temp, 9
> 
> I agree with your conclusion that DNS is not ready when ntpd started.
> 
>>> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 4 eth0 
>>> 192.168.3.129:123
>>> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 5 eth0 
>>> [fe80::d263:b4ff:fe00:912f%2]:123
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, 
>>> cast_flags:8, flags:121
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_check: processing 
>>> pool.rcthomas.org, 8, 121
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.207
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.111
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.4
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.1.14
> 
> What about this, though? Those are private IP addresses, so I assume
> those are coming from pool.rcthomas.org.
> 
>>> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_take_status: 
>>> pool.rcthomas.org=>good, 8
> 
> This sure looks like it resolved correctly.
> 
> What is the output from:
> ntpq -p
> 
> Also note that the definition of network-online.target can vary and may
> or may not represent what you actually want.
> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
> 
> If there's a bug here, I'd like to get it reported upstream so it can be
> fixed.
> 
> However, I am very skeptical of the idea that ntpd should, by default,
> wait until the network is online before starting. That prevents useful
> configurations like local refclocks, with no advantage if ntpd simply
> retries the network connections periodically, which I believe it is
> supposed to do.
> 
> —
> Richard

You are correct that the private IP addresses are coming from 
“pool.rcthomas.org”
and the public addresses are from “us.pool.ntp.org”.

It may be worth noting that each of the two pools resolves (at any given time) 
to just four IP addresses, and the conf file specifies minsane 5 (so as to 
always have at least one sane server from each of the pools) and minclock 7 (to 
allow two spares if one or more of the servers goes insane).  If that’s not a 
good idea, please correct me.

I’ve tried various combinations and orders of the “pool” statements.

What always happens is that they both are initially rejected; then the last one 
(and only the last one — whether it’s the private one or the public one) 
resolves OK on the next attempt and ntpsec connects to those servers — It 
almost looks as if (for some reason) the first one, having been rejected, is 
forgotten about but (again, for some reason) the last one is remembered and 
retried.

The first pool statement is eventually retried, but not for a period of several 
minutes (5 or 10?)  Something (I don’t know what) causes it to be 
re-considered, and this time (of course) it resolves.

I just last night discovered the re-consideration after a long delay thing. 
Previously I would always loose patience and restart ntpsec before that timeout 
—  so I didn’t see it.

I thought (though I may be wrong) that “preempt” was supposed to shorten that 
timeout to something more reasonable.  Please enlighten me if I’m mistaken!

In any case, the net result is that ntpsec does not 

Bug#818366: synaptic: fails to start under Wayland

[Paul Gevers]

Hi Trevis, all,

On Sun, 10 Mar 2019 20:46:02 +0530 Trevis Schiffer
 wrote:

> Check this commit.
>

>
> Looks like it is fixed on version 0.84.3

The reported failure in one of the recent merged bug reports was for
versions 0.84.3, so I don't think it fixed the issue (completely).

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

Paul



signature.asc
Description: OpenPGP digital signature

Bug#924346: xmltooling: CVE-2019-9628: XML parser class fails to trap exceptions on malformed XML declaration

[Salvatore Bonaccorso]

Source: xmltooling
Version: 3.0.3-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://issues.shibboleth.net/jira/browse/CPPXT-143
Control: found -1 1.6.0-4+deb9u1
Control: found -1 1.6.0-4

Hi,

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

CVE-2019-9628[0]:
XML parser class fails to trap exceptions on malformed XML declaration

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9628
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9628
[1] https://shibboleth.net/community/advisories/secadv_20190311.txt
[2] https://issues.shibboleth.net/jira/browse/CPPXT-143
[3] 
https://git.shibboleth.net/view/?p=cpp-xmltooling.git;a=commit;h=af27c422f551e16989ff6f1722d83614c8550eb5

Regards,
Salvatore

Bug#921558: lsb-base: killproc does not pass name parameter to start-stop-daemon

[Axel Beckert]

Control: tag -1 + patch

Hi Dmitry,

Dmitry Bogatov wrote:
> > base=${1##*/}
> > if [ ! $pidfile ]; then
> > name_param="--name $base --pidfile /var/run/$base.pid"
> > else
> > name_param="--pidfile $pidfile"
> > fi
> >
> > The if clause checks for nonempty $pidfile instead of nonempty $base to
> > decide whether --name is used.
> >
> > Also --pidfile $pidfile is always used, even when $pidfile is empty.
> >
> > I am reportig this as serious since sid's start-stop-daemon requires a
> > name parameter in addition to --pidfile when the pidfile is not owned by
> > root, therefore this bug causes init script failures. (#921205)

#924312 was another one I filed earlier today. Just forcemerged it
into this.

> I believe it would be reasonable to add '--name $base' into `else'
> clause. Opinions?

Sounds sane, I just checked that with #924311 (miredo, uses
start-stop-daemon directly, edited the init script) as well as #924312
(stunnel4, by editing /lib/lsb/init-functions) and it worked in both
cases.

Here's the change I made to /lib/lsb/init-functions (as Dmitry already
suggested):

--- /lib/lsb/init-functions~2018-11-28 20:21:37.0 +0100
+++ /lib/lsb/init-functions 2019-03-11 21:46:41.673767215 +0100
@@ -141,7 +141,7 @@
 if [ ! $pidfile ]; then
 name_param="--name $base --pidfile /var/run/$base.pid"
 else
-name_param="--pidfile $pidfile"
+name_param="--name $base --pidfile $pidfile"
 fi
 
 sig=$(echo ${2:-} | sed -e 's/^-\(.*\)/\1/')

It though wouldn't hurt if e.g. Andreas could check if this change
would have fixed the issue in exim as well.

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


signature.asc
Description: Digital signature

Bug#924312: stunnel4: Fails to stop with sysvinit: start-stop-daemon: matching only on non-root pidfile /var/lib/stunnel4///stunnel4.pid is insecure

[Peter Pentchev]

On Mon, Mar 11, 2019 at 09:28:04PM +0100, Axel Beckert wrote:
> Control: reassign -1 lsb-base
> Control: forcemerge 921558 -1
> Control: affects 921558 + stunnel4
> 
> Hi Paul,
> 
> Paul Gevers wrote:
> > On Mon, 11 Mar 2019 14:15:25 +0100 Axel Beckert  wrote:
> > > Version: 3:5.50-3
> > 
> > ^^^
> > I don't think the bug is only in this version, is it?
> 
> No. But for a reason I did not expect:
> 
> In contrary to the other cases of this issue I run into recently
> (miredo and smokeping), stunnel4's init script doesn't use
> start-stop-daemon directly but via killproc() from
> /lib/lsb/init-functions of lsb-base. And the actual bug seems to be in
> that shell script library:
> 
> 125 # start-stop-daemon uses the same algorithm as "pidofproc" above.
> 126 killproc () {
> 127 local pidfile sig status base name_param is_term_sig OPTIND
> 128 pidfile=
> 129 name_param=
> 130 is_term_sig=
> 131 
> 132 OPTIND=1
> 133 while getopts p: opt ; do
> 134 case "$opt" in
> 135 p)  pidfile="$OPTARG";;
> 136 esac
> 137 done
> 138 shift $(($OPTIND - 1))
> 139 
> 140 base=${1##*/}
> 141 if [ ! $pidfile ]; then
> 142 name_param="--name $base --pidfile /var/run/$base.pid"
> 143 else
> 144 name_param="--pidfile $pidfile"
> 145 fi
> […] […]
> 152 status=0
> 153 if [ ! "$is_term_sig" ]; then
> 154 if [ -n "$sig" ]; then
> 155 /sbin/start-stop-daemon --stop --signal "$sig" \
> 156 --quiet $name_param || status="$?"
> 157 else
> 158 /sbin/start-stop-daemon --stop \
> 159 --retry 5 \
> 160 --quiet $name_param || status="$?"
> 161 fi
> 162 else
> 163 /sbin/start-stop-daemon --stop --quiet \
> 164 --oknodo $name_param || status="$?"
> 165 fi
> 
> Since neither name_param nor any of the start-stop-daemon --stop calls
> contain --exec or -x nor does killproc allow to pass additional
> parameters, this looks like a bug in lsb-base. And indeed, it is and
> is also already reported: https://bugs.debian.org/921558
> 
> Reassigning accordingly.

Thanks for reporting this and for your analysis!  I came up with the
same result (didn't reply since I was still going through the Git log to
see in which version of stunnel the use of killproc was introduced) and
I have a patch for stunnel4 now that uses start-stop-daemon directly,
although this would be a divergence from the upstream source - the
upstream author switched to the LSB killproc several years ago after
seeing that I had made that change in Debian... so it would be a pity
to now say "well, yeah, but you see, it doesn't really work, so let's go
back to looking for the list of processes and sending the signals by
ourselves" :)

To be honest, I don't think I should upload stunnel with a patch that
makes the init script use the LSB start_daemon function to start
the process and then uses start-stop-daemon directly to stop it;
I might make another change that uses start-stop-daemon in both places,
but, honestly, I would prefer some kind of change in init-functions that
would let me continue to use the LSB shell functions.  Even if it means
passing an additional argument to killproc to make it use --exec, this
would still be an acceptable divergence from upstream for me.

> > This bug is currently blocking the migration of stunnel4 to testing
> > which is needed to have openssl migrate. I'd like to do that today
> > because tomorrow the full freeze starts.
> 
> Should be solved now. Thanks for poking me so that I had a closer
> look!

Thanks to both of you for raising this and noting its importance!

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#924345: xastir-data should be Arch: all

[Christoph Berg]

Package: xastir-data
Version: 2.1.0-3
Severity: normal

The multiarch hinter suggests that xastir-data should actually be
"Architecture: all" rather than "any".

Looking at the control file, most of xastir-data's package stanza
looks like it was copied from xastir, but never updated. Same
Description, Depends, Recommends, Suggests. Looks like WIP and never
finalized.

Christoph


signature.asc
Description: PGP signature

Bug#924344: glib2.0: CVE-2019-9633

[Salvatore Bonaccorso]

Source: glib2.0
Version: 2.58.3-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/glib/issues/1649
Control: fixed -1 2.59.2-1

Hi,

The following vulnerability was published for glib2.0, filling a bug
for tracking.

CVE-2019-9633[0]:
| gio/gsocketclient.c in GNOME GLib 2.59.2 does not ensure that a parent
| GTask remains alive during the execution of a connection-attempting
| enumeration, which allows remote attackers to cause a denial of service
| (g_socket_client_connected_callback mishandling and application crash)
| via a crafted web site, as demonstrated by GNOME Web (aka Epiphany).

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9633
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9633
[1] https://gitlab.gnome.org/GNOME/glib/issues/1649

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#924312: stunnel4: Fails to stop with sysvinit: start-stop-daemon: matching only on non-root pidfile /var/lib/stunnel4///stunnel4.pid is insecure

[Axel Beckert]

Control: reassign -1 lsb-base
Control: forcemerge 921558 -1
Control: affects 921558 + stunnel4

Hi Paul,

Paul Gevers wrote:
> On Mon, 11 Mar 2019 14:15:25 +0100 Axel Beckert  wrote:
> > Version: 3:5.50-3
> 
> ^^^
> I don't think the bug is only in this version, is it?

No. But for a reason I did not expect:

In contrary to the other cases of this issue I run into recently
(miredo and smokeping), stunnel4's init script doesn't use
start-stop-daemon directly but via killproc() from
/lib/lsb/init-functions of lsb-base. And the actual bug seems to be in
that shell script library:

125 # start-stop-daemon uses the same algorithm as "pidofproc" above.
126 killproc () {
127 local pidfile sig status base name_param is_term_sig OPTIND
128 pidfile=
129 name_param=
130 is_term_sig=
131 
132 OPTIND=1
133 while getopts p: opt ; do
134 case "$opt" in
135 p)  pidfile="$OPTARG";;
136 esac
137 done
138 shift $(($OPTIND - 1))
139 
140 base=${1##*/}
141 if [ ! $pidfile ]; then
142 name_param="--name $base --pidfile /var/run/$base.pid"
143 else
144 name_param="--pidfile $pidfile"
145 fi
[…] […]
152 status=0
153 if [ ! "$is_term_sig" ]; then
154 if [ -n "$sig" ]; then
155 /sbin/start-stop-daemon --stop --signal "$sig" \
156 --quiet $name_param || status="$?"
157 else
158 /sbin/start-stop-daemon --stop \
159 --retry 5 \
160 --quiet $name_param || status="$?"
161 fi
162 else
163 /sbin/start-stop-daemon --stop --quiet \
164 --oknodo $name_param || status="$?"
165 fi

Since neither name_param nor any of the start-stop-daemon --stop calls
contain --exec or -x nor does killproc allow to pass additional
parameters, this looks like a bug in lsb-base. And indeed, it is and
is also already reported: https://bugs.debian.org/921558

Reassigning accordingly.

> This bug is currently blocking the migration of stunnel4 to testing
> which is needed to have openssl migrate. I'd like to do that today
> because tomorrow the full freeze starts.

Should be solved now. Thanks for poking me so that I had a closer
look!

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


signature.asc
Description: Digital signature

Bug#786887:

[Andreas Hasenack]

New bug opened about this: #924343

Bug#924343: snmpd: default config startup warnings

[Andreas Hasenack]

Package: snmpd
Version: 5.7.3+dfsg-5
Severity: Normal

Dear Maintainer,

this is a follow-up to bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786887 which was
closed because it was filed against a very old version of this
package.

I just tried again with an up-to-date debian sid system, and it still
happens with a default configuration:

root@sid-snmpd-default-monitors:~# > /var/log/syslog
root@sid-snmpd-default-monitors:~# systemctl start snmpd
root@sid-snmpd-default-monitors:~# cat /var/log/syslog
Mar 11 19:45:31 sid-snmpd-default-monitors systemd[1]: Starting Simple
Network Management Protocol (SNMP) Daemon
Mar 11 19:45:31 sid-snmpd-default-monitors systemd[1]: Started Simple
Network Management Protocol (SNMP) Daemon..
Mar 11 19:45:31 sid-snmpd-default-monitors snmpd[385]:
/etc/snmp/snmpd.conf: line 145: Warning: Unknown token:
defaultMonitors.
Mar 11 19:45:31 sid-snmpd-default-monitors snmpd[385]:
/etc/snmp/snmpd.conf: line 147: Warning: Unknown token:
linkUpDownNotifications.
Mar 11 19:45:31 sid-snmpd-default-monitors snmpd[385]: Turning on
AgentX master support.
Mar 11 19:45:31 sid-snmpd-default-monitors snmpd[385]: NET-SNMP version 5.7.3

Line 145 is the line that enabled defaultMonitors (indented like that, btw):
   # generate traps on UCD error conditions
defaultMonitors  yes

There are a number of steps one has to take to get rid of those
warnings, and I'm listing them here in the hopes of helping others,
not necessarily as a guideline on how this should be fixed. I
collected these together from several bug reports and/or comments:
- remove the MIBS= variable definition (to empty) from the systemd service file:
#Environment="MIBS="
- comment the "mibs" line in /etc/snmp/snmp.conf:
#mibs :
- remove ",mteTrigger,mteTriggerConf" from the ExecStart line in the
same systemd service file:
ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g
Debian-snmp -I -smux -f -p /run/snmpd.pid
- reload systemd:
sudo systemctl daemon-reload
- enable non-free and install snmp-mibs-downloader:
sudo apt install snmp-mibs-downloader
- restart snmpd
sudo systemctl restart snmpd

Bug#924341: pygnuplot: FTBFS due to unsatisfiable build-dependency debhelper (= 12)

[Hans Joachim Desserud]

Source: pygnuplot
Version: 0.11.16-1
Severity: serious
Tags: ftbfs

Dear Maintainer,

pygnuplot fails to build because it cannot install its build 
dependencies:

$ sudo apt build-dep pygnuplot
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:pygnuplot : Depends: debhelper (= 12) but 12.1.1 is to be 
installed

E: Unable to correct problems, you have held broken packages.

(see also 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pygnuplot.html)


I assume a >= requirement would resolve this issue, though haven't 
tested if the package builds then.



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

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#924342: ITP: wf-recorder -- screen recorder for wlroots-based compositors

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: wf-recorder
  Version : no release yet
  Upstream Author : Ilia Bozhinov
* URL : https://github.com/ammen99/wf-recorder
* License : MIT
  Programming Lang: C
  Description : screen recorder for wlroots-based compositors

wf-recorder is a utility program for screen recording of wlroots-based
compositors (more specifically, those that support wlr-screencopy-v1 and
xdg-output). Its dependences are ffmpeg, wayland-client and
wayland-protocols.

Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR

[Andras Korn]

On Mon, Mar 11, 2019 at 06:12:06PM +, Dmitry Bogatov wrote:

> > On Fri, Mar 08, 2019 at 02:39:47PM +, Dmitry Bogatov wrote:
> > > [2019-03-07 12:57] Andras Korn 
> > > > part 1 text/plain 218
> > > > Sorry, I sent an earlier version of the patch by mistake.
> > > >
> > > > I'm attaching the correct one, which I tested and which works for me.
> > > > [...]
> > > > -  if (sigc && (stat(STOPIT, ) != -1) && (s.st_mode & S_IXUSR)) {
> > > > +  if ((sigp) || (sigc && (stat(STOPIT, ) != -1) && (s.st_mode & 
> > > > S_IXUSR))) {
> > > 
> > > As far as I can tell by glance on patch, you want SIGPWR trigger reboot.
> > > If so, why don't you create REBOOT file in, say, /etc/rc.local and make
> > > lxc controller to send SIGCONT?
> >
> > No -- I want SIGPWR to trigger a halt.
> >
> > For the purposes of LXC, any signal will do; I just need for a signal to
> > trigger a shutdown regardless of the permissions on runit.stopit and
> > runit.reboot.
> 
> Halt. Fine. But why can't you pre-provision you container with apporiate
> `stop.*' file with apporiate permissions?

Because that adds complexity elsewhere -- /etc/runit/1 as shipped creates
/run/runit.stopit with mode 0, so either all containers would need ot have a
custom /etc/runit/1, or run a custom script to chmod 100 /run/runit.stopit
on every boot, or have an immutable /run/runit.stopit.

It's not just about me; this affects everyone who wants to use runit inside
an lxc container.

My goal is to make using runit as hassle-free as possible, without
sacrificing any of its core values.

> > > By the way, SIGPWR is not in POSIX, according to signal(7).
> >
> > You're right; in that case, maybe we can use SIGQUIT?
> 
> SIGTERM feels better, imho. TERM is graceful termination, while SIGQUIT
> creates coredump. By default.

SIGPWR would be nice to use as the halt signal because it's the lxc default,
so that runit could be a drop-in replacement for sysvinit in LXC containers.

If we're not going to use SIGPWR it's pretty much all the same which signal
we use, because it will need to be configured explicitly in LXC (but that's
acceptable -- POSIX is important enough).

> But this naming only matters if you explain to me, how solution not
> involving changing C code does not suffice. Two lines for convenience in
> this case, three there -- and we all know where it ends.

I'm sorry, I don't buy the slippery slope argument. I'm not adding a DNS
resolver, a DHCP client or a QR encoder, merely making the user interface a
tiny bit more similar to sysvinit's, to make integration easier. This is
entirely in line with The Unix Way: making one program a drop-in replacement
for another such that other programs interfacing with them don't see a
difference unless they need to. It's why bzip2 and gzip take most of the
same switches etc.

Since you apparently don't agree that this is a good idea, should I take the
patch to Gerrit instead?

András

-- 
Warranty is void in case of nuclear war, whether caused by the program or not.

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Hans van Kranenburg]

On 3/11/19 7:34 AM, Juergen Gross wrote:
> 
> I'm not sure. Patch 3 of this series is basically already there (see
> commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
> is patch 4, which should really be easy to do?
> 
> Hans, could you give it a try? You'd need to use a 4.20 kernel at least.
> I can do the official patch posting in case you confirm it working.

Ehm ok, well... This is interesting.

I just built a 4.20.13 (without the patch), and I did it from the Debian
kernel team repo, because then I just get all latest config options like
I would get them in Debian.

I rebooted the HP Z820 with it (with Xen 4.11) and I don't see any
errors similar to the ones I pasted earlier.

I haven't been running any domU on it yet (just installed it), but this
is not what I expected.

xen_extra  : .2-pre
xen_version: 4.11.2-pre
xen_commandline: placeholder dom0_mem=2G,max:2G
dom0_max_vcpus=1-4 com2=115200,8n1 console=com2,vga noreboot=true
xpti=dom0=false,domu=true smt=off clocksource=tsc tsc=stable:socket

Hans

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Richard Laager]

On 3/10/19 4:11 AM, Rick Thomas wrote:
> If ntpsec implemented the "preempt" option on "peer" directives, the
> first "peer" would be revisited after a few minutes and all would be
> well.  But it doesn't.  So the first "peer" is as if it never existed.

What leads you to this conclusion, specifically about preempt? The way
pool directives work is that they are re-evaluated until it reaches
maxclock:
https://docs.ntpsec.org/latest/discover.html

I'm not 100% sure how multiple independent pools (like you have here)
will intersect. It's possible that ntpd is spinning up all the
associations from the public pool. If only for testing, what happens if
you comment out the public pool? Does it behave correctly then?

On 3/11/19 2:46 AM, Rick Thomas wrote:
> Edited /lib/systemd/system/ntpsec-systemd-netif.path

As you figured out, this is the wrong place. You want ntpsec.service.

>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_probe: us.pool.ntp.org, 
>> cast_flags:8, flags:101
>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: processing us.pool.ntp.org, 
>> 8, 101
>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary 
>> failure in name resolution
>> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_take_status: us.pool.ntp.org=>temp, 
>> 9
>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, 
>> cast_flags:8, flags:121
>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: processing 
>> pool.rcthomas.org, 8, 121
>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary 
>> failure in name resolution
>> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_take_status: 
>> pool.rcthomas.org=>temp, 9

I agree with your conclusion that DNS is not ready when ntpd started.

>> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 4 eth0 
>> 192.168.3.129:123
>> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 5 eth0 
>> [fe80::d263:b4ff:fe00:912f%2]:123
>> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, 
>> cast_flags:8, flags:121
>> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_check: processing 
>> pool.rcthomas.org, 8, 121
>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.207
>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.111
>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.4
>> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.1.14

What about this, though? Those are private IP addresses, so I assume
those are coming from pool.rcthomas.org.

>> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_take_status: 
>> pool.rcthomas.org=>good, 8

This sure looks like it resolved correctly.

What is the output from:
ntpq -p

Also note that the definition of network-online.target can vary and may
or may not represent what you actually want.
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

If there's a bug here, I'd like to get it reported upstream so it can be
fixed.

However, I am very skeptical of the idea that ntpd should, by default,
wait until the network is online before starting. That prevents useful
configurations like local refclocks, with no advantage if ntpd simply
retries the network connections periodically, which I believe it is
supposed to do.

-- 
Richard

Bug#907277: autoconf: AC_SEARCH_LIBS for __atomic_foo fails with AC_LANG([C++]) and g++-8

[Paul Gevers]

Hi all,

On 10-03-2019 13:41, Simon McVittie wrote:
> On Thu, 17 Jan 2019 at 11:00:40 -0500, Nick Bowler wrote:
>> I'm not familiar with the library in question but the problem
>> appears to be specific to these __atomic_xyz builtins which seem
>> to get special treatment in g++.  Other builtins I tested do not
>> exhibit such failures.
> 
> Retitling to reflect the scope of the bug.

Does anybody know why gcc got more picky, but ONLY for __atomic_foo?

If it is only __atomic_foo that is failing, can't we special case that?
I.e. if testing for __atomic_foo, pass the test? Maybe only in Debian
and not upstream, albeit I rather have a generic solution, but then it
shouldn't be Debian pulling the boat.

Or is this a ridiculous proposal?

I fear that although this may have limited impact on packages in the
archive, I don't know how many private builds are impacted by this.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#924340: unblock: python2.7/2.7.16-1 python-stdlib-extensions/2.7.16-1 python-defaults/2.7.16-1

[Matthias Klose]

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

Please consider unblocking the python2 packages to the final 2.7.16 release,
basically bumping the version and reporting a final release number in 
sys.version.

Bug#921952: [Pkg-sass-devel] Bug#921952: Don't include in buster without proper commitment to update in stable

[Moritz Mühlenhoff]

On Mon, Mar 11, 2019 at 12:29:10PM +0100, Jonas Smedegaard wrote:
> control: reopen -1
> 
> Quoting Jonas Smedegaard (2019-03-11 12:22:03)
> > Quoting Moritz Muehlenhoff (2019-02-10 14:47:49)
> > > Source: libsass
> > > Severity: serious
> > > 
> > > None of the security bugs filed in the BTS has seen any maintainer 
> > > followup
> > > (dating back to 2017 in some cases), and that's just the tip of the 
> > > iceberg,
> > > the security tracker lists many more.
> > > 
> > > Unless someone steps forward and commits to properly maintain it during 
> > > the
> > > lifetime of a stable release, let's not include it in buster.
> > 
> > I have now looked closer at this issue, and disagree that this package 
> > has a bug of general neglect.  Closing this bugreport accordingly.
> 
> Whoops - I have no idea how I could manage to "investigate" but miss the 
> amount of bugreports that I now see (and are not new).
> 
> Reopening. Sorry for the noise.

In addition there's also a fair number of security issues which don't
even have a bug filed, see
https://security-tracker.debian.org/tracker/source-package/libsass

Cheers,
Moritz

Bug#924339: javahelper regressed building -doc packages

[Matthias Klose]

Package: javahelper
Version: 0.72-5
Severity: serious
Tags: sid buster

javahelper regressed building -doc packages, as seen with the
android-platform-build package. See #924328.

Bug#924312: stunnel4: Fails to stop with sysvinit: start-stop-daemon: matching only on non-root pidfile /var/lib/stunnel4///stunnel4.pid is insecure

[Paul Gevers]

Hi Axel,

On Mon, 11 Mar 2019 14:15:25 +0100 Axel Beckert  wrote:
> Version: 3:5.50-3

^^^
I don't think the bug is only in this version, is it?

> This is caused by the following change in dpkg 1.19.3 from 22 Jan 2019:
> 
>   * start-stop-daemon: Check whether standalone --pidfile use is secure.
> Prompted by Michael Orlitzky .

This bug is currently blocking the migration of stunnel4 to testing
which is needed to have openssl migrate. I'd like to do that today
because tomorrow the full freeze starts.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#924338: unblock: binutils-/gcc -mipsen packages

[Matthias Klose]

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

Please consider unblocking binutils-mipsen, gcc-8-cross-mipsen,
gcc-defaults-mipsen (the gcc-* packages are not yet in testing).

the mips64 packages were removed from the -ports packages, and now removed in
testing from testing when the -ports packages migrated.

Bug#924301: e2fsprogs: e2scrub failure on /

[Theodore Ts'o]

On Mon, Mar 11, 2019 at 09:59:05AM +0100, Vincent Lefevre wrote:
> Package: e2fsprogs
> Version: 1.45.0-1
> Severity: normal
> 
> I got the following mail:
> 
> 
> Date: Sun, 10 Mar 2019 03:10:04 +0100 (CET)
> From: e2sc...@zira.vinc17.org
> To: r...@zira.vinc17.org
> Subject: e2scrub failure on /
> 
> So sorry, the automatic e2scrub of / on zira.vinc17.org failed.
> 
> A log of what happened follows:
> ??? e2scrub@-.service - Online ext4 Metadata Check for /
>Loaded: loaded (/lib/systemd/system/e2scrub@.service; static; vendor 
> preset: enabled)
>Active: failed (Result: exit-code) since Sun 2019-03-10 03:10:04 CET; 28ms 
> ago
>  Docs: man:e2scrub(8)
>   Process: 5133 ExecStart=/sbin/e2scrub -t / (code=exited, status=1/FAILURE)
>  Main PID: 5133 (code=exited, status=1/FAILURE)
> 
> Mar 10 03:10:01 zira systemd[1]: Starting Online ext4 Metadata Check for /...
> Mar 10 03:10:01 zira e2scrub@-[5133]:   Volume group "zira-vg" has 
> insufficient free space (0 extents): 64 required.

Hmm, that message is coming from the lvcreate command.  I'm not sure
why it is failing.   Can you try running:

sudo bash -vx /sbin/e2scrub /

as well as sending me the output of "sudo lvs"

Many thanks!!

- Ted

Bug#924336: dillo: ssl negotiation fails on some sites

[Axel Beckert]

Control: tag -1 + confirmed fixed-upstream
Control: found -1 3.0.5-3
Control: found -1 3.0.5-5
Control: forwarded -1 
http://lists.dillo.org/pipermail/dillo-dev/2018-December/011100.html

Hi,

liftof+d...@gmail.com wrote:
> When I use Dillo to access certain web sites, no content appears
> in the browser window.  When run from an xterm, this message can
> be seen:
> 
> Nav_open_url: new url='https://www.raspberrypi.org/'
> 139903201941136:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 
> alert handshake failure:s23_clnt.c:757:

thanks for the bug report!

Indeed, this seems to happen with quite some sites, probably due to
disabling legacy crypto algorithms. I can reproduce this with dillo on
Debian 9 Stretch as well as on Sid/Buster.

It has been reported upstream already at
http://lists.dillo.org/pipermail/dillo-dev/2018-December/011100.html
and said to be fixed upstream in the development branch, probably by
having switched from OpenSSL to MbedTLS (also already in Debian). But
so far I have been unable to get the current development version of
Dillo to compile. :-/

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

Bug#924337: Please reenable mqtt and varnish

[Bastian Germann]

Source: collectd
Version: 5.8.1-1.2
Severity: important

The mqtt and varnish plugins are disabled because of dependency issues.
The blocking bugs #911265, #911266, and #879471 are resolved. Please
reenable the plugins.

Bug#924309: RM: passenger/5.0.30-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Nicolas

On 11-03-2019 13:29, Nicolas Braud-Santoni wrote:
> Passenger has had an open, grave security bug open since December 2017 
> (#884463)
> and hasn't been uploaded to since August 2016.
> 
> As far as I can tell, no other package will be adversely impacted by the
> removal.

passenger ships libapache2-mod-passenger
puppet-master-passenger depends on libapache2-mod-passenger
puppet-master-passenger is build by puppet
DSA uses puppet to control our infrastructure

I don't think we can remove passenger without work. How did you come to
the conclusion that no other packages are impacted?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#923891: Workarounds?

[Soren Stoutner]

Is there a short-term workaround that will fix the broken login system? 
For example, can Redmine 4.0.1-1 be safely downgraded to 3.4.6-1 or will
that cause database problems?

-- 
Soren Stoutner
Small Business Tech Solutions
so...@smallbusinesstech.net
623-262-6169

Bug#923446: m2crypto: autopkgtest with new version of openssl: Connection refused

[Daniel Stender]

Control: severity -1 serious

For this actually is a FTBFS bug I'm raising its severity.

Thanks,
DS

--
4096R/DF5182C8
https://danielstender.com

Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)

[Thorsten Glaser]

On Mon, 11 Mar 2019, Dmitry Bogatov wrote:

> So, you propose that we:
>  * drop all checks for /forcecheck

No!

>  * document this fact in NEWS file
>  * write documentation, that e[2-4]fs users should use tune2fs tool
>instead

Yes.

//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**!!! NEU !!!** Mit der **tarent Academy** bieten wir ab sofort auch Trainings
und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und
Zukunftstechnologien an. Besuchen Sie uns
auf [www.tarent.de/academy](http://www.tarent.de/academy). Wir freuen uns auf
Ihren Kontakt.

*

Bug#924336: dillo: ssl negotiation fails on some sites

[liftof+dbug]

Package: dillo
Version: 3.0.4-2+b1
Severity: important

Dear Maintainer,

When I use Dillo to access certain web sites, no content appears
in the browser window.  When run from an xterm, this message can
be seen:

Nav_open_url: new url='https://www.raspberrypi.org/'
139903201941136:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
handshake failure:s23_clnt.c:757:

I have also tried various recent live ISOs to confirm the bug
still exists, though I use Debian 8.11 everyday on this computer.

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

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

Versions of packages dillo depends on:
ii  libc62.19-18+deb8u10
ii  libfltk1.3   1.3.2-6+b1
ii  libgcc1  1:4.9.2-10+deb8u2
ii  libjpeg62-turbo  1:1.3.1-12+deb8u1
ii  libpng12-0   1.2.50-2+deb8u3
ii  libssl1.0.0  1.0.1t-1+deb8u11
ii  libstdc++6   4.9.2-10+deb8u2
ii  libx11-6 2:1.6.2-3+deb8u2
ii  wget 1.16-1+deb8u5
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages dillo recommends:
ii  perl  5.20.2-3+deb8u12

dillo suggests no packages.

-- no debconf information

Bug#924060: Serious regression in systemd 215-17+deb8u10

[Markus Koschany]

Am 11.03.19 um 15:51 schrieb Dan Poltawski:
> Thanks for your responses. One of my colleagues has been looking into this 
> trying to get the bottom of it and we do seem to have identified a memory 
> leak which isn't present on stretch. I note the report posted to the list 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924060.

[...]

Thank you for sharing your analysis with us. I will prepare a regression update 
shortly.
It appears the confusion stems from the fact that CVE-2018-16864 was already 
addressed
by version 215-17+deb8u9. Thus nobody saw a connection between the memory leak 
and the recent
upload which deals with another issue.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#924132: runit: Add support for runit in init-system-helpers

[Dmitry Bogatov]

[2019-03-09 21:05] Lorenzo Puliti 
> this is for buster +1
>
> Here is my proposal for adding runit-init support in 
> 'init-system-helpers'; please do not reassign to init-system-helpers
> as this need also some changes in runit and dh-runit to work properly.
> This is still a work in progress but it's enough to do some testing:
>  
>  * for init-system-helpers look here
> https://salsa.debian.org/Lorenzo.ru.g-guest/init-system-helpers
> 
>  * for runit look here
> https://salsa.debian.org/Lorenzo.ru.g-guest/runit/tree/runsvchd+helpers
> (this include also commits for #916973 and for #924038)
>
> For more details and (hopefully) a discussion look here
> https://www.freelists.org/post/debian-runit/Runitinit-support-in-initsystemhelpers

Thank you for your work. It will take me some time to understand your
proposal, see code and think about it.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR

[Dmitry Bogatov]

[2019-03-10 12:09] Andras Korn 
> On Fri, Mar 08, 2019 at 02:39:47PM +, Dmitry Bogatov wrote:
> > [2019-03-07 12:57] Andras Korn 
> > > part 1 text/plain 218
> > > Sorry, I sent an earlier version of the patch by mistake.
> > >
> > > I'm attaching the correct one, which I tested and which works for me.
> > > [...]
> > > -  if (sigc && (stat(STOPIT, ) != -1) && (s.st_mode & S_IXUSR)) {
> > > +  if ((sigp) || (sigc && (stat(STOPIT, ) != -1) && (s.st_mode & 
> > > S_IXUSR))) {
> > 
> > As far as I can tell by glance on patch, you want SIGPWR trigger reboot.
> > If so, why don't you create REBOOT file in, say, /etc/rc.local and make
> > lxc controller to send SIGCONT?
>
> No -- I want SIGPWR to trigger a halt.
>
> For the purposes of LXC, any signal will do; I just need for a signal to
> trigger a shutdown regardless of the permissions on runit.stopit and
> runit.reboot.

Halt. Fine. But why can't you pre-provision you container with apporiate
`stop.*' file with apporiate permissions?

> > By the way, SIGPWR is not in POSIX, according to signal(7).
>
> You're right; in that case, maybe we can use SIGQUIT?

SIGTERM feels better, imho. TERM is graceful termination, while SIGQUIT
creates coredump. By default.

But this naming only matters if you explain to me, how solution not
involving changing C code does not suffice. Two lines for convenience in
this case, three there -- and we all know where it ends.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)

[Dmitry Bogatov]

[2019-03-09 21:57] Thorsten Glaser 
> > But I really want to have some transition plan to get rid of
> > /forcecheck, something like:
>
> … you might like that tune2fs can now (1.45.0-1, not yet in
> buster, officially not likely to make it but we can hope) set
> a flag force_fsck that next boot’s auto e2fsck will honour.
> I’m assuming this works for ext2/ext3/ext4; ask tytso if unsure.
>
> So just print a warning (in the first upload after buster) and
> recommend using that instead, *AND* document in /usr/share/doc/…/
> that the file should not be used any more, and get the reiserfs
> people (and others) to invent something similar. It’s more granular
> (per filesystem) and thus better anyway.

So, you propose that we:

 * drop all checks for /forcecheck
 * document this fact in NEWS file
 * write documentation, that e[2-4]fs users should use tune2fs tool
   instead

Well, fine, but what about reiserfs and minix? And, I can't see
standalone tune2fs even in unstable:

$ apt-file find /bin/tune2fs
android-sdk: /usr/lib/android-sdk/tools/bin/tune2fs
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#924334: ITS: fpart

[Ganael Laplanche]

Package: fpart
Version: 0.9.2-1+b1
Severity: important

Hello,

Following :

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

and

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

I would like to take ownership and update the fpart package.

FYI, I will be using updated source files available here:

https://github.com/martymac/fpart/tree/master/contribs/package/debian

Thanks in advance,
Best regards,

Ganael Laplanche.

-- 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/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (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 fpart depends on:
ii  libc6  2.24-11+deb9u4
ii  rsync  3.1.2-1+deb9u1
ii  sudo   1.8.19p1-2.1

fpart recommends no packages.

fpart suggests no packages.

-- no debconf information

Bug#759339: systemd-cryptsetup-generator: systemd-cryptsetup-generator fails to handle multiple encrypted btrfs volumes in raid1

[Michael Biebl]

Control: tags -1 + moreinfo

Hi Damien

On Tue, 26 Aug 2014 16:58:28 +0200 Damien Clauzel  wrote:
> Yes. But there is also the problem of assembling the btrfs raid1 arrays
> after opening the encrypted volumes.
> 
> Damien Clauzel
> 
> 
> 2014-08-26 16:41 GMT+02:00 Michael Biebl :
> 
> > Am 26.08.2014 15:54, schrieb Damien CLAUZEL:
> > > Package: systemd
> > > Version: 208-8
> > > Severity: normal
> > > File: systemd-cryptsetup-generator
> > >
> > > I am running a system with several disks, containing encrypted volumes
> > > formated in btrfs with raid1.
> > >
> > > After switching to systemd via a dist-upgrade, the encrypted volumes are
> > > not handled anymore during boot.

Is this still an issue with a recent version of systemd?
Ideally test with v241 from unstable/testing or stretch-backports.

If you still encounter any problems, please report your issue upstream
at https://github.com/systemd/systemd/issues/new and report back with
the issue number.

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



signature.asc
Description: OpenPGP digital signature

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

[Santiago Vila]

On Mon, Mar 11, 2019 at 06:34:18PM +0100, Matthias Klose wrote:

> I have no clue, I have never seen that before, and it seems to work fine on 
> the
> buildds, and in the cross-toolchain-base* package's autopkg test.  Starting 
> here
> a build with -j1 to see if it's reproducible.
> 
> Is this seen with gcc-7-cross and gcc-9-cross as well?

It happened to me with the (now removed) gcc-7-cross as well, yes.
In case it helps, these are the logs I had in my last backup:

https://people.debian.org/~sanvila/build-logs/gcc-7-cross/

(Never tried gcc-9-cross yet because my usual target is testing and
sometimes sid).

Thanks a lot.

Bug#924333: FTBFS: missing czech/News/weekly/index.wml

[Cyril Brulebois]

Package: www.debian.org
Severity: normal
User: www.debian@packages.debian.org
Usertags: scripts

Hi,

While working on rebuilding the website within stretch and buster, I've
noticed the following.

The build fails both in stretch and in buster due to a missing file
(czech/News/weekly/index.wml):

make -C weekly
make[3]: Entering directory 
'/home/kibi/debian-www/stretch/webwml/czech/News/weekly'
make[3]: *** No rule to make target 'index.wml', needed by 'index.cs.html'. 
 Stop.
make[3]: Leaving directory 
'/home/kibi/debian-www/stretch/webwml/czech/News/weekly'
../../Makefile.common:79: recipe for target 'weekly' failed
make[2]: *** [weekly] Error 2
make[2]: Leaving directory '/home/kibi/debian-www/stretch/webwml/czech/News'
../Makefile.common:79: recipe for target 'News' failed
make[1]: *** [News] Error 2
make[1]: Leaving directory '/home/kibi/debian-www/stretch/webwml/czech'
Makefile:28: recipe for target 'czech' failed
make: *** [czech] Error 2

This seems to date back to this commit:
  
https://salsa.debian.org/webmaster-team/webwml/commit/0cbd1d8ebfa0d33b09d84e495a0c661e8830dabd

which is from 2007.

If fixing the missing index file doesn't make sense, the parent Makefile
should perhaps not recurse into that subdirectory?


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

Bug#765594: systemd: Attempting to hibernate permanently breaks encrypted swap partition

[Michael Biebl]

Hi Rebecca

On Thu, 16 Oct 2014 22:22:29 +0100 "Rebecca N. Palmer"
 wrote:
> Control: tags -1 patch
> 
> Looks like the "swap=plain" assumption is at 
> src/cryptsetup/cryptsetup.c:162; here's a patch (untested as yet, will 
> try it in the morning if I don't hear anything).
> 
> --- cryptsetup.c  2014-10-16 22:10:00.369584521 +0100
> +++ cryptsetup2.c 2014-10-16 22:13:32.765582134 +0100
> @@ -159,7 +159,7 @@ static int parse_one_option(const char *
>   } else if (streq(option, "tcrypt-system")) {
>   arg_type = CRYPT_TCRYPT;
>   arg_tcrypt_system = true;
> -} else if (STR_IN_SET(option, "plain", "swap", "tmp"))
> +} else if (streq(option, "plain") || (arg_type == NULL && 
> STR_IN_SET(option, "swap", "tmp")))
>   arg_type = CRYPT_PLAIN;
>   else if (startswith(option, "timeout=")) {

Please test, if your problem still exists with a recent version of
systemd (ideally test v241 from unstable/buster or the v241 backport for
stretch).

If you still run into problems and your patch still applies, please
consider forwarding it to upstream as pull request via
https://github.com/systemd/systemd/

We usually only apply patches to Debian which have been reviewed and
accepted upstream.

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



signature.asc
Description: OpenPGP digital signature

Bug#923976: [Pkg-puppet-devel] Bug#923976: Bug#923976: puppet: Reports submitte

[Kienan Stewart]

Hi Apollon,

On Sat, Mar 09, 2019 at 11:24:27PM +0200, Apollon Oikonomopoulos wrote:
> Control: tags -1 - unreproducible
> 
> Hi,
> 
> 
> Thanks for the patch, it should do the trick. However, before applying 
> it I want to be 100% sure that we know what's happening and why.
> 
> So, I managed to reproduce this by simply installing ruby-multi-json,
> which allows Puppet to use different json backends. Can you verify that 
> ruby-multi-json is installed, presumably on the master?
> 

ruby-multi-json (1.12.1-1) is installed.

Checking with 'apt-cache policy rdepends ruby-multi-json', it's like because we 
use r10k

> Thanks,
> Apollon

Thanks,
Kienan


signature.asc
Description: PGP signature