Bug#966839: openmm: withhold the package until a stable release

[merkys]

Source: openmm
Severity: grave
Owner: Andrius Merkys 
Control: forwarded -1 https://github.com/openmm/openmm/issues/2784

Hello,

The upstream expressed their concern that packaging development version of 
OpenMM may cause trouble with its users [1]. Therefore it has been agreed to 
withhold the Debian package until the next stable release.

[1] https://github.com/openmm/openmm/issues/2784

Andrius

Bug#957141: dns2tcp: ftbfs with GCC-10

[Antoni Villalonga]

Please find attached patch to fix this issue.

-- 
Antoni Villalonga
https://friki.cat/
Description: fixes gcc-10 build issues
Author: Antoni Villalonga 
Last-Update: 2020-08-02
--- a/common/includes/debug.h
+++ b/common/includes/debug.h
@@ -24,7 +24,7 @@
 #include 
 #include 
 
-int debug;
+extern int debug;
 
 #ifndef _WIN32
 #define DPRINTF(level, fmt, args...)  \
--- a/server/main.c
+++ b/server/main.c
@@ -42,6 +42,8 @@
 #include "myerror.h"
 #include "log.h"
 
+int debug;
+
 int			detach_process(t_conf *conf)
 {
   int			fd;
--- a/client/main.c
+++ b/client/main.c
@@ -36,6 +36,8 @@
 #include "myerror.h"
 #include "dns.h"
 
+int debug;
+
 /**
  * @brief main part
  * @retval 0 on success

Bug#966838: rails: newapp autopkgtest failed and it also broke autopkgtest for many rails assets packages

[Pirate Praveen]

Package: rails
Version: 6.0.3.2+dfsg-4
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/arm64/r/ruby-rails-assets-autosize/6520761/log.gz 
(same error in rails as well other autopkgtest failures)


run bundle install --local
/usr/share/rubygems-integration/all/gems/railties-6.0.3.2/lib/rails/generators/app_base.rb:364:in 
`block in bundle_command': undefined local variable or method 
`_bundle_command' for 
# (NameError)

Did you mean? bundle_command
  exec_bundle_command
from /usr/lib/ruby/2.7.0/bundler.rb:364:in `block in with_original_env'
from /usr/lib/ruby/2.7.0/bundler.rb:677:in `with_env'
from /usr/lib/ruby/2.7.0/bundler.rb:364:in `with_original_env'
from 
/usr/share/rubygems-integration/all/gems/railties-6.0.3.2/lib/rails/generators/app_base.rb:363:in 
`bundle_command'
from 
/usr/share/rubygems-integration/all/gems/railties-6.0.3.2/lib/rails/generators/app_base.rb:406:in 
`run_bundle'

from (eval):1:in `run_bundle'
from /usr/lib/ruby/vendor_ruby/thor/command.rb:27:in `run'
from /usr/lib/ruby/vendor_ruby/thor/invocation.rb:126:in 
`invoke_command'
from /usr/lib/ruby/vendor_ruby/thor/invocation.rb:133:in `block in 
invoke_all'

from /usr/lib/ruby/vendor_ruby/thor/invocation.rb:133:in `each'
from /usr/lib/ruby/vendor_ruby/thor/invocation.rb:133:in `map'
from /usr/lib/ruby/vendor_ruby/thor/invocation.rb:133:in `invoke_all'
from /usr/lib/ruby/vendor_ruby/thor/group.rb:232:in `dispatch'
from /usr/lib/ruby/vendor_ruby/thor/base.rb:466:in `start'
from 
/usr/share/rubygems-integration/all/gems/railties-6.0.3.2/lib/rails/commands/application/application_command.rb:26:in 
`perform'

from /usr/lib/ruby/vendor_ruby/thor/command.rb:27:in `run'
from /usr/lib/ruby/vendor_ruby/thor/invocation.rb:126:in 
`invoke_command'

from /usr/lib/ruby/vendor_ruby/thor.rb:387:in `dispatch'
from 
/usr/share/rubygems-integration/all/gems/railties-6.0.3.2/lib/rails/command/base.rb:69:in 
`perform'
from 
/usr/share/rubygems-integration/all/gems/railties-6.0.3.2/lib/rails/command.rb:46:in 
`invoke'
from 
/usr/share/rubygems-integration/all/gems/railties-6.0.3.2/lib/rails/cli.rb:18:in 
`'
from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:72:in 
`require'
from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:72:in 
`require'
from 
/usr/share/rubygems-integration/all/gems/railties-6.0.3.2/exe/rails:10:in 
`'

from /usr/bin/rails:23:in `load'
from /usr/bin/rails:23:in `'

Bug#957360: insighttoolkit4: ftbfs with GCC-10

[Étienne Mollier]

Étienne Mollier, on 2020-08-02 20:25:07 +0200:
> I will push that change to salsa if I see the build succeed,

Arf, no dice, there might be more changes needed, including
maybe:
  * reviewing cmake build dependencies metainformations, as in
the upstream commit documented in a previous entry, which
makes me wonder whether the system castxml is actually used,
  * an update to ITK 4.13.3.

Nothing is out of reach, but it won't happen this morning UTC+2.

Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#966837: virtualbox: when in full-screen moves autonomously to current screen

[Francesco Potortì]

Package: virtualbox
Version: 6.1.12-dfsg-7
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

Working on Mate with six desktops.  Virtualbox is in desktop 2 in full
screen.  Several times a day virtualbox moves to the screen where I am
working.

This did not happen one month ago, with older kernel and vbox.

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it



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

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

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  5.7.0-1
ii  libc6 2.31-2
ii  libcurl3-gnutls   7.68.0-1+b1
ii  libdevmapper1.02.12:1.02.171-1
ii  libgcc-s1 10.2.0-3
ii  libgl11.3.2-1
ii  libgsoap-2.8.104  2.8.104-2
ii  liblzf1   3.6-2
ii  libopus0  1.3-1+b1
ii  libpng16-16   1.6.37-2
ii  libpython3.8  3.8.5-1
ii  libsdl1.2debian   1.2.15+dfsg2-5
ii  libssl1.1 1.1.1g-1
ii  libstdc++610.2.0-3
ii  libvncserver1 0.9.13+dfsg-1
ii  libvpx6   1.8.2-dmo1
ii  libx11-6  2:1.6.10-1
ii  libxcursor1   1:1.2.0-2
ii  libxml2   2.9.10+dfsg-5+b1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.16-5
ii  python3   3.8.2-3
ii  python3.8 3.8.5-1
ii  virtualbox-dkms [virtualbox-modules]  6.1.12-dfsg-8
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages virtualbox recommends:
ii  libqt5core5a5.14.2+dfsg-4
ii  libqt5gui5  5.14.2+dfsg-4
ii  libqt5opengl5   5.14.2+dfsg-4
ii  libqt5widgets5  5.14.2+dfsg-4
ii  libxcb1 1.14-2
ii  libxext62:1.3.3-1+b2
ii  virtualbox-qt   6.1.12-dfsg-7

Versions of packages virtualbox suggests:
ii  vde22.3.2+r586-2.2+b1
ii  virtualbox-guest-additions-iso  6.1.12-1

-- no debconf information

Bug#966649: [UDD] Upload_history table is currently empty

[Lucas Nussbaum]

On 02/08/20 at 22:38 +0200, Andreas Tille wrote:
> On Sun, Aug 02, 2020 at 04:09:49PM +0200, Lucas Nussbaum wrote:
> > On 02/08/20 at 15:12 +0200, Andreas Tille wrote:
> > > Hi,
> > > 
> > > an untested 2to3 port of UDD code is in python3 branch of
> > > 
> > >https://salsa.debian.org/qa/udd/-/tree/python3
> > 
> > ... but it does not include the script in question for this bug?
> 
> You mean munge_ddc.py?  Hmmm, I can not even find it in master branch?

As I wrote in the bug:
> 'munge_ddc.py' has the following issues:
> - it's not version-controlled

Lucas

Bug#966836: dracut-core: Typo in README.Debian

[Diego Escalante]

Package: dracut-core
Version: 050+65-1
Severity: normal
Tags: patch
X-Debbugs-Cc: die...@gnome.org

Dear Maintainer,

There's a typo in README.Debian. Patch attached :).

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: 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
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dracut-core depends on:
ii  bash5.0-6
ii  cpio2.13+dfsg-2
ii  e2fsprogs   1.45.6-1
ii  kmod27+20200310-2
ii  kpartx  0.8.4-3
ii  libc6   2.31-2
ii  libkmod227+20200310-2
ii  pkg-config  0.29.2-1
ii  udev245.7-1
ii  util-linux  2.36-1

Versions of packages dracut-core recommends:
ii  binutils   2.35-1
ii  console-setup  1.196
ii  cryptsetup 2:2.3.3-1+b1
pn  dmraid 
ii  dmsetup2:1.02.171-2
ii  lvm2   2.03.07-1+b1
pn  mdadm  
ii  pigz   2.4-1+b1
ii  systemd245.7-1

dracut-core suggests no packages.

-- no debconf information
>From f1470ca1120e17d3a5a7fa1ee4429a4ab261b075 Mon Sep 17 00:00:00 2001
From: Diego Escalante Urrelo 
Date: Mon, 3 Aug 2020 01:10:24 -0500
Subject: [PATCH] d: Fix a typo in dracut-core.README.Debian

---
 debian/dracut-core.README.Debian | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/dracut-core.README.Debian b/debian/dracut-core.README.Debian
index a90c66de..c4be1784 100644
--- a/debian/dracut-core.README.Debian
+++ b/debian/dracut-core.README.Debian
@@ -3,7 +3,7 @@ dracut for Debian
 
 1. Give it a try
 
-Currently dracut is not the default initrd craetion tool in Debian.
+Currently dracut is not the default initrd creation tool in Debian.
 You can try dracut without removing initramfs-tools from your machine
 by following these steps:
 
-- 
2.27.0

Bug#937490: pynifti: Python2 removal in sid/bullseye

[Michael Hanke]

Hi,

On Sun, Aug 2, 2020, 23:47 Moritz Mühlenhoff  wrote:

> On Fri, Jul 10, 2020 at 01:08:44PM +0200, Andreas Tille wrote:
> > On Mon, Jun 29, 2020 at 08:37:58PM +0200, Moritz Mühlenhoff wrote:
> > > On Fri, Aug 30, 2019 at 07:34:39AM +, Matthias Klose wrote:
> > >
> > > The upstream homepage states
> > >
> > > | PyNIfTI is no longer actively developed. At has been
> > > | superseded by NiBabel -- a pure-Python package that
> > > | provides everything that PyNIfTI could do, and a lot more.
> > >
> > > Given that nibabel is packaged, let's simply remove pynifti?
> >
> > Same answer from my side as for mrtrix - from my point of
> > view it can go.
>
> Michael/Yaroslav, ping. Ack to remove pynifti from your end?


Yes, it can go. Thx.


Michael

>
>

Bug#966835: haskell-shake needs source upload for new haddock interface

[Adrian Bunk]

Source: haskell-shake
Version: 0.16.4+dfsg-4
Severity: serious
Control: affects -1 libghc-shake-doc

The following packages have unmet dependencies:
 libghc-shake-doc : Depends: haddock-interface-33 but it is not installable

Bug#960901: Buffer is a built-in node function

[Ben Finney]

Howdy Pirate,

On 18-May-2020, Pirate Praveen wrote:

> For this particular case you can try embedding buffer module version
> 4.x as browsers need an equivalent module to features present only
> in node.

This looks like advice for me to work around the problem. What do I
need to do? How do I (as a user of the Debian package of Webpack)
“embed buffer module version 4.x”?

-- 
 \   “Even if the voices in my head are not real, they have pretty |
  `\   good ideas.” —anonymous |
_o__)  |
Ben Finney 

signature.asc
Description: PGP signature

Bug#966834: debhelper: dh_missing has a confusing typo+msg in $has_related_files

[Diego Escalante]

Package: debhelper
Version: 13.2
Severity: important
X-Debbugs-Cc: die...@gnome.org

Dear Maintainer,

dh_missing prints the following message when $has_related_files is met:

+   if ($had_related_files) {
+   my ($missing, $alt_source) = $had_related_files->@*;
+   nonquiet_print();
+   nonquiet_print('Some of the files had a file that looked 
similar to a missing counter part. Perhaps');
+   nonquiet_print('one of the debhelper tools should installed the 
missing file instead of its related');
+   nonquiet_print('file assuming the content is identical.');
+   nonquiet_print();
+   nonquiet_print('As an example, perhaps you want to replace:');
+   nonquiet_print(" * ${alt_source}");
+   nonquiet_print('with:');
+   nonquiet_print(" * ${missing}");
+   nonquiet_print('in a file in debian/ or as argument to one of 
the dh_* tools called from debian/rules.');
+   nonquiet_print('(Note it is possible the paths are not used 
verbatim but instead directories ');
+   nonquiet_print('containing or globs matching them are used 
instead)');
+   nonquiet_print();
+   nonquiet_print('Alternatively, add the missing file to 
debian/not-installed if it cannot and should not');
+   nonquiet_print('be used.');
+   nonquiet_print();


The above message is confusing in precisely what "file" means, specially
in the second sentence where it goes about "the missing file instead of
its related file" (huh?)

Since there's a typo in "debhelpers tools should (?) installed", I
couldn't figure out what the original intention of the warning was. I
figured out my FTBFS, but mostly because I saw the printed references to
the offending files.

I would have sent you a patch but I didn't know what the message was
supposed to convey. Sorry :(.

I would be thankful if the message could be updated to be slightly more
precise, or at least remove the typo :P.

Thanks!

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: 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
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.9.0-1
ii  dpkg 1.20.5
ii  dpkg-dev 1.20.5
ii  dwz  0.13-5
ii  file 1:5.38-4
ii  libdebhelper-perl13.2
ii  libdpkg-perl 1.20.5
ii  man-db   2.9.3-1
ii  perl 5.30.3-4
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#966832: kodi 18.8

[Vasyl Gello]

Dear colleagues,

I confirm the issue affects kodi 18.7+. I prepared 18.8 release, but we are 
blocked with this bug.

Kodi 19.0 I am working on in my personal space has no such issue because it 
already supports python3-only.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature

Bug#966828: emacs: Fatal error 11: Segmentation fault

[Winter Metasequoia]

FYI.  I just encountered similar situation, but downgrading libx11-6
from 2:1.6.10-1 to 2:1.6.9-2+b1
emacs has been recovered.  I hope someone confirms this.

On Mon, 3 Aug 2020 00:12:41 +0200 Salman Mohammadi  wrote:
> Package: emacs
> Version: 1:26.3+1-2
> Severity: grave
>
>
> Dear Maintainer,
>
> I cannot run emacs at all and I get the following error message:
>
> Fatal error 11: Segmentation fault
> Backtrace:
> emacs[0x5111be]
> emacs[0x4f6ead]
> emacs[0x50f63e]
> emacs[0x50f86d]
> emacs[0x50f8e9]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f29d6abd140]
> emacs[0x4d94b0]
> emacs[0x4d9897]
> emacs[0x4da4df]
> emacs[0x56dc2c]
> emacs[0x5a74c0]
> emacs[0x56dbab]
> emacs[0x5a74c0]
> emacs[0x56dbab]
> emacs[0x56f90b]
> emacs[0x56dc2c]
> emacs[0x5a74c0]
> emacs[0x56dbab]
> emacs[0x5a74c0]
> emacs[0x56dbab]
> emacs[0x5a74c0]
> emacs[0x56dbab]
> emacs[0x5a74c0]
> emacs[0x56dbab]
> emacs[0x5a74c0]
> emacs[0x570726]
> emacs[0x56fcc6]
> emacs[0x571c1c]
> emacs[0x56cd7e]
> emacs[0x4f8470]
> emacs[0x56cced]
> emacs[0x4f71f8]
> emacs[0x4fc2b3]
> emacs[0x4fc5f8]
> emacs[0x41a5c2]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f29d67ddcca]
> emacs[0x41b29a]
> Segmentation fault
>
> Regards,
>
> Salman
>
>
> -- System Information:
> Debian Release: bullseye/sid
>APT prefers unstable
>APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)

Bug#966088: debian-rust mailing list

[Wolfgang Silbermayr]

I support this request. People don't subscribe to the pkg-rust-maintainers
list due to the low signal-to-noise ratio if they just want to communicate
with the debian-rust team and not be informed about each and every package 
upload.

The pkg-rust-maintainers list is useful to the team itself and should be kept
available.

Wolfgang Silbermayr.

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Ben Hutchings]

On Sun, 2020-08-02 at 22:44 +0200, Thorsten Glaser wrote:
> On Sun, 2 Aug 2020, Ben Hutchings wrote:
> 
> > The RFC says that the IPV6_TCLASS option's value is an int, and that
> 
> for setsockopt (“option's”), not cmsg
> 
> > No, the wording is *not* clear.
> 
> Agreed.
> 
> So perhaps let’s try to find out what’s actually right…

For what it's worth, FreeBSD/Darwin and Windows also put 4 bytes of
data in a IPV6_TCLASS cmsg.  So whether or not it's "right", it's
consistent between three independent implementations.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.




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

Bug#966537: ITP: tomboy-ng -- Cross Platform Notes

[Ben Hutchings]

On Mon, 2020-08-03 at 10:34 +1000, David Bannon wrote:
> Ben, I am not sure if I am allowed to answer here, don't want Bart to
> slap me down again.
> 
> If I have it wrong again, very sorry, will withdraw
> 
> 
> On 3/8/20 4:34 am, Ben Hutchings wrote:
> > Gtk+ 2 is deprecated, and we should not add new applications using it.
> > So it sounds like the best option for now would be to build it with Qt
> > support only.  Why is that limited to 64-bit architectures?
> 
> Ben, most distros are still shipping GTK2 and most don't ship Qt5. So,
> at present, it sort of makes sense to use GTK2 from the point of view of
> the average user.

I am only talking about what should be done in an official Debian
package here.  It you build a generic binary for Linux then Gtk+ 2 may
well be the better option.

> The point is that with Lazarus, its trivial to switch
> from GTK2 to QT5 at compile time so, in a way, tomboy-ng is not really a
> GTK2 app, it can be what ever is decided at compile time.
> 
> The Qt5 version is dependent of a shim library, libqt5pas that is
> available in most newer distributions but 64bit only.  Thats apparently
> because the upstream libraries that are needed to link to it are not
> available.

Debian has it for 32-bit and 64-bit Arm and x86 architectures, plus
32-bit MIPS.

[...]
> That all sounds great. I am starting to understand the Debian process,
> but just starting !

You should probably join the debian-mentors mailing list and send any
questions there.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.



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

Bug#966716: initramfs-tools: update-initramfs fails with no conf.d/resume and veracrypt volume mounted

[Ben Hutchings]

[Added the bug address back in cc.  Reply to all, not just to me.]

On Mon, 2020-08-03 at 00:56 +0200, m...@tuta.io wrote:
> > That's a warning from cryptsetup, not from initramfs-tools itself.
> I'm sorry for that, how do I forward this to cryptsetup?
> 
> > So you don't know whether update-initramfs actually failed?
> I didn't take the chance, no. 
> A few days ago I was trying to configure cryptsetup to unlock with a
> keyfile. I was doing so from a live system that mounted cryptsetup
> devices with generic names ("luks-UUID"), if I didn't change the name
> of the device to "hdd500_crypt" with "dmsetup rename", then I would
> get this exact message and the system would not boot.
> 
> Unfortunately this is my only machine and it is very important that
> it keeps working. If I do try to reboot after getting that warning I
> fear that I might have to spend an entire afternoon fixing it.

If I understand rightly, you created or reconfigured a cryptsetup
volume (hdd500_crypt) but it's not listed in /etc/crypttab.  The
initramfs should still work as it only needs to mount / and /usr, but
you probably couldn't boot all the way to multi-user mode without
/home.

Is hdd500_crypt listed in /etc/crypttab?  If you add an entry for it
and re-run "update-initramfs -u", does it complete successfully without
warnings?

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.




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

Bug#962990: blhc: False positive with ngetty

[Eriberto Mota]

Control: reassign 962990 ngetty

The current version of blhc (0.12) allow debian/rules write lines in build
logto ignore false positives. So, the #962990 is being reassigned from blhc
to ngetty.

Regards,

Eriberto

Bug#966501: 2.0.3 REST API regression: Failed to parse parameters for /v1.12/libpod/events: unexpected end of JSON input

[Reinhard Tartler]

I have good news for you, podman 2.0.4 got out last Friday, and I've
uploaded it to unstable earlier today. Let me know how this version works
with your CI.

Best,
-rt

On Fri, Jul 31, 2020 at 7:01 AM Martin Pitt  wrote:

> Hallo Reinhard,
>
> Reinhard Tartler [2020-07-31  6:42 -0400]:
> > Thank you for your bugreport. I looked into backporting the change and
> > checked in with my contact upstream. It turns out that this is not the
> only
> > issue with the REST interface, and neither of them are easy to backport
> to
> > 2.0.3. A new release will come out soon that should be suitable for
> > cockpit-podman.
>
> Right, I prodded the podman team about a new release this morning. So far
> 2.0.2
> was the only upstream release where the REST interface works.
>
> > Cockpit looks like a really cool project. I do need to find some time to
> > play with it, in particular with the upcoming cockpit-podman component.
> > Thanks for packaging it! Are you working full time on "cockpit"?
>
> Yes, I am :) I'm currently working on getting the integration tests to
> succeed
> in upstream CI, and once they do and Debian has a podman.deb that actually
> works, I'll package cockpit-podman for Debian.
>
> > Given that the REST interface is not available in testing (the respective
> > systemd units were only introduced in 2.0.3+dfsg1-1)
>
> Right, I currently hack around that in our CI:
>
>
> https://github.com/cockpit-project/cockpit-podman/blob/master/test/vm.install#L13
>
> >and podman provides a lot of value even without them, I'd rather have the
> >current package migrate to testing at this point. Having said this, I do
> >really appreciate your bug report and will see to a remedy as soon as it
> >becomes available in the form of a new upstream release.
>
> Understandable.
>
> > For the time being, I'd recommend disabling the cockpit-podman test for
> the
> > time being and re-enable it when this bug gets closed properly.
>
> I'll probably grab 2.0.2 from
> http://snapshot.debian.org/package/libpod/2.0.2%2Bdfsg1-3/
> in the meantime then, to unblock the upstream CI work. That's not a big
> deal.
>
> Thanks,
>
> Martin
>


-- 
regards,
Reinhard

Bug#966537: ITP: tomboy-ng -- Cross Platform Notes

[David Bannon]

Ben, I am not sure if I am allowed to answer here, don't want Bart to
slap me down again.

If I have it wrong again, very sorry, will withdraw


On 3/8/20 4:34 am, Ben Hutchings wrote:
> Gtk+ 2 is deprecated, and we should not add new applications using it.
> So it sounds like the best option for now would be to build it with Qt
> support only.  Why is that limited to 64-bit architectures?

Ben, most distros are still shipping GTK2 and most don't ship Qt5. So,
at present, it sort of makes sense to use GTK2 from the point of view of
the average user. The point is that with Lazarus, its trivial to switch
from GTK2 to QT5 at compile time so, in a way, tomboy-ng is not really a
GTK2 app, it can be what ever is decided at compile time.

The Qt5 version is dependent of a shim library, libqt5pas that is
available in most newer distributions but 64bit only.  Thats apparently
because the upstream libraries that are needed to link to it are not
available.

The Lazarus people maintain and develop libqt5pas but I make binary deb
and rpms available at https://github.com/davidbannon/libqt5pas for
people using older distros such as Ubuntu18.04. Its no useful at all for
eg U16.04. I expect the same applies to Stretch, have not tested Qt5 on
Buster.


> Depending on what your script does, the 'kit' might not include what we
> would consider the full source code.  The script itself would also need
> to be made public, usually as part of the source package.
>
> It is generally preferable for Debian source packages to start from a
> tarball that exactly matches an upstream release.

Absolutely !  What I have been doing while I play with this model is to
download a zip file from github, I run a script that unzips and inserts
in the dependency source, kcontrols. It then makes the
tomboy-ng.orig.tar.gz file that exactly matched the new created working
dir. debuild will run and make the files that go towards the SRC DEB. 
Together they make a quite conventional SRC DEB kit.

As a side note, that first script also sets up some things that are
useful for people like me who have FPC or Lazarus installed in user
space.  Many Lazarus developers keep Lazarus in userspace rather than
install from a deb, there are good reasons. But this is irreverent to
building a SRC DEB where we assume both FPC and Lazarus are root installed.

That script, and one called by the Makefile are bundled in the zip file
downloaded from Github.  

>
> In any case this will have to go into unstable first, and then (if all
> goes well) it can go into bullseye and maybe buster-backports.  It
> won't be added to buster as we don't add new applications to stable
> releases.

That all sounds great. I am starting to understand the Debian process,
but just starting !

Davo

Bug#476863: closed by Kartik Kulkarni (Closing 476863)

[Adam Sjøgren]

Kartik Kulkarni writes:

> I believe that this bug is too old and I am taking the liberty to
> close it.

Is age (alone) sufficient cause to close a bug?

The current version in Debian unstable seems to be more broken, compared
to what the help text says:

  $ source-highlight --src-lang perl hello
  Processing hello ... created hello.html
  $ source-highlight --src-lang perl --output=STDOUT hello
  Please, use one of the two syntaxes for invocation: 
  source-highlight [OPTIONS]... -i input_file -o output_file
  source-highlight [OPTIONS]... [FILES]...
  $ source-highlight --help | grep -A3 'output=FILENAME'
-o, --output=FILENAME Output file (default=stdout, when the third
invocation form is used). If 'STDOUT' is
specified, the output is directed to 
standard
output
  $ source-highlight --version | head -n 1
  GNU Source-highlight 3.1.9 (library: 4:1:0)
  $ 

The --output STDOUT no longer works, despite the help text.

Ah, it is now mandatory to use --input when using --output (that's what
"the third invocation form" is about), it seems:

  $ source-highlight --src-lang perl --output=STDOUT --input=hello
  
  #!/usr/bin/perl
[...]
  say 'Hello world';
  
  $ 

And if you use --input and no --output, the behaviour I expected with
just a filename is observed:

  $ source-highlight --src-lang perl --input=hello
  
  #!/usr/bin/perl
[...]
  say 'Hello world';
  
  $ 

I still think the help text is confusing, but at least now it won't
overwrite a existing file *if* you use --input.

Upstream it seems that this is the expected behaviour:

  "Sat 01 Jun 2019 08:18:17 PM UTC, comment #2: 
   I think this is fixed now
   Tom Tromey "

 · http://savannah.gnu.org/support/index.php?106347#comment2

So for that reason I think it is fine to close this bug.

Thanks for taking the time to look at this oldie!


  Best regards,

Adam

-- 
 "I wonder if you can refuse to inherit the world." Adam Sjøgren
 "I think if you're born, it's too late."  a...@koldfront.dk

Bug#966525: dmagnetic FTBFS on i386: check-sixel failed

[dettus]

Hello everybody.


After Adrian was kind enough to give me a solution to my problem, I was 
able to apply it.


So my wonderful project dMagnetic can now be found with the release 
number 0.25-2 in

your mentors.debian.net system.

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

Now, I would kindly ask you to upload it to the unstable servers.



Thomas

On 8/2/20 4:09 PM, Adrian Bunk wrote:

On Fri, Jul 31, 2020 at 06:02:03PM +0200, Thomas Dettbarn wrote:

Hello Adrian.

So, I patched my package, and uploaded to mentors.

I got a message with the subject "dmagnetic_0.25-1:
ACCEPTED into unstable."

It can be found here,

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


but now I am a little bit concerned about the developer information
page: https://tracker.debian.org/pkg/dmagnetic it is still complaining
about i386 not working. Could you have a look?

Whatever you do on mentors does not have any effect in Debian,
unless it gets uploaded into the archive.

Version 0.25-1 of dmagnetic has been uploaded (by Adam Borowski).
This version cannot ever be changed in Debian.

You have to make a new revision 0.25-2 with the fix applied,
a changelog describing all changes like
   * Build with -ffloat-store on i386 to fix FTBFS. (Closes: #966525)
and that has to be uploaded to Debian for you.

I can sponsor such an upload if you upload it to mentors.


Thomas

cu
Adrian

Bug#966832: python2: /usr/share/perl5/Debian/Debhelper/Sequence/python2.pm is gone from Debian

[Christian Marillat]

Package: python2
Version: 2.7.17-2
Severity: normal

Dear Maintainer,

You are saying to install dh-python but dh-python doesn't have this file,
and I can't rebuild my python2 packages to update python dependency to python2

Christian

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

Kernel: Linux 5.7.12 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python2 depends on:
ii  libpython2-stdlib  2.7.17-2
ii  python2-minimal2.7.17-2
ii  python2.7  2.7.18-1

python2 recommends no packages.

Versions of packages python2 suggests:
pn  python-tk
pn  python2-doc  

-- no debconf information

Bug#966830: haskell-blogliterately: Cannot fulfill the build dependencies

[Adrian Bunk]

Source: haskell-blogliterately
Version: 0.8.6.3-1
Severity: serious
Tags: ftbfs

The following packages have unmet dependencies:
 builddeps:haskell-blogliterately : Depends: libghc-lens-dev (< 4.18) but 
4.18.1-1 is to be installed
Depends: libghc-pandoc-dev (< 2.8) but 
2.9.1.1-3 is to be installed
Depends: libghc-pandoc-types-dev (< 1.20) 
but 1.20-1+b1 is to be installed

Bug#966831: patat: Cannot fulfill the build dependencies

[Adrian Bunk]

Source: patat
Version: 0.8.4.0-1
Severity: serious
Tags: ftbfs

The following packages have unmet dependencies:
 builddeps:patat : Depends: libghc-ansi-terminal-dev (< 0.10) but 0.10.3-1 is 
to be installed
   Depends: libghc-pandoc-dev (< 2.8) but 2.9.1.1-3 is to be 
installed

Bug#966829: linux-image-4.19.0-9-amd64: USB subsystem hangs with 4.19.0/buster series kernels

[E Harris]

Package: src:linux
Version: 4.19.118-2+deb10u1
Severity: important

Since upgrading to buster from stretch several months ago (in Feb 2020), I
have been experiencing unpredictable but repeated hangs of USB devices. 
The hangs are somewhat random, and have occurred anywhere from a few hours
after boot to a week or more after boot, with it happening most commonly
after about 2-3 days.

Although this sometimes occurs right after a device reports a read error or
other USB transaction that does not immediately complete, that does not seem
to always be the case.  Often there are also USB device resets near a hang,
I am not sure if they may be a contributing factor, or just a result of the
hang.

I haven't reported this problem before now because the problem isn't easy
to reproduce in a predictable manner, and I have been trying to narrow 
down if it might be device related.  Although it does seem to happen more
frequently on a device that currently has unreadable sectors, it also 
occurs with other devices that do not have read errors.

The hangs have at least once seemed to occur with USB devices other than 
USB harddrives (once was with a USB bluetooth 4.0 adapter).

Since I have several external USB3 hard drives when these hangs occur, it 
tends to cause filesystem lockups which then cause hard process hangs of 
anything that attempts access to those filesystems.  Due to the way linux
VFS works, the only solution to get the system back into a normal 
state is a reboot.  In all cases, a soft reboot (not hard powered off of 
either the machine or USB devices) has gotten things working again, which
leads me to believe that it is not actually a problem with any USB device,
but with the Linux kernel USB subsystem itself.

This also occurred with linux-image-4.19.0-8-amd64, and I am upgrading to 
linux-image-4.19.0-10-amd64 now.

I had no experiences of this type with the older stretch series of kernels
(4.9.0 series), which ran for years on this exact same hardware (with the
exception of one hard drive which has been replaced) with no problems.
In fact, while trying to narrow this problem down, I rebooted and ran
stretch kernel linux-image-4.9.0-12-amd64 for a few weeks and again
had no problems, even though read errors on the device mentioned above
occurred several times (I was using ddrescue to recover data at that time).

The tainted kernel is caused by the zfs drivers, which are used in a zfs
zpool on top of LUKS encrypted drives.

The USB3 cards in use are based on the NEC uPD720200 and uPD720201 chips.
I tried replacing the USB3 PCIe cards with known good ones, no difference.
So I put the original ones back in.

Here are the kernel log messages surrounding a typical hang:

[770583.827725] usb 2-4: reset SuperSpeed Gen 1 USB device number 5 using 
xhci_hcd
[770614.676494] usb 2-4: reset SuperSpeed Gen 1 USB device number 5 using 
xhci_hcd
[770614.702802] sd 9:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_TIME_OUT 
driverbyte=DRIVER_OK
[770614.702819] sd 9:0:0:0: [sdf] tag#0 CDB: Read(16) 88 00 00 00 00 00 de e1 
05 a0 00 00 00 b0 00 00
[770614.702827] print_req_error: I/O error, dev sdf, sector 3739288992
[770645.393118] usb 2-4: reset SuperSpeed Gen 1 USB device number 5 using 
xhci_hcd
[770645.418426] sd 9:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_TIME_OUT 
driverbyte=DRIVER_OK
[770645.418437] sd 9:0:0:0: [sdf] tag#0 CDB: Read(16) 88 00 00 00 00 00 de e1 
05 40 00 00 00 58 00 00
[770645.418440] print_req_error: I/O error, dev sdf, sector 3739288896
[770663.557525] INFO: task rclone:397934 blocked for more than 120 seconds.
[770663.557537]   Tainted: P   OE 4.19.0-9-amd64 #1 Debian 
4.19.118-2+deb10u1
[770663.557541] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[770663.557547] rclone  D0 397934   7932 0x
[770663.557556] Call Trace:
[770663.557576]  ? __schedule+0x2a2/0x870
[770663.557586]  schedule+0x28/0x80
[770663.557594]  io_schedule+0x12/0x40
[770663.557603]  blk_mq_get_tag+0x115/0x260
[770663.557610]  ? finish_wait+0x80/0x80
[770663.557618]  blk_mq_get_request+0xc1/0x3c0
[770663.557625]  blk_mq_make_request+0x131/0x530
[770663.557634]  generic_make_request+0x1a4/0x400
[770663.557642]  submit_bio+0x45/0x130
[770663.557812]  vdev_disk_io_start+0x603/0x6d0 [zfs]
[770663.557957]  zio_vdev_io_start+0x108/0x330 [zfs]
[770663.558097]  zio_nowait+0xc3/0x150 [zfs]
[770663.558242]  vdev_raidz_io_start+0x13a/0x2d0 [zfs]
[770663.558381]  zio_vdev_io_start+0x108/0x330 [zfs]
[770663.558525]  ? vdev_config_sync+0x180/0x180 [zfs]
[770663.558685]  zio_nowait+0xc3/0x150 [zfs]
[770663.558829]  ? vdev_config_sync+0x180/0x180 [zfs]
[770663.558972]  vdev_mirror_io_start+0x8b/0x160 [zfs]
[770663.559118]  ? spa_config_enter+0xb2/0x100 [zfs]
[770663.559256]  zio_vdev_io_start+0x2d0/0x330 [zfs]
[770663.559280]  ? tsd_get_by_thread+0x2a/0x40 [spl]
[770663.559417]  zio_nowait+0xc3/0x150 [zfs]
[770663.559537]  arc_read+0x617/0xa50 [zfs]
[770663.559659]  ? dbuf_

Bug#966828: emacs: Fatal error 11: Segmentation fault

[Salman Mohammadi]

Package: emacs
Version: 1:26.3+1-2
Severity: grave


Dear Maintainer,

I cannot run emacs at all and I get the following error message:

Fatal error 11: Segmentation fault
Backtrace:
emacs[0x5111be]
emacs[0x4f6ead]
emacs[0x50f63e]
emacs[0x50f86d]
emacs[0x50f8e9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f29d6abd140]
emacs[0x4d94b0]
emacs[0x4d9897]
emacs[0x4da4df]
emacs[0x56dc2c]
emacs[0x5a74c0]
emacs[0x56dbab]
emacs[0x5a74c0]
emacs[0x56dbab]
emacs[0x56f90b]
emacs[0x56dc2c]
emacs[0x5a74c0]
emacs[0x56dbab]
emacs[0x5a74c0]
emacs[0x56dbab]
emacs[0x5a74c0]
emacs[0x56dbab]
emacs[0x5a74c0]
emacs[0x56dbab]
emacs[0x5a74c0]
emacs[0x570726]
emacs[0x56fcc6]
emacs[0x571c1c]
emacs[0x56cd7e]
emacs[0x4f8470]
emacs[0x56cced]
emacs[0x4f71f8]
emacs[0x4fc2b3]
emacs[0x4fc5f8]
emacs[0x41a5c2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f29d67ddcca]
emacs[0x41b29a]
Segmentation fault

Regards,

Salman


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs depends on:
ii  emacs-gtk  1:26.3+1-2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package

[Mike Hommey]

On Sun, Aug 02, 2020 at 11:50:11PM +0200, Helmut Grohne wrote:
> Hi Mike,
> 
> On Mon, Aug 03, 2020 at 05:39:23AM +0900, Mike Hommey wrote:
> > I'd rather replace nss-config with upstream's.
> 
> Please don't. That makes nss-config subtly buggy. The upstream
> nss-config simply calls into pkg-config. In particular, it uses the
> unqualified pkg-config. So the behaviour of nss-config becomes dependent
> on the architecture you install pkg-config. In practice that means that
> means when you install libnss3-dev for a foreign architecture, it will
> be broken. And that amounts to breaking cross builds.
> 
> Really, using upstream's is the worst of choices here. Even removing
> nss-config entirely would be better as that'd force dependent packages
> (of which there are about 12) to properly use pkg-config instead.

Upstream's nss-config uses pkg-config for 3 things:
- getting exec_prefix. It's always /usr, independently of the pkg-config
  you use
- getting includedir. It's always /usr/include/nss, independently of the
  pkg-config you use
- getting libdir. This varies dependending on the pkg-config you use,
  but so does the content of the current nss-config, and as was said
  up-thread, nothing uses that.

So really, using upstream's nss-config wouldn't break things more than
they currently are, while it would fix the immediate multi-arch problem.
All the while not breaking any reverse-dependency.

Mike

Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load

[Dirk Kostrewa]

Hi Salvatore,

I have removed the xorg.conf with the Nvidia graphics driver and any 
nvidia-related *.conf files in /etc/modprobe.d/, and I have rebooted the 
laptop. The following output should show, that only the default nouveau 
driver is loaded:


# lsmod | grep nvidia

# lsmod | grep nouveau
nouveau  2179072  0
ttm   131072  1 nouveau
i2c_algo_bit   16384  2 i915,nouveau
drm_kms_helper    208896  2 i915,nouveau
mxm_wmi    16384  1 nouveau
drm   495616  12 drm_kms_helper,i915,ttm,nouveau
wmi    28672  6 
dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor,mxm_wmi,nouveau

video  45056  4 dell_wmi,dell_laptop,i915,nouveau
button 16384  1 nouveau

# lspci -k | egrep 'VGA|3D' -A2
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 
(rev 06)

    Subsystem: Dell HD Graphics 530
    Kernel driver in use: i915
--
01:00.0 3D controller: NVIDIA Corporation GM107GLM [Quadro M1000M] (rev a2)
    Subsystem: Dell GM107GLM [Quadro M1000M]
    Kernel driver in use: nouveau

# dmesg | grep -i nvidia
[    4.282530] nouveau :01:00.0: NVIDIA GM107 (117310a2)
[    4.547712] audit: type=1400 audit(1596389563.639:8): 
apparmor="STATUS" operation="profile_load" profile="unconfined" 
name="nvidia_modprobe" pid=543 comm="apparmor_parser"
[    4.547714] audit: type=1400 audit(1596389563.639:9): 
apparmor="STATUS" operation="profile_load" profile="unconfined" 
name="nvidia_modprobe//kmod" pid=543 comm="apparmor_parser"

[    5.944911] nvidia: loading out-of-tree module taints kernel.
[    5.944918] nvidia: module license 'NVIDIA' taints kernel.
[    5.949482] nvidia: module verification failed: signature and/or 
required key missing - tainting kernel
[    5.962949] nvidia-nvlink: Nvlink Core is being initialized, major 
device number 241
[    5.963181] NVRM: The NVIDIA probe routine was not called for 1 
device(s).

   NVRM: nouveau, rivafb, nvidiafb or rivatv
   NVRM: was loaded and obtained ownership of the NVIDIA 
device(s).

   NVRM: driver(s)), then try loading the NVIDIA kernel module
[    5.963182] NVRM: No NVIDIA graphics adapter probed!
[    6.005267] nvidia-nvlink: Unregistered the Nvlink Core, major device 
number 241
[    6.075128] nvidia-nvlink: Nvlink Core is being initialized, major 
device number 241
[    6.075448] NVRM: The NVIDIA probe routine was not called for 1 
device(s).

   NVRM: nouveau, rivafb, nvidiafb or rivatv
   NVRM: was loaded and obtained ownership of the NVIDIA 
device(s).

   NVRM: driver(s)), then try loading the NVIDIA kernel module
[    6.075449] NVRM: No NVIDIA graphics adapter probed!
[    6.097310] nvidia-nvlink: Unregistered the Nvlink Core, major device 
number 241


Apparently, the nvidia driver was loaded first, and after that, the 
nouveau driver took over.


Here is the "top" result, again with a permanent high CPU load for a 
kworker process:


# top
top - 19:50:57 up 18 min,  4 users,  load average: 1,26, 1,22, 0,93
Tasks: 198 total,   2 running, 196 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,0 us, 11,3 sy,  0,0 ni, 87,1 id,  0,0 wa,  0,0 hi, 1,6 si,  
0,0 st

MiB Mem :  15889,5 total,  13903,9 free,    808,5 used,   1177,0 buff/cache
MiB Swap:  0,0 total,  0,0 free,  0,0 used.  14617,1 avail Mem

  PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
   72 root  20   0   0  0  0 R  86,7   0,0 15:23.97 
kworker/7:1+pm
   47 root  20   0   0  0  0 S  13,3   0,0 2:52.21 
ksoftirqd/7

  684 root  20   0  505356 126896 102732 S   6,7   0,8 0:20.77 Xorg
    1 root  20   0  169624  10312   7880 S   0,0   0,1 0:01.34 systemd
    2 root  20   0   0  0  0 S   0,0   0,0 0:00.00 
kthreadd


Here is the stack of PID 72:

# cat /proc/72/stack
[<0>] 0x

The file with a few seconds tracing, cut after line 5000 and compressed, 
is attached as "out-no-nvidia.txt.gz".


Please, let me know, whether my way of not loading the nvidia driver was 
sufficient or not. If it is required to completely uninstall the Nvidia 
driver for a really untainted system, I will do it, but would need more 
time for this.


Regards,

Dirk.

Am 02.08.20 um 18:22 schrieb Salvatore Bonaccorso:


Hi Dirk,

On Sun, Aug 02, 2020 at 03:44:09PM +0200, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo

Hi Dirk

On Sun, Aug 02, 2020 at 10:00:27AM +0200, Dirk Kostrewa wrote:

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

Dear Maintainer,

after booting the kernel 4.19.0-10-amd64, there is a kworker process running
with a permanent high CPU load of almost 90% as reported by the "top"
command:

$ top
top - 09:48:19 up 0 min,  4 users,  load average: 1.91, 0.58, 0.20
Tasks: 218 total,   2 running, 216 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.8 us, 12.4 sy,  0.0 ni, 84.5 id,  0.0 wa,  0.0

Bug#937490: pynifti: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Jul 10, 2020 at 01:08:44PM +0200, Andreas Tille wrote:
> On Mon, Jun 29, 2020 at 08:37:58PM +0200, Moritz Mühlenhoff wrote:
> > On Fri, Aug 30, 2019 at 07:34:39AM +, Matthias Klose wrote:
> > 
> > The upstream homepage states
> > 
> > | PyNIfTI is no longer actively developed. At has been
> > | superseded by NiBabel -- a pure-Python package that
> > | provides everything that PyNIfTI could do, and a lot more.
> > 
> > Given that nibabel is packaged, let's simply remove pynifti?
> 
> Same answer from my side as for mrtrix - from my point of
> view it can go.

Michael/Yaroslav, ping. Ack to remove pynifti from your end?

Cheers,
Moritz

Bug#966538: firefox-esr: Firefox accuses debian-9.13.0-amd64-netinst.iso of containing malware

[Thomas Schmitt]

Hi,

the counterpart of this bug, which is assigned to debian-cd is
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966608
  "debian-cd: Daily iso flagged as virus/malware by Firefox"
where the maintainer of the ISOs affirms
  "It *is* a false positive - we are happy
   that we do not have a problem with malware."
and reports
  "We've had a slew of similar complaints this week, all apparently
   triggered by Google's "safe browsing" service. We're trying to get it
   fixed at their end."

> This appears to be a bug with Firefox and possibly
> something about the Debian ISOs for some reason,

If the warning would only tell something about the location of the
suspicious bytes inside the ISOs.
Or if the warning would be repeatable. (Thanks for the screenshot)
I'll try with your ISO URL tomorrow in the hope to get the warning
again and to find some button ...

A Debian ISO consists of hard to fake .deb packages embedded in a jelly
of ISO 9660 metadata. This jelly further embraces data files (some executable
like vmlinuz) and a Master Boot Record with x86 machine code, which stems
from the SYSLINUX project.
The jelly is generated by my program xorriso. So i wonder whether its about
a particular Debian package, a file of other kind, the Master Boot Record,
or about some metadata.


Have a nice day :)

Thomas

Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package

[Helmut Grohne]

Hi Mike,

On Mon, Aug 03, 2020 at 05:39:23AM +0900, Mike Hommey wrote:
> I'd rather replace nss-config with upstream's.

Please don't. That makes nss-config subtly buggy. The upstream
nss-config simply calls into pkg-config. In particular, it uses the
unqualified pkg-config. So the behaviour of nss-config becomes dependent
on the architecture you install pkg-config. In practice that means that
means when you install libnss3-dev for a foreign architecture, it will
be broken. And that amounts to breaking cross builds.

Really, using upstream's is the worst of choices here. Even removing
nss-config entirely would be better as that'd force dependent packages
(of which there are about 12) to properly use pkg-config instead.

So no, please don't use upstream's nss-config.

Helmut

Bug#966812: keepass2: Keepass2 crashes at startup after system update

[Adilson dos Santos Dantas]

Package: keepass2
Version: 2.45+dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After update my system packages, keepas2 stops working. It simply crashes at
startup. Maybe is something related to libc6 with mono. I'm attaching the crash
report below to check if the problem is with current keepass packages or it is
something with mono runtime.

Best regards,

Adilson

adilsond@r2d2:~$ keepass2 
free(): double free detected in tcache 2

=
Native Crash Reporting
=
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=

=
Native stacktrace:
=
0x5609cf35fa15 - /usr/bin/cli : (null)
0x5609cf35fdac - /usr/bin/cli : (null)
0x5609cf30d605 - /usr/bin/cli : (null)
0x5609cf35efef - /usr/bin/cli : (null)
0x7fe6925bc140 - /lib/x86_64-linux-gnu/libpthread.so.0 : (null)
0x7fe692404cb1 - /lib/x86_64-linux-gnu/libc.so.6 : gsignal
0x7fe6923ee537 - /lib/x86_64-linux-gnu/libc.so.6 : abort
0x7fe692447728 - /lib/x86_64-linux-gnu/libc.so.6 : (null)
0x7fe69244ea1a - /lib/x86_64-linux-gnu/libc.so.6 : (null)
0x7fe692450015 - /lib/x86_64-linux-gnu/libc.so.6 : (null)
0x4179d31e - Unknown

=
Telemetry Dumper:
=
Pkilling 0x7fe67a30a700 from 0x7fe6923c4780
Could not exec mono-hang-watchdog, expected on path 
'/etc/../bin/mono-hang-watchdog' (errno 2)
Pkilling 0x7fe679f08700 from 0x7fe6923c4780
Pkilling 0x7fe6794fe700 from 0x7fe6923c4780
Pkilling 0x7fe67a109700 from 0x7fe6923c4780
Pkilling 0x7fe679d07700 from 0x7fe6923c4780
Pkilling 0x7fe6792fd700 from 0x7fe6923c4780
Pkilling 0x7fe682803700 from 0x7fe6923c4780
Entering thread summarizer pause from 0x7fe6923c4780
Finished thread summarizer pause from 0x7fe6923c4780.

Waiting for dumping threads to resume

=
External Debugger Dump:
=
[New LWP 9824]
[New LWP 9825]
[New LWP 9831]
[New LWP 9832]
[New LWP 9833]
[New LWP 9834]
[New LWP 9836]
[New LWP 9837]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fe6924941c7 in wait4 () from /lib/x86_64-linux-gnu/libc.so.6
  Id   Target Id  Frame 
* 1Thread 0x7fe6923c4780 (LWP 9823) "cli" 0x7fe6924941c7 in 
wait4 () from /lib/x86_64-linux-gnu/libc.so.6
  2Thread 0x7fe684bff700 (LWP 9824) "SGen worker" 0x7fe6925b77b2 in 
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
  3Thread 0x7fe682803700 (LWP 9825) "Finalizer"   0x7fe6925ba174 in 
do_futex_wait.constprop () from /lib/x86_64-linux-gnu/libpthread.so.0
  4Thread 0x7fe67a30a700 (LWP 9831) "cli" 0x7fe6925bb1bf in 
accept () from /lib/x86_64-linux-gnu/libpthread.so.0
  5Thread 0x7fe67a109700 (LWP 9832) "cli" 0x7fe6925b7ad8 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
  6Thread 0x7fe679f08700 (LWP 9833) "Thread Pool Wor" 0x7fe6925ba388 in 
do_futex_wait.constprop () from /lib/x86_64-linux-gnu/libpthread.so.0
  7Thread 0x7fe679d07700 (LWP 9834) "Thread Pool Wor" 0x7fe6925ba388 in 
do_futex_wait.constprop () from /lib/x86_64-linux-gnu/libpthread.so.0
  8Thread 0x7fe6794fe700 (LWP 9836) "Thread Pool Wor" 0x7fe6925ba388 in 
do_futex_wait.constprop () from /lib/x86_64-linux-gnu/libpthread.so.0
  9Thread 0x7fe6792fd700 (LWP 9837) "Thread Pool Wor" 0x7fe6925ba388 in 
do_futex_wait.constprop () from /lib/x86_64-linux-gnu/libpthread.so.0

Thread 9 (Thread 0x7fe6792fd700 (LWP 9837)):
#0  0x7fe6925ba388 in do_futex_wait.constprop () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7fe6925ba4b3 in __new_sem_wait_slow.constprop.0 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x5609cf564d71 in ?? ()
#3  0x5609cf5029d6 in ?? ()
#4  0x7fe6925b0ea7 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#5  0x7fe6924c6daf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 8 (Thread 0x7fe6794fe700 (LWP 9836)):
#0  0x7fe6925ba388 in do_futex_wait.constprop () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7fe6925ba4b3 in __new_sem_wait_slow.constprop.0 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x5609cf564d71 in ?? ()
#3  0x5609cf5029d6 i

Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load

[Dirk Kostrewa]

Hi Salvatore,

thank you for taking care of this!

I first did the tracing for a few seconds, and I have appended the 
compressed output "out.txt.gz", cut after line 5000, to this e-mail. 
Since some "nvidia"-related processes also appear, I want to inform you 
that I have an Optimus laptop where the Nvidia GPU renders images and 
the integrated Intel GPU sends the images to the monitor, just in case.


I also tried the stack trace, but was not sure, whether I did it right - 
so, this is what I did:


# top

top - 16:29:42 up 7 min,  3 users, load average: 1,82, 1,52, 0,80
Tasks: 200 total,   2 running, 198 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,5 us, 12,4 sy,  0,0 ni, 86,5 id,  0,0 wa, 0,0 hi,  0,5 si,  
0,0 st

MiB Mem :  15889,4 total,  13390,9 free,   1263,3 used, 1235,2 buff/cache
MiB Swap:  0,0 total,  0,0 free,  0,0 used. 14265,6 avail Mem

  PID USER  PR  NI    VIRT    RES    SHR S  %CPU %MEM TIME+ 
COMMAND
   70 root  20   0   0  0  0 R  84,0 0,0   6:23.39 
kworker/4:1+pm
   32 root  20   0   0  0  0 S  16,0 0,0   1:12.32 
ksoftirqd/4

  761 root  20   0  349132 104820  67088 S   3,7 0,6   0:21.44 Xorg
...

I saw the kworker process with PID 70 and thus looked at the stack of 
this process:


# cat /proc/70/stack
[<0>] usb_start_wait_urb+0x65/0x160 [usbcore]
[<0>] usb_control_msg+0xdd/0x140 [usbcore]
[<0>] set_port_feature+0x30/0x40 [usbcore]
[<0>] hub_suspend+0x1e3/0x250 [usbcore]
[<0>] usb_suspend_both+0x9d/0x230 [usbcore]
[<0>] usb_runtime_suspend+0x2a/0x70 [usbcore]
[<0>] __rpm_callback+0xc7/0x200
[<0>] rpm_callback+0x1f/0x70
[<0>] rpm_suspend+0x138/0x670
[<0>] __pm_runtime_suspend+0x41/0x80
[<0>] usb_runtime_idle+0x2d/0x40 [usbcore]
[<0>] __rpm_callback+0xc7/0x200
[<0>] rpm_idle+0xa5/0x310
[<0>] pm_runtime_work+0x73/0x90
[<0>] process_one_work+0x1a7/0x3a0
[<0>] worker_thread+0x30/0x390
[<0>] kthread+0x112/0x130
[<0>] ret_from_fork+0x35/0x40
[<0>] 0x

I hope, this was right. If I can give you any more information, please, 
let me know.


Regards,

Dirk.

Am 02.08.20 um 15:44 schrieb Salvatore Bonaccorso:

Control: tags -1 + moreinfo

Hi Dirk

On Sun, Aug 02, 2020 at 10:00:27AM +0200, Dirk Kostrewa wrote:

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

Dear Maintainer,

after booting the kernel 4.19.0-10-amd64, there is a kworker process running
with a permanent high CPU load of almost 90% as reported by the "top"
command:

$ top
top - 09:48:19 up 0 min,  4 users,  load average: 1.91, 0.58, 0.20
Tasks: 218 total,   2 running, 216 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.8 us, 12.4 sy,  0.0 ni, 84.5 id,  0.0 wa,  0.0 hi,  2.3 si,  0.0
st
MiB Mem :  15889.4 total,  14173.1 free,    889.3 used,    827.0 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.  14677.7 avail Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
    64 root      20   0       0      0      0 R  86.7   0.0 0:47.41
kworker/0:2+pm
     9 root      20   0       0      0      0 S  20.0   0.0 0:08.84
ksoftirqd/0
   364 root     -51   0       0      0      0 S   6.7   0.0 0:00.50
irq/126-nvidia
  1177 dirk      20   0 2921696 122848  94268 S   6.7   0.8 0:02.23 kwin_x11
     1 root      20   0  169652  10280   7740 S   0.0   0.1 0:01.56 systemd
     2 root      20   0       0      0      0 S   0.0   0.0 0:00.00 kthreadd
...

The expected result after booting the kernel 4.19.0-10-amd64 is a kworker
process with a CPU load close to 0%.

As a control, booting the previous kernel 4.19.0-9-amd64 does not show a
high CPU load for the kworker process. Instead, the kworker CPU load
reported by the "top" command is 0.0%.

Therefore, I suspect a bug in the kernel 4.19.0-10-amd64.

Neither "dmesg" nor "journalctl -b" show any messages containing "kworker".

I am using Debian/GNU Linux 10.5 with kernel 4.19.0-10-amd64 and libc6:amd64
2.28-10.

If you need more information, I would be happy to provide it.

To find out what could be the cause, could you have a look at
https://www.kernel.org/doc/html/latest/core-api/workqueue.html#debugging
this could help determining isolating why the kworker goes crazy.

Regards,
Salvatore


out.txt.gz
Description: application/gzip

Bug#966827: gst-plugins-ugly1.0: diff for NMU version 1.16.2-2.1

[Sebastian Ramacher]

Package: gst-plugins-ugly1.0
Version: 1.16.2-2
Severity: normal
Tags: patch pending

Dear maintainer,

since gst-plugins-ugly1.0 is currently involved in the x264 transition
and will also be part of the upcoming libcdio transition, I've prepared
an NMU for gst-plugins-ugly1.0 (versioned as 1.16.2-2.1) and uploaded it
to DELAYED/2. Please feel free to tell me if I should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru gst-plugins-ugly1.0-1.16.2/debian/changelog gst-plugins-ugly1.0-1.16.2/debian/changelog
--- gst-plugins-ugly1.0-1.16.2/debian/changelog	2019-12-09 11:04:15.0 +0100
+++ gst-plugins-ugly1.0-1.16.2/debian/changelog	2020-08-02 22:53:19.0 +0200
@@ -1,3 +1,13 @@
+gst-plugins-ugly1.0 (1.16.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Gianfranco Costamagna ]
+  * Add some dependencies on libregexp-assemble-perl, libimage-exiftool-perl,
+libfont-ttf-perl to fix a build failure (workaround for #963347)
+
+ -- Sebastian Ramacher   Sun, 02 Aug 2020 22:53:19 +0200
+
 gst-plugins-ugly1.0 (1.16.2-2) unstable; urgency=medium
 
   * Source-only re-upload.
diff -Nru gst-plugins-ugly1.0-1.16.2/debian/control gst-plugins-ugly1.0-1.16.2/debian/control
--- gst-plugins-ugly1.0-1.16.2/debian/control	2019-12-04 14:44:14.0 +0100
+++ gst-plugins-ugly1.0-1.16.2/debian/control	2020-08-02 22:53:19.0 +0200
@@ -28,7 +28,10 @@
libsidplay1-dev,
libtool (>= 2.2.6),
libx264-dev (>= 2:0.120),
-   pkg-config (>= 0.11.0)
+   pkg-config (>= 0.11.0),
+   libregexp-assemble-perl,
+   libimage-exiftool-perl,
+   libfont-ttf-perl
 Standards-Version: 3.9.3
 Vcs-Git: https://salsa.debian.org/gstreamer-team/gst-plugins-ugly1.0.git
 Vcs-Browser: https://salsa.debian.org/gstreamer-team/gst-plugins-ugly1.0/


signature.asc
Description: PGP signature

Bug#966813: e2fsprogs: FTBFS with GCC 10: multiple definition of ... due to -fno-common

[tytso]

On Sun, Aug 02, 2020 at 07:23:35PM +0200, Andreas Beckmann wrote:
> 
> e2fsprogs/experimental started to FTBFS when GCC 10 was made the default 
> compiler:
>

Thanks for the bug report.  This is fixed in e2fsprogs 1.45.6-1 by:

commit 336c440ccea8f94b0728f881cddee84f730e7cc7
Author: Lukas Czerner 
Date:   Mon Feb 10 16:24:59 2020 +0100

tst_libext2fs: Avoid multiple definition of global variables

gcc version 10 changed the default from -fcommon to -fno-common and as a
result e2fsprogs make check tests fail because tst_libext2fs.c end up
with a build error.

This is because it defines two global variables debug_prog_name and
extra_cmds that are already defined in debugfs/debugfs.c. With -fcommon
linker was able to resolve those into the same object, however with
-fno-common it's no longer able to do it and we end up with multiple
definition errors.

Fix the problem by using SKIP_GLOBDEFS macro to skip the variables
definition in debugfs.c. Note that debug_prog_name is also defined in
lib/ext2fs/extent.c when DEBUG macro is used, but this does not work even
with older gcc versions and is never used regardless so I am not going to
bother with it.

Signed-off-by: Lukas Czerner 
Reviewed-by: Eric Sandeen 
Signed-off-by: Theodore Ts'o 

It's just that the e2fsprogs/experimental hasn't been updated in a while.

The next time the e2fsprogs/experimental gets updated with a new test
version, this will no longer be a problem.

Cheers,

- Ted

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Thorsten Glaser]

On Sun, 2 Aug 2020, Ben Hutchings wrote:

> The RFC says that the IPV6_TCLASS option's value is an int, and that

for setsockopt (“option's”), not cmsg

> No, the wording is *not* clear.

Agreed.

So perhaps let’s try to find out what’s actually right…

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

Bug#966805: thunderbird: OAUTH2 no longer works ("NS_ERROR_NET_INADEQUATE_SECURITY" error)

[Carsten Schoenert]

Hello Andrea,

Am 02.08.20 um 16:26 schrieb Andrea Borgia:

Dear Maintainer,

after upgrading from package 68.10.0-1 to 68.11.0-1, I got a generic
login failure for my gmail account, which was already configured to
use OAUTH2 and worked fine. >
Then, I removed the saved password and tried again: this time I got a
more informative popup with an error message saying
"NS_ERROR_NET_INADEQUATE_SECURITY".


this is related to the http2 protocol which is used for Oauth. The root 
for this isn't Thunderbird but libnss3.
Thunderbird did not have a tight enough dependency on this library in 
testing, unstable but also in experimental.


For unstable I pushed a fixed version (see #966806).

As you opened this report against the version of Thunderbird in 
experimental I'll ket this report open until a fix is prepared, should 
be done by the next version for experimental.


You can fix your current problem by installing libnss3 from unstable.

--
Regards
Carsten

Bug#966649: [UDD] Upload_history table is currently empty

[Andreas Tille]

On Sun, Aug 02, 2020 at 04:09:49PM +0200, Lucas Nussbaum wrote:
> On 02/08/20 at 15:12 +0200, Andreas Tille wrote:
> > Hi,
> > 
> > an untested 2to3 port of UDD code is in python3 branch of
> > 
> >https://salsa.debian.org/qa/udd/-/tree/python3
> 
> ... but it does not include the script in question for this bug?

You mean munge_ddc.py?  Hmmm, I can not even find it in master branch?
I once branched master for a 2to3 run and I'm merging from time to time.
As I said most things (actually those I did not wrote on my own) are
untested.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package

[Mike Hommey]

On Sat, Aug 01, 2020 at 10:58:48PM +0200, Helmut Grohne wrote:
> Control: tags -1 + patch
> 
> On Wed, Jul 24, 2019 at 05:02:30PM +0800, Chen-Yu Tsai wrote:
> > libpng-dev takes care of (or works around) this by disabling the
> > --libdir feature of libpng-config, and removing the @libdir@ template.
> > 
> > Maybe the same could be done for libnss3-dev (and libnspr4-dev)?
> 
> I concur.
> 
> I checked that nss-config is the only file that breaks M-A:same (by
> comparing all instances for all architectures). I also checked that the
> --libdir support is the only reason for it to break M-A:same. Removing
> the support is sufficient. There is no need for issuing
> -L/usr/lib/ as that is on the default search path.
> 
> You can easily see on codesearch that nothing uses the --libdir option:
> https://codesearch.debian.net/search?q=%28nss-config%7CNSS_CONFIG%29.*--libdir&literal=0
> 
> I'm attaching a removal patch. Please consider applying it. Applying it
> also closes #963136.
> 
> Would you mind a NMU?

I'd rather replace nss-config with upstream's.

Mike

Bug#966825: transition: libcdio

[Gabriel F. T. Gomes]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: gabr...@debian.org, sergi...@debian.org, vasek.ge...@gmail.com
Severity: normal

Hi,

libcdio needs a transition (upstream bumped the SONAME without ABI break).

I built all the packages reported at:

  https://release.debian.org/transitions/html/auto-libcdio.html

using the following approach (on an up-to-date debian unstable machine):

  1. Fetch with: apt source 
  2. Build with sbuild on a sid chroot with libcdio-dev from experimental:
   sbuild \
 --extra-repository='deb http://deb.debian.org/debian experimental 
main' \
 --build-dep-resolver=aptitude \
 --add-depends="libcdio-dev (= 2.1.0-1)" \
 .dsc

These are the packages:

  audacious-plugins_4.0.4-1
  audiotools_3.1.1-1.1
  cdw_0.8.1-1
  clementine_1.4.0~rc1+git174-gcb64d9705+dfsg-2
  cmus_2.8.0-2
  daisy-player_11.7.3-1
  fuse-umfuse-iso9660_0.3-1.3
  gmerlin_1.2.0~dfsg+1-6.1
  gmerlin-avdecoder_1.2.0~dfsg-10
  gst-plugins-ugly1.0_1.16.2-2
  gvfs_1.44.1-1
  kodi_18.7+dfsg1-1
  libcddb_1.3.2-6
  libcdio_2.0.0-2
  libcdio-paranoia_10.2+2.0.0-1
  libdevice-cdio-perl_2.0.0-1
  mpd_0.21.22-1
  mplayer_1.3.0-8
  mpv_0.32.0-2
  pragha_1.3.4-2
  pycdio_2.1.0-1
  qmmp_1.3.1-1.1
  simpleburn_1.8.0-1
  tellico_3.3.1-1
  vcdimager_2.0.1+dfsg-3
  virtualjaguar_2.1.3-2
  xine-lib-1.2_1.2.10-4
  xmms2_0.8+dfsg-20

All built OK, except for:

  gst-plugins-ugly1.0
  mplayer
  kodi

The problem with them is not related to libcdio:

  * gst-plugins-ugly1.0:
- currently FTBFS (https://bugs.debian.org/963347).
- building from experimental (version 1.17.2-1) works OK.

  * mplayer:
- builds OK but hangs on lintian (troff process using 100% cpu).
- killing the troff process lets the build finish successfully.

  * kodi:
- not in testing.

According to

  grep-dctrl -FBuild-Depends libcdio-dev -w -sPackage 
/var/lib/apt/lists/*Sources

libcddb also build-depends on libcdio-dev, so I tested it using the
same approach and it builds OK, but the generated binary is not
actually linked against libcdio.


Ben file:

title = "libcdio";
is_affected = .depends ~ "libcdio18" | .depends ~ "libcdio19";
is_good = .depends ~ "libcdio19";
is_bad = .depends ~ "libcdio18";


Cheers,
Gabriel


pgp93twQNGASD.pgp
Description: OpenPGP digital signature

Bug#966826: RFS: libmobi/0.6-1 [ITP] -- Tools for handling Mobipocket/Kindle ebook format documents

[Bartek Fabiszewski]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libmobi":

* Package name: libmobi
   Version : 0.6-1
   Upstream Author : Bartek Fabiszewski 
* URL : https://github.com/bfabiszewski/libmobi
* License : LGPL-3+
* Vcs : https://salsa.debian.org/bfabiszewski/libmobi
   Section : libs

It builds those binary packages:

  libmobi0-tools - Tools for handling Mobipocket/Kindle ebook format documents
  libmobi0 - C library for handling Mobipocket/Kindle ebook format documents
  libmobi-dev - Development files for libmobi

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libm/libmobi/libmobi_0.6-1.dsc

Changes since the last upload:

libmobi (0.6-1) unstable; urgency=medium
.
   * Initial release. (Closes: #966677)

Regards,
Bartek Fabiszewski

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Ben Hutchings]

On Sun, 2020-08-02 at 19:29 +, Thorsten Glaser wrote:
> Ben Hutchings dixit:
> 
> >ip(7) also doesn't document IP_PKTOPIONS.
> 
> Hmm, I don’t use IP_PKTOPIONS though. I’m not exactly sure I found
> the correct place in the kernel for what I do.

The first instance of put_cmsg(...IP_TOS...) you found in
net/ipv4/ip_sockglue.c implements that socket option.

[...]
> >I see no point in changing the IPv6 behaviour: it seems to be
> >consistent with itself and with the standard
> 
> Not really: if the kernel writes an int and userspace reads
> its first byte, it only works by accident on little endian,
> but not elsewhere.

The RFC says that the IPV6_TCLASS option's value is an int, and that
"the first byte of cmsg_data[] will be the *first byte of the integer*
traffic class" (my emphasis).  We can infer from "the first byte of"
that cmsg_data[] will hold more than one byte.  And "the integer"
suggests that it's a C int, like the socket option.

> >so only risks breaking user-space that works today.
> 
> Hrm. It risks breaking userspace that reads an int. But the
> RFC clearly says it should read the first byte, not an int.
[...]

No, the wording is *not* clear.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.


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

Bug#516394: removal of djbdns ?

[Moritz Mühlenhoff]

Hi Peter,

On Mon, Jul 27, 2020 at 05:20:23PM +0300, Peter Pentchev wrote:
> Now... related to that. I am not sure whether Moritz Muehlenhoff, when
> reopening this bug, was aware of the fact that Dmitry Bogatov included
> two patches from Jeff King that address the cache poisoning attack -
> and actually, the patches were mentioned in this bug log by Matija Nalis
> back in 2010. Moritz, is it possible that you had missed the inclusion
> of these two patches, or do you believe that they, by themselves, are
> still not enough to address this problem? If so, that would indeed be
> kind of unfortunate, since it is my impression that these particular
> patches are considered the best way to handle this among users of
> Prof. Bernstein's software.

I only reopened the bug since there was a discussion on debian-devel about
the fact that bugs in removed-and-then-reintroduced packages don't get
automatically reopened and remembered that long-standing bug. The changelog
made by Dmitry Bogatov doesn't mention it either. If that specific bug is
believed to be fixed by these two patches, then I trust you on that. So
feel free to mark the bug as closed in 1:1.05-10, then.

The fact that djbdns has no active upstream is a different concern, though,
especially in the wake of the whole qmail disaster. Following it, Georgi 
Guninski
raised a few issues on oss-security e.g.
(https://www.openwall.com/lists/oss-security/2020/06/01/1) and without an
active upstream noone ever addressed or investigated them.

Cheers,
Moritz

Bug#962307: Fwd: Re: RFS: anymeal/1.5-1 [ITA] -- Cookbook database for storing recipes

[Jan Wedekind]

Hi Boyuan Yang,
Many thanks for reviewing the software. Thanks for forwarding the email.

1. I have changed the section to "utils" as suggested.

2. I have updated debian/copyrights with the copyright information for the 
two m4 files and also for the GoogleTest file.


3. I have cleaned up debian/changelog.

4. I have removed the override for dh_auto_install which was indeed 
unnecessary.


I have uploaded version 1.6 on mentors.debian.net:

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

The package can be downloaded as follows:

dget -x 
https://mentors.debian.net/debian/pool/main/a/anymeal/anymeal_1.6-1.dsc

Regards,
Jan Wedekind

On Wed, 29 Jul 2020, Boyuan Yang wrote:


I'm forwarding this message to you in case replying to the bug report solely
is not enough for you to receive the message.

--
Regards,
Boyuan Yang

Bug#966822: systemd: user-runtime-dir service crashes the kernel under SELinux

[Mart van de Wege]

On Sun, 2 Aug 2020 21:59:05 +0200
Michael Biebl  wrote:

> Am 02.08.20 um 21:41 schrieb Mart van de Wege:
> > Package: systemd
> > Version: 245.7-1
> > Severity: normal
> > 
> > With SELinux enabled (booting with selinux=1 security=selinux), as
> > soon as systemd wants to clean up /run/user/ for a session,
> > the kernel will oops, leaving the systemd-user-runtime-dir process
> > that's trying to clean up the directory in an uninterruptible sleep
> > (D) state. 
> 
> I fail to see how this is a systemd bug. This looks more like a kernel
> and/or Selinux issue to me.
> 
You have a point there. I selected systemd because it at first appeared
to be a systemd bug (process hangs), but of course, if it causes an
oops reliably with selinux enabled (which it does), it should be
retargeted to those packages.

Is that still possible, or should we close this one and let me refile?


Regards,

Mart 

Bug#966538: firefox-esr: Firefox accuses debian-9.13.0-amd64-netinst.iso of containing malware

[Triston Line]

Dear Maintainer & Thomas Schmitt,

I've found this bug report while looking for the reason behind my OpenSuse
Firefox 78.0.2esr package telling me that the debian-10.5.0-amd64-DVD-1.iso
is a virus containing harmful malware after attempting to download it from:
https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-10.5.0-amd64-DVD-1.iso
for the first time.

I've downloaded about 10 different Linux Distro ISOs before and after
downloading Debian 10, and none of them raised the war banner of Firefox
crying contagion. This appears to be a bug with Firefox and possibly
something about the Debian ISOs for some reason, though I rarely use
Firefox myself so this is the first I've noticed it happening.

Thank you for your time, I've attached a small 53KB screenshot, but I'm not
sure that #@bugs.debian.org allows attachments.

Triston Line

Bug#966824: pmake: no longer provides pmake binary

[Thorsten Glaser]

Package: pmake
Version: 20200710-5
Severity: normal

pmake lacks the pmake binary, breaking packages using it to build

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Bug#966823: python2-doc: trying to overwrite '/usr/share/doc/python2/README.Debian', which is also in package python2 2.7.17-2

[Simon McVittie]

Package: python2-doc
Version: 2.7.18-1
Severity: serious
Justification: Policy 7.6

> Preparing to unpack .../python2-doc_2.7.18-1_all.deb ...
> Unpacking python2-doc (2.7.18-1) over (2.7.17-2) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/python2-doc_2.7.18-1_all.deb (--unpack):
>  trying to overwrite '/usr/share/doc/python2/README.Debian', which is also in 
> package python2 2.7.17-2
> Errors were encountered while processing:
>  /var/cache/apt/archives/python2-doc_2.7.18-1_all.deb

If this file moved to python2 in 2.7.18-1 (perhaps as a result of the
debhelper compat bump), it probably needs a versioned Breaks/Replaces.

smcv

Bug#966822: systemd: user-runtime-dir service crashes the kernel under SELinux

[Michael Biebl]

Am 02.08.20 um 21:41 schrieb Mart van de Wege:
> Package: systemd
> Version: 245.7-1
> Severity: normal
> 
> With SELinux enabled (booting with selinux=1 security=selinux), as soon as 
> systemd wants 
> to clean up /run/user/ for a session, the kernel will oops, leaving the 
> systemd-user-runtime-dir process that's trying to clean up the directory in 
> an 
> uninterruptible sleep (D) state.
> 

I fail to see how this is a systemd bug. This looks more like a kernel
and/or Selinux issue to me.




signature.asc
Description: OpenPGP digital signature

Bug#672284: lintian: False positive: no-debian-copyright when packages supply debian/$pkgname.copyright

[Thorsten Glaser]

On Mon, 14 May 2012, Jakub Wilk wrote:

> But I always thought that we were supposed to documented license and
> copyright holders of all files in the _source_ package, so having

No.

The copyright file exists for the binary packages, and the binary
packages alone. ftpmasters require the complete copyright/licence
of the upstream sources to be present in the origtgz (I once had
one where the licence was not present in the tarball but added
in a debian diff; this was deemed inacceptable (mirrors must be
permitted to redistribute only a part), and debian/ is often not
even worth documenting.

I’ve had a package with a debian/copyright.in that copied, at
build time, the upstream copyright notice at the end. This was
deemed acceptable but not nice, and I ended up changing it to
doing to in the clean target (so the source package ships both
debian/copyright.in and debian/copyright) but this was strictly
for tooling/QA.

This is, by the way, one of the reasons why I think DEP 5 to be
complete nōnsense. It doesn’t fit the Debian model.

And yes, it’s completely acceptable to have diverging copyright
files between binary packages.

bye,
//mirabilos
-- 
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
   veni, vidi, fixi(t) ;-)

Bug#966712: statsmodels: debci tests fail

[Rebecca N. Palmer]

Control: severity -1 serious
Control: tags -1 fixed-upstream patch

test_full_output*:
https://github.com/statsmodels/statsmodels/issues/6771
test_plot:
https://github.com/statsmodels/statsmodels/commit/fa8739e9d2822fe985bc96cd31bb3eb568fd9dc7

Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3

[Bastian Germann]

On Sat, 1 Aug 2020 21:58:05 +0200 Gianfranco Costamagna
 wrote:
> nack.
> +Copyright 2010-2018 Adobe (http://www.adobe.com/), with Reserved Font Name 
> 'Source'. All Rights Reserved. Source is a trademark of Adobe in the United 
> States and/or other countries.
> +
> +This Font Software is licensed under the SIL Open Font License, Version 1.1.
>
> missing licenses

I added the missing licenses.

Bug#966821: lintian: false positive: copyright-without-copyright-notice in antimicro

[Thorsten Glaser]

Package: lintian
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

https://lintian.debian.org/sources/antimicro/2.23-2.html
(unsure which lintian version was used) triggers an FP on
copyright-without-copyright-notice as you can see on:
https://metadata.ftp-master.debian.org/changelogs//main/a/antimicro/antimicro_2.23-2_copyright

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libsereal-decoder-perl4.017+ds-1
ii  libsereal-encoder-perl4.017+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

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

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

-- no debconf information

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Thorsten Glaser]

Ben Hutchings dixit:

>ip(7) also doesn't document IP_PKTOPIONS.

Hmm, I don’t use IP_PKTOPIONS though. I’m not exactly sure I found
the correct place in the kernel for what I do.

On the sending side, I use setsockopt with either
IPPROTO_IP,IP_TOS or IPPROTO_IPV6,IPV6_TCLASS to
set the default traffic class on outgoing packets.

On the receiving side I use setsockopt with either
IPPROTO_IP,IP_RECVTOS or IPPROTO_IPV6,IPV6_RECVTCLASS
to set up the socket then recvmsg to get a cmsg(3) of
IPPROTO_IP,IP_TOS/IPPROTO_IPV6,IPV6_TCLASS from which
I read the traffic class octet.

These are where I believe I found inconsistencies
between code and documentation.

>Those are two different APIs though: recvmsg() for datagram sockets, vs
>getsockopt(... IP_PKTOPTIONS ...) for stream sockets.  They obviously
>ought to be consistent, but mistakes happen.

OK, I’m currently looking at the datagram case only.
This may change later if there’s enough time.

>I see no point in changing the IPv6 behaviour: it seems to be
>consistent with itself and with the standard

Not really: if the kernel writes an int and userspace reads
its first byte, it only works by accident on little endian,
but not elsewhere.

>so only risks breaking user-space that works today.

Hrm. It risks breaking userspace that reads an int. But the
RFC clearly says it should read the first byte, not an int.

>But you should know that the highest priority for Linux API
>compatibility is to avoid breaking currently working user-space.  That
>means that ugly and inconsistent APIs won't get fixed if it causes a
>regression for the programs people actually use.  If the API never
>worked like it was supposed to on some architectures, that's not a
>regression, and is lower priority.

This is why I just put this up for discussion instead of
requesting a specific change.

That being said, given that the IPv6 API is *only* documented
in the RFC and *not* documented in the Linux manpages…

(Perhaps codesearching for IPV6_TCLASS might also help.
It’s unclear how many users this has…)



In the end, what I really want, is clear documentation for
how I should implement the following file that it works on
Linux, and ideally also other systems implementing the RFC
API (FreeBSD supposedly does but needs testing):

https://github.com/tarent/ECN-Bits/blob/master/linux-c/lib/ecn.c

Given that there’s no documentation, trying to read the
coffee grounds from the kernel source, finding it doesn’t
even match the RFC (which, again, doesn’t match what itojun
proposed, for some reason), does not instigate trust in the
things I *think* I’ve found.

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

Bug#966705: elfutils introduced a bootstrap loop via libmicrohttpd-dev

[Mark Wielaard]

Hi Helmut,

On Sun, Aug 02, 2020 at 07:57:00PM +0200, Helmut Grohne wrote:
> I don't think that anything (in Debian) links
> libdebuginfod at present.

There is a list of programs here:
https://sourceware.org/elfutils/Debuginfod.html We hope it will be
used by any program that uses debuginfo.  Ask Frank said, we already
have a public server running that would make use with Debian debug
packages really easy.  Not all programs use/link to it directly, some
use it indirectly through other elfutils libraries or tools.  Which is
why at least the client library should not be disabled by default.

> I actually wonder more about why debuginfod must be merged into
> elfutils. To the uninitiated, it would seem that building debuginfod
> entirely separate should be possible. Simply separating debuginfod into
> a separate tarball (and source package in Debian) would have eliminated
> the need for the profile and --disable-debuginfod and likely more. Doing
> so might be difficult on the upstream side though and I'm not sure
> whether splitting debuginfod at release time would be practical. Very
> likely, you do have reasons for maintaining them together.

The reason is simply like any other code maintained together.  It is
developed, integrated and tested together.  The project as a whole
does releases every 3 or 4 months.  Splitting things up in separate
"releases" doesn't really seem that practical.

Cheers,

Mark

Bug#812228: Multi-Arch support for dh-python

[Kevin Wu]

Pinging this bug, any progress? It is blocking crossgrading with GNOME
installed (affects python3-pil and python3-cairo).

On Sat, 25 Aug 2018 22:38:22 +0300 Adrian Bunk  wrote:
> The correct approach is actually to disallow py{,3}compile in
> Multi-Arch: same packages.
>
> It does not even make much sense since it is not possible to install
> multiple architectures of the python interpreter at the same time,
> and in normal cases the package could just be binary-all.
>
> gir1.2-ibus-1.0 is a bit special for that, and the approach taken for
> that is to have no byte-compilation (and no python dependencies).
>
> The latter is not perfect, but seems to be acceptable for a very
> special situation (the python module is an optional part of an
> architecture-specific package). If anything should be improved
> on that, the python module should be split out of the package.
>
> cu
> Adrian
-- 
Best,
Kevin

Bug#949637: hub: New upstream release

[Matthew Gabeler-Lee]

On 2020-07-28 07:19, Simon Frei wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 22 Jan 2020 21:24:10 -0500 (EST) Matthew Gabeler-Lee
 wrote:

A quick followup: I was able to use gpb and a bit of editing to get a
package built locally that seems to work.

I have a guest account on salsa, and I'd be happy to submit that work
there, but given that work touches 3 branches (master, upstream,
pristine-tar), I'm not quite sure on the mechanics of that.


According to "Team Maintenance" in
https://go-team.pages.debian.net/packaging.html and the team being
listed as the maintainer of hub, it's fine for you to directly commit 
to

it. You'd have to request access to the go team. I'd be great if you
could do that. Otherwise I might want to try it myself, for which it
would be great to build on your work. However I wasn't able to find 
your

fork either from the hub repo nor your salsa profile. Would you mind
making your work available somehow?


I've pushed my work up to a fork on salsa:

https://salsa.debian.org/cheetah-guest/hub/-/compare/master...update-2.14.2
https://salsa.debian.org/cheetah-guest/hub/-/compare/upstream...upstream-update-2.14.2
https://salsa.debian.org/cheetah-guest/hub/-/compare/pristine-tar...pristine-tar-update-2.14.2

Feel free to use this as you wish. I've largely moved over from the hub 
tool to the newer gh tool (https://github.com/cli/cli) so I'm not likely 
to dig into this more any time soon.

Bug#966817: New dependency on lzip not documented in changelog

[Josh Triplett]

On Sun, Aug 02, 2020 at 11:14:06AM -0700, Felix Lechner wrote:
> On Sun, Aug 2, 2020 at 11:09 AM Josh Triplett  wrote:
> > lintian 2.86.0 introduces a new dependency on lzip, but does not
> > document that dependency in the changelog.
> 
> Lzip is used in checks/files/compressed/lz.pm but was never available.
> 
> More information about that check is in Bug#702545.

Ah, that makes sense.

> What is the proper remedy for your bug, please?

Just an entry in the 2.86.0 changelog along the lines of "Add missing
dependency on lzip, used to test for broken lzip files in packages."

Thanks,
Josh

Bug#908908: turn lvm2-dbusd Architecture: all

[Bastian Blank]

Hi Helmut

On Sun, Aug 02, 2020 at 07:25:50PM +0200, Helmut Grohne wrote:
> On Sun, Aug 02, 2020 at 06:15:39PM +0200, Bastian Blank wrote:
> > https://salsa.debian.org/lvm-team/lvm2/-/compare/master...lvmdbusd-arch-all
> Thank you very much for sitting down and implementing this.
> This looks good to me. It definitely solves the problem that I reported.
> I do like your technique of doing multi-flavour builds with debhelper.

It solves on thing that does not really survive the sniff test:
configuring the build differently between all-only and any+all.  While
it does not produce any differences right now, this might change in the
future and will be really hard to detect, as at least I don't do both
kinds of builds.

Regards,
Bastiaqn

-- 
No one wants war.
-- Kirk, "Errand of Mercy", stardate 3201.7

Bug#966705: elfutils introduced a bootstrap loop via libmicrohttpd-dev

[Helmut Grohne]

On Sun, Aug 02, 2020 at 06:41:33PM +0200, Mark Wielaard wrote:
> If it is convenient for Debian we can do a 0.181 release to make this
> official.

Thank you for the offer. I don't think that anything (in Debian) links
libdebuginfod at present. Therefore we'll just make the library and the
program optional with one flag (pkg.elfutils.nodebuginfod is what I
propose as build profile name).

We can revise build profiles at a later time if the need arises.

In general, I don't like stub libraries. Bootstrapping is hard and you
can easily get it wrong. A failure at one step sometimes manifests much
later. Therefore we compare bootstrap builds with native builds using
diffoscope. Having a stub library would show up as a giant difference.
I'm not saying this cannot be done. I just want to avoid doing it as
long as we can.

I actually wonder more about why debuginfod must be merged into
elfutils. To the uninitiated, it would seem that building debuginfod
entirely separate should be possible. Simply separating debuginfod into
a separate tarball (and source package in Debian) would have eliminated
the need for the profile and --disable-debuginfod and likely more. Doing
so might be difficult on the upstream side though and I'm not sure
whether splitting debuginfod at release time would be practical. Very
likely, you do have reasons for maintaining them together.

This kinda is the same situation with util-linux. Splitting the
libraries into a separate source tarball would make bootstrapping
easier. There seems to be a trend in fusing components together. This
also happened to udevd and systemd.

Helmut

Bug#908908: turn lvm2-dbusd Architecture: all

[Helmut Grohne]

Hi Bastian,

On Sun, Aug 02, 2020 at 06:15:39PM +0200, Bastian Blank wrote:
> > Trust me, the python bindings need to be droppable for lvm2. I gave you
> > a simple solution. I fear using build profiles will be slightly more
> > complex. Do you prefer that?
> 
> I have an even more complex variant, also making lvm2-dbusd arch-all and
> drop the build-deps for that.
> 
> https://salsa.debian.org/lvm-team/lvm2/-/compare/master...lvmdbusd-arch-all

Thank you very much for sitting down and implementing this.

This looks good to me. It definitely solves the problem that I reported.

I do like your technique of doing multi-flavour builds with debhelper.

Helmut

Bug#966819: lv2-c++-tools FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: lv2-c++-tools
Version: 1.0.5-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lv2-c++-tools fails to cross build from source, because it builds for
the build architecture. It has a ./configure script, but it doesn't
actually set up cross tools as debhelper expects. Thus when debhelper
runs make, it doesn't pass cross tools along. From a debhelper
perspective, this is more of a makefile build system than an autoconf
build system. Once we tell it, it passes cross tools.

Those are mostly picked up by the build system except for pkg-config. It
needs a little patch to honour the variables passed by dh_auto_build.

Please consider applying the attached patch.

Helmut
diff --minimal -Nru lv2-c++-tools-1.0.5/debian/changelog 
lv2-c++-tools-1.0.5/debian/changelog
--- lv2-c++-tools-1.0.5/debian/changelog2017-09-03 23:11:37.0 
+0200
+++ lv2-c++-tools-1.0.5/debian/changelog2020-08-02 10:18:55.0 
+0200
@@ -1,3 +1,12 @@
+lv2-c++-tools (1.0.5-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make pkg-config substitutable.
++ Let dh_auto_build pass cross tools to make via the makefile buildsystem.
+
+ -- Helmut Grohne   Sun, 02 Aug 2020 10:18:55 +0200
+
 lv2-c++-tools (1.0.5-4) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru lv2-c++-tools-1.0.5/debian/patches/cross.patch 
lv2-c++-tools-1.0.5/debian/patches/cross.patch
--- lv2-c++-tools-1.0.5/debian/patches/cross.patch  1970-01-01 
01:00:00.0 +0100
+++ lv2-c++-tools-1.0.5/debian/patches/cross.patch  2020-08-02 
10:18:46.0 +0200
@@ -0,0 +1,43 @@
+--- lv2-c++-tools-1.0.5.orig/Makefile
 lv2-c++-tools-1.0.5/Makefile
+@@ -7,6 +7,8 @@
+ PROGRAMS = lv2peg
+ DATAPACKS = lv2soname
+ 
++PKG_CONFIG ?= pkg-config
++
+ # The static plugin library with headers
+ liblv2-plugin_a_SOURCES = lv2plugin.cpp
+ liblv2-plugin_a_HEADERS = \
+@@ -30,7 +32,7 @@
+   lv2gui.hpp \
+   ../../headers/lv2_ui.h \
+   ../../headers/lv2_ui_presets.h
+-liblv2-gui_a_CFLAGS = `pkg-config --cflags gtkmm-2.4` -Iheaders
++liblv2-gui_a_CFLAGS = `$(PKG_CONFIG) --cflags gtkmm-2.4` -Iheaders
+ liblv2-gui_a_SOURCEDIR = libraries/lv2gui
+ liblv2-gui_a_INSTALLDIR = $(libdir)
+ 
+--- lv2-c++-tools-1.0.5.orig/Makefile.template
 lv2-c++-tools-1.0.5/Makefile.template
+@@ -432,9 +432,9 @@
+ 
+ # PKG-CONFIG DEPENDENCY CHECK
+ PKG_NAMES = $(filter-out =%,$(subst >, ,$(PKG_DEPS))) 
+-PKG_DEPDIRS = `pkg-config --cflags $(PKG_NAMES) 2> /dev/null`
++PKG_DEPDIRS = `$(PKG_CONFIG) --cflags $(PKG_NAMES) 2> /dev/null`
+ check-pkg-deps:
+-  @$(foreach pkg, $(PKG_DEPS), if pkg-config --atleast-version $(sort 
$(subst >=, ,$(pkg))) ; then true; else echo "*** You don't have $(pkg), which 
you need in order to build this software."; false; fi && ) true
++  @$(foreach pkg, $(PKG_DEPS), if $(PKG_CONFIG) --atleast-version $(sort 
$(subst >=, ,$(pkg))) ; then true; else echo "*** You don't have $(pkg), which 
you need in order to build this software."; false; fi && ) true
+ 
+ 
+ # TEST REPORT GENERATION
+@@ -479,7 +479,7 @@
+   @echo "c_compiler = \"$(shell $(CC) --version | head -n 1)\"" >> 
$(TESTREPORT)/info
+   @echo "cxx_compiler = \"$(shell $(CXX) --version | head -n 1)\"" >> 
$(TESTREPORT)/info
+   @echo >> $(TESTREPORT)/info
+-  @$(foreach pkgname, $(PKG_NAMES), echo "dependency.$(pkgname) = 
\""`pkg-config --modversion $(pkgname)`"\"" >> $(TESTREPORT)/info;)
++  @$(foreach pkgname, $(PKG_NAMES), echo "dependency.$(pkgname) = 
\""`$(PKG_CONFIG) --modversion $(pkgname)`"\"" >> $(TESTREPORT)/info;)
+   export LD_LIBRARY_PATH=$${LD_LIBRARY_PATH}$(LIBRARY_DIRS); \
+   for test in $(TESTS); do \
+ mkdir -p $(TESTREPORT)/$$test; \
diff --minimal -Nru lv2-c++-tools-1.0.5/debian/patches/series 
lv2-c++-tools-1.0.5/debian/patches/series
--- lv2-c++-tools-1.0.5/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ lv2-c++-tools-1.0.5/debian/patches/series   2020-08-02 10:16:36.0 
+0200
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru lv2-c++-tools-1.0.5/debian/rules 
lv2-c++-tools-1.0.5/debian/rules
--- lv2-c++-tools-1.0.5/debian/rules2017-09-03 23:00:59.0 +0200
+++ lv2-c++-tools-1.0.5/debian/rules2020-08-02 10:18:55.0 +0200
@@ -5,7 +5,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
 
 %:
-   dh $@ 
+   dh $@ --buildsystem=makefile
 
 override_dh_auto_configure:
./configure --prefix=/usr

Bug#966705: elfutils introduced a bootstrap loop via libmicrohttpd-dev

[Helmut Grohne]

On Sun, Aug 02, 2020 at 12:58:49PM +0200, Matthias Klose wrote:
> please send a patch to build without libdebuginfod/debuginfod.

Attached.

Helmut
diff --minimal -Nru elfutils-0.180/debian/changelog 
elfutils-0.180/debian/changelog
--- elfutils-0.180/debian/changelog 2020-07-16 19:34:22.0 +0200
+++ elfutils-0.180/debian/changelog 2020-08-02 14:43:31.0 +0200
@@ -1,3 +1,10 @@
+elfutils (0.180-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add pkg.elfutils.nodebuginfod build profile. (Closes: #966705)
+
+ -- Helmut Grohne   Sun, 02 Aug 2020 14:43:31 +0200
+
 elfutils (0.180-1) unstable; urgency=medium
 
   * Transfer to team maintenance, add Kurt Roeckx and myself as uploaders.
diff --minimal -Nru elfutils-0.180/debian/control elfutils-0.180/debian/control
--- elfutils-0.180/debian/control   2020-07-16 19:34:22.0 +0200
+++ elfutils-0.180/debian/control   2020-08-02 14:43:31.0 +0200
@@ -12,8 +12,8 @@
   libc6-dbg [powerpc powerpcspe ppc64 ppc64el armel armhf arm64 sparc64 
riscv64],
   flex, bison,
   pkg-config,
-  libarchive-dev,
-  libmicrohttpd-dev, libcurl4-gnutls-dev, libsqlite3-dev,
+  libarchive-dev ,
+  libmicrohttpd-dev , libcurl4-gnutls-dev 
, libsqlite3-dev ,
 Build-Conflicts: autoconf2.13
 Standards-Version: 4.5.0
 Section: libs
@@ -109,6 +109,7 @@
  This package contains development libraries and header files for libasm1.
 
 Package: libdebuginfod1
+Build-Profiles: 
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends},
@@ -121,6 +122,7 @@
  This library is part of elfutils.
 
 Package: libdebuginfod-dev
+Build-Profiles: 
 Section: libdevel
 Architecture: any
 Multi-Arch: same
@@ -132,6 +134,7 @@
  libdebuginfod1.
 
 Package: debuginfod
+Build-Profiles: 
 Section: devel
 Architecture: any
 Depends: libdebuginfod1 (= ${binary:Version}), ${shlibs:Depends}, 
${misc:Depends}
diff --minimal -Nru elfutils-0.180/debian/rules elfutils-0.180/debian/rules
--- elfutils-0.180/debian/rules 2020-07-16 19:34:22.0 +0200
+++ elfutils-0.180/debian/rules 2020-08-02 14:43:31.0 +0200
@@ -37,14 +37,15 @@
dh_testdir
dh_autoreconf
 ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
-   ./configure --enable-maintainer-mode
+   ./configure --enable-maintainer-mode --disable-debuginfod
$(MAKE) $(MAKEFLAGS)
$(MAKE) clean
 endif
CFLAGS="$(CFLAGS) -O3" CXXFLAGS="-fpermissive" CPPFLAGS="$(CPPFLAGS)" 
LDFLAGS="$(LDFLAGS)" \
./configure $(confflags) --prefix=/usr \
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
-   --program-prefix=eu- --disable-silent-rules
+   --program-prefix=eu- --disable-silent-rules \
+   --$(if $(filter 
pkg.elfutils.nodebuginfod,$(DEB_BUILD_PROFILES)),dis,en)able-debuginfod
 
 build: build-stamp
 build-stamp:  config.status

Bug#966820: libgc builds differently for cross/native

[Helmut Grohne]

Source: libgc
Version: 1:8.0.4-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libgc builds differently during a native build from a cross build. It
figures out whether -latomic_ops is needed by checking for compiler
intrinsics. Unfortunately, the check doesn't work during cross and libgc
is pessimistic. Therefore it always builds with the external
-latomic_ops during cross. This is an unwanted difference to native
builds for a number of architectures. The attached patch forces the
check to match the native behaviour for the relevant architectures.

Helmut
diff --minimal -Nru libgc-8.0.4/debian/changelog libgc-8.0.4/debian/changelog
--- libgc-8.0.4/debian/changelog2020-07-22 02:37:12.0 +0200
+++ libgc-8.0.4/debian/changelog2020-08-02 20:41:06.0 +0200
@@ -1,3 +1,11 @@
+libgc (1:8.0.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix cross/native difference: explicitly disable usage of
+-latomic_ops. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 02 Aug 2020 20:41:06 +0200
+
 libgc (1:8.0.4-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru libgc-8.0.4/debian/rules libgc-8.0.4/debian/rules
--- libgc-8.0.4/debian/rules2020-04-07 11:03:33.0 +0200
+++ libgc-8.0.4/debian/rules2020-08-02 20:41:04.0 +0200
@@ -7,6 +7,10 @@
 
 LDFLAGS += -pthread
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+ATOMIC_BUILTIN_ARCHS = alpha amd64 arm64 armel armhf hppa hurd-i386 i386 ia64 
kfreebsd-amd64 kfreebsd-i386 mips64el mipsel powerpc ppc64 ppc64el riscv64 
s390x x32
+endif
+
 %:
dh $@ --with pkgkde_symbolshelper,autoreconf
 
@@ -26,7 +30,8 @@
--datadir=\$${prefix}/share/doc \
--host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) \
-   --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
+   --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
+   $(if $(filter 
$(DEB_HOST_ARCH),$(ATOMIC_BUILTIN_ARCHS)),--with-libatomic-ops=none)
 
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 override_dh_auto_test:

Bug#966818: mark bsdmainutils Multi-Arch: foreign again

[Helmut Grohne]

Package: bsdmainutils
Version: 12.1.6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:calc src:ctfutils src:cvs src:fish src:libedit 
src:libstorj src:mksh src:mp3info src:mtree-netbsd src:nethack src:qsf 
src:rheolef src:slashem src:vg src:wav2cdr src:xmorph

Before being split, bsdmainutils used to be Multi-Arch: foreign. Its
dependencies are Multi-Arch: foreign now. Please add back Multi-Arch:
foreign to the transitional dummy package. It is not implied by
Architecture: all.

Helmut
diff --minimal -Nru bsdmainutils-12.1.6/debian/changelog 
bsdmainutils-12.1.6+nmu1/debian/changelog
--- bsdmainutils-12.1.6/debian/changelog2020-07-23 14:53:53.0 
+0200
+++ bsdmainutils-12.1.6+nmu1/debian/changelog   2020-08-02 20:15:54.0 
+0200
@@ -1,3 +1,10 @@
+bsdmainutils (12.1.6+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark bsdmainutils Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 02 Aug 2020 20:15:54 +0200
+
 bsdmainutils (12.1.6) unstable; urgency=medium
 
   * Fix version check that was too optimistic. (Closes: #965202)
diff --minimal -Nru bsdmainutils-12.1.6/debian/control 
bsdmainutils-12.1.6+nmu1/debian/control
--- bsdmainutils-12.1.6/debian/control  2020-07-20 18:46:02.0 +0200
+++ bsdmainutils-12.1.6+nmu1/debian/control 2020-08-02 20:15:53.0 
+0200
@@ -11,6 +11,7 @@
 
 Package: bsdmainutils
 Architecture: all
+Multi-Arch: foreign
 Section: oldlibs
 Depends: ${misc:Depends}, bsdutils (>= 3.0-0), debianutils (>= 1.8),
  bsdextrautils (>= 2.35.2-7), calendar, ncal

Bug#966815: RFS: localepurge/0.7.3.10 -- reclaim disk space by removing unneeded localizations

[Adam Borowski]

On Sun, Aug 02, 2020 at 06:43:17PM +0100, Miguel Figueiredo wrote:
>  * Package name: localepurge
>Version : 0.7.3.10

> Changes since the last upload:
> 
>  localepurge (0.7.3.10) UNRELEASED; urgency=high
>  .
>* Remove the cleanup of /usr/share/X11/locale/* for now as it introduced
>  breakage in several ways.  (Closes: #961641)
>* Convert fr.po to UTF-8.

Attempting to upload an "UNRELEASED" package is an autoreject.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
⠈⠳⣄

Bug#965370: RFS: wand/0.6.2-1 -- Python interface for ImageMagick library (Python 3)

[Adam Borowski]

On Mon, Jul 20, 2020 at 01:17:13PM +, Håvard Flaget Aasen wrote:
>  * Package name: wand
>Version : 0.6.2-1

> Changes since the last upload:
> 
>* New upstream version 0.6.2
>* Set upstream metadata fields: Bug-Submit.
>* Update salsa CI
>  - Watch all variations of reprotest.
>* Use spaces rather than tabs in d/copyright
>* Rebase patches
>* flask sphinx theme is now in the upstream repository
>  - Remove patch and lintian-override

Alas, it fails to build; during tests:

=== FAILURES ===
 test_artifacts 

def test_artifacts():
with Image(filename='rose:') as img:
img.artifacts['key'] = 'value'
assert 'date:create' in img.artifacts
assert img.artifacts['key'] == 'value'
assert img.artifacts['novalue'] is None
>   assert len(img.artifacts) > 0
E   AssertionError: assert 0 > 0
E+  where 0 = len()
E+where  = 
.artifacts

tests/image_properties_test.py:51: AssertionError
=== warnings summary ===
.pybuild/cpython3_3.8_wand/build/tests/color_test.py::test_user_error
  /<>/.pybuild/cpython3_3.8_wand/build/wand/color.py:113: 
OptionWarning: unrecognized color `not_a_color' @ 
warning/color.c/GetColorCompliance/1057
self.raise_exception()

-- Docs: https://docs.pytest.org/en/latest/warnings.html
= 1 failed, 538 passed, 7 skipped, 3 deselected, 2 xfailed, 1 warnings in 16.48 
seconds =


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
⠈⠳⣄

Bug#966537: ITP: tomboy-ng -- Cross Platform Notes

[Ben Hutchings]

On Thu, 2020-07-30 at 20:51 +1000, David Bannon wrote:
[...]
>  tomboy-ng is built, from the same source, to work with 32 or 64 bit
>  GTK2, Qt5 (64bit only) and a list including Windows, MacOS, Raspbian.
>  It can be built for GTK3 but not to a satisfactory standard as yet.

Gtk+ 2 is deprecated, and we should not add new applications using it.
So it sounds like the best option for now would be to build it with Qt
support only.  Why is that limited to 64-bit architectures?

>  A script exists that will convert the zip file downloaded from github
>  to a 'kit' ready for debuild.

Depending on what your script does, the 'kit' might not include what we
would consider the full source code.  The script itself would also need
to be made public, usually as part of the source package.

It is generally preferable for Debian source packages to start from a
tarball that exactly matches an upstream release.

>  A tomboy-ng binary install uses about 5Meg, in most systems little or
>  no additional packages are required.
>  Some issues remain about building in a manner appropriate for Debian.
>  Its not clear, at present, if tomboy-ng will build satisfactory using
>  the version of Lazarus in Buster.  Bullseye is fine.

In any case this will have to go into unstable first, and then (if all
goes well) it can go into bullseye and maybe buster-backports.  It
won't be added to buster as we don't add new applications to stable
releases.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.



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

Bug#966530: dak: Please CC WNPP bug in reject mails

[Ben Hutchings]

On Thu, 2020-07-30 at 11:01 +0200, Andreas Tille wrote:
[...]
> Hint:  Some UDD parsers contain code to parse a bug number from the
> latest changelog paragraph.  I'd volunteer to extract this code and
> attach to this bug report if this might be some contribution to solve
> this bug.
[...]

The bug list will already have been parsed and copied to the Closes
field of the .changes field, which dak (presumably) already loaded.  So
there should be no need for additional parsing.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.




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

Bug#957360: insighttoolkit4: ftbfs with GCC-10

[Étienne Mollier]

Hi Andreas,

Andreas Tille, on 2020-08-02 19:36:30 +0200:
> I've just uoloaded castxml 0.3.4.

Thank you for the swift upgrade of castxml.  I pulled your
changes on my machine and triggered a build of ITK with the
following constraint in the build dependencies:

castxml (>= 0.3.4),

I will push that change to salsa if I see the build succeed,
probably tomorrow morning given the build time, unless I can
get no sleep.

Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#966817: New dependency on lzip not documented in changelog

[Felix Lechner]

Hi Josh,

On Sun, Aug 2, 2020 at 11:09 AM Josh Triplett  wrote:
>
> lintian 2.86.0 introduces a new dependency on lzip, but does not
> document that dependency in the changelog.

Lzip is used in checks/files/compressed/lz.pm but was never available.

More information about that check is in Bug#702545.

What is the proper remedy for your bug, please?

Kind regards
Felix Lechner

Bug#966817: New dependency on lzip not documented in changelog

[Josh Triplett]

Package: lintian
Version: 2.86.0
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

lintian 2.86.0 introduces a new dependency on lzip, but does not
document that dependency in the changelog.

I found commit fa8fd784e98199476b9b1bf4756b87f9b9c26f2e, but that
doesn't explain what lintian actually uses lzip for.

Bug#964905: [Martin Tournoij] Re: GoatCounter port

[Antoine Beaupré]

Some more information about Debian packaging, from upstream.
-- 
For once you have tasted flight,
You will walk the earth with your eyes turned skyward;
For there you have been,
And there you long to return.
- Leonardo da Vinci


--- Begin Message ---
Also, I looked at your Debian package (things were getting very off-topic on
the Docker issue 😅) and I see you're building with Go 1.11, at least that's
that the path "/usr/lib/go-1.11" suggests.

Go 1.11 won't work correct since it requires some features in Go 1.13 or
newer. It looks like in GoatCounter 1.3 it'll kinda-work since it doesn't
use any of the new functions so no compile errors, but it does use:

return errors.Errorf("salt.Refresh: %w", err)

That "%w" will only work with Go 1.13 or newer, with older versions you'll
get some sort of inline error telling you that %w isn't recognized and that
there's extra data (i.e. the errors will look weird/wrong).

Also, the  reason you're getting this error:

anarcat@emma:dist(master)$ dh-make-golang estimate zgo.at/goatcounter
go get: 175.92 MiBpackage zgo.at/goatcounter/cmd/check
imports honnef.co/go/tools/code: cannot find package 
"honnef.co/go/tools/code" in any of:
/usr/lib/go-1.11/src/honnef.co/go/tools/code (from $GOROOT)
/tmp/dh-make-golang182190041/src/honnef.co/go/tools/code (from 
$GOPATH)

Is because it's using the latest master of the "honnef.co/go/tools"
dependency, rather than the 2020.1.4 tag in the go.mod file.

It's not really critical, as it's just the linter tool that goatcounter
uses. You don't need to build it.
--- End Message ---

Bug#966816: /lib/systemd/system/blk-availability.service:10: Neither a valid executable name nor an absolute path: ${exec_prefix}/bin/true

[Michael Biebl]

Package: lvm2
Version: 2.03.09-2
Severity: important
File: /lib/systemd/system/blk-availability.service

$ systemctl cat blk-availability.service
# /lib/systemd/system/blk-availability.service
[Unit]
Description=Availability of block devices
Before=shutdown.target
After=lvm2-activation.service iscsi-shutdown.service iscsi.service 
iscsid.service fcoe.service rbdmap.service
DefaultDependencies=no
Conflicts=shutdown.target

[Service]
Type=oneshot
ExecStart=${exec_prefix}/bin/true
ExecStop=/sbin/blkdeactivate -u -l wholevg -m disablequeueing -r wait
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target



ExecStart=${exec_prefix}/bin/true → This is obviously wrong.

Instead of fixing the path again ( I see there have been bugs in
that regard in the past already), you might consider dropping the
ExecStart= altogether. For Type=oneshot services, ExecStart= does not
need to be set.

When stopping the service, I also noticed
Aug 02 19:54:05 pluto blkdeactivate[42210]: /sbin/blkdeactivate: Zeile 345: 
/bin/sort: No such file or directory



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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.171-2
ii  dmsetup   2:1.02.171-2
ii  init-system-helpers   1.58
ii  libaio1   0.3.112-8
ii  libblkid1 2.36-2
ii  libc6 2.31-2
ii  libdevmapper-event1.02.1  2:1.02.171-2
ii  libreadline5  5.2+dfsg-3+b13
ii  libselinux1   3.1-2
ii  libsystemd0   246-1
ii  libudev1  246-1
ii  lsb-base  11.1.0

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.8.5-4

lvm2 suggests no packages.

-- no debconf information

Bug#965839: Is tk5 still useful? (Re: Bug#965839: tk5: Removal of obsolete debhelper compat 5 and 6 in bookworm)

[myon]

> The package tk5 uses debhelper with a compat level of 5 or 6,
> which is deprecated and scheduled for removal[1].

tk5 was last touched by a maintainer for lenny, and then two NMUs.

Is that software still useful? Should we remove the package?

The Icom R5 isn't sold anymore.

Christoph

Bug#950830: #950830 installation-reports: Preseeding language+country+locale not working in Buster

[john doe]

On 8/2/2020 3:10 PM, Holger Wansing wrote:

Hi,

one  wrote (7 Feb 2020 08:39:02):

d-i debian-installer/language   string en
d-i debian-installer/countrystring CH
d-i debian-installer/locale string en_US.UTF-8



From my testing this should be basically the correct parameters, however

when looking at
https://d-i.debian.org/doc/installation-guide/en.amd64/apbs04.html
there are just spaces between the fields, no tabs.

Maybe that's the problem?

Do you have a chance to give it a try?
(Maybe also try a bullseye image? However, the format of the preseeding
parameters did not change between Buster and Bullseye.)



For me the below preseed snippet works on Buster and Bullseye:

# The values can also be preseeded individually for greater flexibility.
d-i debian-installer/language string C
d-i debian-installer/country string EN
d-i debian-installer/locale string C
# Optionally specify additional locales to be generated.
d-i localechooser/supported-locales multiselect en_US.UTF-8, ...


--
John Doe

Bug#966814: cb2bib: frequent parallel FTBFS

[Adrian Bunk]

Source: cb2bib
Version: 2.0.0-1
Severity: serious
Tags: ftbfs patch
Control: block 964269 by -1

https://buildd.debian.org/status/logs.php?pkg=cb2bib&arch=mips64el

...
g++ -pipe -g -O2 -fdebug-prefix-map=/<>/debian/build/src=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++11 -Wall 
-Wextra -dM -E -o moc_predefs.h 
/usr/lib/mips64el-linux-gnuabi64/qt5/mkspecs/features/data/dummy.cpp
make[3]: *** No rule to make target 'libc2b.a', needed by '../bin/cb2bib'.  
Stop.
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory '/<>/debian/build/src'
make[2]: *** [Makefile:73: sub-src-make_first] Error 2
make[2]: *** Waiting for unfinished jobs
rm -f ../libc2b.a
ar cqs ../libc2b.a approximatePattern.o arxivXml.o authorString.o 
bibExtractor.o bibParser.o bibPreparser.o bibSearcher.o cb2bib_utilities.o 
collectionAnalyzer.o collectionIndex.o compositePattern.o coreBibParser.o 
crJson.o document.o documentCache.o documentParser.o heuristicBibParser.o 
idMaker.o journalDB.o metadataParser.o monthDB.o network.o networkQuery.o 
posTagger.o preprocess.o pubmedXml.o searchPattern.o settings.o 
substringMatcher.o texParser.o texToHtml.o triads.o wordMatcher.o wordPattern.o 
qrc_c2blib.o moc_bibExtractor.o moc_bibParser.o moc_bibPreparser.o 
moc_bibSearcher.o moc_coreBibParser.o moc_idMaker.o moc_metadataParser.o 
moc_network.o moc_networkQuery.o moc_preprocess.o moc_settings.o
make[3]: Leaving directory '/<>/debian/build/src/c2b'
make[2]: Leaving directory '/<>/debian/build'
dh_auto_build: error: cd debian/build && make -j4 returned exit code 2
make[1]: *** [debian/rules:21: override_dh_auto_build] Error 25


Ideally this should be fixed, but if it cannot easily be fixed
the following would be sufficiant as workaround:

--- debian/rules.old2020-08-02 06:44:16.845689557 +
+++ debian/rules2020-08-02 06:44:28.877655791 +
@@ -7,7 +7,7 @@
 BUILDDIR=$(CURDIR)/debian/build
 
 %:
-   dh $@ --parallel --buildsystem=qmake --builddirectory=$(BUILDDIR)
+   dh $@ --no-parallel --buildsystem=qmake --builddirectory=$(BUILDDIR)
 
 override_dh_auto_configure:
mkdir -p $(BUILDDIR) && \

Bug#966815: RFS: localepurge/0.7.3.10 -- reclaim disk space by removing unneeded localizations

[Miguel Figueiredo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "localepurge":

 * Package name: localepurge
   Version : 0.7.3.10
   Upstream Author : Miguel Figueiredo 
 * URL : https://salsa.debian.org/elmig-guest/localepurge
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/elmig-guest/localepurge
   Section : admin

It builds those binary packages:

  localepurge - reclaim disk space by removing unneeded localizations

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/localepurge/localepurge_0.7.3.10.dsc


Changes since the last upload:

 localepurge (0.7.3.10) UNRELEASED; urgency=high
 .
   * Remove the cleanup of /usr/share/X11/locale/* for now as it introduced
 breakage in several ways.  (Closes: #961641)
   * Convert fr.po to UTF-8.


--
Best regards / Melhores cumprimentos,

Miguel Figueiredo

Bug#966649: [UDD] Upload_history table is currently empty

[Lucas Nussbaum]

On 02/08/20 at 15:12 +0200, Andreas Tille wrote:
> Hi,
> 
> an untested 2to3 port of UDD code is in python3 branch of
> 
>https://salsa.debian.org/qa/udd/-/tree/python3

... but it does not include the script in question for this bug?

Lucas

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Ben Hutchings]

[The previous message is archived at .]

On Tue, 2020-07-28 at 20:31 +0200, Thorsten Glaser wrote:
> Package: src:linux
> Version: 5.7.6-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: t...@mirbsd.de
> 
> I’m using setsockopt to set the traffic class on sending and receive
> it in control messages on receiving, for both IPv4 and IPv6.
> 
> The relevant documentation is the ip(7) manpage and, because the ipv6(7)
> manpage doesn’t contain it, RFC3542.

ip(7) also doesn't document IP_PKTOPIONS.

[...]
> Same in net/ipv4/ip_sockglue.c…
> 
> int tos = inet->rcv_tos;
> put_cmsg(&msg, SOL_IP, IP_TOS, sizeof(tos), &tos);
> … in one place, but…
> 
> put_cmsg(msg, SOL_IP, IP_TOS, 1, &ip_hdr(skb)->tos);
> 
> … in ip_cmsg_recv_tos(), yielding inconsistent results for IPv4(!).

Those are two different APIs though: recvmsg() for datagram sockets, vs
getsockopt(... IP_PKTOPTIONS ...) for stream sockets.  They obviously
ought to be consistent, but mistakes happen.

[...]
> tl;dr: Receiving traffic class values from IP traffic is broken on
> big endian platforms.

Some user-space that uses getsockopt(... IP_PKTOPTIONS ...) for stream
sockets might be broken.

I searched for 'cmsg_type.*IP_TOS' on codesearch.debian.net, and found
only two instances where it was used in conjunction with IP_PKTOPTIONS.

libzorpll reads only the first byte (so is broken on big-endian):
https://sources.debian.org/src/libzorpll/7.0.1.0%7Ealpha1-1.1/src/io.cc/#L239

squid reads an int and then truncates it to a byte (so is fine):
https://sources.debian.org/src/squid/4.12-1/src/ip/QosConfig.cc/#L41

> I place the following suggestion for discussion, to achieve maximum
> portability: put 4 bytes into the CMSG for both IPv4 and IPv6, where
> the first and fourth byte are, identically, traffic class, second and
> third 0.
[...]

I see no point in changing the IPv6 behaviour: it seems to be
consistent with itself and with the standard, so only risks breaking
user-space that works today.

As for IPv4, changing the format of the IP_TOS field in the
IP_PKTOPIONS value looks like it would work for the two users found in
Debian.

But you should know that the highest priority for Linux API
compatibility is to avoid breaking currently working user-space.  That
means that ugly and inconsistent APIs won't get fixed if it causes a
regression for the programs people actually use.  If the API never
worked like it was supposed to on some architectures, that's not a
regression, and is lower priority.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.



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

Bug#318884: xfig: Xfig draws a figure 5 times on start-up

[Roland Rosenfeld]

Hi Greg!

On Mo, 18 Jul 2005, Greg Kochanski wrote:

> Package: xfig
> Version: 1:3.2.5-alpha5-3
> Severity: normal
> 
> If you take a complex drawing (I have one with nearly 10 elements),
> you'll notice that the drawing is placed on the screen five times
> during xfig start-up.This can take a while.

Seems I never saw such a complex drawing in xfig.  Could you please
check, whether this issue still persists with current version?  I
didn't notice this 5 times redrawing with the files that I found and
also via ssh -X over VDSL (which slows down the drawing) I noticed any
problems...

Maybe this was fixed in the meantime?

Greetings

Roland

Bug#965352: libopenmpi3: breaks tests in client programs

[Drew Parsons]

Source: openmpi
Followup-For: Bug #965352

It looks like ucx 1.8.1-2 has helped.  dolfin and scalapack are now
building. I'll upload a new version of scalapack to be certain.

mpi4py tests are still failing.

Bug#957360: insighttoolkit4: ftbfs with GCC-10

[Andreas Tille]

Hi Étienne,

thanks for checking this bug.

On Sun, Aug 02, 2020 at 05:35:21PM +0200, Étienne Mollier wrote:
> I saw the use of castxml 0.3.4 indeed helped
> with the ftbfs.  If I understood the situation properly, this
> means this issue will most likely be fixed by an update of
> castxml, which is still 0.3.3 in Sid for the moment.

I've just uoloaded castxml 0.3.4.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#966696: emacs Segmentation fault

[積丹尼 Dan Jacobson]

Regarding
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42676
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42677
etc.
Well if this is an libx11-6 bug, then patching just emacs won't fix the
(many more?) other packages this affects...

> "c" == cufalo   writes:
c> Reported also for libx11-6 at 
c> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966691

c> Anyway, thank you so much!

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[Udo Richter]

Confirming fixed in Debian 10.5 point release:

Bug is reproducible with kernel 4.19.0-9 running, not reproducible with
4.19.0-10 running. Tested via xdg-screensaver lock.

Bug#297768: xfig: "Save as" over an old .fig complains if that .fig happens to be empty

[Roland Rosenfeld]

Hi Helge!

On Mi, 02 Mär 2005, Helge Hafting wrote:

Seems, that I never fully understood your ticket before.
Shame on me, that I didn't respond earlier :-(
Today I read it again and tried out what you described.

> I tried to save over an existing file.fig
> That file.fig happened to be a zero-length file.
> Saving worked, but I was hampered because xfig popped up a message telling
> me that the file was an invalid .fig file.
> 
> Such a message is of course necessary when trying to open a file for use,
> but I wasn't doing that.  I believe xfig tried to open it for reading
> in order to provide a preview the way xfig usually does when selecting
> filenames.  

I think that xfig tries to help you on selecting the correct file to
overwrite.  For this it presents the preview of the file you are
overwriting (so you can decide whether it's it good idea to overwrite
the selected file).  If the file is empty or a FIG file (maybe someone
used the .fig suffix for a different type of file), it presents you a
popup telling you, that you selected a file that is not a FIG file.

From my point of view this is a good behavior.
Usually overwriting an existing file is not what you want especially
if this file seems to be a FIG file but isn't.  An additional alarm
popup sounds like a good idea to me here.

> It'd be much better if the preview simply fail silently, or the error
> message could be rendered in the window space set aside for preview
> when this happen.  There was no use for the message because _I_ wasn't
> trying to use the file contents at all - I wanted to overwrite it
> with something new.

Okay, you were knowing this, but is this the standard use case?  Do
you usually create an empty file to overwrite it?  For me an empty
file may be a hint that something went wrong before (maybe the disk is
full, so the file wasn't written before?), so I like the additional
hint, that something went wrong before.  If I don't need the popup,
it's easy to close it with one click.

> It was xfig itself who wanted a look at the file contents, not me.
> An error message in such a case is only annoying.  Popups are bad
> user interfaces at the best of times, but a chore when I not even
> have _use_ for the message.

I have use for this message :-)

Greetings
Roland

Bug#957959: wmxres: diff for NMU version 1.2-10.2

[Sudip Mukherjee]

Control: tags 957959 + patch
Control: tags 957959 + pending

Dear maintainer,

I've prepared an NMU for wmxres (versioned as 1.2-10.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should cancel it.

Added Doug Torrance in Cc as he intends to adopt this package.

--
Regards
Sudip

diff -Nru wmxres-1.2/debian/changelog wmxres-1.2/debian/changelog
--- wmxres-1.2/debian/changelog 2017-01-08 16:42:39.0 +
+++ wmxres-1.2/debian/changelog 2020-08-02 17:57:54.0 +0100
@@ -1,3 +1,10 @@
+wmxres (1.2-10.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957959)
+
+ -- Sudip Mukherjee   Sun, 02 Aug 2020 17:57:54 
+0100
+
 wmxres (1.2-10.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru wmxres-1.2/wmgeneral/wmgeneral.c wmxres-1.2/wmgeneral/wmgeneral.c
--- wmxres-1.2/wmgeneral/wmgeneral.c1999-11-13 15:11:18.0 +
+++ wmxres-1.2/wmgeneral/wmgeneral.c2020-08-02 14:16:24.0 +0100
@@ -45,6 +45,7 @@
 GC NormalGC;
 XpmIconwmgen;
 Pixmap pixmask;
+Display*display;
 
   /*/
  /* Mouse Regions */
diff -Nru wmxres-1.2/wmgeneral/wmgeneral.h wmxres-1.2/wmgeneral/wmgeneral.h
--- wmxres-1.2/wmgeneral/wmgeneral.h1998-06-20 10:44:45.0 +0100
+++ wmxres-1.2/wmgeneral/wmgeneral.h2020-08-02 14:15:52.0 +0100
@@ -21,7 +21,7 @@
  /* Global variable */
 /***/
 
-Display*display;
+extern Display *display;
 
   /***/
  /* Function Prototypes */

Bug#966813: e2fsprogs: FTBFS with GCC 10: multiple definition of ... due to -fno-common

[Andreas Beckmann]

Source: e2fsprogs
Version: 1.46~WIP.2019.10.03-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-10

Hi,

e2fsprogs/experimental started to FTBFS when GCC 10 was made the default 
compiler:

gcc -o tst_libext2fs  -Wl,-z,relro -Wl,-z,now -Wl,-rpath-link,../../lib -DDEBUG 
debug_cmds.o extent_cmds.o tst_cmds.o debugfs.o util.o ncheck.o icheck.o ls.o 
lsdel.o dump.o set_fields.o logdump.o htree.o unused.o e2freefrag.o filefrag.o 
extent_inode.o zap.o xattrs.o quota.o tst_libext2fs.o create_inode.o journal.o 
revoke.o recovery.o do_journal.o \
../../lib/libss.a -ldl ../../lib/libe2p.a  ../../lib/libsupport.a \
../../lib/libext2fs.a -lblkid  -luuid  -ldl \
../../lib/libcom_err.a -lpthread  -I ../../../../debugfs
/usr/bin/ld: 
tst_libext2fs.o:./debian/BUILD-STD/lib/ext2fs/../../../../lib/ext2fs/tst_libext2fs.c:33:
 multiple definition of `extra_cmds'; 
debugfs.o:./debian/BUILD-STD/lib/ext2fs/../../../../debugfs/debugfs.c:51: first 
defined here
/usr/bin/ld: 
tst_libext2fs.o:./debian/BUILD-STD/lib/ext2fs/../../../../lib/ext2fs/tst_libext2fs.c:31:
 multiple definition of `debug_prog_name'; 
debugfs.o:./debian/BUILD-STD/lib/ext2fs/../../../../debugfs/debugfs.c:52: first 
defined here
collect2: error: ld returned 1 exit status

More information about the corresponding GCC change can be found here:
https://gcc.gnu.org/gcc-10/porting_to.html
"Default to -fno-common"


Andreas


e2fsprogs_1.46~WIP.2019.10.03-1.log.gz
Description: application/gzip

Bug#966811: [Pkg-utopia-maintainers] Bug#966811: network-manager: unknown keys in /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf

[Michael Biebl]

Control: reassign -1 wpasupplicant

Am 02.08.20 um 18:42 schrieb Cesare Leonardi:
> Package: network-manager
> Version: 1.26.0-1
> Severity: normal
> 
> Running "NetworkManager --print-config" the following messages are printed:
> ---
> # WARNING: unknown key 'wifi.cloned-mac-address' in section 
> [device-mac-addr-change-wifi] of file 
> '/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf'
> # WARNING: unknown key 'ethernet.cloned-mac-address' in section 
> [device-mac-addr-change-wifi] of file 
> '/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf'
> ---
> 
> From NetworkManager.conf(5) seems those keys are valid in a connection
> section, not in a device section.
> 



$ dpkg -S /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf
wpasupplicant: /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf


Wrong package, so reassigning. Not sure if wpasupplicant should actually
override NM behaviour this way, tbh.



signature.asc
Description: OpenPGP digital signature

Bug#327596: xfig: incorrect grid lines

[Geert Uytterhoeven]

Hi Roland,

On Sun, Aug 2, 2020 at 6:44 PM Roland Rosenfeld  wrote:
> On So, 11 Sep 2005, Geert Uytterhoeven wrote:
> > Package: xfig
> > Version: 1:3.2.5-alpha5-4
> >
> > Whatever grid mode (except for NONE) I select, xfig always draws the
> > finest grid.
> >
> > The version in sarge (1:3.2.5-alpha5-3) also shows this behavior, while
> > it used to work fine 1 or 2 weeks ago.
>
> Sorry, it seems that I never understood and/or overlooked this bug
> report.
>
> I just tried this out with the current xfig version from Debian buster
> and it works as expected: All different grit variants can be selected
> and are shown.
>
> Could you please check, whether the issue is solved for you, too?

Works fine for me, too, with xfig 1:3.2.6a-2 in Ubuntu 18.04.4 LTS.
(If you really need this, I can verify with a "pure" Debian version in the
 coming days)

I'm still a regular xfig user, and can't even remember this issue,
so I assume it must have been fixed ages ago.  The changelog doesn't
mention a fix, though.

Thanks for closing soon ;-)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Bug#950830: #950830 installation-reports: Preseeding language+country+locale not working in Buster

