Bug#924401: base-files fails postinst when base-passwd is unpacked

[Johannes Schauer]

Hi Santiago,

Quoting Santiago Vila (2019-03-13 13:50:11)
> On Wed, Mar 13, 2019 at 01:15:02PM +0100, Johannes Schauer wrote:
> > I'm not advocating for doing "hacks here and there so that bootstrapping 
> > tools
> > work properly" as you put it but that we think about the question of whether
> > maybe there is a better way to populate an empty directory with software
> > components that does not require as much magic as currently has to be 
> > supplied
> > by tools like debootstrap. The result would not be "hacks here and there" 
> > but a
> > cleaner and more robust setup procedure.
> > 
> > So what I want you to take away from this long mail is: maybe we should
> > re-think the way we are currently creating a Debian chroot because maybe 
> > there
> > exists a different approach that would give us benefits that are actually
> > important to our users and make maintaining the universal operating system
> > easier?
> Sounds good in theory, but I'd like to know what kind of new architecture are
> you thinking of, how would it be implemented, or how would it work in
> practice.

I assume by "architecture" here you don't mean Debian architecture but are
talking about the architecture that would improve on the current situation? I
already linked to two examples of approaches. I think in essence we somehow
have to manage the maintainer scripts.

One way would be support for chrootless maintainerscripts. Helmut filed #824594
against src:base-files but the maintainer was not convinced about the merits of
the approach and wanted to see some data about how a debootstrap-like tool
could take advantage of it. This was indeed my main motivation to write
mmdebstrap: to show that the approach was viable. Honestly, only now that I was
reading #824594 again, I realize that we are back at src:base-files talking
about the same topic that got me to write mmdebstrap in the first place. :D

Another way would be replacing maintainer scripts by more declarative
approaches, like pointed out by Guillem. I like this method a lot and it does
not conflict with the chrootless method which is still useful in situations
where one wants to (for example) create either a foreign architecture chroot or
create a chroot without needing superuser privileges.

And yet another would be, to allow dependencies between Essential packages or
by defining a package set even smaller than current Essential. But I like this
version the least.

> For example, for people bootstrapping new architectures, we introduced
> build-stages (afaik now called build-profiles).  (The  in gettext,
> for example).

Build profiles are for bootstrapping in the context of building software
packages.  Here, we talk about bootstrapping in the context of debootstrap
where we bootstrap a directory filled with unpacked binary packages from
"zero". The arguments brought forth here only concern bootstrapping new
architectures in so far that an Essential:yes set with less maintainer scripts
makes bootstrapping a new architecture easier.

> Maybe in the same line we could add a special Depends field only meaningful
> for bootstrapping tools? Is this the sort of thing you have in mind?
> 
> I would certainly consider a lot cleaner to add a new field to base-files in
> the form "Bootstrap-Depends: base-passwd" than converting all chowns in
> postinst to use integer numbers.

I agree that we should not expect maintainers to write numeric user and group
ids into their maintainer scripts. This is not only hard to write but also hard
to read and maintain. In my opinion, using numeric ids should only be a
temporary measure until we have a declarative method or other helper that does
the correct translation instead. But since no such helper exists right now,
numeric ids are probably the best way to fix this bug for buster.

I was now als able to trigger this bug in mmdebstrap. Here is how to populate a
chroot directory with a set of packages that is less than the Essential:yes set
and based on busybox:

sudo mmdebstrap --mode=root --variant=custom \
--include=dpkg,busybox,libc-bin,base-files,base-passwd,debianutils \
--setup-hook='mkdir -p "$1/bin"' \
--setup-hook='for p in awk cat chmod chown cp diff echo env grep less ln 
mkdir mount rm rmdir sed sh sleep sort touch uname; do ln -s busybox 
"$1/bin/$p"; done' \
--setup-hook='echo root:x:0:0:root:/root:/bin/sh > "$1/etc/passwd"' \
--setup-hook='printf "root:x:0:\nmail:x:8:\nutmp:x:43:\n" > "$1/etc/group"' 
\
unstable ./debian-unstable-busybox

As one can see, I had to create a minimal /etc/passwd and /etc/group inside the
chroot filled with entries for root, mail and utmp for the base-files postinst
to work. Using mmdebstrap like that is indeed quite a hack right now, so I'm
not claiming that mmdebstrap should be the reason for base-files to change. But
maybe this is a useful way for you of how to see this problem happening for
yourself.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#924534: (no subject)

[Julien Goodwin]

There isn't much in the NM logs, here's all I could find that seemed useful (no 
lines removed from these subsets)

