Bug#873033: ITP: opengcs -- Guest Compute Service for Linux Hyper-V Container

[Balint Reczey]

Hi Jose,

On Wed, 6 Jun 2018 16:47:53 + Jose Miguel Parrella Romero
 wrote:

> I intend to explore bringing the opengcs source package to Debian in
collaboration with Balint.

The upstream project has since been obsoleted by hcsshim. Closing the
bug report again.

Cheers,

Balint

Bug#986769: wireshark: Dropdown menus invisible in Sway

[Balint Reczey]

Hi Pelle,

On Wed, May 12, 2021 at 11:55 PM Pelle  wrote:
>
> On Sun, May 09, 2021 at 06:26:21PM +0200, Balint Reczey wrote:
> >Could you please tell which drop-down menus did not work
>
> The drop-down menus in the main menu don't work: File, Edit, View, Go,
> Capture, etc.

OK, those worked for me.

> >or if you have some special config that could affect the behaviour?
>
> When running Wireshark in Sway with a newly created user, the drop-downs
> work. However, I haven't intentionally changed any Qt configuration, and
> neither `.qt`, `.config/Trolltech/` or `.config/Trolltech.conf` exist.
> I'm not sure where else accidentally created Qt configuration could be hiding.

I suggest making a copy of your user's $HOME under a newly created
user account, importing it to git and removing parts of it in the form
of a binary search to find what makes the difference.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#986769: wireshark: Dropdown menus invisible in Sway

[Balint Reczey]

Control: tags -1 moreinfo unreproducible

Hi Pelle,

On Sun, Apr 11, 2021 at 11:12 PM Pelle  wrote:
>
> Package: wireshark
> Version: 3.4.4-1
> Severity: normal
>
> Dear Maintainer,
>
> Wireshark's dropdown menus are invisible in Sway (the Wayland compositor). The
> invisible dropdown menu entries can't be clicked but they can still be
> activated via keyboard. The dropdown menus in other QT-based apps (VLC, Krita,
> …) work fine in Sway.
>
> A workaround is to run `ssh -X localhost wireshark` in Sway, or to run
> Wireshark inside Weston.
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 wireshark depends on:
> ii  wireshark-qt  3.4.4-1

I've tried to reproduce the error, but all menus I could think of
worked under Sway in Ubuntu 21.04 with an intel GPU and in unstable
(today) in Qemu.
Could you please tell which drop-down menus did not work or if you
have some special config that could affect the behaviour?

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#931553: wireshark-dev idl2wrs now supports Python3

[Balint Reczey]

Control: fixed -1 3.2.0-1

On Tue, May 4, 2021 at 10:48 PM Gerald Combs  wrote:
>
> This bug should be fixed in Wireshark 3.2 and later as described at 
> https://gitlab.com/wireshark/wireshark/-/issues/15865.

True, thanks!

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#987853: wireshark: CVE-2021-22207

[Balint Reczey]

Control: tags -1 pending confirmed

Hi Salvatore,

On Fri, Apr 30, 2021 at 10:57 PM Salvatore Bonaccorso  wrote:
>
> Source: wireshark
> Version: 3.4.4-1
> Severity: important
> Tags: security upstream
> Forwarded: https://gitlab.com/wireshark/wireshark/-/issues/17331
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
>
> Hi,
>
> The following vulnerability was published for wireshark.
>
> CVE-2021-22207[0]:
> | Excessive memory consumption in MS-WSP dissector in Wireshark 3.4.0 to
> | 3.4.4 and 3.2.0 to 3.2.12 allows denial of service via packet
> | injection or crafted capture file
>
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

I've prepared the next upload including this fix at
https://salsa.debian.org/debian/wireshark/-/commits/debian/master but
have not uploaded it because I did not consider this vulnerability
important enough to ask an exception for the freeze.

I will happily do the upload if it gets unblocked.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#987431: Graphical session or LightDM do not close until unattended-upgrades has applied all updates

[Balint Reczey]

Control: found -1 1.26.0-7
Control: clone -1 -2
Control: reassign -2 cinnamon 4.8.6-2
Control: retitle -2 Cinnamon does not close session when shutdown starts

Hi Yvan,

On Mon, Apr 26, 2021 at 12:57 PM Yvan Masson
 wrote:
>
> Hi Balint,
>
> Le 26/04/2021 à 11:56, Balint Reczey a écrit :
> > Control: reassign -1 lightdm
> >
> > Hi Yvan,
> >
> > On Fri, Apr 23, 2021 at 9:21 PM Yvan Masson  
> > wrote:
> >>
> >> Package: unattended-upgrades
> >> Version: 2.8
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >> I am preparing some Debian 11 desktops (for when it will be the new
> >> stable). The setup is very simple: no root account, one partition, tasks
> >> desktop/Cinnamon/standard tools/SSH. Unattended-upgrades is configured
> >> to install updates on shutdown (see 1): upgrading works properly, but is
> >> very disturbing for the users:
> >>
> >> When the user chooses to shutdown or reboot the computer from his
> >> Cinnamon session, the session does not close until all updates are
> >> applied. While waiting:
> >> - icons on the desktop disappear
> >> - the usual menu that allows choosing between
> >> suspend/hibernate/reboot/cancel/shutdown won't appear again (see 2)
> >> - it is still possible to start applications
> >>
> >> When a user session has been opened, then closed, and the user clicks on
> >> shutdown or reboot from LightDM, the behavior is similar: LightDM does
> >> not stop. It is even possible to log in again, while unattended-upgrades
> >> is applying updates, but when updates are applied the computer
> >> shutdowns/reboots as requested originally from LightDM.
> >>
> >> I would expect the session to be completely closed, LightDM stopped, and
> >> the console or Plymouth displaying a message indicating the ongoing
> >> updates. I am almost sure this has already worked for me in a previous
> >> Debian version or Ubuntu, with the same setup from me.
> >>
> >> Please let me know if you need more information or if you want me to do
> >> some tests.
> >
> > The change that took place in unattended-upgrades 1.8:
> >
> > unattended-upgrades (1.8) unstable; urgency=medium
> >
> > When InstallOnShutdown was configured unattended-upgrades in
> > versions before 1.7 installed updates _after_ the shutdown transaction
> > is started by systemd making maintainer scripts restarting services
> > fail or wait in a deadlock until being killed by shutdown's timeout
> > leaving a broken installation behind.
> >
> > Starting with version 1.7 configuring InstallOnShutdown makes
> > unattended-upgrades start package installations _before_ the shutdown
> > transaction is started, when PrepareForShutdown() signal is received
> > via DBus.
> >
> > Unattended-upgrades 1.7 also increases logind's InhibitDelayMaxSec to
> > 30 seconds. This allows more time for unattended-upgrades to shut down
> > gracefully or even install a few packages in InstallOnShutdown mode,
> > but is still a big step back from the 30 minutes allowed for
> > InstallOnShutdown previously.
> >
> > Users enabling InstallOnShutdown mode are advised to increase
> > InhibitDelayMaxSec even further, possibly to 30 minutes.
> > --
> >
> > When shutdown is successfully initiated from a graphical session the
> > user should be logged out and if the shutdown is successfully
> > initiated from a login manager it should stop, otherwise any inhibitor
> > holding up the shutdown can cause the described problems.
>
> Thanks for the detailed answer.
>
> I just checked again on my simple test VM, the only "shutdown" inhibitor
> is Unattended Upgrades Shutdown.
>
> For comparison, I installed Gnome and GDM on this same VM:
> - When choosing to shutdown from the Gnome session, the session is
> properly closed, but GDM stays on while upgrades are applied. It is even
> possible to log in again.
>
> - When I boot, log in, log out and then choosing to shutdown from GDM,
> GDM seems to be properly closed: screen becomes all black with only the
> blinking "_" on top-left, but `ps` from a SSH session shows that it is
> still running.

It seems GDM is better, but not perfect yet, then. The re-login
problem is tracked in #608259.

> If I understand properly, all of this means that GDM/LightDM and
> Cinnamon do no always react properly to "shutdown" systemd inhibitors:
> is my understanding correct?

Yes. I've cloned the bug to track it for every package that needs to be fixed.

> Do not hesitate to ask if I can help, by testing reporting this elsewhere.

Thanks, maybe the other packages' maintainers will ask for help with testing.

Cheers,
Balint

--
Balint Reczey
Ubuntu & Debian Developer

Bug#987431: Graphical session or LightDM do not close until unattended-upgrades has applied all updates

[Balint Reczey]

Control: reassign -1 lightdm

Hi Yvan,

On Fri, Apr 23, 2021 at 9:21 PM Yvan Masson  wrote:
>
> Package: unattended-upgrades
> Version: 2.8
> Severity: normal
>
> Dear Maintainer,
>
> I am preparing some Debian 11 desktops (for when it will be the new
> stable). The setup is very simple: no root account, one partition, tasks
> desktop/Cinnamon/standard tools/SSH. Unattended-upgrades is configured
> to install updates on shutdown (see 1): upgrading works properly, but is
> very disturbing for the users:
>
> When the user chooses to shutdown or reboot the computer from his
> Cinnamon session, the session does not close until all updates are
> applied. While waiting:
> - icons on the desktop disappear
> - the usual menu that allows choosing between
> suspend/hibernate/reboot/cancel/shutdown won't appear again (see 2)
> - it is still possible to start applications
>
> When a user session has been opened, then closed, and the user clicks on
> shutdown or reboot from LightDM, the behavior is similar: LightDM does
> not stop. It is even possible to log in again, while unattended-upgrades
> is applying updates, but when updates are applied the computer
> shutdowns/reboots as requested originally from LightDM.
>
> I would expect the session to be completely closed, LightDM stopped, and
> the console or Plymouth displaying a message indicating the ongoing
> updates. I am almost sure this has already worked for me in a previous
> Debian version or Ubuntu, with the same setup from me.
>
> Please let me know if you need more information or if you want me to do
> some tests.

The change that took place in unattended-upgrades 1.8:

unattended-upgrades (1.8) unstable; urgency=medium

When InstallOnShutdown was configured unattended-upgrades in
versions before 1.7 installed updates _after_ the shutdown transaction
is started by systemd making maintainer scripts restarting services
fail or wait in a deadlock until being killed by shutdown's timeout
leaving a broken installation behind.

Starting with version 1.7 configuring InstallOnShutdown makes
unattended-upgrades start package installations _before_ the shutdown
transaction is started, when PrepareForShutdown() signal is received
via DBus.

Unattended-upgrades 1.7 also increases logind's InhibitDelayMaxSec to
30 seconds. This allows more time for unattended-upgrades to shut down
gracefully or even install a few packages in InstallOnShutdown mode,
but is still a big step back from the 30 minutes allowed for
InstallOnShutdown previously.

Users enabling InstallOnShutdown mode are advised to increase
InhibitDelayMaxSec even further, possibly to 30 minutes.
--

When shutdown is successfully initiated from a graphical session the
user should be logged out and if the shutdown is successfully
initiated from a login manager it should stop, otherwise any inhibitor
holding up the shutdown can cause the described problems.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#889290: If NTP is installed, then systemd-timesyncd should be disabled.

[Balint Reczey]

Control: fixed -1 systemd 245.4-2
Control: fixed -1 ntp 1:4.2.8p14+dfsg-2

Hi,

On Mon, 18 Nov 2019 18:16:58 +0100 Daniel Swarbrick
 wrote:
> I am also witnessing multiple hosts where ntp is failing to start,
> however the disable-with-time-daemon.conf file /is/ present on these
> systems:
>
> $ dpkg -S disable-with-time-daemon.conf
> systemd:
> /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
>
> System is buster 10.2, systemd package version 241-7~deb10u2.
>
> And it is clearly doing what it should:
>
> $ systemctl status systemd-timesyncd
> ● systemd-timesyncd.service - Network Time Synchronization
> Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service;
> enabled; vendor preset: enabled)
>Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
> └─disable-with-time-daemon.conf
> Active: inactive (dead)
> Condition: start condition failed at Mon 2019-11-18 15:38:08 UTC; 1h
> 26min ago
>   Docs: man:systemd-timesyncd.service(8)
>
> Nov 18 15:38:08 lhr-ceph02 systemd[1]: Condition check resulted in
> Network Time Synchronization being skipped.
>
> However, ntp does not start, and doesn't even appear to log any errors.
> I'm wondering if it's a race condition, caused by this in the ntp unit file:
>
> Conflicts=systemd-timesyncd.service
>
> But I would sort of expect a failure message to be logged. I have tried
> to replicate the setup in a VM, however there, ntp is starting as it
> should - making me suspect a race condition even more.
>
> On Thu, 1 Nov 2018 03:42:03 -0700 Rick Thomas  wrote:
>
>  > Hmmm…
>  >
>  > It appears that the systemd package in stretch (9.5) has a patch for
> this:
>  >
> /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
>  >
>  > But this is not present in buster.

I believe this is fixed now since ntp  and systemd-timesyncd are not
conistallable.

Cheers,
Balint

Bug#986329: debhelper: dh_installtmpfiles calls systemd-tmpfiles on not *.conf files

[Balint Reczey]

Package: debhelper
Severity: wishlist
Version: 13.3.4

Dear Maintainers,

Systemd upstream added README files in .d directories including in tmpfiles.d:
https://github.com/systemd/systemd/commit/d83e90c73cf25a839f5e60f355baa0d38364ff41

If /usr/lib/tmpfiles.d/README is shipped in the systemd package it
triggers errors to be shown upon installation because in postinst the
README is processed like it was a config file:
systemd.postinst:
...
if [ -d /run/systemd/system ] ; then
systemd-tmpfiles --create README debian.conf home.conf
journal-nocow.conf legacy.conf systemd-nologin.conf
systemd-pstore.conf systemd-tmp.conf systemd.conf tmp.conf var.conf
x11.conf >/dev/null || true
...

For now the plan is not shipping the README, but it would be nice to
not have this issue in debhelper.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#966387: unattended-upgrade-shutdown left running after package removal

[Balint Reczey]

Control: tags -1 confirmed
Control: severity -1 minor

On Mon, Jul 27, 2020 at 10:03 PM Jakub Wilk  wrote:
>
> Package: unattended-upgrades
> Version: 1.11.2
>
> I removed the unattended-upgrades package, but the
> unattended-upgrade-shutdown process is still running running in the
> background:
>
># dpkg -P unattended-upgrades
>(Reading database ... 39928 files and directories currently installed.)
>Removing unattended-upgrades (1.11.2) ...
>Purging configuration files for unattended-upgrades (1.11.2) ...
>dpkg: warning: while removing unattended-upgrades, directory 
> '/var/log/unattended-upgrades' not empty so not removed
>Processing triggers for man-db (2.8.5-2) ...
>Processing triggers for systemd (241-7~deb10u4) ...
>
># pgrep -a unattended
>575 /usr/bin/python3 
> /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal

Yes, thanks for reporting it.
The process does no harm and will disappear at next reboot.
Not nice, though.

Cheers,
Balint

Bug#983362: Bug#983367: gvfs: autopkg test always fails on qemu testbed

[Balint Reczey]

Hi Ryutaroh.

On Thu, Feb 25, 2021 at 1:39 AM Ryutaroh Matsumoto
 wrote:
>
> I was told that autopkg test scripts should not assume that an ordinary user 
> can sudo at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983432#10

This can be looked at several ways and thank you for collecting a few opinions.

As Simon pointed out passwordless sudo is available in Ubuntu test
images (both for VMs and LXC runners), thus it is not a surprise that
tests started relying on that. IMO making passwordless sudo available
is the most pleasant way of enabling testing as a normal user and
still allowing raising privileges for a few operations.
On Ubuntu isolation-container and isolation-machine will keep implying
passwordless sudo being available and IMO the easiest solution forward
would be generating Debian test images the same way. Personally I'd
like to see Debian executing the tests using sudo and any other way
would be just more complicated.

The needs-sudo restriction can be a good way of documenting the tests'
requirements and the test runners' capability.

Should none of the above would be adopted in Debian I can make the
test SKIP if sudo fails.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#984888: pam-mysql: Newly added test with 323 hashed passwords fail on s390x

[Balint Reczey]

Hi,

On Sun, Mar 14, 2021 at 3:49 PM  wrote:
>
> Balint Reczey  writes:
>
> > Autopkgtests are failing in CI on s390x due to the following newly added 
> > tests:
> >
> > ...
> > OK: Y_MD5: correct password accepted
> > OK: Y_MD5: incorrect password refused
> > FAIL: mysql: correct password refused
> > OK: mysql: incorrect password refused
> > ...
>
> (It isn't the 323 variant that fails, but anyway...)
>
> Debugging suggests that the internal SHA-1 implementation does not work
> on big-endian architectures.  The easy way out is switching to the
> libcrypto implementation (the package already depends on libssl1.1 and
> the PAM module links against libcrypto.so.1).  The hard way is finding
> the bug and fixing it for arbitrary endianness.  I wonder which one the
> Release Team prefers...

I'm sure the Release Team would prefer using a well known SHA
implementation rather than an internal one especially when the
internal one proved to be broken.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#984888: pam-mysql: Newly added test with 323 hashed passwords fail on s390x

[Balint Reczey]

Source: pam-mysql
Version: 0.8.1-4
Severity: normal

Dear Maintainer,

Autopkgtests are failing in CI on s390x due to the following newly added tests:

debian/tests/auth:
...
'mysql': { 'crypt':  2, '323': 'false', 'hash':
'*1A8A8D8A90F03E8A15D4FFB3FC91A4693F077A84' }, # select
PASSWORD('foopwd')

...

https://ci.debian.net/packages/p/pam-mysql/testing/s390x/
https://ci.debian.net/data/autopkgtest/testing/s390x/p/pam-mysql/10949034/log.gz
:
...
OK: Y_MD5: correct password accepted
OK: Y_MD5: incorrect password refused
FAIL: mysql: correct password refused
OK: mysql: incorrect password refused
...

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#982461: apt: Please provide a configuration option for disabling fsync()-s

[Balint Reczey]

Hi Julian,

On Wed, Feb 10, 2021 at 3:23 PM Julian Andres Klode  wrote:
>
>
> On Wed, Feb 10, 2021 at 03:10:45PM +0100, Balint Reczey wrote:
> > Source: apt
> > Version:
> > Severity: wishlist
> >
> > Hi,
> >
> > I run eatmydata apt ... frequently and it is used widely by others
> > when there is no need to fsync()-s during package installations or
> > removals, but it is nice to save time and wear off SSDs later.
> >
> > Using fsync() is unlikely to bring any benefit when a system is very
> > unlikely to crash or it is cheap to recreate in case of an
> > installation failure like it is the case for provisioning containers.
> > Also using fsync is fairly pointless when apt-btrfs-snapshot is
> > installed and a snapshot is taken after the apt operation anyway.
> >
> > Ideally dpkg would provide a command line option for skipping fsync,
> > but it is not yet the case: #923423.
> >
> > On APT's side I'd like to propose a config option which when set would
> > prefix dpkg calls with eatmydata until dpkg has a better interface for
> > disabling fsyncs.
>
> dpkg already has --force-unsafe-io to avoid syncs, it's what I use. I
> don't want to have an option for eatmydata inside apt, it also affects a
> lot of other stuff down the line like services outside on sysvinit
> systems and all stuff happening in maintainer scripts; but then it only
> works on the native architecture, not for foreign ones, and scripts
> might be unsetting LD_PRELOAD. Heck APT probably should unset
> LD_PRELOAD like it cleans up PATH.
>
> I considered adding a seccomp filter to apt that would block fsync() and
> friends, which is more persuasive than eatmydata. But force-unsafe-io is
> usually enough.
>
> Lastly, you can also just create a dpkg -> eatmydata symlink somewhere,
> and then specify that as your Dir::Bin::dpkg, and that would work too.
> eatmydata could ship some symlinks in /usr/libexec/eatmydata, similar to
> what ccache does.
>
> I do not believe that adding such a hack to apt is the right approach.

IMO the practice of using eatmydata with is widespread enough to be
considered safe (checking for systemd as init), but let's not consider
if for now.

As I see apt does not pass --force-unsafe-io either yet to dpkg and
the proposed option could add it:

test@debian:~$ sudo strace -ff -ofirefox-install.trace -efsync apt
install --reinstall ./firefox_85.0.1-1_amd64.deb
...
Processing triggers for gnome-menus (3.36.0-1) ...
test@debian:~$ grep fsync firefox-install.trace* | wc -l
123

The other problem with force-unsafe-io is that it disables only part
of the fsync()-s, around half of them:

$ sudo strace -ofirefox-install.trace -efsync dpkg --force-unsafe-io
-i ./firefox_85.0.1-1_amd64.deb
(Reading database ... 194419 files and directories currently installed.)
...
test@debian:~$ grep fsync firefox-install.trace* | wc -l
64

test@debian:~$ sudo strace -ofirefox-install.trace -efsync dpkg -i
./firefox_85.0.1-1_amd64.deb
(Reading database ... 194419 files and directories currently installed.)
...
test@debian:~$ grep fsync firefox-install.trace* | wc -l
117

Maybe dpkg would either extend --force-unsafe-io's scope or add
--force-all-unsafe-io to skip all fsync()-s.

Cheers,
Balint

> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#982461: apt: Please provide a configuration option for disabling fsync()-s

[Balint Reczey]

Source: apt
Version:
Severity: wishlist

Hi,

I run eatmydata apt ... frequently and it is used widely by others
when there is no need to fsync()-s during package installations or
removals, but it is nice to save time and wear off SSDs later.

Using fsync() is unlikely to bring any benefit when a system is very
unlikely to crash or it is cheap to recreate in case of an
installation failure like it is the case for provisioning containers.
Also using fsync is fairly pointless when apt-btrfs-snapshot is
installed and a snapshot is taken after the apt operation anyway.

Ideally dpkg would provide a command line option for skipping fsync,
but it is not yet the case: #923423.

On APT's side I'd like to propose a config option which when set would
prefix dpkg calls with eatmydata until dpkg has a better interface for
disabling fsyncs.

apt-btrfs-snapshot and similar tools could ship a config file snippet
setting the option,

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Balint Reczey]