[Holger Wansing]

Hi,

one  wrote (7 Feb 2020 08:39:02):
> d-i   debian-installer/language   string en
> d-i   debian-installer/countrystring CH
> d-i   debian-installer/locale string en_US.UTF-8

>From my testing this should be basically the correct parameters, however
when looking at
https://d-i.debian.org/doc/installation-guide/en.amd64/apbs04.html
there are just spaces between the fields, no tabs.

Maybe that's the problem?

Do you have a chance to give it a try? 
(Maybe also try a bullseye image? However, the format of the preseeding
parameters did not change between Buster and Bullseye.)


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#851639: ITP: alacritty -- A cross-platform, GPU-accelerated terminal emulator

[Rob Browning]

While I don't know much about alacritty, I just happended to notice that
the underlying issue might have been resolved a couple of days ago:

  https://github.com/alacritty/alacritty/issues/357

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#966705: elfutils introduced a bootstrap loop via libmicrohttpd-dev

[Mark Wielaard]

On Sun, 2020-08-02 at 07:17 -0400, Frank Ch. Eigler wrote:
> > please send a patch to build without libdebuginfod/debuginfod.
> 
> For distro bootstrapping purposes, elfutils can be built with a
> configure option that builds a libmicrohttpd- / libcurl- free set of
> stub binaries / libraries.  That should suffice to be able to build
> the buildroot of the distro.

