Bug#932881: add dependency on logsave

[Sven Joachim]

Control: reassign -1 e2fsprogs 1.45.3-1
Control: forcemerge 932861 -1

On 2019-07-24 08:32 +0300, Aleksi Suhonen wrote:

> Package: initramfs-tools
> Severity: grave
> Version: 0.133
>
> After upgrading e2fsprogs to 1.45.3-1, computer fails to boot because
> rootfs fails to fsck. And fsck fails because binary for logsave is
> missing. Or in fact, fsck doesn't fail, but the init script reports it
> did, because it cannot tell the difference...
>
> This is because logsave has just been split into its own package
> "logsave." The initrd builder scripts should depend on it, except it
> seems that not all hardware platforms have the logsave package yet...

It is e2fsprogs which needs to depend on logsave for the time being in
order not to break its reverse dependencies.  As for initramfs-tools,
initramfs-tools-core should probably depend on
logsave | e2fsprogs (<< 1.45.3), that is tracked in #932854.

Cheers,
   Sven

Bug#928009: file: "name use count (30) exceeded error with file on TIFF image inside mail"

[Paul Wise]

On Wed, 24 Jul 2019 13:24:45 +0800 Paul Wise  wrote:

> $ wget -q 
> https://bugs.launchpad.net/ubuntu/+source/file/+bug/1717991/+attachment/4952354/+files/test.jpg
> $ file test.jpg ; echo $?
> test.jpg: ERROR: JPEG image data, JFIF standard 1.01, resolution (DPI),
> density 240x240, segment length 16, Exif Standard: [TIFF image data,
> big-endian, direntries=8, description=Picture saved with settings
> embedded., orientation=upper-left, xresolution=148, yresolution=156,
> resolutionunit=2, software=Adobe Photoshop Lightroom 6.1.1 (Windows),
> datetime=2017:08:17 11:16:47] name use count (30) exceeded
> 1

The workaround for this issue is to increase the name recursion limit:

$ file --parameter name=300 test.jpg ; echo $?
test.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI),
density 240x240, segment length 16, Exif Standard: [TIFF image data,
big-endian, direntries=8, description=Picture saved with settings
embedded., orientation=upper-left, xresolution=148, yresolution=156,
resolutionunit=2, software=Adobe Photoshop Lightroom 6.1.1 (Windows),
datetime=2017:08:17 11:16:47], baseline, precision 8, 2335x1831,
components 3
0

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#932881: add dependency on logsave

[Aleksi Suhonen]

Package: initramfs-tools
Severity: grave
Version: 0.133

After upgrading e2fsprogs to 1.45.3-1, computer fails to boot because 
rootfs fails to fsck. And fsck fails because binary for logsave is 
missing. Or in fact, fsck doesn't fail, but the init script reports it 
did, because it cannot tell the difference...


This is because logsave has just been split into its own package 
"logsave." The initrd builder scripts should depend on it, except it 
seems that not all hardware platforms have the logsave package yet...


Excerpt from the other package's changelog:

e2fsprogs (1.45.3-1) unstable; urgency=medium

  * New upstream version
  * Automatic online file system scrubs is now disabled by default.
They can be enabled by editing /etc/e2scrub.conf.
...
  * Only require the udev, systemd, and cron build dependencies when
building on Linux. (Closes: #931266)
  * Move logsave to its own package.  (Closes: #923372)
  * Update the Czech and Dutch translations

 -- Theodore Y. Ts'o   Sun, 14 Jul 2019 21:01:11 -0400



Best Regards,

--
Aleksi Suhonen

Bug#928009: file: "name use count (30) exceeded error with file on TIFF image inside mail"

[Paul Wise]

Control: found -1 file/1:5.37-4
Control: found -1 file/1:5.35-4
Control: found -1 file/1:5.30-1

On Fri, 26 Apr 2019 11:01:37 +0200 NoviceFileBug wrote:

>ERROR: JPEG image data, Exif standard: [TIFF image data, big-endian, 
> direntries=12, model=POCOPHONE F1, height=3024, orientation=upper-right, 
> datetime=2019:04:25 22:08:11, resolutionunit=2, GPS-Data, xresolution=191, 
> yresolution=199, manufacturer=Xiaomi, width=4032] name use count (30) exceeded

At work we hit this bug report too (in stretch, buster, unstable).

We discovered that it has been reported before:

https://bugzilla.redhat.com/show_bug.cgi?id=1201630
https://bugs.launchpad.net/ubuntu/+source/file/+bug/1717991

The file from the Fedora bug report works fine now:

http://upload.wikimedia.org/wikipedia/commons/thumb/7/7d/Apollo_11_Launch2.jpg/192px-Apollo_11_Launch2.jpg

But the file from the Ubuntu bug report still fails:

$ wget -q 
https://bugs.launchpad.net/ubuntu/+source/file/+bug/1717991/+attachment/4952354/+files/test.jpg
$ file test.jpg ; echo $?
test.jpg: ERROR: JPEG image data, JFIF standard 1.01, resolution (DPI),
density 240x240, segment length 16, Exif Standard: [TIFF image data,
big-endian, direntries=8, description=Picture saved with settings
embedded., orientation=upper-left, xresolution=148, yresolution=156,
resolutionunit=2, software=Adobe Photoshop Lightroom 6.1.1 (Windows),
datetime=2017:08:17 11:16:47] name use count (30) exceeded
1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#931932: fixed in ruby-mini-magick 4.9.2-1+deb10u1

[Utkarsh Gupta]

Hey,

On 24/07/19 10:53 am, Salvatore Bonaccorso wrote:
> Hey!
>
> On Wed, Jul 24, 2019 at 10:43:40AM +0530, Utkarsh Gupta wrote:
>> Hey Salvatore,
>>
>> On Tue, 16 Jul 2019 21:07:05 + Salvatore Bonaccorso
>>  wrote:
>>> Source: ruby-mini-magick
>>> Source-Version: 4.9.2-1+deb10u1
>>>
>>> We believe that the bug you reported is fixed in the latest version of
>>> ruby-mini-magick, which is due to be installed in the Debian FTP archive.
>> Where is the source of this upload?
>> I can't seem to find any changelog entries :(
>> Neither any separate branch :(
> Not on salsa. I'm not part of the the ruby team, and apparently the
> master branch did already track the experimental upload, so I just did
> a traditional NMU. The debdiff to import in the packaging repo is
> found at:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931932#23
>
> I would suggest to update to an upstream version which has the fix
> then upload later on to unstable. Would be nice to incoorporate the
> NMU (as well in changelog) so that BTS correctly tracks the fixed
> versions.
>
> Does this help?

Perfecto, thanks! :D


Best,
Utkarsh




signature.asc
Description: OpenPGP digital signature

Bug#931932: fixed in ruby-mini-magick 4.9.2-1+deb10u1

[Salvatore Bonaccorso]

Hey!

On Wed, Jul 24, 2019 at 10:43:40AM +0530, Utkarsh Gupta wrote:
> Hey Salvatore,
> 
> On Tue, 16 Jul 2019 21:07:05 + Salvatore Bonaccorso
>  wrote:
> > Source: ruby-mini-magick
> > Source-Version: 4.9.2-1+deb10u1
> >
> > We believe that the bug you reported is fixed in the latest version of
> > ruby-mini-magick, which is due to be installed in the Debian FTP archive.
> 
> Where is the source of this upload?
> I can't seem to find any changelog entries :(
> Neither any separate branch :(

Not on salsa. I'm not part of the the ruby team, and apparently the
master branch did already track the experimental upload, so I just did
a traditional NMU. The debdiff to import in the packaging repo is
found at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931932#23

I would suggest to update to an upstream version which has the fix
then upload later on to unstable. Would be nice to incoorporate the
NMU (as well in changelog) so that BTS correctly tracks the fixed
versions.

Does this help?

Regards,
Salvatore

Bug#931932: fixed in ruby-mini-magick 4.9.2-1+deb10u1

[Utkarsh Gupta]

Hey Salvatore,

On Tue, 16 Jul 2019 21:07:05 + Salvatore Bonaccorso
 wrote:
> Source: ruby-mini-magick
> Source-Version: 4.9.2-1+deb10u1
>
> We believe that the bug you reported is fixed in the latest version of
> ruby-mini-magick, which is due to be installed in the Debian FTP archive.

Where is the source of this upload?
I can't seem to find any changelog entries :(
Neither any separate branch :(

I am sorry if I am missing anything obvious, but maybe you could help?

> 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 931...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Salvatore Bonaccorso  (supplier of updated
ruby-mini-magick 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)




signature.asc
Description: OpenPGP digital signature

Bug#932880: invalid octals silently parsed as zero

[Trent W. Buck]

Package: nftables
Version: 0.9.1-2
Severity: important

I was aligning literal numbers with leading zeroes (instead of spaces).
I found that nft treats "010" as an octal number, i.e. 010 = 8.  Fine.
But nft also thinks that 099 = 0!

nft should error out when it encounters such an invalid octal.

A simple example ruleset is shown below.

#!/usr/sbin/nft --file

flush ruleset

add table x
add chain x y
add rule x y ip saddr 9 continue   comment "parsed as 0.0.0.9/32"
add rule x y ip saddr 09 continue  comment "parsed as 0.0.0.0/32"
## This one generates an error, because "1 - 0" is an invalid interval.
#add rule x y ip saddr { 01 - 09 } continue

list chain x y


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'proposed-updates'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#932879: Add details

[JB]

Just an additional message to include a screenshot of the GNOME GUI panel I am 
talking about.


JB

Bug#932879: gnome: Not able to choose proper formats in "Region & Language" settings GUI

[Julien-Benjamin]

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

Dear Maintainer,



   * What led up to the situation?

After an upgrade from Strech, I found out that I was unable to choose my 
formats (measurements, paper type, date format) when using the locale 
en_US.UTF-8.

* What exactly did you do (or not do) that was effective (or ineffective)?
I upgraded from Strech following the usual method (Debian wiki/manual). The 
settings were overidden during the upgrade, as far as I understand.

* What was the outcome of this action?
It changed my formats settings and I am unable to change it from the dedicated 
settings GUI. I did not try to force it in CLI though.
  
* What outcome did you expect instead?
I was expecting to be able to e.g. change the paper type to A4 or change the 
date format, or even switch from imperial measurements to International System 
of Units.

Best,

JB


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

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

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

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

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.30.1-1
ii  at-spi2-core  2.30.0-7
ii  baobab3.30.0-2
ii  caribou   0.4.21-7
ii  chromium  73.0.3683.75-1
ii  dconf-cli 0.30.1-2
ii  dconf-gsettings-backend   0.30.1-2
ii  eog   3.28.4-2+b1
ii  evince3.30.2-3
ii  evolution-data-server 3.30.5-1
ii  firefox-esr   60.8.0esr-1~deb10u1
ii  fonts-cantarell   0.111-2
ii  gdm3  3.30.2-3
ii  gedit 3.30.2-2
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.58.0-2
ii  gnome-backgrounds 3.30.0-1
ii  gnome-bluetooth   3.28.2-3
ii  gnome-calculator  3.30.1-2
ii  gnome-characters  3.30.0-2
ii  gnome-contacts

Bug#855092: beets: FTBFS randomly (failing tests)

[Paul Gevers]

Hi Carl, Santiago,

Just passing by, but I suspect that Carl doesn't know that bugs in the
Debian BTS are not automatically forwarded to the submitter of the bug.
Hence, doing so now. Santiago, maybe the third item leaves something for
you to comment on?

On Thu, 30 May 2019 17:07:25 +1000 Carl Suster  wrote:
> Hi,
> 
> I'm an upstream contributor to beets and I was looking into the failures 
> you're seeing here. I'm interested in making these tests reliable.
> 
> I tried to build the package on my (sid) laptop using sbuild and the 
> latest packaging repo from salsa. I'm not able to reproduce these test 
> failures. If I remove the Debian patches disabling tests, I'm still not 
> able to reproduce any of the failures that led you to add those patches 
> in the first case. I'm seeing three categories of tests here:
> 
>1) The test in skip-broken-test. If the failure you're seeing is the 
> same error on the GitHub issue you mention in that patch 
> ('musicbrainz.host'), then my suspicion is that when running the test 
> beets is unable to find/read the file beets/config_default.yaml. One way 
> this can happen is if beets is being invoked as a zipped egg rather than 
> unpacked source (unsupported). Otherwise it might be that the build 
> environment has paths set in an unusual way that interferes with beets' 
> mechanism to find that YAML file relative to the invoked module.
> 
>2) There are two tests failing due to filesystem access 
> (test_no_write_permission and test_add_tags). Maybe we can do a better 
> job of mocking here so that the actual filesystem isn't being tested. 
> I'll take a look.
> 
>3) The two test_import_task_created* tests exercise a feature based 
> on a coroutine implementation (beets.util.pipeline), so I wonder if 
> that's related? It's the only unusual thing I can think of off-hand. I 
> know that the Debian build infrastructure is a little unusual, but I'm 
> not sure what specifically the difference could be here.
> 
> If you can help point me in the right direction to reproduce these 
> issues that would be appreciated.
> 
> Cheers,
> Carl
> 
> 

Paul



signature.asc
Description: OpenPGP digital signature

Bug#879674: Bank Director

[infodirectormoneygramoff...@gmail.com]

Bug#932878: nft segfault on overlapping intervals

[Trent W. Buck]

Package: nftables
Version: 0.9.1-2
Severity: normal

While studying RFC 4890 I ran into parsing problems.
I have narrowed it down to the ruleset below.

Note the typo ("174" should be "147") results in overlapping intervals
with conflicting verdicts.

I think this should result in an error rather than a segfault.


#!/usr/sbin/nft --file
delete chain inet x y
table inet x {
chain y {
icmpv6 type vmap {
144 - 174 : accept,
154 - 199 : drop,
}
}
}


   PID: 8941 (nft)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Wed 2019-07-24 14:37:13 AEST (45s ago)
  Command Line: nft --file tmp.nft
Executable: /usr/sbin/nft
 Control Group: /user.slice/user-0.slice/session-25.scope
  Unit: session-25.scope
 Slice: user-0.slice
   Session: 25
 Owner UID: 0 (root)
   Boot ID: d7a30c4dec804cd08fbd79e513dfbc16
Machine ID: ee3c68006daf4086b06772170d63f3f6
  Hostname: not-omega
   Storage: 
/var/lib/systemd/coredump/core.nft.0.d7a30c4dec804cd08fbd79e513dfbc16.8941.156394303300.lz4
   Message: Process 8941 (nft) of user 0 dumped core.

Stack trace of thread 8941:
#0  0x7f1d5d9fb39b set_to_intervals (libnftables.so.1)
#1  0x7f1d5d9dcd2f n/a (libnftables.so.1)
#2  0x7f1d5d9df2c7 do_command (libnftables.so.1)
#3  0x7f1d5da02320 n/a (libnftables.so.1)
#4  0x7f1d5da02cdc nft_run_cmd_from_filename 
(libnftables.so.1)
#5  0x5637f2eaa5f0 main (nft)
#6  0x7f1d5d73809b __libc_start_main (libc.so.6)
#7  0x5637f2eaa68a _start (nft)

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'proposed-updates'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#774970: Reviewed for ubuntu

[zrm]

One of the issues with the suggested fix (and the original 
dnsmasq.service file) is that it still fails to ever start dnsmasq if 
the Requires= target fails at boot, even if the target is eventually 
reached.


That can be addressed by adding a WantedBy= entry to the [Install] 
section corresponding to each Requires= entry in the [Unit] section.


That way when the target is reached it tries to start dnsmasq again.

Bug#932860: wine can not be installed after updating libglib2.0-0 to 2.61.1-2

[fin4478 fin4478]

There are same errors when trying to install wine32 4.0-2 from the
Debian repository. 

On Tue, 23 Jul 2019 17:27:37 -0700 James Lu
 wrote:
> Hi,
> 
> It looks like you're trying to install the Wine packages from WineHQ,
> which are not the same ones provided by Debian. It doesn't look like
> the WineHQ repository has been updated for Bullseye yet, so it's
> likely you'll have to wait for them to add those missing builds.
> 
> Best,
> James
> 
> On 2019-07-23 5:02 p.m., fin4478 fin4478 wrote:
> > Package: wine32
> > Version: 4.0-2
> > 
> > To prevent warnings in the file .xsession-errors with the Xfce
> > 4.13.3 desktop libglib2.0-0 must be updated to the version 2.60.
> > This removes wine and many of its libraries. Reinstalling wine
> > shows the following problems:
> > xfce@optipc:~$ sudo aptitude install winehq-staging
> > The following NEW packages will be installed:
> >   acl{a} glib-networking:i386{a} gstreamer1.0-plugins-base:i386{a} 
> >   libasound2-plugins:i386{a} libatk-bridge2.0-0:i386{a}
> > libatk1.0-0:i386{a} libatspi2.0-0:i386{a} libavcodec58:i386{a}
> > libbz2-1.0:i386{a} libcairo-gobject2:i386{a} libcolord2:i386{a}
> > libcroco3:i386{a} libgdbm-compat4:i386{a} libgdbm6:i386{a}
> > libgdk-pixbuf2.0-0:i386{a} libgstreamer-plugins-base1.0-0:i386{a}
> > libgstreamer1.0-0:i386{a} libgtk-3-0:i386{a} libharfbuzz0b:i386{a}
> > libieee1284-3{a} libieee1284-3:i386{a} libjson-glib-1.0-0:i386{a}
> > libmariadb3:i386{a} libpango-1.0-0:i386{a}
> > libpangocairo-1.0-0:i386{a} libpangoft2-1.0-0:i386{a}
> > libpci3:i386{a} libperl5.28:i386{a} librest-0.7-0:i386{a}
> > librsvg2-2:i386{a} librsvg2-common:i386{a} libsane{a}
> > libsane:i386{a} libsane-common{a} libsensors-config{ab}
> > libsensors5{a} libsensors5:i386{a} libsnmp-base{a} libsnmp30{a}
> > libsnmp30:i386{a} libsoup-gnome2.4-1:i386{a} libsoup2.4-1:i386{a}
> > sane-utils{a} update-inetd{a} wine-staging{a} wine-staging-amd64{a}
> > wine-staging-i386:i386{a} winehq-staging The following packages
> > will be REMOVED: bind9-host{u} cgroupfs-mount{u} dkms{u}
> > fonts-wine{u} geoip-database{u} gtk2-engines-xfce{u}
> > i965-va-driver:i386{u} intel-media-va-driver:i386{u}
> > libasyncns0:i386{u} libavahi-common-data:i386{u} libavahi-core7{u}
> > libavcodec57:i386{u} libavutil55:i386{u} libbind9-161{u}
> > libcom-err2:i386{u} libdaemon0{u} libdatrie1:i386{u} libdns1104{u}
> > libexif12:i386{u} libexo-1-0{u} libfaudio0{u} libflac8:i386{u}
> > libfstrm0{u} libgcrypt20:i386{u} libgd3:i386{u} libgeoip1{u}
> > libgeos-3.7.1{u} libgmp10:i386{u} libgomp1:i386{u} libgpm2:i386{u}
> > libgsoap-2.8.75{u} libgtksourceview-3.0-1{u}
> > libgtksourceview-3.0-common{u} libhogweed4:i386{u} libice6:i386{u}
> > libicu63:i386{u} libigdgmm9:i386{u} libintl-perl{u}
> > libintl-xs-perl{u} libisc1100{u} libisccc161{u} libisccfg163{u}
> > libjbig0:i386{u} libjim0.77{u} libk5crypto3:i386{u}
> > libkeybinder-3.0-0{u} libkeyutils1:i386{u} libkrb5support0:i386{u}
> > libllvm7{u} libltdl7:i386{u} liblwres161{u} liblz4-1:i386{u}
> > libmbim-glib4{u} libmbim-proxy{u} libmodule-find-perl{u}
> > libmodule-scandeps-perl{u} libnettle6:i386{u} libnotify-bin{u}
> > libnuma1:i386{u} libp11-kit0:i386{u} libpixman-1-0:i386{u}
> > libproc-processtable-perl{u} libprotobuf-c1{u} libqmi-glib5{u}
> > libqmi-proxy{u} libreadline7{u} libsasl2-2:i386{u}
> > libsasl2-modules:i386{u} libsasl2-modules-db:i386{u} libsm6:i386{u}
> > libsndfile1:i386{u} libsndio7.0:i386{u} libsort-naturally-perl{u}
> > libsoxr0:i386{u} libstb0{u} libstb0:i386{u} libswresample2:i386{u}
> > libsystemd0:i386{u} libtasn1-6:i386{u} libterm-readkey-perl{u} 

Bug#932877: parser rejects blank/comment lines in literal sets/maps

[Trent W. Buck]

Package: nftables
Version: 0.9.1-2
Severity: minor

The nftables file parser allows newlines in literal sets and maps.
It allows comments in them -- but it doesn't allow comments on their own line.
I think this is a mistake, and the parser should be changed to allow them.

A simple example ruleset is below.

# cat tmp.nft
table inet x {
# comments are allowed here
chain y {
# comments are allowed here
icmpv6 type {
1,  # comments are allowed here
2,
} accept

icmpv6 type {
1,
# comments AREN'T allowed here
2,
} accept
}
}
list ruleset

root@not-omega:~# nft --file tmp.nft
tmp.nft:12:43-43: Error: syntax error, unexpected newline, expecting comma 
or '}'
# comments AREN'T allowed here
  ^
tmp.nft:13:14-14: Error: syntax error, unexpected comma
2,
 ^
tmp.nft:14:11-16: Error: syntax error, unexpected accept, expecting newline 
or semicolon
} accept
  ^^

PS: it also doesn't allow blank lines, e.g.

add table x
add chain x y
add rule x y ip saddr {
1,

2,
} accept



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'proposed-updates'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#932860: wine can not be installed after updating libglib2.0-0 to 2.61.1-2

[fin4478 fin4478]

I  am using the version 2.61.1-2 from the experimental repository and it
does have the i386 version. I did notice that the i386 version is
missing with the version 2.60. I was unsure when I wrote this bug
report and used the 2.60 number.

Bug#932757: fwupd: should include Built-Using fields in the signed packages

[Mario.Limonciello]

Dell Customer Communication - Confidential

Sure.  Will be part of next fwupd release.

https://github.com/hughsie/fwupd/commit/09700bbce8b2016056079cf73b0408e9afbc5301


> -Original Message-
> From: Adam D. Barratt 
> Sent: Monday, July 22, 2019 2:05 PM
> To: sub...@bugs.debian.org
> Subject: Bug#932757: fwupd: should include Built-Using fields in the signed
> packages
> 
> 
> [EXTERNAL EMAIL]
> 
> Source: fwupd
> Version: 1.2.5-2
> 
> Hi,
> 
> As discussed with Steve at Debconf, the fwupd-*-signed binary packages
> are missing Built-Using fields pointing back to the unsigned source
> package. Please add them. :-)
> 
> Regards,
> 
> Adam