Hi Sebastian,

On Sun, Apr 12, 2020 at 1:09 AM Sebastian Andrzej Siewior
 wrote:
>
> On 2018-03-11 21:51:05 [+0100], Balint Reczey wrote:
> > For the recompressed firefox .deb (Ubuntu's
> > firefox_58.0.2+build1-0ubuntu0.17.10.1_amd64.deb) increased ~9% in
> > size but decompressed in <20% of the original time:
>
> So you are saying that the decompression speed that is the bottleneck
> here? I *assumed* that it is mostly the disk speed since I get around 60
> to 80MiB/sec out of xz.

I would not say bottleneck, but a very big contributor to the CPU time
used. Some systems can have very slow IO and very fast CPU, but I
think those typically correlate positively and SSDs are more common
than spinning disks improving the typical IO speed.

> > $ du -s firefox-*deb
> > 43960 firefox-xz.deb
> > 47924 firefox-zstd.deb
>
>   48M linux-image-5.5.0-1-amd64_5.5.13-2_amd64.data.tar.xz
>   54M linux-image-5.5.0-1-amd64_5.5.13-2_amd64.data.tar.19.zstd
>
>  766M linux-image-5.5.0-1-amd64-dbg_5.5.13-2_amd64.data.tar.xz
>  901M linux-image-5.5.0-1-amd64-dbg_5.5.13-2_amd64.data.tar.19.zstd
>
> zstd -19 -T16
> |linux-image-5.5.0-1-amd64-dbg_5.5.13-2_amd64.data.tar : Completed in 287.37 
> sec  (cpu load : 1533%)
> |
> |real4m47,416s
> |user73m23,825s
> |sys 0m2,753s
> |
>
> xz -T16
> | real4m15,447s
> | user66m51,572s
> | sys 0m3,201s
>
>
> > $ rm -rf firefox-xz/* ;time  dpkg-deb -R firefox-xz.deb firefox-xz/
> > real 0m4,270s
> > user 0m4,220s
> > sys 0m0,630s
> > $ rm -rf firefox-zstd/* ;time  dpkg-deb -R firefox-zstd.deb firefox-zstd/
> > real 0m0,765s
> > user 0m0,556s
> > sys 0m0,462s
>
> So this looks impressive. Is dpkg-deb also performing sync() on the
> output or is the report when the files hit the disk cache? Either way,
> should be noticeable on ssd/nvme which write at higher performance.
>
> > Tests on the full Ubuntu main archive showed ~6% average increase in
> > the size of the binary packages.
>
> I guess the vast majority of packages are small and hardly increase in
> size. The bigger packages then increase more.

Yes, the increase ratio seem to be approximately uniform, looking at
the data posted by Julian, thus bigger packages increase more:
https://lists.ubuntu.com/archives/ubuntu-devel/2018-March/040245.html

> > The patches are also available on Salsa [2].
>
> While I read the whole thread here, I did not find any consent other
> than discuss it d-devel. Is this still the case?

Yes, ideally the divergence should be avoided thus we are waiting if
the package format could be set to stone in Debian.

Cheers,
Balint

--
Balint Reczey
Ubuntu & Debian Developer

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Balint Reczey]

On Fri, Jan 8, 2021 at 8:54 PM Balint Reczey
 wrote:
>
> Control: retitle -1 dpkg: Please add decompression support for zstd
> (Zstandard) compressed packages

And the updated patch I forgot to attach.

-- 
Balint Reczey
Ubuntu & Debian Developer
From b32b384666cd7ef61f61d7ba4761b03bd61af776 Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Thu, 8 Mar 2018 09:53:36 +0100
Subject: [PATCH] dpkg: Add Zstandard compression and decompression support for
 binary packages

---
 README   |   1 +
 configure.ac |   2 +
 debian/control   |   3 +
 debian/rules |   1 +
 dpkg-deb/Makefile.am |   1 +
 dpkg-deb/extract.c   |   1 +
 dpkg-deb/main.c  |   7 ++
 lib/dpkg/compress.c  | 157 ++-
 lib/dpkg/compress.h  |   1 +
 m4/dpkg-libs.m4  |   7 ++
 man/deb.pod  |   6 +-
 t-func/deb-format.at |  26 +++
 12 files changed, 210 insertions(+), 3 deletions(-)

diff --git a/README b/README
index dd5a70fac..898369b7c 100644
--- a/README
+++ b/README
@@ -73,6 +73,7 @@ To enable optional functionality or programs, this software might be needed:
 
   libmd (used by libdpkg, currently falling back to embedded code)
   libz (from zlib, used instead of gzip command-line tool)
+  libzstd (from libzstd, used instead of zstd command-line tool)
   liblzma (from xz utils, used instead of xz command-line tool)
   libbz2 (from bzip2, used instead of bzip2 command-line tool)
   libselinux
diff --git a/configure.ac b/configure.ac
index 10d2ad278..7d9151376 100644
--- a/configure.ac
+++ b/configure.ac
@@ -88,6 +88,7 @@ AC_SYS_LARGEFILE
 # Checks for libraries.
 DPKG_LIB_MD
 DPKG_LIB_Z
+DPKG_LIB_ZSTD
 DPKG_LIB_BZ2
 DPKG_LIB_LZMA
 DPKG_LIB_SELINUX
@@ -279,6 +280,7 @@ Configuration:
 libselinux  . . . . . . . . . : $have_libselinux
 libmd . . . . . . . . . . . . : $have_libmd
 libz  . . . . . . . . . . . . : $have_libz
+libzstd  . . . . . . . . . .  : $have_libzstd
 liblzma . . . . . . . . . . . : $have_liblzma
 libbz2  . . . . . . . . . . . : $have_libbz2
 libcurses . . . . . . . . . . : ${have_libcurses:-no}
diff --git a/debian/control b/debian/control
index 52f4d8986..0df054b0e 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,9 @@ Build-Depends:
 # Needed for --porefs defaults, conditional addenda and mode=eof.
  po4a (>= 0.59),
  zlib1g-dev,
+ zstd,
  libbz2-dev,
+ libzstd-dev,
  liblzma-dev,
  libselinux1-dev [linux-any],
  libncurses-dev (>= 6.1+20180210) | libncursesw5-dev,
@@ -56,6 +58,7 @@ Multi-Arch: same
 Depends:
  ${misc:Depends},
  zlib1g-dev,
+ libzstd-dev,
  liblzma-dev,
  libbz2-dev,
 Description: Debian package management static library
diff --git a/debian/rules b/debian/rules
index fde5388a5..87c74bfee 100755
--- a/debian/rules
+++ b/debian/rules
@@ -65,6 +65,7 @@ build-tree/config.status:
 		--with-devlibdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
 		--without-libmd \
 		--with-libz \
+		--with-libzstd \
 		--with-liblzma \
 		--with-libbz2
 
diff --git a/dpkg-deb/Makefile.am b/dpkg-deb/Makefile.am
index 02d79ed7d..bbd30e02c 100644
--- a/dpkg-deb/Makefile.am
+++ b/dpkg-deb/Makefile.am
@@ -21,5 +21,6 @@ dpkg_deb_LDADD = \
 	../lib/dpkg/libdpkg.la \
 	$(LIBINTL) \
 	$(Z_LIBS) \
+	$(ZSTD_LIBS) \
 	$(LZMA_LIBS) \
 	$(BZ2_LIBS)
diff --git a/dpkg-deb/extract.c b/dpkg-deb/extract.c
index d0f6cb6c4..bf2d782a4 100644
--- a/dpkg-deb/extract.c
+++ b/dpkg-deb/extract.c
@@ -180,6 +180,7 @@ extracthalf(const char *debar, const char *dir,
   decompressor = compressor_find_by_extension(extension);
   if (decompressor != COMPRESSOR_TYPE_NONE &&
   decompressor != COMPRESSOR_TYPE_GZIP &&
+  decompressor != COMPRESSOR_TYPE_ZSTD &&
   decompressor != COMPRESSOR_TYPE_XZ)
 ohshit(_("archive '%s' uses unknown compression for member '%.*s', "
  "giving up"),
diff --git a/dpkg-deb/main.c b/dpkg-deb/main.c
index 17ed92b18..d728af748 100644
--- a/dpkg-deb/main.c
+++ b/dpkg-deb/main.c
@@ -108,7 +108,11 @@ usage(const struct cmdinfo *cip, const char *value)
 "  --[no-]uniform-compression   Use the compression params on all members.\n"
 "  -z#  Set the compression level when building.\n"
 "  -Z Set the compression type used when building.\n"
+#ifdef ENABLE_ZSTD_COMPRESSOR
+" Allowed types: gzip, xz, zstd, none.\n"
+#else
 " Allowed types: gzip, xz, none.\n"
+#endif
 "  -S Set the compression strategy when building.\n"
 " Allowed values: none; extreme (xz);\n"
 " filtered, huffman, rle, fixed (gzip).\n"
@@ -245,6 +249,9 @@ int main(int argc, const char *const *argv) {
   if (opt

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Balint Reczey]

Control: retitle -1 dpkg: Please add decompression support for zstd
(Zstandard) compressed packages

Hi Guillem,

On Fri, Apr 20, 2018 at 5:04 AM Guillem Jover  wrote:
>
> Hi!
>
> On Wed, 2018-04-18 at 11:56:27 +0200, Balint Reczey wrote:
> > On Mon, Apr 16, 2018 at 3:51 AM, Balint Reczey
> >  wrote:
> > > On Sun, Mar 18, 2018 at 3:38 AM, Guillem Jover  wrote:
> > >> On Sun, 2018-03-11 at 21:51:05 +0100, Balint Reczey wrote:
> > >>> Package: dpkg
> > >>> Version: 1.19.0.5
> > >>> Severity: wishlist
> > >>> Tags: patch
> > >>
> > >>> Please add support for Zstandard compression to dpkg and other
> > >>> programs generated by the dpkg source package [1].
> > >>
> > >> Thanks. I started implementing this several weeks ago after having
> > >> discussed it with Julian Andres Klode on IRC, but stopped after seeing
> > >> the implementation getting messy given the current code structure.
> > >
> > > I think it is not that bad. :-)
>
> Well, that file is a mess already. :)
>
> > >> So, the items that come to mind (most from the dpkg FAQ [F]:
> > >>
> > >> * Availability in general Unix systems would be one. I think the code
> > >>   should be portable, but I've not checked properly.
> > >
> > > The libzstd package does not have any special dependency and there are
> > > packages for other Unix-like systems [2][3][4].
>
> Right, as suspected, but it's nice to get confirmation, thanks.
>
> > >> * Size of the shared library another, it would be by far the fattest
> > >>   compression lib used by dpkg. It's not entirely clear whether the
> > >>   shlib embeds a zlib library?
> > >
> > > I agree that the libzstd library is fairly big and I'd like to look
> > > into ways of making it leaner, maybe creating a variant with limited
> > > features covering what is needed in dpkg, apt, btrfs-progs and other
> > > system packages.
>
> That could be an option, ideally sanctioned by upstream to avoid a
> perpetual fork, and possible divergence from upstream format, encoding,
> etc.
>
> > > It does not seem to embed the zlib library, but it offers many
> > > features which may be obsolete for dpkg.
> > >
> > > I tried dropping support for legacy file formats for example
> > > (ZSTD_LEGACY_SUPPORT=8) and the size of the library dropped to 382K
> > > from the original 490K.
>
> Still a pretty fat. :)
>
> > >> * Increase in the (build-)essential set (directly and transitively).
> > >
> > > Yes, that's true, while apt also started supporting Zstd and .
>
> apt is not part of the essential-set though.
>
> > >> * It also seems the format has changed quite some times already, and
> > >>   it's probably the reason for the fat shlib. Not sure if the format
> > >>   has stabilized enough to use this as good long-term storage format,
> > >>   and what's the policy regarding supporting old formats for example,
> > >>   given that this is intended mainly to be used for real-time and
> > >>   streaming content and similar. For example the Makefile for libzstd
> > >>   defaults to supporting v0.4+ only, which does not look great.
> > >
> > > Format stability is a very valid concern and upstream claims the
> > > current format to be stable [5] (since zstd v0.8.1).
>
> I understand that to mean the current format will not change, but what
> will happen when and iff a new format is needed/wanted, what's their
> stability guarantees, etc.? As I mentioned, one thing is to target
> streaming compression, the other long-term storage; the time-frames
> expected from each of those might be completely opposite.
>
> > >> * The license seems fine, as being very permissive, or it could affect
> > >>   availability. This one I need to add to the FAQ.
> > >> * Memory usage seemed fine or slight better depending on the compression
> > >>   level, but not when wanting equal or less space used?
> > >> * Space used seemed worse.
> > >
> > > Yes, space used is worse than with xz compression, but I think the
> > > much better compression and decompression speed would make up for
> > > that.
>
> That still depends at least on the local hardware used and on the
> network speed.
>
> > >> * Compression and decompression speed seemed better depending on the
> > >>   compression and decompression levels.
>

Bug#977422: News entry is not shown on upgrades

[Balint Reczey]

Hi,

On Tue, 15 Dec 2020 00:30:55 +0100 Michael Biebl  wrote:
> Package: apt-listchanges
> Version: 3.22+nmu2
> Severity: important
>
> Hi,
>
> sometimes, apt-listchanges doesn't show NEWS entries when it is supposed
> to show them.
> I suspect this happens, when a src package builds multiple binary
> packages and the NEWS entry is not from the "main" binary package.
>
> A specific case is src:systemd which builds the udev package
> See 
> https://salsa.debian.org/systemd-team/systemd/-/merge_requests/113#note_207684
> which illustrates the problem.
>
> If I upgrade udev alone, the NEWS entry for udev is shown.
> If I upgrade all binary packages from src:systemd, the NEWS entry is not
> shown.
>
> The test VM is still available, so if you want me to run further
> diagnostics, please let me know.

Apparently this depends on the order of the packages being processed:

qroot@hh-systemd-proposed2:~# apt-listchanges --which news
udev_247.1-4ubuntu1_amd64.deb systemd_247.1-4ubuntu1_amd64.deb  | cat
apt-listchanges: Reading changelogs...
apt-listchanges: News
-

systemd (247-4ubuntu1) hirsute; urgency=medium

  KERNEL API INCOMPATIBILITY: Linux 4.14 introduced two new uevents
  "bind" and "unbind" to the Linux device model. When this kernel
  change was made, systemd-udevd was only minimally updated to handle
  and propagate these new event types. The introduction of these new
  uevents (which are typically generated for USB devices and devices
  needing a firmware upload before being functional) resulted in a
  number of issues which we so far didn't address. We hoped the kernel
  maintainers would themselves address these issues in some form, but
  that did not happen. To handle them properly, many (if not most) udev
  rules files shipped in various packages need updating, and so do many
  programs that monitor or enumerate devices with libudev or sd-device,
  or otherwise process uevents. Please note that this incompatibility
  is not fault of systemd or udev, but caused by an incompatible kernel
  change that happened back in Linux 4.14, but is becoming more and
  more visible as the new uevents are generated by more kernel drivers.

  To learn more about the required udev rules changes please check the
  "CHANGES WITH 247" section of /usr/share/doc/systemd/NEWS.gz.

 -- Balint Reczey   Fri, 11 Dec 2020 18:22:42 +0100

root@hh-systemd-proposed2:~# apt-listchanges --which news
systemd_247.1-4ubuntu1_amd64.deb udev_247.1-4ubuntu1_amd64.deb |cat
apt-listchanges: Reading changelogs...
root@hh-systemd-proposed2:~#

(Tested on Ubuntu Hirsute)

Cheers,
Balint

Bug#977346: unattended-upgrades: Does not find packages, that can be upgraded

[Balint Reczey]

Hi Paul,

On Mon, Dec 14, 2020 at 12:06 PM Paul Menzel  wrote:
>
> Dear Balint,
>
>
> Thank you very much for the quick response.
>
>
> Am 14.12.20 um 11:58 schrieb Balint Reczey:
>
> > On Mon, Dec 14, 2020 at 10:03 AM Paul Menzel  wrote:
>
> […]
>
> >> On one user laptop with Debian sid/unstable, unattended-upgrades does
> >> not find upgradable packages.
> >>
> >>   From a dry run:
> >>
> >> ```
> >> 2020-12-14 09:51:17,335 INFO Checking if system is running on battery is 
> >> skipped. Please install powermgmt-base package to check power status and 
> >> skip installing updates when the system is running on battery.
> >> 2020-12-14 09:51:17,339 INFO Starting unattended upgrades script
> >> 2020-12-14 09:51:17,339 INFO Allowed origins are: 
> >> origin=Debian,codename=buster,label=Debian, 
> >> origin=Debian,codename=buster,label=Debian-Security, 
> >> origin=Debian,codename=buster-security,label=Debian-Security
> >> 2020-12-14 09:51:17,339 INFO Initial blacklist:
> >> 2020-12-14 09:51:17,339 INFO Initial whitelist (not strict):
> >> 2020-12-14 09:51:22,899 INFO No packages found that can be upgraded 
> >> unattended and no pending auto-removals
> >> 2020-12-14 09:51:22,900 INFO The list of kept packages can't be calculated 
> >> in dry-run mode.
> >> ```
> >>
> >> But upgradable packages are there:
> >>
> >> ```
> >> $ apt list --upgradable
> >> Listing... Done
> >> autoconf/unstable,unstable 2.69-12 all [upgradable from: 2.69-11.1]
> >> dde-qt5integration/unstable 5.0.0-2.1+b2 amd64 [upgradable from: 
> >> 5.0.0-2.1+b1]
> >> fonts-font-awesome/unstable,unstable 5.0.10+really4.7.0~dfsg-4 all 
> >> [upgradable from: 5.0.10+really4.7.0~dfsg-2]
> >> gcc-8-base/unstable 8.4.0-5 amd64 [upgradable from: 8.3.0-7]
> >> gir1.2-gdkpixbuf-2.0/unstable 2.42.2+dfsg-1 amd64 [upgradable from: 
> >> 2.40.0+dfsg-10]
> > ...
> >> systemd/unstable 247.1-4 amd64 [upgradable from: 247.1-3]
> >> udev/unstable 247.1-4 amd64 [upgradable from: 247.1-3]
> >> $ sudo apt upgrade
> >> Reading package lists... Done
> >> Building dependency tree
> >> Reading state information... Done
> >> Calculating upgrade... Done
> >> The following packages were automatically installed and are no longer
> >> required:
> >> libboost-filesystem1.71.0 libboost-iostreams1.71.0
> >> Use 'sudo apt autoremove' to remove them.
> >> The following NEW packages will be installed:
> >> libboost-filesystem1.74.0 libboost-iostreams1.74.0
> >> libboost-thread1.74.0 libdeflate0
> >> The following packages have been kept back:
> >> gcc-8-base libboost-dev
> >> The following packages will be upgraded:
> >> autoconf dde-qt5integration fonts-font-awesome gir1.2-gdkpixbuf-2.0
> > ...
> >> systemd-timesyncd udev
> >> 116 upgraded, 4 newly installed, 0 to remove and 2 not upgraded.
> >> Need to get 101 MB of archives.
> >> After this operation, 6,711 kB of additional disk space will be used.
> >> Do you want to continue? [Y/n]
> >> ```
> >>
> >> Is that expected, or am I missing something?
> >
> > This (or something like that) is expected in unstable due to the fix in 
> > #960966.
> >
> > Please change /etc/apt/apt.conf.d/50unattended-upgrades if you want
> > u-u to try very hard to upgrade things:
> >
> > ...
> > // When APT fails to mark a package to be upgraded or installed try 
> > adjusting
> > // candidates of related packages to help APT's resolver in finding a 
> > solution
> > // where the package can be upgraded or installed.
> > // This is a workaround until APT's resolver is fixed to always find a
> > // solution if it exists. (See Debian bug #711128.)
> > // The fallback is enabled by default, except on Debian's sid release 
> > because
> > // uninstallable packages are frequent there.
> > // Disabling the fallback speeds up unattended-upgrades when there are
> > // uninstallable packages at the expense of rarely keeping back packages 
> > which
> > // could be upgraded or installed.
> > // Unattended-Upgrade::Allow-APT-Mark-Fallback "true";
>
> Thank you for the hint, but I still do not understand, why it works on
> other systems. Are the kept back packages a problem? Could a log message
> be added to `unattended-upgrades.log`?

APT found the upgrades on those, probably because different packages
are installed.

Yes, kept back packages are the ones making APT's work harder in
finding the upgradable ones.

When running without --dry-mode u-u already prints out more
information about held back packages.

More explanation _could_ be added, but this workaround is on by
default only in Sid and people using Sid are expected to figure out
things on their own thus I don't plan working on that part. Patches
are still welcome.

Cheers,
Balint

>
>
> Kind regards,
>
> Paul
>
>
> > --
> > Balint Reczey
> > Ubuntu & Debian Developer
>
> Your signature delimiter is missing a space at the end [1]. ;-)
>
>
> [1]: https://en.wikipedia.org/wiki/Signature_block#Standard_delimiter



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#977346: unattended-upgrades: Does not find packages, that can be upgraded

[Balint Reczey]

Control: tags -1 confirmed

Hi Paul,

On Mon, Dec 14, 2020 at 10:03 AM Paul Menzel  wrote:
>
> Package: unattended-upgrades
> Version: 2.7
> Severity: normal
>
>
> Dear Debian folks,
>
>
> On one user laptop with Debian sid/unstable, unattended-upgrades does
> not find upgradable packages.
>
>  From a dry run:
>
> ```
> 2020-12-14 09:51:17,335 INFO Checking if system is running on battery is
> skipped. Please install powermgmt-base package to check power status and
> skip installing updates when the system is running on battery.
> 2020-12-14 09:51:17,339 INFO Starting unattended upgrades script
> 2020-12-14 09:51:17,339 INFO Allowed origins are:
> origin=Debian,codename=buster,label=Debian,
> origin=Debian,codename=buster,label=Debian-Security,
> origin=Debian,codename=buster-security,label=Debian-Security
> 2020-12-14 09:51:17,339 INFO Initial blacklist:
> 2020-12-14 09:51:17,339 INFO Initial whitelist (not strict):
> 2020-12-14 09:51:22,899 INFO No packages found that can be upgraded
> unattended and no pending auto-removals
> 2020-12-14 09:51:22,900 INFO The list of kept packages can't be
> calculated in dry-run mode.
> ```
>
> But upgradable packages are there:
>
> ```
> $ apt list --upgradable
> Listing... Done
> autoconf/unstable,unstable 2.69-12 all [upgradable from: 2.69-11.1]
> dde-qt5integration/unstable 5.0.0-2.1+b2 amd64 [upgradable from:
> 5.0.0-2.1+b1]
> fonts-font-awesome/unstable,unstable 5.0.10+really4.7.0~dfsg-4 all
> [upgradable from: 5.0.10+really4.7.0~dfsg-2]
> gcc-8-base/unstable 8.4.0-5 amd64 [upgradable from: 8.3.0-7]
> gir1.2-gdkpixbuf-2.0/unstable 2.42.2+dfsg-1 amd64 [upgradable from:
> 2.40.0+dfsg-10]
...
> systemd/unstable 247.1-4 amd64 [upgradable from: 247.1-3]
> udev/unstable 247.1-4 amd64 [upgradable from: 247.1-3]
> $ sudo apt upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following packages were automatically installed and are no longer
> required:
>libboost-filesystem1.71.0 libboost-iostreams1.71.0
> Use 'sudo apt autoremove' to remove them.
> The following NEW packages will be installed:
>libboost-filesystem1.74.0 libboost-iostreams1.74.0
> libboost-thread1.74.0 libdeflate0
> The following packages have been kept back:
>gcc-8-base libboost-dev
> The following packages will be upgraded:
>autoconf dde-qt5integration fonts-font-awesome gir1.2-gdkpixbuf-2.0
...
> systemd-timesyncd udev
> 116 upgraded, 4 newly installed, 0 to remove and 2 not upgraded.
> Need to get 101 MB of archives.
> After this operation, 6,711 kB of additional disk space will be used.
> Do you want to continue? [Y/n]
> ```
>
> Is that expected, or am I missing something?

This (or something like that) is expected in unstable due to the fix in #960966.

Please change /etc/apt/apt.conf.d/50unattended-upgrades if you want
u-u to try very hard to upgrade things:

...
// When APT fails to mark a package to be upgraded or installed try adjusting
// candidates of related packages to help APT's resolver in finding a solution
// where the package can be upgraded or installed.
// This is a workaround until APT's resolver is fixed to always find a
// solution if it exists. (See Debian bug #711128.)
// The fallback is enabled by default, except on Debian's sid release because
// uninstallable packages are frequent there.
// Disabling the fallback speeds up unattended-upgrades when there are
// uninstallable packages at the expense of rarely keeping back packages which
// could be upgraded or installed.
// Unattended-Upgrade::Allow-APT-Mark-Fallback "true";

Cheers,
Balint

--
Balint Reczey
Ubuntu & Debian Developer

Bug#976792: libwireshark11: library is huge

[Balint Reczey]

Control: tags -1 upstream confirmed
Control: severity -1 wishlist
Control: reassign -1 src:wireshark

Hi Matt,

On Tue, Dec 8, 2020 at 12:51 AM Matt Taggart  wrote:
>
> Package: libwireshark11
> Version: 2.6.8-1.1
> Severity: normal
>
> Is it normal for libwireshark.so.11.1.8 to be almost 80MB? It's by far
> the largest library on my system. The next largest is libLLVM-7.so.1 at
> 58MB, and then some other toolkit and compiler libs below 50MB and then
> it drops off quickly with 99% of system libraries being under 1MB.
> strip(1) doesn't seem to reduce it, but maybe there is some bloat in
> there that's not supposed to be?

It contains dissectors for many protocols and also a good part of the
dissectors' code is autogenerated.
The situation is known by upstream [1] and it may be worth taking a new look.

Cheers,
Balint

[1] https://www.wireshark.org/lists/wireshark-dev/200911/msg4.html

Bug#973611: libverto: Please consider switching to libevent

[Balint Reczey]

Hi Sam,

Thank you for the quick response.

On Mon, Nov 2, 2020 at 2:46 PM Sam Hartman  wrote:
>
> So, the main reason we're using libev is that upstream krb5 uses libev.
> I think they do because libev is a smaller more self contained code base
> than libevent, and because honestly the KDC isn't normally a performance
> bottleneck, so it doesn't much matter.

Good point, size of code base also matters.

> That said, I think libverto in Debian should support all the options,
> and certainly should support libevent.
> That won't make things easier for Ubuntu really, if they want to avoid
> building libverto against libev, but it will let Debian users use
> libevent if that's what they want.

In general I agree with offering the choice, but in that particular
package's case I saw no prior indication of any user wanting to use
libverto-libevent1 rather than libverto-libev1. I see that you
maintain krb5, too. What advantage do you see in providing
libverto-libevent1, too, that would make the extra complexity worth
it? In fact maintaining the Ubuntu delta would become slightly more
complicated.

Cheers,
Balint

> I'd love a merge proposal that turns on libevent and leaves libev
> present, and will eventually try to get to that myself if you aren't
> interested in submitting that.


--
Balint Reczey
Ubuntu & Debian Developer

Bug#973611: libverto: Please consider switching to libevent

[Balint Reczey]

Source: libverto
Version: 0.3.1-1
Severity: wishlist

Hi,

Libverto can be built against either libevent of libev and in Ubuntu
we build it against libevent because long time ago libevent was chosen
to be in the main repository earlier than libev was considered [1].

The benchmarks comparing libev and libevent I've found are very dated
[2] and also the test methodology is questioned [3].

I don't have a better benchmark thus I can't say the libevent is
clearly better than libev, but libevent upstream seemed to be more
active in the recent years and uses decent technology for making it
easy to work with the project compared to libev, where as I see the
code is maintained in CVS and the but tracker seems to be a low
traffic mailing list.

Disclaimer: I'm the libevent package maintainer in Debian.

Given that I could not prove libevent being a clearly better choice
I've filed a merge proposal on Salsa [4] but I don't mind if it is not accepted.

Comments are welcome! Maybe someone has a more recent benchmark or
experience in a project where both libraries were tested and they
performed differently.

Cheers,
Balint

[1] https://bugs.launchpad.net/ubuntu/+source/libverto/+bug/906281
[2] http://libev.schmorp.de/bench.html
[3] https://github.com/libevent/libevent/issues/342
[4] https://salsa.debian.org/debian/libverto/-/merge_requests/3
-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#970611: src:barrier: fails to migrate to testing for too long: FTBFS on mips*el

[Balint Reczey]

On Sat, 19 Sep 2020 21:28:53 +0200 Paul Gevers  wrote:
> Source: barrier
> Version: 2.3.2+dfsg-1
> Severity: serious
> Tags: sid bullseye
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
>
> Dear maintainer(s),
>
> As recently announced [1], the Release Team now considers packages that
> are out-of-sync between testing and unstable for more than 60 days as
> having a Release Critical bug in testing. Your package src:barrier in
> its current version in unstable has been trying to migrate for 61 days
> [2]. Hence, I am filing this bug.
>

Attaching the fix I'm uploading to DELAYED/0.

Cheers,
Balint
diff --git a/debian/changelog b/debian/changelog
index e631bb07..f8a6fb4a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+barrier (2.3.3+dfsg-1.1) unstable; urgency=medium
+
+  * Non maintainer upload.
+  * lib/ipc: Introduce writef_void(void*, ...) to fix ambiguity with
+writef(barrier::IStream*, ...) and thus fix FTBFS
+(Closes: #970611)
+
+ -- Balint Reczey   Thu, 22 Oct 2020 22:09:11 +0200
+
 barrier (2.3.3+dfsg-1) unstable; urgency=medium
 
   * New upstream version 2.3.3+dfsg.
diff --git a/debian/patches/0002-lib-ipc-Introduce-writef_void-void.patch b/debian/patches/0002-lib-ipc-Introduce-writef_void-void.patch
new file mode 100644
index ..ca8db99a
--- /dev/null
+++ b/debian/patches/0002-lib-ipc-Introduce-writef_void-void.patch
@@ -0,0 +1,49 @@
+From bd0c671fcc9732c9d1ccf5216f34f4629640b9fb Mon Sep 17 00:00:00 2001
+From: Balint Reczey 
+Date: Thu, 22 Oct 2020 22:00:18 +0200
+Subject: [PATCH] lib/ipc: Introduce writef_void(void*, ...)
+
+to fix ambiguity with writef(barrier::IStream*, ...)
+---
+ src/lib/barrier/ProtocolUtil.cpp | 4 ++--
+ src/lib/barrier/ProtocolUtil.h   | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/lib/barrier/ProtocolUtil.cpp b/src/lib/barrier/ProtocolUtil.cpp
+index e742687f..21ba38fc 100644
+--- a/src/lib/barrier/ProtocolUtil.cpp
 b/src/lib/barrier/ProtocolUtil.cpp
+@@ -80,7 +80,7 @@ ProtocolUtil::vwritef(barrier::IStream* stream,
+ 
+ // fill buffer
+ UInt8* buffer = new UInt8[size];
+-writef(buffer, fmt, args);
++writef_void(buffer, fmt, args);
+ 
+ try {
+ // write buffer
+@@ -339,7 +339,7 @@ ProtocolUtil::getLength(const char* fmt, va_list args)
+ }
+ 
+ void
+-ProtocolUtil::writef(void* buffer, const char* fmt, va_list args)
++ProtocolUtil::writef_void(void* buffer, const char* fmt, va_list args)
+ {
+ UInt8* dst = static_cast(buffer);
+ 
+diff --git a/src/lib/barrier/ProtocolUtil.h b/src/lib/barrier/ProtocolUtil.h
+index 9930cfc0..e01a6e60 100644
+--- a/src/lib/barrier/ProtocolUtil.h
 b/src/lib/barrier/ProtocolUtil.h
+@@ -79,7 +79,7 @@ private:
+ const char* fmt, va_list);
+ 
+ static UInt32getLength(const char* fmt, va_list);
+-static voidwritef(void*, const char* fmt, va_list);
++static voidwritef_void(void*, const char* fmt, va_list);
+ static UInt32eatLength(const char** fmt);
+ static voidread(barrier::IStream*, void*, UInt32);
+ };
+-- 
+2.25.1
+
diff --git a/debian/patches/series b/debian/patches/series
index 0635bdc7..fcd4e248 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 use-system-gtest.patch
+0002-lib-ipc-Introduce-writef_void-void.patch

Bug#972552: Buster->Sid upgrades fail with 'Could not perform immediate configuration on 'libnss-nis:amd64''

[Balint Reczey]

Control: reassign -1 apt
Control: forcemerge 953260 -1
Control: affects 953260 libnss-nis

Hi Otto,

This is tracked in Ubuntu, too:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1871268

Cheers,
Balint

On Tue, Oct 20, 2020 at 10:12 AM Otto Kekäläinen  wrote:
>
> Package: libnss-nis
> Version: 3.1-4
>
> In my regular Buster to Sid upgrade testing I noticed that apt upgrade
> runs started failing one week ago with the error message:
>
> Processing triggers for libc-bin (2.31-4) ...
> E: Could not configure 'libc6:amd64'.
> E: Could not perform immediate configuration on 'libnss-nis:amd64'.
> Please see man 5 apt.conf under APT::Immediate-Configure for details.
> (2)
>
> Apt exit code is 100.
>
> The next apt run goes fine and the error is not permanent. I am filing
> this bug report anyway, as I suspect that having a apt-get exit code
> 100 in the middle of a standard upgrade is not the intended design for
> the overall user experience.
>
>
> Steps to reproduce:
>
> host$ docker run -it debian:buster bash
> docker$ echo 'deb http://deb.debian.org/debian sid main' > 
> /etc/apt/sources.list
> docker$ apt-get update
> docker$ apt-get install -y libnss-nis
> 
> Unpacking libc-bin (2.31-4) over (2.28-10) ...
> Setting up libc-bin (2.31-4) ...
> Selecting previously unselected package krb5-locales.
> (Reading database ... 6762 files and directories currently installed.)
> Preparing to unpack .../krb5-locales_1.17-10_all.deb ...
> Unpacking krb5-locales (1.17-10) ...
> Setting up krb5-locales (1.17-10) ...
> E: Could not configure 'libc6:amd64'.
> E: Could not perform immediate configuration on 'libnss-nis:amd64'.
> Please see man 5 apt.conf under APT::Immediate-Configure for details.
> (2)
> docker$ echo $?
> 100
>
>
> Running 'apt-get install -y -oApt::Immediate-Configure=true
> libnss-nis'  does not make the error go away.
>
>
> The issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953260 is
> potentially related.
>


-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#968379: wireshark-common: versioned dependency on libsystemd0 breaks installability with elogind

[Balint Reczey]

Hi Cristian,

On Sun, Aug 16, 2020 at 6:42 PM Cristian Ionescu-Idbohrn
 wrote:
>
> On Fri, 14 Aug 2020, Balint Reczey wrote:
> >
> > Wireshark parses systemd journals and for doing so it depends on
> > libsystemd0.
> > The version it depends on is controlled only by the used symbols and
> > wireshark only build-depends on libsystemd-dev.
>
> But Balint, reassigning that bug to elogind won't help Thorsten, nor
> me, nor anyone else using another init.
>
> Is that a poor upstream decision?  Isn't there a way to package
> wireshark with that troublesome filter in a separate package?  After
> all, _nothing_ should depend on the init system choice.

As a workaround you can use equivs to install a dummy package that
Provides: libsystemd0 (99:99) to satisfy wireshark-common's
dependencies and lose only the ability to dissect journals which most
likely you are not interested in ;-).

I think there is an agreement with elogind's maintainer and upstream
about the way this should be fixed so there is no need for workarounds
in wireshark.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#968379: wireshark-common: versioned dependency on libsystemd0 breaks installability with elogind

[Balint Reczey]

Control: reassign -1 libelogind0 243.7-1+debian1

Hi Thorsten,

On Fri, Aug 14, 2020 at 3:03 AM Thorsten Glaser  wrote:
>
> Package: wireshark-common
> Version: 3.2.6-1
> Severity: important
> X-Debbugs-Cc: t...@mirbsd.de
>
> I cannot upgrade wireshark-common (and thus wireshark-qt) from 3.2.5-1
> to 3.2.6-1 because the latter introduced a version into the libsystemd0
> dependency. This seems to have been done with no reason, considering it
> is not documented in the Debian changelog.

Wireshark parses systemd journals and for doing so it depends on libsystemd0.
The version it depends on is controlled only by the used symbols and
wireshark only build-depends on libsystemd-dev.

With systemd 246 the wireshark build started using the following
symbol, due to changes in libsystemd-dev:

root@sid-new:~# objdump -T
/usr/lib/x86_64-linux-gnu/wireshark/extcap/sdjournal  | grep 246
  DF *UND*   LIBSYSTEMD_246
sd_journal_enumerate_available_data

libelogind0 provides only libsystemd0 (= 243.7) which I understand
since keeping up with systemd upstream is hard, but other packages
will pick up versioned dependency on later libsystemd0 like wireshark
so eventually moving the provided version will be needed. IMO the most
forward-proof direction is providing newer libsystemd0 versions in
libelogind0 thus I'm reassigning the bug.

Thanks,
Balint

>
> Please revert this, because otherwise, wireshark-qt is not installable
> on systemd-less systems.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
> 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
>
> Versions of packages wireshark-common depends on:
> ii  debconf [debconf-2.0]  1.5.74
> ii  libc6  2.31-3
> ii  libcap21:2.42-2
> ii  libcap2-bin1:2.42-2
> ii  libelogind0 [libsystemd0]  243.7-1+debian1
> ii  libgcrypt201.8.6-2
> ii  libglib2.0-0   2.64.4-1
> ii  libmaxminddb0  1.3.2-1
> ii  libnl-3-2003.4.0-1+b1
> ii  libnl-genl-3-200   3.4.0-1+b1
> ii  libpcap0.8 1.9.1-4
> ii  libspeexdsp1   1.2~rc1.2-1.1
> ii  libssh-gcrypt-40.9.4-1
> ii  libwireshark13 3.2.6-1
> ii  libwiretap10   3.2.6-1
> ii  libwsutil113.2.6-1
> ii  zlib1g 1:1.2.11.dfsg-2
>
> Versions of packages wireshark-common recommends:
> pn  wireshark | tshark  
>
> wireshark-common suggests no packages.
>
> -- debconf information:
>   wireshark-common/setcap-failed:
> * wireshark-common/install-setuid: true
>   wireshark-common/group-is-user-group:
>   wireshark-common/addgroup-failed:
>   wireshark-common/group-removal-failed:



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#958883: unattended-upgrades pegs CPU at 100% for an extended period

[Balint Reczey]

Hi Matt,

On Sat, Aug 1, 2020 at 12:03 AM Matt Taggart  wrote:
>
> I am also seeing unattended upgrade consume 100% CPU. Attached is a
> image of the cpu usage that started upon upgrade to buster. Each time uu
> runs the system has 30-40mins of 100% cpu spinning.
>
> The system is running the current buster version, 1.11.2.
>
> I see:
> #958883 (this bug) - fixed in 2.4, might be the same issue?
> #899366 - fixed in 1.4
> #960966 - still open but strace seems different
>
> The last things I see in strace -f are:
>
> 
> recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=NULL,
> iov_len=0}], msg_iovlen=1, msg_controllen=0,
> msg_flags=MSG_CTRUNC|MSG_TRUNC|MSG_CMSG_CLOEXEC},
> MSG_PEEK|MSG_TRUNC|MSG_CMSG_CLOEXEC) = 20
> recvmsg(5, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
> nl_groups=}, msg_namelen=128->12, msg_iov=[{iov_base={{len=20,
> type=NLMSG_DONE, flags=NLM_F_MULTI, seq=0, pid=31505}, 0}, iov_len=20}],
> msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CTRUNC|MSG_CMSG_CLOEXEC},
> MSG_CMSG_CLOEXEC) = 20
> brk(0x79c5000)  = 0x79c5000
> brk(0x7a1f000)  = 0x7a1f000
> mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f257770d000
> mremap(0x7f257770d000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x7f257750c000
> mremap(0x7f257750c000, 2101248, 4198400, MREMAP_MAYMOVE) = 0x7f257710b000
> 
>
> I considered trying 2.5 from testing but it wants to pull in newer apt
> and some other things.
> Is a backport of 2.5 to buster possible for testing?
> Let me know if you want me to try anything.
> This seems important enough to fix in a stable update.

There were many performance-related fixes in unattended-upgrades. The
most significant ones need newer python-apt, so a potential backport
is blocked on a python-apt backport. Also while I'd be happy to
provide a backport at the moment I can't commit to maintaining one so
it needs a volunteer to do the unattended-upgrades backport.

If you are ok with running a patched version yourself there is a fix
in flight to disable the CPU intensive parts. Please read the change
carefully because it will keep more packages back:

https://github.com/mvo5/unattended-upgrades/pull/280

Cheers,
Balint

>
> --
> Matt Taggart
> tagg...@debian.org
>


-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#960966: unattended-upgrades pegs CPU at 100% for an extended period

[Balint Reczey]

Hi,

I've opened a PR to mitigate the problem until APT's resolver gets fixed:
https://github.com/mvo5/unattended-upgrades/pull/280

Cheers,
Balint

On Tue, Jul 21, 2020 at 4:33 AM Paul Wise  wrote:
>
> Package: unattended-upgrades
> Version: 2.4
> Followup-For: Bug #960966
> Control: severity -1 important
>
> I noticed this 100% CPU usage in unattended-upgrades too.
>
> When I strace the process, it seems to be repeatedly stat()ing all the
> files that it expects to be in /var/lib/apt/lists/ over and over again,
> including both the files that exist and ones that do not exist because
> apt doesn't write empty files to disk.
>
> $ sudo strace -p 1359212 |& grep 
> deb.debian.org_debian_dists_testing_main_source_Sources
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> stat("/var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_source_Sources",
>  {st_mode=S_IFREG|0644, st_size=42687296, ...}) = 0
> ...
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#965136: libselinux: Newly versioned symbols did not bump dependency version in .symbols

[Balint Reczey]

Source: libselinux
Version: 3.1-1
Severity: grave
Tags: patch

Hi,

The switch to versioned symbols did not bump the version of the now
versioned symbols thus packages built against 3.1-1 would pick up a
dependency on the older libselinux1 package where versioned symbols
were not available causing programs to fail.

I've filed an MR in Salsa:
https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/3 .

The failure can be observed at
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/s/systemd/20200716_044131_250e2@/log.gz

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#965003: ITP: grpc-proto -- Protobuf protocol definitions for gRPC services

[Balint Reczey]

Package: wnpp
Owner: Balint Reczey 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: grpc-proto
  Version : 0.0~git20200526.dd2dca3
  Upstream Author : https://github.com/grpc/grpc-proto
* URL : https://github.com/grpc/grpc-proto
* License : Apache-2.0
  Description : Protobuf protocol definitions for gRPC services

Remote Procedure Calls (RPCs) provide a useful abstraction for building
distributed applications and services.

gRPC is a modern open source high performance RPC framework that can
run in any environment.

Protocol Buffers (Protobuf) are a flexible, efficient, automated
mechanism for serializing structured data - similar to XML, but
smaller, faster, and simpler.

This package provides the Protobuf protocol definitions (.proto files)
for gRPC services.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#796960: RFA: wordpress-shibboleth

[Balint Reczey]

Hi Dominic,

On Wed, 26 Aug 2015 09:51:40 +0100 Dominic Hargreaves  wrote:
> Package: wnpp
> Severity: normal
>
> I no longer use this software, so am not in a position to test that
> new versions work. It has a low popcon and no bugs currently, but there
> is a new upstream release to package, so I'd be pleased to have someone
> take over the package to integrate that.

I think fully orphaning the package would give it more visibility and
the QA Team could take care of it more easily.
I've just NMUd the single RC bug, but I think QA uploads are preferred
over NMUs.

Cheers,
Balint

Bug#963788: systemd: please make user order and ids of systemd and systemd-timesyncd reproducible

[Balint Reczey]

Control: reassign -1 dpkg 1.20.3
Control: affects -1 systemd

Hi All,

I agree with Chris, it would be better to find an archive-wide
solution than adding a hack to the two binary packages of systemd.
As I see the postinst scripts themselves are correct and the
nondeterminism comes from the order of executing them which is done by
dpkg, thus I'm reassigning this bug.

Cheers,
Balint

On Tue, Jun 30, 2020 at 12:51 AM Chris Lamb  wrote:
>
> [adding reproducible-bui...@lists.alioth.debian.org to CC]
>
> Johannes 'josch' Schauer wrote:
>
> > This is problem for reproducible installations because the exact same
> > package set, consisting of systemd and systemd-timesyncd can result in a
> > different system after installation.
>
> I remember working on related issues in Tails which releases
> bit-for-bit reproducible ISO images.
>
> In the end, we went with a horrible post-build script that swapped
> group IDs that were assigned non-deterministically due to the
> arbitrary execution order of the postinst scripts.
>
> I mention this here to encourage us exploring an archive-wide solution
> rather than fixing every time it comes up.
>
> This is a particularly good candidate for a general solution as, in my
> hard-won experience:
>
>  a) The non-determinism can happen infrequently and thus does not appear
> even in extensive testing.
>
>  b) There was no way to flush out the problem in CI (compare using
> disorderfs to reverse your filesystem ordering to
> deterministically flush out non-deterministic behaviour or similar
> tricks.)
>
>  c) Each test build run can take a significant amount of time.
>
>  d) The packages could be entirely unrelated. As in, it could have
> been between entirely different packages that could not have been
> fixed by adding a relationship.
>
> (Tails also has unrelated reasons for having persistent GIDs across
> builds with different inputs. I would immediately concede that
> these are out of scope for Debian itself to resolve.)
>
> I'm not sure exactly where this change could be made (dpkg? apt?) as I
> lack a confident understanding of the exact roles of those two tools,
> but I am assuming that one of these is *eventually* deciding whether to
> run the postinst for systemd or systemd-timesyncd first.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org chris-lamb.co.uk
>`-
>


-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#962471: unattended-upgrades: Duplicate log lines

[Balint Reczey]

Control: tags -1 confirmed

On Mon, Jun 8, 2020 at 4:09 PM Paul Menzel  wrote:
>
> Package: unattended-upgrades
> Version: 2.4
> Severity: normal
>
> Dear Debian folks,
>
>
> Looking through `/var/log/unattended-upgrades/unattended-upgrades.log`,
> there are duplicate lines (last four warning lines):
>
> > 2020-06-06 15:48:38,161 INFO Writing dpkg log to 
> > /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
> > 2020-06-06 15:48:47,354 INFO While building minimal partition: cache has 
> > not allowed changes
> > 2020-06-06 16:02:43,082 INFO All upgrades installed
> > 2020-06-06 16:02:46,990 WARNING Keeping auto-removable 
> > libboost-system1.67.0 package(s) because it would also remove the following 
> > packages which should be kept in this step: libboost-chrono1.67.0 
> > liborcus-0.14-0
> > 2020-06-06 16:02:47,623 WARNING Keeping auto-removable 
> > libboost-filesystem1.67.0 package(s) because it would also remove the 
> > following packages which should be kept in this step: liborcus-0.14-0
> > 2020-06-06 16:02:50,622 WARNING Keeping auto-removable 
> > libboost-iostreams1.67.0 package(s) because it would also remove the 
> > following packages which should be kept in this step: liborcus-0.14-0
> > 2020-06-06 16:02:53,437 INFO Packages that were successfully auto-removed: 
> > libboost-date-time1.67.0 libboost-locale1.67.0 libboost-thread1.67.0 
> > python3-gst-1.0
> > 2020-06-06 16:02:53,437 INFO Packages that are kept back: 
> > libboost-filesystem1.67.0 libboost-iostreams1.67.0 libboost-system1.67.0
> > 2020-06-06 16:02:53,636 INFO Package cpp-8 is kept back because a related 
> > package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:53,662 INFO Package gcc-8-base is kept back because a 
> > related package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:53,710 INFO Package libboost-dev is kept back because a 
> > related package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:53,733 INFO Package libgcc1 is kept back because a related 
> > package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:53,793 INFO Package libmpx2 is kept back because a related 
> > package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:53,979 INFO Package sshfs is kept back because a related 
> > package is kept back or due to local apt_preferences(5).
> > 2020-06-06 16:02:59,108 INFO Checking if system is running on battery is 
> > skipped. Please install powermgmt-base package to check power status and 
> > skip installing updates when the system is running on battery.
> > 2020-06-06 16:02:59,113 INFO Starting unattended upgrades script
> > 2020-06-06 16:02:59,113 INFO Allowed origins are: 
> > origin=Debian,codename=sid,label=Debian, 
> > origin=Debian,codename=sid,label=Debian-Security, 
> > origin=Debian,codename=sid-security,label=Debian-Security
> > 2020-06-06 16:02:59,113 INFO Initial blacklist:
> > 2020-06-06 16:02:59,114 INFO Initial whitelist (not strict):
> > 2020-06-06 16:03:00,568 WARNING package cpp-8 upgradable but fails to be 
> > marked for upgrade (E:Unable to correct problems, you have held broken 
> > packages.)
> > 2020-06-06 16:03:01,885 WARNING package cpp-8 upgradable but fails to be 
> > marked for upgrade (E:Unable to correct problems, you have held broken 
> > packages.)
> > 2020-06-06 16:03:07,462 WARNING package libmpx2 upgradable but fails to be 
> > marked for upgrade (E:Unable to correct problems, you have held broken 
> > packages.)
> > 2020-06-06 16:03:08,536 WARNING package libmpx2 upgradable but fails to be 
> > marked for upgrade (E:Unable to correct problems, you have held broken 
> > packages.)
>
> This is confusing. If the duplicates are useful, it’d be great to have
> more context in the log.

The problem is that it is hard to exactly explain why a package can't
be installed. Briefly it is because APT could not find an upgrade
solution where it can be upgraded and that's what unattended-upgrades
can tell.

Cheers,
Balint

>
>
> Kind regards,
>
> Paul
>



--
Balint Reczey
Ubuntu & Debian Developer

Bug#960280: wireshark: segfault during column manipulation

[Balint Reczey]

Control: tags -1 moreinfo

Hi Feri,

On Mon, May 11, 2020 at 3:48 PM Ferenc Wágner  wrote:
>
> Package: wireshark
> Version: 2.6.8-1.1
> Severity: normal
>
> Dear Maintainer,
>
> While I was fiddling with the column setup, wireshark received a SIGSEGV
> and crashed.  I'll keep the core file around for some time in case
> there's interest; the backtrace starts like this:
>
> (gdb) bt full
> #0  __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:173
> No locals.
> #1  0x55d011cf0dbc in recent_get_column_width (col=) at 
> ./ui/recent.c:1431
> col_l = 0x55d015bacfa0 = {0x7f27d002c300, 0x55d0170123d0}
> col_w = 0x7f27d002c300
> cfmt = 6
> cfield = 0x0
> #2  0x55d011c069d0 in ColumnEditorFrame::on_buttonBox_accepted 
> (this=0x55d01399c590) at ./ui/qt/column_editor_frame.cpp:143
> width = 
> xalign = 
> col_str = {d = 0x55d016490200}
> #3  0x55d011ba5bc1 in ColumnEditorFrame::qt_static_metacall 
> (_a=0x7ffc7bd4d930, _id=6, _c=QMetaObject::InvokeMetaMethod, 
> _o=0x55d01399c590)
> at 
> ./obj-x86_64-linux-gnu/ui/qt/qtui_autogen/EWIEGA46WW/moc_column_editor_frame.cpp:155
> _t = 
> result = 
> #4  ColumnEditorFrame::qt_metacall (this=0x55d01399c590, 
> _c=QMetaObject::InvokeMetaMethod, _id=6, _a=0x7ffc7bd4d930)
> at 
> ./obj-x86_64-linux-gnu/ui/qt/qtui_autogen/EWIEGA46WW/moc_column_editor_frame.cpp:155
> No locals.
> #5  0x7f27e52b88b7 in QMetaObject::activate(QObject*, int, int, void**) 
> () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> No symbol table info available.
> [...]
>
> I can't reproduce the crash, it took several operations to get there
> (like adding, removing and editing columns).

If you find the steps to reproduce it  please add them later.

Thanks,
Balint


--
Balint Reczey
Ubuntu & Debian Developer

Bug#960267: autopkgtest: Reports skipped tests even when single test is requested with --test-name

[Balint Reczey]

Package: autopkgtest
Version: 5.13.1
Severity: minor

Hi,

When requesting running a single test autopkgtest also reports that
tests were skipped, but it is not actually true, since the only
requested test was successful.

# autopkgtest systemd --test-name=unit-config -- null
...
autopkgtest [10:08:36]: test unit-config:  - - - - - - - - - - results
- - - - - - - - - -
unit-config  PASS
autopkgtest [10:08:36]:  summary
boot-and-servicesSKIP Test breaks testbed but testbed does not
provide revert-full-system
root-unittests   SKIP Test breaks testbed but testbed does not
provide revert-full-system
boot-smoke   SKIP Test breaks testbed but testbed does not
provide revert-full-system
systemd-fsckdSKIP Test breaks testbed but testbed does not
provide revert-full-system
unit-config  PASS
# echo $?
2

This makes checking the result of a single test a bit more complicated
in scripts running autopkgtest.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#956436: systemd-timesyncd will remove virtualbox-guest-utils

[Balint Reczey]

Hi Michael,

On Sun, Apr 12, 2020 at 7:58 PM Michael Biebl  wrote:
>
> Am 12.04.20 um 19:40 schrieb Balint Reczey:
> > Hi Michael,
> >
> > On Sat, Apr 11, 2020 at 9:53 PM Michael Biebl  wrote:
> >>
> >> Am 11.04.20 um 10:02 schrieb luca:
> >>> Package: systemd-timesyncd
> >>> Version: 245.4-3
> >>> Severity: normal
> >>>
> >>>
> >>> # apt-get -V dist-upgrade
> >>> Reading package lists... Done
> >>> Building dependency tree
> >>> Reading state information... Done
> >>> Calculating upgrade... Done
> >>> The following packages were automatically installed and are no longer 
> >>> required:
> >>>libnotify-bin (0.7.9-1)
> >>>libqpdf26 (9.1.1-1)
> >>> Use 'apt autoremove' to remove them.
> >>> The following packages will be REMOVED:
> >>>virtualbox-guest-utils (6.1.4-dfsg-4)
> >>>virtualbox-guest-x11 (6.1.4-dfsg-4)
> >>
> >> Balint, I guess we should drop
> >> Conflicts: virtualbox-guest-utils,
> >>virtualbox-guest-utils-hwe
> >> ?
> >
> > Ah, yes, sorry, I did think about that, but forgot to propose the
> > solution in the MR.
> >
> > IMO systemd-timesyncd should be the default time-daemon but also the
> > least preferred option to install, when some other installed package
> > can sync the time.
> >
> > I think the cleanest solution would be virtualbox source building a
> > binary package that Conflicts/Provides/Replaces: time-daemon and sets
> > up time synchronisation with the host (
> > https://www.virtualbox.org/manual/ch09.html#changetimesync )
>
> Nod, I think that package actually is virtualbox-guest-utils?

Virtualbox-guest-utils ships other utils which could be useful even if
time synchronization should be done by a proper time-daemon, so a new
binary package could make sense, but virtualbox-guest-utils can indeed
just that package as well.

>
> > If this solution is not viable, then I think the second best option is
> > considering virtualbox-guest-utils as a time-daemon alternative:
> >
> > AFAIK when virtualbox-guest-utils* is installed the guest's clock can
> > be considered to be synchronised to the host and hopefully
> > transitively to a reasonably good source, so I propose changing
> > systemd instead to depend on systemd-timesyncd | time-daemon |
> > virtualbox-guest-utils | virtualbox-guest-utils-hwe.  This solution
> > has the disadvantage of not being able to install systemd-timesyncd
> > when virtualbox-guest-utils is present, but should not sync time with
> > the host. IMO this is not a huge problem, since other time-daemon-s
> > can still be installed such as chrony, so the guest can still have
> > accurate time, just not with systemd-timesyncd.
>
> I would prefer not to add virtualbox-guest-utils* as an alternative
> Depends.
>
> > Cheers,
> > Balint
> >
> > PS: virtualbox-guest-utils is in contrib, but per #681419 it can still
> > be used as an alternate dependency.
>
> I guess I'll drop the conflicts and clone/reassign this bug report to
> virtualbox and leave it up to them to decide if it should be possible to
> install an NTP client alongside virtualbox-guest-utils* or not (and if
> the latter, to add a C/R/P: time-daemon)

Thanks, that's fair.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#956436: systemd-timesyncd will remove virtualbox-guest-utils

[Balint Reczey]

Hi Michael,

On Sat, Apr 11, 2020 at 9:53 PM Michael Biebl  wrote:
>
> Am 11.04.20 um 10:02 schrieb luca:
> > Package: systemd-timesyncd
> > Version: 245.4-3
> > Severity: normal
> >
> >
> > # apt-get -V dist-upgrade
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > Calculating upgrade... Done
> > The following packages were automatically installed and are no longer 
> > required:
> >libnotify-bin (0.7.9-1)
> >libqpdf26 (9.1.1-1)
> > Use 'apt autoremove' to remove them.
> > The following packages will be REMOVED:
> >virtualbox-guest-utils (6.1.4-dfsg-4)
> >virtualbox-guest-x11 (6.1.4-dfsg-4)
>
> Balint, I guess we should drop
> Conflicts: virtualbox-guest-utils,
>virtualbox-guest-utils-hwe
> ?

Ah, yes, sorry, I did think about that, but forgot to propose the
solution in the MR.

IMO systemd-timesyncd should be the default time-daemon but also the
least preferred option to install, when some other installed package
can sync the time.

I think the cleanest solution would be virtualbox source building a
binary package that Conflicts/Provides/Replaces: time-daemon and sets
up time synchronisation with the host (
https://www.virtualbox.org/manual/ch09.html#changetimesync )

If this solution is not viable, then I think the second best option is
considering virtualbox-guest-utils as a time-daemon alternative:

AFAIK when virtualbox-guest-utils* is installed the guest's clock can
be considered to be synchronised to the host and hopefully
transitively to a reasonably good source, so I propose changing
systemd instead to depend on systemd-timesyncd | time-daemon |
virtualbox-guest-utils | virtualbox-guest-utils-hwe.  This solution
has the disadvantage of not being able to install systemd-timesyncd
when virtualbox-guest-utils is present, but should not sync time with
the host. IMO this is not a huge problem, since other time-daemon-s
can still be installed such as chrony, so the guest can still have
accurate time, just not with systemd-timesyncd.

Cheers,
Balint

PS: virtualbox-guest-utils is in contrib, but per #681419 it can still
be used as an alternate dependency.

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#956031: RM: kerneloops -- ROM; became useless

[Balint Reczey]

Package: ftp.debian.org
Severity: normal

Please remove kerneloops from the archive.

It became useless because the service collecting the logs stopped: #953172

Thanks,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#955483: Alphanumeric ordering of depending sockets breaks restart

[Balint Reczey]

Hi,

On Thu, 2 Apr 2020 13:10:13 +0200 Michael Biebl  wrote:
> Am 02.04.20 um 12:45 schrieb Christian Ehrhardt:
> > On Thu, Apr 2, 2020 at 10:54 AM Michael Biebl  wrote:
> >>
> >> I don't think this is going to work.
> >>
> >> You'll need to restart both the service and socket in the correct order,
> >
> > @Michael:
> > I have tried "systemctl restart service socket socket" before and it works.
> > But I was wondering if it might work just by accident, due to the service 
> > being
> > not yet fully up when the sockets restart. And I was unsure if this
> > could be racy.
> > Are you saying this is "the right order" and this way around systemd
> > will take care
> > that service and sockets won't collide in a bad way?
>
> No, I don't know for sure.

IMO the restart of sockets worked by accident because it was OK to
restart then when the service is not running.
When the service is running systemd can't restart the socket safely
and thus IMO systemd is right denying the operation.

Systemd could implement systemctl restart -r  where it
would find what and in which order should be restarted to have a
restart of the set of units and it would do stops then starts when the
ordering required that. For example it would do stop foo.service ;
restart foo.socket; start foo.service, etc.

I think it would be very complicated or to implement that reliably in
dh_installsystemd or in deb-systemd-invoke partly because local
configuration could also impact the order and set of units to restart.
In the meantime deb-systemd-invoke could fallback to do systemctl stop
...; systemctl start when restarts fail.

Cheers,
Balint

Bug#955511: xbmc-pvr-addons: Should be removed from testing

[Balint Reczey]

Source: xbmc-pvr-addons
Severity: serious

Hi,

The source builds only transitional packages and they are not needed anymore.
After removing them from testing they can be removed from unstable as well.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#953172: kerneloops: service http://oops.kernel.org no longer available

[Balint Reczey]

Control: severity -1 serious
Control: tags -1 help upstream

Hi Arno,

On Thu, Mar 5, 2020 at 3:21 PM Arno Peters  wrote:
>
> Source: kerneloops
> Version: 0.12+git20140509-6
> Severity: normal
>
> Dear Maintainer,
>
> The server at http://oops.kernel.org is no longer accepting submissions.  As
> far as I can see, this has been the case since 2017.  The developer mentions a
> migration of code at that time in an open issue on github.  The corresponding
> issue was never closed.
>
> This package is therefore no longer relevant or useful. In my opinion, it
> should be removed from the Debian repository.

Agreed.
I'm bumping the severity to start the removal from testing.

We had a few conversations with upstream, but there seems to be no one
 interested in running the service.
See: https://lwn.net/Articles/799278/

It could maybe be a useful service to run within Debian's
infrastructure. If anyone is interested please let the upstream
developer know.

Thanks,
Balint

>
> -- System Information:
> Debian Release: 10.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), 
> LANGUAGE=nl_NL.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled



--
Balint Reczey
Ubuntu & Debian Developer

Bug#839961: libjs-d3: please package new upstream release

[Balint Reczey]

Hi,

On Mon, Feb 10, 2020 at 10:39 PM László Böszörményi (GCS)
 wrote:
>
> Hi Paul, Balint,
>
> On Wed, Jan 15, 2020 at 3:51 PM Balint Reczey
>  wrote:
> > On Wed, 23 Jan 2019 20:12:56 +0100 Paul Gevers  wrote:
> > > On Thu, 06 Oct 2016 22:03:43 +0200 Paul Gevers  wrote:
> > > > Upstream d3 is very active and currently runs at 4.2.6. Please consider
> > > > updating the libjs-d3 package.
> > >
> > > Any progress on this? I'd love to have the new version in Buster. I
> > > offer help if you need or want it.
>  There's definitely need for help, please read on.

Whenever this is the case please use Debian's standard practices to
announce that:
https://www.debian.org/devel/wnpp/

> > I believe the state of this package is a perfect fit for salvaging:
> > https://wiki.debian.org/PackageSalvaging
>  It's a bit more complex situation while it's clear it's my bad that
> no activity shown on this package.
>
> > I'd like to have a fresh d3 in next Ubuntu LTS and also in Bullseye,
> > but I don't have enough free time now to salvage the package myself.
> > :-(
>  Wanted to go into details, but let me be brief now. When I packaged
> D3.js it was one source tree only with dependencies packaged. Then its
> build system switched to rollup, not packaged back then. With time it
> further evolved and became highly modularized, meaning multiple source
> tarballs.
> Currently it has 45 (forty-five) modules, depending on each other like
> a tree structure. Random check showed at least one of these has
> unpackaged other JavaScript dependency. In really short, just see the
> top level D3.js dependency list[1] which shows 31 (thirty-one)
> immediate D3 modules dependency. That means about 50+ (fifty+)
> JavaScript packages need to be created, uploaded and accepted to the
> archives.
> Do you know anyone who can take such a huge task?

This is a very good question in general, and the immediate answer is
not "It's me!" from the maintainer (or "It's us!" in case of a team
maintaining the package) then I'd recommend looking for help in
maintenance.
For this particular package I'd recommend bringing it under the Debian
Javascript Maintainers Team's umbrella who already maintain node-d3
which has v5 in experimental.

Cheers,
Balint

> @Balint: What's the best way to talk with you in personally? A meeting
> or a phone call would do; maybe a chat on some platform.
>
> Regards,
> Laszlo/GCS
> [1] https://github.com/d3/d3/blob/master/package.json



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#951276: default webinterface non-functional

[Balint Reczey]

On Thu, Feb 27, 2020 at 7:02 PM Gilles Filippini  wrote:
>
> Hi,
>
> Bálint Réczey a écrit le 26/02/2020 à 18:24 :
> > Control: tags -1 help
> > Control: block -1 by 851663
> >
> > Hi Gilles,
> >
> > Bálint Réczey  ezt írta (időpont: 2020. febr.
> > 25., K, 23:32):
> >>
> >> Hi,
> >>
> >> Gilles Filippini  ezt írta (időpont: 2020. febr. 25.,
> >> K, 23:12):
> >>>
> >>> Hi,
> >>>
> >>> On Thu, 13 Feb 2020 17:48:57 +0100 Roderich Schupp
> >>>  wrote:
>  Package: kodi-data
>  Version: 2:18.5+dfsg1-1~exp0
>  Severity: normal
> 
>  The default webinterface shows just a header bar,
>  see attached screenshot.
> 
>  The webinterface.default included in the Debian package is
>  seriously outdated, the current Kodi v18 webinterface
>  is here: https://github.com/xbmc/chorus2/releases/tag/18.x-2.4.6
> >>>
> >>> d/README.source says:
>  Kodi replaced the default webinterface in 17.0 beta6 but the new 
>  interface contains
>  many generated files without providing the source for them. The web 
>  interface
>  is temporarily reverted to the one included in beta5 to restore GPL 
>  compliance.
> >>>
> >>> And Balint filed a related upstream issue:
> >>> https://github.com/xbmc/chorus2/issues/179
> >>>
> >>> @Balint, from your last comment on this issue it seems the only
> >>> litigious material left is the screenshots. Are these images requested
> >>> for running the chorus2 web interface? Couldn't they be removed from the
> >>> upstream source package until they are fixed?
> >>
> >> The upstream source needs a new review to see which files should be 
> >> dropped.
> >> If those are just a few images like the screenshots I'm ready to
> >> create a new +dfsg2 source and ship the new web interface.
> >>
> >> Help is very welcome here, since I'm currently busy with other
> >> packages, but otherwise the kodi 18 packages are close to ready for
> >> upload to unstable.
>
> I'd be happy to help. But I'm not at ease on this very topic. I've just
> recently discovered kodi. I'm still wondering about installing it. I'd
> like a fully functionnal server installation, accesed from the
> webinterface only.
>
> > I took a look and the situation did improve license-wise, but Kodi ships
> > addons/webinterface.default/js/kodi-webinterface.js which is a
> > minimized version of
> > https://github.com/xbmc/chorus2 . It needs to be packages separately,
> > see, the linked RFP bug.
> >
> > When Chorus2 is  shipped in Debian properly rebuilding it from source
> > then the kodi package can switch to using it.
>
> I have no experience at all packaging such a software. How about first
> repacking kodi with Chorus2 source tree so it could quickly enter
> experimental, then splitting it out into a separate package once it is
> functionnal?

A much better approach IMO is dropping the addon from kodi-data binary
package and providing the current drop-in web interface as a temporary
binary package that chorus2 will replace.

Cheers,
Balint
Ubuntu & Debian Developer

Bug#951906: python-apt: Please provide apt_pkg.Cache.upgrade() option to also install new packages

[Balint Reczey]

Package: python-apt
Version: 1.9.6
Severity: wishlist

Dear APT Maintainers,

Apt.Cache.upgrade(dist_upgrade=False) currently has two modes, one
allowing only upgrades, one installing new packages and also allowing
removals.
I'd like to use this function in unattended-upgrades allowing
installation of new dependencies, but not allowing removals.

Please consider supporting this upgrade method, too.

Thanks,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#950873: libwireshark-dev: Missing a header file required by present header

[Balint Reczey]

Control: merge  950871 -1
Control: tags -1 confirmed pending

On Fri, Feb 7, 2020 at 4:51 PM Thorsten Schulz
 wrote:
>
> Package: libwireshark-dev
> Version: 3.2.1-1
> Severity: normal
>
> Dear Maintainer,
>
> While trying to build an external dissector, I am including 
> . (FYI: 
> https://github.com/T12z/TCNopen/tree/master/trdp/spy/src/trdp_spy -- I am 
> working on adding deb-packaging ;) )
> However, the included epan/plugin_if.h itself includes , which is 
> not packaged by any non-source package. Thus, compilation is impossible w/o 
> pulling the full source of wireshark.
>
> It would be nice for easy packaging, to have that dependent header cfile.h 
> included in some *-dev package.

Thanks, will be fixed in next upload.

Cheers,
Balint

--
Balint Reczey
Ubuntu & Debian Developer

Bug#839961: libjs-d3: please package new upstream release

[Balint Reczey]

Hi Paul and Laszlo,

On Wed, 23 Jan 2019 20:12:56 +0100 Paul Gevers  wrote:
> Hi,
>
> On Thu, 06 Oct 2016 22:03:43 +0200 Paul Gevers  wrote:
> > Upstream d3 is very active and currently runs at 4.2.6. Please consider
> > updating the libjs-d3 package.
>
> Any progress on this? I'd love to have the new version in Buster. I
> offer help if you need or want it.

I believe the state of this package is a perfect fit for salvaging:
https://wiki.debian.org/PackageSalvaging

I'd like to have a fresh d3 in next Ubuntu LTS and also in Bullseye,
but I don't have enough free time now to salvage the package myself.
:-(

Cheers,
Balint

Bug#883804: vmdk-stream-converter: Python2 removal in sid/bullseye

[Balint Reczey]

Control: tags -1 pending

Hi,

I've uploaded a fixed package to DELAYED/10.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#942440: transition: libevent

[Balint Reczey]

On Mon, Nov 11, 2019 at 11:07 PM Paul Gevers  wrote:
>
> Control: tags -1 confirmed
>
> Hi Balint,
>
> On 16-10-2019 13:44, Balint Reczey wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > Dear Release Team,
> >
> > I would like to update libevent in unstable.
> >
> > I have performed test rebuilds [1] in Ubuntu 19.10 which found no
> > libenvent-specific FTBFS issue.
>
> Please go ahead.

Uploaded, thanks.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#942440: transition: libevent

[Balint Reczey]

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

Dear Release Team,

I would like to update libevent in unstable.

I have performed test rebuilds [1] in Ubuntu 19.10 which found no
libenvent-specific FTBFS issue.

 In terms of 'ben' lingo, the transition has the following parameters:

Affected: .depends ~
/\b(libevent\-2\.1\-7|libevent\-core\-2\.1\-7|libevent\-extra\-2\.1\-7|libevent\-openssl\-2\.1\-7|libevent\-pthreads\-2\.1\-7|libevent\-2\.1\-6|libevent\-core\-2\.1\-6|libevent\-extra\-2\.1\-6|libevent\-openssl\-2\.1\-6|libevent\-pthreads\-2\.1\-6)\b/
Good: .depends ~
/\b(libevent\-2\.1\-7|libevent\-core\-2\.1\-7|libevent\-extra\-2\.1\-7|libevent\-openssl\-2\.1\-7|libevent\-pthreads\-2\.1\-7)\b/
Bad: .depends ~
/\b(libevent\-2\.1\-6|libevent\-core\-2\.1\-6|libevent\-extra\-2\.1\-6|libevent\-openssl\-2\.1\-6|libevent\-pthreads\-2\.1\-6)\b/

Cheers,
Balint

[1]: https://launchpad.net/~rbalint/+archive/ubuntu/scratch4/+packages
--
Balint Reczey
Ubuntu & Debian Developer

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[Balint Reczey]

Hi David,

On Wed, Oct 9, 2019 at 6:03 PM David Kalnischkies  wrote:
>
> On Wed, Oct 09, 2019 at 12:53:45AM +0200, Adam Borowski wrote:
> > It's not about not being available in normal use, it's because switching the
> > library's implementation is fragile -- especially if systemd's prerm fails
> > which it's notorious to.  This will make apt fail, and apt happens to be the
> > very package supposed to fix such a problem.
>
> I think systemd has to many fingers in too many areas to switch it out at
> runtime. But I also think you and everyone else reading this bugreport
> knows that better than I do. That might be unfortunate, but as a user is
> unlikely to change from and to it a lot it seems like a waste to
> optimize for potential problems in "unrelated" packages (if we called
> every package with a failing maintainer script related to apt because it
> makes apt fail, apt would be related to the entire archive).
>
> APT is also not "the very package supposed to fix such a problem". The
> entire program family is supposed to start from a consistent state and
> end in a consistent state. Some tools like apt might have a --fix-broken
> mode which tries to help if it is really easy, but the only tool which
> can help you for real if you deal with major breakage is dpkg: That not
> only knows what a maintainer script is (apt doesn't) – it is also
> essential, so it [normally] works even in inconsistent states.
>
>
> > > I expect that apt will eventually switch to using libglib's dbus support,
> > > once we implement a daemon, but that's a bit off, and that stuff might 
> > > live
> > > in a separate binary to not pull in libglib on systems that don't need a
> > > daemon.
> >
> > Would you accept a patch to move the inhibit function to a small separate
> > binary?  That'd be a very simple solution.
>
> The Inhibit() is implemented in libapt so that shutdown is inhibited for
> all libapt-based tools from aptitude to unattended-upgrades – and so
> they all gain this linkage via libapt.

For the record unattended-upgrades handles inhibition on its own
(differently) and did so before libapt added inhibition handling.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#856268: unattended-upgrades: reboot on a specific day

[Balint Reczey]

Control: tags -1 wontfix
Control: forwarded -1 https://github.com/mvo5/unattended-upgrades/issues/224

Hi Johannes,

While I see the value of not restarting on weekdays I believe adding
this feature to u-u is not the best way to go. It would add logic that
can't satisfy every use case.
For example, sometimes there are workdays on weekends, sometimes
migrations of the weekends thus a simple static rule of restarting on
Sundays may not fit.

I suggest creating a systemd timer or a cron job that fits your
preferred schedule and looks for /var/run/reboot-required and reboots
only when it is present.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#939770: wireshark: Wrong path in pre-install notification

[Balint Reczey]

Control: tags -1 pending

Hi Justin,

On Mon, Sep 9, 2019 at 8:49 PM Justin B Rye  wrote:
>
> Balint Reczey wrote:
> > Justin B Rye wrote:
> >> So instead of saying "after the package installation is finished" you
> >> might change it to something like:
> >>
> >>   For more detailed information please see
> > - /usr/share/doc/wireshark-common/README.Debian.
> > > + /usr/share/doc/wireshark-common/README.Debian.gz once the package is
> >> + installed.
> >
> > Good point. Can I apply this change as the one reviewed?
>
> If you're asking whether you can regard this as having received an
> official debian-l10n-english review, sure, as far as I'm concerned
> it's okay whether you include my bikeshedding or not.

Thanks, I pushed your proposal to the packaging repository:
https://salsa.debian.org/debian/wireshark/commit/4d21f2d33430229c693cf2999e50939a0eaf6cea

Cheers,
Balint

> --
> JBR with qualifications in linguistics, experience as a Debian
> sysadmin, and probably no clue about this particular package



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#939770: wireshark: Wrong path in pre-install notification

[Balint Reczey]

Hi Justin,

On Sun, Sep 8, 2019 at 11:48 PM Justin B Rye  wrote:
>
> Balint Reczey wrote:
> >> I suggest to change path in the question and make it clear that the
> >> file will only exist after the package is installed – even though a
> >> text mentioning it might be shown before installation is completed.
>
> Thanks for taking the trouble to deal with this!  The patch would work
> as it is, but I've thought of another complication: I might be reading
> this template when no package installation is occurring.  For a start,
> I might give an answer, wait for wireshark to be installed, read the
> README file, and then decide to run "dpkg-reconfigure wireshark" to
> get the same prompt again and give a different answer...
>
> So instead of saying "after the package installation is finished" you
> might change it to something like:
>
>   For more detailed information please see
> - /usr/share/doc/wireshark-common/README.Debian.
> + /usr/share/doc/wireshark-common/README.Debian.gz once the package is
> + installed.

Good point. Can I apply this change as the one reviewed?

Cheers,
Balint

>
> --
> JBR with qualifications in linguistics, experience as a Debian
> sysadmin, and probably no clue about this particular package



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#939770: wireshark: Wrong path in pre-install notification

[Balint Reczey]

Control: tags -1 confirmed patch
Control: found -1 1.2.9-2

Dear English Localization Team,

Please review the attached patch for fixing the issue reported below.

The current template can be found here:
https://salsa.debian.org/debian/wireshark/blob/debian/master/debian/templates

Thank you,
Balint

On Sun, Sep 8, 2019 at 6:36 PM Nils Dagsson Moskopp
 wrote:
>
> Package: wireshark
> Version: 2.6.7-1~deb9u1
> Severity: minor
>
> Dear Maintainer,
>
> in the pre-install notification about installing dumpcamp so that
> non-root users can capture packets it is displayed that users can
> read about that feature in the file at the following path:
>
> /usr/share/doc/wireshark-common/README.Debian
>
> A file does not actually exist at the path.
> After installation, it does also not exist.
> However, the following path holds the file:
>
> /usr/share/doc/wireshark-common/README.Debian.gz
>
> I suggest to change path in the question and make it clear that the
> file will only exist after the package is installed – even though a
> text mentioning it might be shown before installation is completed.

-- 
Balint Reczey
Ubuntu & Debian Developer
From 38256c713614c857c43692ab153c369b721ac42b Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Sun, 8 Sep 2019 22:30:10 +0200
Subject: [PATCH] debian/templates: Fix README.Debian's path and not that it
 needs to be installed

Change-Id: I7ebc987a8956122e1bb283d33ec3c989c5d83330
Closes: #939770
---
 debian/templates | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/templates b/debian/templates
index dc47130770..66fb399ae2 100644
--- a/debian/templates
+++ b/debian/templates
@@ -17,7 +17,8 @@ _Description: Should non-superusers be able to capture packets?
  less of the code will run with elevated privileges.
  .
  For more detailed information please see
- /usr/share/doc/wireshark-common/README.Debian.
+ /usr/share/doc/wireshark-common/README.Debian.gz after the package
+ installation is finished.
  .
  Enabling this feature may be a security risk, so it is disabled by
  default. If in doubt, it is suggested to leave it disabled.
-- 
2.17.1

Bug#934067:

[Balint Reczey]

Package: gdm3
Version: debian/3.12.1-1
Severity: important

Dear Maintainers,

Gdm3 package symlinks gdm3.service -> gdm.service but the next systemd
release will really dislike it and will mark services as failed:

test@test-Standard-PC-i440FX-PIIX-1996:~$ service gdm3 status
● gdm.service - GNOME Display Manager
   Loaded: error (Reason: Unit gdm.service failed to load properly:
File exists.)
   Active: inactive (dead)

aug 06 18:12:37 test-Standard-PC-i440FX-PIIX-1996 systemd[1]:
gdm.service: Two services allocated for the same bus name
org.gnome.DisplayManager, refusing operation.
test@test-Standard-PC-i440FX-PIIX-1996:~$ service gdm status
● gdm.service - GNOME Display Manager
   Loaded: error (Reason: Unit gdm.service failed to load properly:
File exists.)
   Active: inactive (dead)

aug 06 18:14:59 test-Standard-PC-i440FX-PIIX-1996 systemd[1]:
gdm.service: Two services allocated for the same bus name
org.gnome.DisplayManager, refusing operation.

This can already be observed with the systemd version in Ubuntu eoan-proposed.

Luckily GDM starts and lets users to log in, but the service is marked
as dead. This breaks systemd autopkgtest:

...
test_udev (__main__.ServicesTest) ... ok

==
ERROR: test_gdm3 (__main__.ServicesTest)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest.bVYr80/build.F0n/src/debian/tests/boot-and-services",
line 72, in test_gdm3
self.active_unit('gdm3')
  File "/tmp/autopkgtest.bVYr80/build.F0n/src/debian/tests/boot-and-services",
line 183, in active_unit
out = subprocess.check_output(['systemctl', 'status', unit])
  File "/usr/lib/python3.7/subprocess.py", line 395, in check_output
**kwargs).stdout
  File "/usr/lib/python3.7/subprocess.py", line 487, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['systemctl', 'status',
'gdm3']' returned non-zero exit status 3.

--
Ran 23 tests in 9.748s

FAILED (errors=1, skipped=2)
autopkgtest [04:15:47]: test boot-and-services: ---]
boot-and-servicesFAIL non-zero exit status 1

Please fix the issue to let next systemd pass autopkgtest.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#932214: wireshark: TCP statistics bad (duration, export)

[Balint Reczey]

Hi,

On Thu, Jul 25, 2019 at 3:00 PM Philipp Marek  wrote:
>
> > The wireshark command is shipped by the wireshark-qt package, you need
> > to upgrade that, too, to run a proper test.
> Ah yes, thanks.
>
> So I didn't actually test the 3.0.2 binary!?!!
>
> Why does the wireshark package allow that, and doesn't specify
> it's dependencies more detailed?

I fixed that in Salsa for the next upload, thanks.

Cheers,
Balint

Bug#932214: wireshark: TCP statistics bad (duration, export)

[Balint Reczey]

On Thu, Jul 25, 2019 at 2:43 PM Philipp Marek  wrote:
>
> Hi Balint,
>
> > Could you please report the issue upstream?
> Yes, of course ;(
>
>
> > Those are not related to packaging and upstream is very happy to help
> > directly.
> Well, a packaging point I noticed while reporting upstream:
>
>  $ dpkg-query -l wireshark
>  ii  wireshark  3.0.2-1~exp0 amd64
>
>  $ wireshark -v
>  Wireshark 2.6.8 (Git v2.6.8 packaged as 2.6.8-1.1)
>
> Is that correct, and/or on purpose? Is that a 3.0.2 or a 2.6.8?

The wireshark command is shipped by the wireshark-qt package, you need
to upgrade that, too, to run a proper test.

Cheers,
Balint


-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#932214: wireshark: TCP statistics bad (duration, export)

[Balint Reczey]

Hi Philipp,

On Tue, Jul 23, 2019 at 2:13 PM Philipp Marek  wrote:
> > Now it it in experimental, please give it a try!
>
> "Abs time" column is still wrong,
> and I get different "Duration" values[1].
>
> Ad 1: The quick test now was to click the Statistics/Connections
> menu item while the file was still loading.
> Not sure whether it happens later on as well, didn't test that
> often.

Could you please report the issue upstream?
Those are not related to packaging and upstream is very happy to help directly.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#932214: wireshark: TCP statistics bad (duration, export)

[Balint Reczey]

Control: tags -1 upstream moreinfo

On Tue, Jul 16, 2019 at 7:15 PM Philipp Marek  wrote:
>
> Package: wireshark
> Version: 2.6.9-1
> Severity: minor
>
> I've got a capture file going 1031 seconds, 2.7GB.
>
> When running the TCP connection statistics and sorting by "duration", I get
> different answers; once I got 1031 (as expected), after a wireshark restart
> with the same file I only got 820 or so.
>
> Once I tried clicking "limit to display filter" (no filter was set!),  that
> had the effect of recalculating and giving a different result.
>
>
> Furthermore, checking "absolute time" isn't honored in the CSV export;  the
> header field correctly says "Abs time",  but the numbers are still relative
> to the beginning (ie. decimal numbers >=0, instead of 12:01:55 etc.).
>
>
> I got a message that a 3.0.2 package is NEW (incoming), but I couldn't
> download that anywhere to test. Will do as soon as I see it.

Now it it in experimental, please give it a try!

Cheers,
Balint

>
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.0.0-trunk-amd64 (SMP w/8 CPU cores)
> Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_AT:de (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages wireshark depends on:
> ii  wireshark-qt  2.6.8-1.1
>
> wireshark recommends no packages.
>
> wireshark suggests no packages.
>
> -- no debconf information
>
> --



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#631715: unattended-upgrades: Sends base64-encoded MIME message when message is long

[Balint Reczey]

Control: notfound -1 0.62.2
Control: tags -1 unreproducible

Hi,

I'm pretty sure this is not a bug in unattended-upgrades.
Currently the email headers in autopkgtest runs look like this:

>From root@ci-1562886795 Thu Jul 11 23:48:16 2019
Return-path: 
Envelope-to: root@ci-1562886795
Delivery-date: Thu, 11 Jul 2019 23:48:16 +
Received: from root by ci-1562886795 with local (Exim 4.90_RC3)
(envelope-from )
id 1hlinQ-0007WZ-BF
for root@ci-1562886795; Thu, 11 Jul 2019 23:48:16 +
Subject: [package on hold] unattended-upgrades result for ci-1562886795: SUCCESS
To: root@ci-1562886795
Auto-Submitted: auto-generated
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: root 
Message-Id: 
Date: Thu, 11 Jul 2019 23:48:16 +

Unattended upgrade result: All upgrades installed
...

The problem you reported is probably the result of local configuration.

Cheers,
Balint

--
Balint Reczey
Ubuntu & Debian Developer

Bug#931649: apt: Please advise users on moved or EOL'd repositories

[Balint Reczey]

Package: apt
Version: 1.9.1
Severity: wishlist

Dear APT Maintainers,

When a repository is no longer available APT does tell that but gives
little help to the user who the issue could be resolved:

root@teaching-dolphin:~# apt update
Ign:1 http://archive.ubuntu.com/ubuntu artful InRelease
Ign:2 http://security.ubuntu.com/ubuntu artful-security InRelease
Err:3 http://security.ubuntu.com/ubuntu artful-security Release
  404  Not Found
...
Reading package lists... Done
...
E: The repository 'http://archive.ubuntu.com/ubuntu artful-backports
Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user
configuration details.
root@teaching-dolphin:~# do-release-upgrade
Checking for a new Ubuntu release
Your Ubuntu release is not supported anymore.
For upgrade information, please visit:
http://www.ubuntu.com/releaseendoflife

On the other hand if the user knows about do-release-upgrade or can
update /etc/apt/sources.list manually the system can be upgraded to a
still supported version or changed to use the new location of the
repositories if they moved.

Please consider printing hints in well known cases to help users
getting out of the situation by either suggesting upgrading the the
system or redirecting them to the new repository URLs.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#930654: base-files: mesg: ttyname failed: No such device

[Balint Reczey]

Package: base-files
Version: 10.2
Severity: normal
Tags: patch

Dear Maintainer,

Every time I log in to a Debian LXC container I get this greeting :-):

$ lxc shell sid
mesg: ttyname failed: No such device
root@sid:~#

Please consider applying the following patch or something similar to
suppress the useless error.
--
--- ./share/dot.profile
+++ ./share/dot.profile
@@ -6,4 +6,4 @@
   fi
 fi

-mesg n || true
+mesg n 2> /dev/null || true
--

Thanks,
Balint

PS:  This was a discussion already in #794727 .



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#929617: d3-format: latest-debian-changelog-entry-reuses-existing-version

[Balint Reczey]

I have uploaded an NMU with the attached patch to DELAYED/3.
Please also see the change in
https://salsa.debian.org/js-team/d3-format/merge_requests/2

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer
From bd8e713e8365dcff22a6b883a4512fc12e1d51b2 Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Sat, 8 Jun 2019 22:56:17 +0200
Subject: [PATCH] Update changelog

---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index b9b6a5a..525c5b7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+d3-format (1:1.0.2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload (Closes: #929617)
+- Bumping the version to over 1:1.0.2-3 because 1.0.2-3 was used by
+  src:node-d3-format
+
+ -- Balint Reczey   Sat, 08 Jun 2019 22:52:37 +0200
+
 d3-format (1:1.0.2-1) unstable; urgency=medium
 
   * Take back my package, thank you very much.
-- 
2.17.1

Bug#929446: marked as done (wireshark: CVE-2019-12295)

[Balint Reczey]

Hi Tobias,

Thank you for taking care of packages with open security issues, but
I'm wondering why you chose to do an immediate NMU.
I planed uploading 2.6.9-1 today following the usual process we agreed
on with the Security Team and I believe fixing this bug after 4 days
it was opened is not an excessive amount of delay especially since two
days were on a weekend.

Thanks,
Balint

On Mon, May 27, 2019 at 4:45 PM Debian Bug Tracking System
 wrote:
>
> Your message dated Mon, 27 May 2019 14:42:22 +
> with message-id 
> and subject line Bug#929446: fixed in wireshark 2.6.8-1.1
> has caused the Debian Bug report #929446,
> regarding wireshark: CVE-2019-12295
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 929446: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929446
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Salvatore Bonaccorso 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Thu, 23 May 2019 19:56:24 +0200
> Subject: wireshark: CVE-2019-12295
> Source: wireshark
> Version: 2.6.8-1
> Severity: grave
> Tags: security upstream
> Forwarded: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15778
> Control: found -1 2.6.7-1~deb9u1
>
> Hi,
>
> The following vulnerability was published for wireshark.
>
> CVE-2019-12295[0]:
> | In Wireshark 3.0.0 to 3.0.1, 2.6.0 to 2.6.8, and 2.4.0 to 2.4.14, the
> | dissection engine could crash. This was addressed in epan/packet.c by
> | restricting the number of layers and consequently limiting recursion.
>
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2019-12295
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12295
> [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15778
> [2] https://www.wireshark.org/security/wnpa-sec-2019-19.html
>
> Regards,
> Salvatore
>
>
>
> -- Forwarded message --
> From: "Dr. Tobias Quathamer" 
> To: 929446-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 27 May 2019 14:42:22 +
> Subject: Bug#929446: fixed in wireshark 2.6.8-1.1
> Source: wireshark
> Source-Version: 2.6.8-1.1
>
> We believe that the bug you reported is fixed in the latest version of
> wireshark, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 929...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Dr. Tobias Quathamer  (supplier of updated wireshark 
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Mon, 27 May 2019 16:08:44 +0200
> Source: wireshark
> Architecture: source
> Version: 2.6.8-1.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Balint Reczey 
> Changed-By: Dr. Tobias Quathamer 
> Closes: 929446
> Changes:
>  wireshark (2.6.8-1.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* CVE-2019-12295
>  In Wireshark 3.0.0 to 3.0.1, 2.6.0 to 2.6.8, and 2.4.0 to 2.4.14,
>  the dissection engine could crash. This was addressed in
>  epan/packet.c by restricting the number of layers and
>  consequently limiting recursion. (Closes: #929446)
> Checksums-Sha1:
>  638a99183f0251eae3adcddc57e683e3b925ec84 3531 wireshark_2.6.8-1.1.dsc
>  55c82bbb3e02077378a512f69f6ff8e0f4dcc5cf 71716 
> wireshark_2.6.8-1.1.debian.tar.xz
>  e4ea88d8c0ddfbc1e510b9c76d088d2229e2eebc 25763 
> wireshark_2.6.8-1.1_amd64.buildinfo
> Checksums-Sha256:
>  71f0a3be5a1360c0b2e60eda3f71fc9d771254099e2296ed0839679c61f41b5a 3531 
> wireshark_2.6.8-1.1.dsc
>  4161d9c12abceb7ffce74e581b5762f4ee49f947b06fb690b408a95be1c8bd2c 71716 
> wire

Bug#926409: lintian: autopkgtest takes very long to finish

[Balint Reczey]

Hi Chris,

On Thu, Apr 4, 2019 at 7:30 PM Chris Lamb  wrote:
>
> tags 926409 + moreinfo
> thanks
>
> Hi Balint,
>
> > Lintian has a lot of tests which is great for coverage, but maybe some
> > of them could be skipped in autopkgtest runs.
>
> Interesting. I guess I would have three follow-up questions here:
>
>  * On what criterion or criteria could we include or exclude tests
>from the autopkgtest runs? Whilst we could skip the unit tests (as
>these are "just" Perl that is unlikely to vary) the most
>interesting ones to run in terms of detecting regressions in an
>real-world environment (the entire point of autopkgtests from my
>point of view) would be the tests of the checks themselves and
>these likely constitute the vast majority of the total time.

One criterion that came to my mind is filtering by severity, including
errors for sure, but not pedantic ones.
The full suite can run during the build thus we don't loose a lot of coverage.
I hoped to rely on Lintian maintainer's judgement about what to omit.

>  * I'm not sure *how* we can speed up the tests. I mean, they all
>essentially involve building Debian packages with all the usual
>debhelper calls, etc. Speeding *this* up is somewhat out-of-scope
>of this Lintian wishlist issue, alas.

A profiling round with perf would point out a few things IMO, but as a
start I did a timestamped run here to find slowest tests:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco-rbalint-scratch/disco/arm64/l/lintian/20190404_002129_96f0c@/log.gz

If there many package builds in the tests just changing the faster
compression helps, a lot with little effort (until zstd becomes the
default ;-)).

>  * Why not simply increase Ubuntu's timeout? I would concede this is
>not the best use of CI resources, but the trade-off with "human"
>time would appear to be worth it here.

I agree, and we may increase the timeout, but the running the tests
seems to take longer in general than seems reasonable.

Cheers,
Balint

> However, perhaps Felix has some input here as he has been doing a lot
> of work on the test suite recently?
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org chris-lamb.co.uk
>`-



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#926409: lintian: autopkgtest takes very long to finish

[Balint Reczey]

Package: lintian
Version: 2.11.0
Severity: wishlist

Hi,

Lintian has a lot of tests which is great for coverage, but maybe some
of them could be skipped in autopkgtest runs.
Currently autopkgtest takes ~1 wall clock hours on Debian's amd64 CI
[1], but Ubuntu runs autopkgtest on all architectures and arm64 runs
for example take more than 3 hours [2].

Setting the tests to run in parallel helps with the wall clock time,
but still this may not be the best use of CI CPU resources or if all
tests are needed, maybe lintian itself could be sped up a bit.

Cheers,
Balint

[1] https://ci.debian.net/packages/l/lintian/unstable/amd64/
[2] http://autopkgtest.ubuntu.com/packages/l/lintian/disco/arm64

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#923064: [INTL:da] Danish translation of the debconf templates wireshark

[Balint Reczey]

No problem, thanks for updating the translation!

On Wed, Feb 27, 2019 at 6:48 PM Joe Dalton  wrote:
>
> of course sorry about that
>
>
> 
> Den tirs 26/2/19 skrev Balint Reczey :
>
>  Emne: Re: Bug#923064: [INTL:da] Danish translation of the debconf templates 
> wireshark
>  Til: "Joe Dalton" , 923...@bugs.debian.org
>  Dato: tirsdag 26. februar 2019 17.43
>
>  Control: tags -1 moreinfo
>
>  Hi Joe,
>
>  On
>  Sat, Feb 23, 2019 at 8:00 PM Joe Dalton 
>  wrote:
>  >
>  > Package:
>  wireshark
>  > Severity: wishlist
>  > Tags: l10n patch
>  >
>  > Please include the attached Danish
>  wireshark debconf po file.
>  >
>  > joe@debianbuster:~/over/debian/wireshark$
>  msgfmt --statistics -c -v -o /dev/null da.po
>  > da.po: 16 oversatte tekster.
>
>  This looks like the po file
>  for apt-listchanges. Could you please
>  attach
>  the one for wireshark?
>
>  Cheers,
>  Balint
>
>
>  --
>  Balint Reczey
>  Ubuntu &
>  Debian Developer



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#923064: [INTL:da] Danish translation of the debconf templates wireshark

[Balint Reczey]

Control: tags -1 moreinfo

Hi Joe,

On Sat, Feb 23, 2019 at 8:00 PM Joe Dalton  wrote:
>
> Package: wireshark
> Severity: wishlist
> Tags: l10n patch
>
> Please include the attached Danish wireshark debconf po file.
>
> joe@debianbuster:~/over/debian/wireshark$ msgfmt --statistics -c -v -o 
> /dev/null da.po
> da.po: 16 oversatte tekster.

This looks like the po file for apt-listchanges. Could you please
attach the one for wireshark?

Cheers,
Balint


-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#922522: ITP: waylandpp -- wayland compositor infrastructure - C++ development files

[Balint Reczey]

Package: wnpp
Owner: Balint Reczey 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: waylandpp
  Version : 0.2.4
  Upstream Author : Nils Brause
* URL : https://github.com/NilsBrause/waylandpp
* License : GPL-3+
  Programming Lang: C++
  Description : wayland compositor infrastructure - C++ development files

Wayland is a protocol for a compositor to talk to its clients as well
as a C library implementation of that protocol. The compositor can be
a standalone display server running on Linux kernel modesetting and
evdev input devices, an X application, or a wayland client
itself. The clients can be traditional applications, X servers
(rootless or fullscreen) or other display servers.

This package ships the C++ bindings for the development libraries.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

The package is a build dependency of Kodi 18 for enabling Wayland support.

I'd be happy to maintain the package under Debian X Strike Force's
umbrella if the team accepts that.

Bug#922121: libnfs: autopkgtest fails on several Ubuntu architectures

[Balint Reczey]

Control: forwarded -1 https://github.com/sahlberg/libnfs/issues/285
Control: tags -1 confirmed

Hi Jeremy,

On Tue, Feb 12, 2019, 18:12 Jeremy Bicha  Source: libnfs
> Version: 3.0.0-2
>
> Thanks for your libnfs update this week. The autopkgtest now passes on
> Ubuntu's amd64 and s390x.
>
> It still fails on arm64, i386 and ppc64el.
>
> The valgrind test fails on arm64 and ppc64el. Maybe we should only run
> the valgrind test on whitelisted architectures?
>

IMO those tests are valid and are not prohibitively expensive. Valgrind
also have to be working on those architectures thus I'd like to keep the
tests enabled.


> i386 fails because -Wall -Werror is set. In my experience, that can
> break easily.
>

Yes, I reported the issue upstream, let's see if it gets fixed there.

Cheers,
Balint


> https://autopkgtest.ubuntu.com/packages/libn/libnfs
>
> Thanks,
> Jeremy Bicha
>

Bug#921578: libnfs: autopkgtest failures on Ubuntu

[Balint Reczey]

Hi Sebastien,

On Tue, Feb 12, 2019 at 2:39 AM Sebastien Bacher  wrote:
>
> Thanks for the update/fix! I'm not on the system where I poked at that
> the other day now to verify but it looked like only the first test was
> an issue, "nfs-ls -D nfs://127.0.0.1" didn't return an error so maybe it
> was not needed to skip that one?

I re-enabled the passing ones in git but they can wait for the next upload.
I also reported the remaining failures upstream:
https://github.com/sahlberg/libnfs/issues/285

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#919766: FTBFS-es

[Balint Reczey]

Hi Barak,

On Thu, Jan 31, 2019 at 2:54 AM Barak A. Pearlmutter
 wrote:
>
> Thanks, that was very kind of you. Much appreciated. I'm in the
> process of preparing to upload.
> But next time feel free to just NMU, 0 day, tell me after, I totally don't 
> mind!
> (This goes for any of my packages.)

Thanks!

I see you have already closed the changelog in git just did not
upload. If you hold back the upload because of the current doxygen
breakage [1], then please just do a source-only upload and let it be
built when the broken build-dependencies are fixed.

[1] https://lists.debian.org/debian-science/2019/02/msg6.html

Cheers,
Balint

>
> Cheers,
>
> --Barak.



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#919555: FTBFS-es

[Balint Reczey]

Control: tags -1 + patch upstream pending

Hi,

I have prepared the fixes in Salsa [1], please upload them or I'll
upload them as an NMU in a few days.

Cheers,
Balint

[1] https://salsa.debian.org/debian/libemf/commits/master
-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#919555: libemf: FTBFS on several architectures including arm64 and s390x

[Balint Reczey]

Source: libemf
Version:  1.0.11-1
Severity: important
Tags: upstream
Justification: fails to build from source

Hi,

Builds of libemf have been failing on arm64 and s390x and the
non-release architectures ppc64 and sparc64:

See https://buildd.debian.org/status/package.php?p=libemf

Tail of log for libemf on arm64:

^~~
../include/libEMF/wine/winbase.h:1377:50: error: 'CONTEXT' does not
name a type; did you mean 'CONTEXT86'?
 BOOLWINAPI SetThreadContext(HANDLE,const CONTEXT *);
  ^~~
  CONTEXT86
make[3]: *** [Makefile:480: libemf.lo] Error 1
make[3]: Leaving directory '/<>/libemf'
make[2]: *** [Makefile:429: all-recursive] Error 1
make[2]: *** Waiting for unfinished jobs
echo Timestamp >doxygen-doc/libemf.tag
make[2]: Leaving directory '/<>'
dh_auto_build: make -j8 all doxygen-doc doxygen-pdf returned exit code 2
make[1]: *** [debian/rules:13: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: build-arch] Error 2

Tail of log for libemf on s390x:

See tests/test-suite.log
Please report to dallenbarn...@users.sourceforge.net

make[5]: *** [Makefile:733: test-suite.log] Error 1
make[5]: Leaving directory '/<>/tests'
make[4]: *** [Makefile:841: check-TESTS] Error 2
make[4]: Leaving directory '/<>/tests'
make[3]: *** [Makefile:908: check-am] Error 2
make[3]: Leaving directory '/<>/tests'
make[2]: *** [Makefile:429: check-recursive] Error 1
make[2]: Leaving directory '/<>'
dh_auto_test: make -j2 check VERBOSE=1 -j1 returned exit code 2
make[1]: *** [debian/rules:16: override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: build-arch] Error 2

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#919507: Packaging policy to flag unattended-upgrades reboot

[Balint Reczey]

Hi Karl,

Thank you for bringing this up.

On Thu, Jan 17, 2019 at 7:10 AM Karl O. Pinc  wrote:
>
> Hello,
>
> Do you have any suggestions for updating the
> Debian Policy docs so that packagers know what
> must be done to inform when an update requires
> a reboot?
>
> I filed the following bugs against debian-policy
> and systemd:
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919507
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919509
> thinking that packages are supposed to provide
> breadcrumbs so that unattended-upgrades knows when
> a package upgrade requires a reboot.
>
> I've been invited to submit a patch to Debian policy.
>
> But looking at the packaging of packages I _thought_
> flagged reboots I don't see anything.
>
> I know the kernel flags a reboot, but see that
> unattended-upgrades is dropping a config into
> /etc/kernel/postinst.d/.
>
> I thought libc6 flagged a reboot, but can't find
> anything.
>
> I've got an email from a box that flagged a
> reboot on upgrade of tomcat8, but can't find
> anything in the packaging.  Why I got an email is
> now a mystery.
>
> I would think that having the unattended-upgrade
> package have to keep track of which packages
> require reboot would not scale

I agree. I was surprised too, when I found the scripts for the kernel
in unattended-upgrades.
Please note that in Ubuntu update-notifier-common also ships a similar hook:
/etc/kernel/postinst.d/update-notifier ->
/usr/share/update-notifier/notify-reboot-required

I agree that packages should ask for reboot themselves, but I'm OK
with keeping the current logic in u-u for the kernels.

Regarding the policy change I'd also mention
/var/run/reboot-required.pkgs , like this:

Maintainer scripts can signal that a reboot is required to fully apply
the changes to the system by touching /var/run/reboot-required and
adding the package name to /var/run/reboot-required.pkgs. Maintainer
scripts should not add the package name to
/var/run/reboot-required.pkgs if it is already present there.

Thanks,
Balint

>
> Thanks.
>
> Regards,
>
> Karl 
> Free Software:  "You don't pay back, you pay forward."
>  -- Robert A. Heinlein
>
> P.S.  Somebody on #debian-mentors was able to do a
> search today for all the packages which, I think,
> contained mention of "reboot-required".  I don't
> know what they did or how they did it.
> There was a list of maybe 15 or 20 packages,
> but the remark was that some of these are
> tool-related.  (?) I forget the details.
>


-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#919027: wireshark: missing executables

[Balint Reczey]

Control: tags -1 confirmed

Hi Stefan,

On Sat, Jan 12, 2019 at 6:33 AM Stefan Pietsch  wrote:
>
> Package: wireshark-common
> Version: 2.6.6-1
> Severity: normal
>
> The wireshark-common package is missing these executable files:
>
> - captype

Adding it.

> - idl2wrs

This is already present in wireshark-dev.

> - randpkt

Adding it.

Thanks for the bug report!

Cheers,
Balint


--
Balint Reczey
Ubuntu & Debian Developer

Bug#918089: wireshark: d/copyright does not mention SAMBA's Pidl parser

[Balint Reczey]

Hi Andrius,

On Wed, Jan 9, 2019 at 9:17 PM Andrius Merkys  wrote:
>
> Hi Balint,
>
> On 2019-01-09 09:58, Balint Reczey wrote:
> > Thank you for the bug report.
> > I'm adding a reference to the GPLv3+ file and also opened the bug
> > about the pidl parser in general.
>
> thanks for the prompt reply and a fix. However, from tools/pidl/META.yml I 
> assume that not only tools/pidl/idl.yp, but the all files under tools/pidl/ 
> are subject to GPLv3.

This was not clear from the rest of the files' licensing header, they
just say 'GPL'. If only one file is convered by GPLv3+ and the rest is
GPL+ this makes the overall pidl/ project GPLv3+ so it is consistent,
but I agree that this is potentially not Samba upstream's intention.
It they care they can clarify that.

Please note that in Wireshark's source there are BSD covered while the
whole project is GPLv2+.

Cheers,
Balint

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


-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#918089: wireshark: d/copyright does not mention SAMBA's Pidl parser

[Balint Reczey]

Control: forwarded -1 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15408

Hi Andrius,

On Thu, Jan 3, 2019 at 2:33 PM Andrius Merkys  wrote:
>
> Source: wireshark
>
> Hello,
>
> wireshark source package contains embedded copy of SAMBA's Pidl parser under 
> tools/pidl/, which is not mentioned in d/copyright. As Pidl parser does not 
> seem to be used in wireshark at all, it is possibly better to exclude it from 
> the source. Otherwise libparse-pidl-perl binary package could be used.

Thank you for the bug report.
I'm adding a reference to the GPLv3+ file and also opened the bug
about the pidl parser in general.

Cheers,
Balint

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



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#916839: imagemagick: Silent ABI break in 6.9.10-11 on i386

[Balint Reczey]

Hi Bastien,

On Mon, Jan 7, 2019 at 11:17 PM Bastien ROUCARIES
 wrote:
>
> Hi,
>
> I have uploaded a newer version fixing the problem. Could you ask
> release team a rebuild.

Thanks!
I filed #918706 for the rebuilds, please follow up on it if needed.

>
> BTW could you get a glimpse at ruby-mini-magick ? It seems choked

I see this is being resolved in #918642, thanks!

Cheers,
Balint


>
> Bastien
>
> On Sat, Jan 5, 2019 at 4:08 PM Balint Reczey
>  wrote:
> >
> > Hi Bastien,
> >
> > On Fri, Jan 4, 2019 at 8:41 PM Balint Reczey
> >  wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Dec 20, 2018 at 6:46 AM Bastien ROUCARIES
> > >  wrote:
> > > >
> > > > On Wed, Dec 19, 2018 at 12:09 PM Balint Reczey
> > > >  wrote:
> > > > >
> > > > > Package: imagemagick
> > > > > Version: 8:6.9.10.14+dfsg-1
> > > > > Severity: grave
> > > > > Control: forwareded -1 
> > > > > https://github.com/ImageMagick/ImageMagick6/issues/31
> > > > > Control: tags -1 upstream fixed-upstream
> > > > > Control: affects -1 ruby-rmagick
> > > > >
> > > > > Hi,
> > > > >
> > > > > The ABI broke in 6.9.10-11 due to changing MagickDoubleType to double
> > > > > from long double.
> > > > > This breaks ruby-rmagick and possibly other reverse dependencies, thus
> > > > > after fixing imagemagick please check if some reverse dependencies
> > > > > need to be rebuilt. The fix will be available in the .18 upstream
> > > > > release.
> > > >
> > > > Exact, this will need a so bump I suppose...
> > >
> > > Since the ABI broke only in unstable and testing and only affected
> > > i386 and possibly a few rare arches not in Ubuntu I'd say a few
> > > rebuilds would suffice. Upstream did not do a major ABI bump either
> > > and released the fix.
> >
> > I have uploaded an NMU to DELAYED/5 with the attached fix, which is
> > already included in Ubuntu.
> > This will enter the archive before the transition freeze thus Buster
> > will be fixed even if no upload is made to imagemagick in the next
> > week, but feel free to override it an upload a better fix like a full
> > new upstream release.
> >
> > Cheers,
> > Balint
> >
> > >
> > > Cheers,
> > > Balint
> > >
> > > >
> > > > Bastien
> > > >
> > > >
> > > >
> > > > >
> > > > > Cheers,
> > > > > Balint
> > > > >
> > > > > --
> > > > > Balint Reczey
> > > > > Ubuntu & Debian Developer
> > > > >
> > >
> > >
> > >
> > > --
> > > Balint Reczey
> > > Ubuntu & Debian Developer
> >
> >
> >
> > --
> > Balint Reczey
> > Ubuntu & Debian Developer



--
Balint Reczey
Ubuntu & Debian Developer

Bug#918706: nmu: multiple imagemagick reverse dependencies

[Balint Reczey]

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

Dear Release Team,

Imagemagick upstream temporarily broke ABI (#916839) and the following
packages may need a binNMU as the current packages were built and
linked with the broken imagemagick libraries while they were present
in the archive:

  nmu aiscm_0.18.1-1 . ANY . -m 'Rebuild against imagemagick that
fixed ABI breakage.'
  nmu chafa_1.0.1-2 . ANY . -m 'Rebuild against imagemagick that fixed
ABI breakage.'
  nmu emacs_1:25.2+1-11 . ANY . -m 'Rebuild against imagemagick that
fixed ABI breakage.'
  nmu gem_1:0.94~pre1-1 . ANY . -m 'Rebuild against imagemagick that
fixed ABI breakage.'
  nmu graphicsmagick_1.4~hg15873-1 . ANY . -m 'Rebuild against
imagemagick that fixed ABI breakage.'
  nmu inkscape_0.92.3-7 . ANY . -m 'Rebuild against imagemagick that
fixed ABI breakage.'
  nmu pqiv_2.11-1 . ANY . -m 'Rebuild against imagemagick that fixed
ABI breakage.'
  nmu vips_8.7.2-1 . ANY . -m 'Rebuild against imagemagick that fixed
ABI breakage.'

Imagemagick already build for the release architectures but on some
ports a dependency-wait could be applied for imagemagick
(8:6.9.10.23+dfsg-1).

Thanks,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#916839: imagemagick: Silent ABI break in 6.9.10-11 on i386

[Balint Reczey]

Hi Bastien,

On Fri, Jan 4, 2019 at 8:41 PM Balint Reczey
 wrote:
>
> Hi,
>
> On Thu, Dec 20, 2018 at 6:46 AM Bastien ROUCARIES
>  wrote:
> >
> > On Wed, Dec 19, 2018 at 12:09 PM Balint Reczey
> >  wrote:
> > >
> > > Package: imagemagick
> > > Version: 8:6.9.10.14+dfsg-1
> > > Severity: grave
> > > Control: forwareded -1 
> > > https://github.com/ImageMagick/ImageMagick6/issues/31
> > > Control: tags -1 upstream fixed-upstream
> > > Control: affects -1 ruby-rmagick
> > >
> > > Hi,
> > >
> > > The ABI broke in 6.9.10-11 due to changing MagickDoubleType to double
> > > from long double.
> > > This breaks ruby-rmagick and possibly other reverse dependencies, thus
> > > after fixing imagemagick please check if some reverse dependencies
> > > need to be rebuilt. The fix will be available in the .18 upstream
> > > release.
> >
> > Exact, this will need a so bump I suppose...
>
> Since the ABI broke only in unstable and testing and only affected
> i386 and possibly a few rare arches not in Ubuntu I'd say a few
> rebuilds would suffice. Upstream did not do a major ABI bump either
> and released the fix.

I have uploaded an NMU to DELAYED/5 with the attached fix, which is
already included in Ubuntu.
This will enter the archive before the transition freeze thus Buster
will be fixed even if no upload is made to imagemagick in the next
week, but feel free to override it an upload a better fix like a full
new upstream release.

Cheers,
Balint

>
> Cheers,
> Balint
>
> >
> > Bastien
> >
> >
> >
> > >
> > > Cheers,
> > > Balint
> > >
> > > --
> > > Balint Reczey
> > > Ubuntu & Debian Developer
> > >
>
>
>
> --
> Balint Reczey
> Ubuntu & Debian Developer



-- 
Balint Reczey
Ubuntu & Debian Developer
diff -Nru imagemagick-6.9.10.14+dfsg/debian/changelog imagemagick-6.9.10.14+dfsg/debian/changelog
--- imagemagick-6.9.10.14+dfsg/debian/changelog	2018-11-05 03:09:08.0 +0700
+++ imagemagick-6.9.10.14+dfsg/debian/changelog	2019-01-05 15:40:40.0 +0700
@@ -1,3 +1,11 @@
+imagemagick (8:6.9.10.14+dfsg-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert hidden ABI break by changing MagickFloatType's size on i386
+(Closes: #916839)
+
+ -- Balint Reczey   Sat, 05 Jan 2019 15:40:40 +0700
+
 imagemagick (8:6.9.10.14+dfsg-7) unstable; urgency=medium
 
   * Bug fix: "wrong Provides: libmagickcore-6.defaultquantum-dev,
diff -Nru imagemagick-6.9.10.14+dfsg/debian/patches/0023-Revert-hidden-ABI-break-by-changing-MagickFloatType-.patch imagemagick-6.9.10.14+dfsg/debian/patches/0023-Revert-hidden-ABI-break-by-changing-MagickFloatType-.patch
--- imagemagick-6.9.10.14+dfsg/debian/patches/0023-Revert-hidden-ABI-break-by-changing-MagickFloatType-.patch	1970-01-01 07:00:00.0 +0700
+++ imagemagick-6.9.10.14+dfsg/debian/patches/0023-Revert-hidden-ABI-break-by-changing-MagickFloatType-.patch	2019-01-05 15:40:40.0 +0700
@@ -0,0 +1,31 @@
+From: Balint Reczey 
+Date: Tue, 18 Dec 2018 20:04:57 +0100
+Subject: Revert hidden ABI break by changing MagickFloatType's size on i386
+
+This reverts commit 94a86b3324bed28b4ed4a80ff0be05dc58c0023e.
+---
+ magick/magick-type.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/magick/magick-type.h b/magick/magick-type.h
+index 0fc437c..2f5e38f 100644
+--- a/magick/magick-type.h
 b/magick/magick-type.h
+@@ -46,7 +46,7 @@ typedef float MagickFloatType;
+ #elif (MAGICKCORE_SIZEOF_FLOAT_T == MAGICKCORE_SIZEOF_DOUBLE)
+ typedef double MagickFloatType;
+ #elif (MAGICKCORE_SIZEOF_FLOAT_T == MAGICKCORE_SIZEOF_LONG_DOUBLE)
+-typedef double MagickFloatType;
++typedef long double MagickFloatType;
+ #else
+ #error Your MagickFloatType type is neither a float, nor a double, nor a long double
+ #endif
+@@ -55,7 +55,7 @@ typedef double MagickDoubleType;
+ #elif (MAGICKCORE_SIZEOF_DOUBLE_T == MAGICKCORE_SIZEOF_DOUBLE)
+ typedef double MagickDoubleType;
+ #elif (MAGICKCORE_SIZEOF_DOUBLE_T == MAGICKCORE_SIZEOF_LONG_DOUBLE)
+-typedef double MagickDoubleType;
++typedef long double MagickDoubleType;
+ #else
+ #error Your MagickDoubleType type is neither a float, nor a double, nor a long double
+ #endif
diff -Nru imagemagick-6.9.10.14+dfsg/debian/patches/series imagemagick-6.9.10.14+dfsg/debian/patches/series
--- imagemagick-6.9.10.14+dfsg/debian/patches/series	2018-10-29 23:17:35.0 +0700
+++ imagemagick-6.9.10.14+dfsg/debian/patches/series	2019-01-05 15:40:40.0 +0700
@@ -20,3 +20,4 @@
 0020-Fix-end-tags.patch
 0021-Fix-remaining-error-in-documentation.patch
 0022-Fix-privacy-breach.patch
+0023-Revert-hidden-ABI-break-by-changing-MagickFloatType-.patch

Bug#916839: imagemagick: Silent ABI break in 6.9.10-11 on i386

[Balint Reczey]

Hi,

On Thu, Dec 20, 2018 at 6:46 AM Bastien ROUCARIES
 wrote:
>
> On Wed, Dec 19, 2018 at 12:09 PM Balint Reczey
>  wrote:
> >
> > Package: imagemagick
> > Version: 8:6.9.10.14+dfsg-1
> > Severity: grave
> > Control: forwareded -1 https://github.com/ImageMagick/ImageMagick6/issues/31
> > Control: tags -1 upstream fixed-upstream
> > Control: affects -1 ruby-rmagick
> >
> > Hi,
> >
> > The ABI broke in 6.9.10-11 due to changing MagickDoubleType to double
> > from long double.
> > This breaks ruby-rmagick and possibly other reverse dependencies, thus
> > after fixing imagemagick please check if some reverse dependencies
> > need to be rebuilt. The fix will be available in the .18 upstream
> > release.
>
> Exact, this will need a so bump I suppose...

Since the ABI broke only in unstable and testing and only affected
i386 and possibly a few rare arches not in Ubuntu I'd say a few
rebuilds would suffice. Upstream did not do a major ABI bump either
and released the fix.

Cheers,
Balint

>
> Bastien
>
>
>
> >
> > Cheers,
> > Balint
> >
> > --
> > Balint Reczey
> > Ubuntu & Debian Developer
> >



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#916839: imagemagick: Silent ABI break in 6.9.10-11 on i386

[Balint Reczey]

Package: imagemagick
Version: 8:6.9.10.14+dfsg-1
Severity: grave
Control: forwareded -1 https://github.com/ImageMagick/ImageMagick6/issues/31
Control: tags -1 upstream fixed-upstream
Control: affects -1 ruby-rmagick

Hi,

The ABI broke in 6.9.10-11 due to changing MagickDoubleType to double
from long double.
This breaks ruby-rmagick and possibly other reverse dependencies, thus
after fixing imagemagick please check if some reverse dependencies
need to be rebuilt. The fix will be available in the .18 upstream
release.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#914753: needrestart: Please skip check when the system is shutting down already

[Balint Reczey]

Package: needrestart
Severity: wishlist
Version: 3.3-2

Hi,

Unattended-upgrades has a mode where it installs upgrades during
shutdown where discovering the services in need of a restart is not
particularly useful but the discovery itself slows down the shutdown.

Please consider detecting if the system goes down already per systemd
and also please check for logind's PreparingForShutdown state [2].

Thanks,
Balint

[1] https://github.com/mvo5/unattended-upgrades/blob/master/debian/NEWS
[2] https://www.freedesktop.org/wiki/Software/systemd/inhibit/

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#741356: unattended-upgrades: enhancements to InstallOnShutdown mode

[Balint Reczey]

Control: forwarded -1 https://github.com/mvo5/unattended-upgrades/issues/155
Control: retitle -1 Please support Offline System Updates
Control: tags -1 - patch + help

Hi Simon,

On Mon, Jul 17, 2017 at 12:05 AM Balint Reczey
 wrote:
>
> Hi Simon,
>
> On Thu, 9 Mar 2017 10:47:02 + Simon McVittie  wrote:
> > Control: retitle 741356 Do not rely on networking during InstallOnShutdown
> >
> > On Wed, 12 Mar 2014 at 19:39:25 +, Simon McVittie wrote:
> > > Any thoughts on this?
> >
> > For what it's worth, this and some other tweaks have been in production
> > use on SteamOS for quite a while. I attach less-outdated debdiffs in case
> > they are useful.
> >
> > I am not actively working on this module, and I have not reviewed the
> > forward-ports or the new changes; please let me know if there is any
> > possibility of getting this integrated, and I can try to get some time to
> > forward-port changes or respond to review, or have a colleague take over.
>
> Thanks for the bugreport and the patches!
> Part of your proposal has been implemented in apt 1.4.2 by separating
> the download and install phases. The u-u side reported in #863911
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863911> will be in
> next u-u upload.
>
> Since latest u-u NMU nattended-upgrades.service also contains
> After=network.target which ensures that network is up while u-u-s is
> running instead of not relying on network being available.
>
> You are very welcome to forward-port SteamOS updates here especially in
> a form of
> smaller commits, but please wait for the next update first because it
> merges many changes from Debian BTS and Ubuntu.

Since last time we discussed this bug some other problems surfaced
regarding how u-u handles the upgrades on shutdown, and I think 1.7
solved the solvable issues [1].
I also considered adding a mode that upgrades packages on shutdown
without networking enabled, but I did not find a solution that would
not break something else.
OTOH I'm open to adding a mode which would use systemd's
offline-updates and optionally always reboot again after the upgrade
steps answering the issue you raised in [2].

At the moment I'm satisfied with the modes u-u provides and I'd like
to work on other parts to make upgrades smoother thus I don't plan
working on this mode but as I said I'd be happy to merge patches and
have it implemented.

Cheers,
Balint

[1] 
https://tracker.debian.org/news/1001416/accepted-unattended-upgrades-17-source-into-unstable/
[2] https://lists.debian.org/debian-devel/2014/09/msg00501.html

--
Balint Reczey
Ubuntu & Debian Developer

Bug#908060: fakeroot: Extracting files with set file capabilites using tar results invalid mode

[Balint Reczey]

Package: fakeroot
Version: 1.23-1

Dear Maintainer,

The following operation fails with fakeroot but works with sudo:

$ fakeroot  bash -c "touch asd && chmod 0775 asd && setcap
cap_net_raw+ep asd && tar --xattrs -czf asd.tar.gz asd && rm asd"
$ fakeroot bash -c "tar --xattrs-include='*' -xf asd.tar.gz && file
asd ; getcap asd"
asd: ERROR: invalid mode 0775
$ sudo bash -c "tar --xattrs-include='*' -xf asd.tar.gz && file asd ;
getcap asd"
asd: empty
asd = cap_net_raw+ep

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#869987: document (and enable?) the automatic purge of downloaded packages (APT::Periodic::AutocleanInterval)

[Balint Reczey]

Control: notfound -1 0.93.1+nmu1
Control: tags -1 - patch

On Fri, 28 Jul 2017 09:28:39 -0400 Antoine Beaupre
 wrote:> Package: unattended-upgrades
> Version: 0.93.1+nmu1
> Severity: normal
> Tags: patch
>
> Hi,
>
> In the past week, my filesystem finally filled up due to 6GB of
> archives in /var/cache/apt/archives. I identified unattended-upgrades
> as the cause of this problem, as it didn't purge old packages (hello
> texlive!) that it downloaded previously, even when there were
> many versions of the same packages.
>
> unattended-upgrades doesn't document how to work around this problem
> at all, in itself. There is, however, sparse documentation here and
> there that indicate there are ways of doing this with:
>
> // Do "apt-get autoclean" every n-days (0=disable)
> APT::Periodic::AutocleanInterval "7";
>
> This is documented in:
>
> https://wiki.debian.org/UnattendedUpgrades
> https://debian-handbook.info/browse/stable/sect.regular-upgrades.html
>
> It seem important that the default configuration also documents this
> feature, if not just enable it by default.
>
> I filed a pull request upstream for this:
>
> https://github.com/mvo5/unattended-upgrades/pull/68

As discussed in the GitHub issue the default seems to be working and
it may have been a local issue.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#903108: python-apt: Please provide native filter API for pkg.is_auto_removable and pkg.is_upgradable

[Balint Reczey]

Package: python-apt
Version: 1.0.1
Severity: wishlist

Dear Maintainers,

Unattended-upgrades needs to find all upgradable and autoremovable
packages, but the filtering itself happens in Python code making it
slow - and a very significant part of u-u's CPU time starting with u-u
1.4 (~60% when there is nothing to install):

$ python3 -c "import timeit; print(timeit.timeit(stmt='{pkg.name for
pkg in cache if pkg.is_upgradable}', setup='import apt;cache =
apt.Cache();gc.enable()',number=10)/10)"
0.703306365699973

$ sudo time ./unattended-upgrade  --verbose
Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=bionic, o=Ubuntu,a=bionic-security,
o=UbuntuESM,a=bionic
No packages found that can be upgraded unattended and no pending auto-removals
2.21user 0.09system 0:02.33elapsed 98%CPU (0avgtext+0avgdata 109296maxresident)k
0inputs+21072outputs (0major+28423minor)pagefaults 0swaps

I tried using FilteredCache, but as it filters in Python, too, it did
not speed up filtering and actually it made the code slower.

Please extend the API to provide filtering in native code (or just
much faster code) at least for .is_auto_removable and .is_upgradable.

Thanks,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#870173: wireshark: CVE-2017-9616: Over deep mp4 chunks may cause stack Exhausted

[Balint Reczey]

Control: fixed -1 2.4.6-1

On Sun, Jul 30, 2017 at 8:51 PM Salvatore Bonaccorso  wrote:
>
> Source: wireshark
> Version: 2.2.7-1
> Severity: important
> Tags: upstream security
> Forwarded: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13777
>
> Hi,
>
> the following vulnerability was published for wireshark.
>
> CVE-2017-9616[0]:
> | In Wireshark 2.2.7, overly deep mp4 chunks may cause stack exhaustion
> | (uncontrolled recursion) in the dissect_mp4_box function in
> | epan/dissectors/file-mp4.c.
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2017-9616
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9616
> [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13777
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore

Thanks, this is now fixed.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#808336: unattended-upgrades: obsolete config /etc/apt/apt.conf.d/50unattended-upgrades

[Balint Reczey]

Control: tags -1 - moreinfo unreproducible

On Sat, Jul 15, 2017 at 11:57 PM Balint Reczey
 wrote:
>
> Control: tags -1 moreinfo unreproducible
>
> Hi Martin-Éric,
>
> On Fri, 18 Dec 2015 20:08:17 +0200 =?utf-8?q?Martin-=C3=89ric_Racine?=
>  wrote:
> > Package: unattended-upgrades
> > Version: 0.86.5
> > Severity: important
> >
> > The file /etc/apt/apt.conf.d/50unattended-upgrades is reported as old
> config. It needs to be deleted upon upgrade by maintainer scripts.
>
> This config file seems to be still used and removed on purge.
> Could you please add some more detail about the problem?

I found a Stretch system where I can observe the bug, thus I can
triage it from there, but it is not appearing all Stretch systems for
the record.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#899000: piuparts: Please allow running tests in lxc and VM backends in addinion to chroots

[Balint Reczey]

Package: piuparts
Version: 0.86
Severity: wishlist

Dear Maintainers,


Piuparts checks many package operations in a chroot, but since in the
chroot there are no running services service uprades and similar parts
of the mainitainer scripts are not tested.

We already have autopktests using lxc/VM backends thus simple
installation tests of services can be implemented easily, but for
service upgrade tests piuparts seems to be the best place where they
could be added.

The added backends would also excersice the parts of maintainer
scripts where a running init system is assumed.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#873033: ITP: opengcs -- Guest Compute Service for Linux Hyper-V Container

[Balint Reczey]

Hi,

On Wed, Aug 23, 2017 at 10:37 PM, Balint Reczey
<balint.rec...@canonical.com> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Balint Reczey <rbal...@ubuntu.com>
>
> * Package name: opengcs
>   Version : 0.3.1+git20170816.24.3193f23-1
>   Upstream Author : Microsoft
> * URL : https://github.com/Microsoft/opengcs
> * License : MIT
>   Programming Lang: Go
>   Description : Guest Compute Service for Linux Hyper-V Container
>
>  Open Guest Compute Service is a Linux-based open source project to
>  further the development of a production quality implementation of
>  Linux Hyper-V container on Microsoft Windows (LCOW).
>  It's designed to run inside a custom Linux OS for supporting Linux
>  container payload.

Opengcs can be used in a very specific environment and I think it may
not be particularly useful to have it packaged and maintained in
Debian, while it would require effort to keep it updated. Considering
that instead of converting the bug to RFP I'm just closing it, feel
free to reopen the bug as an RFP or ITP if feel so.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#697615: adanaxisgpl: contains (possibly modified) embedded copy of Ruby 1.8.4

[Balint Reczey]

Control: severity -1 serious

Hi Antonio,

On Mon, 7 Jan 2013 13:09:56 -0300 Antonio Terceiro 
wrote:
> Package: adanaxisgpl
> Severity: normal
>
> Hello,
>
> Today I was using http://codesearch.debian.net/ and have discovered that
> adanaxisgpl contains an embedded copy of Ruby 1.8.4 under src/MushRuby/.
>
> This is a violartion of the Debian Policy § 4.13
>
> http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
>
> I did not investigate whether this embedded copy was modified wrt Ruby
> 1.8.4, or whether the package would work with the packaged versions of
> Ruby.

It is pretty much an RC bug in any way. Thanks for reporting it!

Cheers,
Balint

Bug#893847: python3.6: uncoordinated dropping of python3-distutils dep breaks builds

[Balint Reczey]

Hi Doko,

On Mon, 2 Apr 2018 05:53:44 +0200 Matthias Klose  wrote:
> closing now. python-apt builds again, and I think the severity of your bug
> reports (yes, there are more of them) is a little bit exaggerated.

This bug is not marked as wontfix, but it affects other packages.
Should we handle this bug as wontfix and fix other packages?

Cheers,
Balint

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Balint Reczey]

Hi Guillem,

On Mon, Apr 16, 2018 at 3:51 AM, Balint Reczey
<balint.rec...@canonical.com> wrote:
> Hi Guillem
>
> On Sun, Mar 18, 2018 at 3:38 AM, Guillem Jover <guil...@debian.org> wrote:
>> Hi!
>>
>> On Sun, 2018-03-11 at 21:51:05 +0100, Balint Reczey wrote:
>>> Package: dpkg
>>> Version: 1.19.0.5
>>> Severity: wishlist
>>> Tags: patch
>>
>>> Please add support for Zstandard compression to dpkg and other
>>> programs generated by the dpkg source package [1].
>>
>> Thanks. I started implementing this several weeks ago after having
>> discussed it with Julian Andres Klode on IRC, but stopped after seeing
>> the implementation getting messy given the current code structure.
>
> I think it is not that bad. :-)
>
>> In any case, as I mentioned on IRC to Andres, this is something I
>> pondered about already in 2016, when Paul Wise blogged about it, and
>> which I also told Andres about at the time when he was adding lz4
>> support to apt. :) But parked it for later as there were several
>> apparent problems with it at the time.
>>
>> So, the items that come to mind (most from the dpkg FAQ [F]:
>>
>> * Availability in general Unix systems would be one. I think the code
>>   should be portable, but I've not checked properly.
>
> The libzstd package does not have any special dependency and there are
> packages for other Unix-like systems [2][3][4].
>
>> * Size of the shared library another, it would be by far the fattest
>>   compression lib used by dpkg. It's not entirely clear whether the
>>   shlib embeds a zlib library?
>
> I agree that the libzstd library is fairly big and I'd like to look
> into ways of making it leaner, maybe creating a variant with limited
> features covering what is needed in dpkg, apt, btrfs-progs and other
> system packages.
> It does not seem to embed the zlib library, but it offers many
> features which may be obsolete for dpkg.
>
> I tried dropping support for legacy file formats for example
> (ZSTD_LEGACY_SUPPORT=8) and the size of the library dropped to 382K
> from the original 490K.
>
>> * Increase in the (build-)essential set (directly and transitively).
>
> Yes, that's true, while apt also started supporting Zstd and .
>
>> * It also seems the format has changed quite some times already, and
>>   it's probably the reason for the fat shlib. Not sure if the format
>>   has stabilized enough to use this as good long-term storage format,
>>   and what's the policy regarding supporting old formats for example,
>>   given that this is intended mainly to be used for real-time and
>>   streaming content and similar. For example the Makefile for libzstd
>>   defaults to supporting v0.4+ only, which does not look great.
>
> Format stability is a very valid concern and upstream claims the
> current format to be stable [5] (since zstd v0.8.1).
>
>> * The license seems fine, as being very permissive, or it could affect
>>   availability. This one I need to add to the FAQ.
>> * Memory usage seemed fine or slight better depending on the compression
>>   level, but not when wanting equal or less space used?
>> * Space used seemed worse.
>
> Yes, space used is worse than with xz compression, but I think the
> much better compression and decompression speed would make up for
> that.
>
>> * Compression and decompression speed seemed better depending on the
>>   compression and decompression levels.
>>
>> [F] 
>> <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_compressors_for_.deb_packages.3F>
>>
>> Overall I'm still not sure whether this is worth it. Also the
>> tradeoffs for stable are different to unstable/testing, or for
>> fast/slow networks, or long-term storage, one-time installations,
>> or things like CI and similar.
>>
>> In any case this would still need discussion on debian-devel, and
>> involvement from other parts of the project, at least ftp-masters for
>> example. And whether the added "eternal" support makes sense if we are
>> or not planning to eventually switch to the compressor as the default,
>> for example, etc.
>
> I agree that the tradeoffs are very different for the use cases and
> please feel free to bring this topic to debian-devel quoting any part
> of my emails.
>
>>
>>> $ rm -rf firefox-xz/* ;time  dpkg-deb -R firefox-xz.deb firefox-xz/
>>> real 0m4,270s
>>> user 0m4,220s
>>> sys 0m0,630s
>>> $ rm -rf firefox-zstd/* ;time  dpkg-deb -R firefox-zstd.deb firefox-zstd/
>>> real 0m0,765s
>>> 

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Balint Reczey]

Hi Guillem

On Sun, Mar 18, 2018 at 3:38 AM, Guillem Jover <guil...@debian.org> wrote:
> Hi!
>
> On Sun, 2018-03-11 at 21:51:05 +0100, Balint Reczey wrote:
>> Package: dpkg
>> Version: 1.19.0.5
>> Severity: wishlist
>> Tags: patch
>
>> Please add support for Zstandard compression to dpkg and other
>> programs generated by the dpkg source package [1].
>
> Thanks. I started implementing this several weeks ago after having
> discussed it with Julian Andres Klode on IRC, but stopped after seeing
> the implementation getting messy given the current code structure.

I think it is not that bad. :-)

> In any case, as I mentioned on IRC to Andres, this is something I
> pondered about already in 2016, when Paul Wise blogged about it, and
> which I also told Andres about at the time when he was adding lz4
> support to apt. :) But parked it for later as there were several
> apparent problems with it at the time.
>
> So, the items that come to mind (most from the dpkg FAQ [F]:
>
> * Availability in general Unix systems would be one. I think the code
>   should be portable, but I've not checked properly.

The libzstd package does not have any special dependency and there are
packages for other Unix-like systems [2][3][4].

> * Size of the shared library another, it would be by far the fattest
>   compression lib used by dpkg. It's not entirely clear whether the
>   shlib embeds a zlib library?

I agree that the libzstd library is fairly big and I'd like to look
into ways of making it leaner, maybe creating a variant with limited
features covering what is needed in dpkg, apt, btrfs-progs and other
system packages.
It does not seem to embed the zlib library, but it offers many
features which may be obsolete for dpkg.

I tried dropping support for legacy file formats for example
(ZSTD_LEGACY_SUPPORT=8) and the size of the library dropped to 382K
from the original 490K.

> * Increase in the (build-)essential set (directly and transitively).

Yes, that's true, while apt also started supporting Zstd and .

> * It also seems the format has changed quite some times already, and
>   it's probably the reason for the fat shlib. Not sure if the format
>   has stabilized enough to use this as good long-term storage format,
>   and what's the policy regarding supporting old formats for example,
>   given that this is intended mainly to be used for real-time and
>   streaming content and similar. For example the Makefile for libzstd
>   defaults to supporting v0.4+ only, which does not look great.

Format stability is a very valid concern and upstream claims the
current format to be stable [5] (since zstd v0.8.1).

> * The license seems fine, as being very permissive, or it could affect
>   availability. This one I need to add to the FAQ.
> * Memory usage seemed fine or slight better depending on the compression
>   level, but not when wanting equal or less space used?
> * Space used seemed worse.

Yes, space used is worse than with xz compression, but I think the
much better compression and decompression speed would make up for
that.

> * Compression and decompression speed seemed better depending on the
>   compression and decompression levels.
>
> [F] 
> <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_compressors_for_.deb_packages.3F>
>
> Overall I'm still not sure whether this is worth it. Also the
> tradeoffs for stable are different to unstable/testing, or for
> fast/slow networks, or long-term storage, one-time installations,
> or things like CI and similar.
>
> In any case this would still need discussion on debian-devel, and
> involvement from other parts of the project, at least ftp-masters for
> example. And whether the added "eternal" support makes sense if we are
> or not planning to eventually switch to the compressor as the default,
> for example, etc.

I agree that the tradeoffs are very different for the use cases and
please feel free to bring this topic to debian-devel quoting any part
of my emails.

>
>> $ rm -rf firefox-xz/* ;time  dpkg-deb -R firefox-xz.deb firefox-xz/
>> real 0m4,270s
>> user 0m4,220s
>> sys 0m0,630s
>> $ rm -rf firefox-zstd/* ;time  dpkg-deb -R firefox-zstd.deb firefox-zstd/
>> real 0m0,765s
>> user 0m0,556s
>> sys 0m0,462s
>
> Right, although that might end up being noise when factored into a
> normal dpkg installation, due to the fsync()s, or maintscript
> execution, etc.

I agree that fsync()s and scripts add more time overall to the
installation time, but fsync()'s effect is decreasing with faster
storage. I would like to look into speeding up maintscript execution.

I need to reproduce my results on latest sid, but  when installing big
package-sets like ubuntu-desktop on a server VM the package

Bug#895385: Please build python3.x-dbg without using pymalloc to help detecting memory handling issues

[Balint Reczey]

Control: notfound -1 3.6.5-3

On Tue, 10 Apr 2018 22:43:38 +0200 Balint Reczey
<balint.rec...@canonical.com> wrote:
...
> Dear Maintainers,
>
> Shipping the -dbg Python packages without using pymalloc and with
> -DPy_USING_MEMORY_DEBUGGER helped me in finding memory allocation
> issues easier in Python modules and I'm sure that would help others as
> well. I'm aware of the negative impact on the speed, but IMO for the
> -dbg packages slower execution would be acceptable.

As Julien pointed out to me recently |PYTHONMALLOC| [1] environment
variable can be used to use malloc instead of pymalloc and using it
makes Python Valgrind-friendly. This is a better solution than compiling
without pymalloc, thus I'm closing this bug.

Thanks,
Balint

[1] https://docs.python.org/3/using/cmdline.html#envvar-PYTHONMALLOC

Bug#895385: Please build python3.x-dbg without using pymalloc to help detecting memory handling issues

[Balint Reczey]

Package: python3.6
Version: 3.6.5-3
Severity: wishlist
Tags: patch

Dear Maintainers,

Shipping the -dbg Python packages without using pymalloc and with
-DPy_USING_MEMORY_DEBUGGER helped me in finding memory allocation
issues easier in Python modules and I'm sure that would help others as
well. I'm aware of the negative impact on the speed, but IMO for the
-dbg packages slower execution would be acceptable.

I'm attaching the patch I used with python3.6, but the first not
disruptive opportunity for introducing this change would probably be
the switch to python3.8 which is expected to ship new shared libraries
anyway.

Thanks,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer
diff -Nru python3.6-3.6.5/debian/rules python3.6-3.6.5/debian/rules
--- python3.6-3.6.5/debian/rules	2018-04-01 05:46:30.0 +
+++ python3.6-3.6.5/debian/rules	2018-04-04 15:12:23.0 +
@@ -164,6 +164,9 @@
 DPKG_LDFLAGS := $(shell DEB_BUILD_MAINT_OPTIONS=hardening=-pie dpkg-buildflags --get LDFLAGS)
 OPT_CFLAGS   := $(filter-out -O%,$(DPKG_CFLAGS)) # default is -O3
 DEBUG_CFLAGS := $(patsubst -O%,-Og,$(DPKG_CFLAGS))
+DEBUG_CPPFLAGS:= $(shell dpkg-buildflags --get CPPFLAGS) -DPy_USING_MEMORY_DEBUGGER
+
+DEBUG_ABIFLAGS = d
 
 # on alpha, use -O2 only, use -mieee
 ifeq ($(DEB_HOST_ARCH),alpha)
@@ -406,11 +409,12 @@
 	mkdir -p $(buildd_debug)
 	cd $(buildd_debug) && \
 	  CC="$(CC)" CXX="$(CXX)" AR="$(AR)" RANLIB="$(RANLIB)" CFLAGS="$(DEBUG_CFLAGS)" \
-	  CPPFLAGS="$(DPKG_CPPFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
+	  CPPFLAGS="$(DEBUG_CPPFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
 	$(config_site) \
 	../configure \
 		$(common_configure_args) \
-		--with-pydebug
+		--with-pydebug \
+		--without-pymalloc
 
 	$(call __post_configure,$(buildd_debug))
 	touch $@
@@ -420,11 +424,12 @@
 	mkdir -p $(buildd_shdebug)
 	cd $(buildd_shdebug) && \
 	  CC="$(CC)" CXX="$(CXX)" AR="$(AR)" RANLIB="$(RANLIB)" CFLAGS="$(DEBUG_CFLAGS)" \
-	  CPPFLAGS="$(DPKG_CPPFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
+	  CPPFLAGS="$(DEBUG_CPPFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
 	$(config_site) \
 	../configure \
 		$(common_configure_args) \
 		--enable-shared \
+		--without-pymalloc \
 		--with-pydebug
 
 	$(call __post_configure,$(buildd_shdebug))
@@ -1203,20 +1208,20 @@
 	-e 's,^RUNSHARED *=.*,RUNSHARED=,' \
 	-e '/BLDLIBRARY/s/-L\. //' \
 		$(buildd_shdebug)/Makefile \
-		> $(d)-dbg/$(scriptdir)/config-$(VER)dm-$(DEB_HOST_MULTIARCH)/Makefile
+		> $(d)-dbg/$(scriptdir)/config-$(VER)$(DEBUG_ABIFLAGS)-$(DEB_HOST_MULTIARCH)/Makefile
 	sed -e 's,^RUNSHARED *=.*,RUNSHARED=,' \
 	-e '/BLDLIBRARY/s/-L\. //' \
-		$(buildd_shdebug)/$(shell cat $(buildd_shdebug)/pybuilddir.txt)/_sysconfigdata_dm_$(PLAT)_$(DEB_HOST_MULTIARCH).py \
-		> $(d)-dbg/$(scriptdir)/_sysconfigdata_dm_$(PLAT)_$(DEB_HOST_MULTIARCH).py
+		$(buildd_shdebug)/$(shell cat $(buildd_shdebug)/pybuilddir.txt)/_sysconfigdata_$(DEBUG_ABIFLAGS)_$(PLAT)_$(DEB_HOST_MULTIARCH).py \
+		> $(d)-dbg/$(scriptdir)/_sysconfigdata_$(DEBUG_ABIFLAGS)_$(PLAT)_$(DEB_HOST_MULTIARCH).py
 	sed -i 's/ -O3 / -O2 /g;s/$(LTO_CFLAGS)//g;s/-fprofile-use *-fprofile-correction//g' \
-		$(d)-dbg/$(scriptdir)/_sysconfigdata_dm_$(PLAT)_$(DEB_HOST_MULTIARCH).py
+		$(d)-dbg/$(scriptdir)/_sysconfigdata_$(DEBUG_ABIFLAGS)_$(PLAT)_$(DEB_HOST_MULTIARCH).py
 
 	mv $(d)-dbg/usr/lib/libpython*.a $(d)-dbg/usr/lib/$(DEB_HOST_MULTIARCH)/
 
 	for i in $(d)-dbg/$(scriptdir)/lib-dynload/*.so; do \
 	  case "$$i" in *$(DEB_HOST_MULTIARCH)*) continue; esac; \
-	  b=$$(basename $$i .cpython-$(EXT_VER)dm.so); \
-	  d=$${b}.cpython-$(EXT_VER)dm-$(DEB_HOST_MULTIARCH).so; \
+	  b=$$(basename $$i .cpython-$(EXT_VER)$(DEBUG_ABIFLAGS).so); \
+	  d=$${b}.cpython-$(EXT_VER)$(DEBUG_ABIFLAGS)-$(DEB_HOST_MULTIARCH).so; \
 	  mv $$i $(d)-dbg/$(scriptdir)/lib-dynload/$$d; \
 	done
 
@@ -1224,24 +1229,24 @@
 		usr/bin \
 		usr/share/man/man1 \
 		$(scriptdir)/lib-dynload \
-		usr/include/$(PVER)dm \
-		usr/include/$(DEB_HOST_MULTIARCH)/$(PVER)dm \
+		usr/include/$(PVER)$(DEBUG_ABIFLAGS) \
+		usr/include/$(DEB_HOST_MULTIARCH)/$(PVER)$(DEBUG_ABIFLAGS) \
 		usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig
 
 	cp -p $(d)-dbg/$(scriptdir)/lib-dynload/*.so \
 		$(d_ldbg)/$(scriptdir)/lib-dynload/
-	cp -p $(d)-dbg/$(scriptdir)/_sysconfigdata_dm_$(PLAT)_$(DEB_HOST_MULTIARCH).py \
+	cp -p $(d)-dbg/$(scriptdir)/_sysconfigdata_$(DEBUG_ABIFLAGS)_$(PLAT)_$(DEB_HOST_MULTIARCH).py \
 		$(d_ldbg)/$(scriptdir)/
-	cp -p $(buildd_shdebug)/libpython$(VER)dm.so.1.0 \
+	cp -p $(buildd_shdebug)/libpython$(VER)$(DEBUG_ABIFLAGS).so.1.0 \
 		$(d_ldbg)/usr/lib/$(DEB_HOST_MULTIARCH)/
 	dh_link -p$(p_ldbg) \
-	/usr/lib/$(DEB_HOST_MULTIARCH)/libpython$(VER)dm.so.1.0 \
-		/usr/lib/$(DEB_HOST_MULTIARCH)/libpython$(VER)dm.so.1 \
-	/usr/lib/$(DEB_HOST_MULTIARCH)/l