0.180 comes with a simple --disable-debuginfod which will simply not
build the debuginfod server binary and libdebuginfod client library and
helper program. Which you could use during bootstrap. Afterwards you'll
need to build elfutils with --enable-debuginfod and rebuild everything
that depends on libdebuginfod.

After 0.180 was released two new configure flags --disable-
libdebuginfod and --enable-libdebuginfod=dummy were introduced to have
slightly more fine grained control over whether just the server or just
the client would be build:

commit f7f0cdc59a13780938ae3f578955737a75e60ea9
Author: Mark Wielaard 
Date:   Fri Jun 19 19:41:08 2020 +0200

debuginfod: Add --disable-libdebuginfod and --enable-libdebuginfod=dummy.

Make it possible to build just the debuginfod client or to create a
dummy libdebuginfod that doesn't link against libcurl. The dummy library
can be used for bootstrapping. For testing purposes you can also build
debuginfod against the dummy libdebuginfod but then the debuginfod
server will not be able to do delegation.

Signed-off-by: Mark Wielaard 

See also https://sourceware.org/bugzilla/show_bug.cgi?id=25509

You could use --enable-libdebuginfod=dummy and --disable-debuginfod
during bootstrap and then rebuild elfutils again with 
--enable-debuginfod and --enable-debuginfod after bootstrap. The
advantage of using --enable-libdebuginfod=dummy is that you do get an
abi compatible stub libdebuginfod which other programs can link to
(during bootstrap) so you don't have to rebuild the whole dependency
chain afterwards.