Bug#932860: wine can not be installed after updating libglib2.0-0 to 2.60

[Sven Joachim]

Control: reassign -1 src:glib2.0
Control: forcemerge 932678 -1

On 2019-07-24 00:02 +, fin4478 fin4478 wrote:

> Package: wine32
> Version: 4.0-2
>
> To prevent warnings in the file .xsession-errors with the Xfce 4.13.3
> desktop libglib2.0-0 must be updated to the version 2.60. This removes
> wine and many of its libraries.

That's because libglib2.0-0 2.60 is not available on i386 due to the
FTBFS bug #932678.  I worked around that by building glib2.0 2.60-5 in
an i386 chroot locally, with DEB_BUILD_OPTIONS=nocheck.

Cheers,
   Sven

Bug#932876: logsave: should be Multi-Arch: foreign

[Sven Joachim]

Package: logsave
Version: 1.45.3-1

Like the package it partially replaces (e2fsprogs), logsave should be
Multi-Arch: foreign.  The initramfs-tools-core package will have to
depend on logsave, which makes cross-grades (say, from i386 to amd64)
difficult, as logsave and e2fsprogs cannot be cross-graded before dpkg.


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

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

Versions of packages logsave depends on:
ii  libc6  2.28-10

logsave recommends no packages.

logsave suggests no packages.

-- no debconf information

Bug#932875: gpsbabel-gui: gpsbabelfe-bin is not included

[Jun NOGATA]

Package: gpsbabel-gui
Version: 1.6.0+ds-3
Severity: normal

Dear Maintainer,

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

Gpsbabelfe can't start, the package does not contain gpsbabelfe-bin.

jun:~/$ gpsbabelfe 
Couldn't find/run gpsbabelfe-bin.  Possible installation issues

jun:~/$ dpkg -L gpsbabel-gui
/.
/usr
/usr/bin
/usr/bin/gpsbabelfe
/usr/share
/usr/share/applications
/usr/share/applications/gpsbabel.desktop
/usr/share/doc
/usr/share/doc/gpsbabel-gui
/usr/share/doc/gpsbabel-gui/changelog.Debian.gz
/usr/share/doc/gpsbabel-gui/copyright
/usr/share/pixmaps
/usr/share/pixmaps/gpsbabel.xpm

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


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

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

Versions of packages gpsbabel-gui depends on:
ii  gpsbabel  1.6.0+ds-3

gpsbabel-gui recommends no packages.

gpsbabel-gui suggests no packages.

-- no debconf information

Bug#932874: logsave: Insufficient Breaks/Replaces on e2fsprogs

[Sven Joachim]

Package: logsave
Version: 1.45.3-1
Severity: serious

Installing logsave without upgrading e2fsprogs fails:

,
| Preparing to unpack .../logsave_1.45.3-1_amd64.deb ...
| Unpacking logsave (1.45.3-1) ...
| dpkg: error processing archive 
/var/cache/apt/archives/logsave_1.45.3-1_amd64.deb (--install):
|  trying to overwrite '/sbin/logsave', which is also in package e2fsprogs 
1.45.2-1
`

There are a Replaces/Breaks relationships on e2fsprogs (<< 1.45.2-1)
which need to be bumped to (<< 1.45.3-1).


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

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

Versions of packages logsave depends on:
ii  libc6  2.28-10

logsave recommends no packages.

logsave suggests no packages.

-- no debconf information

Bug#932861: boot failure because e2fsprogs should depend on logsave

[Ben Caradoc-Davies]

Thanks, Kyle. I took the liberty of bumping this to critical severity 
and updating the title because it breaks the whole system (failure to boot).


After booting my system with the previous kernel/initramfs, I was able 
to install logsave, but also needed to run "update-initramfs -u" to 
update the latest initramfs to include logsave before it was able to boot.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#931771: subversion: E170013 (unable to connect to a repository) and E120171 (Error occured during SSL communication)

[James McCoy]

On Mon, Jul 15, 2019 at 09:15:11AM +0200, Martin wrote:
> * Florian
> 
> yes the subversion package v1.10.4-1 is from the official public buster main
> repository. btw. this bug is related with libserf issue:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931773

Florian was referring to a public svn repository, so that the issue can
be independently tested.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#932873: vim-runtime: justify plugin enabled by default, and standard vim keys , and _ are overridden

[GI]

Package: vim-runtime
Version: 2:8.1.0875-5
Severity: normal

Dear Maintainer,

It looks like the "justify.vim" plugin is enabled by default. This
causes vim to wait for a keypress when the user presses "," or "_".

These are common keys used in VI normal mode. To enable a plugin that
overrides these by default may surprise many users. (It surprised me.)

Plugins usually use  or  when defining mappings.
The justify.vim plug in does not, perhaps intentionally. Enabling it by
default will surprise (and perhaps annoy) users who use the "_" and ","
keys.

I'd suggest not shipping it by default. Or at least provide an easy way
for users to disable it.

GI


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

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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim-gtk [vim]  2:8.1.0875-5
ii  vim-tiny   2:8.1.0875-5

vim-runtime suggests no packages.

-- no debconf information

Bug#925675: Patch

[Giovanni Mascellani]

Hi,

I believe the problem here is the order of the linking flags. The
attached patch should fix.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
From: Giovanni Mascellani 
Date: Tue, 23 Jul 2019 23:36:17 -0300
Subject: Fix compilation with GCC 9

Fix order of linking flags.

--- enemylines7-0.6.orig/Makefile
+++ enemylines7-0.6/Makefile
@@ -18,7 +18,7 @@ all: $(TARGET)
 OFILES = audio.o config.o container.o entity.o random.o game.o util.o menu.o help.o font_ogl.o skybox.o math/frustum.o math/quaternion.o font_data.o position.o light.o formation.o tex.o models/sphere.o models/bomb.o models/displaylists.o models/plane1.o models/slope1_1.o models/slope1_2.o models/slope2_1.o models/slope2_2.o models/slope3_1.o models/slope3_2.o models/slope4_1.o models/slope4_2.o models/tower.o models/bunker.o models/biosphere.o models/plane2.o models/station.o floor.o radio.o main.o elements/energy.o elements/difficulty.o elements/interval.o elements/score.o elements/timeleft.o tweak/tweak_release.o block/block.o block/blockinfo.o block/cacher.o block/collider.o block/cube.o block/debugger.o block/destructor.o block/infostack.o block/map2.o block/material.o block/merger.o block/painter3.o block/painter6.o block/selector2.o
 
 $(TARGET): $(OFILES)
-   $(CXX) $(LDFLAGS) $(OFILES) -o $(TARGET)
+   $(CXX) $(OFILES) -o $(TARGET) $(LDFLAGS)
 
 
 clean:



signature.asc
Description: OpenPGP digital signature

Bug#932872: [libkscreenlocker5] Doesn't lock automatically by timeout

[Alex Volkov]

Package: libkscreenlocker5
Version: 5.14.5-1
Severity: grave

--- Please enter the report below this line. ---

Doesn't lock automatically by timeout, which presents a security issue. Seems 
to work in a newly created test user setup, and randomly works sometimes in my 
user, but I have no idea what makes in work. Probably some app "inhibits" the 
automatic timeout, but I have no idea how to check it with all that 
"brilliant" dbus crap.  Ubuntu has https://wiki.ubuntu.com/
DebuggingScreenLocking, but it's for Gnome, not KDE.


--- System information. ---
Architecture: 
Kernel:   Linux 4.19.37-bootes0-iommu-p-1000

Debian Release: 10.0
  991 stable  security.debian.org 
  991 stable  ftp.fi.debian.org 
  990 buster-backports ftp.debian.org 
   99 stable  www.deb-multimedia.org 
  500 stable  dl.google.com 
  500 stable  deb.torproject.org 

--- Package information. ---
Depends (Version) | Installed
=-+-
kpackagetool5 | 5.54.0-1
libc6   (>= 2.28) | 
libkf5configcore5 (>= 5.24.0) | 
libkf5configgui5  (>= 4.97.0) | 
libkf5coreaddons5 (>= 4.97.0) | 
libkf5crash5  (>= 4.96.0) | 
libkf5declarative5   (>= 5.50.0~) | 
libkf5globalaccel-bin | 
libkf5globalaccel5 (>= 5.0.0) | 
libkf5i18n5   (>= 4.97.0) | 
libkf5idletime5   (>= 4.96.0) | 
libkf5notifications5  (>= 4.96.0) | 
libkf5package5(>= 5.42.0) | 
libkf5quickaddons5   (>= 5.50.0~) | 
libkf5waylandclient5 (>= 4:5.5.0) | 
libkf5waylandserver5 (>= 4:5.6.2) | 
libkf5windowsystem5   (>= 5.25.0) | 
libpam0g(>= 0.99.7.1) | 
libqt5core5a  (>= 5.11.0~rc1) | 
libqt5dbus5  (>= 5.11.0~) | 
libqt5gui5   (>= 5.11.0~) | 
libqt5network5   (>= 5.11.0~) | 
libqt5qml5 (>= 5.0.2) | 
libqt5quick5   (>= 5.2.0) | 
libqt5widgets5   (>= 5.11.0~) | 
libqt5x11extras5   (>= 5.6.0) | 
libseccomp2   (>= 0.0.0~20120605) | 
libstdc++6 (>= 4.4.0) | 
libwayland-client0(>= 1.9.91) | 
libwayland-server0  (>= 1.3~) | 
libx11-6  | 
libxcb-keysyms1(>= 0.4.0) | 
libxcb1   | 
libxi6(>= 2:1.2.99.4) | 


Recommends   (Version) | Installed
==-+-===
kde-config-screenlocker| 5.14.5-1


Package's Suggests field is empty.

Bug#932635: [Pkg-electronics-devel] Bug#932635: iverilog ftbfs in unstable

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

On Sun, Jul 21, 2019 at 04:06:17PM +0200, Matthias Klose wrote:
>dh_auto_test -a
>   make -j1 check VERBOSE=1
> make[1]: Entering directory '/<>'
> mv parse.cc.h parse.h 2>/dev/null || mv parse.hh parse.h
> mv: cannot stat 'parse.hh': No such file or directory
> make[1]: *** [Makefile:259: parse.h] Error 1
---end quoted text---

 suspect a problem in toolchain, because previously the build didn't 
 attempt to do this during 'make check':
 mv parse.cc.h parse.h 2>/dev/null || mv parse.hh parse.h


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


signature.asc
Description: PGP signature

Bug#932871: rpush improvemnts for tag2upload

[Ian Jackson]

Package: dgit-infrastructure
Version: 9.5
User: d...@packages.debian.org
Usertags: rsn

Quoting myself:

   It would probably be worthwhile checking critical fields, so that the
   signer cannot be tricked into signing things that the original
   git-debpush user could not have done.  I looked at the code and I
   think this is
 1 we need a slightly stronger syntax check for the Maintainer
when we construct the git tagger line
 2 we should cross-check the source package name in all
relevant places
 3 it would be easy to cross-check the version too.

1 is easy.  2 involves dgit rpush honouring -p.  3 means a new version
option I think.

We should also check the syntax of all the signed things are right.  I
think this means feeding eg buildinfo and changes and dsc to a deb822
parser, which we probably mostly already do.

None of this is particularly difficult.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#932795: Ethics of FTBFS bug reporting

[Gunnar Wolf]

Don Armstrong dijo [Tue, Jul 23, 2019 at 06:06:59PM -0700]:
> I think this discussion is great and good to have; thanks for starting it!

I completely concur.

> As a point of order, the TC isn't responsible for deciding whether bugs
> are RC or not. That responsibility belongs with the Release Managers.
> 
> [I don't think that should stop the TC from facilitating the decision
> and the baseline being enshrined in policy so the RMs can rely on it to
> decide whether it is RC or not.]

As we are at DebConf (from which most of the participants of this
thread so far are sorely missed), we have been exchanging some
heigher-bandwidth interactions.

I feel you are expressing the consensus we have found so far
informally. Thing is, the release managers have not been invested
formally of this power - But I think this is the way to be pursued. I
quite liked Ian's proposal of introducing "supported" and "reasonable"
as long-standing concepts that could be enshrined in our basic
documents (i.e. constitution) and in delegations. That way, they could
be rephrased - The Release Team delegation's task description can then
include keeping an updated qualifications for supported build
requirements, and thus, for determining whether a bug report regarding
the minimum characteristics of a system, determine whether the FTBFS
bugs it generates are RC or not.

[ I would like to write more, but Well, three beers are already in
  my system, as it is customary by 22:30 at DebConf. ]

Bug#926657: [Pkg-openldap-devel] Bug#926657: openldap: slapd process failure is not detected by systemd

[Ryan Tandy]

Control: tag -1 pending

Committed to git.

The generated unit already has Type=forking (hard-coded in 
sysv-generator), so I removed that line from the drop-in.


Context for posterity: 
https://github.com/systemd/systemd/issues/1211#issuecomment-138915391

Bug#925674: First triage

[Giovanni Mascellani]

Hi,

Il 23/07/19 22:19, Markus Koschany ha scritto:
> Thanks for your analysis. I will prepare a patch after the day trip, as
> soon as time permits.

No need for that, find the patch attached!

I did not test the generated package, though. Maybe you could do that.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
From: Giovanni Mascellani 
Date: Tue, 23 Jul 2019 18:48:17 -0300
Subject: Fix compilation with GCC 9

Building with GCC 9 fails because some standard structures do not
declare an overload for ==, relying on the implicit behaviour. This
patch fix the generated Lua bindings so that the operator == is
called, without forcing that operation to go though a specific
overload function.

---
 scripts/update_lua_bindings.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/update_lua_bindings.sh b/scripts/update_lua_bindings.sh
index c04eb01..e0e307c 100755
--- a/scripts/update_lua_bindings.sh
+++ b/scripts/update_lua_bindings.sh
@@ -16,3 +16,4 @@ else
 sed -i -e 's/const,/const /g' -e 's/tolua_outside//g' -e 's/tolua++\.h/components\/lua\/tolua++\.h/' $3
 fi
 
+sed  -i -e 's/self->operator==(\(.*\));$/((*self) == (\1));/g' $3


signature.asc
Description: OpenPGP digital signature

Bug#932769: #932769

[Mark Hutchison]

Hi fellas,

Apologies for the brevity in the initial bug report.  I was using the
reportbug tool directly from the console of the VM I was working on, small
resolution.  Allow me to elaborate...

We initially discovered this bug testing our storage product, we had a
Debian 10 VM running in a typical ESXi 6.7 environment with iSCSI backed
storage.  The VM ran in a VMDK file on a VMFS datastore volume.  While the
VM was running in memory, we removed the storage initiators from ESXi
purposefully to test something unrelated, to simulate a storage outage.
After a couple of minutes the OS will go into R/O mode without its disk,
and at that time dhclient will rapidly request IP's from our ISC DHCP
server.  dhclient will take the IP, consume it from the DHCP pool and then
request another.  After some period of time this depletes the DHCP pool,
several hours to days depending on the scopes size.  This could also be
replicated by deleting the hard disk from a running VM in a virtual
environment.

When I look at systemctl for the dhclient service, I can see that there's
an error, "can't create /var/lib/dhcp/dhclient.intname.leases Read Only
file system", and then the DHCPREQUEST > DHCPACK > DHCPDECLINE sequence
starts every few seconds, and occasionally the service will show "RTNETLINK
answers: File Exists."

I'm guessing from the error that dhclient has a problem with not being able
to read / write to the client leases file, declines the IP and requests
another, but secretly holds on to the IP.

The DHCP server logs will show a final DHCPDECLINE after the ACK, and mark
the address as abandoned.  The VM will still have the address leased
however.  After a period of time VMware's guest tools will show all the
consumed IP's belonging to that MAC address and virtual interface.  Network
gear ARP shows the IP's belonging to the same MAC as well.

We've consistently reproduced this bug in our lab, and performed the test
simultaneously with a Debian 9, Centos and Ubuntu 16 instance to make sure
it wasn't some kind of NetworkManager thing, or a broader Linux issue.

I see that someone reported this similar bug back in 2018 as well, I think
they may be the same thing.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888209

Thanks, just let me know if you have any questions.

Bug#932769: [moreinfo] DoS via DHCP request

[Mark Hutchison]

Hi fellas,

Apologies for the brevity in the initial bug report.  I was using the
reportbug tool directly from the console of the VM I was working on, small
resolution.  Allow me to elaborate...

We initially discovered this bug testing our storage product, we had a
Debian 10 VM running in a typical ESXi 6.7 environment with iSCSI backed
storage.  The VM ran in a VMDK file on a VMFS datastore volume.  While the
VM was running in memory, we removed the storage initiators from ESXi
purposefully to test something unrelated, to simulate a storage outage.
After a couple of minutes the OS will go into R/O mode without its disk,
and at that time dhclient will rapidly request IP's from our ISC DHCP
server.  dhclient will take the IP, consume it from the DHCP pool and then
request another.  After some period of time this depletes the DHCP pool,
several hours to days depending on the scopes size.  This could also be
replicated by deleting the hard disk from a running VM in a virtual
environment.

When I look at systemctl for the dhclient service, I can see that there's
an error, "can't create /var/lib/dhcp/dhclient.intname.leases Read Only
file system", and then the DHCPREQUEST > DHCPACK > DHCPDECLINE sequence
starts every few seconds, and occasionally the service will show "RTNETLINK
answers: File Exists."

I'm guessing from the error that dhclient has a problem with not being able
to read / write to the client leases file, declines the IP and requests
another, but secretly holds on to the IP.

The DHCP server logs will show a final DHCPDECLINE after the ACK, and mark
the address as abandoned.  The VM will still have the address leased
however.  After a period of time VMware's guest tools will show all the
consumed IP's belonging to that MAC address and virtual interface.  Network
gear ARP shows the IP's belonging to the same MAC as well.

We've consistently reproduced this bug in our lab, and performed the test
simultaneously with a Debian 9, Centos and Ubuntu 16 instance to make sure
it wasn't some kind of NetworkManager thing, or a broader Linux issue.

I see that someone reported this similar bug back in 2018 as well, I think
they may be the same thing.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888209

Thanks, just let me know if you have any questions.



On Tue, Jul 23, 2019 at 4:23 PM Tomáš Pospíšek  wrote:

> Am 23.07.19 um 17:57 schrieb Ben Hutchings:
> > On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
> >> Package: general
> >> Followup-For: Bug #932769
> >>
> >> Could you privide a recipe on how to reproduce this? There's a lot of
> >> very special setup below, that someone wwould need large amounts of time
> >> to reporoduce I feel.
> >>
> >> Is it possible to reduce the problem to something easily demonstratable?
> >>
> >> This seems to be an important issue to me.
> >>
> >> I think the problem here *might* be a kernel problem? Re-assign this to
> >> kernel package?
> > [...]
> >
> > So far as I know, the kernel only ever does DHCP if you net-boot
> > without an initramfs.
>
> My focus was more on this issue here - aparenty:
>
> Mark Hutchison wrote:
>
> >> This DoS's the server [due to DHCP changing IPs rapidly
> >> - my interpretation] and the interface attempts to take and discard
> >> IP's in a rapid fashion.
>
> -> changing IPs of an interface of a *VM* can DoS the server. Which I
> think is not expected, and not terribly funny. It takes a bit of not so
> straightforward circumstances (as far as I can understand the bug
> report), but then an attacker can DoS the server via DHCP. Which is uh,
> I mean ah, um.
>
> Information is a bit sparse here, though.
>
> If I may shoot completely off topic for a second: Woah, many thanks
> for your terrific kernel maintenance work Ben. Truly amazing :-o!!!
> Thanks so may times a lot! Woah :-) Thank you! (this doesn't exclude
> the rest of the kernel team - my thanks extend to you all - it's just
> that I have the honor to say thanks to a participating party in this
> email exchange 8v)!
> *t
>

Bug#932870: lintian: check that there are some autopkgtests that don't have Restrictions: superficial

[Paul Wise]

Package: lintian
Version: 2.16.0
Severity: wishlist
Suggested-by: dkg on #debci
X-Debbugs-CC: Daniel Kahn Gillmor 

autopkgtests that have Restrictions: superficial do not provide
significant test coverage. Please add a tag that is similar to the
testsuite-autopkgtest-missing tag that is shown when there are no
autopkgtests that are not marked as superficial. This will help ensure
that maintainers add tests that provide tests that give much more
significant test coverage and ensure the package is really functional.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#932841: libdpkg-perl: Dpkg::Source::Package installs a permanent SIGINT handler

[Guillem Jover]

Hi!

On Tue, 2019-07-23 at 20:44:35 +0100, Ian Jackson wrote:
> Package: libdpkg-perl
> Version: 1.18.25
> Severity: normal

> $ perl -we 'use Data::Dumper; print Dumper($SIG{INT})'
> $VAR1 = undef;
> $ perl -we 'use Data::Dumper; use Dpkg::Source::Package; print 
> Dumper($SIG{INT})'
> $VAR1 = sub { "DUMMY" };
> $
> 
> This is a problem because when a SIGINT handler is installed, perl
> will not immediately exit when it is in some other C library.
> 
> For example,
> 
> $ perl -we 'use Data::Dumper; use WWW::Curl::Easy; my $curl = 
> WWW::Curl::Easy->new; $curl->setopt(CURLOPT_URL, "http://192.0.2.1;); 
> $curl->perform()'
> ^C [returns prompt immediately]
> $ perl -we 'use Data::Dumper; use WWW::Curl::Easy; use Dpkg::Source::Package; 
> my $curl = WWW::Curl::Easy->new; $curl->setopt(CURLOPT_URL, 
> "http://192.0.2.1;); $curl->perform()'
> ^C [hangs]
> 
> If libdpkg-perl needs a signal handler it should install it only
> during its own operations, probably localising it and arranging to
> chain to the original handler (if any) when it has done its own work.

Ah indeed, this is not good.

> But I doubt the necessity.

This is coming from Dpkg::Exit, to hook up temporary file cleanup
handlers. The problem is that due to backwards compatibility this
has not been fixable in the past. But I guess it's about time to
start bumping module versions to 2.00 and start cleaning up this
kind of thing.

So I've fixed this locally, and will include that in 1.20.0.

Thanks,
Guillem

Bug#932869: xinetd: Annoying "Setting IPV6_V6ONLY option failed" warnings

[CUI Hao]

Package: xinetd
Version: 1:2.3.15.3-1
Severity: normal
Tags: upstream ipv6

Dear Maintainer,

xinetd produce "Setting IPV6_V6ONLY option failed" errors in syslog from time 
to time, which is really annoying.

I have reported this bug to upstream, and it has been fixed in the version 
2.3.15.4 (released almost 1 year ago). Please update Debian package.

For detail please see:
https://github.com/openSUSE/xinetd/issues/11

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages xinetd depends on:
ii  libc62.28-10
ii  libselinux1  2.8-1+b1
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400
ii  netbase  5.6

Versions of packages xinetd recommends:
ii  logrotate3.14.0-4
ii  rsyslog [system-log-daemon]  8.1901.0-1
ii  update-inetd 4.49

xinetd suggests no packages.

-- no debconf information

Bug#925674: First triage

[Markus Koschany]

Hi Giovanni,

Am 23.07.19 um 18:57 schrieb Giovanni Mascellani:
> Hi,
> 
> the problem here is that operator== is called on an instance of
> std::map<>::iterator. The intention is probably to compare two iterators
> for inequality. But calling the operator overloading function is not the
> right thing, because the implementation of std::map<>::iterator might
> use the default iterator, and not overload it. Probably GCC 8 used an
> overloaded operator, but GCC 9 reverted to the default one. User code
> should not call the function "operator==", but use the "==" operator and
> let the compiler do its work.
> 
> I believe that the bug should be fixed by changing
> 
>   bool tolua_ret = (bool)  self->operator==(*value);
> 
> to
> 
>   bool tolua_ret = (bool)  ((*self)==(*value);
> 
> The problem is that that line of code is automatically generated by the
> "tolua" tool. I suppose that tolua should be fixed to generate correct
> code. I will look into that later, if I can.
> 
> Greetings from Curitiba!

Thanks for your analysis. I will prepare a patch after the day trip, as
soon as time permits.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#932868: mypaint: depends on mypaint-data (>= 1.2.0-4.1) but it will not be installed

[Blau Araujo]

Package: mypaint
Version:  1.2.0-4.1


Apparently, mypaint package dependencies are broken in Buster. Also, 
attempting to install the dependency (mypaint-data) results in the 
removal of gimp package.


Thanks,
Blau Araujo

Bug#932865: python-qrtools: not installable: depends on python2 version of zbar

[Adam Borowski]

Package: python-qrtools
Version: 1.4~bzr32-1
Severity: grave
Justification: renders package unusable

Hi!
This package depends on python-zbar, which has already been removed as part
of the python2-rm transition.  This obviously makes it non-installable.


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

Kernel: Linux 5.2.1-00036-gf2c1d208af28 (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python-qrtools depends on:
ii  python   2.7.16-1
pn  python-pil   
pn  python-zbar  
pn  qrencode 

python-qrtools recommends no packages.

python-qrtools suggests no packages.

Bug#932795: Ethics of FTBFS bug reporting

[Don Armstrong]

I think this discussion is great and good to have; thanks for starting it!

As a point of order, the TC isn't responsible for deciding whether bugs
are RC or not. That responsibility belongs with the Release Managers.

[I don't think that should stop the TC from facilitating the decision
and the baseline being enshrined in policy so the RMs can rely on it to
decide whether it is RC or not.]

-- 
Don Armstrong  https://www.donarmstrong.com

Those who begin coercive elimination of dissent soon find themselves
exterminating dissenters. Compulsory unification of opinion achieves
only the unanimity of the graveyard.
 -- Justice Roberts in 319 U.S. 624 (1943)

Bug#932866: RFS: elpy/1.29.1+31.ge61540b-1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear Chris and mentors,

I am looking for a sponsor for my package "elpy".  A new upstream
version is needed because self-tests are failing in DebCI with the
existing version due to the new version of Black.  I chose to package
a git snapshot because it's a poor use of free time to rebase and
3-way merge the patch queue onto the last stable release, and because
if the relaxed timing for self-tests doesn't do the trick on DebCI
then we'll need something close to upstream/master to work with
upstream on a fix.

Package name: elpy
Version : 1.29.1+31.ge61540b-1
URL : https://github.com/jorgenschaefer/elpy
License : GPL-3+
Section : devel

It builds this binary package:

  elpa-elpy - Emacs Python Development Environment

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/elpy

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.29.1+31.ge61540b-1.dsc

Or clone from here and use gbp to build:

  https://salsa.debian.org/emacsen-team/elpy.git


Changes since the last upload:

elpy (1.29.1+31.ge61540b-1) unstable; urgency=medium

  * Package upstream snapshot.
  * Drop all patches that were merged upstream:
0002-Add-a-quickstart-section-to-the-documentation-1598.patch
0003-Make-sure-we-cannot-load-Elpy-twice.patch
0004-Enable-elpy-mode-in-python-buffer-when-enabling-Elpy.patch
0005-Fix-typo.patch
  * Register HTML documentation with doc-base.
  * Add a tip to README.Debian about how to trigger elpy-enable only for
buffers that would use python-mode, instead of unconditionally running
it during Emacs init.
  * debian/elpa-test: Set elpa-rpc-timeout to double it's default value to
defend against timing-related self-test failures on DebCI.
  * Add 0002-Double-max-wait-in-elpy-wait-for-output-self-test.patch to
double the amount of time we wait-for-output during self-tests.
  * Switch to debhelper-compat 12.

 -- Nicholas D Steeves   Tue, 23 Jul 2019 20:22:01 -0400

elpy (1.28.0-2) unstable; urgency=medium


Regards,
Nicholas

Bug#932867: mugshot: not in Buster

[Blau Araujo]

Package: mugshot
Version: 0.4.1-1

Dear maintainers,

For some reason, mugshot was migrated to Testing and removed from Buster.

Since it is a program that affects one of the features of the Whisker 
menu, widely used in Xfce, I think it would be important to review its 
removal from Buster.


Package Tracker page: https://tracker.debian.org/pkg/mugshot
Maintainer: python-apps-t...@lists.alioth.debian.org

Thanks,
Blau Araujo

Bug#932864: pinta: not in Buster

[Blau Araujo]

Package: pinta
Version: 1.6-2


Dear maintainers,



Although it appears in Package Tracker as in Stable (version 1.6-2), 
Pinta package is unavailable for installation in Buster.



Package Tracker: https://tracker.debian.org/pkg/pinta
Maintainer: pkg-cli-apps-t...@lists.alioth.debian.org
Uploader: si...@ubuntu.com


Thanks,
Blau Araujo

Bug#932863: RFP: GNU Health - a hospital information system

[mason]

Package: wnpp

Severity: wishlist

Upstream Dev: http://hg.savannah.gnu.org/hgweb/health/

Official Website: http://health.gnu.org/home

Description: GNU Health is a Free/Libre project for health
practitioners, health institutions and governments. It provides the
functionality of Electronic Medical Record (EMR), Hospital Management
(HMIS) and Health Information System (HIS).

Its modular design allows to be deployed in many different scenarios:
from small private offices, to large, national public health systems.

Programming Language: Python

License: GPLv3+


signature.asc
Description: PGP signature

Bug#932862: lintian: check for autopkgtests that do cmd --version/--help but don't have Restrictions: superficial

[Paul Wise]

Package: lintian
Version: 2.16.0
Severity: wishlist

A number of packages run cmd --version/--help in their autopkgtests.
This test doesn't really test the functionality of the command, just of the 
command-line and options parsing. autopkgtest has an option called superficial 
for the Restrictions field that can be used to mark a test as not really 
exercising any real functionality. Trivial tests like running a command with 
the --version or --help options should be marked as superficial. Please add a 
lintian warning when a test runs either a command from $PATH or a test script 
with just a --help or --version argument but has not marked the test as 
superficial. There are probably a number of different ways to write a 
superficial that are harder to detect (like the one in uhubctl), but those will 
require manual review.

https://codesearch.debian.net/search?q=path%3Adebian%2Ftests%2Fcontrol+--%28version%7Chelp%29
https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst#L302
https://codesearch.debian.net/search?q=path%3Adebian%2Ftests%2F+--%28version%7Chelp%29

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#932860: wine can not be installed after updating libglib2.0-0 to 2.60

[James Lu]

Hi,

It looks like you're trying to install the Wine packages from WineHQ,
which are not the same ones provided by Debian. It doesn't look like the
WineHQ repository has been updated for Bullseye yet, so it's likely
you'll have to wait for them to add those missing builds.

Best,
James

On 2019-07-23 5:02 p.m., fin4478 fin4478 wrote:
> Package: wine32
> Version: 4.0-2
> 
> To prevent warnings in the file .xsession-errors with the Xfce 4.13.3
> desktop libglib2.0-0 must be updated to the version 2.60. This removes
> wine and many of its libraries. Reinstalling wine shows the following
> problems:
> xfce@optipc:~$ sudo aptitude install winehq-staging
> The following NEW packages will be installed:
>   acl{a} glib-networking:i386{a} gstreamer1.0-plugins-base:i386{a} 
>   libasound2-plugins:i386{a} libatk-bridge2.0-0:i386{a} libatk1.0-0:i386{a} 
>   libatspi2.0-0:i386{a} libavcodec58:i386{a} libbz2-1.0:i386{a} 
>   libcairo-gobject2:i386{a} libcolord2:i386{a} libcroco3:i386{a} 
>   libgdbm-compat4:i386{a} libgdbm6:i386{a} libgdk-pixbuf2.0-0:i386{a} 
>   libgstreamer-plugins-base1.0-0:i386{a} libgstreamer1.0-0:i386{a} 
>   libgtk-3-0:i386{a} libharfbuzz0b:i386{a} libieee1284-3{a} 
>   libieee1284-3:i386{a} libjson-glib-1.0-0:i386{a} libmariadb3:i386{a} 
>   libpango-1.0-0:i386{a} libpangocairo-1.0-0:i386{a} 
>   libpangoft2-1.0-0:i386{a} libpci3:i386{a} libperl5.28:i386{a} 
>   librest-0.7-0:i386{a} librsvg2-2:i386{a} librsvg2-common:i386{a} 
>   libsane{a} libsane:i386{a} libsane-common{a} libsensors-config{ab} 
>   libsensors5{a} libsensors5:i386{a} libsnmp-base{a} libsnmp30{a} 
>   libsnmp30:i386{a} libsoup-gnome2.4-1:i386{a} libsoup2.4-1:i386{a} 
>   sane-utils{a} update-inetd{a} wine-staging{a} wine-staging-amd64{a} 
>   wine-staging-i386:i386{a} winehq-staging 
> The following packages will be REMOVED:
>   bind9-host{u} cgroupfs-mount{u} dkms{u} fonts-wine{u} geoip-database{u} 
>   gtk2-engines-xfce{u} i965-va-driver:i386{u} intel-media-va-driver:i386{u} 
>   libasyncns0:i386{u} libavahi-common-data:i386{u} libavahi-core7{u} 
>   libavcodec57:i386{u} libavutil55:i386{u} libbind9-161{u} 
>   libcom-err2:i386{u} libdaemon0{u} libdatrie1:i386{u} libdns1104{u} 
>   libexif12:i386{u} libexo-1-0{u} libfaudio0{u} libflac8:i386{u} 
>   libfstrm0{u} libgcrypt20:i386{u} libgd3:i386{u} libgeoip1{u} 
>   libgeos-3.7.1{u} libgmp10:i386{u} libgomp1:i386{u} libgpm2:i386{u} 
>   libgsoap-2.8.75{u} libgtksourceview-3.0-1{u} 
>   libgtksourceview-3.0-common{u} libhogweed4:i386{u} libice6:i386{u} 
>   libicu63:i386{u} libigdgmm9:i386{u} libintl-perl{u} libintl-xs-perl{u} 
>   libisc1100{u} libisccc161{u} libisccfg163{u} libjbig0:i386{u} 
>   libjim0.77{u} libk5crypto3:i386{u} libkeybinder-3.0-0{u} 
>   libkeyutils1:i386{u} libkrb5support0:i386{u} libllvm7{u} libltdl7:i386{u} 
>   liblwres161{u} liblz4-1:i386{u} libmbim-glib4{u} libmbim-proxy{u} 
>   libmodule-find-perl{u} libmodule-scandeps-perl{u} libnettle6:i386{u} 
>   libnotify-bin{u} libnuma1:i386{u} libp11-kit0:i386{u} 
>   libpixman-1-0:i386{u} libproc-processtable-perl{u} libprotobuf-c1{u} 
>   libqmi-glib5{u} libqmi-proxy{u} libreadline7{u} libsasl2-2:i386{u} 
>   libsasl2-modules:i386{u} libsasl2-modules-db:i386{u} libsm6:i386{u} 
>   libsndfile1:i386{u} libsndio7.0:i386{u} libsort-naturally-perl{u} 
>   libsoxr0:i386{u} libstb0{u} libstb0:i386{u} libswresample2:i386{u} 
>   libsystemd0:i386{u} libtasn1-6:i386{u} libterm-readkey-perl{u} 
>   libv4lconvert0:i386{u} libva-drm1:i386{u} libva-x11-1:i386{u} 
>   libva1:i386{u} libvdpau-va-gl1:i386{u} libvdpau1:i386{u} libvncserver1{u} 
>   libvpx4:i386{u} libwebpmux2:i386{u} libwnck-common{u} libwnck22{u} 
>   libx264-148:i386{u} libx265-95:i386{u} libxcb-render0:i386{u} 
>   libxcb-shm0:i386{u} libxcb-xfixes0:i386{u} libxfce4ui-utils{u} 
>   libxpm4:i386{u} libxtst6:i386{u} libzstd1:i386{u} mesa-va-drivers:i386{u} 
>   mesa-vdpau-drivers:i386{u} needrestart{u} runc{u} tini{u} 
>   usb-modeswitch{u} usb-modeswitch-data{u} va-driver-all:i386{u} 
>   vdpau-driver-all:i386{u} xfce4-appfinder{u} 
> 0 packages upgraded, 48 newly installed, 110 to remove and 15 not upgraded.
> Need to get 173 MB of archives. After unpacking 1,145 MB will be used.
> The following packages have unmet dependencies:
>  libx265-165:i386 : Depends: libnuma1:i386 (>= 2.0.11) but it is not going to 
> be installed
>  libkrb5-3:i386 : Depends: libcom-err2:i386 (>= 1.43.9) but it is not going 
> to be installed
>   Depends: libk5crypto3:i386 (>= 1.15~beta1) but it is not 
> going to be installed
>   Depends: libkeyutils1:i386 (>= 1.5.9) but it is not going 
> to be installed
>   Depends: libkrb5support0:i386 (= 1.17-5) but it is not 
> going to be installed
>  libgssapi-krb5-2:i386 : Depends: libcom-err2:i386 (>= 1.43.9) but it is not 
> going to be installed
>  Depends: libk5crypto3:i386 (>= 1.16) but it is not 
> going to be installed
>  Depends: 

Bug#932861: e2fsprogs should depend on logsave

[Kyle Robbertze]

Package: e2fsprogs
Version: 1.45.3-1
Severity: serious
Justification: Policy 3.5

Dear Maintainer,

After upgrading e2fsprogs to 1.45.3-1, my system refused to boot with
the error:

> /init: line 398: logsave: not found
>
> The root filesystem on /dev/sda3 requires a manual fsck

I was then dropped back in to the initramfs shell. After ensuring that
the file system was clean using fsck and rebooting, the same issue
occured. The solution was to use a live image to chroot into the system
and install logsave. The system then booted normally.

Thus, the suggests on logsave should be replaced with a depends, as the
package is unusable without it.

Thanks
Kyle

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

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

Versions of packages e2fsprogs depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcom-err2  1.45.3-1
ii  libext2fs2   1.45.3-1
ii  libss2   1.45.3-1
ii  libuuid1 2.33.1-0.1

Versions of packages e2fsprogs recommends:
ii  e2fsprogs-l10n  1.45.3-1

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  logsave1.45.3-1
ii  parted 3.2-25+b1

-- no debconf information

Bug#923372: You need install logsave manually and recreate initrd after this change

[Javier Barroso]

Hello,

Using unstable, after the last update, I hit logsave not found , at
initramfs prompt (see the old bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833231)

I needed to install manually the logsave package and then reinstall the
latest kernel to get logsave inside the initrd

Thank you very much !

PD: Not sure which is the best method to skip the manual installation

Bug#932860: wine can not be installed after updating libglib2.0-0 to 2.60

[fin4478 fin4478]

Package: wine32
Version: 4.0-2

To prevent warnings in the file .xsession-errors with the Xfce 4.13.3
desktop libglib2.0-0 must be updated to the version 2.60. This removes
wine and many of its libraries. Reinstalling wine shows the following
problems:
xfce@optipc:~$ sudo aptitude install winehq-staging
The following NEW packages will be installed:
  acl{a} glib-networking:i386{a} gstreamer1.0-plugins-base:i386{a} 
  libasound2-plugins:i386{a} libatk-bridge2.0-0:i386{a} libatk1.0-0:i386{a} 
  libatspi2.0-0:i386{a} libavcodec58:i386{a} libbz2-1.0:i386{a} 
  libcairo-gobject2:i386{a} libcolord2:i386{a} libcroco3:i386{a} 
  libgdbm-compat4:i386{a} libgdbm6:i386{a} libgdk-pixbuf2.0-0:i386{a} 
  libgstreamer-plugins-base1.0-0:i386{a} libgstreamer1.0-0:i386{a} 
  libgtk-3-0:i386{a} libharfbuzz0b:i386{a} libieee1284-3{a} 
  libieee1284-3:i386{a} libjson-glib-1.0-0:i386{a} libmariadb3:i386{a} 
  libpango-1.0-0:i386{a} libpangocairo-1.0-0:i386{a} 
  libpangoft2-1.0-0:i386{a} libpci3:i386{a} libperl5.28:i386{a} 
  librest-0.7-0:i386{a} librsvg2-2:i386{a} librsvg2-common:i386{a} 
  libsane{a} libsane:i386{a} libsane-common{a} libsensors-config{ab} 
  libsensors5{a} libsensors5:i386{a} libsnmp-base{a} libsnmp30{a} 
  libsnmp30:i386{a} libsoup-gnome2.4-1:i386{a} libsoup2.4-1:i386{a} 
  sane-utils{a} update-inetd{a} wine-staging{a} wine-staging-amd64{a} 
  wine-staging-i386:i386{a} winehq-staging 
The following packages will be REMOVED:
  bind9-host{u} cgroupfs-mount{u} dkms{u} fonts-wine{u} geoip-database{u} 
  gtk2-engines-xfce{u} i965-va-driver:i386{u} intel-media-va-driver:i386{u} 
  libasyncns0:i386{u} libavahi-common-data:i386{u} libavahi-core7{u} 
  libavcodec57:i386{u} libavutil55:i386{u} libbind9-161{u} 
  libcom-err2:i386{u} libdaemon0{u} libdatrie1:i386{u} libdns1104{u} 
  libexif12:i386{u} libexo-1-0{u} libfaudio0{u} libflac8:i386{u} 
  libfstrm0{u} libgcrypt20:i386{u} libgd3:i386{u} libgeoip1{u} 
  libgeos-3.7.1{u} libgmp10:i386{u} libgomp1:i386{u} libgpm2:i386{u} 
  libgsoap-2.8.75{u} libgtksourceview-3.0-1{u} 
  libgtksourceview-3.0-common{u} libhogweed4:i386{u} libice6:i386{u} 
  libicu63:i386{u} libigdgmm9:i386{u} libintl-perl{u} libintl-xs-perl{u} 
  libisc1100{u} libisccc161{u} libisccfg163{u} libjbig0:i386{u} 
  libjim0.77{u} libk5crypto3:i386{u} libkeybinder-3.0-0{u} 
  libkeyutils1:i386{u} libkrb5support0:i386{u} libllvm7{u} libltdl7:i386{u} 
  liblwres161{u} liblz4-1:i386{u} libmbim-glib4{u} libmbim-proxy{u} 
  libmodule-find-perl{u} libmodule-scandeps-perl{u} libnettle6:i386{u} 
  libnotify-bin{u} libnuma1:i386{u} libp11-kit0:i386{u} 
  libpixman-1-0:i386{u} libproc-processtable-perl{u} libprotobuf-c1{u} 
  libqmi-glib5{u} libqmi-proxy{u} libreadline7{u} libsasl2-2:i386{u} 
  libsasl2-modules:i386{u} libsasl2-modules-db:i386{u} libsm6:i386{u} 
  libsndfile1:i386{u} libsndio7.0:i386{u} libsort-naturally-perl{u} 
  libsoxr0:i386{u} libstb0{u} libstb0:i386{u} libswresample2:i386{u} 
  libsystemd0:i386{u} libtasn1-6:i386{u} libterm-readkey-perl{u} 
  libv4lconvert0:i386{u} libva-drm1:i386{u} libva-x11-1:i386{u} 
  libva1:i386{u} libvdpau-va-gl1:i386{u} libvdpau1:i386{u} libvncserver1{u} 
  libvpx4:i386{u} libwebpmux2:i386{u} libwnck-common{u} libwnck22{u} 
  libx264-148:i386{u} libx265-95:i386{u} libxcb-render0:i386{u} 
  libxcb-shm0:i386{u} libxcb-xfixes0:i386{u} libxfce4ui-utils{u} 
  libxpm4:i386{u} libxtst6:i386{u} libzstd1:i386{u} mesa-va-drivers:i386{u} 
  mesa-vdpau-drivers:i386{u} needrestart{u} runc{u} tini{u} 
  usb-modeswitch{u} usb-modeswitch-data{u} va-driver-all:i386{u} 
  vdpau-driver-all:i386{u} xfce4-appfinder{u} 
0 packages upgraded, 48 newly installed, 110 to remove and 15 not upgraded.
Need to get 173 MB of archives. After unpacking 1,145 MB will be used.
The following packages have unmet dependencies:
 libx265-165:i386 : Depends: libnuma1:i386 (>= 2.0.11) but it is not going to 
be installed
 libkrb5-3:i386 : Depends: libcom-err2:i386 (>= 1.43.9) but it is not going to 
be installed
  Depends: libk5crypto3:i386 (>= 1.15~beta1) but it is not 
going to be installed
  Depends: libkeyutils1:i386 (>= 1.5.9) but it is not going to 
be installed
  Depends: libkrb5support0:i386 (= 1.17-5) but it is not going 
to be installed
 libgssapi-krb5-2:i386 : Depends: libcom-err2:i386 (>= 1.43.9) but it is not 
going to be installed
 Depends: libk5crypto3:i386 (>= 1.16) but it is not 
going to be installed
 Depends: libkeyutils1:i386 (>= 1.4) but it is not 
going to be installed
 Depends: libkrb5support0:i386 (>= 1.15~beta1) but it 
is not going to be installed
 libgphoto2-port12:i386 : Depends: libltdl7:i386 (>= 2.4.6) but it is not going 
to be installed
 libdbus-1-3:i386 : Depends: libsystemd0:i386 but it is not going to be 
installed
 libldap-2.4-2:i386 : Depends: libsasl2-2:i386 (>= 2.1.27+dfsg) but it is not 
going to be installed
 libgphoto2-6:i386 : Depends: 

Bug#932859: logsave not found

[Ivan Sergio Borgonovo]

Package: e2fsprogs
Version: 1.45.3-1

Upgrading from 1.45.2-1 to 1.45.3-1 I get stuck in initramfs with this 
messages


/init: line 398: logsave: not found
The root filesystem on /dev/md0 requires a manual fsck

Kernel 4.19.37-6 doesn't work with new e2fsprogs/libext2fs2.

Kernel 4.19.28-2 works with both old and new e2fsprogs/libext2fs2.

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#932854: Missing dependency for initramfs-tools-core

[Miguel A. Vallejo]

I can confirm this problem. After manually fsck the root partition and
still get the same initramfs shell I downgraded e2fsprogs and
libext2fs2 to the previous versions I found in /var/cache/apt/archives
(1.45.2-1) and the system booted again.

Bug#932244: ITP: php-easyrdf -- PHP library for RDF

[Marco Villegas]

Hi,

Some good news:

* The package git repository has now been moved to the php team in
  salsa, see https://salsa.debian.org/php-team/pear/php-easyrdf
* I managed to get gbp working correctly. In the process, while using
  pristine tar I noticed the release tarball is removing development
  related files, including tests, which is OK at this point, since they
  require an old version of phpunit, so the related debian package
  cannot run them, which is something that may be something to change
  upstream.
* I have uploaded the new version of the package to mentors too, see
  https://mentors.debian.net/package/php-easyrdf

Some context on why this package can be useful:

* Resource Description Framework, RDF,  is an official W3C
  Recommendation for Semantic Web data models.
* There is no a RDF related php library in Debian.
* This library is used by multiple upstream projects, see [1] for a
  list in packagist. So having it packaged will help to add any of
  those projects, e.g. drupal.

On the packaged version:

* The upstream project has a 0.9.x branch, which is used by many
  projects.
* It also has a master branch, which contains on it a
  0.10.0-alpha.1 tag, which I avoided since (i) it is not stable, and
  (ii) has several new dependencies. 

1: https://packagist.org/packages/easyrdf/easyrdf/dependents

Best,

-Marco

Bug#932858: smtp.montor: hostname() doesn't accept any arguments

[Allan Wind]

Package: mon
Version: 1.3.3-2
Severity: normal

Dear Maintainer,

smtp.montitor contains two two warnings from Sys::Hostname::hostname in
the Summary and Detail:

Summary: hostname() doesn't accept any arguments. This will become fatal in 
Perl 
5.32 at /usr/lib/mon/mon.d/smtp.monitor line 248. 

Detail: hostname() doesn't accept any arguments. This will become fatal 
in Perl 5.32 at /usr/lib/mon/mon.d/smtp.monitor line 181.

This is because the function is called as  which implicitly 
passed @_ (at call site), i.e. hostname(@_).  This defect is easy enough 
to fix, namely, change the two lines from:

$OurHostname = 

to:

$OurHostname = hostname();


/Allan

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

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

Versions of packages mon depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libtime-period-perl  1.25-1
ii  mon-client   1.2.0-2

Versions of packages mon recommends:
ii  bc   1.07.1-2+b1
ii  fping4.2-1
pn  libauthen-pam-perl   
ii  libcgi-pm-perl   4.40-1
pn  libcrypt-ssleay-perl 
ii  libfilesys-df-perl   0.92-6+b4
ii  libmail-imapclient-perl  3.42-1
ii  libnet-dns-perl  1.19-1
pn  libnet-ldap-perl 
ii  libnet-telnet-perl   3.04-1
ii  libproc-processtable-perl0.56-1
ii  libsnmp-perl 5.7.3+dfsg-5
ii  libstatistics-descriptive-perl   3.0702-1
pn  libtime-parsedate-perl   
ii  libtimedate-perl 2.3000-2
ii  perl-modules-5.24 [libnet-perl]  5.24.1-3+deb9u5
ii  swaks20181104.0-2

Versions of packages mon suggests:
ii  mon-contrib  1.0+dfsg-4

-- Configuration Files:
/etc/mon/auth.cf changed [not included]
/etc/mon/mon.cf [Errno 2] No such file or directory: '/etc/mon/mon.cf'

-- no debconf information

Bug#932856: mariadb-client-10.3: mysqldump uses 10.3 options with pre-10.3 servers and breaks

[Daniel Fussell]

Package: mariadb-client-10.3
Version: 1:10.3.15-1
Severity: critical
Tags: upstream
Justification: causes serious data loss

Dear Maintainer,

mysqldump is unable to backup triggers and routines from any pre-10.3
version server

From the upstream bug-report ( https://jira.mariadb.org/browse/MDEV-17429):

When issuing a 10.3 mysqldump command to dump triggers and routines
from a 10.2 server, the tool breaks because it tries to issue a SHOW
PACKAGES command which is not supported in 10.2 and earlier releases.

mysqldump --quick --routines --triggers --no-create-info
--skip-lock-tables --no-data --compress -h 10.10.16.138 -u
mariadb_mock_import -p myschema



mysqldump: Couldn't execute 'SHOW PACKAGE STATUS WHERE Db =
'myschema'': You have an error in your SQL syntax; check the manual
that corresponds to your MariaDB server version for the right syntax
to use near 'PACKAGE STATUS WHERE Db = 'myschema'' at line 1 (1064)

Running mysqldump without the --triggers and --routines flags will
backup the database structure and data, but will lose the associated
triggers and routines.  For admins and developers, loading the dump back
into a server would require manually creating the triggers from some
previous backup or repository (assuming a viable backup exists).

Running mysqldump with --triggers and --routines flags enabled will fail
entirely, potentially breaking backup scripts and cron jobs that depend
on it.  While this will not lose data directly, it does preclude the
option of restoring databases when a server upgrade fails, or tables are
corrupted, or when a mistaken drop/update/replace/insert statement is
issued.

A successful database dump (including triggers and routines) is expected.

The mysqldump 10.3 server version incompatibility is reported to be
fixed in 10.3.17.

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

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

Versions of packages mariadb-client-10.3 depends on:
ii  debianutils   4.8.6.1
ii  libc6 2.28-10
ii  libconfig-inifiles-perl   3.01-1
ii  libgnutls30   3.6.7-4
ii  libstdc++6    8.3.0-6
ii  mariadb-client-core-10.3  1:10.3.15-1
ii  perl  5.28.1-6
ii  zlib1g    1:1.2.11.dfsg-1

Versions of packages mariadb-client-10.3 recommends:
ii  libdbd-mysql-perl 4.050-2
ii  libdbi-perl   1.642-1+b1
ii  libterm-readkey-perl  2.38-1

mariadb-client-10.3 suggests no packages.

-- no debconf information

Bug#932857: RM: r-cran-rjsonio -- ROM; Nobody wants to maintain this non-free package

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi ftpmasters,

I was asking on debian-r list[1] whether somebody wants to take over
this non-free package and did not got any positive response.  So please
remove it from the archive.

Thanks for your work as ftpmaster

  Andreas.

[1] https://lists.debian.org/debian-r/2019/07/msg6.html

Bug#932769: [moreinfo] DoS via DHCP request

[Tomáš Pospíšek]

Am 23.07.19 um 17:57 schrieb Ben Hutchings:
> On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
>> Package: general
>> Followup-For: Bug #932769
>>
>> Could you privide a recipe on how to reproduce this? There's a lot of
>> very special setup below, that someone wwould need large amounts of time
>> to reporoduce I feel.
>>
>> Is it possible to reduce the problem to something easily demonstratable?
>>
>> This seems to be an important issue to me.
>>
>> I think the problem here *might* be a kernel problem? Re-assign this to
>> kernel package?
> [...]
> 
> So far as I know, the kernel only ever does DHCP if you net-boot
> without an initramfs.

My focus was more on this issue here - aparenty:

Mark Hutchison wrote:

>> This DoS's the server [due to DHCP changing IPs rapidly
>> - my interpretation] and the interface attempts to take and discard
>> IP's in a rapid fashion.

-> changing IPs of an interface of a *VM* can DoS the server. Which I
think is not expected, and not terribly funny. It takes a bit of not so
straightforward circumstances (as far as I can understand the bug
report), but then an attacker can DoS the server via DHCP. Which is uh,
I mean ah, um.

Information is a bit sparse here, though.

If I may shoot completely off topic for a second: Woah, many thanks
for your terrific kernel maintenance work Ben. Truly amazing :-o!!!
Thanks so may times a lot! Woah :-) Thank you! (this doesn't exclude
the rest of the kernel team - my thanks extend to you all - it's just
that I have the honor to say thanks to a participating party in this
email exchange 8v)!
*t

Bug#931728: variety: privacy breach in variety

[James Lu]

Control: tags -1 + help

A brief trip upstream reveals that the settings fetching is to (1) rate
limit API calls to prevent going over limits (2) provide usage
statistics for remote APIs that mandate them.

These are sort of tied to the online fetching bits of Variety, so
perhaps a solution might be to have a confirmation window at first run
to opt-in to the online features. I want to work on this soon, but my
knowledge of GTK and Variety's config system aren't super thorough...

Best,
James

On 2019-07-09 10:07 a.m., James Lu wrote:
> Control: forwarded -1 https://github.com/varietywalls/variety/issues/198
> 
> Hi Damyan,
> 
> I've copied this upstream, thanks for spotting this.
> 
> Best,
> James
> 
> On 2019-07-09 9:43 a.m., Damyan Ivanov wrote:
>> Package: variety
>> Version: 0.7.1-2
>> Severity: important
>> Tags: upstream
>>
>> Hi,
>>
>> Thank you for packaging variety. It is a very nice program and does its work 
>> smoothly.
>>
>> Sadly, it contains code which attempts to load "options" from a remove 
>> server 
>> without user's consent. See [1] and [2].
>>
>> [1] 
>> https://sources.debian.org/src/variety/0.7.1-2/variety/VarietyWindow.py/?hl=81#L609
>> [2] 
>> https://sources.debian.org/src/variety/0.7.1-2/variety/VarietyWindow.py/?hl=81#L932
>>
>> I'll prepare a merge request that removes the start of the background thread 
>> which does the fetch. Variety works just fine without it.
>>
>>
>> Thanks for considering,
>> Damyan
>>
>> -- System Information:
>> Debian Release: 10.0
>>   APT prefers unstable-debug
>>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
>> (1, 'experimental')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
>> Kernel taint flags: TAINT_OOT_MODULE
>> Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=bg_BG.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages variety depends on:
>> ii  gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1
>> ii  gir1.2-gexiv2-0.10   0.10.9-1
>> ii  gir1.2-glib-2.0  1.58.3-2
>> ii  gir1.2-gtk-3.0   3.24.5-1
>> ii  gir1.2-notify-0.70.7.7-4
>> ii  gir1.2-pango-1.0 1.42.4-6
>> ii  imagemagick  8:6.9.10.23+dfsg-2.1
>> ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
>> ii  python3  3.7.3-1
>> ii  python3-bs4  4.7.1-1
>> ii  python3-cairo1.16.2-1+b1
>> ii  python3-configobj5.0.6-3
>> ii  python3-dbus 1.2.8-3
>> ii  python3-gi   3.30.4-1
>> ii  python3-gi-cairo 3.30.4-1
>> ii  python3-lxml 4.3.3-2
>> ii  python3-pil  5.4.1-2
>> ii  python3-pkg-resources41.0.1-1
>> ii  python3-requests 2.21.0-1
>>
>> Versions of packages variety recommends:
>> ii  gir1.2-appindicator3-0.1  0.4.92-7
>> ii  python3-httplib2  0.11.3-2
>>
>> Versions of packages variety suggests:
>> pn  feh | nitrogen  
>> ii  gnome-shell-extension-appindicator  22-1
>>
>> -- no debconf information
>>
> 



signature.asc
Description: OpenPGP digital signature

Bug#932854: Missing dependency for initramfs-tools-core

[Colin Booth]

Package: initramfs-tools-core
Version: 0.133

The functions file shipped with initramfs-tools-core version 0.133 and
earlier contains a call to logsave(8) in the _checkfs_once() function.
The latest version of e2fsprogs (1.45.3-1) has removed logsave and it is
now shipped in a separate package. This causes a surprise drop into an
initramfs shell as the fsck line fails.

Please add a Depends: logsave in the next shipping version of
initramfs-tools-core or update the _checkfs_once function to not require
that program.

-- 
Colin Booth

Bug#932855: e2fsprogs 1.45.3-1 breaks initramfs-tools-core <=0.133

[Colin Booth]

Package: e2fsprogs
Version: 1.45.3-1

The split of logsave(8) from e2fsprogs into its own package breaks all
initramfs images built using the scripts/functions file shipped with
initramfs-tools-core due to a missing dependency in the broken package.

Expected: correctly fsck'ed and booting system.

Observed: initramfs panic with "The X filesystem on Y requires a manual
fsck".

Installing logsave fixes the problem as update-initramfs is able to
locate and pack the file correctly.

-- 
Colin Booth

Bug#932853: please someone "git checkout -b bullseye && git push"

[Tomas Pospisek]

Package: release-notes
Severity: wishlist

I have considered forking and branching via Salsa, and then sending the
pull request, but that's not less work. So I'm very kindly asking, if
someone with commit rights could please do a

git checkout -b bullseye && git push

So other then can maybe start forking on that branch and sending
patches/pull requests for already coming in bullseye changes:

#841666, #931785, #932580

Gracias,
*t

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#932852: RFS: runescape/0.5-2 -- Multiplayer online game set in a fantasy world

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "runescape"

 * Package name: runescape
   Version : 0.5-2
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/runescape
 * License : BSD-2-Clause
   Section : non-free/games

  It builds those binary packages:

  runescape - Multiplayer online game set in a fantasy world

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/runescape

  Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/non-free/r/runescape/runescape_0.5-2.dsc

  More information about runescape can be obtained from 
https://oldschool.runescape.com.

  Changes since the last upload:

  runescape (0.5-2) unstable; urgency=medium

  * Using new DH level format. Consequently:
- debian/compat: removed.
+ debian/control: changed from 'debhelper' to 'debhelper-compat' in
  Build-Depends field and bumped level to 12.
  * debian/control:
+ Bumped Standards-Version to 4.4.0.
+ Added the XS-Autobuild: yes header.
  * debian/copyright:
+ Added a note about autobuilding.

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#932815: snapd: "snap remove" broken with AppArmor 2.13.2+

[intrigeri]

Hi,

thanks a lot, Jamie, for all these explanations!

Jamie Strandboge:
> You may find it acceptable to remove the Breaks in
> apparmor in Debian due to the above since the corner case is unlikely
> and a simple 'sudo snap refresh' is a viable workaround if bugs come in.

I'll do that for the moment and I'll let the snapd maintainers decide
how they want to handle this problem in Buster and testing/sid.

Cheers,
-- 
intrigeri

Bug#931296: general: Camera flash drive mount does not show up on desktop

[Tomas Pospisek]

Package: general
Followup-For: Bug #931296

Hi Roger,

Roger wrote:

> Plugging in camera in Buster does not show flash storage on desktop as
> it did in previous versions with Xfce DE.

There was no reply to this bug report. The problem is, that debugging
this involves some work, which you need to do. Such as going through
the logs on your machine and trying to see whether there's some
interesting info there related to the problem you are seeing.

Also googling around if you find some reports about this problem on the
net might be useful.

Without that info this bug report will have to be closed, since
there's not much we can do.
*t

Bug#932851: systemd causes diskless nodes to stop working / require hard reset

[Timothy Pearson]

Package: systemd
Version: 241-5

Ever since the switch to systemd we have been experiencing significant problems 
with our diskless nodes, where if the NFS connection is dropped for any reason 
(NFS server reboot, network router state reset, etc.) there is a high chance 
the diskless nodes will enter an unrecoverable state and require a hard reset 
(power off, power on).

While we've been working around this for a while and assumed it was just a 
Debian quirk, I was able to obtain the following trace from the console of a 
hung system today:

[820689.313769] nfs: server 192.168.1.1 not responding, still trying
[820693.530338] nfs: server 192.168.1.1 not responding, still trying
[820693.530451] nfs: server 192.168.1.1 not responding, still trying
[820696.994677] nfs: server 192.168.1.1 not responding, still trying
[820697.218891] nfs: server 192.168.1.1 not responding, still trying
[820697.698918] nfs: server 192.168.1.1 not responding, still trying
[820698.106834] nfs: server 192.168.1.1 not responding, still trying
[820721.177609] nfs: server 192.168.1.1 not responding, still trying
[820725.466102] nfs: server 192.168.1.1 not responding, still trying
[820818.681006] watchdog: BUG: soft lockup - CPU#2 stuck for 21s! 
[systemd-logind:273]
[820932.960202] INFO: task openvpn:5096 blocked for more than 120 seconds.
[820937.889046] nfs: server 192.168.1.1 OK
[820937.889226] nfs: server 192.168.1.1 OK
[820937.889374] nfs: server 192.168.1.1 OK
[820937.889381] nfs: server 192.168.1.1 OK
[820937.889448] nfs: server 192.168.1.1 OK
[820937.889503] nfs: server 192.168.1.1 OK
[820937.889574] nfs: server 192.168.1.1 OK
[820937.889665] nfs: server 192.168.1.1 OK
[820937.889670] nfs: server 192.168.1.1 OK
[820937.889674] nfs: server 192.168.1.1 OK
[820937.903880] systemd-journald[171]: Failed to open system journal: 
Permission denied
[820938.083071] systemd[1]: systemd-journald.service: Main process exited, 
code=killed, status=6/ABRT
[820938.57] systemd[1]: systemd-journald.service: Failed to kill control 
group /system.slice/systemd-journald.service, ignoring: Permission denied
[820938.124774] systemd[1]: systemd-journald.service: Failed to kill control 
group /system.slice/systemd-journald.service, ignoring: Permission denied
[820938.131244] systemd[1]: systemd-journald.service: Unit entered failed state.
[820938.131418] systemd[1]: systemd-journald.service: Failed with result 
'watchdog'.
[820938.144754] systemd[1]: systemd-udevd.service: Main process exited, 
code=killed, status=6/ABRT
[820938.170807] systemd[1]: systemd-udevd.service: Failed to kill control group 
/system.slice/systemd-udevd.service, ignoring: Permission denied
[820938.177666] systemd[1]: systemd-udevd.service: Unit entered failed state.
[820938.177798] systemd[1]: systemd-udevd.service: Failed with result 
'watchdog'.
[820938.189036] systemd[1]: systemd-udevd.service: Service has no hold-off 
time, scheduling restart.

This fairly clearly puts the blame somewhere in systemd, which makes sense as 
our older non-systemd machines recover perfectly fine from even extended NFS 
server failures.  At minimum the systemd watchdog should probably be disabled 
while the NFS server is unavailable.

Bug#932850: RM: bcrypt -- RoQA; obsolete, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove bcrypt, it's outdated and obsolete, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864253 for a more
in depth description.

Cheers,
Moritz

Bug#931111: linux-image-4.9.0-9: Memory "leak" caused by CGroup as used by pam_systemd

[Ben Hutchings]

On Tue, 2019-07-23 at 15:56 +0200, Philipp Hahn wrote:
[...]
> - when the job / session terminates, the directory is deleted by
> pam_systemd.
> 
> - but the Linux kernel still uses the CGroup to track kernel internal
> memory (SLAB objects, pending cache pages, ...?)
> 
> - inside the kernel the CGroup is marked as "dying", but it is only
> garbage collected very later on
[...]
> I do not know who is at fault here, if it is
> - the Linux kernel for not freeing those resources earlier
> - systemd for using CGs in a broken way
> - someone others fault.
[...]

I would say this is a kernel bug.  I think it's the same problem that
this patch series is trying to solve:
https://lwn.net/ml/linux-kernel/20190611231813.3148843-1-g...@fb.com/

Does the description there seem to match what you're seeing?

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?



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

Bug#925674: First triage

[Giovanni Mascellani]

Hi,

the problem here is that operator== is called on an instance of
std::map<>::iterator. The intention is probably to compare two iterators
for inequality. But calling the operator overloading function is not the
right thing, because the implementation of std::map<>::iterator might
use the default iterator, and not overload it. Probably GCC 8 used an
overloaded operator, but GCC 9 reverted to the default one. User code
should not call the function "operator==", but use the "==" operator and
let the compiler do its work.

I believe that the bug should be fixed by changing

  bool tolua_ret = (bool)  self->operator==(*value);

to

  bool tolua_ret = (bool)  ((*self)==(*value);

The problem is that that line of code is automatically generated by the
"tolua" tool. I suppose that tolua should be fixed to generate correct
code. I will look into that later, if I can.

Greetings from Curitiba!

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#932769: [moreinfo] DoS via DHCP request

[Ben Hutchings]

On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
> Package: general
> Followup-For: Bug #932769
> 
> Could you privide a recipe on how to reproduce this? There's a lot of
> very special setup below, that someone wwould need large amounts of time
> to reporoduce I feel.
> 
> Is it possible to reduce the problem to something easily demonstratable?
> 
> This seems to be an important issue to me.
> 
> I think the problem here *might* be a kernel problem? Re-assign this to
> kernel package?
[...]

So far as I know, the kernel only ever does DHCP if you net-boot
without an initramfs.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?




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

Bug#932849: ftp.debian.org: NEW process looses .buildinfo files

[Holger Levsen]

Package: ftp.debian.org
Severity: normal

hi,

 
https://tracker.debian.org/news/1027072/accepted-liblogger-simple-perl-20-1-source-all-into-unstable-unstable/
 says this upload was made with a .buildinfo file, yet this .buildinfo file 
isnt available
 this was on 2019-02-04
 any idea why this could have happened?
 process_new loses them
 really?
 the buildinfo copying happens here 
https://salsa.debian.org/ftp-team/dak/blob/master/dak/process_upload.py#L270
 which isn't on the NEW->policy->ACCEPT path
 thanks. i would have accepted a 'yes' but this is "better" :/
 i guess i will file a bug now
 tar tf /srv/ftp-master.debian.org/queue/done/2019/02.tar.xz  | grep 
liblogger-simple-perl
 02/04/liblogger-simple-perl_2.0-1_amd64.changes
 02/04/liblogger-simple-perl_2.0-1_amd64.buildinfo
 they're still retrievable, just not as friendly
 lol/thank you!
   * h01ger lols at bremner mubling next to him
 jrtc27: may i quote you in that bug to be filed?
 yeah please do
 meant to report one last time I ran into this...
 thank you, again! :)
   * h01ger hopes that would be an easy patch
 probably, for someone who knows the detailed code structure for NEW
 that's one part of dak that I haven't really fully understood
 isnt it just adding a 'cp $buildinfofile $path/$date/' somewhere?
 sure
 (in python, of course)
 a call to the existing function
 the question is where exactly though
 :)


thanks for maintaining ftp.d.o!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#932716: [Pkg-samba-maint] Bug#932716: samba: smbd gets killed by systemd on magic script invocation

[Mathieu Parent]

Control: tag -1 + moreinfo

Le lun. 22 juil. 2019 à 09:54, Alexander Zima  a écrit :
>
> Package: samba
> Version: 2:4.5.16+dfsg-1+deb9u2
> Severity: normal
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> Samba was configured to use a magic script and the magic script was executed.
>
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> Tried different settings in the systemd unit (Type forking, simple, notify) 
> and
> ultimately started smbd manually without systemd.
>
>
>* What was the outcome of this action?
>
> When smbd was run manually, the magic script was executed normally and
> everything worked as expected.
> When smbd was started via systemd, systemd killed the smbd process. The log
> reported the following:
> Jun 26 14:18:19 vast01 systemd[1]: smbd.service: State 'stop-sigterm' timed 
> out. Killing.
> Jun 26 14:18:19 vast01 systemd[1]: smbd.service: Killing process 30152 (smbd) 
> with signal SIGKILL.
> Jun 26 14:18:19 vast01 systemd[1]: smbd.service: Killing process 12712 (smbd) 
> with signal SIGKILL.
> Jun 26 14:18:19 vast01 systemd[1]: smbd.service: Killing process 13890 (smbd) 
> with signal SIGKILL.
> Jun 26 14:18:19 vast01 systemd[1]: smbd.service: Killing process 30153 
> (smbd-notifyd) with signal SIGKILL.
> Jun 26 14:18:19 vast01 systemd[1]: smbd.service: Killing process 30154 
> (cleanupd) with signal SIGKILL.
> Jun 26 14:18:19 vast01 systemd[1]: smbd.service: Killing process 30156 (lpqd) 
> with signal SIGKILL.
> Jun 26 14:18:19 vast01 systemd[1]: smbd.service: Main process exited, 
> code=killed, status=9/KILL
> Jun 26 14:18:19 vast01 systemd[1]: smbd.service: Unit entered failed state.
> Jun 26 14:18:19 vast01 systemd[1]: smbd.service: Failed with result 'timeout'

Please attach you /var/log/samba/log.smb file, and optionaly
/var/log/samba/cores/smbd.

Thanks
-- 
Mathieu Parent

Bug#932787: Bus error on sparc64

[GCS]

Control: tags -1 +moreinfo

Hi Phillip,

On Tue, Jul 23, 2019 at 11:09 PM Uwe Kleine-König  
wrote:
> On Tue, Jul 23, 2019 at 09:14:53AM +, Uwe Kleine-König wrote:
> > the test suite for rauc (currently in NEW) provokes a Bus error in
> > mksquashfs on sparc64 (tested on kyoto.debian.net in a sid chroot).
> > Reproduction is as follows:
> >
> >   install casync dbus dbus-x11 debhelper e2fsprogs faketime grub-common 
> > libcurl4-gnutls-dev, libglib2.0-dev, libjson-glib-dev libssl-dev libtool 
> > squashfs-tools systemd git
> >
> >   git clone https://github.com/rauc/rauc.git
> >   sed -i 's/0x73717368$/GUINT32_FROM_LE(0x73717368)/' src/bundle.c
> >   sh autogen.sh
> >   ./configure
> >   make check
> >   rm -rf /tmp/rauc-*
> >   ./test/bundle.test
> >
> > The last command fails with
> > "rauc:ERROR:test/common.c:339:test_create_bundle:
> > 'create_bundle(bundlename, contentdir, NULL)' should be TRUE" and leaves
> > behind a directory that allows to reproduce the issue:
> >
> >   $ rm -f image; mksquashfs /tmp/rauc-*/content image
> >   Parallel mksquashfs: Using 32 processors
> >   Creating 4.0 filesystem on image, block size 131072.
> >   Bus error
>
> The problem is in all_zero from squashfs-tools/mksquashfs.c:
>
> int all_zero(struct file_buffer *file_buffer)
> {
> int i;
> long entries = file_buffer->size / sizeof(long);
> long *p = (long *) file_buffer->data;
>
> for(i = 0; i < entries && p[i] == 0; i++);
>
> if(i == entries) {
> for(i = file_buffer->size & ~(sizeof(long) - 1);
> i < file_buffer->size && file_buffer->data[i] == 0;
> i++);
>
> return i == file_buffer->size;
> }
>
> return 0;
> }
>
> If file_buffer->data isn't a multiple of sizeof(long) the access to p[0]
> traps on sparc.
>
> Replacing that by:
>
> int all_zero(struct file_buffer *file_buffer)
> {
> int i;
>
> for(i = 0; i < file_buffer->size; i++)
> if (file_buffer->data[i] != 0)
> return 0;
>
> return 1;
> }
>
> should fix it. On architectures that fixup unaligned accesses in the
> kernel it is probably even faster.
 May you comment on this change from Uwe?

Thanks,
Laszlo/GCS

Bug#932685: [Pkg-samba-maint] Bug#932685: Samba package won't respect the -y switch of apt-get install command

[Mathieu Parent]

Control; retitle -1 samba-common: DHCP debconf question shouldn't be critical
Control: severity -1 wishlist

Le dim. 21 juil. 2019 à 22:09, Mikael Hartzell
 a écrit :
>
> Package: samba-common
> Version: 2:4.9.5+dfsg-5
>
> I maintain a software package (freelcs.sourceforge.net) that runs on Debian. 
> My software needs samba and installs this among other packages it needs with 
> apt-get. The user runs my GUI installer which uses apt-get in the background 
> to install needed Debian packages unattended. This has worked fine before in 
> Debian releases 7, 8 and 9, but now in Debian 10 the installer fails because 
> the samba-common package won't respect the -q=2 -y swithces on apt-get 
> commandline. The exact commandline I use is:
>
> apt-get -q=2 --reinstall -y  install samba

-q is not related to debconf questions.

> another commandline I tried is:
>
> sudo apt-get --reinstall -y --no-install-recommends install samba

Those options neither.

> The expected behavior is that samba package is installed without prompting 
> the user for anything. However both of these commands now always open up a 
> prompt asking:
>
> "If your computer gets IP address information from a DHCP server on the 
> network, the DHCP server may also provide information about WINS servers 
> ("NetBIOS name servers") present on the network.  This requires a change to 
> your smb.conf file so
> that DHCP-provided WINS settings will automatically be read from 
> /var/lib/samba/dhcp.conf.
> The dhcp-client package must be installed to take advantage of this feature.
> Modify smb.conf to use WINS settings from DHCP?"
>
> IMHO this seems like a bug in the samba package, since the behavior has 
> changed from earlier samba - versions and the apt-get switches -q=2 -y and 
> --no-install-recommends should provide default answers for the packages 
> questions and the installation should proceed without any prompts.

This was actually fixed by samba 2:4.8.1+dfsg-1 [1]. And was broken by
the upload of isc-dhcp (4.1.1-P1-7) in 2010.

[1]: 
https://salsa.debian.org/samba-team/samba/commit/04bfc02107845ed941cf7cfd5003a56736d78d54

What you want is something like:

DEBIAN_FRONTEND=noninteractive apt-get -y  install samba

So, the behavior is as expected.

However, I agree that asking for wins options today should not be that
"critical".

I'm keeping this bug to track either:
- the lowering of the option, or
- the complete removal of dhcp/wins support


Regards
-- 
Mathieu Parent

Bug#932328: logrotate.timer "breaks" activity report of /etc/cron.daily/exim4-base

[Erik C.J. Laan]

On 7/19/19 8:00 AM, Erik C.J. Laan wrote:

On 7/19/19 7:29 AM, Sven Hartge wrote:

On 18.07.19 20:01, Sven Hartge wrote:

On 17.07.19 20:46, Sven Hartge wrote:

Possible solution (untested): Also create a exim4-base.timer and 
.service and

create a Before= dependency on logrotate.service.

I've whipped up a little Proof-of-Concept to test this, available also
at https://salsa.debian.org/hartge-guest/exim4/tree/systemd-timer

I'm testing this right now on two of my systems to see how this 
behaves,

especially the Before=logrotate.{service,timer} ordering.

Yes, my test was successful, by ordering the exim4-base.service
Before=logrotate.service, the latter only starts after the first has
completed.

Grüße,
Sven.

This morning I installed the .timer and .service files manually on 3 
machines, and ran systemctl enable exim4-base.timer and systemctl 
start exim4-base.timer. One of these machines is my hoe mail server 
(+- 100 mails/day), the other 2 are clients that usually only mail me 
a daily report.


With kind regards, Erik Laan,

I discovered I also had to use the newest version of 
/etc/cron.daily/exim4-base, otherwise it would be run twice a day. After 
installing the updated /etc/cron.daily/exim4-base too it works like a 
charm. Thanks for the solution.


--
Met vriendelijke groeten/With kind regards, Erik Laan.

Bug#932795: Ethics of FTBFS bug reporting

[Adrian Bunk]

On Tue, Jul 23, 2019 at 08:45:42PM +0200, Ansgar wrote:
> Adrian Bunk writes:
> > - An environment with at least 16 GB RAM is supported.
> >
> > Not sure about the exact number, but since many packages have 
> > workarounds for gcc or ld running into the 4 GB address space
> > limit on i386 it is clear that several packages wouldn't build
> > in an amd64 vm with only 8 GB RAM.
> 
> Aren't there even packages that will not build on i386 with a i386
> kernel (non-PAE) as they require the full 4 GB address space to be
> buildable?

That's true (and PAE doesn't make a difference for that).

> Even more, from the "32 bit archs in Debian" BoF at DebConf15 I remember
> the suggestion that one might have to switch to 64-bit compilers even on
> 32-bit architectures in the future...  So building packages would in
> general require a 64-bit kernel, multi-arch and 4+ GB RAM.

Most packages could still be built natively (and building GNU hello
will never require 4GB RAM), but building all packages natively on
32bit architectures is already problematic and might not be feasible 
long-term.

> Ansgar

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#932769: [moreinfo] DoS via DHCP request

[Tomas Pospisek]

One more question. When you say VNWare integrated product. AFAIK vmware 
have their own networking module in the kernel? Can you reproduce this 
with some other virtualisation technology like kvm, qemu?


And one more question: do depending on who does the DHCP receival in the 
VM (systemd? isc-dhcp-client? [...]?): shouldn't there be some rate 
limiting sanity check in the DHCP client?

*t

On Tue, 23 Jul 2019, Tomas Pospisek wrote:


Package: general
Followup-For: Bug #932769

Could you privide a recipe on how to reproduce this? There's a lot of
very special setup below, that someone wwould need large amounts of time
to reporoduce I feel.

Is it possible to reduce the problem to something easily demonstratable?

This seems to be an important issue to me.

I think the problem here *might* be a kernel problem? Re-assign this to
kernel package?

When you say that it DoS'es the server then what does "top" say? What is
being DoS'ed? Is it the CPU?
*t

It would be truly cool, if you could provide more infos.
*t


To: Debian Bug Tracking System 
Subject: general: DHCP request bug when storage lost
Date: Mon, 22 Jul 2019 14:48:00 -0600

Package: general
Severity: important
Tags: l10n

Dear Maintainer,

While doing unrelated storage testing for our VMware integrated product, we 
purposefully recreated
a storage outage by removing the iSCSI initiators from the backing array 
hosting the vmdk disk
images for the virtual machine.

Upon removal of uplinks to storage, the VM goes into a R/O file system state 
after 5-10 minutes.
When storage initiators are brought back up and the LUNs are rescanned, the VM 
begins to
rapidly request DHCP leases from an ISC DHCP server.  This DoS's the server in 
a way due
to the number of DHCPDECLINE errors, and the interface attempts to take and 
discard IP's in a
rapid fashion.

This only seems to appear on this distribution, and I can't replicate the 
behavior on Debian 9
or in a desktop environment.



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

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






-- System Information:
Debian Release: 10.0
 APT prefers stable
 APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[Ian Jackson]

Sean Whitton writes ("Bug#932753: tag2upload should record git tag signer info 
in .dsc [and 1 more messages]"):
> AIUI a fingerprint fails to uniquely identify a PGP key unless you also
> include the cryptographic algorithm that was used and the key size.  So
> for example, my current key is uniquely identified by writing both 4096R
> and 8DC2487E51ABDD90B5C4753F0F56D0553B6D411B.
> 
> Even though it's unlikely we'll get a clash of fingerprints within the
> Debian keyring, it seems the algorithm and keysize ought to be included
> alongside the fingerprint, if the above is right.

In this message[1]

[GNUPG:] VALIDSIG 559AE46C2D6B6D3265E7CBA1E3E3392348B50D39 2019-07-20 
1563636558 0 4 0 1 8 01 559AE46C2D6B6D3265E7CBA1E3E3392348B50D39

   ^^^

I think I want to include `1' for pubkey-algo and `8' for hash-algo
then ?