No changes (both IPv4 & IPv6 set to default method)
NetworkManager[18485]:   [1552542701.3933] device (wlp4s0): Activation: 
(wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless 
network "ESSID-V6Only"
NetworkManager[18485]:   [1552542701.4132] device (wlp4s0): state change: 
config -> ip-config (reason 'none', sys-iface-state: 'managed')
NetworkManager[18485]:   [1552542701.4142] dhcp4 (wlp4s0): activation: 
beginning transaction (timeout in 45 seconds)
NetworkManager[18485]:   [1552542701.4162] dhcp4 (wlp4s0): dhclient 
started with pid 18944
NetworkManager[18485]:   [1552542746.1856] dhcp4 (wlp4s0): request timed 
out
NetworkManager[18485]:   [1552542746.1857] dhcp4 (wlp4s0): state changed 
unknown -> timeout
NetworkManager[18485]:   [1552542746.2175] dhcp4 (wlp4s0): canceled DHCP 
transaction, DHCP client pid 18944
NetworkManager[18485]:   [1552542746.2175] dhcp4 (wlp4s0): state changed 
timeout -> done
NetworkManager[18485]:   [1552542746.2177] device (wlp4s0): state change: 
ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
NetworkManager[18485]:   [1552542746.2180] manager: NetworkManager state 
is now DISCONNECTED
NetworkManager[18485]:   [1552542746.2181] manager: startup complete
NetworkManager[18485]:   [1552542746.2185] device (wlp4s0): Activation: 
failed for connection 'ESSID-V6Only'
NetworkManager[18485]:   [1552542746.2186] device (wlp4s0): state change: 
failed -> disconnected (reason 'none', sys-iface-state: 'managed')


IPv4 explicitly marked disabled:
NetworkManager[18485]:   [1552542821.9833] device (wlp4s0): Activation: 
(wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless 
network "ESSID-V6Only"
NetworkManager[18485]:   [1552542822.0137] device (wlp4s0): state change: 
config -> ip-config (reason 'none', sys-iface-state: 'managed')
NetworkManager[18485]:   [1552542854.1857] device (wlp4s0): state change: 
ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
NetworkManager[18485]:   [1552542854.1862] manager: NetworkManager state 
is now DISCONNECTED
NetworkManager[18485]:   [1552542854.1869] device (wlp4s0): Activation: 
failed for connection 'ESSID-V6Only'
NetworkManager[18485]:   [1552542854.1873] device (wlp4s0): state change: 
failed -> disconnected (reason 'none', sys-iface-state: 'managed')

Bug#924510: cron runs job at wrong time; ignores values in /etc/crontab; after upgrade to buster

[Christian Kastner]

Hi,

On 13.03.19 20:16, Tony Walker wrote:
> I upgraded to Buster from stretch and noticed that my cron jobs were
> running at ~7:38 AM
> instead of the time in my /etc/crontab. After some troubleshooting, I
> did reinstall by
> installing from 9.7 media followed immediately by apt full-upgrade. The
> problem persisted.
> I then did the same on a different system and found that the problem
> exists on this
> system as well (total of two out of two systems that exhibit the problem).
> 
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> 
> I tried the default setting of 6:25 AM ["25 6 * * *"] and a few other times
> (e.g., 1:00 AM ["0 1 * * *"]). cron seems to ignore all entries and the
> jobs always
> run at ~7:38 AM. date and hwclock agree on current time. /etc/timezone
> is America/New_York

that sounds extremely odd. I don't even have a clue what could cause
this in the code. I'm almost certain it's not the job database...
perhaps parsing?

What does `journalctl -t CRON` say?  (If you don't use systemd, the
default /etc/rsyslog.conf contains a line #cron ... that when you enable
it, will log all cron messages to /var/log/cron.log).

If those messages don't provide a clue, then the only thing I can think
of is to rebuild in debug mode, and then to run cron in the foreground.
It will then, quite verbosely, report about all the steps it takes. Let
me know if you need such a build, I can provide you with one.

Regards,
Christian

Bug#924409: removing hiera from debian? or do not ship with buster

[Apollon Oikonomopoulos]

Control: severity -1 important
Control: tags -1 - buster
Control: retitle -1 hiera should be removed after Buster is released

Hi,

On 13:07 Tue 12 Mar , Antoine Beaupre wrote:
> I see that Hiera in Puppet is at version 3.2.0 in buster. That's at
> least two minor versions behind upstream, which is (unofficially) at
> 3.5:
> 
> https://github.com/puppetlabs/hiera/releases
> 
> That said, Hiera itself is deprecated as a standalone system: Hiera 5
> has been part of Puppet since 4.9:
> 
> https://puppet.com/docs/hiera/3.3/index.html
> 
> The Hiera README on GitHub says the same:
> 
> https://github.com/puppetlabs/hiera/blob/master/README.md
> 
> "This project is deprecated in favor of Hiera version 5 which is
> implementation in Puppet."
> 
> Since Buster will likely ship with Puppet 5.5 (or later), it doesn't
> seem to make sense to ship Hiera in buster and it should be
> removed. It could also be removed from unstable as well, but I wanted
> to checkin with maintainers here first before filing a formal removal.

Puppet currently lists `hiera` (3) as a runtime dependency in its 
gemspec[1]. This is to provide backward compatibility until users 
manually upgrade[2] their Puppet manifests, as Hiera 3 and Hiera 5 are 
incompatible.

Since Hiera 5 was introduced after Stretch was released, we should keep 
plain `hiera` around for Buster to allow users to upgrade in a 
non-disruptive fashion. Of course we should document all of this on the 
release notes :)

I'm lowering severity to non-RC, but keeping the bug around with an 
updated title so that we can remove hiera after Buster's release.

Thanks,
Apollon

[1] https://github.com/puppetlabs/puppet/blob/master/.gemspec#L35
[2] https://puppet.com/docs/puppet/5.3/hiera_migrate.html

Bug#924534: network-manager: Regression from 1.14.4-4 in 1.14.6-2, fails to connect to IPv6-only network

[Julien Goodwin]

Package: network-manager
Version: 1.14.6-2
Severity: important
Tags: ipv6

I am currently using an IPv6-only wireless network, in network-manager
1.14.4-4 this worked fine. After upgrading to 1.14.6-2 it wouldn't
connect. Switching to an IPv4+IPv6 wireless network connected fine in
1.14.6-2, after downgrading to 14.4-4 connecting to an IPv6-only network
works again.


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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.12-1
ii  init-system-helpers1.56+nmu1
ii  libaudit1  1:2.8.4-2
ii  libbluetooth3  5.50-1
ii  libc6  2.28-8
ii  libcurl3-gnutls7.64.0-1
ii  libglib2.0-0   2.58.3-1
ii  libgnutls303.6.6-2
ii  libjansson42.12-1
ii  libmm-glib01.10.0-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-8
ii  libnm0 1.14.4-4
ii  libpam-systemd 241-1
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0241-1
ii  libteamdctl0   1.28-1
ii  libudev1   241-1
ii  libuuid1   2.33.1-0.1
ii  lsb-base   10.2018112800
ii  policykit-10.105-25
ii  udev   241-1
ii  wpasupplicant  2:2.7+git20190128+0c1e29f-2

Versions of packages network-manager recommends:
pn  crda 
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iptables 1.8.2-4
ii  isc-dhcp-client  4.4.1-2
ii  modemmanager 1.10.0-1
ii  ppp  2.4.7-2+4

Versions of packages network-manager suggests:
pn  libteam-utils  

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
no-auto-default=5c:ff:35:0f:6c:bb,
[ifupdown]
managed=true


-- no debconf information

Bug#924533: SSL_ERROR_EXPIRED_CERT_ALERT on tracker.debian.org please fix it.

[shirish शिरीष]

Package: tracker.debian.org
Severity: normal

Dear Maintainer,
I have been getting -

Secure Connection Failed

An error occurred during a connection to tracker.debian.org. SSL peer
rejected your certificate as expired. Error code:
SSL_ERROR_EXPIRED_CERT_ALERT

The page you are trying to view cannot be shown because the
authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.


Please renew the SSL ceritificate .

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

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

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

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

[Pierre Ynard]

> And, I can't see standalone tune2fs even in unstable:
>
> $ apt-file find /bin/tune2fs
> android-sdk: /usr/lib/android-sdk/tools/bin/tune2fs

/sbin/tune2fs is shipped by e2fsprogs.

-- 
Pierre Ynard

Bug#919859: [src:linux]

[Dimitris Pitsioris]

Package: src:linux

Still nothing, even after todays upgrade to 4.19.28 (package 
linux-image-4.19.0-4-amd64).



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

Debian Release: buster/sid
  990 testing http.debian.net   990 testing 
debian.mur.at   500 unstablehttp.debian.net   500 unstable 
 debian.mur.at   500 stable  deb.opera.com   500 experimental 
 debian.mur.at 1 experimentalhttp.debian.net

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#924532: gitlab-runner: New upstream version

[Dean Hamstead]

Package: gitlab-runner
Version: 11.2.0+dfsg-2
Severity: wishlist

There is a new upstream version. 11.8.0 as of now

This is desirable for me due to this bug being fixed 
https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1010

Bug#924531: unblock: systemc/2.3.3-2

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

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

Please unblock package systemc

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

debdiff attached

unblock systemc/2.3.3-2

-- 
‎أحمد المحمودي (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
diff --git a/debian/changelog b/debian/changelog
index 637867a..a84f6cc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+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)   
Sun, 10 Mar 2019 07:04:08 +0100
+
 systemc (2.3.3-1) unstable; urgency=medium
 
   [ Carsten Schoenert ]
diff --git a/debian/control b/debian/control
index ccfc9d8..ae00831 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: electronics
 Priority: optional
 Maintainer: أحمد المحمودي (Ahmed El-Mahmoudy) 

 Build-Depends: debhelper (>= 11), texinfo
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Homepage: https://www.accellera.org/downloads/standards/systemc/
 Vcs-Git: https://salsa.debian.org/electronics-team/systemc.git
 Vcs-Browser: https://salsa.debian.org/electronics-team/systemc
diff --git a/debian/libsystemc.symbols b/debian/libsystemc.symbols
index 2fec5c3..2e850c3 100644
--- a/debian/libsystemc.symbols
+++ b/debian/libsystemc.symbols
@@ -92,7 +92,7 @@ libsystemc-2.3.3.so libsystemc #MINVER#
  _ZN5sc_dt10sc_lv_base10clean_tailEv@Base 2.3.3
  
_ZN5sc_dt10sc_lv_base18assign_from_stringERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.3.3
  _ZN5sc_dt10sc_lv_base4initEiRKNS_8sc_logicE@Base 2.3.3
- _ZN5sc_dt10sc_lv_base7set_bitEiNS_16sc_logic_value_tE@Base 2.3.3
+ (arch-bits=32)_ZN5sc_dt10sc_lv_base7set_bitEiNS_16sc_logic_value_tE@Base 2.3.3
  _ZN5sc_dt10sc_lv_baseC1EPKc@Base 2.3.3
  _ZN5sc_dt10sc_lv_baseC1EPKci@Base 2.3.3
  _ZN5sc_dt10sc_lv_baseC1ERKS0_@Base 2.3.3
@@ -157,7 +157,6 @@ libsystemc-2.3.3.so libsystemc #MINVER#
  _ZN5sc_dt11sc_unsigned10concat_setExi@Base 2.3.3
  _ZN5sc_dt11sc_unsigned10concat_setEyi@Base 2.3.3
  _ZN5sc_dt11sc_unsigned14set_packed_repEPj@Base 2.3.3
- _ZN5sc_dt11sc_unsigned22convert_SM_to_2C_to_SMEv@Base 2.3.3
  _ZN5sc_dt11sc_unsigned3setEi@Base 2.3.3
  _ZN5sc_dt11sc_unsigned4scanERSi@Base 2.3.3
  _ZN5sc_dt11sc_unsigned5clearEi@Base 2.3.3
@@ -614,7 +613,6 @@ libsystemc-2.3.3.so libsystemc #MINVER#
  _ZN5sc_dt22sc_fxval_fast_observerD2Ev@Base 2.3.3
  _ZN5sc_dt22sc_proxy_out_of_boundsEPKcx@Base 2.3.3
  _ZN5sc_dt23convert_signed_2C_to_SMEiiPj@Base 2.3.3
- (arch-bits=64)_ZN5sc_dt25convert_unsigned_2C_to_SMEiiPj@Base 2.3.3
  _ZN5sc_dt29sc_int_concref_invalid_lengthEi@Base 2.3.3
  _ZN5sc_dt30sc_uint_concref_invalid_lengthEi@Base 2.3.3
  _ZN5sc_dt5alignERKNS_8scfx_repES2_RiS3_RNS_13scfx_mant_refES5_@Base 2.3.3
@@ -2010,6 +2008,9 @@ libsystemc-2.3.3.so libsystemc #MINVER#
  _ZN7sc_core15sc_prim_channelD0Ev@Base 2.3.3
  _ZN7sc_core15sc_prim_channelD1Ev@Base 2.3.3
  _ZN7sc_core15sc_prim_channelD2Ev@Base 2.3.3
+ _ZN7sc_core15sc_process_hostD0Ev@Base 2.3.3
+ _ZN7sc_core15sc_process_hostD1Ev@Base 2.3.3
+ _ZN7sc_core15sc_process_hostD2Ev@Base 2.3.3
  _ZN7sc_core15sc_set_locationEPKciPNS_13sc_simcontextE@Base 2.3.3
  
_ZN7sc_core15sc_spawn_objectINS_25sc_clock_negedge_callbackEE9semanticsEv@Base 
2.3.3
  _ZN7sc_core15sc_spawn_objectINS_25sc_clock_negedge_callbackEED0Ev@Base 2.3.3
@@ -4325,7 +4326,6 @@ libsystemc-2.3.3.so libsystemc #MINVER#
  
(arch-bits=32)_ZNSt6vectorIPN7sc_core17sc_thread_processESaIS2_EE17_M_default_appendEj@Base
 2.3.3
  
(arch-bits=64)_ZNSt6vectorIPN7sc_core17sc_thread_processESaIS2_EE17_M_default_appendEm@Base
 2.3.3
  
_ZNSt6vectorIPN7sc_core17sc_thread_processESaIS2_EE17_M_realloc_insertIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.3
- 
_ZNSt6vectorIPN7sc_core17sc_thread_processESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.3
  
(arch-bits=32)_ZNSt6vectorIPN7sc_core18sc_process_monitorESaIS2_EE17_M_default_appendEj@Base
 2.3.3
  
(arch-bits=64)_ZNSt6vectorIPN7sc_core18sc_process_monitorESaIS2_EE17_M_default_appendEm@Base
 2.3.3
  
_ZNSt6vectorIPN7sc_core18sc_process_monitorESaIS2_EE17_M_realloc_insertIJRKS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 2.3.3
@@ -5139,7 +5139,7 @@ libsystemc-2.3.3.so libsystemc #MINVER#
  
(arch-bits=32)_ZThn8_NK7sc_core11sc_signal_tIN5sc_dt8sc_logicELNS_16sc_writer_policyE3EE4dumpERSo@Base
 2.3.3
  
(arch-bits=32)_ZThn8_NK7sc_core11sc_signal_tIN5sc_dt8sc_logicELNS_16sc_writer_policyE

Bug#924526: Support FSProtect on NFS

[Pierre Ynard]

submitter 924526 Ivan Baldo 
thanks

Hello,

>   In umountnfs.sh where it says
> /|/proc|/dev|/dev/pts|/dev/shm|/proc/*|/sys|/lib/init/rw) should add
> /fsprotect/system because thats the underlying root FS when using
> fsprotect with NFS.
>   fsprotect is a package in Debian and should be supported.

First, if I understand correctly, fsprotect is in itself related neither
to NFS, nor to network filesystems, nor to FUSE.

What is the problem that you encounter exactly? Can you share the
contents of /proc/mounts on your system?

It is my understanding that /fsprotect/system is a mount point
for the underlying filesystem which, combined with a tmpfs in an
aufs, is mounted as the root. What happens if you try to unmount
/fsprotect/system while the aufs is still mounted? Is that even
possible, with umount, with umount -f?

I suspect that in /etc/init.d/umountfs, /fsprotect/system is protected
from unmounting because it is listed before / in /proc/mounts;
however there is no such logic in /etc/init.d/umountnfs.sh, so if
/fsprotect/system is a network mount it would try to unmount it while
the aufs / is still mounted.

If that's the case, I'm not convinced that adding /fsprotect/system in
the list is the right approach, that would be a very specific fix.

-- 
Pierre Ynard

Bug#924530: unblock: dico/2.7-2

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

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

Please unblock package dico

Fixes #915584: dicoweb: fails to install with python 3.7

debdiff attached

unblock dico/2.7-2

-- 
‎أحمد المحمودي (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
diff --git a/debian/changelog b/debian/changelog
index c48212c..e202277 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+dico (2.7-2) unstable; urgency=medium
+
+  * Fix typo in dicodconfig.8 (Closes: #916748)
+  * Add Pre-Depends: python3-dicoclient to dicoweb as a workaround to prevent
+dicoweb unpacked before python3 is configured (Closes: #915584)
+  * Update standards version to 4.3.0
+  * Add patch description
+
+ -- أحمد المحمودي (Ahmed El-Mahmoudy)   
Tue, 12 Mar 2019 05:00:34 +0100
+
 dico (2.7-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --git a/debian/control b/debian/control
index 84e4787..557996c 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,7 @@ Build-Depends: debhelper (>= 11),
libpcre3-dev,
libpam0g-dev,
wordnet-dev
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Homepage: http://puszcza.gnu.org.ua/software/dico/
 Vcs-Git: https://salsa.debian.org/debian/dico.git
 Vcs-Browser: https://salsa.debian.org/debian/dico
@@ -179,12 +179,12 @@ Package: dicoweb
 Architecture: all
 Section: web
 Depends: libapache2-mod-passenger | libapache2-mod-wsgi,
- python3-dicoclient,
  python3-django (>= 1.4.5),
  python3-memcache,
  python3-wikitrans,
  ${misc:Depends},
  ${python3:Depends}
+Pre-Depends: python3-dicoclient
 Recommends: memcached
 Description: RFC 2229 compliant modular dictionary server (web interface)
  GNU Dico is an implementation of the DICT protocol as defined in RFC 2229.
diff --git a/debian/dicodconfig.8 b/debian/dicodconfig.8
index a694289..66f450b 100644
--- a/debian/dicodconfig.8
+++ b/debian/dicodconfig.8
@@ -36,7 +36,7 @@ may then be included from the
 configuration file
 .I /etc/dicod.conf
 with an
-``#include /var/lib/dictd/dictorg-db.list''
+``#include /var/lib/dicod/dictorg-db.list''
 line.
 See
 .BR info dico
diff --git a/debian/patches/test_env_conflict.diff 
b/debian/patches/test_env_conflict.diff
index 82b84bb..30c36b6 100644
--- a/debian/patches/test_env_conflict.diff
+++ b/debian/patches/test_env_conflict.diff
@@ -1,3 +1,8 @@
+Description: work around test failure due to $V variable being set for make
+ calls by debhelper >=11.5.2
+Author: Marc Dequènes (Duck) 
+Date: Thu Nov 15 11:16:28 2018 +0900
+
 --- a/grecs/tests/testsuite
 +++ b/grecs/tests/testsuite
 @@ -5152,14 +5152,14 @@


signature.asc
Description: PGP signature

Bug#478287: FUSE filesystems improperly killed at shutdown

[Steve Langasek]

On Thu, Mar 14, 2019 at 01:17:11AM +, Pierre Ynard wrote:
> clone 478287 -1
> reassign -1 fuse
> tags 478287 moreinfo
> thanks

> > They kill all processes including processes that support FUSE filesytems
> > (and probably nfs/smbfs/cifs as well) in sendsigs (and probably
> > killprocs).

> Is this still an issue nowadays? If it is, then relevant FUSE processes
> can and should register in /run/sendsigs.omit.d/ to avoid getting killed
> by /etc/init.d/sendsigs

> Steve, I saw you explain in one bug report that there was no such
> process supporting CIFS. Can you confirm about NFS, SMBFS or others that
> you know about, if they rely on any process that wouldn't already be
> protected in /run/sendsigs.omit.d/ ?

Any information I would have about /run/sendsigs.omit.d is bound to be
dated, sorry.

-- 
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#924529: delly FTCBFS: builds for the wrong architecture

[Do Thanh Trung]

Source: delly
Version: 0.8.1-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap


Hi,

delly fails to cross build because it does not pass cross build tools to 
make. Using "dh_auto_build" instead of "$(MAKE) can solve this problem.


--
Trung
diff -Nru delly-0.8.1/debian/rules delly-0.8.1/debian/rules
--- delly-0.8.1/debian/rules2019-02-05 15:17:08.0 +0700
+++ delly-0.8.1/debian/rules2019-02-05 15:17:08.0 +0700
@@ -9,7 +9,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) BUILT_PROGRAMS="src/delly src/dpe"
+   dh_auto_build -- BUILT_PROGRAMS="src/delly src/dpe"
chrpath -d src/dpe src/delly
 
 override_dh_auto_install:
-- 
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com

Bug#924528: /usr/share/doc/ffmpeg/manual/index.html missing

[積丹尼 Dan Jacobson]

Package: ffmpeg-doc
Version: 7:4.1.1-1
Severity: minor

$ cat /usr/share/doc-base/ffmpeg-doc
Document: ffmpeg-doc
Title: FFmpeg API Documentation
Author: FFmpeg Developers
Abstract: This is the API documentation for FFmpeg.
Section: Programming

Format: HTML
Index: /usr/share/doc/ffmpeg/api/index.html
Files: /usr/share/doc/ffmpeg/api/*.html

OK that is great, but these.

$ ls /usr/share/doc/ffmpeg/manual/*.html|wc -l
30

need indexing too.

Bug#924527: Mention -all/non -all versions on those versions

[積丹尼 Dan Jacobson]

Package: ffmpeg-doc
Version: 7:4.1.1-1

Kindly at the top of each of
ffmpeg: /usr/share/man/man1/ffmpeg-all.1.gz
ffmpeg: /usr/share/man/man1/ffplay-all.1.gz
ffmpeg: /usr/share/man/man1/ffprobe-all.1.gz
ffmpeg-doc: /usr/share/doc/ffmpeg/manual/ffmpeg-all.html
ffmpeg-doc: /usr/share/doc/ffmpeg/manual/ffplay-all.html
ffmpeg-doc: /usr/share/doc/ffmpeg/manual/ffprobe-all.html
be sure to mention that these are apparently actually more detailed
versions of their non "-all" counterparts.

And on their non "-all" counterparts, mention at top that there are also
the "-all" versions where more details exist.

Else users will never know the existence of the other, or think that
since on the surface they look the same, that they are some error. And
also they probably refer to /usr/bin/*-all .

Bug#924448: Da stack trace

[Kingsley G. Morse Jr.]

I elicited a stack trace from gdb by 

1.) redirecting output to a file

(gdb) set logging on /tmp/gimp.gdb.log


2.) and defining a function that requested a
back trace after running gimp

(gdb) define mc
>file gimp
>r
>bt 1000
>^d


3.) running the function

(gdb) mc


Here's ist output

warning: File 
"/usr/lib/debug/.build-id/da/c552d8815d9a4ef5d055ab6cd81e0478998e2c.debug" has 
no build-id, file skipped
warning: File 
"/usr/lib/debug/.build-id/e5/02ab31fa523af198980f0f57ccb2949798ec9d.debug" has 
no build-id, file skipped
warning: File 
"/usr/lib/debug/.build-id/41/f29963806d55346284ccbbbff7ce1568c05a4b.debug" has 
no build-id, file skipped
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
warning: File 
"/usr/lib/debug/.build-id/c8/2785938ed49369549f97c435a2164d5537d787.debug" has 
no build-id, file skipped
warning: File 
"/usr/lib/debug/.build-id/b4/8ee7d166852be63462d6a8f2d1599b6c65a89d.debug" has 
no build-id, file skipped
warning: File 
"/usr/lib/debug/.build-id/b0/929a0b74877b19ff6ae956d9c3a23b2211d39e.debug" has 
no build-id, file skipped
warning: File 
"/usr/lib/debug/.build-id/b1/1e8718bce950a16015ee80c15c6b488369fb38.debug" has 
no build-id, file skipped
[New Thread 0xb5d28b40 (LWP 30375)]
warning: File 
"/usr/lib/debug/.build-id/ff/9a2994397cf6d0556c3eff4084392dc31eb2a7.debug" has 
no build-id, file skipped
[New Thread 0xb4205b40 (LWP 30402)]
[New Thread 0xb3a04b40 (LWP 30403)]
warning: File 
"/usr/lib/debug/.build-id/3e/91fc79df7ef64213ada45340cd54a7d110a90f.debug" has 
no build-id, file skipped
[New Thread 0xa9cdfb40 (LWP 30408)]
[New Thread 0xa94deb40 (LWP 30409)]
[New Thread 0xa8cddb40 (LWP 30410)]
[New Thread 0xa71c1b40 (LWP 30451)]
[Thread 0xa71c1b40 (LWP 30451) exited]
[New Thread 0xa71c1b40 (LWP 30524)]
[Thread 0xa8cddb40 (LWP 30410) exited]
[New Thread 0xa8cddb40 (LWP 30527)]

Thread 1 "gimp" received signal SIGSEGV, Segmentation fault.
0xb6fbbef9 in signal_emit_unlocked_R (node=node@entry=0x82e9d680, 
detail=detail@entry=0, 
instance=instance@entry=0x82e119a8, emission_return=0x0, 
instance_and_params=0xbf8000d0)
at ../../../gobject/gsignal.c:3501
3501../../../gobject/gsignal.c: No such file or directory.
#0  0xb6fbbef9 in signal_emit_unlocked_R (node=node@entry=0x82e9d680, 
detail=detail@entry=0, 
instance=instance@entry=0x82e119a8, emission_return=0x0, 
instance_and_params=0xbf8000d0)
at ../../../gobject/gsignal.c:3501
#1  0xb6fc5e00 in g_signal_emit_valist (instance=, 
signal_id=, 
detail=, 
var_args=0xbf80022c 
"\235(\033\200\207(\033\200\330\334\377\266\250\031\341\202\060\372\372\266\250\031\341\202\001")
 at ../../../gobject/gsignal.c:3391
#2  0xb6fc63f5 in g_signal_emit (instance=0x82e119a8, signal_id=619, detail=0)
at ../../../gobject/gsignal.c:3447
#3  0x801b28c9 in gimp_tool_widget_changed ()
#4  0xb6fafa30 in g_object_notify_by_spec_internal (pspec=, 
object=0x82e119a8)
at ../../../gobject/gobject.c:1181
#5  g_object_notify (object=0x82e119a8, property_name=0x804bf8dd "unit-angle")
at ../../../gobject/gobject.c:1229
#6  0x801996c0 in ?? ()
#7  0x8019a3af in ?? ()
#8  0xb6fa9037 in g_closure_invoke (closure=0x82e9ead0, return_value=0x0, 
n_param_values=1, 
param_values=0xbf800520, invocation_hint=0xbf8004c4) at 
../../../gobject/gclosure.c:810
#9  0xb6fbcd45 in signal_emit_unlocked_R (node=node@entry=0x82e9d680, 
detail=detail@entry=0, 
instance=instance@entry=0x82e119a8, emission_return=0x0, 
instance_and_params=0xbf800520)
at ../../../gobject/gsignal.c:3565
#10 0xb6fc5e00 in g_signal_emit_valist (instance=, 
signal_id=, 
detail=, 
var_args=0xbf80067c 
"\235(\033\200\207(\033\200\330\334\377\266\250\031\341\202\060\372\372\266\250\031\341\202\001")
 at ../../../gobject/gsignal.c:3391
#11 0xb6fc63f5 in g_signal_emit (instance=0x82e119a8, signal_id=619, detail=0)
at ../../../gobject/gsignal.c:3447
#12 0x801b28c9 in gimp_tool_widget_changed ()
#13 0xb6fafa30 in g_object_notify_by_spec_internal (pspec=, 
object=0x82e119a8)
at ../../../gobject/gobject.c:1181
#14 g_object_notify (object=0x82e119a8, property_name=0x804bf8dd "unit-angle")
at ../../../gobject/gobject.c:1229
#15 0x801996c0 in ?? ()
#16 0x8019a3af in ?? ()
#17 0xb6fa9037 in g_closure_invoke (closure=0x82e9ead0, return_value=0x0, 
n_param_values=1, 
param_values=0xbf800970, invocation_hint=0xbf800914) at 
../../../gobject/gclosure.c:810
#18 0xb6fbcd45 in signal_emit_unlocked_R (node=node@entry=0x82e9d680, 
detail=detail@entry=0, 
instance=instance@entry=0x82e119a8, emission_return=0x0, 
instance_and_params=0xbf800970)
at ../../../gobject/gsignal.c:3565
#19 0xb6fc5e00 in g_signal_emit_valist (instance=, 
signal_id=, 
detail=, 
var_args=0xbf800acc "\235(\033\200\207(\033\200\330\334\377\266\250\031\34Quit

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#895131: linux-perf: Add libopencsd support to perf

[John Paul Adrian Glaubitz]

On 3/13/19 8:14 PM, Ben Hutchings wrote:
>> Since this library is ARM-specific anyway, wouldn't it make
>> more sense to have this build-dependency on ARM targets only?
> 
> Please open a *new* bug for this.

Okay, can do. Although it seems that upstream is going to change
libopencsd now to use -fPIC instead of -fpic.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#492176: FUSE filesystems improperly killed at shutdown

[Pierre Ynard]

clone 478287 -1
reassign -1 fuse
tags 478287 moreinfo
thanks

> On a live system the / filesystem is usually a union mount of a readonly
> base and a tmpfs overlay. The initscripts try quite hard to break the
> filesystem if the base is mounted from the network:

How is this specific to operations from the network, and not just any
FUSE root filesystem?

> They kill all processes including processes that support FUSE filesytems
> (and probably nfs/smbfs/cifs as well) in sendsigs (and probably
> killprocs).

Is this still an issue nowadays? If it is, then relevant FUSE processes
can and should register in /run/sendsigs.omit.d/ to avoid getting killed
by /etc/init.d/sendsigs

Steve, I saw you explain in one bug report that there was no such
process supporting CIFS. Can you confirm about NFS, SMBFS or others that
you know about, if they rely on any process that wouldn't already be
protected in /run/sendsigs.omit.d/ ?

> They also umount all filesystems with umount -f which kills the FUSE
> filesystem. The comment explicitly says it is menat to kill NFS
> filesystems.

Which comment, where? I assume that we're talking about
/etc/init.d/umountfs calling umount -f; however this script does not
attempt to unmount / (and neither /usr now), so in that case you
describe I don't understand how that could be an issue.

> Both can cause ugly error messages on shutdown or even prevent the
> shutdown completely if the filesystem is unmounted and poweroff or
> halt is not cached.
>
> I have seen this problem with httpfs root on a live Debian system.
> However, this could possibly cause problems with any setups where the
> / filesystem is on the network.

A / filesystem on the network could indeed experience issues with the -i
option passed to halt in /etc/init.d/halt (#499796, #632091), but that's
separate from umount issues. Please note how /etc/init.d/networking is
aware of handling two FUSE network filesystem types: fuse.httpfs (used
in this case) and fuse.curlftpfs. Are there others to handle?

> In /etc/init.d/umountfs all filesystems except tmpfs are umounted with
> the force "-f" flag. While I already think it is a bad idea to use
> the special force flag for everything, it causes real trouble with
> fuse-filesystems. For fuse-filesystems the force flag will close the
> /dev/fuse connection and thus the filesystem will abort. If there are
> still open filedescriptors on the mount point, all further access to
> these mount points will return "Transport endpoint is not connected"
> (errno 108).

At this point of the shutdown sequence, there should be nothing left
using the filesystems that are to be unmounted, so I don't really
understand this. And forced unmounting will cause errors with later
access attempts on any filesystem, not just FUSE, so I don't see how
that's specifically worse of a problem with FUSE. Finally, simply not
unmounting the filesystems might avoid those error messages, but I don't
think that really solves the problem. Can you explain better, or mention
what would still be using FUSE filesystems when it's time to unmount
them?

> I also think this should be fixed in fuse, however, the author of fuse
> thinks the present behaviour is correct and so there is presently no
> way to fix it at kernel level. Please see this thread:
> http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/6579/focus=6592

This URL doesn't seem to work now.

I personally have no experience with FUSE. Dear fuse maintainers, could
you please help and:

 - look into this issue about FUSE filesystem processes getting killed
   at shutdown?
 - advise about anything that I might have failed to understand about
   the unmounting issue?
 - advise about FUSE network filesystem types and how to detect them?

Thanks,

-- 
Pierre Ynard

Bug#726509: RFP: elpa-coffeescript-mode -- Emacs mode for editing CoffeeScript

[Ben Finney]

Control: retitle -1 RFP: elpa-coffee-mode -- Emacs mode for editing CoffeeScript

On 16-Oct-2013, Ben Finney wrote:
> * Package name: coffeescript-mode

This is now available from MELPA:

Package name: elpa-coffeescript-mode
Version: 0.6.3
Upstream Author: Chris Wanstrath 
 Syohei YOSHIDA
URL: https://stable.melpa.org/#/coffee-mode
License: GPL-3+
Programming Lang: Emacs Lisp
Description: Emacs mode for editing CoffeeScript

‘coffee-mode’ is an Emacs major mode for editing code written
in the CoffeeScript and IcedCoffeeScript programming languages.

Provides syntax highlighting, indentation support, imenu
support, a menu bar, and a few cute commands.

-- 
 \ “The Vatican is not a state.… a state must have territory. This |
  `\ is a palace with gardens, about as big as an average golf |
_o__) course.” —Geoffrey Robertson, 2010-09-18 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#924424: munin-plugins-core: postgres_connections_ "Query failed!" after update to 2.0.47-1

[Lars Kruse]

Control: tags -1 fixed-upstream

Hello Thorsten,


Am Wed, 13 Mar 2019 22:25:04 +
schrieb "Thorsten Ortlepp" :

> >Could you please verify, whether this change fixes your issue?  
> 
> Yes, this fix made postgres_connections_example work again.

great - thank you!

Lars

Bug#924448: Duplicating in gdb blocked key board (mostly)

[Kingsley G. Morse Jr.]

Another clue:

After gimp crashed in gdb, I couldn't type
anything in any xterminal.

However, pressing ctl-alt-F1, to go to an old
school console, worked.

That let me kill gdb's process and fix my key
baord.


Another clue, maybe:

gdb reported

Thread 1 "gimp" received signal SIGSEGV, Segmentation fault.
0xb7010f49 in signal_emit_unlocked_R (node=node@entry=0x82e7b2a0, 
detail=detail@entry=0, 
instance=instance@entry=0x80ba2288, emission_return=0x0, 
instance_and_params=0xbf8000d0)
at ../../../gobject/gsignal.c:3501
3501../../../gobject/gsignal.c: No such file or directory.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#924524: libinput10: libinput error: event2 - DELL081C:00 044E:121F Touchpad

[Benjamin]

Package: libinput10
Version: 1.12.6-1
Severity: important

I get regular errors regarding my touchpad on my Dell Latitude 7490, for
event 2 and others:

org.gnome.Shell.desktop[1196]: libinput error: event2  - DELL081C:00 044E:121F 
Touchpad: kernel bug: Touch jump detected and discarded.

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

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

Versions of packages libinput10 depends on:
ii  libc6 2.28-8
ii  libevdev2 1.6.0+dfsg-1
ii  libinput-bin  1.12.6-1
ii  libmtdev1 1.1.5-1+b1
ii  libudev1  241-1
ii  libwacom2 0.32-1

libinput10 recommends no packages.

libinput10 suggests no packages.

-- no debconf information

Bug#923873: Please increase MAX_CONFIG_LINE, otherwise ipmi_sim is not practically useable

[Thomas Goirand]

In #924465, the release team has pre-approved this patch. If you do not
react to this bug, I will NMU it to the delayed queue (5 days) tomorrow.

Cheers,

Thomas Goirand (zigo)

Bug#922862: Please add a test for packages that are shipping a cron script/config file and not a .timer

[Michael Biebl]

Am 12.03.19 um 14:38 schrieb Chris Lamb:
> Hi Michael,
> 
>> Seeing that the new lintian is available since for almost 3 weeks, is it
>> normal that
>> https://lintian.debian.org/tags/missing-systemd-timer-for-cron-script.html
>> only lists a couple of packages?
> 
> No, see #890873.
> 
>> Are those results on lintian.d.o regularly updated when new lintian
>> versions are uploaded
> 
> Yes, we usually have regular distro-wide scans with new versions.

Thanks for the additional info, Chris!
Very much appreciated.


-- 
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#924450: [pkg-apparmor] Bug#924450: Bug#924450: apparmor: Write Buster release notes snippet about AppArmor

[Jonas Meurer]

intrigeri:
> Christian Boltz:
>> AFAIK [1] support for enforcing network rules is not available in Debian 
>> yet, therefore it's probably a good idea to remove the "network" part 
>> from the text.
> 
> Indeed. FWIW apparmor.d(5) was patched in Debian to read:
> 
>Some features are not supported on Debian yet:
> 
>Network Rules
>DBus rules
>Unix socket rules

Thanks a lot to both of you for the corrections. I filed a follow-up MR
to fix this:

https://salsa.debian.org/ddp-team/release-notes/merge_requests/7

Cheers,
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#254909: 254909

[Nichola Williams]

Sent from my iPhone

Bug#924424: Re: Bug#924424: munin-plugins-core: postgres_connections_ "Query failed!" after update to 2.0.47-1

[Thorsten Ortlepp]

Hi Lars,


I am quite confident, that this was fixed upstream just a few minutes ago:
 
https://github.com/munin-monitoring/munin/commit/2c6ef84d0b85688e8ef6a470d4c8d3431b0e708d

Could you please verify, whether this change fixes your issue?


Yes, this fix made postgres_connections_example work again.

Regards,
Thorsten

Bug#794466: Virtualbox might not be suitable for Stretch

[Lucas Nussbaum]

Hi,

On 13/03/19 at 22:18 +0100, Ivo De Decker wrote:
> Control: severity -1 serious
> 
> Hi,
> 
> On Mon, Aug 28, 2017 at 03:01:18PM +0200, Lucas Nussbaum wrote:
> > After a private discussion with Gianfranco, I'm retitling this bug and
> > downgrading its severity. (Gianfranco agrees, at least on the general
> > lines of argumentation).
> > 
> > The reasoning is as follows.
> > 
> > Virtualbox did not make it into stretch due to this bug, for good
> > reasons.
> > 
> > We are at the start of the buster release cycle, and we don't know what
> > will be the status at the time of the freeze. The situation around
> > security support should be re-evaluated at the beginning of the buster
> > freeze, but until then, it sounds like a better plan to maximize user
> > testing and allow virtualbox to migrate to testing.
> > 
> > Security support for unstable/testing is not a problem because we are
> > tracking new upstream releases anyway, where issues are being addressed
> > by upstream. Also, there's a public svn repository to get fixes from if
> > necessary.
> 
> Could you clarify how you intend to handle security issues for virtualbox in
> buster? During a brief discussion on irc, the security team made it clear that
> they won't handle that (as the package is in contrib and upstream isn't
> cooperating), so it would be up to the maintainers to handle that.

I'm not a maintainer, but I'm in "To:", so I'll reply anyway, as a heavy
user of Virtualbox (mainly through Vagrant).

I don't know if the security support situation around virtualbox has
improved. I suspect it has not.

The situation we have with stretch, where virtualbox is installable via
stretch-backports, is a good compromise for users in my POV. If the
backports team does not make it a requirement for inclusion in
buster-backports that the package is in testing, I wouldn't mind it
staying out of testing during the buster cycle.

(But again I'm not the maintainer)

Lucas

Bug#923616: in the meanwhile

[Jeffrey Cliff]

the above link ( https://salsa.debian.org/themusicgod1-guest/os-timesync )
now has a preliminary building package

Hopefully this helps, and makes the GSoC students' job a little easier

Jeff Cliff

Bug#884553: Foreign architecture package support for linux kernel flavours patch

[adrian15]

El 13/03/19 a las 09:01, Raphael Hertzog escribió:
> On Tue, 12 Mar 2019, adrian15 wrote:
>> Is it ok for merging in Debian GIT or is there anything that I can improve?
> 
> I think it's OK if this was tested and if it doesn't break anything.
Yeah, I tested it in various commits from history while I was git
bisecting another live-build bug.

I must admit I haven't tested default usage of:

lb config --architectures i386 --linux-flavours "686"

but I'm pretty confident it works well because else my own build which
relies in proper LB_LINUX_FLAVOURS variables would have failed.

> Do you have commit rights to apply it yourself?
No, I don't.
> 
> If not, you might want to submit a merge request. You might want to
> improve the commit's description to explain why it's enough to accept
> the arch qualifier... i.e. other parts of the code already deal with
> it properly.
> 
> Cheers,

Ok, here there is my pull request:

https://salsa.debian.org/live-team/live-build/merge_requests/18


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#920899: closed by Piotr Ożarowski (Bug#920899: fixed in dh-python 3.20190307)

[Stefano Rivera]

Control: reopen -1

Hi Debian (2019.03.07_13:51:28_-0800)
> It's using /usr/lib/pypy/ns/ the same way as we do in Python 2.

It's in /usr/lib/ not /usr/share/

I couldn't reasonably make pypy use /usr/ as it's prefix, without it
finding cPython libraries. So the whole of pypy is in /usr/lib/pypy/.

Patch attached.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272
From e3e2f2dc8f693119ff40e5366d5bd9bc590eeffb Mon Sep 17 00:00:00 2001
From: Stefano Rivera 
Date: Wed, 13 Mar 2019 14:50:37 -0700
Subject: [PATCH] Put pypy namespace files in the correct place:
 /usr/lib/pypy/ns.

---
 debian/changelog | 6 ++
 dh_pypy  | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index d29b1e4..2ac9ba6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+dh-python (3.20190313) UNRELEASED; urgency=medium
+
+  * Put pypy namespace files in the correct place: /usr/lib/pypy/ns.
+
+ -- Stefano Rivera   Wed, 13 Mar 2019 14:47:03 -0700
+
 dh-python (3.20190308) unstable; urgency=medium
 
   * so2pyver: add a fallback to UTF-8 if locale.getdefaultlocale() returns None
diff --git a/dh_pypy b/dh_pypy
index b16487f..97bee8b 100755
--- a/dh_pypy
+++ b/dh_pypy
@@ -282,7 +282,7 @@ def main():
 log.error('cannot remove __init__.py from package: %s', e)
 exit(6)
 if nsp:
-dstdir = join('debian', package, 'usr/share/pypy/ns/')
+dstdir = join('debian', package, 'usr/lib/pypy/ns/')
 if not exists(dstdir):
 os.makedirs(dstdir)
 with open(join(dstdir, package), 'a', encoding='utf-8') as fp:
-- 
2.20.1

Bug#924522: please package tests

[Jelmer Vernooij]

Package: python3-caldav
Version: 0.5.0-0.1
Severity: wishlist

python-caldav comes with a useful set of tests that can be run against CalDAV 
server implementations. It would be great if these were packaged so that e.g. 
server packages can run them in their autopkgtest.

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

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

Versions of packages python3-caldav depends on:
ii  python3   3.7.2-1
ii  python3-lxml  4.3.2-1
ii  python3-requests  2.21.0-1
ii  python3-six   1.12.0-1
ii  python3-vobject   0.9.6.1-0.1

python3-caldav recommends no packages.

python3-caldav suggests no packages.

-- no debconf information

Bug#924452: lam4-dev: mpi alternative incompatible with current openmpi, mpich

[Camm Maguire]

Greetings!  I should have some time to look at this this week.  If you
happen to develop a patch, that would of course speed things up
considerably.

Thanks so much for your report!

Andreas Beckmann  writes:

> Package: lam4-dev
> Version: 7.1.4-3.1
> Severity: serious
> Tags: sid buster
>
> Installing lam4-dev after libopenmpi-dev results in messed up
> alternatives:
>
> # apt-get install libopenmpi-dev
> # ls -la /etc/alternatives/mpi /usr/include/mpi /usr/bin/mpicc
> ls: cannot access '/usr/include/mpi': No such file or directory
> lrwxrwxrwx 1 root root 22 Mar 13 07:32 /etc/alternatives/mpi -> 
> /usr/bin/mpicc.openmpi
> lrwxrwxrwx 1 root root 21 Mar 13 07:32 /usr/bin/mpicc -> /etc/alternatives/mpi
>
> # apt-get install lam4-dev
> # ls -la /etc/alternatives/mpi /usr/include/mpi /usr/bin/mpicc
> ls: cannot access '/usr/bin/mpicc': No such file or directory
> lrwxrwxrwx 1 root root 22 Mar 13 07:44 /etc/alternatives/mpi -> 
> /usr/bin/mpicc.openmpi
> lrwxrwxrwx 1 root root 21 Mar 13 07:44 /usr/include/mpi -> 
> /etc/alternatives/mpi
>
> I'll try to clean this up.
>
>
> Andreas
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

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

[gregor herrmann]

On Wed, 13 Mar 2019 20:24:59 +0200, Niko Tyni wrote:

> - have perl_5.28.1-5 Build-Depend on libgdbm-dev (>= 1.18-3)
>   [any gdbm version built with LFS support would do, but 1.18-3
>fixed other binary compat issues so pick that for safety]
> - have perl_5.28.1-5 Break libmarc-charset-perl (<< 1.35-3)
> - have libmarc-charset-perl_1.35-3 Build-Depend and Depend on
>   perl (>= perl_5.28.1-5)

Sounds right.
 
> We could limit the above to just 32-bit architectures, but IIRC those
> would need to be listed one by one and it's probably not worth the
> trouble.

*nod*
 
> This will cause temporary uninstallability of libmarc-charset-perl in
> sid so the uploads should be coordinated a bit. I guess I can do both
> if needed.

Thanks.
(If it helps I can also upload libmarc-charset-perl but maybe the
coordination effort is higher than if you just go ahead :))
 

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: Kings of Convenience: Know How


signature.asc
Description: Digital Signature

Bug#924183: Seems fixed in point release

[Scott Kitterman]

Yes.  It is.  I'm waiting a bit to see if there's another quick release before 
updating in Debian.

Upstream used the Debian provided patch to resolve the issue.

Scott K

On March 13, 2019 9:21:34 PM UTC, MK  wrote:
>Postfix stable release 3.4.3 (and actually in 3.4.2, but that missed a
>linux5 change)
>"DANE trust anchor file support was broken after the Postfix 3.4 TLS
>library overhaul. Fix by intrigeri."

Bug#924521: rails: CVE-2019-5420

[Salvatore Bonaccorso]

Source: rails
Version: 2:5.2.2+dfsg-6
Severity: important
Tags: security upstream
Control: found -1 2:5.2.2+dfsg-5

Hi,

The following vulnerability was published for rails.

CVE-2019-5420[0]:
Possible Remote Code Execution Exploit in Rails Development Mode

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-5420
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5420
[1] https://www.openwall.com/lists/oss-security/2019/03/13/3

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#924500: sbuild: Right syntax for "individual_stalled_pkg_timeout"?

[Santiago Vila]

Got it, I think:

$individual_stalled_pkg_timeout->{'llvm-toolchain-3.8'} = 300;
$individual_stalled_pkg_timeout->{'kicad-packages3d'} = 90;

(Yes, this is probably trivial for anybody who knows perl, but not
necessarily for the end user).

Thanks.

Bug#866419: Switch dependency to python-pil

[David Gnedt]

Tags: patch

You can find attached two patches. The first corrects the namespace of PIL
imports in cfv 1.18.3. The second one replaces the dependency on python-imaging
with python-pil.
--- a/cfv
+++ b/cfv
@@ -1837,7 +1837,7 @@
 	if filename == '':
 		return '0','0'
 	try:
-		import Image
+		from PIL import Image
 		im1=Image.open(filename)
 		return map(str, im1.size)
 	except (ImportError, IOError):
@@ -1910,7 +1910,7 @@
 		file.write('Generated at: %s\n'%time.strftime('%a, %d %b %Y %H:%M:%S',time.gmtime(time.time(
 		file.write('Find  it  at: http://cfv.sourceforge.net/\n\n')
 		try:
-			import Image
+			from PIL import Image
 			self.use_dimensions=1 should this be made optional somehow?
 		except ImportError:
 			self.use_dimensions=0
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@
 Package: cfv
 Architecture: all
 Depends: ${python:Depends}, ${misc:Depends}
-Suggests: python-imaging, bittorrent | bittornado
+Suggests: python-pil, bittorrent | bittornado
 Description: versatile file checksum creator and verifier
  cfv is a utility to test and create a wide range of checksum
  verification files. It currently supports testing and creating

Bug#924520: rails: CVE-2019-5418 CVE-2019-5419

[Salvatore Bonaccorso]

Source: rails
Version: 2:5.2.2+dfsg-6
Severity: important
Tags: security upstream
Control: found -1 2:5.2.2+dfsg-5
Control: found -1 2:4.2.7.1-1

Hi,

The following vulnerabilities were published for rails.

CVE-2019-5418[0]:
File Content Disclosure in Action View

CVE-2019-5419[1]:
Denial of Service Vulnerability in Action View

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-5418
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5418
[1] https://security-tracker.debian.org/tracker/CVE-2019-5419
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5419
[2] https://www.openwall.com/lists/oss-security/2019/03/13/5
[3] https://www.openwall.com/lists/oss-security/2019/03/13/4

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#923282: freezegun breaks cached-property autopkgtest

[Paul Gevers]

Hi Mathias,

On Wed, 13 Mar 2019 00:27:27 +0100 Mathias Behrle 
wrote:
> Basically cached_property *is* and *was* working, it is only that the tests 
> are
> failing due to API incompatibilities introduced by a test utility (freezegun)
> during or shortly before the soft freeze. 

Do I understand you correctly that there is no issue at all for the
package cached-property as used by our users?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#912549: icedtea-web FTBFS with OpenJDK 11

[Emmanuel Bourg]

On 13/03/2019 21:30, Markus Koschany wrote:

 Michael Crusoe has suggested a workaround[1].  What do you think about
 this?
>>>
>>> In case there is no answer to this question I assume it is OK to
>>> upload the workaround.  Hope you agree with this.
>>
>> please look at the new upstream 1.7.2 and 1.8 releases.
>>
> 
> In https://bugs.debian.org/855686 Emmanuel wrote that icedtea-web will
> be removed. I don't have a strong opinion in this case. If Michael's
> workaround works, why not. However I think it is too late now for new
> upstream releases as doko seems to imply.
> 
> Please note there are several other RC issues that are marked as pending
> but I believe the "fix" is to remove the package from Debian.

FYI I'm working on a fix, I plan to upload it next week if it works, or
the Michael's patch if it doesn't.

Emmanuel Bourg

Bug#924519: RFA: lsb -- Linux Standard Base init script functionality

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal

I request an adopter for the lsb package.

The package description is:
 The Linux Standard Base (http://www.linuxbase.org/) is a standard
 core system that third-party applications written for Linux can
 depend upon.
 .
 This package only includes the init-functions shell library, which
 may be used by other packages' initialization scripts for console
 logging and other purposes.

Over the years, I have first tried bringing LSB support to Debian,
and later winded it down through removing most of the functionality;
which I also in a "Why I (tried to) killed the LSB" DebConf17 talk
[0] (and which should probably get to release notes too).

I have and will keep an eye on src:lsb, to tackle serious issues that
might still arise, but don't want to be a blocker if anyone wants to
work on LSB for Debian, really. (Don't mistake my intentions, I don't
think it's a worthwile goal). So… it seems that a Request for Adoption
is exactly what I'm looking for: conveying that it's up for takers,
but that I'm around for the occasional fixes, and naturally also for
handover!

Join debian-...@lists.debian.org if you're interested!

Cheers,
OdyX

[0] https://debconf17.debconf.org/talks/181/

Bug#924434: unblock pre-approval: movim/0.14.1-4

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Tue, Mar 12, 2019 at 11:14:16PM +0100, Dominik George wrote:
> Please unblock package movim
> 
> Upstream fixed a few semi-critical bugs, which we here would call important.
> I added the bugs to the BTS and backported the fixes form the new upstream
> release, they are listed in the attached
> debdiff/changelog.
> 
> If you are up to gifts today, you may as well pre-approve the upload of 
> 0.14.2,
> the new upstream release. It does not include much more, only some more
> minor bugfixes and some UI improvements in CSS ;).

Please go ahead with the upload to unstable and remove the moreinfo tag from
this bug once the package is in unstable and is built on all relevant
architectures, passed piuparts, autopkgtests (if present), etc.

Thanks

Ivo

Bug#924183: Seems fixed in point release

[MK]

Postfix stable release 3.4.3 (and actually in 3.4.2, but that missed a linux5 
change)
"DANE trust anchor file support was broken after the Postfix 3.4 TLS library 
overhaul. Fix by intrigeri."

Bug#918806: [bug-mailutils] version 3.5: mail/mailx discard message body when attachment is supplied

[Sergey Poznyakoff]

Hi Daniel,

> Are you aware of this report in debian about mail discarding stdin when
> being used to send an e-mail with an attachment?
> 
> https://bugs.debian.org/918806

Thanks for reporting. I fixed it in 43214185092e714e0c233bf196f571bba5c17be0.

Meanwhile, you can use the --mime option as a workaround:

 echo "body text" | /usr/bin/mail --mime -s "some subject" -A "somefile.csv" 
m...@email.com

Regards,
Sergey

Bug#794466: Virtualbox might not be suitable for Stretch

[Ivo De Decker]

Control: severity -1 serious

Hi,

On Mon, Aug 28, 2017 at 03:01:18PM +0200, Lucas Nussbaum wrote:
> After a private discussion with Gianfranco, I'm retitling this bug and
> downgrading its severity. (Gianfranco agrees, at least on the general
> lines of argumentation).
> 
> The reasoning is as follows.
> 
> Virtualbox did not make it into stretch due to this bug, for good
> reasons.
> 
> We are at the start of the buster release cycle, and we don't know what
> will be the status at the time of the freeze. The situation around
> security support should be re-evaluated at the beginning of the buster
> freeze, but until then, it sounds like a better plan to maximize user
> testing and allow virtualbox to migrate to testing.
> 
> Security support for unstable/testing is not a problem because we are
> tracking new upstream releases anyway, where issues are being addressed
> by upstream. Also, there's a public svn repository to get fixes from if
> necessary.

Could you clarify how you intend to handle security issues for virtualbox in
buster? During a brief discussion on irc, the security team made it clear that
they won't handle that (as the package is in contrib and upstream isn't
cooperating), so it would be up to the maintainers to handle that.

Thanks,

Ivo

Bug#924518: open-vm-tools-desktop: KMS resolution detection fails

[Bernd Zeimetz]

Package: open-vm-tools-desktop
Version: 2:10.1.15-1
Severity: important

vmtoolsd needs the vmwgfx module to be able to detect available KMS
resolutions. Otherwise display resizing does not work at all.

See https://github.com/vmware/open-vm-tools/issues/214 for a longer
discussion.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Nicholas D Steeves]

On Wed, Mar 13, 2019 at 05:09:24AM -0400, Chris Lamb wrote:
> Nicholas D Steeves wrote:
> 
> > > > If you have a minute would you please sponsor this backport
> > > 
> > > Please drop the "new-package-should-not-package-python2-module"
> > > override and move the justification to the changelog.
> > > 
> > > It should be clear from this tag's description that this is override
> > > is inappropriate and, IIRC, explicitly not requested.
> > > 
> > 
> > Oops, I missed that :-$  Just to confirm: you'd like me to make this
> > change to the stretch-backport (after which it will no longer be a
> > no-change backport), and also the branch for sid, which would not be
> > uploaded until buster is released?
> 
> Sure.
> 

Done.  Updated backport available here:

  
https://mentors.debian.net/debian/pool/main/p/python-css-parser/python-css-parser_1.0.4-1~bpo9+1.dsc


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest

[Dirk Eddelbuettel]

On 13 March 2019 at 21:39, Paul Gevers wrote:
| Source: multcomp, r-cran-dosefinding
| Control: found -1 multcomp/1.4-10-1
| Control: found -1 r-cran-dosefinding/0.9-16-2
| Severity: important
| X-Debbugs-CC: debian...@lists.debian.org
| User: debian...@lists.debian.org
| Usertags: breaks needs-update
| 
| Dear maintainers,
| 
| With a recent upload of multcomp the autopkgtest of r-cran-dosefinding
| fails in testing when that autopkgtest is run with the binary packages
| of multcomp from unstable. It passes when run with only packages from
| testing. In tabular form:
|passfail
| multcomp   from testing1.4-10-1
| r-cran-dosefinding from testing0.9-16-2
| versioned deps [0] from testingfrom unstable
| all others from testingfrom testing

No issue at CRAN for multcomp:

   https://cloud.r-project.org/web/checks/check_results_multcomp.html

So this is likely self-inflicted at Debian.

Also, DoseFinding only _Suggests:_ multcomp

   https://cloud.r-project.org/web/packages/DoseFinding/index.html

Dirk

| I copied some of the output at the bottom of this report. Unfortunately,
| there is no error reported, but successful runs have more output.
| 
| Due to the nature of this issue, I filed this bug report against both
| packages. Can you please investigate the situation and reassign the bug
| to the right package? If needed, please change the bug's severity.
| 
| More information about this bug and the reason for filing it can be found on
| https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
| 
| Paul
| 
| [0] You can see what packages were added from the second line of the log
| file quoted below. The migration software adds source package from
| unstable to the list if they are needed to install packages from
| multcomp/1.4-10-1. I.e. due to versioned dependencies or breaks/conflicts.
| 
| 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-dosefinding/2099783/log.gz
| 
| autopkgtest [23:10:49]: test run-unit-test: [---
| testgFit.R passed
| testplanMod.R passed
| testsDesign.R passed
| testsFitting.R passed
| testsMCPMod.R passed
| autopkgtest [23:10:55]: test run-unit-test: ---]
| 
| [DELETED ATTACHMENT signature.asc, application/pgp-signature]

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

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

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Mon, Mar 11, 2019 at 12:18:42PM +0100, Andreas Beckmann wrote:
> Please unblock package python-saharaclient
> 
> This upload fixes removal of obsolete alternatives that would otherwise
> stay around after upgrades from stretch.
> The NMU was just uploaded to DELAYED/5

Please don't file unblock request for packages not (yet) in unstable. We can't
do anything about them, and it's just extra work to check.

Thanks,

Ivo

P.S. I've tagged this bug moreinfo for now instead of closing it, please
remove the tag once the package is in unstable.

Bug#924517: perl: POSIX::mblen() broken

[Niko Tyni]

Package: perl
Version: 5.28.1-4
Tags: upstream patch

As reported in https://bugs.launchpad.net/bugs/1818953 POSIX::mblen()
is broken on threaded perls with glibc.

  % perl -MPOSIX=mblen -e 'mblen("a", 1)'
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  zsh: abort (core dumped)  perl -MPOSIX=mblen -e 'mblen("a", 1)'

This is a 5.28 regression. I've reported it upstream with the attached
proposed patch, which should be trivial to backport to 5.28.

Will update this bug with the upstream ticket number once I get one.
-- 
Niko Tyni   nt...@debian.org
>From aaf1159fe2b891f63f819b2d496b0f938456a36d Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sun, 10 Mar 2019 19:40:42 +0200
Subject: [PATCH] Fix POSIX::mblen mbstate_t initialization on threaded perls
 with glibc

As reported in https://bugs.launchpad.net/bugs/1818953 POSIX::mblen()
is broken on threaded perls with glibc.

  % perl -MPOSIX=mblen -e 'mblen("a", 1)'
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  zsh: abort (core dumped)  perl -MPOSIX=mblen -e 'mblen("a", 1)'

This broke in v5.27.8-134-g6c9ff7e96e which made the function
use mbrlen(3) under the hood on threaded perls.

The problem is initialization of the shift state with

  mbrlen(NULL, 0, &ps));

The glibc documentation for mbrlen(3) at

  https://www.gnu.org/software/libc/manual/html_node/Converting-a-Character.html#Converting-a-Character

does not mention initialization by passing in a null pointer for the
string, only a pointer to a NUL wide character.

   If the next multibyte character corresponds to the NUL wide character,
   the return value is 0. If the next n bytes form a valid multibyte
   character, the number of bytes belonging to this multibyte character
   byte sequence is returned.

Use memset(3) instead for mbstate_t initialization, as suggested in

  https://www.gnu.org/software/libc/manual/html_node/Keeping-the-state.html

with the hope that this is more portable.

While at it, add a few basic test cases. These are in a new file because
they need fresh_perl_is() from test.pl while the existing ones use
Test::More (and conversion of at least posix.t looks way too involved.)

Bug-Ubuntu: https://bugs.launchpad.net/bugs/1818953
---
 MANIFEST   |  1 +
 ext/POSIX/POSIX.xs |  2 +-
 ext/POSIX/lib/POSIX.pm |  2 +-
 ext/POSIX/t/mb.t   | 45 ++
 4 files changed, 48 insertions(+), 2 deletions(-)
 create mode 100644 ext/POSIX/t/mb.t

diff --git a/MANIFEST b/MANIFEST
index 4cf40a8eec..57465859b9 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -4182,6 +4182,7 @@ ext/POSIX/POSIX.xs		POSIX extension external subroutines
 ext/POSIX/t/export.t		Test @EXPORT and @EXPORT_OK
 ext/POSIX/t/iscrash		See if POSIX isxxx() crashes with threads on Win32
 ext/POSIX/t/math.t		Basic math tests for POSIX
+ext/POSIX/t/mb.t		Multibyte function tests for POSIX
 ext/POSIX/t/posix.t		See if POSIX works
 ext/POSIX/t/sigaction.t		See if POSIX::sigaction works
 ext/POSIX/t/sigset.t		See if POSIX::SigSet works
diff --git a/ext/POSIX/POSIX.xs b/ext/POSIX/POSIX.xs
index 1ebc358af4..27051c1fdb 100644
--- a/ext/POSIX/POSIX.xs
+++ b/ext/POSIX/POSIX.xs
@@ -3329,7 +3329,7 @@ mblen(s, n)
 #endif
 CODE:
 #if defined(USE_ITHREADS) && defined(HAS_MBRLEN)
-PERL_UNUSED_RESULT(mbrlen(NULL, 0, &ps));   /* Initialize state */
+memset(&ps, 0, sizeof(ps)); /* Initialize state */
 RETVAL = mbrlen(s, n, &ps); /* Prefer reentrant version */
 #else
 RETVAL = mblen(s, n);
diff --git a/ext/POSIX/lib/POSIX.pm b/ext/POSIX/lib/POSIX.pm
index 25392be4b1..4de039410f 100644
--- a/ext/POSIX/lib/POSIX.pm
+++ b/ext/POSIX/lib/POSIX.pm
@@ -4,7 +4,7 @@ use warnings;
 
 our ($AUTOLOAD, %SIGRT);
 
-our $VERSION = '1.87';
+our $VERSION = '1.88';
 
 require XSLoader;
 
diff --git a/ext/POSIX/t/mb.t b/ext/POSIX/t/mb.t
new file mode 100644
index 00..4c60c22bae
--- /dev/null
+++ b/ext/POSIX/t/mb.t
@@ -0,0 +1,45 @@
+#!./perl
+
+# These tests are in a separate file, because they use fresh_perl_is()
+# from test.pl.
+
+# The mb* functions use the "underlying locale" that is not affected by
+# the Perl one.  So we run the tests in a separate "fresh_perl" process
+# with the correct LC_CTYPE set in the environment.
+
+BEGIN {
+require Config; import Config;
+if ($^O ne 'VMS' and $Config{'extensions'} !~ /\bPOSIX\b/) {
+	print "1..0\n";
+	exit 0;
+}
+unshift @INC, "../../t";
+require 'loc_tools.pl';
+require 'test.pl';
+}
+
+plan tests => 3;
+
+use POSIX qw();
+
+SKIP: {
+skip("mblen() not present", 3) unless $Config{d_mblen};
+
+is(&POSIX::mblen("a", &POSIX::MB_CUR_MAX), 1, 'mblen() basically works');
+
+skip("LC_CTYPE locale support not available", 2)
+  unless locales_enabled('LC_CTYPE');
+
+my $utf8_locale = find_utf8_ctype_locale();
+skip("no utf8 locale available", 2) unless $utf8_locale;
+
+local $ENV{LC_CTYPE} = $utf8_locale;
+
+fresh_perl_

Bug#924516: geoclue-2.0: geoclue gets location despite geolocation features turned off (GNOME Privacy)

[Alain Ducharme]

Package: geoclue-2.0
Version: 2.5.2-1
Severity: normal

Dear Maintainer,

(Testing Debian 10 Buster)
Using GNOME Settings > Privacy, turned off the geolocation features on the
desktop; however geoclue still contacts location.services.mozilla.com in the
background whenever an application requests location services.

When geolocation features are turned off, I would expect this to not occur.  
I would expect no communications with location.services.mozilla.com to 
be occurring with this privacy setting.

Steps to reproduce:

1) "Turn off the geolocation features of your desktop" (as per GNOME Help)
GNOME Settings > Privacy > Location Services = Off
# optional - verify from command line that location services are turned off:
gsettings get org.gnome.system.location enabled # should return: false

2) Monitor geoclue packets using netfilter