If it is convenient for Debian we can do a 0.181 release to make this
official.

Cheers,

Mark

Bug#327596: xfig: incorrect grid lines

[Roland Rosenfeld]

Hi Geert!

On So, 11 Sep 2005, Geert Uytterhoeven wrote:

> Package: xfig
> Version: 1:3.2.5-alpha5-4
> 
> Whatever grid mode (except for NONE) I select, xfig always draws the
> finest grid.
> 
> The version in sarge (1:3.2.5-alpha5-3) also shows this behavior, while
> it used to work fine 1 or 2 weeks ago.

Sorry, it seems that I never understood and/or overlooked this bug
report.

I just tried this out with the current xfig version from Debian buster
and it works as expected: All different grit variants can be selected
and are shown.

Could you please check, whether the issue is solved for you, too?

Greetings

Roland


signature.asc
Description: PGP signature

Bug#966716: initramfs-tools: update-initramfs fails with no conf.d/resume and veracrypt volume mounted

[Ben Hutchings]

Control: tag -1 moreinfo

On Sun, 2020-08-02 at 09:40 -0300, Tuco wrote:
> Package: initramfs-tools
> Version: 0.133+deb10u1
> Severity: important
> 
> Dear Maintainer,
> 
> update-initramfs failed during a system upgrade with the error:
> 
> > cryptsetup: WARNING: target "hdd500_crypt" not found in /etc/crypttab
> 
> where "hdd500_crypt" is my hdd, it contains /home and a small swap
> partition(less than my ram).