Ian.

[1] Part of the output of
  gpgv --status-fd=2 --keyring=/usr/share/keyrings/debian-keyring.gpg < 
../bpd/dgit_9.4.dsc

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#815950: Find source?

[Tomas Pospisek]

Hi,

Nelson wrote on 29 Jun 2019:


What is the status of this issue, please?

As it is now, seeing only this message is not really user-friendly:

=
Forbidden

You are not allowed to access this!
=


Have you tried to find out, where this happens? I.e. the source code for 
this? Then you could maybe send a patch?

*t

Bug#932769: [moreinfo] DoS via DHCP request

[Tomas Pospisek]

Package: general
Followup-For: Bug #932769

Could you privide a recipe on how to reproduce this? There's a lot of
very special setup below, that someone wwould need large amounts of time
to reporoduce I feel.

Is it possible to reduce the problem to something easily demonstratable?

This seems to be an important issue to me.

I think the problem here *might* be a kernel problem? Re-assign this to
kernel package?

When you say that it DoS'es the server then what does "top" say? What is
being DoS'ed? Is it the CPU?
*t

It would be truly cool, if you could provide more infos.
*t

> To: Debian Bug Tracking System 
> Subject: general: DHCP request bug when storage lost
> Date: Mon, 22 Jul 2019 14:48:00 -0600
> 
> Package: general
> Severity: important
> Tags: l10n
> 
> Dear Maintainer,
> 
> While doing unrelated storage testing for our VMware integrated product, we 
> purposefully recreated
> a storage outage by removing the iSCSI initiators from the backing array 
> hosting the vmdk disk 
> images for the virtual machine.
> 
> Upon removal of uplinks to storage, the VM goes into a R/O file system state 
> after 5-10 minutes.
> When storage initiators are brought back up and the LUNs are rescanned, the 
> VM begins to 
> rapidly request DHCP leases from an ISC DHCP server.  This DoS's the server 
> in a way due
> to the number of DHCPDECLINE errors, and the interface attempts to take and 
> discard IP's in a
> rapid fashion. 
> 
> This only seems to appear on this distribution, and I can't replicate the 
> behavior on Debian 9
> or in a desktop environment.
> 
> 
> 
> -- System Information:
> Debian Release: 10.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled





-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#932787: Bus error on sparc64

[Uwe Kleine-König]

Control: tag -1 + patch

Hello,

On Tue, Jul 23, 2019 at 09:14:53AM +, Uwe Kleine-König wrote:
> Package: squashfs-tools
> Version: 1:4.3-12
> Severity: normal
> 
> Hello,
> 
> the test suite for rauc (currently in NEW) provokes a Bus error in
> mksquashfs on sparc64 (tested on kyoto.debian.net in a sid chroot).
> Reproduction is as follows:
> 
>   install casync dbus dbus-x11 debhelper e2fsprogs faketime grub-common 
> libcurl4-gnutls-dev, libglib2.0-dev, libjson-glib-dev libssl-dev libtool 
> squashfs-tools systemd git
> 
>   git clone https://github.com/rauc/rauc.git
>   sed -i 's/0x73717368$/GUINT32_FROM_LE(0x73717368)/' src/bundle.c
>   sh autogen.sh
>   ./configure
>   make check
>   rm -rf /tmp/rauc-*
>   ./test/bundle.test
> 
> The last command fails with
> "rauc:ERROR:test/common.c:339:test_create_bundle:
> 'create_bundle(bundlename, contentdir, NULL)' should be TRUE" and leaves
> behind a directory that allows to reproduce the issue:
> 
>   $ rm -f image; mksquashfs /tmp/rauc-*/content image
>   Parallel mksquashfs: Using 32 processors
>   Creating 4.0 filesystem on image, block size 131072.
>   Bus error