option A) using iptables
iptables -A OUTPUT -m owner --gid-owner geoclue

# Launch GNOME Maps (or other app utilizing geoclue, e.g. GNOME Calendar)

iptables -nvxL OUTPUT
#Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
#pkts  bytes target prot opt in out source destination
#  13 1697all  --  *  *   0.0.0.0/0 0.0.0.0/0   
 owner GID match 116

option B) using nftables (alternative)
nft add table inet geoclue
nft "add chain inet geoclue geoclue { type filter hook output priority 0; }"
nft add rule inet geoclue geoclue skuid geoclue counter

# Launch GNOME Maps (or other app utilizing geoclue, e.g. GNOME Calendar)

nft list ruleset
#table inet geoclue {
#   chain geoclue {
#   type filter hook output priority 0; policy accept;
#   skuid "geoclue" counter packets 13 bytes 1697
#   }
#}

...geoclue is communicating with location.services.mozilla.com when it should
not.

Work around is to disable and mask geoclue.service.

Thank you!

-- 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)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages geoclue-2.0 depends on:
ii  adduser 3.118
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libavahi-glib1  0.7-4+b1
ii  libc6   2.28-8
ii  libglib2.0-02.58.3-1
ii  libjson-glib-1.0-0  1.4.4-2
ii  libmm-glib0 1.10.0-1
ii  libnotify4  0.7.7-4
ii  libsoup2.4-12.64.2-2