That's a warning from cryptsetup, not from initramfs-tools itself.
Was there anything else that indicated that update-initramfs failed?

> The system is installed in a ssd "ssd_crypt".
> In my experience this would make the system unbootable, it would loop on the
> message "vg1 not found", "vg1" is a lvm volume group
> whose physical volumes are just "hdd500_crypt". Fortunately I didn't reboot to
> find out.
> fstab and crypttab attached.
[...]

So you don't know whether update-initramfs actually failed?

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.




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

Bug#966716: /etc/crypttab was not attached

[mbcm]

For some reason reportbug didn't attach /etc/crypttab, here it is:
>ssd_crypt UUID=434f8213-2edf-4c4c-86c9-ca245efa618e none luks
>hdd500_crypt UUID=b700e76b-2edc-4837-b230-76c5c8656db1 none luks
As you can see, hdd500_crypt is indeed present.
-
Ignore the text below if you don't know what it is.
Ignore o texto abaixo se não sabe o que é.

PGP: 80F5 D236 E687 C7FE 83BC  F79E 2BBB 840F F7CD D956

Bug#966811: network-manager: unknown keys in /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf

[Cesare Leonardi]

Package: network-manager
Version: 1.26.0-1
Severity: normal

Running "NetworkManager --print-config" the following messages are printed:
---
# WARNING: unknown key 'wifi.cloned-mac-address' in section 
[device-mac-addr-change-wifi] of file 
'/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf'
# WARNING: unknown key 'ethernet.cloned-mac-address' in section 
[device-mac-addr-change-wifi] of file 
'/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf'
---