The problem is in all_zero from squashfs-tools/mksquashfs.c:

int all_zero(struct file_buffer *file_buffer)
{
int i;
long entries = file_buffer->size / sizeof(long);
long *p = (long *) file_buffer->data;

for(i = 0; i < entries && p[i] == 0; i++);

if(i == entries) {
for(i = file_buffer->size & ~(sizeof(long) - 1);
i < file_buffer->size && file_buffer->data[i] == 0;
i++);

return i == file_buffer->size;
}

return 0;
}

If file_buffer->data isn't a multiple of sizeof(long) the access to p[0]
traps on sparc.

Replacing that by:

int all_zero(struct file_buffer *file_buffer)
{
int i;

for(i = 0; i < file_buffer->size; i++)
if (file_buffer->data[i] != 0)
return 0;

return 1;
}

should fix it. On architectures that fixup unaligned accesses in the
kernel it is probably even faster.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#932848: [nmudiff] --non-dd and --no-pending missing from man page

[Mattia Rizzolo]

On Tue, Jul 23, 2019 at 11:52:51PM +0300, Teemu Toivola wrote:
> There also appears to be some sort of interaction worth getting documented
> between --non-dd and --delay as the resulting mail doesn't contain any sign
> of delay setting when --non-dd is used.

Clearly so: neither of those imply any actual upload, so it doesn't make
sense to speak about delayed upload.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#932408: linux-image-4.19.0-5-amd64: kernel panic not syncing

[Terry Glanfield]

Thank you for the suggestion.

I've installed 4.19.60 but that gives the same kernel panic.

Where do I start in getting some more information to track what's causing this?

On Tue, 23 Jul 2019 14:40:59 +0200 Kinky Nekoboi
 wrote:
> i had and have several problems with 4.19.37-5  ... an selfbuild vanila
> kernel 4.19.60 with default options fixed most of them for me ...
>
> Debian should really push a newer 4.19.y kernel for buster
>
> Am 23.07.19 um 14:01 schrieb Terry Glanfield:
> > This is still failing after an update to 4.19.37-5+deb10u1
> >
> > Any clues on where to start tracking this down?
> >
>

Bug#932848: [nmudiff] --non-dd and --no-pending missing from man page

[Teemu Toivola]

Package: devscripts
Version: 2.19.5
Severity: minor

'nmudiff --help' has the following options visible that cannot be found
with more detailed documentation from the man page:

--no-pending, --nopending
  Don't add the 'pending' tag
--non-dd, --nondd
  Mention in the email that you require sponsorship.


$ zgrep -c pending /usr/share/man/man1/nmudiff.1.gz 
0
$ zgrep -c nondd /usr/share/man/man1/nmudiff.1.gz 
0

There also appears to be some sort of interaction worth getting documented
between --non-dd and --delay as the resulting mail doesn't contain any sign
of delay setting when --non-dd is used.


-Teemu

Bug#932847: libbinutils: Can no longer link to Qt provided amd64 libraries - "error adding symbols: bad value"

[Pierre Ducroquet]

Package: libbinutils
Version: 2.32.51.20190707-1
Severity: important

Dear Maintainer,

