Bug#1070008: xfce4-panel: fails to reserve space (in fluxbox)

[Francesco Poli (wintermute)]

Package: xfce4-panel
Version: 4.18.4-1
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello there!
Thanks for maintaining this package in Debian.

I am trying xfce4-panel as a panel for my fluxbox based desktop:
I start it with the following command

  $ xfce4-panel --disable-wm-check --sm-client-disable &

It works well, except for one issue.
If, in the Panel Properties, I choose to "Never" automatically hide the
panel and I check "Reserve space on screen edges for the panel", I
fail to see the intended effect. I mean: maximized windows still cover
the area behind the panel.

The panel is attached to the bottom screen edge.

Please investigate and fix the bug and/or forward my bug report upstream,
as appropriate.

Thanks for your time!
Bye.



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

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

Versions of packages xfce4-panel depends on:
ii  exo-utils   4.18.0-1+b1
ii  libatk1.0-0 2.50.0-1+b1
ii  libc6   2.37-18
ii  libcairo2   1.18.0-1+b1
ii  libdbusmenu-gtk3-4  18.10.20180917~bzr492+repack1-3.1
ii  libexo-2-0  4.18.0-1+b1
ii  libgarcon-1-0   4.18.1-1+b1
ii  libgarcon-gtk3-1-0  4.18.1-1+b1
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b3
ii  libglib2.0-0t64 [libglib2.0-0]  2.78.4-7
ii  libgtk-3-0  3.24.41-1
ii  libpango-1.0-0  1.52.1+ds-1
ii  libpangocairo-1.0-0 1.52.1+ds-1
ii  libwnck-3-0 43.0-3
ii  libx11-62:1.8.7-1+b1
ii  libxext62:1.3.4-1+b1
ii  libxfce4panel-2.0-4 4.18.4-1
ii  libxfce4ui-2-0  4.18.4-1
ii  libxfce4util7   4.18.1-2+b1
ii  libxfconf-0-3   4.18.1-1+b2

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#1069746: connman: cannot configure a wifi network to forget credentials

[Francesco Poli (wintermute)]

Package: connman
Version: 1.42-5
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello and thanks for maintaining this package in Debian!