>From NetworkManager.conf(5) seems those keys are valid in a connection
section, not in a device section.

Cesare.


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-1
ii  libaudit11:2.8.5-3+b1
ii  libbluetooth35.50-1.2
ii  libc62.31-2
ii  libcurl3-gnutls  7.68.0-1+b1
ii  libglib2.0-0 2.64.4-1
ii  libgnutls30  3.6.14-2+b1
ii  libjansson4  2.13.1-1
ii  libmm-glib0  1.14.0-0.1
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-4+b1
ii  libnm0   1.26.0-1
ii  libpam-systemd   245.7-1
ii  libpsl5  0.21.0-1.1
ii  libreadline8 8.0-4
ii  libselinux1  3.1-2
ii  libsystemd0  245.7-1
ii  libteamdctl0 1.30-1
ii  libudev1 245.7-1
ii  libuuid1 2.36-1
ii  policykit-1  0.105-28
ii  udev 245.7-1
ii  wpasupplicant2:2.9.0-13

Versions of packages network-manager recommends:
ii  crda 4.14+git20191112.9856751-1
ii  dnsmasq-base [dnsmasq-base]  2.82-1
ii  iptables 1.8.5-2
ii  modemmanager 1.14.0-0.1
ii  ppp  2.4.7-2+4.1+deb10u1