After upgrading from 2.31.1-16 to 2.32.51.20190707-1, linking to Qt-provided 
QtWebEngine fails with the following error:
> g++- -Wl,-rpath,/home/snoopy/Qt/5.12.3/gcc_64/lib 
> -Wl,-rpath-link,/home/snoopy/Qt/5.12.3/gcc_64/lib  -o my-app *.o -L/usr/lib/ 
> -l:libstlink.so.1 -lusb-1.0 -L/home/snoopy/Qt/5.12.3/gcc_64/lib 
> -lQt5QuickControls2 -lQt5WebEngine -lQt5WebEngineCore -lQt5Quick -lQt5Gui 
> -lQt5WebChannel -lQt5Qml -lQt5Network -lQt5Positioning -lQt5Test -lQt5Sql 
> -lQt5SerialPort -lQt5Core -lGL -lpthread   
/usr/bin/ld: /home/snoopy/Qt/5.12.3/gcc_64/lib/libQt5WebEngineCore.so: error 
adding symbols: bad value

Downgrading libbinutils and binutils-x86-64-linux-gnu fixed this issue and link 
succeeded again.
Another workaround is to use the gold linker.
Both these solutions are fine workarounds, but I think the real issue needs to 
be adressed.

Regards

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

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

Versions of packages libbinutils depends on:
ii  binutils-common  2.32.51.20190707-1
ii  libc62.28-10
ii  zlib1g   1:1.2.11.dfsg-1

libbinutils recommends no packages.

libbinutils suggests no packages.

-- no debconf information

Bug#932846: --verbose kaput: ValueError: not enough values to unpack (expected 3, got 1)

[積丹尼 Dan Jacobson]

Package: unicode
Version: 2.7-1

$ unicode -v v
U+0076 LATIN SMALL LETTER V
UTF-8: 76 UTF-16BE: 0076 Decimal:  Octal: \0166
v (V)
Uppercase: 0056
Category: Ll (Letter, Lowercase); East Asian width: Na (narrow)
Unicode block: ..007F; Basic Latin
Bidi: L (Left-to-Right)


Traceback (most recent call last):
  File "/usr/bin/unicode", line 953, in 
main()
  File "/usr/bin/unicode", line 950, in main
print_characters(processed_args, options.maxcount, format_string, 
options.query_wikipedia, options.query_wiktionary)
  File "/usr/bin/unicode", line 745, in print_characters
uhp = get_unihan_properties(c)
  File "/usr/bin/unicode", line 362, in get_unihan_properties_zgrep
char, key, value = l.strip().split('\t')
ValueError: not enough values to unpack (expected 3, got 1)

Bug#932795: Ethics of FTBFS bug reporting

[Ansgar]

Russ Allbery writes:
> Ansgar  writes:
>> Even more, from the "32 bit archs in Debian" BoF at DebConf15 I remember
>> the suggestion that one might have to switch to 64-bit compilers even on
>> 32-bit architectures in the future...  So building packages would in
>> general require a 64-bit kernel, multi-arch and 4+ GB RAM.
[...]
> I'm rather dubious that it makes sense to *require* multiple cores to
> build a package for exactly the reason that Santiago gave: single-core VMs
> are very common and a not-very-exotic environment in which someone may
> reasonably want to make changes to a package and rebuild it.  But maybe
> I'm missing something that would make that restriction make sense.

Well, the package that gave raise to this issue is this:

   The p4est software library enables the dynamic management of a
   collection of adaptive octrees, conveniently called a forest of
   octrees. p4est is designed to work in parallel and scale to hundreds
   of thousands of processor cores.

I doubt many people from that application domain work with single-core
systems.

There are other interesting issues as well: I recently had problems with
running a numerics library in a VM where the CPU supports AVX-2, but the
VM instance did not.  But the library used the CPU model to select its
preferred implementation (which then used AVX-2 instructions)...

Just like issues with single-CPU systems this is a bug, but not one with
a high priority for me.

Ansgar

Bug#931824: asymptote: FTBFS on ppc64

[Hilmar Preuße]

forwarded 931824 https://github.com/vectorgraphics/asymptote/issues/103
stop

On 10.07.19 23:06, Hilmar Preusse wrote:

> Since a few releases the package fails to build on arch ppc64. This is
> not an release arch, hence severity only important. At the end of the
> build, the generated asy binary is called and causes a segfault for at
> least one input file.
> 
> https://buildd.debian.org/status/fetch.php?pkg=asymptote=ppc64=2.49-2=1562769886=0
> 
Forwarded to upstream, wait for reply.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#932241: vlc: CVE-2019-13615

[Salvatore Bonaccorso]

hi Sebastian,

On Tue, Jul 23, 2019 at 09:24:29PM +0200, Sebastian Ramacher wrote:
> Hi Salvatore
> 
> On 2019-07-16 22:36:50, Salvatore Bonaccorso wrote:
> > Source: vlc
> > Version: 3.0.7.1-2
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://trac.videolan.org/vlc/ticket/22474
> > Control: found -1 3.0.7.1-1
> > Control: found -1 3.0.7-1
> > Control: found -1 3.0.7-0+deb9u1
> > 
> > Hi,
> > 
> > The following vulnerability was published for vlc, sorry another one.
> > For buster, stretch I think we can follow the usual strategy and
> > release a new upstream stable version once available.
> > 
> > CVE-2019-13615[0]:
> > | VideoLAN VLC media player 3.0.7.1 has a heap-based buffer over-read in
> > | mkv::demux_sys_t::FreeUnused() in modules/demux/mkv/demux.cpp when
> > | called from mkv::Open in modules/demux/mkv/mkv.cpp.
> > 
> > 
> > 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-13615
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13615
> > [1] https://trac.videolan.org/vlc/ticket/22474
> 
> FWIW, this issue is disputed upstream.
> 
> Cheers
> 
> > 
> > Please adjust the affected versions in the BTS as needed.

Ack, let's see what will be the outcome. Thanks in any case for the
heads-up on the disputed state upstream!

Regards,
Salvatore

Bug#907020: vnstat: autopkgtest regression

[Teemu Toivola]

On Tue, 23 Jul 2019 19:51:23 +0200
Paul Gevers  wrote:

> > Yes, I've read the dev ref. I also had a chat in #debian-mentors yesterday
> > regarding if doing a NMU would be the correct way of proceeding in this
> > case as I haven't done one before nor have I been active with Debian
> > related packaging any time recently. I got pointed towards PackageSalvaging
> > [1], the MIA team and pinging the maintainer once more. That's why in
> > concluded it wouldn't hurt to ask here before taking any futher actions.
> 
> Concluding from this bug alone that the maintainer is MIA is IMHO a bit
> hasty. This bug received a response last year on the same day that I
> filed the bug. As the bug was, at that time, only severity normal, I'm
> not surprised that it hasn't been fixed, even though it was pending all
> the time. I only raised the severity one week ago. I am *assuming* you
> inspected the lack of response from him on the bugs in the logrotate
> package. I suggest you mention something like that explicitly next time
> (and please confirm if I was rightly assuming).

I haven't contacted MIA and I don't have any intent on trying to hijack
this (or any other) package. That's why I try to ask first before taking
any action so that there's no misunderstandings. I had some suspicions that
the maintainer may have become inactive when the discussion in bug #881811
[3] didn't result in any kind of reaction. After several months had past
and this bug was still open, I tried to contact him a little over a week
ago (before the severity change) offering help but haven't so far received
a reply or a bounce. Due to the severity change, I spent some time learning
how the packaging had been handled to see if there was some reason why the
changes already in Salsa hadn't been uploaded, but couldn't find anything
obvious. I couldn't either find any activity after September 2018 from those
locations that do appear to provide such information ([4] [5] [6]). So yes,
I'm aware that's he is also the maintainer of the logrotate package.

> > As for the NMU, the only thing that isn't fully clear after reading the
> > documentation is the handling of the DELAYED queue when using
> > mentors.debian.net and the behaviour of nmudiff in that situation. Invoking
> > nmudiff with --non-dd (which is mention in the --help output but not on the
> > man page) results in a mail template that doesn't mention the delay
> > anywhere. On the other hand, the template suggested by mentors.debian.net
> > [2] looks more complete/verbose but isn't as clear that the diff file
> > created by nmudiff/debdiff should also be attached for NMUs. Either way, is
> > the lack of 'delay' something I'd need to worry about in this phase?
> 
> It's the sponsor that has to upload to the DELAYED queue, so it's not
> something that you control as the sponsee, I suggest you explicitly
> mention it to your sponsor if you want the NMU to go through DELAYED
> (although your sponsor should be aware of that anyways). That said, an
> RC bug without response from the maintainer for a week is "entitled"
> (quotes very much on purpose, as personally I put more time on all my
> NMU uploads than the dev-ref suggests) to go straight into unstable.

Thanks, that clarifies it. The RFS is in bug #932843 [7].

> > [1] https://wiki.debian.org/PackageSalvaging
> > [2] https://mentors.debian.net/sponsors/rfs-howto/vnstat
> 
> Paul
> 
> PS: if --help has more info than the man page, I suggest you file a bug
> about that if it doesn't exist already.

Ok, I'll check that one too.