Versions of packages geoclue-2.0 recommends:
ii  avahi-daemon  0.7-4+b1
ii  iio-sensor-proxy  2.4-2
ii  modemmanager  1.10.0-1
ii  wpasupplicant 2:2.7+git20190128+0c1e29f-2

geoclue-2.0 suggests no packages.

-- no debconf information

Bug#923533: Missing Vcs-* headers

[Bernhard R. Link]

* Axel Beckert  [190301 15:39]:
> it is confusing that VCS related package has no Vcs-* headers.
>
> git-dpm though seems to have a Git repository on Salsa at
> https://salsa.debian.org/brlink/git-dpm.
>
> So please add the according Vcs-* headers:
>
>   Vcs-Git: https://salsa.debian.org/brlink/git-dpm.git
>   Vcs-Browser: https://salsa.debian.org/brlink/git-dpm

That repository is a mostly semi-temporary place. I've yet not
decided whether it will stay there, or if I will request a
group for it (like it had on alioth) or move it to the Debian group.

Also after getting disappointed two times (first git.debian.org and
then anonscm.debian.org), I lost the believe that those URLs are
even supposed to be be valid for a full release lifetime and thus
am no longer persuaded that putting that information into the archive
is the proper think to do. I'd much rather see some registry where
maintainers can put information about the current leading repository
whenever that changes and where tools like debcheckout can query it from.