Versions of packages network-manager suggests:
pn  isc-dhcp-client  
pn  libteam-utils

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=keyfile
[ifupdown]
managed=false
[keyfile]
unmanaged-devices=mac:64:70:02:2a:a9:c0;mac:9c:d6:43:00:b0:ea


-- no debconf information

Bug#966716: initramfs-tools: update-initramfs fails with no conf.d/resume and veracrypt volume mounted

[Tuco]

Package: initramfs-tools
Version: 0.133+deb10u1
Severity: important

Dear Maintainer,

update-initramfs failed during a system upgrade with the error:

>cryptsetup: WARNING: target "hdd500_crypt" not found in /etc/crypttab

where "hdd500_crypt" is my hdd, it contains /home and a small swap
partition(less than my ram).
The system is installed in a ssd "ssd_crypt".
In my experience this would make the system unbootable, it would loop on the
message "vg1 not found", "vg1" is a lvm volume group
whose physical volumes are just "hdd500_crypt". Fortunately I didn't reboot to
find out.
fstab and crypttab attached.

* What led up to the situation?
I deleted /etc/initramfs-tools/conf.d/resume and had a veracrypt(truecrypt
fork) volume mounted while calling update-initramfs -u -k all.
I did so because:
I don't use hibernation (my swap 4gb is smaller than my ram 16gb) and;
My ssd and hdd are encrypted with the same password, if I delete the resume
file I'm asked only once for the password at boot.