It works pretty well for most cases (except for the case described
in bug report [#1066128]). I have now found another case where
connman should work better.

[#1066128]: 

I have added a configuration file '/var/lib/connman/eduroam.config',
as documented in the connman-service.config(5) manpage, in order
to connect to eduroam (which, as you may know, is a University wifi
network, which uses security type ieee8021x and EAP type peap).

It works: I am able to connect to eduroam, by using my University
single-sign-on credentials (username and password).

However these credentials (especially the password) are stored
(in cleartext!) into a subdirectory under /var/lib/connman/
and are remembered for future use.
Subdirectories under /var/lib/connman/ are only readable by root,
but the connman daemon has access to them and makes their data
usable by other unprivileged users of the box (even a laptop
may have more than one regular user...).

This can be convenient, but has some important drawbacks:

 * storing passwords in cleartext files (only readable by root) can
   be considered acceptable for psk wifi networks, where the passphrase
   is basically a shared secret (known by a number of people), but
   becomes definitely more troublesome for eduroam wifi network, where the
   access credentials may be the single-sign-on credentials used to
   access many other services of one's own University

 * making eduroam access credentials of one user usable by other users
   of the system may be considered inappropriate, since eduroam access
   credentials are personal

For these reasons, I would like to configure connman, so that it forgets
the eduroam access credentials: connman should ask me to re-enter username
and password each time I connect to eduroam, without storing these
credentials for future use.
This should be configurable on a per-network basis, by setting some
appropriate option in '/var/lib/connman/eduroam.config'.

I failed to find any relevant option in the documentation.
Am I missing anything important?

Can this be done for one specific network (eduroam)?

If not, please forward my bug report upstream as a feature request.

Thanks for your time, bye!


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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages connman depends on:
ii  dbus 1.14.10-4
ii  init-system-helpers  1.66
ii  iptables 1.8.10-3
ii  libc62.37-15
ii  libdbus-1-3  1.14.10-4
ii  libglib2.0-0 2.78.4-1
ii  libgnutls30  3.8.3-1
ii  libreadline8 8.2-3+b1
ii  libxtables12 1.8.10-3

Versions of packages connman recommends:
ii  bluez  5.71-1
pn  ofono  
ii  wpasupplicant  2:2.10-21

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#1068775: sbuild-qemu: fails to work, if piuparts is requested, but not installed on the host

[Francesco Poli (wintermute)]

Package: sbuild-qemu
Version: 0.85.6
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hi!

I am trying to set up sbuild-qemu to build (and test) Debian packages.

After creating the virtual machine image:

  $ mkdir -p ~/.cache/sbuild/build
  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid unstable-autopkgtest-amd64.img
  $ mv -i unstable-autopkgtest-amd64.img ~/.cache/sbuild/

I prepared the following configuration file:

  $ cat ~/.sbuildrc 
  $source_only_changes = 1;
  $autopkgtest_require_success = 1;
  $lintian_require_success = 0;
  $piuparts_require_success = 1;
  $run_autopkgtest = 1;
  $run_lintian = 1;
  $run_piuparts = 1;
  $build_dir = "$HOME/.cache/sbuild/build";
  
  # don't remove this, Perl needs it:
  1;

I can update the virtual machine (if I create a symlink, see bug [#1061816]):

  $ sbuild-qemu-update --boot=efi unstable-autopkgtest-amd64.img

[#1061816]: 

But, when I try to build a package from withing the unpacked source
tree:

  $ sbuild-qemu --boot=efi --overlay-dir=/dev/shm
  sbuild --dist unstable --purge-build=never --purge-deps=never 
--chroot-mode=autopkgtest --autopkgtest-virt-server=qemu 
--autopkgtest-virt-server-opt --overlay-dir=/dev/shm 
--autopkgtest-virt-server-opt --qemu-architecture=x86_64 
--autopkgtest-virt-server-opt --ram-size=2048 --autopkgtest-virt-server-opt 
--cpus=2 --autopkgtest-virt-server-opt --boot=efi --autopkgtest-virt-server-opt 
/home/$USER/.cache/sbuild/unstable-autopkgtest-amd64.img 
--bd-uninstallable-explainer apt
Error reading configuration: PIUPARTS binary 'piuparts' does not exist or is 
not executable at /usr/share/perl5/Sbuild/Conf.pm line 76.

Now, piuparts is indeed not installed on the host:

  $ apt policy piuparts
  piuparts:
Installed: (none)
Candidate: 1.4.1
Version table:
   1.4.1 800
  800 http://deb.debian.org/debian testing/main amd64 Packages
  500 http://deb.debian.org/debian unstable/main amd64 Packages

However, I thought that setting $run_piuparts = 1 in ~/.sbuildrc caused
piuparts to be run inside the virtual machine guest system, not on the
host system!
Hence, I thought that piuparts was going to be automatically installed
and executed on the guest system (actually on the throw-away overlay).
And I thought that the same was going to happen for $run_autopkgtest = 1
and for $run_lintian = 1 ...

Am I completely off-track?
What did I fail to understand?

Why does sbuild-qemu insist that piuparts be installed on the *host*
system?

Please clarify and/or fix this issue.
Thanks for your kind assistance!


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

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

Versions of packages sbuild-qemu depends on:
ii  autopkgtest  5.34
ii  python3  3.11.6-1
ii  python3-pexpect  4.9-2
ii  python3-psutil   5.9.8-2
ii  qemu-system-x86  1:8.2.1+ds-2
ii  qemu-utils   1:8.2.1+ds-2
ii  sbuild   0.85.6
ii  vmdb20.28-2

Versions of packages sbuild-qemu recommends:
ii  qemu-system-arm [qemu-system-arm]  1:8.2.1+ds-2
ii  qemu-system-ppc [qemu-system-ppc]  1:8.2.1+ds-2

sbuild-qemu suggests no packages.

-- no debconf information

Bug#1067034: dhcpcd-gtk: fails to see wireless networks and to let me enter passphrases

[Francesco Poli (wintermute)]

Package: dhcpcd-gtk
Version: 0.7.9-5
Severity: important
X-Debbugs-Cc: invernom...@paranoici.org

Hello!
Thanks for maintaining this Debian package.

I gave it a try on a laptop, in order to manage dhcpcd, but I cannot
seem to make it work for wireless networks.

I did the following:

  # echo 'update_config=1' > /etc/wpa_supplicant/wpa_supplicant.conf
  # echo 'ctrl_interface=DIR=/run/wpa_supplicant GROUP=netdev' >> 
/etc/wpa_supplicant/wpa_supplicant.conf
  # chmod 0600 /etc/wpa_supplicant/wpa_supplicant.conf
  # systemctl restart wpa_supplicant.service
  # systemctl restart dhcpcd.service

Then, as a regular user (belonging to group netdev) within my X session,
I issued the following command:

  $ dhcpcd-gtk &

An icon appeared on my systray (in lxpanel), but it corresponds to
"no network" (see attachment).
Hovering on the icon shows a tip that says that no network is associated
(see second attachment).
Right-clicking on the icon shows a menu with "Preferences", "About", and
"Quit" entries.
I cannot find any list of available wireless networks, I cannot click
on one of them in order to connect, enter passphrase, disconnect, ...

What's wrong or missing?
What did I fail to understand?

Please clarify, thanks for your time!



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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dhcpcd-gtk depends on:
ii  dhcpcd [dhcpcd]  1:10.0.6-1
ii  libc62.37-15
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libgtk-3-0   3.24.41-1
ii  libnotify4   0.8.3-1

Versions of packages dhcpcd-gtk recommends:
ii  wpasupplicant  2:2.10-21

dhcpcd-gtk suggests no packages.

-- no debconf information

Bug#1066128: connman: fails to take multiple search domains into account

[Francesco Poli (wintermute)]

Package: connman
Version: 1.42-5
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello and thanks for maintaining this package in Debian!
I have used it for quite some time, and I can say that it works pretty
well for most cases.

However, I have recently encountered a case where connman could work
better...
The case is a network where the DHCP server sends two domains as
"search domains" (let's call them MYDOMAIN and OTHERDOMAIN). These
two search domains are sent by the DHCP server in the
domain search list (DHCP Option 119).

If I don't use connman and configure the Ethernet network with
ifupdown (through a stanza in /etc/network/interfaces ), the DHCP
client (dhcpcd-base) writes the two search domains to /etc/resolv.conf
and everything works as intended.

If instead I use connman to connect to the Ethernet (or Wireless) network,
/etc/resolv.conf is not overwritten, since connman implements an internal
name server. Hence, the dynamically generated resolv.conf is:

  $ cat /run/connman/resolv.conf
  # Generated by Connection Manager
  nameserver ::1
  nameserver 127.0.0.1

That would be OK as /etc/resolv.conf (which could be a symlink to
/run/connman/resolv.conf ), as long as connman is aware of the two
search domains. But connman does not seem to take the two search
domains into account. In the network-specific settings of the GUI,
I see MYDOMAIN as the only domain in the "Domains" tab. However,
if I try to use non-fully-qualified host names, they are not resolved
into IP addresses:

  $ ping -c 3 HOST
  ping: HOST: Name or service not known
  $ ping -c 3 HOST.MYDOMAIN
  PING HOST.MYDOMAIN (192.168.0.143) 56(84) bytes of data.
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=1 ttl=64 time=3.81 ms
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=2 ttl=64 time=4.99 ms
  64 bytes from HOST.MYDOMAIN (192.168.0.143): icmp_seq=3 ttl=64 time=4.79 ms
  
  --- HOST.MYDOMAIN ping statistics ---
  3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 3.807/4.527/4.987/0.515 ms

Moreover, this network needs

  options single-request-reopen

in /etc/resolv.conf , in order to avoid slow name server replies
(see resolv.conf(5) for more details on this option).
How can I add this option with connman?
It would be great, if connman could be configured to use this option
(globally, or, even better, on a per-network basis).
Can this be done?

Currently, I have the following /etc/resolv.conf (not a symlink):

  $ cat /etc/resolv.conf
  # Generated by dhcpcd
  options single-request-reopen
  # /etc/resolv.conf.tail can replace this line

which was left by dhcpcd-base and has the needed option.
Using this together with connman seems to work (in the sense that
it avoids the slow name server reply), but, as I said, connman does
not take the two search domains into account.


I think connman should be improved, so that it can take the two search
domains into account and it can be configured to add options to the
dynamically generated /run/connman/resolv.conf .

Another strategy could be to delegate all the DHCP client stuff to
an external DHCP client (such as dhcpcd-base, which would manage
/etc/resolv.conf directly).
Is that already possible?


Am I misunderstanding anything?

Please clarify and/or enhance the connman Debian package and/or forward
my bug report upstream, as appropriate.

Thanks for your time and dedication!




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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages connman depends on:
ii  dbus 1.14.10-4
ii  init-system-helpers  1.66
ii  iptables 1.8.10-3
ii  libc62.37-15
ii  libdbus-1-3  1.14.10-4
ii  libglib2.0-0 2.78.4-1
ii  libgnutls30  3.8.3-1
ii  libreadline8 8.2-3+b1
ii  libxtables12 1.8.10-3

Versions of packages connman recommends:
ii  bluez  5.71-1
pn  ofono  
ii  wpasupplicant  2:2.10-21

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#1062831: guitarix: segfaults, when creating a preset bank

[Francesco Poli (wintermute)]

Package: guitarix
Version: 0.44.1+dfsg1-3+b1
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org

Hello and thanks for maintaining Guitarix in Debian!

I would like to save some presets.
I click on the "Preset:" button and then on "New Bank": a new field appears,
where I should enter the name of the new bank. If, instead, I just click
on this field, guitarix segfaults.

Please investigate, reproduce the bug and fix it and/or forward my
bug report upstream, as appropriate.

Thanks for your time!


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

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

Versions of packages guitarix depends on:
ii  fonts-roboto  2:0~20170802-3
ii  guitarix-common   0.44.1+dfsg1-3
ii  guitarix-ladspa   0.44.1+dfsg1-3+b1
ii  guitarix-lv2  0.44.1+dfsg1-3+b1
ii  libatkmm-1.6-1v5  2.28.3-2+b1
ii  libavahi-common3  0.8-13+b1
ii  libavahi-gobject0 0.8-13+b1
ii  libbluetooth3 5.71-1
ii  libboost-iostreams1.83.0  1.83.0-2+b2
ii  libc6 2.37-15~deb13u1
ii  libcairomm-1.0-1v51.14.5-1
ii  libcurl3-gnutls   8.5.0-2
ii  libfftw3-single3  3.3.10-1
ii  libgcc-s1 13.2.0-10
ii  libglib2.0-0  2.78.3-2
ii  libglibmm-2.4-1v5 2.66.6-2
ii  libgtk-3-03.24.40-2
ii  libgtkmm-3.0-1v5  3.24.8-2
ii  libgxw0   0.44.1+dfsg1-3+b1
ii  libgxwmm0 0.44.1+dfsg1-3+b1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3
ii  liblilv-0-0   0.24.22-1
ii  liblrdf0  0.6.1-4
ii  libpangomm-1.4-1v52.46.3-1
ii  libsigc++-2.0-0v5 2.12.1-1
ii  libsndfile1   1.2.2-1
ii  libstdc++613.2.0-10
ii  libzita-convolver44.0.3-2
ii  libzita-resampler11.11.2-1

Versions of packages guitarix recommends:
pn  gvfs-backends  
ii  jack-capture   0.9.73-4
pn  lame   
ii  vorbis-tools   1.4.2-1+b1

guitarix suggests no packages.

-- no debconf information

Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.4.1-1
Severity: normal

Hello again Johannes!

As I said in bug report [#1061634], I've been able to create a QEMU/KVM
virtual machine image for autopkgtests:

  $ mkdir -p ~/var/cache/sbuild/
  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid sid-amd64.img
  $ chmod 660 sid-amd64.img
  $ mv -i sid-amd64.img ~/var/cache/sbuild/

[#1061634]: 

It works for autopkgtests, but I wanted to use the same virtual machine
image to build Debian packages with sbuild-qemu.
The first thing I tested is the update of the VM image with
sbuild-qemu-update:

  $ sbuild-qemu-update --arch=amd64 sid-amd64.img
  qemu-system-x86_64 -enable-kvm -object 
rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0,id=rng-device0 -device virtio-serial -nic 
user,model=virtio -m 1024 -smp 1 -nographic sid-amd64.img

This command does not seem to work: it uses 100 % of one CPU core and
seemingly does nothing, until I interrupt it by pressing [Ctrl+C].

Is there any special tweak or configuration needed to use
sbuild-qemu-update with mmdebstrap-autopkgtest-build-qemu VM images?
Where is this documented?

Otherwise, if this is an actual bug, please fix
mmdebstrap-autopkgtest-build-qemu
or help sbuild-qemu developers to fix sbuild-qemu-update.

Thanks for your time and dedication!



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

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

Versions of packages mmdebstrap depends on:
ii  apt  2.7.10
ii  perl 5.38.2-3
ii  python3  3.11.6-1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-15
ii  fakeroot 1.33-1
ii  gpg  2.2.40-1.1+b1
ii  libdistro-info-perl  1.7
ii  libdpkg-perl 1.22.2
ii  mount2.39.3-6
ii  uidmap   1:4.13+dfsg1-3+b1

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.7.10
ii  ca-certificates20230311
ii  debootstrap1.0.134
ii  distro-info-data   0.60
ii  dpkg-dev   1.22.2
pn  genext2fs  
ii  perl-doc   5.38.2-3
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  
ii  systemd255.2-4

-- no debconf information

Bug#1061634: mmdebstrap: possible mmdebstrap-autopkgtest-build-qemu improvements

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.4.1-1
Severity: normal

Hello Johannes!

I've been able to create a QEMU/KVM virtual machine image for autopkgtests:

  $ mkdir -p ~/var/cache/sbuild/
  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid sid-amd64.img
  $ chmod 660 sid-amd64.img
  $ mv -i sid-amd64.img ~/var/cache/sbuild/

It is able to run autopkgtests:

  $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out \
--summary./${SRCPKG}_autopkgtest.summary \
--apt-upgrade -B ./${SRCPKG}_amd64.changes -- \
qemu --boot=efi --overlay-dir /dev/shm \
~/var/cache/sbuild/sid-amd64.img

My comments / suggestions for improvements:

  * I had to manually fix the permissions, since the image file was
originally created with the following weird ones:

  $ ls -l --si sid-amd64.img 
  -rw-r-xrwx 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img

I think the file permissions should be set (possibly at the end of the
mmdebstrap-autopkgtest-build-qemu run) as they would "naturally"
result from the user's umask:

  $ cd /dev/shm
  $ touch foo
  $ ls -l --si foo 
  -rw-rw 1 $USER $USER 0 Jan 27 19:00 foo

That's why I manually changed the permissions at the end:

  $ chmod 660 sid-amd64.img
  $ ls -l --si sid_amd64.img
  -rw-rw 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img

I suggest that mmdebstrap-autopkgtest-build-qemu applies this fix
automatically.

  * I was surprised to see a 25 GiB image fit into a 7.7 GiB filesystem:

  $ cd /dev/shm
  $ ls -l -h sid-amd64.img
  -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
  $ df -h .
  Filesystem  Size  Used Avail Use% Mounted on
  tmpfs   7.7G  765M  7.0G  10% /dev/shm

Well, the mystery is solved by looking at the allocated size:

  $ ls -l -h -s sid-amd64.img 
  662M -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img

Would it be less confusing, if mmdebstrap-autopkgtest-build-qemu created
.qcow2 images?


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

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

Versions of packages mmdebstrap depends on:
ii  apt  2.7.10
ii  perl 5.38.2-3
ii  python3  3.11.6-1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-15
ii  fakeroot 1.33-1
ii  gpg  2.2.40-1.1+b1
ii  libdistro-info-perl  1.7
ii  libdpkg-perl 1.22.2
ii  mount2.39.3-6
ii  uidmap   1:4.13+dfsg1-3+b1

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.7.10
ii  ca-certificates20230311
ii  debootstrap1.0.134
ii  distro-info-data   0.60
ii  dpkg-dev   1.22.2
pn  genext2fs  
ii  perl-doc   5.38.2-3
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  
ii  systemd255.2-4

-- no debconf information

Bug#1061091: syntax/fortran.vim: incorrectly highlights identifiers, when they contain some keyword

[Francesco Poli (wintermute)]

Package: vim-runtime
Version: 2:9.1.0-1
Severity: normal

Hello!

I have recently noticed a regression.
Since one of the latest package upgrades (in Debian testing),
vim began to highlight some Fortran keywords, even when they appear
as part of identifiers. This is incorrect, since a keyword should
be highlighted only where it is actually a keyword, and not where
it appears as a part of an identifier.

Please see the attached 'test.f90' Fortran example program
and a screenshot of how vim highlights its syntax.

Please forward this bug report upstream and/or fix the regression,
as appropriate.

Thanks for your time.


P.S.: I believe that 'test.f90' is so trivial that it is not copyrighted.
Should it turn out to be copyrighted in some jurisdiction, I hereby release
it under the terms of the [Expat licence].

[Expat licence]: http://www.jclark.com/xml/copying.txt


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

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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim 2:9.1.0-1
ii  vim-gtk3 [vim]  2:9.1.0-1
ii  vim-tiny2:9.1.0-1

vim-runtime suggests no packages.

-- no debconf information
program test

integer :: mycalli
integer :: myifi
integer :: myendifi
integer :: mystopi
integer :: mycasei

integer :: myselecti
integer :: mywherei

integer :: myclassi

read(*,*) mycalli, myifi, myendifi, mystopi, mycasei, &
  myselecti, mywherei, myclassi

write(*,*) mycalli + myifi + myendifi + mystopi + mycasei + &
   myselecti + mywherei + myclassi

end

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.4.0-1
Severity: normal

Hello,
I am giving mmdebstrap-autopkgtest-build-qemu a try.

The following command fails:

  $ mmdebstrap-autopkgtest-build-qemu --boot=efi sid sid_amd64.img

during some package installation with "no space left on device" error,
since I have /tmp on a somewhat small physical partition:

  $ df --si /tmp/
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/md3868M   99k  806M   1% /tmp

I tried with a TMPDIR in system memory:

  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--boot=efi sid sid_amd64.img

but it again fails with the following (final chunk of) output:

  [...]
  cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
  I: running special hook: download vmlinuz '/dev/shm/tmp.uNRUbVgiOu/kernel'
  I: running special hook: download initrd.img '/dev/shm/tmp.uNRUbVgiOu/initrd'
  I: running --customize-hook in shell: sh -c 'mount --bind "$1" "$1/mnt"' exec 
/dev/shm/mmdebstrap.IXehDNUWIf
  I: running --customize-hook in shell: sh -c 'mount --bind "$1/mnt/mnt" 
"$1/mnt/dev"' exec /dev/shm/mmdebstrap.IXehDNUWIf
  I: running --customize-hook in shell: sh -c '/sbin/mkfs.ext4 -d "$1/mnt" -L 
autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' 
'25G'' exec /dev/shm/mmdebstrap.IXehDNUWIf
  mke2fs 1.47.0 (5-Feb-2023)
  mkfs.ext4: Permission denied while trying to determine filesystem size
  E: setup failed: E: command failed: /sbin/mkfs.ext4 -d "$1/mnt" -L 
autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' 
'25G'
  W: hooklistener errored out: E: received eof on socket
  
  I: main() received signal PIPE: waiting for setup...
  I: removing tempdir /dev/shm/mmdebstrap.IXehDNUWIf...
  E: mmdebstrap failed to run
  mmdebstrap failed

Does it fail because I do not have enough system memory?

  $ df --si /dev/shm/
  Filesystem  Size  Used Avail Use% Mounted on
  tmpfs   8.3G  108M  8.2G   2% /dev/shm

Is this the explanation?
Otherwise, what went wrong?

By the way, the old script that used guestfish (with all its limitations)
was able to create a QEMU image in .qcow2 format and my /dev/shm was
enough for it to work correctly.
Why does the current mmdebstrap-autopkgtest-build-qemu create a QEMU
image in .img format? Isn't the .qcow2 format better?

Please clarify and/or improve mmdebstrap-autopkgtest-build-qemu .
Thanks for your time!


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

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

Versions of packages mmdebstrap depends on:
ii  apt  2.7.6
ii  perl 5.36.0-10+b1
ii  python3  3.11.4-5+b1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-15
ii  fakeroot 1.32.2-1+b1
ii  gpg  2.2.40-1.1+b1
ii  libdistro-info-perl  1.7
ii  libdpkg-perl 1.22.2
ii  mount2.39.3-2
ii  uidmap   1:4.13+dfsg1-3+b1

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.7.6
ii  ca-certificates20230311
ii  debootstrap1.0.134
ii  distro-info-data   0.60
ii  dpkg-dev   1.22.2
pn  genext2fs  
ii  perl-doc   5.36.0-10
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  
ii  systemd255.2-3

-- no debconf information

Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf

[Francesco Poli (wintermute)]

Package: dhcpcd-base
Version: 1:10.0.5-2
Severity: normal

Hello and thanks for maintaining this package in Debian!

I am giving it a try (inside a virtual machine), as a drop-in
replacement for isc-dhcp-client (with the ifupdown package).

It seems to work pretty well, just like isc-dhcp-client, but
I noticed an issue in a network where the DHCP server sends
two domains as "search domains" (let's call them MYDOMAIN
and OTHERDOMAIN).

When I use dhcpcd-base as a DHCP client, I get the following
resolv.conf file:

  $ cat /etc/resolv.conf
  # Generated by dhcpcd from enp0s3.dhcp
  # /etc/resolv.conf.head can replace this line
  domain MYDOMAIN
  nameserver 192.168.0.1
  # /etc/resolv.conf.tail can replace this line

This lacks the two search domains I was expecting.
To be honest, the isc-dhcp-client Debian package
behaves similarly (somehow failing to write OTHERDOMAIN as
second search domain).

But Rocky Linux clients (on the same network, with the ISC
DHCP client and ifup/ifdown mechanism) correctly set the
resolv.conf with the two search domains:

  $ cat /etc/resolv.conf
  ; generated by /usr/sbin/dhclient-script
  search MYDOMAIN. OTHERDOMAIN.
  nameserver 192.168.0.1

Even Windows clients (on the same network) correctly obtain
the two search domains...

Why cannot I have the two search domains on Debian?

What's wrong?
What did I fail to understand?
Shouldn't this work out of the box?

Please let me know, thanks for your time.


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

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

Versions of packages dhcpcd-base depends on:
ii  adduser   3.137
ii  libc6 2.37-12
ii  libssl3   3.0.11-1
ii  libudev1  254.5-1

dhcpcd-base recommends no packages.

Versions of packages dhcpcd-base suggests:
pn  resolvconf | openresolv | systemd-resolved  

-- no debconf information

Bug#1054229: libcgns-dev: please also ship src/cgns_f.F90 to support Fortran compilers beyond gfortran

[Francesco Poli (wintermute)]

Package: libcgns-dev
Version: 3.4.0-3
Severity: wishlist

Hello and thanks for maintaining this useful library in Debian!

The CGNS library may be used from C/C++ programs/libraries and also
from Fortran programs/libraries.

In order to use the library from Fortran code, the

  use cgns

statement is required, which requires access to the 'cgns.mod' module
file, correctly shipped in package libcgns-dev as /usr/include/cgns.mod .

This works like a charm, as long you compile your own Fortran
program/library with the same Fortran compiler which was used to
generate the 'cgns.mod' module file.
But it may fail, when the two compilers are different, since,
unfortunately!, Fortran module files are [not portable] across
different compilers. 

[not portable]: 

Obviously, the 'cgns.mod' module file shipped in package libcgns-dev as
/usr/include/cgns.mod was compiled with gfortran.
As a consequence, if you also compile your own Fortran program/library
with gfortran, there's no issue at all in using libcgns-dev.

But, if you want to support compilation of your own Fortran program/library
with more than one compiler (for instance gfortran and the Intel 'ifort'
Fortran compiler), you cannot use the official Debian package libcgns-dev.

Well, I seem to have found a strategy to work around this issue.

I downloaded the 'src/cgns_f.F90' source file (from the libcgns Debian
source package, same exact version as the installed Debian binary package)
and compiled it with the incompatible Fortran compiler (e.g.: the Intel
'ifort' Fortran compiler), thus obtaining a 'cgns.mod' module file
compatible with the used Fortran compiler. Among the options passed to
the compiler, there were the following:

  -I/usr/include -c

Then I compiled my own Fortran program source files with the previously
obtained 'cgns.mod' module file in the same directory.
Again with:

  -I/usr/include -c

among the compiler options.
Finally, I linked my own Fortran program .o object files together, with the
following:

  -lcgns

among the passed options.

The strategy works and produces an executable, which is dynamically linked
(among other libraries) to the CGNS library:

  $ ldd my_own_fortran_program | grep cgns
libcgns.so.3.4 => /lib/x86_64-linux-gnu/libcgns.so.3.4 
(0x7f3a4e9f3000)

The executable works correctly.



In conclusion, I would like to suggest to also ship the 'src/cgns_f.F90'
source file in package libcgns-dev, so that the CGNS library in Debian
becomes usable with Fortran compilers other than gfortran.

This would be highly useful, as it would increase the cross-compiler
compatibility of the CGNS library, as shipped in Debian!
And this would just require to ship one more file (less than 200 kbyte)
simply copied from the source Debian package to the libcgns-dev binary
Debian package.

Please consider accepting this proposal.
Thanks for your time and your dedication!

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

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

Versions of packages libcgns-dev depends on:
ii  libcgns3.4  3.4.0-3

libcgns-dev recommends no packages.

libcgns-dev suggests no packages.

-- no debconf information

Bug#1052376: lxpanel: no longer obeys its geometry settings

[Francesco Poli (wintermute)]

Package: lxpanel
Version: 0.10.1-4
Severity: grave
Justification: renders package unusable

Hello!

I have just upgraded lxpanel:

  [UPGRADE] lxpanel:amd64 0.10.1-2 -> 0.10.1-4
  [UPGRADE] lxpanel-data:amd64 0.10.1-2 -> 0.10.1-4

and not it behaves insanely.

My settings are as follows:
in the "Geometry" tab, choose Edge "Bottom", Alignment "Right",
set Margin "275", choose Monitor "1", set Width "100" "% Percent",
Height "28" "Pixels", Icon size "24" Pixels.
In the "Panel Applets" tab, I have a number of plugins,
among which a Task Bar with 'Stretch' checked.

For a complete description of my settings, see my documentation
[page].

[page]: 


Until lxpanel/0.10.1-2, this resulted in a fixed width panel,
that was as large as the screen minus 275 pixels. The panel
spanned from the left edge of the screen to a point 275 pixels
from the right edge of the screen. Various plugins were shown
from left to right, with the Task Bar that was as large as possible,
but leaving enough space for the other plugins on its left and on
its right. Everything was really good.

Now, with lxpanel/0.10.1-4, the behavior seems to have gone crazy.
The only shown plugins are the ones on the left of the Task Bar,
and the Task Bar itself. The panel spans from the left edge of
the screen to a point which moves to the left or to the right,
depending on how many windows have to be represented in the Task Bar!
With enough windows, it is even possible to see the panel become
larger than the screen!
The plugins that should appear to the right of the Task Bar are
only partially shown, and only if the panel grows beyond some
mysterious point...

In other words lxpanel has become unusable.

Downgrading/reinstalling the following packages:

  libwnck-common (2.30.7-6)
  libwnck22 (2.30.7-6+b1)
  libkeybinder0 (0.3.1-2.1)
  libfm4 (1.3.2-1)
  libfm-gtk4 (1.3.2-1)
  lxpanel-data (0.10.1-2) ...
  lxpanel (0.10.1-2)

is enough to restore the normal (sane) behavior.


Please fix this bug as soon as possible (and please do not
downgrade the severity of this bug report!).

Thanks for your time and dedication!
Bye.


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

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

Versions of packages lxpanel depends on:
ii  libasound2   1.2.9-2
ii  libc62.37-8
ii  libcairo21.17.8-3
ii  libcurl3-gnutls  8.2.1-2
ii  libfm-gtk3-4 1.3.2-4
ii  libfm-modules1.3.2-4
ii  libfm4   1.3.2-4
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.78.0-1
ii  libgtk-3-0   3.24.38-5
ii  libiw30  30~pre9-14
ii  libkeybinder-3.0-0   0.3.2-1.1
ii  libmenu-cache3   1.1.0-1.1
ii  libpango-1.0-0   1.51.0+ds-2
ii  libwnck-3-0  43.0-3
ii  libx11-6 2:1.8.6-1
ii  libxml2  2.9.14+dfsg-1.3
ii  lxmenu-data  0.1.5-2.1
ii  lxpanel-data 0.10.1-4

Versions of packages lxpanel recommends:
ii  libnotify-bin  0.8.2-1
ii  notification-daemon3.20.0-4+b1
pn  pavucontrol | gnome-alsamixer  
ii  xkb-data   2.38-2
ii  xterm [x-terminal-emulator]384-1

Versions of packages lxpanel suggests:
ii  chromium [www-browser] 116.0.5845.140-1
ii  falkon [www-browser]   23.08.0-1
ii  firefox-esr [www-browser]  115.2.1esr-1
ii  w3m [www-browser]  0.5.3+git20230121-2

-- no debconf information

Bug#1042714: libmount1: fails to mount vfat filesystem on USB mass storage device with pmount

[Francesco Poli (wintermute)]

Package: libmount1
Version: 2.39.1-3
Severity: important

Hello, thanks for maintaining util-linux in Debian!

After upgrading to version 2.39.1-3, I experienced the following
issue. When I try to use 'pmount' to mount a vfat filesystem on
a USB mass storage device (a digital photocamera, in the present case)
I get a weird error message, claiming that the NTFS signature is missing.
Well, it's a vfat filesystem, so no surprise it's missing NTFS
features...

  $ pmount sdb1 camera
  NTFS signature is missing.
  Failed to mount '/dev/sdb1': Invalid argument
  The device '/dev/sdb1' doesn't seem to have a valid NTFS.
  Maybe the wrong device is used? Or the whole disk instead of a
  partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
  NTFS signature is missing.
  Failed to mount '/dev/sdb1': Invalid argument
  The device '/dev/sdb1' doesn't seem to have a valid NTFS.
  Maybe the wrong device is used? Or the whole disk instead of a
  partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

If I use 'mount' (as the root user) and explicitly specify the
filesystem type, the partition is correctly mounted:

  # mount -t vfat /dev/sdb1 /mnt

However, this is impractical, as it requires root privileges.

As soon as I downgrade package libmount1 (and package mount) to
version 2.38.1-6, everything works again as usual:

  $ pmount sdb1 camera
  $ df --si /media/camera
  FilesystemSize  Used Avail Use% Mounted on
  /dev/sdb1 512M  7.0M  506M   2% /media/camera

What's going on?
Has libmount1/2.39.1-3 lost the capability to recognize vfat
filesystems?

Please investigate and fix this bug as soon as possible.
Thanks for your time and for any help you may provide!



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

Kernel: Linux 6.4.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmount1 depends on:
ii  libblkid12.39.1-3
ii  libc62.37-6
ii  libselinux1  3.5-1

libmount1 recommends no packages.

Versions of packages libmount1 suggests:
pn  cryptsetup-bin  

-- no debconf information

Bug#1035308: jackd2: missing man page for alsa_in/alsa_out (alsa_io)

[Francesco Poli (wintermute)]

Package: jackd2
Version: 1.9.21~dfsg-2
Severity: minor

Hello!

I've recently found out about alsa_in and alsa_out, which seem to be
useful tools to support additional sound cards.

But where's the man page for these two tools?
There seems to be [one] in Debian/bullseye (jackd2/1.9.17~dfsg-1)

[one]: 

But, apparently, package jackd2 somehow lost this man page since the
time bullseye was released as stable...

Was this man page intentionally dropped?
Why? I cannot find any trace in /usr/share/doc/jackd2/changelog.Debian.gz

Or was the man page dropped by accident?
If so, please re-enable it. The man page seems to be included in
the [source] package, but not in the binary package:

  $ dpkg -L jackd2 | grep man/
  /usr/share/man/man1
  /usr/share/man/man1/jackd.1.gz

[source]: 


I am not sure whether this fix is considered an [appropriate] change during
the hard freeze: maybe it is a documentation fix?!?
In case it is not, it's anyway OK, if you fix this bug after bookworm is out.

[appropriate]: 



Thanks for your time and dedication!


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

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

Versions of packages jackd2 depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libasound2 1.2.8-1+b1
ii  libc6  2.36-9
ii  libdbus-1-31.14.6-1
ii  libexpat1  2.5.0-1
ii  libgcc-s1  12.2.0-14
ii  libjack-jackd2-0   1.9.21~dfsg-2
ii  libopus0   1.3.1-3
ii  libreadline8   8.2-1.3
ii  libsamplerate0 0.2.2-3
ii  libsndfile11.2.0-1
ii  libstdc++6 12.2.0-14
ii  libsystemd0252.6-1
ii  libzita-alsa-pcmi0 0.6.1-1
ii  libzita-resampler1 1.8.0-2
ii  python33.11.2-1+b1
ii  python3-dbus   1.3.2-4+b1

Versions of packages jackd2 recommends:
pn  jackd2-firewire  
ii  libpam-modules   1.5.2-6
ii  qjackctl 0.9.9-1

Versions of packages jackd2 suggests:
pn  jack-tools   
pn  meterbridge  

-- debconf information excluded

Bug#1033595: mpv: fails to play YouTube videos after yt-dlp upgrade to version 2023.03.04-1

[Francesco Poli (wintermute)]

Package: mpv
Version: 0.35.1-1
Severity: important

Hi and thanks for maintaining mpv in Debian!


After upgrading from yt-dlp/2023.02.17-1 to yt-dlp/2023.03.04-1,
mpv is no longer able to use yt-dlp to play YouTube videos.

This seems to be due to a change in yt-dlp to solve widespread, severe 
throttling. According to yt-dlp Debian package maintainer, mpv needs
[two] little [patches], in order to adapt to the new yt-dlp version.

[two]: 

[patches]: 


For more details, see bug [#1033517].

[#1033517]: 


Now, I am well aware that bookworm is currently in hard freeze, but I
believe that this bug is important (very important, I would say!) and
should be fixed, even during the freeze.
According to the [freeze policy], even in full freeze, fixes for
important bugs are appropriate, as long as they can be done via unstable
(as it is currently the case for mpv).

[freeze policy]: 

Please, please consider cherry-picking the above [two] [patches] to
mpv Debian package and applying for an unblock, as described in
the [freeze policy].

Thanks for your time and dedication!
Bye.


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

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

Versions of packages mpv depends on:
ii  libarchive13 3.6.2-1
ii  libasound2   1.2.8-1+b1
ii  libass9  1:0.17.1-1
ii  libavcodec-extra59 [libavcodec59]7:5.1.2-3
ii  libavdevice597:5.1.2-3
ii  libavfilter8 7:5.1.2-3
ii  libavformat-extra59 [libavformat59]  7:5.1.2-3
ii  libavutil57  7:5.1.2-3
ii  libbluray2   1:1.3.4-1
ii  libc62.36-8
ii  libcaca0 0.99.beta20-3
ii  libcdio-cdda210.2+2.0.1-1
ii  libcdio-paranoia210.2+2.0.1-1
ii  libcdio192.1.0-4
ii  libdrm2  2.4.114-1+b1
ii  libdvdnav4   6.1.1-1
ii  libegl1  1.6.0-1
ii  libgbm1  22.3.6-1+deb12u1
ii  libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-2
ii  libjpeg62-turbo  1:2.1.5-2
ii  liblcms2-2   2.14-2
ii  liblua5.2-0  5.2.4-3
ii  libmujs2 1.3.2-1
ii  libpipewire-0.3-00.3.65-3
ii  libplacebo2084.208.0-3
ii  libpulse016.1+dfsg1-2+b1
ii  librubberband2   3.1.2+dfsg0-1
ii  libsdl2-2.0-02.26.4+dfsg-1
ii  libsixel11.10.3-3
ii  libswresample4   7:5.1.2-3
ii  libswscale6  7:5.1.2-3
ii  libuchardet0 0.0.7-1
ii  libva-drm2   2.17.0-1
ii  libva-wayland2   2.17.0-1
ii  libva-x11-2  2.17.0-1
ii  libva2   2.17.0-1
ii  libvdpau11.5-2
ii  libvulkan1   1.3.239.0-1
ii  libwayland-client0   1.21.0-1
ii  libwayland-cursor0   1.21.0-1
ii  libwayland-egl1  1.21.0-1
ii  libx11-6 2:1.8.4-2
ii  libxext6 2:1.3.4-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxkbcommon01.5.0-1
ii  libxpresent1 1.0.0-2+b10
ii  libxrandr2   2:1.5.2-2+b1
ii  libxss1  1:1.2.3-1
ii  libxv1   2:1.0.11-1.1
ii  libzimg2 3.0.4+ds1-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages mpv recommends:
ii  xdg-utils  1.1.3-4.1
ii  yt-dlp 2023.03.04-1

Versions of packages mpv suggests:
pn  libcuda1  

-- no debconf information

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

[Francesco Poli (wintermute)]

Package: yt-dlp
Version: 2023.03.04-1
Severity: grave
Justification: renders package unusable

Hello and thanks for maintaining this useful package!


After upgrading from yt-dlp/2023.02.17-1 to yt-dlp/2023.03.04-1, mpv
is no longer able to use yt-dlp to play YouTube videos:

  $ mpv https://www.youtube.com/watch?v=...
  EDL specifies no segments.'
  EDL parsing failed.
  Error in EDL.
  EDL: source file 
'edl://!mp4_dash,init=%915%https://rr1---sn-hpa7znzy.googlevideo.com/videoplayback?expire=1679861814=1lMgZOdpiqvXAtvOorAL=176.207.81.113=.=251=youtube=yes=Ud=31%2C29=sn-hpa7znzy%2Csn-hpa7kn76=au%2Crdu=m=1=21=it=742500=99c5CXNHIzrXpm8d9GnEVnYuvfkNUx0=1=1=audio%2Fwebm=yes=2393695=146.021=1565382960171852=1679839757=2=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cgcr%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRQIgK694JvtFcYR2CD8XvmJn6i09Q9lraFGyVhAMcpRX-UICIQCCGeSN6JZGoxj5dZMwNp-qBqRmJ11_PZLZI2eZCTLkhg%3D%3D=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAJd3QxRLmHXqr04xeeC1fjZSFZr9k6cv2So71H8l6Ax2AiEAhKnq5EgVOp84xsaGYrOL8Uga7UxrqNJG6fCqH4mH238%3D=0-2393695;'
 has unknown duration.
  EDL specifies no segments.'
  EDL parsing failed.
  Error in EDL.
  EDL: source file 
'edl://!mp4_dash,init=%915%https://rr1---sn-hpa7znzy.googlevideo.com/videoplayback?expire=1679861814=1lMgZOdpiqvXAtvOorAL=176.207.81.113=.=248=youtube=yes=Ud=31%2C29=sn-hpa7znzy%2Csn-hpa7kn76=au%2Crdu=m=1=21=it=742500=99c5CXNHIzrXpm8d9GnEVnYuvfkNUx0=1=1=video%2Fwebm=yes=8861743=146.000=1565383003479714=1679839757=2=yes=24007246=ANDROID=5431432=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cgcr%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt=AOq0QJ8wRQIhAKRzV0x6RiHkG_vxxixrOMea0A9COXLNQKnMXZMH-JjoAiBflw-hlwAKQUe_kv1e7oI91GhJbXwXdDtknxSqJXSdVg%3D%3D=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps=AG3C_xAwRgIhAJd3QxRLmHXqr04xeeC1fjZSFZr9k6cv2So71H8l6Ax2AiEAhKnq5EgVOp84xsaGYrOL8Uga7UxrqNJG6fCqH4mH238%3D=0-8861743;'
 has unknown duration.
  File tags:
   Uploader: . - .
   Channel_URL: https://www.youtube.com/channel/
  No video or audio streams selected.
  
  Exiting... (Errors when loading file)

Instead, if I manually download the YouTube video:

  $ yt-dlp -o test https://www.youtube.com/watch?v=...
  [youtube] Extracting URL: https://www.youtube.com/watch?v=...
  [youtube] ...: Downloading webpage
  [youtube] ...: Downloading android player API JSON
  [info] ...: Downloading 1 format(s): 248+251
  [dashsegments] Total fragments: 1
  [download] Destination: test.f248.webm
  [download] 100% of8.45MiB in 00:00:00 at 8.71MiB/s
  [dashsegments] Total fragments: 1
  [download] Destination: test.f251.webm
  [download] 100% of2.28MiB in 00:00:00 at 6.66MiB/s
  [Merger] Merging formats into "test.webm"
  Deleting original file test.f251.webm (pass -k to keep)
  Deleting original file test.f248.webm (pass -k to keep)

I obtain a 'test.webm' file, that can later be played with mpv:

  $ mpv test.webm
   (+) Video --vid=1 (*) (vp9 1080x1080 25.000fps)
   (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
  AO: [jack] 44100Hz stereo 2ch floatp
  VO: [gpu] 1080x1080 yuv420p
  AV: 00:00:03 / 00:02:26 (2%) A-V:  0.000
  
  Exiting... (Quit)


If I downgrade yt-dlp to version 2023.02.17-1, everything works again:

  $ mpv https://www.youtube.com/watch?v=...
   (+) Video --vid=1 (*) (vp9 1080x1080 25.000fps)
   (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
  File tags:
   Uploader: . - .
   Channel_URL: https://www.youtube.com/channel/
  AO: [jack] 44100Hz stereo 2ch floatp
  VO: [gpu] 1080x1080 yuv420p
  AV: 00:00:03 / 00:02:26 (3%) A-V:  0.000 Cache: 141s/15MB
  
  Exiting... (Quit)


What's wrong?

Did yt-dlp change API? If this is the case, the new version of yt-dlp
Debian package should wait for an updated mpv Debian package, before
migrating to testing...

Or is it a bug in yt-dlp that shows up only when yt-dlp is called by mpv
behind the scenes, and not when it is directly invoked from the user's
command line?

Please fix this issue as soon as possible, or revert to the previous
version (yt-dlp/2023.02.17-1), until this behavior has been properly
investigated and solved.

Thanks for your time and patience!


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

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

Versions of packages yt-dlp depends on:
ii  python33.11.2-1
ii  python3-brotli 1.0.9-2+b6
ii  python3-certifi2022.9.24-1
ii  python3-mutagen 

Bug#1030056: qa.debian.org: The most recent lintian version known by UDD is 2.115.3

[Francesco Poli (wintermute)]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

Hi!

In the [UDD Lintian report] for my package, I read:

[...]
| The most recent lintian version known by UDD is 2.115.3
[...]

[UDD Lintian report]: 

However, there are more recent versions of lintian in both unstable
and testing:

  $ rmadison lintian | grep 'unstable\|testing'
  lintian| 2.116.1 | testing| source, all
  lintian| 2.116.2 | buildd-unstable| source, all
  lintian| 2.116.2 | unstable   | source, all

Why is UDD outdated w.r.t. the lintian version?
Shouldn't UDD be aware of the version currently in testing, or maybe
even in unstable?

What's missing?
Did I fail to understand anything?

Please make UDD use the latest lintian version from testing or
unstable, or otherwise clarify my misunderstanding.

Thanks for your time and dedication!
Bye.

Bug#1029570: sc-im: debian/copyright file seems to be inaccurate

[Francesco Poli (wintermute)]

Package: sc-im
Version: 0.8.3+ds-1
Severity: serious
Justification: Policy 4.5

Hello!
Thanks for packaging this interesting program.

I noticed that the [debian/copyright] file seems to be inaccurate
with respect to the [upstream license].

The [debian/copyright] file states:

  [...]
  Files: *
  Copyright: 2013-2021, Andrés Martinelli 
  License: BSD-4-Clause
  [...]

which looks accurate, but then the documented license text
is not a verbatim copy of the [upstream license].

Most notably, clause 3 (out of 4) is missing.
Other minor differences are present.

Please fix the debian/copyright file by including the
correct verbatim copy of the upstream license text.

[debian/copyright]: 

[upstream license]: 


Please note that clause 3 is the infamous "obnoxious advertising
clause" [OAC], which, unfortunately, makes the 4-clause BSD license
GPL-incompatible.

[OAC]: 

As a consequence, I would also recommend to not license
debian/* files under GPL-2+, since having two incompatible
licenses in the same package is risky (it could lead to
a legally undistributable package, unless much care is
taken to never mix the two parts up...).
Maybe debian/* files could be relicensed under the terms
of some non-copyleft permissive license (such as
the Expat license or maybe the 3-clause BSD license...),
if the copyright holder (Joshua Peisach) agrees.


In the meanwhile, it would be really nice, if upstream could
be persuaded to drop the [OAC], thus relicensing the program
under the terms of the 3-clause BSD license.
Why? Because the 4-clause BSD license is a deprecated license,
which causes many GPL-compatibility troubles in the rare cases
where it is still used.
Since the upstream program copyright is currently held by one
sole person, it is still pretty easy to switch to a better
license: only one guy to be persuaded!   :-)

Please try and get in touch with upstream about this.

Thanks for your time and dedication!
Bye.

Bug#1028962: isc-dhcp-client: -x option no longer works (looks like apparmor configuration prevents it from having any effect)

[Francesco Poli (wintermute)]

Package: isc-dhcp-client
Version: 4.4.3-P1-1.1
Severity: important

Hello and thanks for maintaining ISC DHCP in Debian!

After upgrading packages ('isc-dhcp-client' itself or other libraries),
it may happen that

  # checkrestart

(from the 'debian-goodies' package) tells me that an instance of dhclient
should be restarted.

One option is bringing down the corresponding network interface and then
bringing it up again:

  # ifdown $NETWORK_INTERFACE ; ifup $NETWORK_INTERFACE

This works (well, used to work, see below...), but has some drawbacks:
it leaves the box briefly without network, if all goes well; if something
goes wrong, it leaves the box without network, until something else is
done to fix the issue (and it could be troublesome, if you are
administering the box through an SSH session from a distant remote host...);
it may cut existing network connections down; and so forth...

A long time ago, I found what seems to be a better strategy.
First of all, figure out the exact command line for dhclient:

  # ps aux | grep dhclien[t]
  root 738  0.0  0.0   5868  3604 ?Ss   09:37   0:00 
/sbin/dhclient -4 -v -i -pf /run/dhclient.enp0s25.pid -lf 
/var/lib/dhcp/dhclient.enp0s25.leases -I -df 
/var/lib/dhcp/dhclient6.enp0s25.leases enp0s25

Then, stop dhclient without releasing the current lease (as documented in
the dhclient(8) man page):

  # /sbin/dhclient -x -pf /run/dhclient.enp0s25.pid

Finally start dhclient again with the previously found command line:

  # /sbin/dhclient -4 -v -i -pf /run/dhclient.enp0s25.pid -lf 
/var/lib/dhcp/dhclient.enp0s25.leases -I -df 
/var/lib/dhcp/dhclient6.enp0s25.leases enp0s25

This used to work without any network down-time, looked more failsafe and
even quicker.


Unfortunately, this second strategy no longer seems to work.
When I issue the dhclient command with the "-x" option, nothing happens
and dhclient goes on running.

I noticed the following line in /var/log/kern.log :

  2023-01-15T11:29:18.045334+01:00 $HOSTNAME kernel: [ 6692.708089] audit: 
type=1400 audit(1673778558.040:25): apparmor="DENIED" operation="signal" 
profile="/{,usr/}sbin/dhclient" pid=7192 comm="dhclient" requested_mask="send" 
denied_mask="send" signal=term peer="unconfined"

It seems to me that the AppArmor configuration in /etc/apparmor.d/sbin.dhclient
is preventing the "-x" option from having any useful effect.

I am not familiar with AppArmor, but I think that this operation should
be somehow possible, otherwise the AppArmor configuration makes the "-x"
option (almost) completely useless.

Moreover, even the first strategy (ifdown/ifup) now seems to fail to
work perfectly. After issueing the following command:

  # ifdown $NETWORK_INTERFACE ; ifup $NETWORK_INTERFACE

I see that two dhclient istances are running (the previously existing
one, and a new one). And I see the same error in /var/log/kern.log .
Hence, I have to manually kill the previous instance:

  # kill -TERM $OLD_DHCLIENT_PID


All this seems to be extremely annoying and inconvenient.

Please note that I set severity "important" for this bug report,
but one could even claim that this is "grave". Especially taking
into account that ifdown does not stop the running DHCP client...


Please fix the AppArmor configuration or suggest an alternative strategy
to stop the DHCP client without releasing the current lease.
And anyway, please fix the package, so that ifdown works correctly!

Bye and thanks for your time and dedication!




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

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

Versions of packages isc-dhcp-client depends on:
ii  debianutils  5.7-0.4
ii  iproute2 6.1.0-1
ii  libc62.36-8

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.4.3-P1-1.1

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd 
pn  isc-dhcp-client-ddns  
pn  resolvconf

-- no debconf information

Bug#1027441: cups-client: prints on one side, even when the default is two-sided-long-edge or an explicit option is passed to lpr

[Francesco Poli (wintermute)]

Package: cups-client
Version: 2.4.2-1+b2
Severity: important

Hello Debian Printing Team (and Season's Greetings!).

I am experiencing a bug with CUPS: at some point in time in the past
(unfortunately I do not remember exactly with which version, sorry,
I do not print stuff on a daily basis...) CUPS began ignoring the
sides= option value and began printing on one side only.

I remember seeing this issue on other Debian testing boxes with
other printers, but let's focus on the box I am writing this bug
report from.
The printer is an HP LaserJet 1320 printer connected via USB cable,
but I don't think the make and model makes too much of a difference...

The following options are set as default:

  $ lpoptions -p lj
  copies=1 device-uri=usb://HP/LaserJet%201320%20series?serial=00CNFW522KS9 
finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 
job-sheets=none,none marker-change-time=0 media=A4 number-up=1 
pdftops-renderer=pdftops pdftops-renderer-default=pdftops 
print-color-mode=monochrome 
printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info='HP 
LaserJet 1320' printer-is-accepting-jobs=true printer-is-shared=true 
printer-is-temporary=false printer-location=local printer-make-and-model='HP 
LaserJet 1320 Foomatic/pxlmono (recommended)' printer-state=3 
printer-state-change-time=1569079565 printer-state-reasons=none 
printer-type=8564756 printer-uri-supported=ipp://localhost:631/printers/lj 
sides=two-sided-long-edge

Please note that the default is 'sides=two-sided-long-edge'.
However, if I print any multi-page document:

  $ lpr -P lj foo.pdf

I obtain one document page per sheet of paper, that is to say, a one-sided
print, which is almost always *not* what I want (in order to reduce the
waste of paper, the environmental impact, and so forth...).

Even passing explicit options changes nothing:

  $ lpr -P lj -o sides=two-sided-long-edge foo.pdf
  $ lpr -P lj -o fit-to-page -o sides=two-sided-long-edge foo.pdf

It seems that the sides= option is completely ignored.

I have browsed the Debian BTS and found other bug reports that seem
to be related.
Bug [#994395] is similar, but the bug report submitter sees a
'sides=one-sided' default with lpoptions, which is different from
the behavior I am experiencing.
Bug [#1008175] looks much more similar, but was closed as due to
a printer firmware bug. This sounds very awkward to me, but anyway,
in the case of my printer, I am sure I haven't updated its firmware
for ages (and it's not connected to the network, so it cannot even
have auto-updated its own firmware without asking me). This means
that, if the firmware is buggy, it has been buggy for a long time,
and it was buggy even when CUPS was perfectly able to print two-sided.
In other words, if a buggy firmware is to be blamed, CUPS used to
be able to work around this firmware bug and is now no longer able
to do so. So, in any case, there's something that needs to be fixed
in CUPS...

[#994395]: 
[#1008175]: 

Please investigate and fix this bug and/or forward my bug report
upstream, as appropriate.

Thanks for your time and patience!



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (800, 'testing'), (500, 'unstable')
Architecture: i386 (i586)

Kernel: Linux 6.0.0-6-686 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups-client depends on:
ii  adduser  3.129
ii  cups-common  2.4.2-1
ii  libc62.36-7
ii  libcups2 2.4.2-1+b2

cups-client recommends no packages.

Versions of packages cups-client suggests:
ii  cups   2.4.2-1+b2
ii  cups-bsd   2.4.2-1+b2
pn  smbclient  

-- no debconf information

Bug#1027431: RFP: vim-nim -- Nim language support for Vim

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vim-nim
  Version : 1.1.2+git2021.a15714f (or persuade upstream to
   tag releases more often...)
  Upstream Contact: Zahary Karadjov 
* URL : https://github.com/zah/nim.vim
* License : Expat (MIT)
  Programming Lang: Vim (+ Python)
  Description : Nim language support for Vim

nim.vim provides:
 * Syntax highlighting
 * Auto-indent
 * Build/jump to errors within Vim
 * Project navigation and Jump to Definition (cgats or
   compiler-assisted idetools)
for the Nim programming language.



I think this package may be useful, since there is currently
no Vim support for the Nim language in Debian, see bug [#1027002],
not even for syntax highlighting.

[#1027002]: 

I hope someone is willing to package this addon soon.
Thanks to anyone volunteering to do so and maintain it in Debian!

Bug#1027002: vim-runtime: please add syntax highlighting and indentation support for the Nim language

[Francesco Poli (wintermute)]

Package: vim-runtime
Version: 2:9.0.0813-1
Severity: wishlist

Hello!
Do I understand correctly that there's no syntax highlighting or indentation
support for the [Nim] programming language in package vim-runtime?

[Nim]: 

I think it would be a useful addition, perhaps taken from [nim.vim]...

[nim.vim]: 

Please add the relevant files to package vim-runtime and/or forward
my wishlist bug report upstream, as appropriate.

Thanks for your time, bye (and Season's Greetings!).


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

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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim 2:9.0.0813-1+b1
ii  vim-gtk3 [vim]  2:9.0.0813-1+b1
ii  vim-tiny2:9.0.0813-1+b1

vim-runtime suggests no packages.

-- no debconf information

Bug#1026961: openconnect: fails to restore previous network configuration

[Francesco Poli (wintermute)]

Package: openconnect
Version: 9.01-2
Severity: normal

Hello and thanks for maintaining this package in Debian!

I tried it to connect to a Fortinet SSL VPN.
I used the following command:

  # openconnect --prot=fortinet -u $VPNUSER $VPNSERVER

It worked, in the sense that I was able to connect to the VPN.

However, when I decided to disconnect, I used [Ctrl+C] to end the
session: the session ended as expected (good!), but I was left with
a non-working network configuration (outside of the VPN).
In other words, openconnect failed to restore the network configuration
that was in place before its invocation!
Even pinging a remote host resulted in "Network unreachable" errors.

I had to bring my Ethernet network interface down:

  # ifdown $INTERFACE

and then up again:

  # ifup $INTERFACE

in order to get back to a working network configuration (this resulted
in obtaining the network parameters back from the DHCP server and
everything was working fine again).

At the end of the session, I expected openconnect to automatically
restore the network configuration as it had found it at the beginning of
the session.
Please note that another VPN client (package 'openfortivpn', which is
specific for Fortinet VPNs) transparently restores the previous network
configuration, when the user hits [Ctrl+C] to disconnect from the VPN...

I acknowledge that this misbehavior by openconnect is not a big flaw,
but having to manually issue an ifdown/ifup command is anyway annoying.

Please fix this issue and/or forward this bug report upstream, as
appropriate.

Thanks for your time!


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

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

Versions of packages openconnect depends on:
ii  libc62.36-6
ii  libgnutls30  3.7.8-4
ii  libopenconnect5  9.01-2
ii  libproxy1v5  0.4.18-1
ii  libxml2  2.9.14+dfsg-1.1+b2
ii  vpnc-scripts 0.1~git20220510-1

Versions of packages openconnect recommends:
ii  python3 3.10.6-1
ii  python3-asn1crypto  1.5.1-2
ii  python3-mechanize   1:0.4.8+pypi-4
ii  python3-netifaces   0.11.0-2

Versions of packages openconnect suggests:
ii  bash-completion  1:2.11-6
ii  xdg-utils1.1.3-4.1

-- no debconf information

Bug#1025375: hydrogen-doc: documentation binary package is almost empty, should it be dropped entirely?

[Francesco Poli (wintermute)]

Package: hydrogen-doc
Version: 1.2.0~beta1+dfsg-1
Severity: important

Hello and thanks for maintaining Hydrogen in Debian!

I noticed that the hydrogen-doc binary package is now almost empty:

  $ dpkg -L hydrogen-doc
  /.
  /usr
  /usr/share
  /usr/share/doc
  /usr/share/doc/hydrogen-doc
  /usr/share/doc/hydrogen-doc/changelog.Debian.gz
  /usr/share/doc/hydrogen-doc/changelog.gz
  /usr/share/doc/hydrogen-doc/copyright
  /usr/share/hydrogen
  /usr/share/hydrogen/data
  /usr/share/hydrogen/data/new_tutorial
  /usr/share/hydrogen/data/new_tutorial/img_tutorial
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Bridge1_4th.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Bridge3_3a_hh.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/C3_6+7.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Intro4th.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/PatternBase1.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/PatternBase2.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Riff1b.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Riff1c.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Riff1d.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/Verse8th.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/VerseAll.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/VerseBridge.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/VerseBridge_hh.png
  /usr/share/hydrogen/data/new_tutorial/img_tutorial/warn.png
  /usr/share/lintian
  /usr/share/lintian/overrides
  /usr/share/lintian/overrides/hydrogen-doc
  /usr/share/doc/hydrogen-doc/manual_and_old_tutorial
  /usr/share/doc/hydrogen-doc/new_tutorial
  $ ls -l /usr/share/doc/hydrogen-doc/manual_and_old_tutorial
  lrwxrwxrwx 1 root root 23 Nov 27 20:22 
/usr/share/doc/hydrogen-doc/manual_and_old_tutorial -> ../../hydrogen/data/doc
  $ readlink -f /usr/share/doc/hydrogen-doc/manual_and_old_tutorial
  /usr/share/hydrogen/data/doc
  $ ls /usr/share/hydrogen/data/doc
  ls: cannot access '/usr/share/hydrogen/data/doc': No such file or directory


Basically a bunch of screenshots and a dangling symlink...

Then I took a look at the 'changelog.Debian.gz' file, which says:

[...]
  * Clean Hydrogen of currently non-DFSG new documentation
- Use Files-Excluded to exclude tutorial_en.html, which has no source.
[...]

OK, I totally agree with excluding non-free documentation (while in
the meanwhile contacting upstream and persuading them to properly
release source for the documentation and license it under DFSG-free
terms[^NOTE], something which I hope you have already done or are going
to do very soon!).

[^NOTE]: the best option would to license documentation under the same terms
 as the documented program (GPL-2+ in this case)...

But, if, after excluding non-free documentation, almost nothing remains
in the -doc binary package, I wonder what's the point in keeping this
binary package around...

Is there a reasonable hope that the documentation will be re-licensed
in a DFSG-free manner (with source available) real soon now?
If not, I would say that binary package 'hydrogen-doc' could be
dropped entirely...

Please let me know what you think.
Thanks for your time!   :-)


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

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

-- no debconf information

Bug#1021502: lintian: incorrectly complains about debian-news-entry-has-unknown-version

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.115.3
Severity: important

Hi!

I have:

  $ grep -n '(0\.1\.14)' debian/NEWS
  1:apt-listbugs (0.1.14) unstable; urgency=medium
  $ grep -n '(0\.1\.14)' debian/changelog
  391:apt-listbugs (0.1.14) unstable; urgency=medium

in my package ('apt-listbugs').

Running "lintian -EviIL +pedantic" on the .changes file generates
the following report:

  N:
  W: apt-listbugs: debian-news-entry-has-unknown-version 0.1.14 
[usr/share/doc/apt-listbugs/NEWS.Debian.gz:1]
  N:
  N:   The version number of the most recent NEWS.Debian entry does not match 
any
  N:   of the version numbers in the changelog file for this package. This
  N:   usually means the version in NEWS.Debian needs to be updated to match a
  N:   change to package version that happened after the NEWS.Debian entry was
  N:   written.
  N:
  N:   Visibility: warning
  N:   Show-Always: no
  N:   Check: debian/changelog
  N:
  N:


The report does not look right: it seems to me that version 0.1.14 is
indeed present in the changelog file of my package!

Please investigate and fix this bug in lintian.
Thanks for your time!




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

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

Versions of packages lintian depends on:
ii  binutils2.39-6
ii  bzip2   1.0.8-5+b1
ii  diffstat1.64-1
ii  dpkg1.21.9
ii  dpkg-dev1.21.9
ii  file1:5.41-4
ii  gettext 0.21-9
ii  gpg 2.2.39-1
ii  intltool-debian 0.35.0+20060710.5
ii  iso-codes   4.11.0-1
ii  libapt-pkg-perl 0.1.40+b1
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-1+b2
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-4
ii  libclone-perl   0.45-1+b2
ii  libconfig-tiny-perl 2.28-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.9
ii  libemail-address-xs-perl1.05-1
ii  libencode-perl  3.19-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-2
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-2
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.12-1
ii  libmldbm-perl   2.05-3
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.124-1
ii  libperlio-gzip-perl 0.20-1
ii  libperlio-utf8-strict-perl  0.009-1+b1
ii  libproc-processtable-perl   0.634-1+b1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1
ii  libsereal-encoder-perl  5.001+ds-1
ii  libsort-versions-perl   1.62-2
ii  libsyntax-keyword-try-perl  0.27-1
ii  libterm-readkey-perl2.38-2
ii  libtext-levenshteinxs-perl  0.03-5
ii  libtext-markdown-discount-perl  0.13-1+b1
ii  libtext-xslate-perl 3.5.9-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-2
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b3
ii  liburi-perl 5.12-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1
ii  libyaml-libyaml-perl0.84+ds-1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.10.2-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.34.0-5
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.2.5-2.1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1020577: RFP: warewulf4 -- operating system provisioning platform for Linux

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: warewulf4
  Version : 4.3.0
  Upstream Author : Gregory Kurtzer  and others from HPCng 
community
* URL : https://warewulf.org/
* License : BSD-3-clause
  Programming Lang: Go
  Description : operating system provisioning platform for Linux

Long description

Warewulf is an operating system provisioning platform for Linux that is
designed to produce secure, scalable, turnkey cluster deployments that
maintain flexibility and simplicity.
.
Since its initial release in 2001, Warewulf has become the most popular
open source and vendor-agnostic provisioning system within the global
HPC community. Warewulf is known for its massive scalability and simple
management of stateless (disk optional) provisioning.
.
Warewulf leverages a simple administrative model centralizing administration 
around virtual node images which are used to provision out to the cluster 
nodes. This means you can have hundreds or thousands of cluster nodes all 
booting and running on the same, identical virtual node file system image.

Additional information
==
This package would be useful to manage HPC (High Performance Computing)
clusters (or other kinds of clusters), where many nodes boot from a
limited number of system images. These OS images may be updated and/or
modified and then propagated to the associated nodes.

Please note that this is a complete rewrite in Go (with different
license) with respect to version 3 (see bug #919494). Hence,
this RFP bug report should not be merged with the other one.

Bug#1006548: xfce4-power-manager: the icon in the systray is blank!

[Francesco Poli (wintermute)]

Package: xfce4-power-manager
Version: 4.16.0-1
Severity: important

Hello!

I am not sure what's going on, but xfce4-power-manager stopped
showing its icon in the systray (of my fbpanel).
The icon takes space in the systray and may be clicked (the context
menu pops up, with the display brightness slider, the presentation mode
checkbox and the settings... entry), but no icon is actually shown.

As a consequence, there's no visible feedback about the power status.

I am sure it used to work in the past, but I don't know when it
stopped working...

What could be the cause of this issue?

Thanks in advance for any help you may provide.


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

Kernel: Linux 5.16.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.33-7
ii  libcairo2 1.16.0-5
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libglib2.0-0  2.70.4-1
ii  libgtk-3-03.24.31-1
ii  libnotify40.7.9-3
ii  libpango-1.0-01.50.4+ds-1
ii  libpangocairo-1.0-0   1.50.4+ds-1
ii  libupower-glib3   0.99.15-1
ii  libx11-6  2:1.7.2-2+b1
ii  libxext6  2:1.3.4-1
ii  libxfce4ui-2-04.16.1-1
ii  libxfce4util7 4.16.0-1
ii  libxfconf-0-3 4.16.0-2
ii  libxrandr22:1.5.2-1
ii  upower0.99.15-1
ii  xfce4-power-manager-data  4.16.0-1

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd [logind]  250.3-2
ii  xfce4-power-manager-plugins  4.16.0-1

xfce4-power-manager suggests no packages.

-- no debconf information

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[Francesco Poli (wintermute)]

Package: jackd2
Version: 1.9.19~dfsg-2
Severity: grave
Justification: renders package unusable

Hello!
After today's upgrade, jackd stopped working on my Debian testing box.

  $ jackd --realtime -d alsa --device hw:PCH --softmode --hwmeter --rate 44100 &
  jackdmp 1.9.19
  Copyright 2001-2005 Paul Davis and others.
  Copyright 2004-2016 Grame.
  Copyright 2016-2021 Filipe Coelho.
  jackdmp comes with ABSOLUTELY NO WARRANTY
  This is free software, and you are welcome to redistribute it
  under certain conditions; see the file COPYING for details
  no message buffer overruns
  no message buffer overruns
  
  [1]+  Segmentation fault  jackd --realtime -d alsa --device hw:PCH 
--softmode --hwmeter --rate 44100


I tried to selectively downgrade the libraries that appeared related to
jackd2, but to no avail: the segfault was still reproducible.

The list of package upgrades that broke jackd is:

  
  [REMOVE, NOT USED] libbox2d2.3.0:amd64 2.3.1+ds-7
  [REMOVE, NOT USED] libcmis-0.5-5v5:amd64 0.5.2-3
  [REMOVE, NOT USED] libqrcodegencpp1:amd64 1.6.0-1
  [INSTALL, DEPENDENCIES] libbox2d2:amd64 2.4.1-2
  [INSTALL, DEPENDENCIES] libzxingcore1:amd64 1.2.0-1
  [UPGRADE] adwaita-icon-theme:amd64 40.1.1-2 -> 41.0-1
  [UPGRADE] binutils:amd64 2.37-5 -> 2.37-7
  [UPGRADE] binutils-common:amd64 2.37-5 -> 2.37-7
  [UPGRADE] binutils-x86-64-linux-gnu:amd64 2.37-5 -> 2.37-7
  [UPGRADE] cpp-10:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] diffoscope:amd64 182 -> 185
  [UPGRADE] diffoscope-minimal:amd64 182 -> 185
  [UPGRADE] eatmydata:amd64 129-3 -> 129-4
  [UPGRADE] fonts-opensymbol:amd64 2:102.12+LibO7.1.5-2 -> 2:102.12+LibO7.2.1-3
  [UPGRADE] g++-10:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] gcc-10:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] gcc-10-base:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] gcc-11-base:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libasan6:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libatk-wrapper-java:amd64 0.38.0-4 -> 0.38.0-5
  [UPGRADE] libatk-wrapper-java-jni:amd64 0.38.0-4 -> 0.38.0-5
  [UPGRADE] libatomic1:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libbinutils:amd64 2.37-5 -> 2.37-7
  [UPGRADE] libcc1-0:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libctf-nobfd0:amd64 2.37-5 -> 2.37-7
  [UPGRADE] libctf0:amd64 2.37-5 -> 2.37-7
  [UPGRADE] libeatmydata1:amd64 129-3 -> 129-4
  [UPGRADE] libgcc-10-dev:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] libgcc-s1:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libgfortran5:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libglibmm-2.4-1v5:amd64 2.64.2-2 -> 2.66.1-1
  [UPGRADE] libgomp1:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libitm1:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] liblibreoffice-java:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] liblsan0:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libmanette-0.2-0:amd64 0.2.5-1 -> 0.2.6-3
  [UPGRADE] libobjc4:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libquadmath0:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libreoffice:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-base:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-base-core:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-base-drivers:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-calc:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-common:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-core:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-draw:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-impress:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-java-common:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-l10n-de:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-l10n-it:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-math:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-report-builder-bin:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-sdbc-hsqldb:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-style-colibre:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libreoffice-writer:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libscalar-list-utils-perl:amd64 1:1.55-1+b1 -> 1:1.59-1
  [UPGRADE] libstdc++-10-dev:amd64 10.3.0-9 -> 10.3.0-11
  [UPGRADE] libstdc++6:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libtsan0:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libubsan1:amd64 11.2.0-4 -> 11.2.0-7
  [UPGRADE] libuno-cppu3:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libuno-cppuhelpergcc3-3:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libuno-purpenvhelpergcc3-3:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libuno-sal3:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libuno-salhelpergcc3-3:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libunoloader-java:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] libxml2:amd64 2.9.10+dfsg-6.7 -> 2.9.12+dfsg-5
  [UPGRADE] python3-uno:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] rsync:amd64 3.2.3-4 -> 3.2.3-7
  [UPGRADE] uno-libs-private:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] ure:amd64 1:7.1.5-2 -> 1:7.2.1-3
  [UPGRADE] ure-java:amd64 1:7.1.5-2 -> 1:7.2.1-3
  


After some tests, I decided to completely undo today's upgrade:

Bug#993172: gcc-11-base: i386 (Geode LX): latest testing migration produces sig ILL (due to #993162 ?)

[Francesco Poli (wintermute)]

Package: gcc-11-base
Version: 11.2.0-3
Severity: grave
Justification: renders package unusable

Hello!

During today's upgrade, apt-listbugs[^NOTE] warned me that upgrading
libc6 (2.31-13 -> 2.31-17) would produce sig ILL on Geode LX i386 CPUs.
See bug [#993162].

Since I have a Geode LX based box (a Soekris net5501), I decided to
pin libc6 to version 2.31-13, in order to avoid issues, while waiting
for a fixed version of libc6 to migrate to Debian testing (bookworm).

Despite this, I began to see sig ILL (for instance, the smartd daemon
could not be restarted), after the upgrade.

Some tests revealed that these issues were caused by the upgrades
of libstdc++6, libgcc-s1, and libgomp1 (10.2.1-6->11.2.0-3),
allowed by the new installation of gcc-11-base.
Downgrading those three packages and removing gcc-11-base seems to
avoid the sig ILL issues.

I am therefore filing this bug report against gcc-11-base, as a
courtesy to other apt-listbugs users (who will thus be warned
about the need to avoid installing gcc-11-base on Geode LX systems).

Please do not close, reassign, or downgrade the severity of this bug
report, until a proper fix is in place in libc6 and its effects have
propagated to binary packages generated from gcc-11.

Feel free to block this bug report by 993162, if appropriate.

Thanks for your understanding and patience!


[^NOTE]: for the record, I am the current maintainer of apt-listbugs
 and, yes, that package is useful to me as well (of course!)

[#993162]: 


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (800, 'testing'), (500, 'unstable')
Architecture: i386 (i586)

Kernel: Linux 5.10.0-8-686 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#992159: security-tracker: DSA-4957-1 vs. tracker

[Francesco Poli (wintermute)]

Package: security-tracker
Severity: normal

Hi everyone!

In [DSA-4957-1], a number of CVEs are listed as fixed in trafficserver
for buster: CVE-2021-27577 CVE-2021-32566 CVE-2021-32567 CVE-2021-35474
CVE-2021-32565 .

However, the last one [CVE-2021-32565] is not present in the
corresponding [DSA tracker page], probably due to a typo in
the [changelog entry].

[DSA-4957-1]: 

[CVE-2021-32565]: 
[DSA tracker page]: 
[changelog entry]: 


If this is the case, please update the tracker data.
Thanks for your time!

Bug#988823: security-tracker: DSA-4917-1 vs. tracker

[Francesco Poli (wintermute)]

Package: security-tracker
Severity: normal

Hello everyone!

According to [DSA-4917-1], a number of CVEs are fixed in chromium
for buster: CVE-2021-30506 ÷ CVE-2021-30520.

The tracker [DSA page] agrees on that, but also refers to
[CVE-2021-3051], which is not mentioned in the DSA.

[DSA-4917-1]: 

[DSA page]: 
[CVE-2021-3051]: 

Is the DSA incomplete or does the tracker page need a correction?

Please let me know, and update the tracker data, if needed.
Thanks for your time!

Bug#984469: guitarix: debian/copyright is inaccurate

[Francesco Poli (wintermute)]

Package: guitarix
Version: 0.42.1+dfsg1-1
Severity: serious
Tags: patch
Justification: Policy 12.5

Dear Debian Multimedia Maintainers,
I noticed that the [debian/copyright] file for guitarix states that
two images ('data/Layout.svg' and 'data/stereo.svg') are under
CC-BY-1.0, which does not meet the DFSG.

[debian/copyright]: 


I got in touch with the upstream developers, with the intention to
persuade them to re-license the two files under DFSG-free terms.
And I found out that those two files are already under GPL-2+,
as the majority of the guitarix package files.
See the [confirmation] from the Guitarix devs.

[confirmation]: 

This means that there is no DFSG-freeness issue in the guitarix package
(and that's wonderful news!): it's the debian/copyright file that appears
to be inaccurate.

Please find attached a patch that fixes the debian/copyright file
to better reflect the actual licensing status of the package.

Please apply the patch as soon as possible.
Thanks for your time.

Bye!


fix_guitarix_copyright.diff.xz
Description: application/xz

Bug#982099: lxpanel: randomly fails to display one of the configured launchers

[Francesco Poli (wintermute)]

Package: lxpanel
Version: 0.10.0-3
Severity: important

Hello!

First of all thanks for maintaining this nice panel in Debian.
I am giving it a try, in order to check whether I can switch to
it from fbpanel, which [risks] being removed from Debian.

[risks]: 


Unfortunately, I am experiencing what seems to be a bug.

I configured two launchers in the Application Launch Bar, but it rather
often happens that lxpanel fails to display one of them.
At that point (without changing anything in the configuration), I kill
lxpanel and start it again:

  $ killall -TERM lxpanel
  $ lxpanel &

After doing so, lxpanel may fail again to display one of the two launchers.
Hence, I kill it and restart it again.
After repeating this process a number of times, lxpanel is again able to
display both my launchers. But nothing changed in the configuration, so
the issue seems to be non-deterministic (maybe some race condition?).

See the attached screenshots for the correct panel portion
(with_both_launchers.png) and the incorrectly displayed panel portion
(without_one_launcher.png).


Please investigate/fix the bug and/or forward my bug report upstream.
Thanks for your time and helpfulness!


My lxpanel configuration follows.

  $ cat ~/.local/share/applications/uxterm-start-login.desktop 
  [Desktop Entry]
  Type=Application
  Name=Terminal
  Icon=/usr/share/icons/hicolor/scalable/apps/xterm-color.svg
  Exec=/usr/bin/uxterm -ls
  Terminal=false
  Categories=X-LXPanel;
  $ cat ~/.local/share/applications/xscreensaver-lock-screen.desktop 
  [Desktop Entry]
  Type=Application
  Name=Lock screen
  Icon=/usr/share/pixmaps/xscreensaver.svg
  Exec=/usr/bin/xscreensaver-command -lock
  Terminal=false
  Categories=X-LXPanel;
  $ cat ~/.config/lxpanel/launchtaskbar.cfg 
  [special_cases]
  synaptic=synaptic-pkexec
  soffice.bin=libreoffice
  x-terminal-emulator=lxterminal
  $ cat ~/.config/lxpanel/default/config
  [Command]
  $ cat ~/.config/lxpanel/default/panels/panel 
  # lxpanel  config file. Manually editing is not recommended.
  # Use preference dialog in lxpanel to adjust config when you can.
  
  Global {
edge=bottom
allign=left
margin=275
widthtype=percent
width=100
height=28
transparent=1
tintcolor=#dcdad5
alpha=255
setdocktype=1
setpartialstrut=1
usefontcolor=1
fontcolor=#10394d
usefontsize=0
fontsize=10
background=0
backgroundfile=/usr/share/lxpanel/images/background.png
align=right
iconsize=24
  }
  Plugin {
type=launchbar
Config {
  Button {
id=uxterm-start-login.desktop
  }
  Button {
id=xscreensaver-lock-screen.desktop
  }
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=pager
Config {
}
  }
  Plugin {
type=space
Config {
  Size=10
}
expand=0
  }
  Plugin {
type=taskbar
expand=1
Config {
  tooltips=1
  IconsOnly=0
  AcceptSkipPager=1
  ShowIconified=1
  ShowMapped=1
  ShowAllDesks=0
  UseMouseWheel=1
  UseUrgencyHint=1
  FlatButton=0
  MaxTaskWidth=150
  spacing=1
  GroupedTasks=0
  DisableUpscale=0
  UseSmallerIcons=-1
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=tray
Config {
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=dclock
Config {
  ClockFmt=%R
  TooltipFmt=%a, %d %b %Y
  BoldFont=1
  IconOnly=0
  CenterText=1
}
  }
  Plugin {
type=space
Config {
  Size=5
}
  }





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

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

Versions of packages lxpanel depends on:
ii  libasound2   1.2.4-1.1
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libcurl3-gnutls  7.74.0-1
ii  libfm-gtk4   1.3.1-1.1
ii  libfm-modules1.3.1-1.1
ii  libfm4   1.3.1-1.1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk2.0-0  2.24.33-1
ii  libiw30  30~pre9-13.1
ii  libkeybinder00.3.1-2.1
ii  libmenu-cache3   1.1.0-1.1
ii  libpango-1.0-0   1.46.2-3
ii  libwnck222.30.7-6
ii  libx11-6 2:1.7.0-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  lxmenu-data  0.1.5-2.1
ii  lxpanel-data 0.10.0-3

Versions of packages lxpanel recommends:
ii  libnotify-bin  0.7.9-2
ii  notification-daemon3.20.0-4
pn  pavucontrol | gnome-alsamixer  
ii  xkb-data   2.29-2
ii  xterm [x-terminal-emulator]363-1

Bug#979541: sylpheed: [regression] spell check no longer recognizes some correct Italian words

[Francesco Poli (wintermute)]

Package: sylpheed
Version: 3.7.0-8
Severity: normal

Hello!

A few days ago, I began experiencing a strange regression in Italian
spell check within Sylpheed.
Some correct Italian words are no longer recognized as valid.
Especially words with accented vowels (which include non-ASCII UTF-8
characters), but not only.

For example, if I compose a message with the following text:

  """
  Questa è una prova che mi interessa poiché c'è qualcosa che non va.
  """

and select "it" spell language, I see the following red-underlined
words or expressions: "è", "poiché", "c'è".

For the record, the above text is the Italian for:

  """
  This is a test I am interested in, since there's something wrong.
  """

and all the Italian words are correct (I am an Italian native speaker).

The strange thing is that aspell (the program) does not seem to
have issues with the text:

  $ cat test.txt
  Questa è una prova che mi interessa poiché c'è qualcosa che non va.
  $ aspell -l it check test.txt 

Hence, I do not understand what exactly broke during the last days
of package upgrades.
Maybe the way Sylpheed communicates the text to aspell?

Please investigate the bug and fix it and/or forward my bug report
upstream, as appropriate.

Thanks for your time.
Bye!



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

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

Versions of packages sylpheed depends on:
ii  libc62.31-6
ii  libcairo21.16.0-5
ii  libcompfaceg11:1.5.2-5+b2
ii  libenchant-2-2   2.2.12-1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.4-1
ii  libgpgme11   1.14.0-1+b2
ii  libgtk2.0-0  2.24.33-1
ii  libgtkspell0 2.0.16-1.3
ii  libldap-2.4-22.4.56+dfsg-1
ii  libonig5 6.9.5-2
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libssl1.11.1.1i-1
ii  pinentry-gtk21.1.0-4
ii  sensible-utils   0.0.12+nmu1

Versions of packages sylpheed recommends:
ii  aspell-de [aspell-dictionary]  20161207-8
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  aspell-it [aspell-dictionary]  2.4-20070901-0-3.1
ii  ca-certificates20200601
pn  sylfilter | bogofilter | bsfilter  
ii  sylpheed-i18n  3.7.0-8

Versions of packages sylpheed suggests:
pn  claws-mail-tools  
ii  curl  7.74.0-1
pn  sylpheed-doc  
pn  sylpheed-plugins  

-- no debconf information

Bug#977780: connman: wifi stopped working with net.connman.Error.NoCarrier

[Francesco Poli (wintermute)]

Package: connman
Version: 1.36-2+b1
Severity: important

Hello and thanks for maintaining this package in Debian!

I've just installed it, in order to give it a try.
It seemed to work like a charm, with connman-gtk GUI: I was able
to connect with the Ethernet LAN, disconnect from it, connect with
the Wireless LAN, disconnect from it, and all looked right.
I rebooted and all looked OK again.

Then, after one more reboot, I suddenly became unable to connect
to the Wireless LAN, getting the following error in a dialog window:

  Failed to toggle connection state.

  GDBus.Error:net.connman.Error.NoCarrier: No carrier

I really cannot understand what's going on.

It seems to me that the WiFi network card is still visible:

  $ /sbin/ifconfig
  [...]
  wlan0: flags=-28669  mtu 1500
ether 20:68:9d:72:70:cc  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Where did I go wrong?
Please help me!

Thanks for your time.


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

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

Versions of packages connman depends on:
ii  dbus  1.12.20-1
ii  iptables  1.8.6-1
ii  libc6 2.31-5
ii  libdbus-1-3   1.12.20-1
ii  libglib2.0-0  2.66.3-2
ii  libgnutls30   3.6.15-4
ii  libreadline8  8.1-1
ii  libxtables12  1.8.6-1
ii  lsb-base  11.1.0

Versions of packages connman recommends:
pn  bluez  
pn  ofono  
ii  wpasupplicant  2:2.9.0-16

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#977419: lintian: Use of uninitialized value in string eq at package-relations.pm

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.104.0
Severity: important

Hello!

While checking the apt-listbugs package (which I maintain), I experienced
an awkward lintian behavior:

  $ lintian -viF apt-listbugs_0.1.35~rc3_amd64.changes
  N: Using profile debian/ftp-master-auto-reject.
  N: Starting on group apt-listbugs/0.1.35~rc3
  Warning in group apt-listbugs/0.1.35~rc3: Use of uninitialized value in 
string eq at /usr/share/lintian/checks/fields/package-relations.pm line 129.
  Warning in group apt-listbugs/0.1.35~rc3: Use of uninitialized value in 
string eq at /usr/share/lintian/checks/fields/package-relations.pm line 129.
  [...]
  N: Finished processing group apt-listbugs/0.1.35~rc3

with the warning repeated 188 times.

If I enable more checks with:

  $ lintian -EviIL +pedantic apt-listbugs_0.1.35~rc3_amd64.changes

I get the same 188 warnings and two false positives:

  E: apt-listbugs: alternates-not-allowed Depends
  N:
  E: alternates-not-allowed
  N:
  N:   Only the "Depends", "Recommends", "Suggests" and "Pre-Depends" fields
  N:   may specify alternate dependencies using the "|" symbol.
  N:
  N:   Refer to Debian Policy Manual section 7.1 (Syntax of relationship
  N:   fields) for details.
  N:
  N:   Severity: error
  N:
  N:   Check: fields/package-relations
  N:
  E: apt-listbugs: alternates-not-allowed Suggests

I _think_ that these two complaints are false positives, since the
[debian/control] file has not changed since version 0.1.34 and
the same file has been previously (on December the 5th, 2020)
checked by the same version 2.104.0 of lintian, without any
complaint.
And I cannot understand what's wrong with the debian/control file.
But of course, I may be wrong: if this is the case, then please
help me understand...

[debian/control]: 


Is this new awkward behavior of lintian caused by some recent Perl
package upgrade in sid?
Among the lintian dependencies, I see the following changed versions:

  libicu67:amd64 (67.1-4)  ->  (67.1-5)
  libxml2:amd64 (2.9.10+dfsg-6.3)  ->  (2.9.10+dfsg-6.3+b1)
  liblist-moreutils-perl (0.416-1+b6)  ->  (0.430-1)

and nothing else, it seems.

Please investigate and fix this issue.
Thanks for your time!

Bye.



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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.35.1-4
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.39-3
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b4
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b6
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012000-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl

Bug#974949: systray-mdstat: fails to start with org.freedesktop.DBus.Error.ServiceUnknown

[Francesco Poli (wintermute)]

Package: systray-mdstat
Version: 1.2.0-1
Severity: grave
Justification: renders package unusable

Hello,
I've just given the new version from unstable a try.

It seems to completely fail to start:

  $ systray-mdstat &
  [1] 64881
  $ org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Notifications was not provided by any .service files
  
  [1]+  Exit 11 systray-mdstat

This seems to render the package unusable.
I am setting grave severity accordingly: this should prevent migration
to testing, until the bug is fixed.

Please investigate and fix the bug.
Thanks!


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

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

Versions of packages systray-mdstat depends on:
ii  libdesktop-notify-perl  0.05-2
ii  libfile-sharedir-perl   1.118-1
ii  libgtk3-perl0.037-1
ii  libtry-tiny-perl0.30-1
ii  perl5.30.3-4

systray-mdstat recommends no packages.

Versions of packages systray-mdstat suggests:
ii  fbpanel 7.0-4+b1
pn  smart-notifier  

-- no debconf information

Bug#965031: python3-numpy: please clarify the license for some files in debian/copyright

[Francesco Poli (wintermute)]

Package: python3-numpy
Version: 1:1.19.0-1
Severity: important

Hello and thanks for maintaining NumPy in Debian!

While reviewing the package debian/copyright file, I noticed
some files for which only the copyright holder seems to be
documented, but not the license.

These files are:
  numpy/core/src/umath/{reduction.c, ufunc_type_resolution.c
  numpy/core/src/umath/ufunc_object.c
  numpy/core/arrayprint.py
  numpy/core/src/multiarray/{arrayobject.c, usertypes.c}
  numpy/core/src/multiarray/multiarraymodule.c
  numpy/core/src/multiarray/{lowlevel_strided_loops.c.src, nditer_api.c,
 nditer_constr.c, nditer_pywrap.c, 
nditer_templ.c.src}
  numpy/core/src/multiarray/{array_assign_array.c, array_assign.c,
 array_assign_scalar.c, datetime_busday.c,
 datetime_busdaycal.c, datetime.c, 
datetime_strings.c}
  doc/cython/c_numpy.pxd, doc/pyrex/c_numpy.pxd

Does the NumPy default license apply to the above files?
If so, it should be more explicitly documented in the debian/copyright
file.
If not, has there been any attempt to get in touch with the copyright
holders and obtain a license, so that these files explicitly meet the
DFSG?


Moreover, the following files
  numpy/oldnumeric/ma.py
  numpy/ma/*
just say "Released for unlimited redistribution.", which is kind
of laconic for a license.
It is it all the permission we are left with?
Has there been any attempt to get in touch with the copyright holders
and obtain a clearer license, so that these files more explicitly
meet the DFSG?


Please let me know, thanks for your time and dedication!

Bug#963840: libsoqt520-dev: debian/copyright reports the wrong license short name

[Francesco Poli (wintermute)]

Package: libsoqt520-dev
Version: 1.6.0+ds1-1
Severity: important
Tags: patch

Hello!

I've just noticed that the [debian/copyright] file for this package
reports "BSD-4-clause" as license short name.
But the license text is actually the text of the [BSD-3-clause].
And this seems to be the license the package is really released under.

[debian/copyright]: 

[BSD-3-clause]: 

Please fix the debian/copyright file by applying the following
change:


diff -ruN a/debian/copyright b/debian/copyright
--- a/debian/copyright  2020-04-28 03:37:56.0 +0200
+++ b/debian/copyright  2020-06-28 11:43:32.111856926 +0200
@@ -6,7 +6,7 @@
 Files: *
 Copyright: 1998-2005 by Systems in Motion
2005-2013 Kongsberg Oil & Gas Technologies AS
-License: BSD-4-clause
+License: BSD-3-clause
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are
  met:


Thanks for your time!
Bye.

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Francesco Poli (wintermute)]

Package: libefivar1
Version: 37-2.1
Severity: important

Hello!

One week ago I had no issues in running:

  $ efibootmgr -v

but today, I get:

  $ efibootmgr -v
  BootCurrent: 0001
  Timeout: 1 seconds
  BootOrder: 0001,
  Boot* debianCould not parse device path: Invalid argument

Please note that (luckily!) the system is able to boot and reboot,
and that the non-verbose output is:

  $ efibootmgr
  BootCurrent: 0001
  Timeout: 1 seconds
  BootOrder: 0001,
  Boot* debian
  Boot0001* debian2

I searched the web and found a github [issue], that claims the
problem is in efivar, mentioning a [commit] that is supposed
to fix it.
But it seems to me that the [code] currently in Debian unstable
does not include this fix.

[issue]: 
[commit]: 

[code]: 

I hope I am not completely off-track...   :-p

Could you please investigate the issue and cherrypick the patch,
if appropriate?

Thanks for your time.


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

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

Versions of packages libefivar1 depends on:
ii  libc6  2.30-8

libefivar1 recommends no packages.

libefivar1 suggests no packages.

-- no debconf information

Bug#962236: normalize-audio: "normalize-ogg -b -n -v" shows less info than "normalize-audio -b -n -v"

[Francesco Poli (wintermute)]

Package: normalize-audio
Version: 0.7.7-15
Severity: normal

Hello and thanks for maintaining this nice program in Debian!


I wanted to run normalize (in batch mode) on a group of audio files
with the --no-adjust option, in order to analyze the files, without
altering them in any way.

I can do this on a group of .wav files with

  $ normalize-audio --amplitude=-7.5dBFS -b -n -v *.wav

and it seems to work as intended.

However, if I want to do it on a group of .ogg files, I get
per-track info, but not the standard deviation, average, or
per-album adjustment data.

  $ normalize-ogg -a -7.5dBFS --tmpdir /dev/shm -b -n -v *.ogg
  Decoding track01.ogg...
  Decoding track02.ogg...
  Decoding track03.ogg...
  Decoding track04.ogg...
  Decoding track05.ogg...
  Decoding track06.ogg...
  Decoding track07.ogg...
  Decoding track08.ogg...
  Decoding track09.ogg...
  Decoding track10.ogg...
  Decoding track11.ogg...
  Decoding track12.ogg...
  Running normalize...
  Computing levels...
levelpeak
  -6.8533dBFS  0.dBFS   /dev/shm/track01.ogg.16607.wav   
  -8.0583dBFS  0.dBFS   /dev/shm/track02.ogg.16607.wav
  -7.1047dBFS  0.dBFS   /dev/shm/track03.ogg.16607.wav
  -7.2339dBFS  0.dBFS   /dev/shm/track04.ogg.16607.wav
  -7.7699dBFS  0.dBFS   /dev/shm/track05.ogg.16607.wav
  -7.1890dBFS  0.dBFS   /dev/shm/track06.ogg.16607.wav
  -8.0084dBFS  0.dBFS   /dev/shm/track07.ogg.16607.wav
  -7.6048dBFS  0.dBFS   /dev/shm/track08.ogg.16607.wav
  -7.4123dBFS  0.dBFS   /dev/shm/track09.ogg.16607.wav
  -7.5195dBFS  0.dBFS   /dev/shm/track10.ogg.16607.wav
  -8.1773dBFS  0.dBFS   /dev/shm/track11.ogg.16607.wav
  -7.5512dBFS  0.dBFS   /dev/shm/track12.ogg.16607.wav

This is weird, since normalize-ogg decodes the .ogg files into
.wav files and then runs normalize-audio on them.
Hence, I would expect the same output...

Yet, if I manually run normalize-audio on the decoded files,
I also get the final data I am interested in:

  $ normalize-audio --amplitude=-7.5dBFS -b -n -v /dev/shm/*.wav
  Computing levels...
levelpeak
  -6.8533dBFS  0.dBFS   /dev/shm/track01.ogg.16607.wav
  -8.0583dBFS  0.dBFS   /dev/shm/track02.ogg.16607.wav
  -7.1047dBFS  0.dBFS   /dev/shm/track03.ogg.16607.wav
  -7.2339dBFS  0.dBFS   /dev/shm/track04.ogg.16607.wav
  -7.7699dBFS  0.dBFS   /dev/shm/track05.ogg.16607.wav
  -7.1890dBFS  0.dBFS   /dev/shm/track06.ogg.16607.wav
  -8.0084dBFS  0.dBFS   /dev/shm/track07.ogg.16607.wav
  -7.6048dBFS  0.dBFS   /dev/shm/track08.ogg.16607.wav
  -7.4123dBFS  0.dBFS   /dev/shm/track09.ogg.16607.wav
  -7.5195dBFS  0.dBFS   /dev/shm/track10.ogg.16607.wav
  -8.1773dBFS  0.dBFS   /dev/shm/track11.ogg.16607.wav
  -7.5512dBFS  0.dBFS   /dev/shm/track12.ogg.16607.wav
  Standard deviation is 0.39 dB
  -7.5314dBFS  average level
  0.031363dB   volume adjustment

I cannot understand why normalize-ogg seems to suppress the
final output lines (which include interesting data about
standard deviation, average, and per-album adjustment!).

I took a look at the normalize-ogg code, but my knowledge
about Perl is just a smattering, and, in addition, it is rusty.
Hence, I failed to understand the tricky part (with exec()
and pipe handling, I think...).

How can normalize-ogg be fixed to show all the output
of normalize-audio?
Please fix this bug and/or forward my bug report upstream,
as appropriate.

Thanks for your time!
Bye.


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

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

Versions of packages normalize-audio depends on:
ii  libaudiofile1  0.3.6-5
ii  libc6  2.30-8
ii  libmad00.15.1b-10
ii  perl   5.30.2-1

Versions of packages normalize-audio recommends:
ii  flac  1.3.3-1
ii  vorbis-tools  1.4.0-11

Versions of packages normalize-audio suggests:
pn  mpg321  

-- no debconf information

Bug#961684: lintian: exits with error: Can't use an undefined value as a HASH reference

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.77.0
Severity: grave
Justification: renders package unusable

Hello,
while attempting to check a just built package within my sid
pbuilder-managed chroot enviroment, I see that lintian is no
longer working.
Please note that lintian/2.76.0 was working fine in the same
environment.

Attempting to check the package with the following command:

  # su -p pbuser -c "lintian -viF $PACKAGE.changes"
  Can't use an undefined value as a HASH reference at 
/usr/share/lintian/commands/lintian.pm line 831.

exits immediately with the above shown error message.
Same exact misbehavior with:

  # su -p pbuser -c "lintian -EviIL +pedantic $PACKAGE.changes"

I would say that this renders lintian unusable, hence the
'grave' severity of the bug report.

Please fix this issue.
Thanks for your time and dedication!


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=en_US:en (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages lintian depends on:
ii  binutils 2.34-8
ii  bzip21.0.8-3
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-5
ii  gettext  0.19.8.1-10
ii  gpg  2.2.20-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.68-1
ii  libcapture-tiny-perl 0.48-1
ii  libclass-xsaccessor-perl 1.19-3+b4
ii  libclone-perl0.45-1
ii  libconfig-tiny-perl  2.24-1
ii  libcpanel-json-xs-perl   4.19-1
ii  libdevel-size-perl   0.83-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libjson-maybexs-perl 1.004002-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.004000-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.112-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3300-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.010001-1
ii  libunicode-utf8-perl 0.62-1+b1
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.82+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.2-1
ii  t1utils  1.41-4
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli (wintermute)]

Package: firefox-esr
Version: 68.8.0esr-1
Severity: important

Hello!

This morning I upgraded my Debian testing box, and firefox-esr
had the following upgrade:

  [UPGRADE] firefox-esr:amd64 68.7.0esr-1 -> 68.8.0esr-1

After the upgrade, I noticed that firefox-esr was no longer
able to find my microphone (mic input on the audio card integrated on
my motherboard). At first, I thought the issue was due to some
misconfiguration on my part (for instance on the ALSA side), but, no,
ALSA is able to see the CAPTURE ports and they are enabled and unmuted.
After going mad for quite some time, I saw that chromium was still
happily to able to find the microphone and use it...

Please note that the same configuration was working perfectly
yesterday (before the firefox-esr upgrade).

If I test on , the response
is:

|  We can't find your microphone - that most probably means that it's
|  either not connected, broken, or you don't have the proper webcam
|  drivers

But no, it's not a webcam microphone (although I also have a webcam,
which is correctly found by firefox-esr, as a video input).
The issue is that firefox-esr can no longer find any microphone.

I have also tried with "firefox-esr -safe-mode" and I am able
to reproduce the issue, hence it does not seem to be caused by
some extension.

During these COVID-19 pandemic times, working from home, not being
able to use the microphone with the browser (for teleconferencing,
videocalls, and so forth) is a big regression.
I would even say that this bug should have severity "grave".
Please raise the severity, if you agree.

Please try to reproduce the bug, fix it, and/or forward the bug
report upstream, as appropriate.

Thanks for your time and dedication!



-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-4
ii  libasound21.2.2-2.1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-7
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-4
ii  libfontconfig12.13.1-4
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10-20200418-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libglib2.0-0  2.64.2-1
ii  libgtk-3-03.24.20-1
ii  libjsoncpp1   1.7.4-3.1
ii  libnspr4  2:4.25-1
ii  libnss3   2:3.49.1-1
ii  libpango-1.0-01.44.7-4
ii  libsqlite3-0  3.31.1-5
ii  libstartup-notification0  0.12-6
ii  libstdc++610-20200418-1
ii  libx11-6  2:1.6.9-2+b1
ii  libx11-xcb1   2:1.6.9-2+b1
ii  libxcb-shm0   1.14-2
ii  libxcb1   1.14-2
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.16-4
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec-extra58 [libavcodec58]  7:4.2.2-1+b1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-7
ii  libgtk2.0-02.24.32-4
pn  pulseaudio 

-- no debconf information

Bug#959231: security-tracker: Proxy Error on CVE-2020-11565 tracker page

[Francesco Poli (wintermute)]

Package: security-tracker
Severity: normal

Hi all!

I noticed that the tracker page for [CVE-2020-11565] fails to display
and returns the following error:

| Proxy Error
| 
| The proxy server received an invalid response from an upstream server.
| The proxy server could not handle the request
| 
| Reason: Error reading from remote server
| 
| Apache Server at security-tracker.debian.org Port 443

[CVE-2020-11565]: 

Please note that the CVE is mentioned in [DSA-4667-1].

[DSA-4667-1]: 


What's wrong with that tracker page?
Please fix anything that's missing.

Thanks for your time and dedication!

Bug#956602: jami-daemon: any possibility to drop the dependency on librestbed?

[Francesco Poli (wintermute)]

Package: jami-daemon
Version: 20190215.1.f152c98~ds1-1
Severity: wishlist

Dear Alexandre,
first of all, thanks a lot for developing Jami and for maintaining
it in Debian!

I noticed that jami-daemon depends on librestbed0, which is facing
some OpenSSL linking licensing issues, as described in bug [#951877].

[#951877]: 

Beside the OpenSSL issues, librestbed0 is [dual licensed] under
a non-free "Corvusoft Permissive License" version 2.0 license
or the GNU AfferoGPL version 3 (or later).

[dual licensed]: 


Jami is clearly choosing the GNU AfferoGPL here, since Jami
is released under the terms of the GNU GPL v3 (or later), which
is compatible with the GNU AfferoGPL v3.

However, the GNU AfferoGPL v3 is a controversial license, which has
raised a number of discussions, since its drafting and publication.
Some people (including me...) think that the GNU AfferoGPL v3 does
not meet the DFSG.

Do you think there is any chance to persuade the upstream developers
of librestbed to re-license it under more uncontroversially DFSG-free
terms (GNU GPL or more permissive)?
Or, failing that, is there any chance to drop the dependency on
librestbed, maybe replacing it with a dependency on some other
(GPL or more permissively licensed) library?

Please let me know, thanks for your time.

Bug#954410: weechat: Please package the slack plugin

[Francesco Poli (wintermute)]

Package: weechat
Version: 2.7.1-1
Severity: wishlist

Hello and thanks for maintaining this Debian package!

Does it include support for accessing slack channels?
I've read that there exists a plugin named [wee-slack], but
I cannot find the corresponding Debian package.

[wee-slack]: 

If the plugin is not packaged, could you please package it?
Thanks for your time and helpulness!

Bug#951366: rkhunter: libkeyutils1/1.6.1-2 triggers a false positive

[Francesco Poli (wintermute)]

Package: rkhunter
Version: 1.4.6-7
Severity: important

Hello and thanks for maintaining rkhunter in Debian!

After upgrading

  [UPGRADE] libkeyutils1:amd64 1.6-6 -> 1.6.1-2

I get the following warning with

  # rkhunter --sk -c

in /var/log/rkhunter.log:

  Info: Starting test name 'running_procs'
Checking running processes for suspicious files [ Warning ]
  Warning: The following processes are using suspicious files:
   Command: sshd
 UID: 0PID: 7331
 Pathname: /lib/x86_64-linux-gnu/libkeyutils.so.1.9
 Possible Rootkit: Spam tool component

As explained in [bug #951338], this looks like a false positive
triggered by just the filename.

[bug #951338]: 

Please fix this false positive, since getting a daily alert
from rkhunter for this is annoying.

Thanks for your time!
Bye.


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

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

Versions of packages rkhunter depends on:
ii  binutils   2.34-2
ii  debconf [debconf-2.0]  1.5.73
ii  file   1:5.38-4
ii  lsof   4.93.2+dfsg-1
ii  net-tools  1.60+git20180626.aebd88e-1
ii  perl   5.30.0-9
ii  ucf3.0038+nmu1

Versions of packages rkhunter recommends:
ii  curl   7.67.0-2
ii  e2fsprogs  1.45.5-2
ii  exim4-daemon-light [mail-transport-agent]  4.93-10
ii  iproute2   5.4.0-1
ii  mailutils [mailx]  1:3.7-2
ii  unhide 20130526-4
ii  unhide.rb  22-4
ii  wget   1.20.3-1+b2

Versions of packages rkhunter suggests:
ii  liburi-perl 1.76-2
ii  libwww-perl 6.43-1
pn  powermgmt-base  

-- Configuration Files:
/etc/rkhunter.conf changed [not included]

-- debconf information:
  rkhunter/apt_autogen: yes
  rkhunter/cron_db_update: yes
  rkhunter/cron_daily_run: yes

Bug#951338: libkeyutils1: rkhunter warns that libkeyutils.so.1.9 may contain a possible rootkit

[Francesco Poli (wintermute)]

Package: libkeyutils1
Version: 1.6.1-2
Severity: grave
Tags: security
Justification: user security hole

Hello!

After upgrading

  [UPGRADE] libkeyutils1:amd64 1.6-6 -> 1.6.1-2

I get the following warning with

  # rkhunter --sk -c 

in /var/log/rkhunter.log:

  Info: Starting test name 'running_procs'
Checking running processes for suspicious files [ Warning ]
  Warning: The following processes are using suspicious files:
   Command: sshd
 UID: 0PID: 7331
 Pathname: /lib/x86_64-linux-gnu/libkeyutils.so.1.9
 Possible Rootkit: Spam tool component

I tried to reinstall libkeyutils1/1.6.1-2, after checking the SHA256
checksum of the .deb file. The warning was issued again.

On the other hand, after downgrading to libkeyutils1/1.6-6
and restarting ssh

  # service ssh restart

the warning vanishes.


Does libkeyutils1/1.6.1-2 ship a rootkit?
Or is it a false positive from rkhunter?

Please investigate.
Thanks for your time!



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

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

Versions of packages libkeyutils1 depends on:
ii  libc6  2.29-10

libkeyutils1 recommends no packages.

libkeyutils1 suggests no packages.

-- no debconf information

Bug#947686: security-tracker: DSA-4595-1 vs. tracker

[Francesco Poli (wintermute)]

Package: security-tracker
Severity: normal

Hello everyone!

According to [DSA-4595-1], CVE-2019-3467 is fixed in debian-lan-config
for stretch and buster.

However, the tracker [CVE page] does not seem to be linked to the
[DSA page], thus failing to show the correct fixed versions for
debian-lan-config.

Please update the tracker data, as appropriate.

Thanks for your time!

[DSA-4595-1]: 

[CVE page]: 
[DSA page]: 

Bug#945118: asymptote: FTBFS because of grffile

[Francesco Poli (wintermute)]

Package: asymptote
Version: 2.60-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello!

The fix for bug [#944916] seems to be somehow incomplete and
prevents the package from [building].

[#944916]: 
[building]: 


I thought that file doc/asymptote.sty was generated from
doc/asy-latex.dtx ...
However, for reasons I am not sure I understand, I see that
doc/asymptote.sty is also committed to the git repository.
And it still [includes] the line:

  \RequirePackage[space]{grffile}

[includes]: 


I don't fully understand why the invocations of ../asy do not
use the just re-generated doc/asymptote.sty ...

Oh well, I am sure you have already figured out what's wrong!
Please fix it.

Bye and thanks for your time and dedication!   :-)

Bug#944978: pandoc: fails to convert horizontal rules from markdown to PDF (through LaTeX)

[Francesco Poli (wintermute)]

Package: pandoc
Version: 2.5-2+b1
Severity: important

Hello!

I've just encountered a new issue with pandoc.

Since the last upgrade of texlive-* packages
(2019.20190930-1 -> 2019.20191112-1), pandoc is no longer able to
produce a PDF file (through LaTeX) from a markdown file including
horizontal rules.

Steps to reproduce:

  $ cat hrule.md
  # Some horizontal rules
  
  --
  *  *  *  *
  __
  $ pandoc hrule.md -o hrule.pdf
  Error producing PDF.
  ! Missing number, treated as zero.
  
 \protect
  l.62 ...enter}\rule{0.5\linewidth}{\linethickness}


It seems that pdflatex does not like the LaTeX code generated by
pandoc:

  $ pandoc hrule.md -o hrule.tex
  $ grep rule hrule.tex
  \hypertarget{some-horizontal-rules}{%
  \section{Some horizontal rules}\label{some-horizontal-rules}}
  \begin{center}\rule{0.5\linewidth}{\linethickness}\end{center}
  \begin{center}\rule{0.5\linewidth}{\linethickness}\end{center}
  \begin{center}\rule{0.5\linewidth}{\linethickness}\end{center}
  $ texfot pdflatex hrule.tex
  /usr/bin/texfot: invoking: pdflatex hrule.tex
  This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) 
(preloaded format=pdflatex)
  ! Missing number, treated as zero.
  
  l.62 ...enter}\rule{0.5\linewidth}{\linethickness}
  ! Emergency stop.
  
  l.62 ...enter}\rule{0.5\linewidth}{\linethickness}
  !  ==> Fatal error occurred, no output PDF file produced!
  Transcript written on hrule.log.
  

Please fix this bug and/or forward my bug report upstream.
Thanks for your time.

Bye!


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

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

Versions of packages pandoc depends on:
ii  libatomic1   9.2.1-19
ii  libc62.29-3
ii  libffi6  3.2.1-9
ii  libgmp10 2:6.1.2+dfsg-4
ii  libpcre3 2:8.39-12+b1
ii  pandoc-data  2.5-2
ii  zlib1g   1:1.2.11.dfsg-1+b1

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  context
pn  ghc
pn  groff  
pn  libjs-mathjax  
ii  librsvg2-bin   2.44.14-1
pn  node-katex 
pn  nodejs 
ii  pandoc-citeproc0.15.0.1-1+b1
ii  perl   5.30.0-9
pn  php
ii  python 2.7.17-1
pn  r-base-core
ii  ruby   1:2.5.2
ii  texlive-latex-extra2019.20191112-1
ii  texlive-latex-recommended  2019.20191112-1
pn  texlive-luatex 
ii  texlive-xetex  2019.20191112-1
pn  wkhtmltopdf

-- no debconf information

Bug#944693: mailavenger: license incompatibility between 4-clause BSD and GPL

[Francesco Poli (wintermute)]

Package: mailavenger
Version: 0.8.5-2
Severity: serious
Justification: Policy 2.2.1

Hello,
I [noticed] that package mailavenger includes some files which are
derived from code originally released under the terms of the
4-clause BSD license, but their modifications are released under
the terms of the GNU GPL v2 or later, or anyway the files are part
of a whole released under the terms of the GNU GPL v3 or later.

[noticed]: 


The third clause in the 4-clause BSD license (the so-called "obnoxious
advertising clause") is incompatible with both the GNU GPL v2 and the
GNU GPL v3, as [stated] on the FSF license list.

[stated]: 

I believe this makes the package undistributable as is, hence
the "serious" severity of the bug report.


Luckily, the issue could be relatively easy to address.

As far as [libasync/convertint.C] and [libasync/suio_vuprintf.C]
are concerned, the parts covered by the 4-clause BSD license
are copyrighted by the The Regents of the University of California.
I think their general [re-licensing] applies, so the advertising
clause may be dropped: the code is effectively re-licensed under
the terms of the 3-clause BSD license (which is GPL-compatible!).

[libasync/convertint.C]: 

[libasync/suio_vuprintf.C]: 

[re-licensing]: 

As far as [libasync/getopt_long.c] and [util/getopt_long.c]
are concerned, the parts covered by the 4-clause BSD license
are copyrighted by the The NetBSD Foundation, Inc.
As far as I can tell, [NetBSD switched] to the 2-clause BSD license.
I am not 100 % sure this implies that any file copyrighted by
NetBSD Foundation under the 4-clause BSD license may now be effectively
considered as under the 2-clause BSD license (and thus
GPL-compatible!), but it may be worth getting in touch with
the Foundation and asking... I recommend doing so, in order to
get confirmation.

[libasync/getopt_long.c]: 

[util/getopt_long.c]: 

[NetBSD switched]: 


Please fix these issues.
Thanks for your time.

Bye!

Bug#944571: mmdebstrap: the license is not the actual Expat license

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 0.5.1-2
Severity: normal

Hello!
I've just noticed that the mmdebstrap package [claims] to be released
under the terms of the Expat license, but this is not really the
case, since the license text (in both the debian/copyright file
and the upstream source code) lacks an important part, namely
the disclaimer of warranty and limitation of liability (the part
in upper case)!
Please compare with the canonical [Expat] license text.

[claims]: 

[Expat]: 

The disclaimer of warranty and limitation of liability are important
(above all, they protect the authors and copyright holders): I would
strongly recommend adding them as soon as possible, thus effectively
changing the license of mmdebstrap (this can be easily done, as long
as there's only one copyright holder).

Please fix this issue.
Thanks for your time!


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

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

Versions of packages mmdebstrap depends on:
ii  apt   1.8.4
ii  perl  5.30.0-9
ii  perl-doc  5.30.0-9

Versions of packages mmdebstrap recommends:
ii  arch-test   0.16-2
ii  fakechroot  2.19-3.2
ii  fakeroot1.24-1
ii  mount   2.34-0.1
ii  uidmap  1:4.7-2

Versions of packages mmdebstrap suggests:
pn  binfmt-support
ii  dpkg-dev  1.19.7
pn  proot 
pn  qemu-user 
pn  qemu-user-static  

-- no debconf information

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 0.5.1-2
Severity: wishlist

Hello and thanks for developing/packaging this tool!

I wonder whether it can be used to create (without superuser privileges!)
a QEMU/KVM image.
I am especially interested in QEMU/KVM images suitable as autopkgtest
testbeds (autopkgtest-virt-qemu), but the feature could perhaps be
useful for building other minimal Debian base QEMU/KVM images as well...

As you most probably know, autopkgtest-build-qemu uses vmdb2 under the
hood, and vmdb2 [requires] to be run as root. I wonder whether mmdebstrap
can be used in stead of vmdb2, in order to lift the superuser privilege
requirement.

[requires]: 

Could this feature be implemented? It would really be awesome to have
a tool that allows a regular user to create a QEMU/KVM minimal Debian
image...

Please let me know your thoughts!
Thanks for your time and patience.
Bye.

Bug#944467: virt-manager: should the debian/copyright file be updated?

[Francesco Poli (wintermute)]

Package: virt-manager
Version: 1:2.2.1-2
Severity: important

Hello and thanks for maintaining this package in Debian.

While looking at its debian/copyright file, I noticed that it states,
in part:

[...]
| help/:
| 
| Copyright 2007 Red Hat Inc., and Hugh Brock
| 
| Permission is granted to copy, distribute and/or modify this
| document under the terms of the GNU Free Documentation
| License (GFDL), Version 1.1 or any later version published
| by the Free Software Foundation with no Invariant Sections,
| no Front-Cover Texts, and no Back-Cover Texts.
| 
| On Ubuntu / Debian GNU/Linux systems, the complete text of the GNU Free
| Documentation License can be found in `/usr/share/common-licenses/GFDL'.

However, I fail to find any trace of this help/ directory or of
any GFDL-licensed material in the [source] package.

[source]: 


Maybe I looked in the wrong places, hence I am not sure, but I
am beginning to suspect that such material is no longer present
in the package. Should the debian/copyright file be perhaps updated
so that it reflects the current licensing status of the package?

Please note that this bug (if confirmed) could be seen as a violation
of a "must" directive of Debian Policy (section [2.3]), and hence
the severity of the bug report should probably be "serious".
Nonetheless, I chose "important", as I am not sure about the actual
presence of the bug...

[2.3]: 

Please let me know and/or fix the bug.
Thanks for your time!

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Francesco Poli (wintermute)]

Package: autopkgtest
Version: 5.11
Severity: wishlist

Hello and thanks for maintaining autopkgtest!

I wanted to give the QEMU/KVM testbed a try. Hence I tried to create
a VM image by using autopkgtest-build-qemu. Its man page states:

[...]
|  Note that you need to call this as root.
[...]

And indeed the command

  $ autopkgtest-build-qemu unstable ~/var/cache/autopkgtest/sid.img

fails, when issued by a regular user, as it cannot even find parted
in the search PATH.

I guess this is because of vmdb2, which requires superuser privileges.
But why?
Is there any hope to improve vmdb2 or to use another tool, in order
to create a KVM testbed without requiring superuser privileges?



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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.8.4
ii  libdpkg-perl1.19.7
ii  procps  2:3.3.15-2+b1
ii  python3 3.7.5-1
ii  python3-debian  0.1.36

Versions of packages autopkgtest recommends:
ii  autodep8  0.19

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  0~20190828.37eef910-3
ii  qemu-efi-aarch64  0~20190828.37eef910-3
ii  qemu-efi-arm  0~20190828.37eef910-3
ii  qemu-system   1:4.1-1+b4
ii  qemu-utils1:4.1-1+b4
pn  schroot   
ii  vmdb2 0.13.2+git20190215-1

-- no debconf information

Bug#942224: asymptote: VIM addon cannot be managed with vim-addons and fails to enable syntax highlighting

[Francesco Poli (wintermute)]

Package: asymptote
Version: 2.53-1
Severity: normal
Tags: patch

Hello,
thanks for maintaining Asymptote in Debian!

I am giving it a try, but I wanted to see syntax highlighting in VIM.
It seems to me that a VIM addon is shipped in the package:

  $ dpkg -L asymptote | grep vim
  /usr/share/vim
  /usr/share/vim/addons
  /usr/share/vim/addons/ftdetect
  /usr/share/vim/addons/ftdetect/asy_filetype.vim
  /usr/share/vim/addons/ftplugin
  /usr/share/vim/addons/ftplugin/asy.vim

But there seem to be two issues: there's no registry file (hence
vim-addons does not find the addon and cannot manage it) and
the syntax file is placed in ftplugin/ (which looks wrong to me).

In order to enable VIM support for Asymptote I had to prepare
the following file:

  $ cat asymptote.yaml
  addon: asymptote
  description: "easier editing of Asymptote .asy files"
  files:
- syntax/asy.vim
- ftdetect/asy_filetype.vim

and to issue the following commands (as root):

  # mv /usr/share/vim/addons/ftplugin/asy.vim /usr/share/vim/addons/syntax/
  # cp asymptote.yaml /usr/share/vim/registry/
  # chown root:root /usr/share/vim/registry/asymptote.yaml
  # chmod 644 /usr/share/vim/registry/asymptote.yaml

After, I was finally able to manage the addon for my regular user
with:

  $ vim-addons install asymptote

which automatically set up the following symlinks:

  ~/.vim/syntax/asy.vim -> /usr/share/vim/addons/syntax/asy.vim
  ~/.vim/ftdetect/asy_filetype.vim -> 
/usr/share/vim/addons/ftdetect/asy_filetype.vim

Now, when I open a .asy file, VIM automatically enables the appropriate
syntax highlighting.


Please add file asymptote.yaml to package asymptote (so that it
is installed to /usr/share/vim/registry/asymptote.yaml )
and change file debian/asymptote.install so that file asy.vim
is installed to /usr/share/vim/addons/syntax/ (and not to
ftplugin/ ...).

Thanks for your time!
Bye.


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

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

Versions of packages asymptote depends on:
ii  freeglut32.8.1-3+b1
ii  ghostscript  9.27~dfsg-3.1
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b1
ii  install-info 6.6.0.dfsg.1-2
ii  libc62.29-2
ii  libfftw3-double3 3.3.8-2
ii  libgc1c2 1:7.6.4-0.4
ii  libgcc1  1:9.2.1-8
ii  libgl1   1.1.0-1+b1
ii  libglew2.1   2.1.0-4+b1
ii  libgsl23 2.5+dfsg-6+b1
ii  libreadline8 8.0-3
ii  libsigsegv2  2.12-2
ii  libstdc++6   9.2.1-8
ii  libtinfo66.1+20190803-1
ii  python3  3.7.5-1
ii  tex-common   6.12
ii  texlive-binaries 2019.20190605.51237-3
ii  texlive-latex-base   2019.20190930-1
ii  texlive-plain-generic2019.20190930-2
ii  texlive-pstricks 2019.20190930-2
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages asymptote recommends:
ii  asymptote-doc  2.53-1

Versions of packages asymptote suggests:
ii  asymptote-x11  2.53-1

-- no debconf information

Bug#942203: postbooks: fails to comply with the DFSG

[Francesco Poli (wintermute)]

Package: postbooks
Version: 4.11.3-2
Severity: serious
Justification: Policy 2.2.1

Dear xTuple Maintainers,
I noticed that this package is in Debian main and is [released] under
the terms of the Common Public Attribution License (CPAL).

[released]: 


However, software solely released under the terms of the CPAL [fails]
to comply with the DFSG, as [discussed] in 2007 on the debian-legal
mailing list.

[fails]: 

[discussed]: 

Please persuade the upstream copyright holders to switch to a
clearly acceptable license, such as the GNU LGPL v2.1, for instance.

Otherwise, please move the package to the non-free archive, or remove
it from Debian altogether.

Thanks for your time.
Bye!

Bug#941842: RFP: vimoutliner -- script for building an outline editor on top of Vim

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vimoutliner
  Version : 0.4.0 (or some more recent git commit...)
  Upstream Author : Steve Litt ,
Noel Henson 
* URL : https://github.com/vimoutliner/vimoutliner
* License : mostly GPL-2 with some scripts under GPL-3
and some under BSD-3-clause
  Programming Lang: Vim
(+ Perl, Python, Ruby, AWK, Javascript for
 auxiliary scripts)
  Description : script for building an outline editor on top of Vim

 Vimoutliner provides commands for using the Vim text editor as an
 outline editor, to organize text hierarchically into discrete
 sections.


This package is really useful (I use it on a daily basis to manage
todo lists and the like...).
It has been [in Debian] for a long time, but it has been recently
[removed] from unstable and testing. I would be really really grateful
to anyone who volunteers to reintroduce it into Debian!

[in Debian]: 
[removed]: 


The reasons for the removal are listed in the removal page.
In the following, I comment each of them:

 * last MU in 2009
   → OK, this package (like any other!) needs to be properly maintained.
 At least, it should be kept up-to-date with respect to upstream
 releases... I hope whoever volunteers to reintroduce it into Debian
 is willing to commit.

 * last 3 uploads are NMUs
   → Likewise, bug reports should be dealt with, of course. From a quick
 look at the BTS, it looks like the package does not receive a great
 number of bug reports, anyway...

 * last upstream release in 2014
   → Upstream does not release too often, which can mean less effort
 is needed on the Debian package maintainer's side... The git
 repository on github seems to anyway receive updates (in the form
 of commits) from time to time, so I would not call this project
 "dead upstream", just "relaxed upstream"...

 * python2-only
   → This is the main issue to be fixed, as far as I can see. Upstream
 needs to be persuaded to switch from Python2 to Python3. But the
 good news is that Python seems to be used only for some auxiliary
 converter scripts (just one in package version 0.3.4+pristine-9.3
 included in Debian buster, some more in the latest upstream code
 on github): these converter scripts are not essential for the
 core functionality of the package and may even be temporarily
 excluded from the Debian package, until ported to Python3...

 * low popcon
   → This should not be in itself a reason to remove a package from
 Debian, in my humble opinion. Just an aggravating factor, so
 to speak...

I really hope that someone will soon step in and reintroduce the
package into Debian.
Many thanks to anyone willing to do so!

Bug#935913: gle-graphics: qgle segfaults when modifying text strings

[Francesco Poli (wintermute)]

Package: gle-graphics
Version: 4.2.5-7+b1
Severity: normal

Hello again!

I found a reproducible segfault in gle-graphics:

  0) start the GUI

 $ qgle

  1) click on "New" in the toolbar

  2) accept the default size by clicking on "OK" in the dialog window

  3) click on "Edit Mode" in the toolbar

  4) click on "Text Tool" in the sidebar

  5) click somewhere on the canvas: the ``X'' string appears

  6) click on the "Pointer Tool" in the sidebar

  7) click on the ``X'' string on the canvas

  8) in the Properties sidepane, double-click on the Value of the
 "Text" Property

  9) enter another string (such as ``foo'') and press [Enter]
 on the keyboard

If you manage to get here, you should see an application crash
with the following output in the terminal:

  Script:
  size 12.0 12.0
  
  GLE 4.2.5[gle-GjwQeU.gle]-C-R-[gle-3XcUnT][.eps]
  GLE 4.2.5[gle-GjwQeU.gle]-C-R-[gle-sXinOo][.eps]
  Segmentation fault

and the following error in /var/log/kern.log:

  traps: qgle[4876] general protection fault ip:7f3a56129a4f sp:7ffcb0605670 
error:0 in libgs.so.9.27[7f3a55ee+357000]


Please note that the segfault may even happen at an earlier step...


Please investigate and fix the bug and/or forward my report upstream,
as appropriate.

Thanks for your time!
Bye.


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

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

Versions of packages gle-graphics depends on:
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libgcc1 1:9.2.1-4
ii  libgl1  1.1.0-1+b1
ii  libglib2.0-02.60.6-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libncurses6 6.1+20190803-1
ii  libpng16-16 1.6.37-1
ii  libpoppler-glib80.71.0-5+b1
ii  libqt4-network  4:4.8.7+dfsg-19
ii  libqt4-opengl   4:4.8.7+dfsg-19
ii  libqtcore4  4:4.8.7+dfsg-19
ii  libqtgui4   4:4.8.7+dfsg-19
ii  libstdc++6  9.2.1-4
ii  libtiff54.0.10+git190818-1
ii  libtinfo6   6.1+20190803-1
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages gle-graphics recommends:
pn  gle-graphics-doc  
ii  libgs99.27~dfsg-3.1

gle-graphics suggests no packages.

-- no debconf information

Bug#935720: gle-graphics: needs manual search for libgs.so

[Francesco Poli (wintermute)]

Package: gle-graphics
Version: 4.2.5-7+b1
Severity: normal

Hello,
I am giving gle-graphics a try.

As soon as I start the GUI

  $ qgle

the program says it cannot find libgs.so: I have to manually tell it
to look at /usr/lib/x86_64-linux-gnu/libgs.so.9

I think this should fixed, so that the Debian package knows
where to find libgs.so out of the box...

Please fix this packaging bug.

Thanks for your time!
Bye.


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

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

Versions of packages gle-graphics depends on:
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libgcc1 1:9.2.1-1
ii  libgl1  1.1.0-1+b1
ii  libglib2.0-02.60.6-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libncurses6 6.1+20190803-1
ii  libpng16-16 1.6.37-1
ii  libpoppler-glib80.71.0-5+b1
ii  libqt4-network  4:4.8.7+dfsg-19
ii  libqt4-opengl   4:4.8.7+dfsg-19
ii  libqtcore4  4:4.8.7+dfsg-19
ii  libqtgui4   4:4.8.7+dfsg-19
ii  libstdc++6  9.2.1-1
ii  libtiff54.0.10+git190818-1
ii  libtinfo6   6.1+20190803-1
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages gle-graphics recommends:
pn  gle-graphics-doc  
ii  libgs99.27~dfsg-3.1

gle-graphics suggests no packages.

-- no debconf information

Bug#933791: gnupg: please document the consequences of not accepting third-party certifications from keyservers

[Francesco Poli (wintermute)]

Package: gnupg
Version: 2.2.17-3
Severity: important

Hello!

After upgrading gnupg to version 2.2.17-3, I noticed that its
NEWS.Debian.gz file announces a default behavior change:

| Upstream GnuPG now defaults to not accepting third-party certifications
| from the keyserver network.  Given that the SKS keyserver network is
| under attack via certificate flooding, and third-party certifications
| will not be accepted anyway, we now ship with the more tightly-constrained
| and abuse-resistant system hkps://keys.openpgp.org as the default
| keyserver.
|
[...]

Hence, if I understand correctly, gpg now only pulls self-signatures
from keyservers (unless explicitly configured to do otherwise).
Moreover, Debian packaged gpg now uses an isolated keyserver, by
default.

I am aware of the certificate flooding attack that's currently going
on, since I read some blog articles about it and took a look at
some [bug] [reports]. As a consequence, I really appreciate all
the attempts to mitigate and/or solve the issue, as I myself suffered
from significant slow downs, while refreshing keys in my pubring.

[bug]: 
[reports]: 

However, I am a bit puzzled by this specific strategy to mitigate
the issue.
I mean: it's not clear to me how the web of trust is going to work,
from now on.

Only pulling self-signatures from keyservers means I will no longer
benefit from indirect trust paths (I signed Bob's key, Bob signed
Alice's key, hence I can indirectly trust Alice's key, although
I have not yet met Alice personally). Right?
I can only trust keys of people I had the opportunity to meet
personally.
Or am I completely off track?

Moreover, the usual recommendation after an identity and key fingerprint
verification (at a key signing party or otherwise), is to sign Bob's
key and then send the signed key to the Bob's e-mail address, in an
encrypted message: Bob will send the signature to the keyserver network,
only if he is in control of the secret key and if he actually wants the
new signature to be disclosed to the public.
This is the default procedure implemented in caff, isn't it?

Following this procedure, I do not import my own signature on Bob's key
until Bob decides he wants to publish my signature on the keyserver
network.
But, if gpg only imports self-signatures from the keyservers, I will
not even get my own signature on Bob's key, unless I manually import
it into my pubring.
Am I misunderstanding the whole thing?


Please clarify and/or document these consequences in the gnupg
Debian package, so that users have an opportunity to be informed
and adapt their habits and expectations...


Thanks a lot for your time and dedication!
Bye.


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

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

Versions of packages gnupg depends on:
ii  dirmngr 2.2.17-3
ii  gnupg-l10n  2.2.17-3
ii  gnupg-utils 2.2.17-3
ii  gpg 2.2.17-3
ii  gpg-agent   2.2.17-3
ii  gpg-wks-client  2.2.17-3
ii  gpg-wks-server  2.2.17-3
ii  gpgsm   2.2.17-3
ii  gpgv2.2.17-3

gnupg recommends no packages.

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information

Bug#932246: printer-driver-hpcups: no more printing to a HP LaserJet 1320: stack smashing detected and hpcups crashed on signal 6

[Francesco Poli (wintermute)]

Package: printer-driver-hpcups
Version: 3.18.12+dfsg0-2
Severity: important

Dear Debian Printing Team,
I have a small i386 box (Soekris net5501) running testing (buster before
July the 6th, 2019, now bullseye) and connected to a HP LaserJet 1320
printer via USB cable.

The printer is configured via the following command lines:

  # lpadmin -p lj -E \
-v 'usb://HP/LaserJet%201320%20series?serial=00CNFW522KS9' \
-m drv:///hpijs.drv/hp-laserjet_1320-hpijs.ppd \
-o pdftops-renderer-default=pdftops \
-L local -D "HP LaserJet 1320"
  # lpoptions -p lj -o media=A4 -o sides=two-sided-long-edge
  # lpadmin -d lj

The setup has worked fine until July the 9th (that is to say, even
after the first bullseye package upgrades): during that day,
I printed a PDF file without issues.

After that, I went on upgrading the box for about a week:


[UPGRADE] tzdata:i386 2019a-1 -> 2019b-1

[UPGRADE] chrony:i386 3.4-4 -> 3.5-2
[UPGRADE] dirmngr:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gnupg:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gnupg-l10n:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gnupg-utils:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gnupg2:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpg:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpg-agent:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpg-wks-client:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpg-wks-server:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpgconf:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpgsm:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpgv:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] libnewt0.52:i386 0.52.20-8 -> 0.52.21-1
[UPGRADE] libsystemd0:i386 241-5 -> 241-6
[UPGRADE] libudev1:i386 241-5 -> 241-6
[UPGRADE] nano:i386 3.2-3 -> 4.3-1
[UPGRADE] openssh-client:i386 1:7.9p1-10 -> 1:8.0p1-3
[UPGRADE] openssh-server:i386 1:7.9p1-10 -> 1:8.0p1-3
[UPGRADE] openssh-sftp-server:i386 1:7.9p1-10 -> 1:8.0p1-3
[UPGRADE] udev:i386 241-5 -> 241-6
[UPGRADE] whiptail:i386 0.52.20-8 -> 0.52.21-1

[UPGRADE] libassuan0:i386 2.5.2-1 -> 2.5.3-2
[UPGRADE] libedit2:i386 3.1-20181209-1 -> 3.1-20190324-1
[UPGRADE] libgpg-error0:i386 1.35-1 -> 1.36-2
[UPGRADE] libpci3:i386 1:3.5.2-1 -> 1:3.6.2-2
[UPGRADE] pciutils:i386 1:3.5.2-1 -> 1:3.6.2-2
[UPGRADE] usbutils:i386 1:010-3 -> 1:012-1

[REMOVE, NOT USED] libip4tc0:i386 1.8.2-4
[REMOVE, NOT USED] libip6tc0:i386 1.8.2-4
[INSTALL, DEPENDENCIES] libip4tc2:i386 1.8.3-2
[INSTALL, DEPENDENCIES] libip6tc2:i386 1.8.3-2
[UPGRADE] base-files:i386 10.3 -> 11
[UPGRADE] iptables:i386 1.8.2-4 -> 1.8.3-2
[UPGRADE] libiptc0:i386 1.8.2-4 -> 1.8.3-2
[UPGRADE] libnftnl11:i386 1.1.2-2 -> 1.1.3-2
[UPGRADE] libsystemd0:i386 241-6 -> 241-6+b1
[UPGRADE] libudev1:i386 241-6 -> 241-6+b1
[UPGRADE] libxtables12:i386 1.8.2-4 -> 1.8.3-2
[UPGRADE] login:i386 1:4.5-1.1 -> 1:4.7-1
[UPGRADE] passwd:i386 1:4.5-1.1 -> 1:4.7-1
[UPGRADE] startpar:i386 0.61-1 -> 0.63-1
[UPGRADE] udev:i386 241-6 -> 241-6+b1

[UPGRADE] bzip2:i386 1.0.6-9.1 -> 1.0.6-9.2
[UPGRADE] exim4:i386 4.92-8 -> 4.92-9
[UPGRADE] exim4-base:i386 4.92-8 -> 4.92-9
[UPGRADE] exim4-config:i386 4.92-8 -> 4.92-9
[UPGRADE] exim4-daemon-light:i386 4.92-8 -> 4.92-9
[UPGRADE] info:i386 6.5.0.dfsg.1-4+b1 -> 6.6.0.dfsg.1-2
[UPGRADE] install-info:i386 6.5.0.dfsg.1-4+b1 -> 6.6.0.dfsg.1-2
[UPGRADE] iproute2:i386 4.20.0-2 -> 5.2.0-1
[UPGRADE] libbz2-1.0:i386 1.0.6-9.1 -> 1.0.6-9.2
[UPGRADE] libgnutls-dane0:i386 3.6.7-4 -> 3.6.8-2
[UPGRADE] libgnutls30:i386 3.6.7-4 -> 3.6.8-2
[UPGRADE] manpages:i386 4.16-2 -> 5.01-1
[UPGRADE] rsyslog:i386 8.1901.0-1 -> 8.1907.0-1
[UPGRADE] runit-helper:i386 2.8.6 -> 2.8.13.2


Yesterday, I tried to print a PDF file and I found out that
the hpcups crashed and printing was no longer possible.

Even a simple 

  $ echo hello | lpr

generates a print job that never vanishes:

  $ lpq
  lj is ready
  RankOwner   Job File(s) Total Size
  1st unknown 348 unknown 1024 bytes

but the data seem to never reach the printer and
/var/log/cups/error_log shows the following error messages:


E [16/Jul/2019:23:08:14 +0200] [Job 348] Job stopped due to filter errors; 
please consult the /var/log/cups/error_log file for details.
D [16/Jul/2019:23:08:14 +0200] [Job 348] The following messages were recorded 
from 11:08:01 PM to 11:08:14 PM
D [16/Jul/2019:23:08:14 +0200] [Job 348] Applying default options...
D [16/Jul/2019:23:08:14 +0200] [Job 348] Adding start banner page "none".
D [16/Jul/2019:23:08:14 +0200] [Job 348] Queued on "lj" by "USER".
D [16/Jul/2019:23:08:14 +0200] [Job 348] Auto-typing file...
D [16/Jul/2019:23:08:14 +0200] [Job 348] Request file type is text/plain.
D [16/Jul/2019:23:08:14 +0200] [Job 348] File of type text/plain queued by 
"USER".
D [16/Jul/2019:23:08:14 +0200] [Job 348] Adding end banner page "none".
D [16/Jul/2019:23:08:14 +0200] [Job 348] 

Bug#931951: lintian: False positive: command-in-sbin-has-manpage-in-incorrect-section for symlinks in sbin

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.16.0
Severity: normal

Hello,
I have been bitten by a Lintian check false positive on my package
(apt-listbugs):
command-in-sbin-has-manpage-in-incorrect-section

My package indeed ships "/usr/sbin/apt-listbugs" and the man page
is indeed in section 1 ("/usr/share/man/man1/apt-listbugs.1.gz").

But "/usr/sbin/apt-listbugs" is actually a symlink to
"/usr/bin/apt-listbugs":

  $ ls -altrF /usr/*bin/apt-listbugs
  lrwxrwxrwx 1 root root19 Apr 22 16:23 /usr/sbin/apt-listbugs -> 
../bin/apt-listbugs*
  -rwxr-xr-x 1 root root 22111 Apr 22 16:23 /usr/bin/apt-listbugs*


The reason is that, a long time ago, the package used to only ship
"/usr/sbin/apt-listbugs"; at a certain point, it was decided to move
the program to "/usr/bin/", since some of its operating modes
are useful to non-privileged users, too.
However, a number of users could have created custom scripts which
invoke "/usr/sbin/apt-listbugs": in order to avoid gratuitously
breaking all those scripts, it was decided to keep the program
in both "/usr/sbin" and "/usr/bin", with one path being a symlink to
the other.

I think the Lintian complaint is a false positive. Lintian should
look whether the "/usr/sbin/$file" is actually a symlink (to
"/usr/bin/$file") and refrain from emitting the complaint, if this
is the case.

I hope this bug may be fixed soon.

Thanks for your time.
Bye!


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

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

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

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

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

-- no debconf information

Bug#931580: pbuilder: SOURCE_ONLY_CHANGES=yes fails to work with pdebuild-internal

[Francesco Poli (wintermute)]

Package: pbuilder
Version: 0.230.4
Severity: normal
Tags: patch

Hi!

I read in the [documentation] that [source only uploads] are recommended.
No, it's more than that: since the release of buster, they seem to be
[mandatory] for bullseye.

[documentation]: 
[source only uploads]: 
[mandatory]: 


I tried to set SOURCE_ONLY_CHANGES=yes in my sid chroot configuration
file:

  $ cat ~/.pbuilder/sid.conf
  export HOME=/home/my_user_name
  DISTRIBUTION="sid"
  COMPONENTS="main"
  MIRRORSITE="http://deb.debian.org/debian;
  APTCACHE="${HOME}/var/cache/pbuilder/aptcache/${DISTRIBUTION}/"
  APTCACHEHARDLINK="no"
  AUTOCLEANAPTCACHE="yes"
  BASETGZ="${HOME}/var/cache/pbuilder/${DISTRIBUTION}-base.tgz"
  BUILDPLACE="${HOME}/var/cache/pbuilder/build/"
  BUILDRESULT="${HOME}/var/cache/pbuilder/result/${DISTRIBUTION}/"
  HOOKDIR=""
  DEBBUILDOPTS="-i -I"
  SOURCE_ONLY_CHANGES="yes"
  BINDMOUNTS=""
  USE_PDEBUILD_INTERNAL="yes"
  DEBOOTSTRAPOPTS[0]="--variant=buildd"
  DEBOOTSTRAP="debootstrap"
  EXTRAPACKAGES="gnupg debian-archive-keyring"
  USEPROC="yes"
  USEDEVPTS="yes"
  USEDEVFS="no"
  REMOVEPACKAGES="lilo elilo grub-legacy grub-pc"
  BUILDSOURCEROOTCMD="fakeroot"
  PBUILDERROOTCMD="sudo"
  BUILDUSERID=""
  BUILDUSERNAME="pbuilder"
  export DEBIAN_FRONTEND="noninteractive"
  AUTO_DEBSIGN="yes"
  PKGNAME_LOGFILE="yes"
  PKGNAME_LOGFILE_EXTENSION=".buildlog"
  export debian_chroot="pbuild$$"

but it fails to have any effect.

The fact is that I use pdebuild-internal and the generation of the
source .changes file is not implemented for this operation mode,
as [confirmed] by James Clarke.

[confirmed]: 

The attached patch implements the optional generation of the source
.changes file for pdebuild-internal operation mode.
It also implements the signing of all the generated .changes file
(both the binary and source .changes file, if both were generated;
only one of them, if one was generated).
Please note that, the --no-re-sign option is passed to debsign
from the second invocation on, in order to avoid breaking the
checksums of any previously signed .changes file.
See also bug [#906063], which is related to checksum breaking
(I don't know if my patch also fixes that bug, though...).

[#906063]: 

I hereby release my patch under the same terms as pbuilder itself,
that is to say, under the terms of the GNU GPL v2 or later.


Please apply my patch, so that pdebuild-internal users may generate
source .changes files.

Thanks for your time!
Bye.



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

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

Versions of packages pbuilder depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  debootstrap1.0.114
ii  dpkg-dev   1.19.7

Versions of packages pbuilder recommends:
ii  devscripts  2.19.5
ii  eatmydata   105-7
ii  fakeroot1.23-1
ii  iproute24.20.0-2
ii  net-tools   1.60+git20180626.aebd88e-1
ii  sudo1.8.27-1

Versions of packages pbuilder suggests:
pn  cowdancer   
pn  gdebi-core  

-- debconf information excluded


source_only_for_pdebuild_internal.diff.gz
Description: application/gzip

Bug#931536: aptitude update fails to cope with changed release info

[Francesco Poli (wintermute)]

Package: aptitude
Version: 0.8.11-7
Severity: normal

Hello!

As you know, Debian buster has been released yesterday and the current
Debian testing has just been renamed from 'buster' to 'bullseye'.

Good, but... today I tried to update the repository lists and upgrade
my Debian testing boxes with aptitude:

  # cat /etc/apt/sources.list
  deb http://deb.debian.org/debian testing main
  deb http://deb.debian.org/debian unstable main
  
  deb http://deb.debian.org/debian-security testing-security main
  # aptitude update && aptitude --purge-unused safe-upgrade 
  Get: 1 http://deb.debian.org/debian testing InRelease [87.0 kB]
  Hit http://deb.debian.org/debian unstable InRelease
  Get: 2 http://deb.debian.org/debian-security testing-security InRelease [26.1 
kB]
  Fetched 26.1 kB in 0s (57.2 kB/s)
  E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 
'Codename' value from 'buster' to 'bullseye'
  E: Failed to download some files
  W: Failed to fetch http://deb.debian.org/debian/dists/testing/InRelease: 
  E: Some index files failed to download. They have been ignored, or old ones 
used instead.


OK, it's telling me that the codename has changed, so I have to be
sure I want to continue to use that repository.
This is useful in cases where the user has configured something
like "deb http://deb.debian.org/debian stable main" and does not
want to be caught unprepared by a new stable release.

But for Debian testing, I really want to continue tracking testing
and the codename change is not an actual discontinuity.

I had to do the following:

  # apt update
  Get:1 http://deb.debian.org/debian testing InRelease [87.0 kB]
  Hit:2 http://deb.debian.org/debian unstable InRelease
  E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 
'Codename' value from 'buster' to 'bullseye'
  N: This must be accepted explicitly before updates for this repository can be 
applied. See apt-secure(8) manpage for details.
  Do you want to accept these changes and continue updating from this 
repository? [y/N] y
  Hit:3 http://deb.debian.org/debian-security testing-security InRelease
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  All packages are up to date.

and then resume my usual upgrading procedure:

  # aptitude update && aptitude --purge-unused safe-upgrade
  Hit http://deb.debian.org/debian testing InRelease
  Hit http://deb.debian.org/debian unstable InRelease
  Hit http://deb.debian.org/debian-security testing-security InRelease
  
  No packages will be installed, upgraded, or removed.
  0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  Need to get 0 B of archives. After unpacking 0 B will be used.


I think this is a bug in aptitude: it should interactively ask the user
to explicitly confirm the will to go on with the new codename, like apt
does, and also provide a command line option to do so
("--allow-releaseinfo-change", see the apt-get(8) man page).

Please implement this feature.
Thanks for your time and dedication!

Bye.


-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.11
Compiler: g++ 8.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20181013
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7ffcea27c000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f3eb711a000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f3eb70e)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f3eb70b2000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f3eb70a9000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f3eb6fa3000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f3eb6e81000)
libboost_iostreams.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f3eb6e61000)
libboost_system.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f3eb6e5a000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f3eb6c2e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f3eb6c0d000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f3eb6a89000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f3eb6906000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f3eb68ea000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3eb6729000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f3eb670f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f3eb64f1000)

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

[Francesco Poli (wintermute)]

Package: systemd
Version: 241-3
Severity: normal

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

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

Hence, I began doing some research on the proper way to ship a
systemd timer along with an equivalent cron script (while avoiding
conflicts between the two).
I looked for examples in other packages (such as man-db and
logrotate).
I am starting to get an idea of how to set this up, but some aspects
are still unclear.

My main needs are:

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

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

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

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

[cron jobs]: 

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


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

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

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

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.12.0
Severity: normal

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

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

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

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

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

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

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

[complains]: 

[about]: 


Are these false positives?

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

[code]: 

I have a question: is the following line

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

missing something in the regexp?
Should it be

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

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

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

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

Please clarify.
Thanks for your time!




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

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

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

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

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

-- no debconf information

Bug#924852: pangzero: please implement a way to increase/decrease audio volume inside the game

[Francesco Poli (wintermute)]

Package: pangzero
Version: 1.4.1+git20121103-4
Severity: wishlist

Hello,
thanks for maintaining this nice shooter game in Debian!


There seems to be no way to increase or decrease the audio (sound
and music) volume from inside the game.

This means that, before playing, I have to start alsamixer, set a
suitable Master channel level, then start pangzero (in fullscreen).
Also, after quitting from pangzero, I have to again use alsamixer
in order to set the previous Master channel level (the one that is
suitable for any other application that uses the sound card).

This is inconvenient.
I hope that a couple of volume levels (one for sound and one for music)
may be easily implemented, for instance in the options menu.
These two volume levels should set the amplifications for sound and for
music, without changing alsamixer levels or anything else outside
the game.

Please implement this feature and/or forward this bug report upstream,
as appropriate.

Thanks for your time!
Bye.



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

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

Versions of packages pangzero depends on:
ii  libsdl-perl  2.548-1+b1
ii  perl 5.28.1-4

pangzero recommends no packages.

pangzero suggests no packages.

-- no debconf information

Bug#924766: RFP: webext-uppity -- toolbar button to "go up" on the web

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: webext-uppity
  Version : 2.1
  Upstream Author : arantius https://arantius.com/
* URL : https://github.com/arantius/uppity
* License : Expat
  Programming Lang: JavaScript
  Description : toolbar button to "go up" on the web

Navigate up one level (directory) on the web.  URLs are arranged
in a way similar to a file system, with other well defined pieces.
Uppity will remove an in-page anchor, the querystring,
the file, and the last directory in that order, whichever is first
found.  The keyboard shortcut ALT-Up will also navigate this way.

The toolbar button is controlled like any other toolbar button. Right click on 
your toolbar, choose Customize, and then just drag-and-drop the Uppity button 
to where you like it.




This package may be useful as a replacement for xul-ext-uppity,
which was removed because of the incompatibility with recent Firefox:
https://tracker.debian.org/pkg/uppity
https://tracker.debian.org/news/1015889/removed-158-5-from-unstable/

The rewrite as a WebExtension was mentioned in the bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906869

I hope someone is willing to package the new version.
Thanks for your time!

Bug#923673: fbpanel: documentation seems to be incorrect or out of date (margin vs. xmargin)

[Francesco Poli (wintermute)]

Package: fbpanel
Version: 7.0-4
Severity: normal

Hello!

I finally managed to convince fbpanel to have a width computed as
the screen width minus a fixed length (275 pixels).
The relevant options in ~/.config/fbpanel/default are:

  Global {
  edge = bottom
  allign = right
  xmargin = 275
  widthtype = pixel
  width = 3
  [...]
  }

The widthtype must be "pixel" and the width must be set to a number
greater than any foreseeable screen width.

This is something that I have wanted to obtain for a long time,
because the alternative strategy is rather inconvenient: setting a
fixed width which is manually computed (by me!) as, say, 1325 pixels
(which is 1600 - 275), but has to be different for each distinct
screen resolution!


Why did it take so long for me to do this?

Because I had been trying to play with the margin option, which
had apparently no effect.

The fact is that the documentation (/usr/share/doc/fbpanel/README.gz)
states:

[...]
|* Margin - margin from screen edge for left or right allignment. Legal 
values are numbers.
|  Default is 0.
[...]

However, the program ignores any margin option and reads xmargin
(and ymargin) instead.
I had to dig into the source, in order to figure it out:
see function calculate_width() in panel/misc.c
and function panel_parse_global() in panel/panel.c ...

I guess this is an issue with incorrect (or perhaps out of date)
documentation.

Please fix the documentation and/or forward my bug report upstream,
as appropriate.

Thanks for your time.
Bye!


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

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

Versions of packages fbpanel depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-7
ii  libcairo21.16.0-2
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.3-1
ii  libgtk2.0-0  2.24.32-3
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  librsvg2-common  2.44.10-1
ii  libx11-6 2:1.6.7-1

fbpanel recommends no packages.

Versions of packages fbpanel suggests:
ii  hicolor-icon-theme  0.17-2
ii  menu2.1.47+b1

-- no debconf information

Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log

[Francesco Poli (wintermute)]

Package: chrony
Version: 3.4-2
Severity: important

Hello there!
Thanks for maintaining this useful package.

I've just upgraded to version 3.4-2 and noticed that the daemon failed to
restart, due to the mailonchange directive:

  $ grep -B 1 ^mailonchange /etc/chrony/chrony.conf
  # Warn root.
  mailonchange root@localhost 4.0

After reading /usr/share/doc/chrony/NEWS.Debian.gz , I found out that
the new system call filter (which is now enabled by default) is
incompatible with the mailonchange directive.
This didn't make me especially happy, since that little local mail
message telling me there was a significant time adjustment was nice
to have... But, oh well, I can live without it, so I thought "let's
get rid of it!".

  $ grep mailonchange /etc/chrony/chrony.conf

gives no output, OK.

  # service chrony restart

Everything seems to be fine, but:

  $ ps a | grep chrony
  10686 pts/1S+ 0:00 grep chrony

the daemon is not running!

After a bit of investigation, I found out that the log directive:

  $ grep '^log ' /etc/chrony/chrony.conf
  log tracking measurements statistics

seems to also conflict with the system call filter.

There are two issues with this.
First of all, the NEWS.Debian.gz file does not seem to mention it
(the man page also seems to say nothing about it).
Secondly, with no mailonchange and no log, chrony seems to have become
completely silent: how can I check that it is actually working fine,
if I cannot even see which time servers it is tracking?

Is this a bug or something unavoidable (that should be documented in
the NEWS.Debian.gz file and/or in the man page)?


I have disabled the system call filter for the time being, in order
to enable log (as well as mailonchange):

  $ grep OPTS /etc/default/chrony
  DAEMON_OPTS="-F 0"


Please let me know whether I misunderstood something and/or whether
I am doing something wrong.
Thanks for your time!

Bye.



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

Kernel: Linux 4.19.0-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages chrony depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  iproute2 4.20.0-2
ii  libc62.28-7
ii  libcap2  1:2.25-2
ii  libedit2 3.1-20181209-1
ii  libnettle6   3.4.1-1
ii  libseccomp2  2.3.3-4
ii  lsb-base 10.2018112800
ii  ucf  3.0038+nmu1

chrony recommends no packages.

Versions of packages chrony suggests:
pn  dnsutils 
pn  networkd-dispatcher  

-- Configuration Files:
/etc/default/chrony changed:
DAEMON_OPTS="-F 0"


-- no debconf information

Bug#921228: RFS: apt-listbugs/0.1.28

[Francesco Poli (wintermute)]

Package: sponsorship-requests
Severity: normal

Hello!

Since I have received one late translation update, I thought I could
prepare a new version of the apt-listbugs package (0.1.28):
it is ready to be uploaded to Debian sid.
Could someone please build the package from commit
[18eb13976d33dc6f041255c74e3a8f55047f229b], and sponsor its upload
to unstable?

[18eb13976d33dc6f041255c74e3a8f55047f229b]: 


The only change since the last upload is:

   * updated Japanese translation, thanks to "victory"!


Thank you so much for your patience and helpfulness!
Bye.

Bug#919131: RFS: apt-listbugs/0.1.27

[Francesco Poli (wintermute)]

Package: sponsorship-requests
Severity: normal

Hi!

I have just finished preparing a new version of the apt-listbugs
package (0.1.27): it is ready to be uploaded to Debian sid.
Could someone please build the package from commit
[eb4d507254f84432405d36a8f563226a4f145522], and sponsor its upload
to unstable?

[eb4d507254f84432405d36a8f563226a4f145522]: 


The changes since the last upload are:

  * fixed "New error message /etc/cron.daily/apt-listbugs: logname: no
login name": enhanced logic to better cope with cases where logname
(or whoami) is not able to determine the user login (or effective)
name (Closes: #917059)
  * bumped Standards-Version to 4.3.0: no changes needed
  * updated Spanish translation, thanks to Jonatan Porras!
  * updated Swedish translation, thanks to Martin Bagge! (Closes: #918001)
  * bumped debhelper compatibility version to 12 by using the new method
based on versioned build-dependency on debhelper-compat: no other
changes needed
  * updated Norwegian Bokmål translation, thanks to Hans Fredrik Nordhaug!


Thanks a lot to anyone who will help!
Bye.

Bug#917623: anacron: command logname fails in a cron.daily job run by anacron

[Francesco Poli (wintermute)]

Package: anacron
Version: 2.3-27
Severity: normal

Hello,
I noticed that anacron sets an environment (for running cron.daily jobs,
but probably even weekly and monthly jobs...) where the "logname" command
fails.

I mean: if a cron.daily job invokes the "logname" command, then this
command fails, thus producing the following error message on stderr:

  logname: no login name

The error message (if not caught) is sent via local mail along with
the rest of the cron.daily job output.


It seems that this happens only when anacron is in charge of running
cron.{daily|weekly|monthly} jobs. Without anacron installed, cron
takes care of those jobs, and the "logname" command does not fail.

I think anacron should set an environment where the "logname" command
succeeds.


Thanks for your time!
Bye.


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

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

Versions of packages anacron depends on:
ii  debianutils  4.8.6
ii  libc62.28-2
ii  lsb-base 10.2018112800

Versions of packages anacron recommends:
ii  cron [cron-daemon]   3.0pl1-130
ii  rsyslog [system-log-daemon]  8.40.0-1

Versions of packages anacron suggests:
ii  exim4-daemon-light [mail-transport-agent]  4.91-9
pn  powermgmt-base 

-- no debconf information

Bug#917569: linux-image-4.19.0-1-686: fails to boot on i386 (Soekris net5501) BUG at arch/x86/mm/pat.c:549

[Francesco Poli (wintermute)]

Package: src:linux
Version: 4.19.12-1
Severity: important

Hi!

After upgrading an i386 box (Soekris net5501) running testing (buster),
I found out that the newly migrated Linux kernel fails to boot.

Looking at the boot through the serial console reveals the attached
output, in which I spotted the following line:

  [5.363599] kernel BUG at arch/x86/mm/pat.c:549!

The previous kernel image (4.18.20-2) works with no issues.
I have temporarily altered GRUB_DEFAULT in /etc/default/grub, in order to
force the box to automatically boot that kernel version.

I hope this bug may be fixed soon.
Thanks a lot for any help you may provide!



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

Kernel: Linux 4.18.0-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Loading Linux 4.19.0-1-686 ...
Loading initial ramdisk ...
[0.072516] ACPI BIOS Error (bug): A valid RSDP was not found 
(20180810/tbxfroot-210)
[0.337287] Spectre V2 : Spectre mitigation: LFENCE not serializing, 
switching to generic retpoline
[5.363599] kernel BUG at arch/x86/mm/pat.c:549!
[5.391321] invalid opcode:  [#1] SMP
[5.395287] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.0-1-686 #1 Debian 
4.19.12-1
[5.395287] EIP: reserve_memtype+0x1a0/0x310
[5.395287] Code: ff 75 e4 e8 b2 4a fe ff 8b 4d d0 83 c4 0c 3c 06 0f 95 c0 
0f b6 c0 01 c0 89 45 d4 e9 e5 fe ff ff 8d b4 26 00 00 00 00 8d 76 00 <0f> 0b 8d 
b6 00 00 00 00 83 7d 10 05 0f 84 41 01 00 00 83 7d 10 03
[5.395287] EAX:  EBX: ce0ddef8 ECX:  EDX: 
[5.395287] ESI:  EDI:  EBP: ce0ddeb8 ESP: ce0dde84
[5.395287] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246
[5.395287] CR0: 80050033 CR2:  CR3: 069e8000 CR4: 0090
[5.395287] Call Trace:
[5.395287]  ? walk_mem_res+0x3a/0x50
[5.395287]  ? mm_fault_error.cold.33+0x37/0x37
[5.395287]  __ioremap_caller+0xc1/0x2d0
[5.395287]  ? net5501_init+0x36/0xed
[5.395287]  ? alix_init+0x103/0x103
[5.395287]  ioremap_nocache+0x15/0x20
[5.395287]  ? net5501_init+0x36/0xed
[5.395287]  net5501_init+0x36/0xed
[5.395287]  ? alix_init+0x103/0x103
[5.395287]  do_one_initcall+0x42/0x19a
[5.395287]  ? do_early_param+0x7d/0x7d
[5.395287]  kernel_init_freeable+0x15b/0x1e3
[5.395287]  ? rest_init+0x8a/0x8a
[5.395287]  kernel_init+0xd/0xea
[5.395287]  ret_from_fork+0x2e/0x38
[5.395287] Modules linked in:
[6.123386] ---[ end trace c58e6b4182e68965 ]---
[6.151077] EIP: reserve_memtype+0x1a0/0x310
[6.176655] Code: ff 75 e4 e8 b2 4a fe ff 8b 4d d0 83 c4 0c 3c 06 0f 95 c0 
0f b6 c0 01 c0 89 45 d4 e9 e5 fe ff ff 8d b4 26 00 00 00 00 8d 76 00 <0f> 0b 8d 
b6 00 00 00 00 83 7d 10 05 0f 84 41 01 00 00 83 7d 10 03
[6.289052] EAX:  EBX: ce0ddef8 ECX:  EDX: 
[6.326588] ESI:  EDI:  EBP: ce0ddeb8 ESP: c69ec3bc
[6.364128] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246
[6.404777] CR0: 80050033 CR2:  CR3: 069e8000 CR4: 0090
[6.442406] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[6.442406]
[6.446292] Kernel Offset: 0x500 from 0xc100 (relocation range: 
0xc000-0xd07f)
[6.446292] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[6.446292]  ]---
[7.071650] clocksource: timekeeping watchdog on CPU0: Marking clocksource 
'tsc-early' as unstable because the skew is too large:
[7.141411] clocksource:   'pit' wd_now: eb0e884d 
wd_last: eb0535d3 mask: 
[7.197141] clocksource:   'tsc-early' cs_now: 4c0ed40b9 
cs_last: 49481f99b mask: 
[7.261185] tsc: Marking TSC unstable due to clocksource watchdog
[   55.248323] random: crng init done

Bug#916658: RFS: apt-listbugs/0.1.26

[Francesco Poli (wintermute)]

Package: sponsorship-requests
Severity: normal

Hello everybody!

I prepared a new version of the apt-listbugs package (0.1.26):
it is ready to be uploaded to Debian unstable.
Could someone please build the package from commit
[c04fcb88ed8ba0f87c62d5711f394dd455231754], and sponsor its upload to
sid?

[c04fcb88ed8ba0f87c62d5711f394dd455231754]: 


The changes since the last upload are:

  * fixed "executes xdg-open as root user": implemented a way to drop root
privileges when invoking querybts or a browser, if we can figure out
which regular user became root (via "su -", "sudo", ...) and if
package s6 is installed (Closes: #910122)
  * added xdg-open to the list of possible ways to invoke an appropriate
web browser
  * enhanced interface consistency regarding external program (querybts
and web browser) invocation
  * enhanced error handling consistency regarding external program invocation
  * converted README.Debian into README.md (in markdown syntax) and
improved the document a bit
  * created FAQ.md by taking some parts from README.md
  * updated German translation, thanks to Chris Leick! (Closes: #914703)
  * updated Russian translation, thanks to Sergey Alyoshin! (Closes: #915374)
  * updated Portuguese translation, thanks to Miguel Figueiredo!
(Closes: #915802)
  * updated Italian translation, thanks to Luca Monducci!
  * updated Dutch translation, thanks to Frans Spiesschaert! (Closes: #916365)
  * updated Danish translation, thanks to Morten Bo Johansen! (Closes: #916384)
  * updated French translation, thanks to Jean-Baka Domelevo Entfellner!
(Closes: #916509)


Thank you so much for your time and dedication!
Bye.

Bug#912736: RFS: apt-listbugs/0.1.25

[Francesco Poli (wintermute)]

Package: sponsorship-requests
Severity: normal

Hello everybody,
my usual sponsor has some blocking issues and is currently unable to
upload packages on my behalf.

I prepared a new version of apt-listbugs (0.1.25): it is ready to be
uploaded.
Could someone please build the package from commit
[999e167ed8a45ce97283977ec534657b90d808fe],
and sponsor its upload to sid?

[999e167ed8a45ce97283977ec534657b90d808fe]: 


The changes since the last upload are:

  * updated VCS URLs to new salsa.debian.org locations in debian/control and
debian/copyright files, and in man page, as well
  * updated Homepage field in debian/control to point to the new home on
salsa.debian.org
  * updated Dutch translation, thanks to Frans Spiesschaert! (Closes: #900588)
  * bumped Standards-Version to 4.2.1: no changes needed
  * enhanced dealing with ignore_bugs files containing characters which cannot
be represented in the current locale (this is meant to be a fix for
the old bug #834557)


Thanks for your time and helpfulness!
Bye.

Bug#909693: gpgsm: seems to be dead slow when verifying pkcs7-signatures from within Sylpheed

[Francesco Poli (wintermute)]

Package: gpgsm
Version: 2.2.10-1
Severity: important

Hello!

I installed the gpgsm package, in order to verify pkcs7-signatures
in e-mail messages from within Sylpheed.

The combination seems to work, as it is actually able to verify
a signature, as in:

[application/pkcs7-signature (Valid signature (untrusted key))]
Signature made at $DATE
Valid signature but the key for "CN=$CN,O=$O,L=$L,ST=$ST,C=$C" is not trusted
  aka ""

The problem is: it has always been dead slow in doing so.
And it still is.
I cannot understand why.

While verifying an OpenPGP signature with gpg is definitely fast,
verifying a pkcs7-signature with gpgsm is super slow.
And it is slow again *each and every* time I verify the signature
on the same message.
And it blocks Sylpheed during the wait.


Is there anything I should have configured in order to speed up
gpgsm?
I did search the man page, but nothing looks appropriate to me
(probably out of ignorance!).

Could you please help me?
Thanks for your time and patience.
Bye.


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

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

Versions of packages gpgsm depends on:
ii  gpgconf2.2.10-1
ii  libassuan0 2.5.1-2
ii  libc6  2.27-6
ii  libgcrypt201.8.3-1
ii  libgpg-error0  1.32-1
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-5

Versions of packages gpgsm recommends:
ii  gnupg  2.2.10-1

gpgsm suggests no packages.

-- no debconf information

Bug#909428: systray-mdstat: [regression] fails to correctly handle alpha channel in its own PNG images

[Francesco Poli (wintermute)]

Package: systray-mdstat
Version: 1.1.0-1
Severity: normal

Hello!

Since some recent upgrade of my Debian testing boxes (I think it
happened when I upgraded libgtk3-perl 0.034-1 -> 0.034-2), I have been
experiencing a new bug in systray-mdstat: it seems to be unable to
correctly repaint the transparent parts of its own PNG images (such as
/usr/share/perl5/auto/share/dist/systray-mdstat/harddriveok.png) within
the systray.

The practical effect is that, whatever has appeared (or has been moved)
over the systray leaves a permanent trace in the transparent pixels of
the displayed PNG image.  See the attached screenshot, for a visual
example (you can see the image shown by systray-mdstat in the systray,
along with a small part of the surrounding systray area...).

What used to happen before the above-mentioned upgrade, was that the
transparent part used to be painted with the panel color (the fbpanel
gray color, in my specific case).

I don't know whether this regression is due to some code in
systray-mdstat that needs to be updated, or is caused by a regression
in libgtk3-perl.
Please investigate the bug and fix it and/or reassign the bug report,
as appropriate.

Thanks for your time!
Bye.



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

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

Versions of packages systray-mdstat depends on:
ii  libfile-sharedir-perl  1.116-2
ii  libgtk3-perl   0.034-2
ii  libtry-tiny-perl   0.30-1
ii  perl   5.26.2-7

systray-mdstat recommends no packages.

Versions of packages systray-mdstat suggests:
ii  fbpanel 7.0-4
pn  smart-notifier  

-- no debconf information

Bug#908170: texlive-latex-extra: \documentclass[italian]{europecv} causes "File ended while scanning definition of \ecv@cvofkey"

[Francesco Poli (wintermute)]

Package: texlive-latex-extra
Version: 2018.20180824-1
Severity: normal
Tags: patch


Hello!

With

  \documentclass[helvetica,narrow,italian,
 noflag,logo,totpages,booktabs]{europecv}

I get the following error:

  ! File ended while scanning definition of \ecv@cvofkey.
  
  l.3 \usepackage
  ! Emergency stop.
  
  l.3 \usepackage
  !  ==> Fatal error occurred, no output PDF file produced!

which does not occur, if I use:

  \documentclass[helvetica,narrow,english,
 noflag,logo,totpages,booktabs]{europecv}

By trial and error, I found out that the attached patch fixes (or works
around) the issue.

Is there a better fix, by chance?

Could you please apply my patch (or a better fix) and/or
forward my bug report upstream, as appropriate?

Thanks for your time and helpfulness!
Bye.


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1592 Aug 29 21:58 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Aug 17  2017 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 24 04:11 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 24 04:11 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug 23  2017 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Aug 24 04:11 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Aug 24 04:11 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3957 Aug 29 21:57 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Oct 14  2015 mktex.cnf
-rw-r--r-- 1 root root 475 Aug 23  2017 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.91-1
ii  python 2.7.15-3
ii  tex-common 6.09
ii  texlive-base   2018.20180824-1
ii  texlive-binaries   2018.20180824.48463-1
ii  texlive-latex-recommended  2018.20180824-1
ii  texlive-pictures   2018.20180824-1

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2018.20180824-1
ii  texlive-plain-generic  2018.20180824-1

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles
ii  libfile-which-perl  1.22-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments 2.2.0+dfsg-1
ii  texlive-latex-extra-doc 2018.20180824-1

Versions of packages tex-common depends on:
ii  dpkg  1.19.0.5+b1
ii  ucf   3.0038

Versions of packages tex-common 

Bug#907740: webext-debianbuttons: significantly less convenient than the old xul-ext-debianbuttons

[Francesco Poli (wintermute)]

Package: webext-debianbuttons
Version: 2.1-2
Severity: important

Hello!
Thanks for maintaining this firefox extension in Debian (along with
other useful ones)!

I've just upgraded package xul-ext-debianbuttons on my Debian testing
box.  It became a transitional package, pulling in package
webext-debianbuttons as a dependency.
Good.

Unfortunately, though, when starting firefox-esr, I can no longer
see my usual debian-buttons.
I was hoping to see my previous debian-button configuration
transparently migrated to the new version, but that does not
seem to be the case.

Apparently there is a single Debian swirl button, where
 * I have to click in order to get a menu
 * then I have to paste the clipboard content into a text field
 * finally I have to click or right-click on one of the enabled options

All this seems to be extremely slow, compared with the old "select
some text and click on one button" feature of the previous
package xul-ext-debianbuttons version...

Hence, I thought "OK, let's reconfigure it to meet my preferences...".
But, no, it seems I can't.
The extension (which now seems to be called "Debian queries")
does not appear to be configurable.

Is there any chance to get the old-style buttons again?
Please let me know.

Thanks for your time.
Bye!


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

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

Versions of packages webext-debianbuttons depends on:
ii  firefox-esr  52.9.0esr-1

webext-debianbuttons recommends no packages.

webext-debianbuttons suggests no packages.

-- no debconf information

Bug#905865: armagetronad: sometimes fails to start, often fails to actually quit

[Francesco Poli (wintermute)]

Package: armagetronad
Version: 0.2.8.3.4-2
Severity: normal

Hello!

I've just installed armagetronad: thanks for maintaining it in Debian!
I am experiencing a weird behavior, though.

The first time I started the game from an xterm, I obtained the following
output:

  A$ armagetronad
  Trying to start sound. Just restart Armagetron Advanced in case of crash.

and then nothing happened for a long time. The process armagetronad.real
was running, but nothing was apparently happening.
Hitting [Ctrl+C] was useless. Until I decided to kill the process from
another xterm:

  B$ killall -KILL armagetronad.real 

Of course, the effect on the first xterm was:

  ^C^C^C^CKilled

At the second try, I obtained the same output:

  A$ armagetronad
  Trying to start sound. Just restart Armagetron Advanced in case of crash.

but, this time, the game started and was playable (and enjoyable!).
The weird behavior is that, after playing for a while, I selected
"Exit game" and I was brought back to my desktop session, as expected,
but the process did not actually exit and I failed to get my prompt back
on the xterm. Until I had to kill the process from another xterm:

  B$ killall -KILL armagetronad.real 

Once again, the effect on the first xterm was:

  Killed

On the third try, I got no output regarding sound, but I again had to kill
the process, after exiting from the game:

  A$ armagetronad
  Killed

On the fourth and fifth tries, the game again failed to start:

  A$ armagetronad
  ^CKilled

On the sixth try, the game started and exited without issues:

  A$ armagetronad
  A$

On the seventh and eighth tries, the game again failed to start:

  A$ armagetronad
  ^CKilled

On the ninth try, the game again failed to quit, but this time I could
kill it with [Ctrl+C]:

  A$ armagetronad
  ^C

And so forth...


Please investigate the issues and fix this bug.
Thanks for your time, bye!


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

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

Versions of packages armagetronad depends on:
ii  armagetronad-common 0.2.8.3.4-2
ii  libc6   2.27-5
ii  libgcc1 1:8.2.0-3
ii  libgl1  1.0.0+git20180308-3
ii  libgl1-mesa-glx 18.1.5-1
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libpng16-16 1.6.34-2
ii  libsdl-image1.2 1.2.12-8
ii  libsdl1.2debian 1.2.15+dfsg2-1
ii  libstdc++6  8.2.0-3
ii  libxml2 2.9.4+dfsg1-7+b1

armagetronad recommends no packages.

armagetronad suggests no packages.

-- no debconf information

Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?

[Francesco Poli (wintermute)]

Package: jackd2
Version: 1.9.12~dfsg-2
Severity: important

Hello,
a couple of weeks ago I began experiencing an awkward behavior of jackd
on one of my Debian testing machines (I run jackd with almost identical
configuration on two other boxes, without issues).

Basically, jackd no longer wants to start at the beginning of my
X session and also refuses to start, when I try to start it manually
from an xterm with:

  $ jackd --realtime -d alsa --device hw:0 \
--softmode --hwmeter --rate 44100 &

The output I get is:

  jackdmp 1.9.12
  Copyright 2001-2005 Paul Davis and others.
  Copyright 2004-2016 Grame.
  Copyright 2016-2017 Filipe Coelho.
  jackdmp comes with ABSOLUTELY NO WARRANTY
  This is free software, and you are welcome to redistribute it
  under certain conditions; see the file COPYING for details
  no message buffer overruns
  no message buffer overruns
  no message buffer overruns
  JACK server starting in realtime mode with priority 10
  self-connect-mode is "Don't restrict self connect requests"
  audio_reservation_init
  Acquire audio card Audio0
  creating alsa driver ... 
hw:0|hw:0|1024|2|44100|0|0|nomon|hwmeter|soft-mode|32bit
  
  
  ATTENTION: The playback device "hw:0" is already in use. Please stop the 
application using it and run JACK again
  Released audio card Audio0
  audio_reservation_finish
  Cannot initialize driver
  JackServer::Open failed with -1
  Failed to open server
  
  [1]+  Exit 255jackd --realtime -d alsa --device hw:0 
--softmode --hwmeter --rate 44100


OK, so there's another application which is using hw:0 and won't
release the resource.

The problem is: which application is using hw:0 ?!?
jackd does not tell me!

The weird thing is that I searched the web and found some jackd
output transcripts where jackd actually tells the user which
application is using the soundcard with something like:

  ATTENTION: The playback device "hw:0" is already in use. The following
  applications are using your soundcard(s) so you should check them and stop
  them as necessary before trying to start JACK again:
  
  $APPLICATION (process ID $PID)

See for instance http://www.tedfelix.com/linux/linux-midi.html

Why my jackd does not tell me which application is using hw:0 ?!?
How can I figure out which application is getting in the way?


Please help me to investigate and please improve the usefulness of
jackd error messages.


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


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

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

Versions of packages jackd2 depends on:
ii  coreutils  8.28-1
ii  debconf [debconf-2.0]  1.5.69
ii  libasound2 1.1.6-1
ii  libc6  2.27-5
ii  libdbus-1-31.12.10-1
ii  libexpat1  2.2.5-3
ii  libgcc11:8.2.0-1
ii  libjack-jackd2-0   1.9.12~dfsg-2
ii  libopus0   1.3~beta+20180518-1
ii  libreadline7   7.0-5
ii  libsamplerate0 0.1.9-2
ii  libsndfile11.0.28-4
ii  libstdc++6 8.2.0-1
ii  python 2.7.15-3
ii  python-dbus1.2.8-2+b1

Versions of packages jackd2 recommends:
ii  jackd2-firewire  1.9.12~dfsg-2
ii  libpam-modules   1.1.8-3.7
ii  qjackctl 0.5.0-1

Versions of packages jackd2 suggests:
pn  jack-tools   
pn  meterbridge  

-- debconf information:
* jackd/tweak_rt_limits: true

Bug#905304: security-tracker: DSA-4259-1 vs. tracker

[Francesco Poli (wintermute)]

Package: security-tracker
Severity: normal

Hello!

According to [DSA-4259-1], ruby2.3/2.3.3-1+deb9u3 fixes a number of
vulnerabilities, among which CVE-2017-17405, CVE-2017-17742,
CVE-2017-17790, and CVE-2018-6914.

However, the tracker pages for [CVE-2017-17405], [CVE-2017-17742],
[CVE-2017-17790], and [CVE-2018-6914] seem to disagree.

Is the tracker wrong?
Please update the tracker data, then.

Is the DSA wrong?
Please clarify (I searched in the tracker commit history on Salsa,
but I failed to find any explicit explanation about this
discrepancy...).

Thanks for your time!

[DSA-4259-1]: 

[CVE-2017-17405]: 
[CVE-2017-17742]: 
[CVE-2017-17790]: 
[CVE-2018-6914]:  

Bug#903816: security-tracker: CVE-2017-17689 vs. tracker

[Francesco Poli (wintermute)]

Package: security-tracker
Severity: normal

Hello everyone!

According to [DSA-4244-1] thunderbird/1:52.9.1-1~deb9u1 fixes
CVE-2017-17689 in stretch (security), among other vulnerabilities.

However the tracker page for [CVE-2017-17689] seems to disagree,
while, on the other hand, referencing bug [#898631], which is claimed
to be fixed in oldstable, stable, testing, and unstable.

But please note that bug [#898631] does not mention CVE-2017-17689
at all!

Oh what a headache!
Which is wrong and which is right?

Could you please clarify and update the tracker data, if needed?

Thanks for your time!

[DSA-4244-1]: 

[CVE-2017-17689]: 
[#898631]: 

Bug#902026: systemd: "systemctl start systemd-timesyncd.service" kills chrony

[Francesco Poli (wintermute)]

Package: systemd
Version: 238-5
Severity: normal

Dear systemd Debian package maintainers,
it seems I found out a regression of systemd-timesyncd.

It used to refuse to start, whenever other NTP clients (such as chrony)
were used.
If I read bug #805927 correctly, now this is accomplished with
other NTP clients shipping service files with an appropriate
"Conflicts=systemd-timesyncd.service" directive.
However, this does not seem to work as expected.

Please let me explain.

I have chrony running on my system, and its service file seems
to satisfy the above requirement:

  $ cat /lib/systemd/system/chrony.service
  [Unit]
  Description=chrony, an NTP client/server
  Documentation=man:chronyd(8) man:chronyc(1) man:chrony.conf(5)
  Conflicts=systemd-timesyncd.service openntpd.service ntp.service
  After=network.target
  ConditionCapability=CAP_SYS_TIME
  
  [Service]
  Type=forking
  PIDFile=/run/chronyd.pid
  EnvironmentFile=-/etc/default/chrony
  ExecStart=/usr/sbin/chronyd $DAEMON_OPTS
  ExecStartPost=-/usr/lib/chrony/chrony-helper update-daemon
  PrivateTmp=yes
  ProtectHome=yes
  ProtectSystem=full
  
  [Install]
  Alias=chronyd.service
  WantedBy=multi-user.target


But, as soon as I issue:

  # service systemd-timesyncd start

chrony dies and systemd-timesyncd starts.

I thought that systemd-timesyncd should refrain from starting and
leave chrony alone.

I think this misbehavior happens whenever all the services are
started (e.g.: at boot, when "systemctl daemon-reexec" is issued,
and so forth...).

This is very annoying.
My expectation is that the installation of chrony should automatically
disable systemd-timesyncd.
It used to work this way in the past, but it no longer seems to be the
case...

Could you please investigate and fix this issue?
Thanks for your time.

Bye!



-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.117
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.12-4
ii  libaudit11:2.8.3-1
ii  libblkid12.32-0.1
ii  libc62.27-3
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.2-1
ii  libgcrypt20  1.8.3-1
ii  libgpg-error01.31-1
ii  libidn11 1.33-2.2
ii  libip4tc01.6.2-1
ii  libkmod2 25-1
ii  liblz4-1 1.8.2-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.32-0.1
ii  libpam0g 1.1.8-3.7
ii  libseccomp2  2.3.3-2
ii  libselinux1  2.8-1
ii  libsystemd0  238-5
ii  mount2.32-0.1
ii  procps   2:3.3.15-2
ii  util-linux   2.32-0.1

Versions of packages systemd recommends:
ii  dbus1.12.8-3
ii  libpam-systemd  238-5

Versions of packages systemd suggests:
ii  policykit-10.105-20
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 238-5

-- no debconf information

Bug#899336: pdf-presenter-console: [regression] movies are no longer recognized!

[Francesco Poli (wintermute)]

Package: pdf-presenter-console
Version: 4.1.2-1
Severity: important

Hello,
I've just tested pdf-presenter-console/4.1.2-1 from Debian unstable.

It seems to fix bug #888677, as intended.

However, it appears to have a major regression (maybe caused by
collateral damage of the fix for bug #888677 ?!?): it no longer
recognizes movies in PDF pages. They are no longer clickable
in the presenter screen or in the audience screen.

Downgrading to pdf-presenter-console/4.1-4 makes movies work again.



I could even argue that this regression is big enough to justify a
"grave" severity for this bug report, as I think pdf-presenter-console
should not migrate to Debian testing after losing the really useful
movie-playing feature! It would be major step back!
Please raise the severity, if you agree with my reasoning.

Please forward this bug report upstream as soon as possible,
and/or revert the upstream change that introduced this regression.

Thanks for your time!


P.S.: after taking a look at the code, I wonder whether the regression
is maybe caused by the fact that, in file
pdfpc/src/classes/metadata/pdf.vala ,
the "page.remove_annot(a);" line has been added outside the
switch block:

  List anns = page.get_annot_mapping();
  foreach(unowned Poppler.AnnotMapping am in anns) {
  var a = am.annot;
  switch (a.get_annot_type()) {
  case Poppler.AnnotType.TEXT:
  case Poppler.AnnotType.FREE_TEXT:
  case Poppler.AnnotType.HIGHLIGHT:
  case Poppler.AnnotType.UNDERLINE:
  case Poppler.AnnotType.SQUIGGLY:
  if (note_text.length > 0) {
  note_text += "\n";
  }
  note_text += a.get_contents();
  break;
  }
  // Remove the annotation to avoid its rendering
  page.remove_annot(a);
  }

This means that, maybe, all annotations are removed, including
SCREEN and MOVIES ones, which should instead be preserved for
movie playing support... ?!?
Should the "page.remove_annot(a);" line be moved between
"note_text += a.get_contents();" and "break;", perhaps?



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

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

Versions of packages pdf-presenter-console depends on:
ii  libatk1.0-0 2.28.1-1
ii  libc6   2.27-3
ii  libcairo-gobject2   1.15.10-3
ii  libcairo2   1.15.10-3
ii  libfribidi0 0.19.7-2
ii  libgdk-pixbuf2.0-0  2.36.11-2
ii  libgee-0.8-20.20.1-1
ii  libglib2.0-02.56.1-2
ii  libgstreamer-plugins-base1.0-0  1.14.0-2
ii  libgstreamer1.0-0   1.14.0-1
ii  libgtk-3-0  3.22.29-3
ii  libpango-1.0-0  1.42.0-1
ii  libpangocairo-1.0-0 1.42.0-1
ii  libpoppler-glib80.63.0-2
ii  libx11-62:1.6.5-1

Versions of packages pdf-presenter-console recommends:
ii  gstreamer1.0-gtk3  1.14.0-4

pdf-presenter-console suggests no packages.

-- no debconf information

Bug#899259: cups-daemon: with IdleExitTimeout 60, fails to exit after 60 s of inactivity

[Francesco Poli (wintermute)]

Package: cups-daemon
Version: 2.2.7-5
Severity: normal

Dear Debian Printing Team,
this bug report is a sort of "sequel" of #894762...

After some preliminary tests, I concluded that socket activation
was working again.

Well, I was wrong!   :-(

After some further testing, I found out the following misbehavior.

 a) in my preliminary tests, the "lpq" command correctly woke cupsd up,
and the daemon correclty exited after 60 s of inactivity
(I have set "IdleExitTimeout 60" in /etc/cups/cupsd.conf)
 
 b) on the other hand, if I print something with the "lpr" command, cupsd
is correctly started, but it seems to never exit for inactivity:

$ systemctl status cups.service
● cups.service - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor 
preset: ena
   Active: active (running) since Mon 2018-05-21 11:59:07 CEST; 9h ago
 Docs: man:cupsd(8)
 Main PID: 15103 (cupsd)
Tasks: 1 (limit: 4915)
   Memory: 6.6M
   CGroup: /system.slice/cups.service
   └─15103 /usr/sbin/cupsd -l

May 21 11:59:07 HOSTNAME systemd[1]: Started CUPS Scheduler.

  c) now, after manually quitting cupsd and after re-enabling socket
 activation:

 # systemctl stop cups.service
 # systemctl daemon-reload
 # systemctl restart cups.socket

 an "lpq" command correctly starts cupsd (again), but the daemon
 fails to exit after 60 s of inactivity



Why does cupsd fail to exit?
What's wrong?

Please help me.

Thanks for your time!


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

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

Versions of packages cups-daemon depends on:
ii  adduser   3.117
ii  bc1.07.1-2+b1
ii  dpkg  1.19.0.5+b1
ii  libavahi-client3  0.7-4
ii  libavahi-common3  0.7-4
ii  libc6 2.27-3
ii  libcups2  2.2.7-5
ii  libcupsmime1  2.2.7-5
ii  libdbus-1-3   1.12.8-2
ii  libgssapi-krb5-2  1.16-2
ii  libpam0g  1.1.8-3.7
ii  libpaper1 1.1.24+nmu5
ii  libsystemd0   238-4
ii  lsb-base  9.20170808
ii  procps2:3.3.14-1+b1
ii  ssl-cert  1.0.39

Versions of packages cups-daemon recommends:
pn  avahi-daemon  
ii  colord1.3.3-2
ii  cups-browsed  1.20.3-1+b1

Versions of packages cups-daemon suggests:
ii  cups 2.2.7-5
ii  cups-bsd 2.2.7-5
ii  cups-client  2.2.7-5
ii  cups-common  2.2.7-5
ii  cups-filters [foomatic-filters]  1.20.3-1+b1
pn  cups-pdf 
ii  cups-ppdc2.2.7-5
ii  cups-server-common   2.2.7-5
ii  foomatic-db  20180306-1
ii  ghostscript  9.22~dfsg-2.1
pn  hplip
ii  poppler-utils0.63.0-2
ii  printer-driver-gutenprint5.2.13-2+b1
ii  printer-driver-hpcups3.17.10+repack0-5
pn  smbclient
ii  udev 238-4

-- no debconf information

Bug#898379: pitivi: no longer responds as soon as I try to import an Ogg Vorbis audio file

[Francesco Poli (wintermute)]

Package: pitivi
Version: 0.99-3
Severity: important

Hello!
Thanks for maintaining pitivi in Debian.

I am trying to learn how to use it, but I am experiencing an
important bug.
Steps to reproduce the issue:

  0) start pitivi

 $ pitivi

  1) click on the New button in the welcome dialog window

  2) click on the Import button in the media library tab

  3) go to a directory where one or more Ogg Vorbis files are
 present

  4) select one .ogg file and click on the Add button

  5) pitivi stops responding, its windows are no longer repainted,
 and there's nothing I can do, apart from killing the process...

I have tried a number of .ogg files, without any success.
In some cases I get the following errors:

  ERROR 00:03:38 assetpipeline  
_async_done_not_received_cb: we didn't get async done, this is a bug 
(../../../../usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/utils/pipeline.py:299)
  ERROR 00:03:38 assetpipeline  _recover: 
Pipeline error detected during playback, resetting -- num tries: 0 
(../../../../usr/lib/x86_64-linux-gnu/pitivi/python/pitivi/utils/pipeline.py:469)

but not always.

Is there anything I failed to understand?
Could you please investigate this bug and/or forward my bug report
upstream, as appropriate?

Thanks for your time.
Bye.


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

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

Versions of packages pitivi depends on:
ii  gir1.2-gdkpixbuf-2.02.36.11-2
ii  gir1.2-ges-1.0  1.14.0-1
ii  gir1.2-glib-2.0 1.56.1-1
ii  gir1.2-gst-plugins-base-1.0 1.14.0-2
ii  gir1.2-gstreamer-1.01.14.0-1
ii  gir1.2-gtk-3.0  3.22.29-3
ii  gir1.2-pango-1.01.42.0-1
ii  gstreamer1.0-alsa [gstreamer1.0-audiosink]  1.14.0-2
ii  gstreamer1.0-gl [gstreamer1.0-videosink]1.14.0-2
ii  gstreamer1.0-gtk3 [gstreamer1.0-videosink]  1.14.0-4
ii  gstreamer1.0-plugins-bad [gstreamer1.0-videosink]   1.14.0-1+b1
ii  gstreamer1.0-plugins-base   1.14.0-2
ii  gstreamer1.0-plugins-good [gstreamer1.0-videosink]  1.14.0-4
ii  gstreamer1.0-x [gstreamer1.0-videosink] 1.14.0-2
ii  libc6   2.27-3
ii  libcairo2   1.15.10-3
ii  libglib2.0-02.56.1-2
ii  libgstreamer-plugins-base1.0-0  1.14.0-2
ii  libgstreamer1.0-0   1.14.0-1
ii  libpython3.63.6.5~rc1-1
ii  python3 3.6.4-1
ii  python3-cairo   1.16.2-1
ii  python3-dbus1.2.6-1
ii  python3-gi  3.28.2-1
ii  python3-gi-cairo3.28.2-1
ii  python3-gst-1.0 1.14.0-2
ii  python3-matplotlib  2.1.1-2
ii  python3-numpy   1:1.13.3-2
ii  python3-xdg 0.25-4
ii  python3.6   3.6.5~rc1-1

pitivi recommends no packages.

Versions of packages pitivi suggests:
pn  frei0r-plugins 
pn  gir1.2-gnomedesktop-3.0
ii  gir1.2-notify-0.7  0.7.7-3
ii  gstreamer1.0-libav 1.14.0-1
pn  gstreamer1.0-plugins-ugly  

-- no debconf information

Bug#898075: jack: segfaults at start

[Francesco Poli (wintermute)]

Package: jack
Version: 3.1.1+cvs20050801-29.2+b1
Severity: grave
Justification: renders package unusable

Hello!

I have just found out that jack stopped working in Debian testing.
Last time I used it (around last December, on an up-to-date Debian
testing box), it worked without any glitch.

Now, when I try to encode one audio CD (*any* audio CD, including
one that was successfully encoded in the past), I just get a
segfault, immediately after selecting which FreeDB entry I want to use
(when there is a multiple choice):

  $ jack -Q
  [...]
  Segmentation fault

My /var/log/kern.log says:

  May  6 19:44:10 HOSTNAME kernel: [36919.353320] jack[10063]: segfault at 
7f89 ip 7f89ed5665c1 sp 7ffee93b2398 error 4 in 
libc-2.27.so[7f89ed40d000+1b1000]

My configuration file is:

  $ cat ~/.jack3rc 
  # jackrc-version:31
  ripper:cdparanoia
  base_dir:~/music/CDs
  unusable_chars:[' ', '/', ':', '?', '|', '>', '<']
  replacement_chars:['_', '_', '_', '_', '_', '_', '_']

in case it makes any difference.


Could you please try to reproduce the bug and fix it and/or
forward my bug report upstream, as appropriate?

Thanks for your time!
Bye.



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

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

Versions of packages jack depends on:
ii  cdparanoia   3.10.2+debian-13
ii  libc62.27-3
ii  libncursesw6 6.1+20180210-2
ii  libtinfo66.1+20180210-2
ii  python   2.7.15~rc1-1
ii  python-cddb  1.4-5.3
ii  python-eyed3 0.8.4-2
ii  python-pyvorbis  1.5-4
ii  vorbis-tools 1.4.0-10.1

jack recommends no packages.

jack suggests no packages.

-- no debconf information

Bug#897220: openshot-qt: preview does not run real-time

[Francesco Poli (wintermute)]

Package: openshot-qt
Version: 2.4.1+dfsg1-1
Severity: important

Hello Debian Multimedia Maintainers!

I am experiencing a really troublesome issue with OpenShot.

I am following the
[tutorial](https://www.openshot.org/static/files/user-guide/quick_tutorial.html)
at the beginning of the official documentation.

After adding some pictures and an audio file, I try to use the
preview window, but the preview is dead slow (and even runs at
variable "speed": the first chunk of video that should last 1 s
took approximately 10 s to be previewed, while the second chunk
that should again last 1 s took more than 30 s to be previewed,
and so forth...).
In other words, the preview does not run in real-time and
no audio is played.

If I click on Fast Forward, the preview runs too fast (as expected,
faster than real-time).

This means that the preview window is completely unusable for me.

While running the preview, the CPU usage is below 1 %, which seems
to suggest that this is not an issue due to limited computing
resources.
On the other hand, the CPU is a 4-core Intel i5:

  $ grep 'model name' /proc/cpuinfo 
  model name  : Intel(R) Core(TM) i5-4590S CPU @ 3.00GHz
  model name  : Intel(R) Core(TM) i5-4590S CPU @ 3.00GHz
  model name  : Intel(R) Core(TM) i5-4590S CPU @ 3.00GHz
  model name  : Intel(R) Core(TM) i5-4590S CPU @ 3.00GHz

and the video card used by Xorg is the Intel integrated graphics.
Does this affect the preview performance, as far as you know?

Please note that, once exported, I have no performance issues
in viewing the movie with, e.g., mpv.

Is there anything I am failing to understand?
Could you please investigate this issue and/or forward my bug report
upstream, as appropriate?

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



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

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

Versions of packages openshot-qt depends on:
ii  fonts-cantarell 0.0.25-4
ii  libjs-jquery3.2.1-1
ii  python3 3.6.4-1
ii  python3-openshot0.1.9+dfsg1-3+b2
ii  python3-pyqt5   5.10.1+dfsg-1
ii  python3-pyqt5.qtsvg 5.10.1+dfsg-1
ii  python3-pyqt5.qtwebkit  5.10.1+dfsg-1
ii  python3-zmq 17.0.0-1

Versions of packages openshot-qt recommends:
ii  blender   2.79.b+dfsg0-1
ii  inkscape  0.92.3-1+b1

Versions of packages openshot-qt suggests:
pn  openshot-qt-doc  

-- no debconf information

Bug#897219: openshot-qt: [Ctrl+Q] makes the program hang

[Francesco Poli (wintermute)]

Package: openshot-qt
Version: 2.4.1+dfsg1-1
Severity: important

Hello and thanks for maintaining OpenShot in Debian!

I am trying to learn using it, but I am experiencing a big issue:
whenever I want to exit from the program (by choosing Quit from the
File menu, by hitting [Ctrl+Q], by clicking on the X button on the
window-manager-provided window decoration, or ...), OpenShot hangs
indefinitely and I have to manually kill it with

  $ killall -TERM openshot-qt

Next time I start the program, it recovers my last unsaved project.
But, when I attempt to quit, I again see the program hang forever
(its window fails to be repainted, but it never disappears and
the openshot process never exits).

This even happens after

  $ rm -R ~/.openshot_qt/
  $ openshot-qt

and after just clicking on the Hide Tutorial button and on [Ctrl+Q].
The program hangs (even with no open project!) and I again have
to kill it...


Can you reproduce the bug?
Could you please investigate and/or forward my bug report upstream?

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



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

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

Versions of packages openshot-qt depends on:
ii  fonts-cantarell 0.0.25-4
ii  libjs-jquery3.2.1-1
ii  python3 3.6.4-1
ii  python3-openshot0.1.9+dfsg1-3+b2
ii  python3-pyqt5   5.10.1+dfsg-1
ii  python3-pyqt5.qtsvg 5.10.1+dfsg-1
ii  python3-pyqt5.qtwebkit  5.10.1+dfsg-1
ii  python3-zmq 17.0.0-1

Versions of packages openshot-qt recommends:
ii  blender   2.79.b+dfsg0-1
ii  inkscape  0.92.3-1+b1

Versions of packages openshot-qt suggests:
pn  openshot-qt-doc  

-- no debconf information

Bug#896130: RFP: vim-julia -- Vim plugin for Julia support

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vim-julia
  Version : N/A
  Upstream Author : Carlo Baldassi  and others
* URL : https://github.com/JuliaEditorSupport/julia-vim
* License : Expat
  Programming Lang: Vim script
  Description : Vim plugin for Julia support

julia-vim is a plugin for programming in Julia. It adds a number of useful
features to help you in writing Julia code.
.
The plugin provides:
* basic support for editing Julia files (automatic filetype detection,
  indentation, syntax highlighting)
* support for the matchit plugin
* support for Julia block-wise movements (i.e. jumping around between
  Julia blocks like if/end, function/end etc.) and block text-objects
* facilities for conversion of LaTeX entries to Unicode symbols which
  mimic and extend what the Julia REPL and the IJulia notebook
  interface do (optionally, this functionality can be used with all
  file types, not just Julia files)




I think this package may be useful to make the user's life easier,
while editing Julia code.
I hope someone will package and maintain it in Debian, it would
be really great. Thanks to anyone willing to do so!

Bug#895224: pdf-presenter-console: [regression] after upgrading to GStreamer 1.14.0, fails to play movies

[Francesco Poli (wintermute)]

Package: pdf-presenter-console
Version: 4.1-2
Severity: important

Hello.

While testing pdfpc again for bug #855525, I found out that the upgrade

  [INSTALL, DEPENDENCIES] gstreamer1.0-gl:amd64 1.14.0-2
  [INSTALL, DEPENDENCIES] libgstreamer-gl1.0-0:amd64 1.14.0-2
  [UPGRADE] gstreamer1.0-alsa:amd64 1.12.4-1 -> 1.14.0-2
  [UPGRADE] gstreamer1.0-libav:amd64 1.12.4-1 -> 1.14.0-1
  [UPGRADE] gstreamer1.0-plugins-bad:amd64 1.12.4-2+b2 -> 1.14.0-1
  [UPGRADE] gstreamer1.0-plugins-base:amd64 1.12.4-1 -> 1.14.0-2
  [UPGRADE] gstreamer1.0-tools:amd64 1.12.4-1 -> 1.14.0-1
  [UPGRADE] gstreamer1.0-x:amd64 1.12.4-1 -> 1.14.0-2
  [UPGRADE] libgstreamer-plugins-bad1.0-0:amd64 1.12.4-2+b2 -> 1.14.0-1
  [UPGRADE] libgstreamer-plugins-base1.0-0:amd64 1.12.4-1 -> 1.14.0-2
  [UPGRADE] libgstreamer1.0-0:amd64 1.12.4-1 -> 1.14.0-1

had disastrous effects on the movie playing capability of pdfpc.

It now seems that no movie can be played at all, and lots of errors
and warning are written on the terminal.

Please refer to the 
[MWE](https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=855525;filename=855525_mwe.tar.xz;msg=15)
sent for bug #855525.

If I try

  $ pdfpc -Ss wave_presentation.pdf

go to slide 2 and click on the animation, I get the following errors
and warnings:


  (pdfpc:4293): GLib-GObject-CRITICAL **: 15:19:25.228: g_object_get: assertion 
'G_IS_OBJECT (object)' failed
  
  (pdfpc:4293): GStreamer-CRITICAL **: 15:19:25.280: 
gst_element_link_pads_full: assertion 'GST_IS_ELEMENT (dest)' failed
  
  (pdfpc:4293): Gtk-CRITICAL **: 15:19:25.280: gtk_widget_add_events: assertion 
'GTK_IS_WIDGET (widget)' failed
  
  (pdfpc:4293): GLib-GObject-WARNING **: 15:19:25.280: invalid (NULL) pointer 
instance
  
  (pdfpc:4293): GLib-GObject-CRITICAL **: 15:19:25.280: 
g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
  
  (pdfpc:4293): GLib-GObject-WARNING **: 15:19:25.280: invalid (NULL) pointer 
instance
  
  (pdfpc:4293): GLib-GObject-CRITICAL **: 15:19:25.280: 
g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
  
  (pdfpc:4293): GLib-GObject-WARNING **: 15:19:25.280: invalid (NULL) pointer 
instance
  
  (pdfpc:4293): GLib-GObject-CRITICAL **: 15:19:25.280: 
g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
  
  (pdfpc:4293): GLib-GObject-CRITICAL **: 15:19:25.280: g_object_set: assertion 
'G_IS_OBJECT (object)' failed
  
  ** (pdfpc:4293): CRITICAL **: 15:19:25.280: pdfpc_view_video_add_video: 
assertion 'video != NULL' failed
  
  (pdfpc:4293): Gtk-CRITICAL **: 15:19:25.366: gtk_widget_set_opacity: 
assertion 'GTK_IS_WIDGET (widget)' failed
  Gstreamer error Internal data stream error.
  Gstreamer error Internal data stream error.
  
  (pdfpc:4293): Gtk-CRITICAL **: 15:19:27.826: gtk_widget_set_opacity: 
assertion 'GTK_IS_WIDGET (widget)' failed
  
  (pdfpc:4293): Gtk-CRITICAL **: 15:19:29.907: gtk_widget_get_parent: assertion 
'GTK_IS_WIDGET (widget)' failed
  
  ** (pdfpc:4293): CRITICAL **: 15:19:29.907: pdfpc_view_video_remove_video: 
assertion 'self != NULL' failed


The movie is not played at all.


Please forward this bug report upstream and/or investigate and fix
the issue.

Thanks for your time and patience.
Bye.


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

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

Versions of packages pdf-presenter-console depends on:
ii  libatk1.0-0 2.28.1-1
ii  libc6   2.27-3
ii  libcairo-gobject2   1.15.10-1
ii  libcairo2   1.15.10-1
ii  libgdk-pixbuf2.0-0  2.36.11-2
ii  libgee-0.8-20.20.1-1
ii  libglib2.0-02.56.0-4
ii  libgstreamer-plugins-base1.0-0  1.14.0-2
ii  libgstreamer1.0-0   1.14.0-1
ii  libgtk-3-0  3.22.29-3
ii  libpango-1.0-0  1.42.0-1
ii  libpangocairo-1.0-0 1.42.0-1
ii  libpoppler-glib80.62.0-2
ii  libx11-62:1.6.5-1

pdf-presenter-console recommends no packages.

pdf-presenter-console suggests no packages.

-- no debconf information

Bug#894762: cups-daemon: with IdleExitTimeout 60, correctly exits when idle for 60 s, but immediately respawns [regression]

[Francesco Poli (wintermute)]

Package: cups-daemon
Version: 2.2.7-1
Severity: normal

Dear Debian Printing Team,
I noticed a weird misbehavior of cupsd, which seems to be a regression.

I had configured /etc/cups/cupsd.conf with the directive

  IdleExitTimeout 60

in order to let cupsd exit when idle for 60 s: the feature (with
systemd socket activation) was working correctly.

However, after upgrading

  [UPGRADE] cups:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-bsd:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-client:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-common:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-core-drivers:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-daemon:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-ipp-utils:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-ppdc:amd64 2.2.6-5 -> 2.2.7-1
  [UPGRADE] cups-server-common:amd64 2.2.6-5 -> 2.2.7-1

cupsd exits after 60 s of inactivity, but is mysteriously respawned
immediately.
The net result of all this is that cupsd gets restarted once every
60 s, which is annoying (especially because of colord verbosity,
see bug #750533).

The fact is that I cannot understand why cupsd gets respawned,
when nobody is attempting to print anything or to use the web
interface.
And I am pretty sure that cups-daemon/2.2.6-5 did not exhibit
this misbehavior.

Could you please investigate this issue?

Thanks for your time and helpfulness!
Bye.



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

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

Versions of packages cups-daemon depends on:
ii  adduser   3.117
ii  bc1.07.1-2
ii  dpkg  1.19.0.5
ii  libavahi-client3  0.7-3.1
ii  libavahi-common3  0.7-3.1
ii  libc6 2.27-2
ii  libcups2  2.2.7-1
ii  libcupsmime1  2.2.7-1
ii  libdbus-1-3   1.12.6-2
ii  libgssapi-krb5-2  1.16-2
ii  libpam0g  1.1.8-3.7
ii  libpaper1 1.1.24+nmu5
ii  libsystemd0   238-3
ii  lsb-base  9.20170808
ii  procps2:3.3.12-4
ii  ssl-cert  1.0.39

Versions of packages cups-daemon recommends:
pn  avahi-daemon  
ii  colord1.3.3-2
ii  cups-browsed  1.20.1-1+b1

Versions of packages cups-daemon suggests:
ii  cups 2.2.7-1
ii  cups-bsd 2.2.7-1
ii  cups-client  2.2.7-1
ii  cups-common  2.2.7-1
ii  cups-filters [foomatic-filters]  1.20.1-1+b1
pn  cups-pdf 
ii  cups-ppdc2.2.7-1
ii  cups-server-common   2.2.7-1
ii  foomatic-db  20180210-1
ii  ghostscript  9.22~dfsg-2
pn  hplip
ii  poppler-utils0.62.0-2
ii  printer-driver-gutenprint5.2.13-2
ii  printer-driver-hpcups3.17.10+repack0-5
pn  smbclient
ii  udev 238-3

-- no debconf information

Bug#894462: paraview: edges are blotted [regression]

[Francesco Poli (wintermute)]

Package: paraview
Version: 5.4.1+dfsg4-2
Severity: grave
Justification: renders package unusable

Hello paraview Debian package maintainers,
thanks for uploading a Debian revision that uses Qt5 rather than Qt4!

I've just upgraded to it on my Debian testing box, but I found a bad
regression that renders the package unusable to create beautiful and
clear visualizations (this may be considered as basically the main
purpose of paraview!).


The attached test case is based on one of the data files generated
by the little program included in the test case sent for bug #892293.
The program source (written in Fortran) is included again for
completeness' sake.

Steps to reproduce the regression:

  0) start paraview

 $ paraview

  1) click on the "Open" button and open "wave0001.xyz"

  2) specify "PLOT3D Files" in the "Open Data With..." dialog window

  3) click on the "Apply" button
  
  4) change the representation from "Outline" to "Surface With Edges"

  5) from the File menu, select Save State...

  6) save the state as "wave_PARAVIEW-VERSION.pvsm"

  7) from the File menu, select Save Screenshot...

  8) save the screenshot as "wave_PARAVIEW-VERSION.png"


By performing these steps with paraview/5.4.1+dfsg3-2 and
with paraview/5.4.1+dfsg4-2, I obtained the two attached
screenshots.

In paraview/5.4.1+dfsg4-2 there seems to be a commendable attempt
to apply some antialiasing to all the lines (including the edges
on surfaces, the wireframe edges, but also the lines of the orientation
axes, and so forth...).
Unfortunately this new feature creates unsightly images, whenever
the edges are shown from a distance. Please take a look yourself
at the wave_5.4.1+dfsg4-2.png screenshot: all the intersections
between edges seem to be somehow "blotted" and unpleasant to look at.


Please fix this regression, as it makes paraview unusable.

Thanks for your time!
Bye.


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

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

Versions of packages paraview depends on:
ii  libavcodec57   7:3.4.2-1+b1
ii  libavformat57  7:3.4.2-1+b1
ii  libavutil557:3.4.2-1+b1
ii  libc6  2.27-2
ii  libcgns3.3 3.3.0-6
ii  libexpat1  2.2.5-3
ii  libfreetype6   2.8.1-2
ii  libgcc11:8-20180321-1
ii  libgl1 1.0.0-2
ii  libgl2ps1.41.4.0+dfsg1-2
ii  libglew2.0 2.0.0-5
ii  libhdf5-1001.10.0-patch1+docs-4
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libjsoncpp11.7.4-3
ii  libnetcdf131:4.6.1-1
ii  libogg01.3.2-1+b1
ii  libopenmpi22.1.1-8
ii  libpng16-161.6.34-1
ii  libprotobuf10  3.0.0-9.1
ii  libpython2.7   2.7.14-7
ii  libqt5core5a   5.9.2+dfsg-12
ii  libqt5gui5 5.9.2+dfsg-12
ii  libqt5help55.9.2-6
ii  libqt5network5 5.9.2+dfsg-12
ii  libqt5widgets5 5.9.2+dfsg-12
ii  libqt5x11extras5   5.9.2-1
ii  libstdc++6 8-20180321-1
ii  libswscale47:3.4.2-1+b1
ii  libtheora0 1.1.1+dfsg.1-14+b1
ii  libtiff5   4.0.9-4
ii  libx11-6   2:1.6.5-1
ii  libxml22.9.4+dfsg1-6.1
ii  libxt6 1:1.1.5-1
ii  python-autobahn17.10.1+dfsg1-2
ii  python-matplotlib  2.1.1-2
ii  python-mpi4py  2.0.0-3
ii  python-six 1.11.0-2
ii  python-twisted 17.9.0-1
ii  tcl [tclsh]8.6.0+9
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages paraview recommends:
ii  mpi-default-bin  1.10
ii  paraview-doc 5.4.1+dfsg4-2
ii  paraview-python  5.4.1+dfsg4-2

Versions of packages paraview suggests:
pn  h5utils 
pn  hdf5-tools  

-- no debconf information


waveplot3d_blotted-edges.tar.xz
Description: application/xz

Bug#894460: checkrestart: false positive for Xorg with Intel graphics under Linux kernel 4.15

[Francesco Poli (wintermute)]

Package: debian-goodies
Version: 0.79
Severity: normal

Hello!

I noticed a new false positive in checkrestart, since I upgraded my
Debian testing boxes to linux-image-4.15.0-2-amd64/4.15.11-1

Under an X session with Intel graphics, when I run

  # checkrestart -v

I get the attached output, even when the box has just booted and
no upgrade has been performed yet.

I seem to recall that there were some entries ignored in order to
avoid false positives with Intel graphics.
Maybe these entries changed slightly and are no longer ignored?!?

Please add the new entries to the ignore list.

Thanks for your time!
Bye.


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

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

debian-goodies depends on no packages.

Versions of packages debian-goodies recommends:
ii  apt1.6~beta1
ii  curl   7.58.0-2
ii  dctrl-tools2.24-2+b1
ii  dialog 1.3-20171209-1
pn  elfutils   
ii  libipc-system-simple-perl  1.25-4
ii  man-db 2.8.2-1
ii  perl   5.26.1-5
ii  popularity-contest 1.66
ii  procps 2:3.3.12-4
ii  python33.6.4-1
ii  sensible-utils 0.0.12
ii  whiptail   0.52.20-4
ii  zenity 3.28.0-1

Versions of packages debian-goodies suggests:
ii  apt-file   3.1.5
ii  chromium [www-browser] 62.0.3202.89-1
ii  firefox-esr [www-browser]  52.6.0esr-2+b1
pn  konqueror  
pn  libgnome2-bin  
ii  lsb-release9.20170808
ii  lsof   4.89+dfsg-0.1
ii  w3m [www-browser]  0.5.3-36
ii  xdg-utils  1.1.2-2

-- no debconf information
Found 1 processes using old versions of upgraded files
(1 distinct program)
[DEBUG] Process /usr/lib/xorg/Xorg (PID: 1171) 
List of deleted files in use:
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
/i915
[DEBUG] Running: dpkg-query --search /usr/lib/xorg/Xorg
[DEBUG] Reading line from dpkg-query: xserver-xorg-core: /usr/lib/xorg/Xorg

[DEBUG] Found package xserver-xorg-core for program /usr/lib/xorg/Xorg
(1 distinct packages)
[DEBUG] Running: dpkg-query --listfiles xserver-xorg-core
These processes (1) do not seem to have an associated init script to restart 
them:
xserver-xorg-core:
1171/usr/lib/xorg/Xorg

Bug#894408: briquolo: please implement a way to increase/decrease audio volume inside the game

[Francesco Poli (wintermute)]

Package: briquolo
Version: 0.5.7-8
Severity: wishlist
Tags: upstream

Hello,
thanks for maintaining this nice breakout game in Debian!


It seems to me that there is no way to increase or decrease the
audio volume from inside the game.

This means that, before playing, I have to start alsamixer, set a
suitable Master channel level, then start briquolo.
Also, after quitting from briquolo, I have to again use alsamixer
in order to set the previous Master channel level (the one that is
suitable for any other application that uses the sound card).

This is inconvenient.

I hope that a volume level for sound effects may be easily implemented,
for instance in the settings menu.
This volume level should set the amplification for sound effects,
without changing alsamixer levels or anything else outside
the game.

Please implement this feature and/or forward this bug report upstream,
as appropriate.

Thanks for your time!
Bye.


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

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

Versions of packages briquolo depends on:
ii  briquolo-data   0.5.7-8
ii  libc6   2.27-2
ii  libgcc1 1:8-20180321-1
ii  libgl1  1.0.0-2
ii  libgl1-mesa-glx 17.3.7-1
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libpng16-16 1.6.34-1
ii  libsdl-mixer1.2 1.2.12-14
ii  libsdl-ttf2.0-0 2.0.11-4
ii  libsdl1.2debian 1.2.15+dfsg2-0.1
ii  libstdc++6  8-20180321-1

briquolo recommends no packages.

briquolo suggests no packages.

-- no debconf information