> Maybe you also want to add a Homepage header pointing to the latter
> URL, too:
>
>   Homepage: https://salsa.debian.org/brlink/git-dpm

git-dpm actually had a proper homepage, which also got lost with
alioth. I'm still considering where to revive that.

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

Bug#923364: FTBS: Can't build against bouncy-castle build with newer jdk

[Markus Koschany]

Control: severity -1 important

On Sat, 2 Mar 2019 15:38:51 +0100 Markus Koschany  wrote:
[...]
> Could you elaborate on why this is a bug in libitext-java and how this
> is connected to bouncycastle?

Unfortunately you haven't responded to my last email. I can't reproduce
this behavior in libitext-java but I will gladly apply any patch that
fixes RC issues if further information are provided.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#924515: jupyter-notebook: CVE-2019-9644

[Salvatore Bonaccorso]

Source: jupyter-notebook
Version: 5.7.4-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for jupyter-notebook.

CVE-2019-9644[0]:
| An XSSI (cross-site inclusion) vulnerability in Jupyter Notebook before
| 5.7.6 allows inclusion of resources on malicious pages when visited by
| users who are authenticated with a Jupyter server. Access to the
| content of resources has been demonstrated with Internet Explorer
| through capturing of error messages, though not reproduced with other
| browsers. This occurs because Internet Explorer's error messages can
| include the content of any invalid JavaScript that was encountered.

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-9644
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9644
[1] https://github.com/jupyter/notebook/compare/f3f00df...05aa4b2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest

[Paul Gevers]

Source: multcomp, r-cran-dosefinding
Control: found -1 multcomp/1.4-10-1
Control: found -1 r-cran-dosefinding/0.9-16-2
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of multcomp the autopkgtest of r-cran-dosefinding
fails in testing when that autopkgtest is run with the binary packages
of multcomp from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
multcomp   from testing1.4-10-1
r-cran-dosefinding from testing0.9-16-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. Unfortunately,
there is no error reported, but successful runs have more output.

Due to the nature of this issue, I filed this bug report against both
packages. Can you please investigate the situation and reassign the bug
to the right package? If needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
multcomp/1.4-10-1. I.e. due to versioned dependencies or breaks/conflicts.

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-dosefinding/2099783/log.gz

autopkgtest [23:10:49]: test run-unit-test: [---
testgFit.R passed
testplanMod.R passed
testsDesign.R passed
testsFitting.R passed
testsMCPMod.R passed
autopkgtest [23:10:55]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

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

[Didier 'OdyX' Raboud]

Le mercredi, 13 mars 2019, 18.17:34 h CET Dmitry Bogatov a écrit :
> [2019-03-11 21:51] Axel Beckert 
> > > 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):

Great. Thanks for the tests, you got me convinced. :-)

> Okay. Should I NMU or not? Anybody know what is the current status of
> maintenance?

I'll upload tonight, crediting the patch to Dmitry.

Regarding the maintenance status of src:lsb: I'm only keeping an (opinionated) 
eye on it, to avoid having it orphaned (hence my upload of tonight). But 
really, it is up for adoption. I should perhaps make that clearer by removing 
myself from uploader. Opinions?

Cheers, and thanks again for the testing!

OdyX

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

Bug#924161: unblock: lirc/0.10.1-5.1

[Nicolas Braud-Santoni]

On Tue, Mar 12, 2019 at 07:46:34AM +0100, Andreas Beckmann wrote:
> Hi Nicolas,

Hi Andreas,

> On 2019-03-12 02:21, Nicolas Braud-Santoni wrote:
> I didn't spot anything obviously broken in the new diff.

\o/

Sorry this took so much back-and-forth, and thanks for your patience  <3


> Just to verify again, the package currently has broken symlinks that are going
> to be replaced by files, not directories? (Otherwise you would still need some
> symlink_to_dir.)

Correct  :)


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#912549: icedtea-web FTBFS with OpenJDK 11

[Markus Koschany]

Am 13.03.19 um 17:47 schrieb Matthias Klose:
> On 13.03.19 10:54, Andreas Tille wrote:
>> On Tue, Mar 12, 2019 at 11:41:22AM +0100, Andreas Tille wrote:
>>> Michael Crusoe has suggested a workaround[1].  What do you think about
>>> this?
>>
>> In case there is no answer to this question I assume it is OK to
>> upload the workaround.  Hope you agree with this.
> 
> please look at the new upstream 1.7.2 and 1.8 releases.
> 

In https://bugs.debian.org/855686 Emmanuel wrote that icedtea-web will
be removed. I don't have a strong opinion in this case. If Michael's
workaround works, why not. However I think it is too late now for new
upstream releases as doko seems to imply.

Please note there are several other RC issues that are marked as pending
but I believe the "fix" is to remove the package from Debian.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=icedtea-web

Markus



signature.asc
Description: OpenPGP digital signature

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

[Didier 'OdyX' Raboud]

Hi there Andreas,