[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881811
[4] https://salsa.debian.org/cgzones-guest
[5] https://qa.debian.org/developer.php?email=cgzones%40googlemail.com
[6] https://contributors.debian.org/contributor/cgzones-guest@alioth/
[7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932843

-Teemu

Bug#932212: closed by Amos Jeffries (squid: negotiate wrapper crashes under load)

[James Zuelow]

Thanks Amos.

The 4.8-1 .debs for unstable do install on Buster (Buster is so new I don't 
think there are significant differences yet) but it just fails faster, with a 
new error message.  It looks like unstable Squid doesn't like Buster Winbind.  
I don't quite understand that permission denied error.

And since 4.8 will likely not ever be migrated to Buster, I think I'm looking 
for alternatives anyway.  (I'm loathe to keep my production proxies on 
unstable!)


2019/07/22 08:22:06 kid1| Starting new helpers
2019/07/22 08:22:06 kid1| helperOpenServers: Starting 1/150 
'negotiate_wrapper_auth' processes
2019/07/22 08:22:06| negotiate_wrapper: Starting version 1.0.1
2019/07/22 08:22:06| negotiate_wrapper: NTLM command: /usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-ntlmssp --domain=CBJ.LOCAL
2019/07/22 08:22:06| negotiate_wrapper: Kerberos command: 
/usr/lib/squid/negotiate_kerberos_auth -s HTTP/proxy.cbj.local@CBJ.LOCAL
2019/07/22 08:22:06| negotiate_wrapper: Failed execv for /usr/bin/ntlm_auth: 
Permission denied
2019/07/22 08:22:06| negotiate_wrapper: Could not assign streams for 
FDKIN/FDKOUT/FDNIN/FDNOUT
*** stack smashing detected ***:  terminated
2019/07/22 08:22:06| negotiate_kerberos_auth: ERROR: krb5_kt_start_seq_get: 
Resource temporarily unavailable
2019/07/22 08:22:06| negotiate_kerberos_auth: ERROR: krb5_read_keytab: Resource 
temporarily unavailable
2019/07/22 08:22:06 kid1| WARNING: negotiateauthenticator #Hlpr170 exited
2019/07/22 08:22:06 kid1| Too few negotiateauthenticator processes are running 
(need 1/150)
2019/07/22 08:22:06 kid1| Starting new helpers
2019/07/22 08:22:06 kid1| helperOpenServers: Starting 1/150 
'negotiate_wrapper_auth' processes
2019/07/22 08:22:06 kid1| ipcCreate: /usr/bin/ntlm_auth: (13) Permission denied
2019/07/22 08:22:06| negotiate_wrapper: Starting version 1.0.1
2019/07/22 08:22:06| negotiate_wrapper: NTLM command: /usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-ntlmssp --domain=CBJ.LOCAL
2019/07/22 08:22:06| negotiate_wrapper: Kerberos command: 
/usr/lib/squid/negotiate_kerberos_auth -s HTTP/proxy.cbj.local@CBJ.LOCAL
2019/07/22 08:22:06| negotiate_wrapper: Failed execv for /usr/bin/ntlm_auth: 
Permission denied
2019/07/22 08:22:06| negotiate_wrapper: Could not assign streams for 
FDKIN/FDKOUT/FDNIN/FDNOUT
*** stack smashing detected ***:  terminated
2019/07/22 08:22:06 kid1| WARNING: negotiateauthenticator #Hlpr171 exited
2019/07/22 08:22:06 kid1| Too few negotiateauthenticator processes are running 
(need 1/150)
2019/07/22 08:22:06 kid1| Starting new helpers

But the ntlm_auth seems to not have actual file system permission errors.  I 
can run it as an unprivileged user:

jfzuelow@mis-squid2-lnx:~$ ntlm_auth --username=james_zuelow --domain=cbj.local
Password:
NT_STATUS_OK: The operation completed successfully. (0x0)

James

Bug#932845: TS-219 RTC issue with Debian Buster

[Oliver Hartkopp]

Package: linux-image-4.19.0-5-marvell
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 97721
Maintainer: Debian Kernel Team 
Architecture: armel
Source: linux
Version: 4.19.37-5
Depends: kmod, linux-base (>= 4.3~), initramfs-tools (>= 0.120+deb8u2) | 
linux-initramfs-tool

Recommends: firmware-linux-free, u-boot-tools, apparmor
Suggests: linux-doc-4.19, debian-kernel-handbook
Breaks: flash-kernel (<< 3.57~), initramfs-tools (<< 0.120+deb8u2)
Description: Linux 4.19 for Marvell Kirkwood/Orion
 The Linux kernel 4.19 and modules for use on Marvell Kirkwood and Orion
 based systems (https://wiki.debian.org/ArmEabiPort#Supported_hardware).
Homepage: https://www.kernel.org/



Hi Debian Kernel Team,

I'm running a TS-119P+ and a TS-219P II Qnap NAS with Debian Buster.
Both are now running a linux-image-4.19.0-5-marvell kernel.

But since my update from Linux 4.9 (Stretch) to Linux 4.19 (Buster) the 
hardware clock of both boxes refuse to work.


After some digging in kernel sources and re-installing Linux 4.9 on my 
Buster setup it turns out, that a change in the kernel config causes the 
problem:


4.19.0-5-marvell -> CONFIG_RTC_DRV_S35390A=m   (fails)

4.9.0-4-marvell -> CONFIG_RTC_DRV_S35390A=y(works)

See details and solving process at:

https://marc.info/?l=linux-arm-kernel=156390875629259=2

Can you please revert the Kernel config parts for the RTC in a way that 
the RTC drivers are built into the marvell-arch kernel again instead of 
building them as modules?


As described in the referenced description the hwclock tool does not 
work on the machines.


Thanks & best regards,
Oliver

Bug#932795: Ethics of FTBFS bug reporting

[Russ Allbery]

Ansgar  writes:
> Adrian Bunk writes:

>> - An environment with at least 16 GB RAM is supported.
>>
>> Not sure about the exact number, but since many packages have 
>> workarounds for gcc or ld running into the 4 GB address space
>> limit on i386 it is clear that several packages wouldn't build
>> in an amd64 vm with only 8 GB RAM.

> Aren't there even packages that will not build on i386 with a i386
> kernel (non-PAE) as they require the full 4 GB address space to be
> buildable?

> Even more, from the "32 bit archs in Debian" BoF at DebConf15 I remember
> the suggestion that one might have to switch to 64-bit compilers even on
> 32-bit architectures in the future...  So building packages would in
> general require a 64-bit kernel, multi-arch and 4+ GB RAM.

Weighing in here as a Policy Editor, I think we do have a rough consensus
in the project about what sorts of resources a package may or may not
require in order to build, in that we've made firm decisions both
directions (dropping architectures that can no longer build large packages
in a reasonable length of time, for example, but also rejecting packages
that cannot be built reasonably on our buildds).  But they're
largely-undocumented "tribal knowledge."

I would be in favor of writing down those guidelines, as have been
discussed on this thread, and publishing them as part of Policy, since I
think it would provide useful guide rails for developers to know how many
resources they can reasonably require for the package build, and what sort
of build environments they need to support (and therefore should at least
consider simulating to ensure that they do support them).

We could then align our archive-wide rebuild testing with the documented
minimum requirements for package builds, and all be consistently testing
the same thing, which would prevent some surprises.

I do think, as this thread has made clear, that we do have some minimum
requirements and don't expect packages to build in smaller environments.
Minimum available memory is a really obvious one; I'm sure many of our
packages won't build in 128MB of RAM, for example.

I'm rather dubious that it makes sense to *require* multiple cores to
build a package for exactly the reason that Santiago gave: single-core VMs
are very common and a not-very-exotic environment in which someone may
reasonably want to make changes to a package and rebuild it.  But maybe
I'm missing something that would make that restriction make sense.

It's possible that we may have to have a couple of levels of requirements:
base minimum requirements below which we don't expect any maintainer to
worry about, and a higher tier of requirements for larger packages.  For
instance, I'm not sure that we want to say that we don't support building
*any* Debian package on a host that can't build Firefox (particularly
given our support for embedded devices); coreutils probably should build
on a lighter-weight machine than Firefox requires.  And it's possible that
multi-core may be a reasonable requirement for that "heavy package" tier.
If we do go down that path, though, it would be nice to add a metadata
field so that maintainers can flag their packages as being "heavy" so that
our users know to expect them to not build on commodity VMs.

-- 
Russ Allbery (r...@debian.org)   

Bug#932844: hcxdumptool FTCBFS: incorrect makefile dependencies

[Helmut Grohne]

Source: hcxdumptool
Version: 5.1.7-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

hcxdumptool fails to cross build from source. It first cross builds
correctly and then make install rebuilds the tools with the wrong
compiler again. This is due to bad makefile dependencies. Please
consider applying the attached patch to fix the dependencies.

I also note that debian/rules violates Debian Policy section 6.4, but
I'm too lazy to file an RC bug now.

Helmut
--- hcxdumptool-5.1.7.orig/Makefile
+++ hcxdumptool-5.1.7/Makefile
@@ -15,13 +15,16 @@
 
 all: build
 
-build:
 ifeq ($(HOSTOS), Linux)
-	$(CC) $(CFLAGS) $(CPPFLAGS) -o hcxpioff hcxpioff.c $(LDFLAGS)
-	$(CC) $(CFLAGS) $(CPPFLAGS) -o hcxdumptool hcxdumptool.c $(LDFLAGS)
+build:hcxpioff hcxdumptool
 else
+build:
 	$(info OS not supported)
 endif
+hcxpioff:hcxpioff.c
+	$(CC) $(CFLAGS) $(CPPFLAGS) -o $@ $< $(LDFLAGS)
+hcxdumptool:hcxdumptool.c
+	$(CC) $(CFLAGS) $(CPPFLAGS) -o $@ $< $(LDFLAGS)
 
 install: build
 ifeq ($(HOSTOS), Linux)

Bug#932843: RFS: vnstat/1.18-2.1 [NMU]

[Teemu Toivola]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "vnstat"

* Package name: vnstat
  Version : 1.18-2.1
  Upstream Author : Teemu Toivola 
* URL : https://humdi.net/vnstat/
* License : GPL-2
  Section : net

It builds those binary packages:

  vnstat - console-based network traffic monitor
  vnstati - image output support for vnStat

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/vnstat


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_1.18-2.1.dsc


Changes since the last upload:

 vnstat (1.18-2.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Changes by Christian Göttsche
- d/tests: run as root to fix debci (Closes: #907020)
- d/control: bump to std version 4.2.1 (no further changes)

 -- Teemu Toivola   Tue, 23 Jul 2019 00:47:18 +0300


Regards,
 Teemu Toivola
diff -Nru vnstat-1.18/debian/changelog vnstat-1.18/debian/changelog
--- vnstat-1.18/debian/changelog	2018-08-21 19:25:17.0 +0300
+++ vnstat-1.18/debian/changelog	2019-07-23 00:47:18.0 +0300
@@ -1,3 +1,12 @@
+vnstat (1.18-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Changes by Christian Göttsche
+- d/tests: run as root to fix debci (Closes: #907020)
+- d/control: bump to std version 4.2.1 (no further changes)
+
+ -- Teemu Toivola   Tue, 23 Jul 2019 00:47:18 +0300
+
 vnstat (1.18-2) unstable; urgency=medium
 
   * d/tests: fix daily test by using lo interface
diff -Nru vnstat-1.18/debian/control vnstat-1.18/debian/control
--- vnstat-1.18/debian/control	2018-08-21 19:25:17.0 +0300
+++ vnstat-1.18/debian/control	2019-07-22 18:12:42.0 +0300
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Christian Göttsche 
 Build-Depends: debhelper (>= 11), libgd-dev, check
-Standards-Version: 4.2.0
+Standards-Version: 4.2.1
 Rules-Requires-Root: no
 Homepage: https://humdi.net/vnstat/
 Vcs-Git: https://salsa.debian.org/cgzones-guest/vnstat.git
diff -Nru vnstat-1.18/debian/tests/control vnstat-1.18/debian/tests/control
--- vnstat-1.18/debian/tests/control	2018-08-21 19:25:17.0 +0300
+++ vnstat-1.18/debian/tests/control	2019-07-22 18:12:42.0 +0300
@@ -1,2 +1,3 @@
 Tests: version, loopback
 Depends: @
+Restrictions: needs-root

Bug#932842: libwebkit2gtk-4.0-37: Surf hangs after switching from a HLS stream

[Richard Lucassen]

Package: libwebkit2gtk-4.0-37
Version: 2.24.0-1
Severity: important

Dear Maintainer,

As requested by Alberto Garcia and as a follow up of bug 929749, I file a new 
bugreport.

1) Go to http://radio.dos.nl/ using "surf" (which uses libwebkit)

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

3) Click "Choose protocol" until it shows HLS

4) Click on arrow (back to radio)

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

6) switch between the BBC stations (they're all HLS)

(check the Info button on the left top corner, at the bottom of the
info page there is the protocol that is used, it should show "HLS")

The first station plays, but after switching to another station it is over. All 
versions after 2.24.0 suffer from this issue, up to the 2.25.2-1 from 
experimental.

R.


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

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

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

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

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

-- no debconf information

Bug#932759: [Pkg-xen-devel] Bug#932759: After upgrade from stretch to buster, removal of obsolete xen 4.8 packages seems to trigger shutdown of xenconsoled

[niek]

Some more lines from /var/log/syslog of that same time.
Looks like some process is running various scripts in
/usr/lib/linux-boot-probes/ and /usr/lib/os-probes.

Jul 21 07:38:41 host systemd[1]: xen.service: Succeeded.
Jul 21 07:38:41 host systemd[1]: Stopped LSB: Xen daemons.
Jul 21 07:38:53 host kernel: SGI XFS with ACLs, security attributes,
realtime, no debug enabled
Jul 21 07:38:53 host kernel: JFS: nTxBlock = 7137, nTxLock = 57100
Jul 21 07:38:53 host kernel: QNX4 filesystem 0.2.3 registered.
Jul 21 07:38:54 host kernel: raid6: sse2x1   gen()  4028 MB/s
Jul 21 07:38:54 host kernel: raid6: sse2x1   xor()  3036 MB/s
Jul 21 07:38:54 host kernel: raid6: sse2x2   gen()  4666 MB/s
Jul 21 07:38:54 host kernel: raid6: sse2x2   xor()  3596 MB/s
Jul 21 07:38:54 host kernel: raid6: sse2x4   gen()  5263 MB/s
Jul 21 07:38:54 host kernel: raid6: sse2x4   xor()  3941 MB/s
Jul 21 07:38:54 host kernel: raid6: using algorithm sse2x4 gen() 5263 MB/s
Jul 21 07:38:54 host kernel: raid6:  xor() 3941 MB/s, rmw enabled
Jul 21 07:38:54 host kernel: raid6: using ssse3x2 recovery algorithm
Jul 21 07:38:54 host kernel: xor: measuring software checksum speed
Jul 21 07:38:54 host kernel:prefetch64-sse:  6630.000 MB/sec
Jul 21 07:38:54 host kernel:generic_sse:  5853.000 MB/sec
Jul 21 07:38:54 host kernel: xor: using function: prefetch64-sse
(6630.000 MB/sec)
Jul 21 07:38:54 host kernel: Btrfs loaded, crc32c=crc32c-intel
Jul 21 07:38:54 host kernel: fuse init (API version 7.27)
Jul 21 07:38:54 host systemd[1]: Mounting FUSE Control File System...
Jul 21 07:38:54 host systemd[1]: Mounted FUSE Control File System.
Jul 21 07:38:55 host os-prober[11566]: debug: running
/usr/lib/os-probes/mounted/05efi on mounted /dev/sda1
(...)
Jul 21 07:39:38 host 50mounted-tests[16816]: debug:
/usr/lib/linux-boot-probes/mounted/40grub2 succeeded
Jul 21 07:39:38 host systemd[1828]: var-lib-os\x2dprober-mount.mount:
Succeeded.
Jul 21 07:39:38 host systemd[1]: var-lib-os\x2dprober-mount.mount:
Succeeded.
Jul 21 07:39:38 host linux-boot-prober[16820]: debug: linux detected by
/usr/lib/linux-boot-probes/50mounted-tests


niek

Bug#932841: libdpkg-perl: Dpkg::Source::Package installs a permanent SIGINT handler

[Ian Jackson]

Package: libdpkg-perl
Version: 1.18.25
Severity: normal

$ perl -we 'use Data::Dumper; print Dumper($SIG{INT})'
$VAR1 = undef;
$ perl -we 'use Data::Dumper; use Dpkg::Source::Package; print 
Dumper($SIG{INT})'
$VAR1 = sub { "DUMMY" };
$

This is a problem because when a SIGINT handler is installed, perl
will not immediately exit when it is in some other C library.

For example,

$ perl -we 'use Data::Dumper; use WWW::Curl::Easy; my $curl = 
WWW::Curl::Easy->new; $curl->setopt(CURLOPT_URL, "http://192.0.2.1;); 
$curl->perform()'
^C [returns prompt immediately]
$ perl -we 'use Data::Dumper; use WWW::Curl::Easy; use Dpkg::Source::Package; 
my $curl = WWW::Curl::Easy->new; $curl->setopt(CURLOPT_URL, 
"http://192.0.2.1;); $curl->perform()'
^C [hangs]

If libdpkg-perl needs a signal handler it should install it only
during its own operations, probably localising it and arranging to
chain to the original handler (if any) when it has done its own work.

But I doubt the necessity.

Thanks,
Ian.

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-debug
  APT policy: (500, 'oldstable-debug'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-0.bpo.5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libdpkg-perl depends on:
ii  dpkg  1.18.25
ii  perl  5.24.1-3+deb9u5

Versions of packages libdpkg-perl recommends:
ii  bzip2   1.0.6-8.1
ii  libfile-fcntllock-perl  0.22-3+b2
ii  liblocale-gettext-perl  1.07-3+b1
ii  xz-utils5.2.2-1.2+b1

Versions of packages libdpkg-perl suggests:
ii  bcc [c-compiler]0.16.17-3.2
ii  binutils2.28-5
ii  debian-keyring  2017.05.28
ii  gcc [c-compiler]4:6.3.0-4
ii  gcc-5 [c-compiler]  5.4.1-4
ii  gcc-6 [c-compiler]  6.3.0-18+deb9u1
ii  gnupg   2.1.18-8~deb9u4
ii  gnupg2  2.1.18-8~deb9u4
ii  gpgv2.1.18-8~deb9u4
ii  patch   2.7.5-1+deb9u1

-- no debconf information

Bug#932840: devscripts: mergechanges: buggy filename with bin nmus

[Mattia Rizzolo]

Package: devscripts
Version: 2.19.5
Severity: minor
User: devscri...@packages.debian.org
Usertags: mergechanges

% mergechanges -f ifeffit_1.2.11d-10.2+b4_amd64.changes 
ifeffit_1.2.11d-10.2+b4_i386.changes
% l
...
-rw-r--r-- 1 mattia mattia5153 Jul 23 21:29 'ifeffit 
(2:1.2.11d-10.2)_1.2.11d-10.2+b4_multi.changes'
...

That's kinda buggy :)

mergechanges is taking the Source field as it is, but that's buggy for
the usage mergechanges has.

To reproduce the bug more easily, I'm attaching the 2 .changes.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
Format: 1.8
Date: Tue, 23 Jul 2019 21:27:47 +0200
Source: ifeffit (2:1.2.11d-10.2)
Binary: ifeffit ifeffit-dbgsym libifeffit-perl libifeffit-perl-dbgsym 
python-ifeffit python-ifeffit-dbgsym
Binary-Only: yes
Architecture: i386
Version: 2:1.2.11d-10.2+b4
Distribution: unstable
Urgency: low
Maintainer: Mattia Rizzolo 
Changed-By: Mattia Rizzolo 
Description:
 ifeffit- Interactive XAFS analysis program
 libifeffit-perl - Perl extensions for IFEFFIT
 python-ifeffit - Python GUI interface and extensions for IFEFFIT
Changes:
 ifeffit (2:1.2.11d-10.2+b4) unstable; urgency=low, binary-only=yes
 .
   * Binary-only non-maintainer upload for i386; no source changes.
   * Rebuild with libreadline8.
Checksums-Sha1:
 459af89b76b581a1ba8520e42b6f7e751db52f5a 861376 
ifeffit-dbgsym_1.2.11d-10.2+b4_i386.deb
 5b1675a1ba7bdfd0ee472f2a6e38f27a7f376ddf 10413 
ifeffit_1.2.11d-10.2+b4_i386.buildinfo
 2c731459da19b49955ce0db29930938608ec2e8e 1291660 
ifeffit_1.2.11d-10.2+b4_i386.deb
 3a1d0021d6c54c8f03f01e3d772ec6112a507010 294756 
libifeffit-perl-dbgsym_1.2.11d-10.2+b4_i386.deb
 e4907b30e960ed3c8913b0654c6fad9d9fab2dc9 262900 
libifeffit-perl_1.2.11d-10.2+b4_i386.deb
 ce7d8e1d31c443d4f0226eba1667b61286547c00 273912 
python-ifeffit-dbgsym_1.2.11d-10.2+b4_i386.deb
 661e0a61c32f63f749fe3ec9a8ca4b111f881360 265528 
python-ifeffit_1.2.11d-10.2+b4_i386.deb
Checksums-Sha256:
 29ffee2ab36ce3be0598843422b1270eb7e87bedded90facb874cba21b47118b 861376 
ifeffit-dbgsym_1.2.11d-10.2+b4_i386.deb
 6fc7951f5e253aa960f0da0040c4c60614a0d79d93f2dc953183e27649b9d6b0 10413 
ifeffit_1.2.11d-10.2+b4_i386.buildinfo
 342782268bf5a4422055366883ca4aea7d226d430dd380eacb0d2365448dc5c8 1291660 
ifeffit_1.2.11d-10.2+b4_i386.deb
 998b5e2480139e550a818769082b4252dbc7680c44633f7e2574de96c81bbd72 294756 
libifeffit-perl-dbgsym_1.2.11d-10.2+b4_i386.deb
 9d9829bc7198ee279cdccc9c39d293cba3fe05a8b5dde16b84c20c275d7c8379 262900 
libifeffit-perl_1.2.11d-10.2+b4_i386.deb
 d04aa758c0a436249e4a683f665f9e68cbc87b13372cd4afa1771746a83e14be 273912 
python-ifeffit-dbgsym_1.2.11d-10.2+b4_i386.deb
 d5c8ddbb00e5e20d4cdf48909d258a417b9420ad80a7a1a11f8efa89949972d5 265528 
python-ifeffit_1.2.11d-10.2+b4_i386.deb
Files:
 c28376addcf502171f0c6df4cc9a788a 861376 contrib/debug optional 
ifeffit-dbgsym_1.2.11d-10.2+b4_i386.deb
 ac1df984cc97a515c2c602d0d83f317b 10413 contrib/science optional 
ifeffit_1.2.11d-10.2+b4_i386.buildinfo
 2c6ebae3b2ecdd78c8b126a5fb30f395 1291660 contrib/science optional 
ifeffit_1.2.11d-10.2+b4_i386.deb
 cb1606d74de741d2e16f670be66349cd 294756 contrib/debug optional 
libifeffit-perl-dbgsym_1.2.11d-10.2+b4_i386.deb
 bd53f29bb2448632c37a729400261e3e 262900 contrib/perl optional 
libifeffit-perl_1.2.11d-10.2+b4_i386.deb
 7f556b61461e90cef5101947372456fc 273912 contrib/debug optional 
python-ifeffit-dbgsym_1.2.11d-10.2+b4_i386.deb
 47423ac1a69b12bae91fe51248227ef7 265528 contrib/python optional 
python-ifeffit_1.2.11d-10.2+b4_i386.deb
Format: 1.8
Date: Tue, 23 Jul 2019 21:20:04 +0200
Source: ifeffit (2:1.2.11d-10.2)
Binary: ifeffit ifeffit-dbgsym libifeffit-perl libifeffit-perl-dbgsym 
python-ifeffit python-ifeffit-dbgsym
Binary-Only: yes
Architecture: amd64
Version: 2:1.2.11d-10.2+b4
Distribution: unstable
Urgency: low
Maintainer: Mattia Rizzolo 
Changed-By: Mattia Rizzolo 
Description:
 ifeffit- Interactive XAFS analysis program
 libifeffit-perl - Perl extensions for IFEFFIT
 python-ifeffit - Python GUI interface and extensions for IFEFFIT
Changes:
 ifeffit (2:1.2.11d-10.2+b4) unstable; urgency=low, binary-only=yes
 .
   * Binary-only non-maintainer upload for amd64; no source changes.
   * Rebuild with libreadline8.
Checksums-Sha1:
 9991e18754de45b26dd0f69fe5a1066d749d8e72 1151132 
ifeffit-dbgsym_1.2.11d-10.2+b4_amd64.deb
 8848d6a8ddbfd18a0fc26803bdd54a968f337954 10779 
ifeffit_1.2.11d-10.2+b4_amd64.buildinfo
 7a51684822298d2ab5b3d68cd07d6db13c092fb8 1324476 
ifeffit_1.2.11d-10.2+b4_amd64.deb
 ff46cb1af810e6a47b41861e6bc7deb81d8c7de2 379692 
libifeffit-perl-dbgsym_1.2.11d-10.2+b4_amd64.deb
 88f844312b9659947af8fb607df6cdaccf0bb219 271192 
libifeffit-perl_1.2.11d-10.2+b4_amd64.deb
 dc0dff534a4b2f8ec7c2cc7dcddfdfd8a79785ed 

Bug#932838:

[Marcus Furlong]

This leads to people disabling functionality. See e,g,:

https://gerrit.wikimedia.org/r/#/c/operations/docker-images/docker-pkg/+/487849/3/docker_pkg/image.py

-- 
Marcus Furlong

Bug#932839: uswsusp: conflicts with plymouth

[Jonathan Michalon]

Package: uswsusp
Version: 1.0+20120915-6.2
Severity: important
Tags: patch

Hi,

Using uswsusp after an upgrade from Stretch, it hangs after loading the s2disk 
image.
Last message is:
resume: Image successfully loaded

I found a report on launchpad [1], telling that it conflicts with plymouth and 
indeed
removing plymouth fixes the problem. Now in Buster, plymouth is pulled-in by the
desktop-base package so that I had it installed by upgrade.
This, to my mind, makes s2disk unusable on any standard desktop installation 
(hope I'm wrong…).
On launchapd the user provides a quick patch to tell plymouth to quit, see [2].

Would probably be nice to patch it at least at Debian's level since the bug 
comes from 2010 and
we face it in 2019 :)

[1] https://bugs.launchpad.net/ubuntu/+source/hibernate/+bug/1159205
[2] https://bugs.launchpad.net/ubuntu/+source/uswsusp/+bug/816859/comments/9


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

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

Versions of packages uswsusp depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-10
ii  liblzo2-2  2.10-0.1
ii  libpci31:3.5.2-1
ii  libx86-1   1.1+ds1-10.2

Versions of packages uswsusp recommends:
ii  initramfs-tools  0.133
ii  mount2.33.1-0.1

uswsusp suggests no packages.

-- debconf information:
* uswsusp/early_writeout: true
  uswsusp/RSA_key_file: /etc/uswsusp.key
* uswsusp/image_size: 0
* uswsusp/snapshot_device:
  uswsusp/continue_without_swap: true
* uswsusp/compress: true
  uswsusp/resume_offset:
* uswsusp/resume_device: /dev/disk/by-uuid/eb7adaac-6f7c-40cd-a542-123165be7b42
  uswsusp/no_swap:
  uswsusp/no_snapshot:
* uswsusp/max_loglevel:
  uswsusp/create_RSA_key: false
* uswsusp/encrypt: false
* uswsusp/shutdown_method: platform
* uswsusp/suspend_loglevel:
* uswsusp/compute_checksum: true
  uswsusp/RSA_key_bits: 1024