* What exactly did you do (or not do) that was effective (or
ineffective)?
I unmounted the truecrypt volume and/or re-created /etc/iniramfs-
tools/conf.d/resume (even with an invalid swap path it works).

* What was the outcome of this action?
I wouldn't expect update-initramfs -u -k all to fail just because there is no
resume partition set AND there is a veracrypt volume mounted.
A user could easily oversee this and accidentally make the system unbootable
during an upgrade just by having a veracrypt volume mounted.

* What outcome did you expect instead?
To always get an error(not an warning) when there is no resume device set or to
always get an error(not an warning) when there is a veracrypt volume mouted.



-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 39M Aug  2 09:06 /boot/initrd.img-4.19.0-10-amd64
-rw-r--r-- 1 root root 39M Aug  2 09:07 /boot/initrd.img-4.19.0-8-amd64
-rw-r--r-- 1 root root 39M Aug  2 09:07 /boot/initrd.img-4.19.0-9-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/vg0-root ro quiet

-- resume
RESUME=/dev/mapper/vg1-swap-- /proc/filesystems
ext3
ext2
ext4
vfat
xfs
fuseblk
jfs
msdos
minix
hfs
hfsplus
qnx4
ufs
btrfs

-- lsmod
Module  Size  Used by
btrfs1400832  0
zstd_compress 172032  1 btrfs
zstd_decompress81920  1 btrfs
xxhash 16384  2 zstd_compress,zstd_decompress
xor24576  1 btrfs
raid6_pq  122880  1 btrfs
ufs86016  0
qnx4   16384  0
hfsplus   118784  0
hfs69632  0
minix  40960  0
msdos  20480  0
jfs   208896  0
uas28672  0
usb_storage73728  3 uas
ctr16384  6
ccm20480  9
nft_chain_route_ipv416384  1
xt_CHECKSUM16384  1
nft_chain_nat_ipv4 16384  4
ipt_MASQUERADE 16384  3
nf_nat_ipv416384  2 ipt_MASQUERADE,nft_chain_nat_ipv4
tun49152  1
bridge188416  0
stp16384  1 bridge
llc16384  2 bridge,stp
devlink77824  0
fuse  122880  7
vboxnetadp 28672  0
vboxnetflt 32768  0
vboxdrv   491520  2 vboxnetadp,vboxnetflt
binfmt_misc20480  1
xfs  1458176  1
arc4   16384  2
snd_hda_codec_hdmi 57344  1
rtl8192cu  81920  0
rtl_usb24576  1 rtl8192cu
rtl8192c_common61440  1 rtl8192cu
nls_ascii  16384  1
nls_cp437  20480  1
rtlwifi98304  3 rtl8192c_common,rtl_usb,rtl8192cu
vfat   20480  1
fat86016  2 msdos,vfat
mac80211  835584  3 rtl_usb,rtl8192cu,rtlwifi
nf_log_ipv616384  0
cfg80211  774144  2 rtlwifi,mac80211
ip6t_REJECT16384  0
nf_reject_ipv6 16384  1 ip6t_REJECT
xt_hl  16384  0
ip6_tables 32768  0
ip6t_rt16384  0
eeepc_wmi  16384  0
asus_wmi   32768  1 eeepc_wmi
sparse_keymap  16384  1 asus_wmi
rfkill 28672  4 asus_wmi,cfg80211
video  45056  1 asus_wmi
wmi_bmof   16384  0
nvidia_drm 49152  5
drm_kms_helper208896  1 nvidia_drm
serio_raw  16384  0
edac_mce_amd   28672  0
drm   495616  8 drm_kms_helper,nvidia_drm
nf_log_ipv416384  0
nf_log_common  16384  2 nf_log_ipv4,nf_log_ipv6
ipt_REJECT 16384  2
nf_reject_ipv4 16384  1 ipt_REJECT
snd_hda_codec_realtek   122880  1
kvm_amd   106496  0
snd_hda_codec_generic86016  1 snd_hda_codec_realtek
xt_LOG 1638

Bug#966715: ospd-openvas.service should be started before gvmd.service

[Christian Fischer]

Package: src:ospd-openvas
Version: 1.0.1-1

Dear Maintainer,

currently the following patch [1] is applied to the ospd-openvas.service
systemd file so that it is started before the gvmd.service.

But as seen in the gvmd.service [2] the service is accessing the
following socket:

--osp-vt-update=/run/ospd/ospd.sock

which is provided by ospd-openvas. This means that the socket mentioned
in that parameter might not be available yet once the gvmd.service is
started. I'm not sure about the effects of this but i would change it so
that gvmd.service is started after ospd-openvas.service.

Regards,

[1]
https://salsa.debian.org/pkg-security-team/ospd-openvas/-/blob/3b9bfa913825606c1580694b8bf8b5f27b7da7d1/debian/patches/adapt-ospd-openvas.service.patch
[2]
https://salsa.debian.org/pkg-security-team/gvmd/-/blob/b1cf764952205dc9da6ccc0e58d05931f28204ac/debian/gvmd.service#L14