Le mercredi, 6 février 2019, 20.20:54 h CET Andreas Metzler a écrit :
> there is a logic error in /lib/lsb/init-functions's killproc:
> 
> base=${1##*/}
> if [ ! $pidfile ]; then
> name_param="--name $base --pidfile /var/run/$base.pid"
> else
> name_param="--pidfile $pidfile"
> fi

This is there since 3.2-20, 10+ years ago:

In 2.0-5 (2005-01-30):
if [ ! $pidfile ]; then
pidfile=/var/run/$(basename "$1").pid

fi

In 3.0-11 (2005-10-27):
base=$(basename "$1")
if [ ! $pidfile ]; then
pidfile=/var/run/$base.pid
fi

In 3.1-20 (2006-11-16):
"Don't use --name in killproc() when a pidfile is provided (Closes: #397977)"

base=${1##*/}
if [ ! $pidfile ]; then
pidfile=/var/run/$base.pid
name_param="--name $base"
fi

In 3.2-16 (2008-08-01):
"Fix behavior of killproc and pidofproc when no pidfile is passed in."

base=${1##*/}
if [ ! $pidfile ]; then
name_param="--name $base"
else
name_param="--pidfile $pidfile"
fi

In 3.2-20 (2008-08-18):
"pidofproc now also checks for /var/run/$base.pid if -p is not specified, 
fixing conformance with the spec."

base=${1##*/}
if [ ! $pidfile ]; then
name_param="--name $base --pidfile /var/run/$base.pid"
else
name_param="--pidfile $pidfile"
fi

I'm just pointing out that it's an old bug; and that makes me uncomfortable to 
fix it, especially for a shell script installed on virtually _all_ Debian 
hosts.

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

… but arguably, the code is bogus. :-)

(Will answer to other points down the thread)

Cheers,
OdyX

Bug#924513: request for updated ARM compile of valgrind package

[Jon Hamill]

Package: valgrind:armhf

Version: valgrind-3.12.0.SVNvalgrind-3.12.0.SVN


When I invoke valgrind to run my binary I am met with a failed assertion about 
a type size. The bug was fixed upstream in valgrind source as of 
https://bugs.kde.org/show_bug.cgi?id=362935


Here is a transcript of the error message from the logfile I used when running 
my executable in valgrind:

==2695== Memcheck, a memory error detector
==2695== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==2695== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==2695== Command: ./fcsServer
==2695== Parent PID: 1775
==2695==

valgrind: m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion 'sizeof(TTEntryC) 
<= 88' failed.



I am using Linux debian 4.13.0 #29 SMP PREEMPT Mon Mar 11 11:46:47 EDT 2019 
armv7l GNU/Linux


with this cpuinfo


root@debian:~/incoming/bin# cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 5 (v7l)
BogoMIPS: 48.00
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
vfpd32 lpae
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xc07
CPU revision: 5

Hardware: Freescale i.MX6 Ultralite (Device Tree)
Revision: 
Serial  : 



Thanks in advance!


Best,

-Jon

Bug#924512: elpa-with-editor: Fix version 2.6.0 -> 2.8.1

[Fedor Khodkov]

Package: elpa-with-editor
Version: 2.8.1-1
Severity: normal

Hello,

Debian package claims elpa-with-editor has version 2.8.1, but inside
emacs it's seen as 2.6.0.  I suppose version information is generated
inside debian/rules file, where in line 2 it's still says VERSION=2.6.0

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

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

Versions of packages elpa-with-editor depends on:
ii  emacsen-common  3.0.4

elpa-with-editor recommends no packages.

elpa-with-editor suggests no packages.

-- no debconf information

Bug#924511: elpa-ghub: Update version 3.0.0 -> 3.2.0

[Fedor Khodkov]

Package: elpa-ghub
Version: 3.2.0-1
Severity: normal

Hello,

Debian package claims elpa-ghub has version 3.2.0, but inside emacs it's
seen as 3.0.0.  It seems file debian/patches/01-fix_version.diff needs to
be updated.

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

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

Versions of packages elpa-ghub depends on:
ii  elpa-dash   2.14.1+dfsg-1
ii  elpa-graphql0.1.1-3
ii  elpa-let-alist  1.0.5-3
ii  elpa-treepy 0.1.1-1
ii  emacsen-common  3.0.4

Versions of packages elpa-ghub recommends:
ii  emacs1:26.1+1-3.2+local1
ii  emacs-lucid [emacs]  1:26.1+1-3.2+local1

elpa-ghub suggests no packages.

-- no debconf information

Bug#893048: ITP: dovecot-trees -- Dovecot individually encrypted email storage plugin

[Georg Faerber]

Control: retitle -1 RFP: dovecot-trees -- Dovecot individually encrypted email 
storage plugin
Control: noowner -1

Hi all,

On 18-03-15 22:34:08, Georg Faerber wrote:
> This package will be maintained within the Debian Dovecot team.

A friend of mine was interested in packaging this, and I would have
helped them. In the meantime, a similar implementation was integrated
upstream into Dovecot. My friend is now using this native feature,
instead of dovecot-trees.

I won't package this personally, accordingly changing the bug
information to reflect the current state.

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#924510: cron runs job at wrong time; ignores values in /etc/crontab; after upgrade to buster

[Tony Walker]

Package: cron
Version: 3.0pl1-132
Severity: normal

Dear Maintainer,

* What led up to the situation?

I upgraded to Buster from stretch and noticed that my cron jobs were running at 
~7:38 AM
instead of the time in my /etc/crontab. After some troubleshooting, I did 
reinstall by
installing from 9.7 media followed immediately by apt full-upgrade. The problem 
persisted.
I then did the same on a different system and found that the problem exists on 
this
system as well (total of two out of two systems that exhibit the problem).

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

I tried the default setting of 6:25 AM ["25 6 * * *"] and a few other times
(e.g., 1:00 AM ["0 1 * * *"]). cron seems to ignore all entries and the jobs 
always
run at ~7:38 AM. date and hwclock agree on current time. /etc/timezone is 
America/New_York
which is correct for me. TZ is not set anywhere that I can find. 
/var/spool/cron/crontabs
is empty, so there should be no other/duplicate jobs causing confusion. Also, 
the recent
shift to DST in the US did not change the behavior.

I googled, searched stackoverflow and bug reports, and posted in the forums. It 
appears
that I am the only person to observe this behavior, so I feel like a stupid 
user and have
been reluctant to send a report. However, I can reproduce the behavior on 
different
systems from a clean install using the default configuration.

* What was the outcome of this action?

Nothing seems to resolve the problem.

* What outcome did you expect instead?

I expected the jobs in the system crontab to run at the specified time.

-- Package-specific info:
--- EDITOR:


--- /usr/bin/editor:
/bin/nano

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 43600 Feb 24 15:56 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 3 root root 4096 Mar 1 20:51 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Oct 7 2017 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Mar 7 20:02 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Mar 12 17:19 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Mar 7 20:02 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Mar 7 20:02 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Mar 12 17:19 /etc/cron.weekly


-- 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)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cron depends on:
ii adduser 3.118
ii debianutils 4.8.6.1
ii init-system-helpers 1.56+nmu1
ii libc6 2.28-8
ii libpam-runtime 1.3.1-5
ii libpam0g 1.3.1-5
ii libselinux1 2.8-1+b1
ii lsb-base 10.2018112800
ii sensible-utils 0.0.12

Versions of packages cron recommends:
ii exim4-daemon-light [mail-transport-agent] 4.92-2

Versions of packages cron suggests:
ii anacron 2.3-27
pn checksecurity 
ii logrotate 3.14.0-4

Versions of packages cron is related to:
pn libnss-ldap 
pn libnss-ldapd 
pn libpam-ldap 
pn libpam-mount 
pn nis 
pn nscd 

-- no debconf information
Package: cron
Version: 3.0pl1-132
Severity: normal


Dear Maintainer,


   * What led up to the situation?


I upgraded to Buster from stretch and noticed that my cron jobs were running at 
~7:38 AM 
instead of the time in my /etc/crontab. After some troubleshooting, I did 
reinstall by 
installing from 9.7 media followed immediately by apt full-upgrade. The problem 
persisted. 
I then did the same on a different system and found that the problem exists on 
this 
system as well (total of two out of two systems that exhibit the problem).


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


I tried the default setting of 6:25 AM ["25 6 * * *"] and a few other times 
(e.g., 1:00 AM ["0 1 * * *"]). cron seems to ignore all entries and the jobs 
always 
run at ~7:38 AM. date and hwclock agree on current time. /etc/timezone is 
America/New_York 
which is correct for me. TZ is not set anywhere that I can find. 
/var/spool/cron/crontabs 
is empty, so there should be no other/duplicate jobs causing confusion. Also, 
the recent
shift to DST in the US did not change the behavior.


I googled, searched stackoverflow and bug reports, and posted in the forums. It 
appears
that I am the only person to observe this behavior, so I feel like a stupid 
user and have 
been reluctant to send a report. However, I can reproduce the behavior on 
different 
systems from a clean install using the default configuration.


   * What was the outcome of this action?


Nothing seems to resolve the problem.


   * What outcome did you expect instead?


I expected the jobs in

Bug#924509: CVE-2016-9840 CVE-2016-9841 CVE-2016-9842 CVE-2016-9843

[Moritz Muehlenhoff]

Package: rsync
Version: 3.1.3-5
Severity: grave
Tags: security

rsync ships a local copy of zlib, which misses the security fixes for
CVE-2016-9840 CVE-2016-9841 CVE-2016-9842 CVE-2016-9843.

I've attached the respective upstream patches.

Also, let's revisit using the shared zlib copy for bullseye, please.

Cheers,
Moritz
>From 6a043145ca6e9c55184013841a67b2fef87e44c0 Mon Sep 17 00:00:00 2001
From: Mark Adler 
Date: Wed, 21 Sep 2016 23:35:50 -0700
Subject: [PATCH] Remove offset pointer optimization in inftrees.c.

inftrees.c was subtracting an offset from a pointer to an array,
in order to provide a pointer that allowed indexing starting at
the offset. This is not compliant with the C standard, for which
the behavior of a pointer decremented before its allocated memory
is undefined. Per the recommendation of a security audit of the
zlib code by Trail of Bits and TrustInSoft, in support of the
Mozilla Foundation, this tiny optimization was removed, in order
to avoid the possibility of undefined behavior.
---
 inftrees.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/inftrees.c b/inftrees.c
index 22fcd666..0d2670d5 100644
--- a/inftrees.c
+++ b/inftrees.c
@@ -54,7 +54,7 @@ unsigned short FAR *work;
 code FAR *next; /* next available space in table */
 const unsigned short FAR *base; /* base value table to use */
 const unsigned short FAR *extra;/* extra bits table to use */
-int end;/* use base and extra for symbol > end */
+unsigned match; /* use base and extra for symbol >= match */
 unsigned short count[MAXBITS+1];/* number of codes of each length */
 unsigned short offs[MAXBITS+1]; /* offsets in table for each length */
 static const unsigned short lbase[31] = { /* Length codes 257..285 base */
@@ -181,19 +181,17 @@ unsigned short FAR *work;
 switch (type) {
 case CODES:
 base = extra = work;/* dummy value--not used */
-end = 19;
+match = 20;
 break;
 case LENS:
 base = lbase;
-base -= 257;
 extra = lext;
-extra -= 257;
-end = 256;
+match = 257;
 break;
 default:/* DISTS */
 base = dbase;
 extra = dext;
-end = -1;
+match = 0;
 }
 
 /* initialize state for loop */
@@ -216,13 +214,13 @@ unsigned short FAR *work;
 for (;;) {
 /* create table entry */
 here.bits = (unsigned char)(len - drop);
-if ((int)(work[sym]) < end) {
+if (work[sym] + 1 < match) {
 here.op = (unsigned char)0;
 here.val = work[sym];
 }
-else if ((int)(work[sym]) > end) {
-here.op = (unsigned char)(extra[work[sym]]);
-here.val = base[work[sym]];
+else if (work[sym] >= match) {
+here.op = (unsigned char)(extra[work[sym] - match]);
+here.val = base[work[sym] - match];
 }
 else {
 here.op = (unsigned char)(32 + 64); /* end of block */
>From 9aaec95e82117c1cb0f9624264c3618fc380cecb Mon Sep 17 00:00:00 2001
From: Mark Adler 
Date: Wed, 21 Sep 2016 22:25:21 -0700
Subject: [PATCH] Use post-increment only in inffast.c.

An old inffast.c optimization turns out to not be optimal anymore
with modern compilers, and furthermore was not compliant with the
C standard, for which decrementing a pointer before its allocated
memory is undefined. Per the recommendation of a security audit of
the zlib code by Trail of Bits and TrustInSoft, in support of the
Mozilla Foundation, this "optimization" was removed, in order to
avoid the possibility of undefined behavior.
---
 inffast.c | 81 +--
 1 file changed, 31 insertions(+), 50 deletions(-)

diff --git a/inffast.c b/inffast.c
index bda59ceb..f0d163db 100644
--- a/inffast.c
+++ b/inffast.c
@@ -10,25 +10,6 @@
 
 #ifndef ASMINF
 
-/* Allow machine dependent optimization for post-increment or pre-increment.
-   Based on testing to date,
-   Pre-increment preferred for:
-   - PowerPC G3 (Adler)
-   - MIPS R5000 (Randers-Pehrson)
-   Post-increment preferred for:
-   - none
-   No measurable difference:
-   - Pentium III (Anderson)
-   - M68060 (Nikl)
- */
-#ifdef POSTINC
-#  define OFF 0
-#  define PUP(a) *(a)++
-#else
-#  define OFF 1
-#  define PUP(a) *++(a)
-#endif
-
 /*
Decode literal, length, and distance codes and write out the resulting
literal and match bytes until either not enough input or output is
@@ -96,9 +77,9 @@ unsigned start; /* inflate()'s starting value for 
strm->avail_out */
 
 /* copy state to local variables */
 state = (struct inflate_state FAR *)strm->state;
-in = strm->next_in - OFF;
+in = strm->next_in;
 last = in + (strm->avail_in - 5);
-out = strm->next_out - OFF;
+out = strm->next_out;
 beg = out - (start - strm->avail_out);
  

Bug#924508: neutron: CVE-2019-9735: it's possible to add a security group rule for VRRP with a dport

[Salvatore Bonaccorso]

Source: neutron
Version: 2:13.0.2-10
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugs.launchpad.net/neutron/+bug/1818385

Hi,

The following vulnerability was published for neutron.

CVE-2019-9735[0]:
| An issue was discovered in the iptables firewall module in OpenStack
| Neutron before 10.0.8, 11.x before 11.0.7, 12.x before 12.0.6, and 13.x
| before 13.0.3. By setting a destination port in a security group rule
| along with a protocol that doesn't support that option (for example,
| VRRP), an authenticated user may block further application of security
| group rules for instances from any project/tenant on the compute hosts
| to which it's applied. (Only deployments using the iptables security
| group driver are affected.)

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-9735
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9735
[1] https://bugs.launchpad.net/neutron/+bug/1818385

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#920446: tries to rename VLAN interface

[Michael Biebl]

Am 13.03.19 um 19:26 schrieb Marc Haber:
> forwarded #920446 https://github.com/systemd/systemd/issues/11992
> thanks
> 
> On Sun, Mar 10, 2019 at 12:04:32AM +0100, Michael Biebl wrote:
>> If this is still a problem with v241, would you mind filing a bug report
>> upstream at https://github.com/systemd/systemd
> 
> It is. #11992.

Thanks, Marc


-- 
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#785512: regression: cannot find iso image on usb stick any more

[Christian Kastner]

On Thu, 28 May 2015 15:26:05 +0100 Philip Hands  wrote:>
It looks to me as though we're missing iso-scan and load-iso from the
> cdrom target, and that as a result we neither include the loop module,
> nor do we attempt to mount the usb stick, nor look for the ISO therein.

This is an ancient request, but as I found myself today again dd'ing
numerous USB sticks, so I thought I'd poke it again:

Would it be possible to get iso-scan (or whatever is needed to get the
installer to find ISO files on a drive) in the CD initrd?

32GB USB sticks go for €4.50 here, it would be great if the space could
be used for multiple ISOs, instead of having to purchase one stick each
per intended ISO.

Regards,
Christian

Bug#924507: ksplashqml: hits its hard timeout of 30 seconds

[Bernhard Übelacker]

Package: plasma-workspace
Version: 4:5.14.5.1-1
Severity: normal
Tags: patch upstream



Dear Maintainer,

I found that the splash screen takes longer than some month ago and did
some investigations that led to following two upstream bugs I reported.

Bug 405444 - ksplashqml hits its hard timeout of 30 seconds because of failing 
qdbus call kinit
Bug 405446 - ksplashqml hits its hard timeout of 30 seconds because setStage(6) 
is needed twice

Because of the near buster release they might be evaluated independent of
upstream for its use in buster to avoid bad user impressions.

The first one probably just manifests on faster systems when the
dbus interface of ksplashqml is not yet up.

The second one might need two setStage(6) calls to arrive when we
maybe just receive one.

Both changes reduced the time ksplashqml is shown at my
system from 30 to 5 seconds.

Kind regards,
Bernhard


https://bugs.kde.org/show_bug.cgi?id=405444
https://bugs.kde.org/show_bug.cgi?id=405446

Bug#920446: tries to rename VLAN interface

[Marc Haber]

forwarded #920446 https://github.com/systemd/systemd/issues/11992
thanks

On Sun, Mar 10, 2019 at 12:04:32AM +0100, Michael Biebl wrote:
> If this is still a problem with v241, would you mind filing a bug report
> upstream at https://github.com/systemd/systemd

It is. #11992.

Greetings
Marc

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

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

[Niko Tyni]

On Wed, Feb 27, 2019 at 09:20:25PM +0200, Niko Tyni wrote:
> On Mon, Feb 25, 2019 at 11:31:14AM +0100, Gianfranco Costamagna wrote:
> > Package: libmarc-charset-perl
> > Version: 1.35-2
> > Severity: serious
> > 
> > Hello, for some reasons the package testsuite started to fail in Ubuntu for 
> > this package and xml-perl reverse-dependency,
> > only on armhf and i386.
> > This happened when the new gdbm has been uploaded and rebuilds issued.
> > 
> > I traced down the problem to some differences in the march8/utf8 Table 
> > generation, I don't know how serious it is, but the
> > testsuite seems completely broken on armhf and i386 at least, and utf8 cjk 
> > conversion seems to return wrong values.
> > This is the reason for me opening this bug as "serious".
> 
> Thanks for noticing this. I've confirmed that this happens on at least
> Debian sid/i386 too. It's a bit unfortunate that we only have autopkgtest
> checks on amd64, so this wasn't spotted earlier.
> 
> > after a no-change rebuild of the package, and installing it, the test goes 
> > passing ok:

This was discussed in #923609, and src:gdbm will not restore backward
binary compatibility. The incompatibility is due to building with
LFS support in the newer versions. The gdbmtool package now includes
separate -nolfs binaries compatible with old databases, so that they
can be converted to a compatible binary format.

This means that libmarc-charset-perl indeed needs to be rebuilt.  However,
a simple binNMU does not do anything to prevent broken combinations of
libmarc-charset-perl and perl in partial upgrades.

I suggest the following steps to fix this:

- have perl_5.28.1-5 Build-Depend on libgdbm-dev (>= 1.18-3)
  [any gdbm version built with LFS support would do, but 1.18-3
   fixed other binary compat issues so pick that for safety]

- have perl_5.28.1-5 Break libmarc-charset-perl (<< 1.35-3)

- have libmarc-charset-perl_1.35-3 Build-Depend and Depend on
  perl (>= perl_5.28.1-5)

We could limit the above to just 32-bit architectures, but IIRC those
would need to be listed one by one and it's probably not worth the
trouble.

This will cause temporary uninstallability of libmarc-charset-perl in
sid so the uploads should be coordinated a bit. I guess I can do both
if needed.

Will clone a separate bug against perl soon but would appreciate some
eyeballs first.
-- 
Niko

Bug#924494: chrony fails to start when seccomp enabled on armel

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

On Wed, Mar 13, 2019 at 03:17:21PM +, Leigh Brown wrote:

Package: chrony
Version: 3.4-3
Severity: important
Tags: patch upstream

Dear Maintainer,

chrony on armel does not start due to seccomp not allowing all required
system calls.


Thanks for your report, that is very appreciated. I forwarded your patch 
upstream, taking the liberty to fix some coding style issues (spacing 
and sorting).


However, I would need more information. Does this issue happen with the 
default chronyd configuration?


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#598559: autofs5: Variable substitution in /etc/auto.master not working

[Bob Burton]

Package: autofs
Version: 5.1.2-4
Followup-For: Bug #598559

Dear Maintainer,

What led up to the situation?

   Upgraded debian server from squeeze (6.0.3) running autofs 4.1.4+debian-3 to 
stretch (9.7) running autofs 5.1.2-4.

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

   Retained existing /etc/auto* files.

What was the outcome of this action?

   Error messages in syslog:

   Mar 13 09:55:24 cronbot2 automount[701]: syntax error in map near [ -DDIR ]
   Mar 13 09:55:24 cronbot2 automount[701]: /
   Mar 13 09:55:24 cronbot2 automount[701]: syntax error in map near [ u2 ]
   Mar 13 09:55:24 cronbot2 automount[701]: /
   Mar 13 09:55:24 cronbot2 automount[701]: syntax error in map near [ u3 ]
   Mar 13 09:55:24 cronbot2 automount[701]: /
   Mar 13 09:55:24 cronbot2 automount[701]: syntax error in map near [ u4 ]
   Mar 13 09:55:24 cronbot2 automount[701]: /
   Mar 13 09:55:24 cronbot2 automount[701]: syntax error in map near [ u5 ]
   Mar 13 09:55:24 cronbot2 automount[701]: /
   Mar 13 09:55:24 cronbot2 systemd[1]: Started Automounts filesystems on 
demand.
   Mar 13 09:55:24 cronbot2 automount[701]: syntax error in map near [ u6 ]

   Automount does not work on login.

What outcome did you expect instead?

   I was hoping it would work and I could go home :).

I re-configured the /etc/auto.master not to use variable substitution, and 
automount started working again.

The man page should eventually be updated--it still includes documentation for 
the -D variable substitution option.

Thanks,
Bob

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 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)

Versions of packages autofs depends on:
ii  libc62.24-11+deb9u3
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  ucf  3.0036

Versions of packages autofs recommends:
ii  e2fsprogs   1.43.4-2
ii  kmod23-2
ii  nfs-common  1:1.3.4-2.1

autofs suggests no packages.

-- Configuration Files:
/etc/init.d/autofs changed:
FLAGS="defaults 21"
DAEMON=/usr/sbin/automount
prog=`basename $DAEMON`
initdir=/etc/init.d
test -e $DAEMON || exit 0
system=unknown
if [ -f /etc/debian_version ]; then
system=debian
elif [ -f /etc/redhat-release ]; then
system=redhat
else
echo "$0: Unknown system, please port and contact 
aut...@linux.kernel.org" 1>&2
exit 1
fi
if [ $system = redhat ]; then
. $initdir/functions
fi
if [ $system = debian ]; then
thisscript="$0"
if [ ! -f "$thisscript" ]; then
echo "$0: Cannot find myself" 1>&2
exit 1
fi
fi
PATH=/sbin:/usr/sbin:/bin:/usr/bin
export PATH
localoptions=''
daemonoptions=''
if [ "$system" = "redhat" ]; then
LOCALOPTIONS=""
DAEMONOPTIONS=""
UNDERSCORETODOT=1
DISABLE_DIRECT=1
DAEMON_EXIT_WAIT=20
[ -f /etc/sysconfig/autofs ] && . /etc/sysconfig/autofs
# Over-ride localoptions if set
if [ -n "$LOCALOPTIONS" ]; then
localoptions=$LOCALOPTIONS
fi
# Over-ride daemonoptions if set
if [ -n "$DAEMONOPTIONS" ]; then
daemonoptions=$DAEMONOPTIONS
fi
elif [ "$system" = "debian" ]; then
TIMEOUT=300
DISABLE_DIRECT=1
DAEMON_EXIT_WAIT=20
[ -f /etc/default/autofs ] && . /etc/default/autofs
daemonoptions="$daemonoptions --timeout=$TIMEOUT"
fi
function getschemes()
{
SOURCES=`grep ^automount: /etc/nsswitch.conf | \
 sed -e 's/^.*://' -e 's/\[.*\]/ /g'`
if [ `echo $SOURCES | awk '{print NF}'` -gt 0 ]
then
echo ${SOURCES}
else
echo files
fi
}
function catnismap()
{
if [ -z "$1" ] ; then
map="auto_master"
else
map="$1"
fi
# Append the map's options at the _start_ if there are any options already
# (ie. myopt -> $2,myopt), otherwise just append them at the end.
if [ -z "$2" ]; then
/usr/bin/ypcat -k "$map" 2> /dev/null | sed -e '/^#/d' -e '/^$/d'
else
/usr/bin/ypcat -k "$map" 2> /dev/null |
sed -e '/^#/d' -e '/^$/d' \
-e "s/^[ \t]*\([^ \t]\+\)[ \t]\+\([^ \t]\+\)[ \t]\+-\([^ \t]\+\)/\1 
\2 $2,\3/" \
-e "s/^[ \t]*\([^ \t]\+\)[ \t]\+\([^ \t]\+\)[ \t]*$/\1 \2 $2/"
fi
}
function getfilemounts()
{
if [ -f /etc/auto.master ] ; then
cat /etc/auto.master | awk '{print $0}' | sed -e '/^#/d' -e '/^$/d' | (
while read auto_master_in
do
if [ "`echo $auto_master_in | grep '^\+'`" = "" ]; then
echo $auto_master_in
else
cat /etc/auto.master | grep '^\+' | sed -e '/^#/d' -e '/^$/d' | 
(
 

Bug#924506: perl: should Break libdist-inkt-perl (<< 0.024-5)

[Niko Tyni]

Package: perl
Version: 5.28.1-4

As discussed in #923358, Archive::Tar 2.28 in Perl 5.28 broke older
versions of libdist-inkt-perl. We should add a Breaks entry on the perl
side to reflect this, so there's no chance of ending up with a broken
combination in partial upgrades (mainly from Stretch to Buster).
-- 
Niko Tyni   nt...@debian.org

Bug#923616: Re : GSoC

[Jeffrey Cliff]

Please do.

Bug#924474: lxqt-qtplugin: FTBFS (dh_auto_configure fails)

[Alf Gaida]

Santiago, very nice catch - thank you so much. I completely oversee this 
consequence of changing the build tools which was needed because we use 
the tools to build qtxdg starting with 0.14.1.


Cheers Alf

Bug#924504: release.debian.org: unblock runit

[Dmitry Bogatov]

Package: release.debian.org
Severity: wishlist

Please, unblock src:runit=2.1.2-26 to fix following bugs:

 * 924038: failure to invoke emergency shell
 * 923957: cascading failure of init scripts, can be critical to
   remote-only systems.

Version in unstable is 2.1.2-25, which did not made to testing; version
in testing is 2.1.2-22. I ask for permission to upload 2.1.2-26 with
following changes:

diff --git a/debian/changelog b/debian/changelog
index 22639a4..e357e55 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+runit (2.1.2-26) unstable; urgency=medium
+
+  * Use full path when executing emergency shell. (Closes: #924038)
++ Thanks: Lorenzo Puliti 
+  * Remove `set -e' from `run_sysv_scripts' to ensure behaviour
+similar to `/etc/init.d/rc' -- failure of one script in `/etc/rcS.d'
+does not prevent other from running. (Closes: #923957)
+
+ -- Dmitry Bogatov   Fri, 08 Mar 2019 15:29:32 +
+
 runit (2.1.2-22) unstable; urgency=medium
 
   * Do not create symlinks between bin:runit and bin:runit-init
diff --git a/debian/contrib/2 b/debian/contrib/2
index 8569963..31da5e9 100755
--- a/debian/contrib/2
+++ b/debian/contrib/2
@@ -9,7 +9,7 @@ SVDIR=/etc/service
 if [ -f /run/runit.stopit ] ; then
# single mode
if grep -q -w -i 'single' /proc/cmdline ; then
-   chpst -P sulogin -p /dev/tty1
+   chpst -P /sbin/sulogin -p /dev/tty1
fi
 
 
diff --git a/debian/contrib/lib/run_sysv_scripts 
b/debian/contrib/lib/run_sysv_scripts
index 7ab2486..12b72f8 100755
--- a/debian/contrib/lib/run_sysv_scripts
+++ b/debian/contrib/lib/run_sysv_scripts
@@ -1,4 +1,5 @@
-#!/bin/sh -eu
+#!/bin/sh -u
+# Deliberately NO `set -e'. See #923957.
 initdir="${1}"
 for script in "$initdir/S"* ; do
path=$(realpath "$script")


pgpOU6yjbzXnP.pgp
Description: PGP signature

Bug#924505: bash: set shell to /bin/sh on removal

[Dmitry Bogatov]

Package: bash
Version: 5.0-2
Severity: wishlist

Dear Maintainer,

To contribute to efford of of making bash non-essential, I propose
following patch, that should resolve issue with login #620898 (in CC).

Please, consider applying.

diff -Nru bash-5.0/debian/bash.prerm bash-5.0/debian/bash.prerm
--- bash-5.0/debian/bash.prerm  2013-10-23 12:41:22.0 +
+++ bash-5.0/debian/bash.prerm  2019-03-13 17:07:54.0 +
@@ -9,6 +9,10 @@
;;

 remove|deconfigure)
+   remove-shell /bin/bash
+   for user in $(awk -F: '$7 == "/bin/bash" { print $1 }' /etc/passwd) ; do
+   usermod -s /bin/sh "${user}"
+   done
;;

 failed-upgrade)
diff -Nru bash-5.0/debian/changelog bash-5.0/debian/changelog
--- bash-5.0/debian/changelog   2019-01-24 10:01:16.0 +
+++ bash-5.0/debian/changelog   2019-03-13 17:08:11.0 +
@@ -1,3 +1,9 @@
+bash (5.0-3) UNRELEASED; urgency=medium
+
+  * Set shell of all users, whose shell was /bin/bash to /bin/sh.
+
+ -- Dmitry Bogatov   Wed, 13 Mar 2019 17:08:11 +
+
 bash (5.0-2) unstable; urgency=medium

   * Apply upstream patches 001 and 002. Closes: #919439.


pgpDpZ9w7gLA6.pgp
Description: PGP signature

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

[Dmitry Bogatov]

control: tags -1 +patch +pending

[2019-03-11 20:51] Andras Korn 
> 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.

Well, this sounds convincingly. Added three more lines, using SIGUSR2
instead of SIGPWR if latter is not available, as sysvinit do.

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

Not sure it will help, his activity seems dormant for quite a long time,
but good luck.


-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

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

[Dmitry Bogatov]

[2019-03-11 21:51] Axel Beckert 
> > 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):

Okay. Should I NMU or not? Anybody know what is the current status of
maintenance?

> --- /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/')
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#924116: lintian: false positive of package-uses-dh-runit-...

[Dmitry Bogatov]

[2019-03-12 06:23] "Chris Lamb" 
> > If you prefer, yes, dh_runit creates directories under /etc/sv/.
>
> Can you be more specific? That would appear to catch runit itself, at
> the very least. How about if a package ships a file matching the
> following scheme?
>
>/etc/sv/foo/run

Well, package can ship /etc/sv/foo/run without dh_runit. See, the real
purpose of ${runit:Breaks} is that if dh_runit is used with `logscript'
option, it will generate

/etc/sv/foo/log/run

which contains script, assuming features of recent versions of
bin:runit, hence the Breaks. Checking for this file would be
more accurate.

It should be noted, that packages can (and sometimes do, sign) ship
their own `/etc/sv//log/run', not generated by `dh_runit', and
which do not need Breaks.

Hope this helps.
-- 
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-11 19:27] 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.

Sorry, I am totally confused. Mind to make a patch?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#924503: release.debian.org: unblock src:gdbm

[Dmitry Bogatov]

Package: release.debian.org
Severity: wishlist

Hello! gdbm=1.18.1-3 in testing, and I ask for unblock gdbm=1.18.1-4,
which resolves issue #923609. This issue is about opening databases,
created with gdbm, shipped in stretch, being impossible.

diff --git a/debian/changelog b/debian/changelog
index 7cf8de9..00f4d79 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gdbm (1.18.1-4) unstable; urgency=medium
+
+  * Install gdbm tools without large file support to facilate transition
+of databases, created on Stretch and before. (Closes: #923609)
+  * Re-export upstream signing key without extra signatures.
+
+ -- Dmitry Bogatov   Tue, 12 Mar 2019 20:23:34 +
+
 gdbm (1.18.1-3) unstable; urgency=medium
 
   * Make values of __DATE__ and __TIME__ macros independent of locale.
diff --git a/debian/rules b/debian/rules
index fce1572..3d6667e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 export LC_ALL = C
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all future=+all reproducible=+all
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=+all
 include /usr/share/dpkg/default.mk
 
 # Upstream source code in src/version.c uses __DATE__ and __TIME__
@@ -35,21 +35,26 @@ ifeq ($(HAVE_DIETLIBC),yes)
--libdir $(DIET_LIBDIR) \
--disable-shared \
--enable-static \
+   --enable-largefile \
--enable-memory-mapped-io=no \
CC='diet gcc' CPPFLAGS='-UHAVE_MMAP'
 endif
-   dh_auto_configure -B glibc-build -- --enable-libgdbm-compat
+   dh_auto_configure -B glibc-build -- --enable-libgdbm-compat 
--enable-largefile
+   dh_auto_configure -B glibc-nolfs-build -- \
+   CFLAGS='-static -O2 -g' --program-suffix=-nolfs --disable-largefile
 
 override_dh_auto_build:
 ifeq ($(HAVE_DIETLIBC),yes)
dh_auto_build -B diet-build
 endif
dh_auto_build -B glibc-build
+   dh_auto_build -B glibc-nolfs-build
 
 override_dh_auto_install:
 ifeq ($(HAVE_DIETLIBC),yes)
dh_auto_install -B diet-build
 endif
+   dh_auto_install -B glibc-nolfs-build
dh_auto_install -B glibc-build
 
 ifeq ($(HAVE_DIETLIBC),yes)
diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc
index c2f38ad..a84c94e 100644
--- a/debian/upstream/signing-key.asc
+++ b/debian/upstream/signing-key.asc
@@ -1,5 +1,4 @@
 -BEGIN PGP PUBLIC KEY BLOCK-
-Version: GnuPG v1
 
 mQGiBDxhQHkRBACyhJxCLQvLs70IUZSlYVKAm+u1Oa4RyUo5/ctCcMm2KOcjui3z
 xs+yUwlglo1n/de9NNJY98PJNLHniMVi5sPba8OKwYx9bilwuAWLgTsgfpX8UuuY
@@ -12,274 +11,19 @@ 
ldAjPN3RDJtRB8/JooHDNq+VCEzjs02JaBpQ+BCOzzqELnkoBPl26yHR56r4WbC5
 +FH/QxEaicjVGxIF/Z9crzG/XUMXwieTNcM6HoGCnMboGqCM4bQgU2VyZ2V5IFBv
 em55YWtvZmYgPGdyYXlAZ251Lm9yZz6IXgQTEQIAHgUCQ/CVtQIbAwYLCQgHAwID
 FQIDAxYCAQIeAQIXgAAKCRA2ArB/VdDHMkVKAJ41glKzudqU5UgxMkHdSLo28ov+
-cACeLUrGgtmv/6MbmICeG64v6KOrngaJARwEEAEIAAYFAlWFAokACgkQ950xAatJ
-0nKTXQf/WXpwxTOopGngluy87lil4ToQZO4LnKUo/zRtlw/vBf0THfN2ie1SQ8Op
-NVSJ3zsJb4OgklM6b6a80cccSYwkECl7BB7tiAVXgZ9v68Grvi2LT2vxIN76q2lD
-POQPHN0jfkl3LaP0+rxeqLORBjmtdeCok6NBucXcgbAorflWOW/FNHl+XOT7Lyqh
-OPC78wmhJ3pw8vdOziEMq+NGDGswQ+h+O1zYalauuU9IvAFoHPYnyjl2jKvCjMB2
-vtLBFnpA2hU/bgn5LEypAn5Pb+0PTAMTGtTaGk3be+eHwh0JF2Pamm6V617uIWRX
-5VQB0h7ySChQoBhMOXazaIJjuZQXx7QjU2VyZ2V5IFBvem55YWtvZmYgPGdyYXlA
-Z251Lm9yZy51YT6IXgQTEQIAHgUCQ/CVdwIbAwYLCQgHAwIDFQIDAxYCAQIeAQIX
-gAAKCRA2ArB/VdDHMubqAJ9tq+C7VtEMexpRAq9jzcKo5fZFywCeKtqljjB7nsCI
-KvZNOV1D4fn7HDmJARwEEAEIAAYFAlWFAokACgkQ950xAatJ0nJl8QgAkhp3UW4G
-BJm8FyCGQOf3NmCDpaHb1ae7qbR1wgptY9mNqx2H9iCyb5vpc8IToGTg5GsfNSiI
-odkJGgZOc3XCJVMAiTq1s4panIVEFH3Sc83AnQ7Xi1Mk+w0qmdg+kTHWfB1IQwLi
-EMvDcEBZVKpfX6tEYw41yJeJoT3P7tNOLBD30QouWkCQiIxuXUhrsvTcSjW44XFr
-9ZjUOBDdPNde6PTNGK7/UZFV1pt7c7LcbuDNUuhmGS1vRJSbaqCPjqLH1Xz0TvrI
-j082CtU3NYXMc1YQUdpGFYoIfDgy8sgzvdf/xa+18vdqWu4w9hJKQLNB12LVbs5q
-cEOT9PO23ARHWLQyU2VyZ2V5IFBvem55YWtvZmYgKEdyYXkpIDxncmF5QG1pcmRk
-aW4uZmFybGVwLm5ldD6IRgQQEQIABgUCQpSzHAAKCRCL2C5vMLlLXKBOAJ0Q37wj
-coXpMuZsr7yLjzp0aDi2NwCgnwSMzWYFGm0e5T08K5CrnfgykNiIRgQSEQIABgUC
-P1tgaAAKCRCjCdZ5GaIlR3GsAJ9IHf/Rl/2+eR03mdAe+AeSTaBfagCfUsLc7/wp
-+fb7Xo6lKQezvJzGBquIVwQTEQIAFwUCPGFAeQULBwoDBAMVAwIDFgIBAheAAAoJ
-EDYCsH9V0McyDeIAoJW0tV7A3MIN+O6LXBNabPvchxRpAJwOMrjvvUDob/Pqpfls
-O4rXIv9h5IhfBBMRAgAXBQI8YUB5BQsHCgMEAxUDAgMWAgECF4AAEgkQNgKwf1XQ
-xzIHZUdQRwABAQ3iAKCVtLVewNzCDfjui1wTWmz73IcUaQCcDjK4771A6G/z6qX5
-bDuK1yL/YeSJARwEEAEIAAYFAlWFAokACgkQ950xAatJ0nIkSwgA4IdFk/8aavE9
-jArdkTwLwDBTfFC3Ij8hxr5ODvxvOxnrTQi99Lh4SfwTi4mDFKIDj4HrTQhNinkB
-myECWYb4nC79gGHpz05TpKm7F4iAJmolFU/gJslIrN9LUDth0rXiZQsGSOY/TcGf
-xpmzrXSMOpm7Jw+9ipxnW+FJrKFcENTbm7EgwOgibmDInhI2/n/ef9gwnv4bjt7r
-4vNOZvYXrMuPreBvaVSawsJfbH8q9/OH133heaCWj89WLnSCssK+qrEtQw2TReLP
-tc/oB77DGtzF81HkGUL7ghJQO6P5hAoOvLebFJHQNfHyWgwGKMZaxKy90QdR5gLC
-8Je/XPGDb4kBIgQQAQIADAUCQj6y7AUDABJ1AAAKCRCXELibyletfFW7CACzqk4T
-Kwf2Tes9n/b3WkuFN0on4fvhOh1pT4eM9t203f//S48RrAVB0M8o705zQOYC5Ooc
-OuA89BjE6jXeF3wW1zcSgLxYy5BL1LoCyeHv/vpX8+Bfi1g61iEM0dN99orknymn
-IcsA8zsLTK3EJ3TQ6jC

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

[Thorsten Glaser]

On Wed, 13 Mar 2019, Dmitry Bogatov wrote:

> Sorry, I am totally confused. Mind to make a patch?

Eh, just don’t drop support, and at best document that
people should use the new tune2fs option for ext[234].

No sense in making a patch, we’ve frozen.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Bug#924501: lintian: spurious maintainer-script-supports-ancient-package-version

[Andreas Beckmann]

Package: lintian
Version: 2.10.0
Severity: normal

Hi,

I'm getting 
  X: lam4-dev: maintainer-script-supports-ancient-package-version preinst:4 
7.1.4-3 (2012-04-09 < 2015-04-26)
in a not-yet-uploaded NMU 7.1.4-3.2 for src:lam.

== 8< debian/lam4-dev.preinst =
#!/bin/sh
set -e

if dpkg --compare-versions "$2" lt-nl "7.1.4-3.2~"
then
update-alternatives --remove mpi /usr/include/lam
fi

# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.

#DEBHELPER#
== >8 ==


Andreas

Bug#922038: zulucrypt-cli does not work

[Ahzo]

This bug has also been reported upstream:
https://github.com/mhogomchungu/zuluCrypt/issues/110 


It is fixed by this commit:
https://github.com/mhogomchungu/zuluCrypt/commit/25ab6fc33cba8600e8ceb6e3cd46c7b3ca68ff85.patch
 


A workaround is preloading libgcrypt:
# LD_PRELOAD=/lib/x86_64-linux-gnu/libgcrypt.so.20 zuluCrypt-cli

Bug#924500: sbuild: Right syntax for "individual_stalled_pkg_timeout"?

[Santiago Vila]

Package: sbuild
Version: 0.78.1-1
Severity: minor

Dear Johannes:

File /usr/share/doc/sbuild/examples/example.sbuildrc has an example
like this:

#%individual_stalled_pkg_timeout = (smalleiffel => 300,
#  jade => 300,
#  atlas => 300,
#  glibc => 1000,
#  'gcc-3.3' => 300,
#  kwave => 600);

For stretch, I wanted an individual timeout for llvm-toolchain-3.8, so
I put this in my .sbuildrc:

%individual_stalled_pkg_timeout = ('llvm-toolchain-3.8' => 300);

but this creates "this is deprecated" warnings from sbuild.

Could I know what's the right (non-deprecated) syntax? Maybe this?:

$individual_stalled_pkg_timeout{'llvm-toolchain-3.8'} = 300;

(and similar lines for every other package, I suppose)

Would be possible to update example.sbuildrc for us people who don't
speak a lot of perl?

Thanks a lot.

Bug#924450: [pkg-apparmor] Bug#924450: Bug#924450: apparmor: Write Buster release notes snippet about AppArmor

[intrigeri]

Christian Boltz:
> AFAIK [1] support for enforcing network rules is not available in Debian 
> yet, therefore it's probably a good idea to remove the "network" part 
> from the text.

Indeed. FWIW apparmor.d(5) was patched in Debian to read:

   Some features are not supported on Debian yet:

   Network Rules
   DBus rules
   Unix socket rules

Cheers,
-- 
intrigeri

Bug#924499: libgeocode-glib0: Segfault in _geocode_create_place_from_attributes

[Ben Hutchings]

Package: libgeocode-glib0
Version: 3.20.1-2
Severity: important

A location search for "middle" in GNOME Maps consistently causes it to
crash (SIGSEGV signal), with the following call stack:

(gdb) bt
#0  0x767b7cf5 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fffe96752b8 in _geocode_create_place_from_attributes ()
   from /usr/lib/x86_64-linux-gnu/libgeocode-glib.so.0
#2  0x7fffe9675794 in _geocode_parse_search_json ()
   from /usr/lib/x86_64-linux-gnu/libgeocode-glib.so.0
#3  0x7fffe9675ae6 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgeocode-glib.so.0
#4  0x7fffe91d45be in ?? () from /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1
#5  0x7fffe91d4f42 in ?? () from /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1
#6  0x7fffe91d4ff6 in ?? () from /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1
#7  0x778bc6aa in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x778bca60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x778bcb0c in g_main_context_iteration ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x740ce72d in g_application_run ()
   from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#11 0x7657e038 in ffi_call_unix64 ()
   from /usr/lib/x86_64-linux-gnu/libffi.so.6
#12 0x7657da9a in ffi_call ()
   from /usr/lib/x86_64-linux-gnu/libffi.so.6
#13 0x7760b301 in ?? () from /usr/lib/libgjs.so.0
#14 0x7760ca7f in ?? () from /usr/lib/libgjs.so.0
#15 0x7396d8fc in ?? () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0
#16 0x7396e918 in ?? () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0
#17 0x73976e78 in ?? () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0
#18 0x73977ffa in ?? () from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0
#19 0x73a239ed in JS::Evaluate(JSContext*, JS::Handle, 
JS::CompileOptions, unsigned short const*, unsigned long, JS::Value*) ()
   from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0
#20 0x73a23afe in JS::Evaluate(JSContext*, JS::Handle, 
JS::CompileOptions, char const*, unsigned long, JS::Value*) ()
   from /usr/lib/x86_64-linux-gnu/libmozjs-24.so.0
#21 0x775fe6f6 in gjs_eval_with_scope () from /usr/lib/libgjs.so.0
#22 0x775f7263 in gjs_context_eval () from /usr/lib/libgjs.so.0
#23 0x53e8 in main ()

-- System Information:
Debian Release: 9.8
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages libgeocode-glib0 depends on:
ii  libc6   2.24-11+deb9u4
ii  libglib2.0-02.50.3-2
ii  libjson-glib-1.0-0  1.2.6-1
ii  libsoup2.4-12.56.0-2+deb9u2

libgeocode-glib0 recommends no packages.

libgeocode-glib0 suggests no packages.

-- no debconf information

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#912549: icedtea-web FTBFS with OpenJDK 11

[Matthias Klose]

On 13.03.19 10:54, Andreas Tille wrote:
> On Tue, Mar 12, 2019 at 11:41:22AM +0100, Andreas Tille wrote:
>> Michael Crusoe has suggested a workaround[1].  What do you think about
>> this?
> 
> In case there is no answer to this question I assume it is OK to
> upload the workaround.  Hope you agree with this.

please look at the new upstream 1.7.2 and 1.8 releases.

Bug#924498: mariadb-server-10.3: Indexes problem with replicatetd Data

[nte]

Subject: mariadb-server-10.3: Indexes problem with replicatetd Data
Package: mariadb-server-10.3
Version: 1:10.3.13-1
Severity: important

Dear Maintainer,

I tested importing dump on MariaDB + Galera (2 nodes Master-Master) as 
follow :


 * Create a db
 * import dump sql (table in INNODB) on Node 1

When I check some index cardinalities, I have on node 1 the right value 
and on node 2 null value (0) e.g :


Node 1 : index on column username (varchar 255 utf-8) : cardinality =38250
Node 2 : index username : cardinality = 0

Indexes are not updated on node 2 and SQL queries on MariaDB Node 2 are 
too slow !


I tested different versions :

MariaDB 10.1.37 (Debian Stretch version) : cardinality is OK : no 
problem (but not same cardinality ...) !
MariaDB 10.2.22 (Debian MariaDB repository) : cardinality is NOT ok : 
problem
MariaDB 10.3.12 (Debian MariaDB repository) : cardinality is NOT ok : 
problem


I run OPTIMIZE Table on Node 2 for build indexes and then indexes are 
managed on Node 2. Strange things too : the cardinalities are always 
differentes on the 2 nodes ...


Hope, you will be able to take a look ...




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

Kernel: Linux 4.15.18-11-pve (SMP w/24 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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/bash
Init: systemd (via /run/systemd/system)

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-1
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-8
ii  libdbi-perl   1.642-1+b1
ii  libgnutls30   3.6.6-2
ii  libpam0g  1.3.1-5
ii  libstdc++6    8.3.0-2
ii  lsb-base  10.2018112800
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.13-1
ii  mariadb-common    1:10.3.13-1
ii  mariadb-server-core-10.3  1:10.3.13-1
ii  passwd    1:4.5-1.1
ii  perl  5.28.1-4
ii  psmisc    23.2-1
ii  rsync 3.1.3-5
ii  socat 1.7.3.2-2
ii  zlib1g    1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- Configuration Files:
/etc/mysql/debian-start changed:
source /usr/share/mysql/debian-start.inc.sh
if [ -f /etc/default/mysql ]; then
  . /etc/default/mysql
fi
MYSQL="/usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf"
MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
MYUPGRADE="/usr/bin/mysql_upgrade 
--defaults-extra-file=/etc/mysql/debian.cnf --version-check"

MYCHECK="/usr/bin/mysqlcheck --defaults-file=/etc/mysql/debian.cnf"
MYCHECK_SUBJECT="WARNING: mysqlcheck has found corrupt tables"
MYCHECK_PARAMS="--all-databases --fast --silent"
MYCHECK_RCPT="${MYCHECK_RCPT:-root}"
trap "" SIGHUP
(
  upgrade_system_tables_if_necessary;
  check_root_accounts;
  check_for_crashed_tables;
) >&2 &
exit 0

/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf [Errno 2] Datei oder 
Verzeichnis nicht gefunden: '/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf'
/etc/mysql/mariadb.conf.d/50-server.cnf [Errno 2] Datei oder Verzeichnis 
nicht gefunden: '/etc/mysql/mariadb.conf.d/50-server.cnf'


-- debconf information:
  mariadb-server-10.3/postrm_remove_databases: false
  mariadb-server-10.3/nis_warning:
  mariadb-server-10.3/old_data_directory_saved:

Bug#922064: [Pkg-salt-team] Bug#922064: Please restore previous version

[Dirk Heinrichs]

Am 13.03.19 um 13:38 schrieb Benjamin Drung:

> and let me know the output?

Sure. Here you are:

Mär 13 17:36:25 salt systemd[1]: Starting The Salt Master Server...
Mär 13 17:36:28 salt salt-master[20006]: line: b'MemTotal:  
16350160 kB\n', fields: [b'MemTotal:', b'16350160', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'MemFree:
5128360 kB\n', fields: [b'MemFree:', b'5128360', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'MemAvailable:  
10598480 kB\n', fields: [b'MemAvailable:', b'10598480', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Buffers:
536 kB\n', fields: [b'Buffers:', b'536', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Cached: 
4564736 kB\n', fields: [b'Cached:', b'4564736', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'SwapCached:   
0 kB\n', fields: [b'SwapCached:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Active: 
5839476 kB\n', fields: [b'Active:', b'5839476', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Inactive:   
1123732 kB\n', fields: [b'Inactive:', b'1123732', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Active(anon):   
2502168 kB\n', fields: [b'Active(anon):', b'2502168', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Inactive(anon):   
96604 kB\n', fields: [b'Inactive(anon):', b'96604', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Active(file):   
3337308 kB\n', fields: [b'Active(file):', b'3337308', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Inactive(file): 
1027128 kB\n', fields: [b'Inactive(file):', b'1027128', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Unevictable:  
0 kB\n', fields: [b'Unevictable:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Mlocked:  
0 kB\n', fields: [b'Mlocked:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'SwapTotal:
0 kB\n', fields: [b'SwapTotal:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'SwapFree: 
0 kB\n', fields: [b'SwapFree:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Dirty: 
1112 kB\n', fields: [b'Dirty:', b'1112', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Writeback:
0 kB\n', fields: [b'Writeback:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'AnonPages:  
2398048 kB\n', fields: [b'AnonPages:', b'2398048', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Mapped:  
418948 kB\n', fields: [b'Mapped:', b'418948', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Shmem:   
200696 kB\n', fields: [b'Shmem:', b'200696', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Slab:   
2967888 kB\n', fields: [b'Slab:', b'2967888', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'SReclaimable:   
1402916 kB\n', fields: [b'SReclaimable:', b'1402916', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'SUnreclaim: 
1564972 kB\n', fields: [b'SUnreclaim:', b'1564972', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'KernelStack:   
9216 kB\n', fields: [b'KernelStack:', b'9216', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'PageTables:   
22396 kB\n', fields: [b'PageTables:', b'22396', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'NFS_Unstable: 
0 kB\n', fields: [b'NFS_Unstable:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Bounce:   
0 kB\n', fields: [b'Bounce:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'WritebackTmp: 
0 kB\n', fields: [b'WritebackTmp:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'CommitLimit:
8175080 kB\n', fields: [b'CommitLimit:', b'8175080', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Committed_AS:   
5179640 kB\n', fields: [b'Committed_AS:', b'5179640', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'VmallocTotal:  
34359738367 kB\n', fields: [b'VmallocTotal:', b'34359738367', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'VmallocUsed:  
0 kB\n', fields: [b'VmallocUsed:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'VmallocChunk: 
0 kB\n', fields: [b'VmallocChunk:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'Percpu:
3376 kB\n', fields: [b'Percpu:', b'3376', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'HardwareCorrupted:
0 kB\n', fields: [b'HardwareCorrupted:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'AnonHugePages:  
1370112 kB\n', fields: [b'AnonHugePages:', b'1370112', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'ShmemHugePages:   
0 kB\n', fields: [b'ShmemHugePages:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'ShmemPmdMapped:   
0 kB\n', fields: [b'ShmemPmdMapped:', b'0', b'kB']
Mär 13 17:36:28 salt salt-master[20006]: line: b'HugePages

Bug#922947: retroarch-assets: please don’t use hinted Roboto fonts

[Moshe Piekarski]

Package: retroarch-assets
Version: 1.3.6+git20160731+dfsg1-1
Followup-For: Bug #922947

Being as roboto-hinted reverted until after the buster release, perhaps the 
priority should be set to normal so that retroarch can be included in 
buster.

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

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

Versions of packages retroarch-assets depends on:
ii  fonts-roboto 2:0~20170802-3
ii  fonts-roboto-hinted  2:0~20170802-3

retroarch-assets recommends no packages.

retroarch-assets suggests no packages.

-- no debconf information

Bug#924497: unblock: bundler/1.17.3-3

[Antonio Terceiro]

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

Please unblock package bundler

This update fixes a bug that affects other packages that use bundler.
Changelog:

bundler (1.17.3-3) unstable; urgency=medium

  * Add test for locating bundler binaries
  * Switch to Rubygems installation layout (Closes: #914771)
* 0003-Do-not-add-system-path-to-RUBYLIB.patch: dropped, not necessary
  anymore
  * 0001-replace-call-to-git-ls-files-with-Dir.glob.patch: fix file listing
  * debian/install: removed, not necessary anymore

 -- Antonio Terceiro   Sat, 09 Mar 2019 08:41:37 -0300

A diff against the version in testing is attached.

unblock bundler/1.17.3-3

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 63563bc..1cc4472 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+bundler (1.17.3-3) unstable; urgency=medium
+
+  * Add test for locating bundler binaries
+  * Switch to Rubygems installation layout (Closes: #914771)
+* 0003-Do-not-add-system-path-to-RUBYLIB.patch: dropped, not necessary
+  anymore
+  * 0001-replace-call-to-git-ls-files-with-Dir.glob.patch: fix file listing
+  * debian/install: removed, not necessary anymore
+
+ -- Antonio Terceiro   Sat, 09 Mar 2019 08:41:37 -0300
+
 bundler (1.17.3-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/install b/debian/install
deleted file mode 100644
index be41aee..000
--- a/debian/install
+++ /dev/null
@@ -1 +0,0 @@
-lib/bundler/templates/newgem/travis.yml.tt /usr/lib/ruby/vendor_ruby/bundler/templates/newgem
diff --git a/debian/patches/0001-replace-call-to-git-ls-files-with-Dir.glob.patch b/debian/patches/0001-replace-call-to-git-ls-files-with-Dir.glob.patch
index 6d52c06..c470fd5 100644
--- a/debian/patches/0001-replace-call-to-git-ls-files-with-Dir.glob.patch
+++ b/debian/patches/0001-replace-call-to-git-ls-files-with-Dir.glob.patch
@@ -24,7 +24,7 @@ index 26fc322..b68627f 100644
 -  # we don't check in man pages, but we need to ship them because
 -  # we use them to generate the long-form help for each command.
 -  s.files += Dir.glob("man/**/*")
-+  s.files = Dir.glob("lib/**") + Dir.glob("exe/*") + Dir.glob("*.md") + Dir.glob("man/*")
++  s.files = Dir.glob('**/*') - Dir.glob('debian/**/*')
# Include the CHANGELOG.md, LICENSE.md, README.md manually
s.files += %w[CHANGELOG.md LICENSE.md README.md]
# include the gemspec itself because warbler breaks w/o it
diff --git a/debian/patches/0003-Do-not-add-system-path-to-RUBYLIB.patch b/debian/patches/0003-Do-not-add-system-path-to-RUBYLIB.patch
deleted file mode 100644
index 7735a6f..000
--- a/debian/patches/0003-Do-not-add-system-path-to-RUBYLIB.patch
+++ /dev/null
@@ -1,47 +0,0 @@
-From: Christian Hofstaedtler 
-Date: Wed, 13 Jul 2016 15:51:52 +
-Subject: Do not add system path to RUBYLIB
-
-Bundler adds it's own installation path in front of RUBYLIB, but when
-this is the system ruby path, this causes system-wide installed gems
-to be used before bundler-installed gems.
-
-Closes: #830958
-Forwarded: not-needed
-Origin: vendor

- lib/bundler.rb| 6 --
- lib/bundler/shared_helpers.rb | 3 ---
- 2 files changed, 9 deletions(-)
-
-diff --git a/lib/bundler.rb b/lib/bundler.rb
-index 1cb3b4f..942f862 100644
 a/lib/bundler.rb
-+++ b/lib/bundler.rb
-@@ -296,12 +296,6 @@ EOF
- env["RUBYOPT"] = env["RUBYOPT"].sub "-rbundler/setup", ""
-   end
- 
--  if env.key?("RUBYLIB")
--rubylib = env["RUBYLIB"].split(File::PATH_SEPARATOR)
--rubylib.delete(File.expand_path("..", __FILE__))
--env["RUBYLIB"] = rubylib.join(File::PATH_SEPARATOR)
--  end
--
-   env
- end
- 
-diff --git a/lib/bundler/shared_helpers.rb b/lib/bundler/shared_helpers.rb
-index 3e2fe24..06c1c78 100644
 a/lib/bundler/shared_helpers.rb
-+++ b/lib/bundler/shared_helpers.rb
-@@ -339,9 +339,6 @@ module Bundler
- end
- 
- def set_rubylib
--  rubylib = (ENV["RUBYLIB"] || "").split(File::PATH_SEPARATOR)
--  rubylib.unshift bundler_ruby_lib
--  Bundler::SharedHelpers.set_env "RUBYLIB", rubylib.uniq.join(File::PATH_SEPARATOR)
- end
- 
- def bundler_ruby_lib
diff --git a/debian/patches/series b/debian/patches/series
index 6a2a92f..743d5b1 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,6 +1,5 @@
 0001-replace-call-to-git-ls-files-with-Dir.glob.patch
 0002-Repla

Bug#924496: 'realloc(): invalid next size: 0x000055a779ef2170' crash when opening iPod w/ ~12000 tracks

[Fred Korz]

Package: rhythmbox
Version: 3.4.3-2
Severity: important

Dear Maintainer,

   * What led up to the situation?

Plugged in a "classic" iPod with ~12000 tracks
Selected it in Rhythmbox's interface
It began reading the tracks ("syncing" appearing on the iPod's display)
Sometime after ~7000 tracks, rhythmbox aborted.

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

After 2 attempts when started in the GUI, started it from commandline to be 
able to capture stdout & stderr.

   * What was the outcome of this action?

Fault message, backtrace, and memory map, excerpt below:

$ type rhythmbox
rhythmbox is /usr/bin/rhythmbox
$ rhythmbox

(rhythmbox:27828): Rhythmbox-WARNING **: 11:43:48.028: Unable to grab media 
player keys: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gnome.SettingsDaemon.MediaKeys was not provided by any .service files
*** Error in `rhythmbox': realloc(): invalid next size: 0x55a779ef2170 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7fe1b5391bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7fe1b5397f96]
/lib/x86_64-linux-gnu/libc.so.6(+0x7a10c)[0x7fe1b539b10c]
/lib/x86_64-linux-gnu/libc.so.6(realloc+0x159)[0x7fe1b539c6e9]
/usr/lib/x86_64-linux-gnu/libtdb.so.1(+0x6caa)[0x7fe1b2e1ecaa]
/usr/lib/x86_64-linux-gnu/libtdb.so.1(+0x6fab)[0x7fe1b2e1efab]
/usr/lib/x86_64-linux-gnu/libtdb.so.1(tdb_store+0x4e)[0x7fe1b2e1d36e]
/usr/lib/x86_64-linux-gnu/librhythmbox-core.so.10(+0xcfc3a)[0x7fe1b6b93c3a]
/usr/lib/x86_64-linux-gnu/librhythmbox-core.so.10(rhythmdb_metadata_cache_store+0x129)[0x7fe1b6b946f9]
/usr/lib/x86_64-linux-gnu/librhythmbox-core.so.10(+0xc15fb)[0x7fe1b6b855fb]
/usr/lib/x86_64-linux-gnu/librhythmbox-core.so.10(+0xec2da)[0x7fe1b6bb02da]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x155)[0x7fe1b5929395]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4c760)[0x7fe1b5929760]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c)[0x7fe1b59297ec]
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(g_application_run+0x1fd)[0x7fe1b28f4cad]
/usr/lib/x86_64-linux-gnu/librhythmbox-core.so.10(rb_application_run+0x349)[0x7fe1b6b079b9]
rhythmbox(main+0xb7)[0x55a773a06d97]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fe1b53412b1]
rhythmbox(_start+0x2a)[0x55a773a06dfa]
=== Memory map: 
55a773a06000-55a773a08000 r-xp  fe:01 16646749   
/usr/bin/rhythmbox
55a773c07000-55a773c08000 r--p 1000 fe:01 16646749   
/usr/bin/rhythmbox
55a773c08000-55a773c09000 rw-p 2000 fe:01 16646749   
/usr/bin/rhythmbox
55a775807000-55a779ff6000 rw-p  00:00 0  [heap]
7fe1796de000-7fe17a02a000 rw-s  fe:01 25821306   
/usr/local/google/home/korz/.cache/rhythmbox/metadata/generic-player.tdb
7fe17a02a000-7fe17a02b000 ---p  00:00 0
7fe17a02b000-7fe17a82b000 rw-p  00:00 0
7fe17ae1e000-7fe17c00 r--p  fe:01 20451083   
/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
7fe17c00-7fe17c022000 rw-p  00:00 0
7fe17c022000-7fe18000 ---p  00:00 0
7fe18000-7fe180022000 rw-p  00:00 0
7fe180022000-7fe18400 ---p  00:00 0
7fe18447f000-7fe18448 ---p  00:00 0
7fe18448-7fe184c8 rw-p  00:00 0


   * What outcome did you expect instead?

Previous versions of rhythmbox had been able to sync with and play content from 
this iPod.  Since last used rhythmbox with this iPod sometime in 2018 I've not 
changed the contents of the iPod.


-- System Information:
Debian Release: rodete
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages rhythmbox depends on:
ii  dbus1.12.2-1
ii  gstreamer1.0-plugins-base   1.14.0-1
ii  gstreamer1.0-plugins-good   1.14.0-4
ii  gstreamer1.0-x  1.14.0-1
ii  libc6   2.24-12
ii  libglib2.0-02.56.0-4
ii  libgstreamer-plugins-base1.0-0  1.14.0-1
ii  libgstreamer1.0-0   1.14.0-1
ii  libgtk-3-0  3.24.2-3
ii  libpeas-1.0-0   1.22.0-1
ii  librhythmbox-core10 3.4.3-2
ii  libx11-62:1.6.7-1
ii  media-player-info   23-1
ii  rhythmbox-data  3.4.3-2

Versions of packages rhythmbox recommends:
ii  avahi-daemon0.6.32-2
ii  cinnamon [notification-daemon]  3.6.7-8
ii  gstreamer1.0-plugins-ugly   1.14.0-1
ii  gstreamer1.0-pulseaudio 1.14.0-4
ii  gvfs-backends   1.30.4-1
ii  rhythmbox-plugins   3.4.3-2
ii  yelp

Bug#921704: tortoisehg: uninstallable with mercurial 4.9

[Pierre-Yves David]

Thg Upstream has pushed a 4.9 ta.

Cheers,

--
Pierre-Yves David

Bug#924465: unblock: pre-approval for openipmi/2.0.25-2 patch

[Emilio Pozuelo Monfort]

On 13/03/2019 10:23, Thomas Goirand wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Dear release team,
> 
> I've been using OpenIPMI's ipmi_sim, which simulates IPMI on a KVM virtual
> machine, though it suffered from a very small buffer line for the VM
> configuration.
> 
> In #923873, I proposed a fix to this, which is simply:
> 
> -#define MAX_CONFIG_LINE 1024
> +#define MAX_CONFIG_LINE 10240
> 
> in lanserv/OpenIPMI/serv.h, increasing the maximum command line to 10K instead
> of the original 1K.
> 
> Would the release team be ok to accept such a fix in Buster?

That looks fine to me.

Emilio

Bug#910902: Please test again: resolveip and Akonadi for a freash installation

[Sandro Knauß]

Hey Otto,

> Fix for this pending at
> https://salsa.debian.org/mariadb-team/mariadb-10.3/commits/bugfix/910902-mov
> e-resolveip-to-server-core

thanks, but this is still not enough to run a mysql_install_db successfully.

  $ /usr/bin/mysql_install_db --datadir=/tmp/test
FATAL ERROR: Could not find /usr/share/mysql/fill_help_tables.sql

and there are even more scripts to move, that are checked and not inside the 
core package:
mysql_install_db (line 369ff)
fill_help_tables="$srcpkgdatadir/fill_help_tables.sql"
create_system_tables="$srcpkgdatadir/mysql_system_tables.sql"
create_system_tables2="$srcpkgdatadir/mysql_performance_tables.sql"
fill_system_tables="$srcpkgdatadir/mysql_system_tables_data.sql"
maria_add_gis_sp="$buildpkgdatadir/maria_add_gis_sp_bootstrap.sql"
mysql_test_db="$srcpkgdatadir/mysql_test_db.sql"

So far I scanned mysql_install_db,  if those files got moved than 
mysql_install_db  should run successfully.

hefee


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