Bug#954828: use pkg-js-tools when node module is detected

[Pirate Praveen]

Package: debmake
Severity: wishlist
Version: 4.3.1-1

When a node module is detected, usually presense of package.json file, 
just add pkg-js-tools as a build dependency and use dh --with nodejs in 
rules and most of the things will be automated.


This is not strictly needed normally as we use npm2deb, but when I 
teach people packaging I introduce debmake and it'd be nice if debmake 
can do these small changes.

Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi

[Michael Biebl]

Am 24.03.20 um 06:37 schrieb Alkis Georgopoulos:
> On 3/24/20 5:22 AM, Michael Biebl wrote:
>> You should file a bug report against wpasupplicant.
>> Andrew, the wpasupplicant maintainer, is not reading network-manager bug
>> reports.
> 
> 
> Thank you Michael,
> 
> I was thinking of:
> 1) Getting feedback from someone affected by this bug (like me) that
> this patch indeed solves it, and then
> 2) Find out how to "reassign this issue to wpasupplicant instead of
> network-manager", without opening a new bug for the same issue and then
> having to manage two bugs...
> 
> Is that an appropriate approach?

I'd prefer a separate, new bug report against wpasupplicant.
The original bug report is about disabling mac randomization, so afaics
a different issue from yours.



signature.asc
Description: OpenPGP digital signature

Bug#954827: dh-make-perl: please install packages using apt instead of dpkg -i when possible

[Paul Wise]

Package: dh-make-perl
Version: 0.109
Severity: wishlist

Modern apt supports installing local packages like this:

   apt-get install ./foo.deb

It would be nice for dh-make-perl to support this (possibly also
aptitude too). Some situations might require different install tools so an 
option might be best. Using apt has the advantage of installing any extra 
dependencies that already exist in the Debian archive instead of failing the 
install. Allowing for use of aptitude has the advantage of a much more flexible 
dependency resolver for complicated installs.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 
'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages dh-make-perl depends on:
ii  debhelper  12.9
ii  dpkg-dev   1.19.7
ii  fakeroot   1.24-1
ii  libapt-pkg-perl0.1.36+b3
ii  libarray-unique-perl   0.08-2
ii  libclass-accessor-perl 0.51-1
ii  libconfig-ini-perl 1:0.025-1
ii  libconfig-model-dpkg-perl  2.132
ii  libdebian-source-perl  0.109
ii  libdpkg-perl   1.19.7
ii  libemail-address-xs-perl   1.04-1+b2
ii  libemail-date-format-perl  1.005-1
ii  libfile-which-perl 1.23-1
ii  liblist-moreutils-perl 0.416-1+b5
ii  libmodule-depends-perl 0.16-3
ii  libsoftware-license-perl   0.103014-2
ii  libtie-ixhash-perl 1.23-2
ii  libwww-mechanize-perl  1.96-1
ii  libwww-perl6.43-1
ii  libyaml-libyaml-perl   0.80+repack-2+b1
ii  libyaml-perl   1.30-1
ii  make   4.2.1-1.2
ii  perl   5.30.0-9
ii  pseudo [fakeroot]  1.9.0+git20190802+060058b-1

Versions of packages dh-make-perl recommends:
ii  apt   2.0.0
ii  apt-file  3.2.2
ii  git   1:2.25.1-1
ii  libdpkg-parse-perl0.03-2
ii  libmodule-build-perl  0.423100-1
pn  libsys-cpu-perl   
ii  pristine-tar  1.47

dh-make-perl suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#919387: autopkgtest: missing build dependency on sysvinit-utils

[Ritesh Raj Sarraf]

Hello Paul.

Sorry. I seem to have completely slipped to replying to the email.

On Sun, 2020-03-22 at 08:11 +0100, Paul Gevers wrote:
> Hi Ritesh
> 
> On Sun, 3 Mar 2019 12:50:09 +0100 Martin Pitt 
> wrote:
> > Hello Ritesh,
> > 
> > Ritesh Raj Sarraf [2019-01-15 18:15 +0530]:
> > > One of the build time test cases make a call to the pidof
> > > command.
> > > This command is provided through the sysvinit-utils package.
> > > 
> > > So, either the sysvinit-utils package needs to be added as a
> > > dependency
> > > or the test case be changed to get rid of the pidof call
> > 
> > sysvinit-utils is Priority: required and Essential: yes, so
> > certainly it
> > shouldn't be necessary to specify it? Adding it explicitly causes a
> > lintian
> > error:
> > 
> >E: autopkgtest source: build-depends-on-essential-package-
> > without-using-version build-depends: sysvinit-utils
> > 
> > so I don't want to do that.
> 
> Can you please comment? Otherwise I'd like to close this bug.
> 
So. We hit this issue when bootstrapping packages on our Debian
derivative distribution, where sysvinit-utils may not be present.

[  278s] test_unicode (__main__.NullRunner)
[  279s] Unicode test output ... ok
[  279s] test_unskippable (__main__.NullRunner)
[  280s] A non-skippable test fails with an exit status that happens ... ok
[  280s] test_versioned_depends (__main__.NullRunner)
[  281s] Depends: with versions ... ok
[  281s] 
[  281s] ==
[  281s] FAIL: test_timeout_no_output (__main__.NullRunner)
[  281s] handling test timeout for test without any output
[  281s] --
[  281s] Traceback (most recent call last):
[  281s]   File "tests/autopkgtest", line 871, in test_timeout_no_output
[  281s] self.assertEqual(subprocess.getoutput('pidof ' + procname), '')
[  281s] AssertionError: '/bin/sh: 1: pidof: not found' != ''
[  281s] - /bin/sh: 1: pidof: not found
[  281s] + 
[  281s] 
[  281s] 
[  281s] --
[  281s] Ran 74 tests in 133.631s
[  281s] 
[  281s] FAILED (failures=1, skipped=7)
[  281s] make[1]: *** [debian/rules:42: override_dh_auto_test] Error 1
[  281s] make[1]: Leaving directory '/usr/src/packages/BUILD'
[  281s] make: *** [debian/rules:28: build] Error 2
[  281s] dpkg-buildpackage: error: debian/rules build subprocess returned exit 
status 2
[  282s] 
[  282s] argon failed "build autopkgtest_5.10co1.dsc" at Tue Mar 24 05:43:22 
UTC 2020.
[  282s] 


But I think it is something for us to check as to how our build chroots
ended up avoiding the essential sysvinit-utils pacakge.

So yes, I think for this bug report, it can be closed given the
package's attributes are set correct.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#954826: libgcc-8-dev: depends on unavailable version of libgcc-s1

[Sven Joachim]

Package: libgcc-8-dev
Version: 8.4.0-2
Severity: grave

The latest version of gcc-8 is not installable because libgcc-8-dev
depends on libgcc-s1 (>= 1:8.4.0-2), but the version of libgcc-s1 in the
archive does not have an epoch and is therefore too low to fulfill this
requirement.

The same holds for libgcc-7-dev 7.5.0-6.

Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi

[Alkis Georgopoulos]

On 3/24/20 5:22 AM, Michael Biebl wrote:

You should file a bug report against wpasupplicant.
Andrew, the wpasupplicant maintainer, is not reading network-manager bug
reports.



Thank you Michael,

I was thinking of:
1) Getting feedback from someone affected by this bug (like me) that 
this patch indeed solves it, and then
2) Find out how to "reassign this issue to wpasupplicant instead of 
network-manager", without opening a new bug for the same issue and then 
having to manage two bugs...


Is that an appropriate approach?

Bug#954770: needrestart: notifications in kde desktop environment

[Ritesh Raj Sarraf]

On Tue, 2020-03-24 at 10:40 +0530, Ritesh Raj Sarraf wrote:
> On Mon, 2020-03-23 at 14:31 +0530, Ritesh Raj Sarraf wrote:
> > I have been trying to get notifications to work on my KDE desktop
> > 
> > environment. So far, I have not had any success.
> 
> So the DBUS USER SESSION feature has some assumption. Like, for the
> variable NR_SESSPPID, which is not working in my case.
> 
> rrs@priyasi:~$ sed -z -n s/^DBUS_SESSION_BUS_ADDRESS=//p
> "/proc/$NR_SESSPPID/environ"
> sed: can't read /proc//environ: No such file or directory
> 10:33 ♒ ॐ   ☹ 😟=> 2  
> 
> 

After I purged package dbus-user-session, it is working proper. So
either it needs a fix, or a documentation update.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#954770: needrestart: notifications in kde desktop environment

[Ritesh Raj Sarraf]

On Mon, 2020-03-23 at 14:31 +0530, Ritesh Raj Sarraf wrote:
> I have been trying to get notifications to work on my KDE desktop
> 
> environment. So far, I have not had any success.

So the DBUS USER SESSION feature has some assumption. Like, for the
variable NR_SESSPPID, which is not working in my case.

rrs@priyasi:~$ sed -z -n s/^DBUS_SESSION_BUS_ADDRESS=//p
"/proc/$NR_SESSPPID/environ"
sed: can't read /proc//environ: No such file or directory
10:33 ♒ ॐ   ☹ 😟=> 2  


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#954242: qgis-providers: postinst failure: free(): invalid pointer

[Sebastiaan Couwenberg]

On 3/23/20 8:21 PM, Piotr Engelking wrote:
> Sebastiaan Couwenberg :
> 
>> So for some reason not all packages in the qgis dependency chain that
>> were rebuilt for the proj transition were upgraded on your systems,
>> that's an unusual situation but not a bug in qgis.
> 
> The current version of libgeotiff5 in testing is 1.5.1-2, so it is not
> surprising it wasn't updated yet. If it needs to be updated for the
> current version of qgis to work, it needs to be listed as a dependency
> (by qgis or by one of the packages that qgis depends on). So yes, it is
> a bug (not necessarily in your package, it is hard for me to say which
> one is responsible here), see bullseye RC policy §2.

None of the packages involved in the proj transition have migrated to
testing yet, if you're using pinning you need to fix that. Get the
entire dependency chain of qgis from unstable, or none of it (at least
those involved in the proj transition).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#954825: gnome-boxes: Segmentation fault when "+" → "Create a Virtual Machine…" is selected

[Cody Brownstein]

Package: gnome-boxes
Version: 3.36.0-1
Severity: important

Dear Maintainer,

gnome-boxes crashes (segmentation fault) when "+" → "Create a Virtual
Machine…" is selected.

Here is the output I receive from gnome-boxes:

--- begin output from gnome-boxes ---

(gnome-boxes:26121): Gtk-WARNING **: 19:59:24.894: GtkFlowBox with a model will 
ignore sort and filter functions

(gnome-boxes:26121): Gtk-WARNING **: 19:59:24.895: GtkListBox with a model will 
ignore sort and filter functions

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.677: util-app.vala:194: Failed 
to find OS with id: 'http://redhat.com/rhel/8.1': Unknown OS ID 
'http://redhat.com/rhel/8.1'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.677: util-app.vala:194: Failed 
to find OS with id: 'http://redhat.com/rhel/8.1': Unknown OS ID 
'http://redhat.com/rhel/8.1'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.677: util-app.vala:194: Failed 
to find OS with id: 'http://fedoraproject.org/fedora/31': Unknown OS ID 
'http://fedoraproject.org/fedora/31'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.677: util-app.vala:194: Failed 
to find OS with id: 'http://fedoraproject.org/fedora/31': Unknown OS ID 
'http://fedoraproject.org/fedora/31'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.677: util-app.vala:194: Failed 
to find OS with id: 'http://fedoraproject.org/silverblue/31': Unknown OS ID 
'http://fedoraproject.org/silverblue/31'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.677: util-app.vala:194: Failed 
to find OS with id: 'http://fedoraproject.org/silverblue/31': Unknown OS ID 
'http://fedoraproject.org/silverblue/31'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.677: util-app.vala:194: Failed 
to find OS with id: 'http://ubuntu.com/ubuntu/19.10': Unknown OS ID 
'http://ubuntu.com/ubuntu/19.10'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.677: util-app.vala:194: Failed 
to find OS with id: 'http://ubuntu.com/ubuntu/19.10': Unknown OS ID 
'http://ubuntu.com/ubuntu/19.10'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.678: util-app.vala:194: Failed 
to find OS with id: 'http://endlessos.com/eos/3.7': Unknown OS ID 
'http://endlessos.com/eos/3.7'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.681: util-app.vala:194: Failed 
to find OS with id: 'http://endlessos.com/eos/3.7': Unknown OS ID 
'http://endlessos.com/eos/3.7'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.907: util-app.vala:194: Failed 
to find OS with id: 'http://redhat.com/rhel/8.1': Unknown OS ID 
'http://redhat.com/rhel/8.1'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.907: util-app.vala:194: Failed 
to find OS with id: 'http://fedoraproject.org/fedora/31': Unknown OS ID 
'http://fedoraproject.org/fedora/31'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.907: util-app.vala:194: Failed 
to find OS with id: 'http://fedoraproject.org/silverblue/31': Unknown OS ID 
'http://fedoraproject.org/silverblue/31'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.907: util-app.vala:194: Failed 
to find OS with id: 'http://ubuntu.com/ubuntu/19.10': Unknown OS ID 
'http://ubuntu.com/ubuntu/19.10'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:25.907: util-app.vala:194: Failed 
to find OS with id: 'http://endlessos.com/eos/3.7': Unknown OS ID 
'http://endlessos.com/eos/3.7'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:30.889: util-app.vala:194: Failed 
to find OS with id: 'http://redhat.com/rhel/8.1': Unknown OS ID 
'http://redhat.com/rhel/8.1'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:30.890: util-app.vala:194: Failed 
to find OS with id: 'http://fedoraproject.org/fedora/31': Unknown OS ID 
'http://fedoraproject.org/fedora/31'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:30.893: util-app.vala:194: Failed 
to find OS with id: 'http://fedoraproject.org/silverblue/31': Unknown OS ID 
'http://fedoraproject.org/silverblue/31'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:30.893: util-app.vala:194: Failed 
to find OS with id: 'http://ubuntu.com/ubuntu/19.10': Unknown OS ID 
'http://ubuntu.com/ubuntu/19.10'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:30.893: util-app.vala:194: Failed 
to find OS with id: 'http://endlessos.com/eos/3.7': Unknown OS ID 
'http://endlessos.com/eos/3.7'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:30.915: util-app.vala:194: Failed 
to find OS with id: 'http://redhat.com/rhel/8.1': Unknown OS ID 
'http://redhat.com/rhel/8.1'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:30.916: util-app.vala:194: Failed 
to find OS with id: 'http://fedoraproject.org/fedora/31': Unknown OS ID 
'http://fedoraproject.org/fedora/31'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:30.916: util-app.vala:194: Failed 
to find OS with id: 'http://fedoraproject.org/silverblue/31': Unknown OS ID 
'http://fedoraproject.org/silverblue/31'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:30.916: util-app.vala:194: Failed 
to find OS with id: 'http://ubuntu.com/ubuntu/19.10': Unknown OS ID 
'http://ubuntu.com/ubuntu/19.10'

(gnome-boxes:26121): Boxes-WARNING **: 19:59:30.916: u

Bug#879484: [Pkg-utopia-maintainers] Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi

[Michael Biebl]

Hi

Am 24.03.20 um 03:41 schrieb Alkis Georgopoulos:
> The two-liner patch made it upstream:
> 
> http://w1.fi/cgit/hostap/commit/?id=7546c489a95a033c78331915fcdfa0e6fd74d563
> 
> 
> It would be awesome if it was cherrypicked/backported, as it's rather
> significant and it solves this issue.

You should file a bug report against wpasupplicant.
Andrew, the wpasupplicant maintainer, is not reading network-manager bug
reports.

Regards



signature.asc
Description: OpenPGP digital signature

Bug#944913: [Python-modules-team] Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1

[Sandro Tosi]

On Sat, Feb 1, 2020 at 5:24 PM Adrian Bunk  wrote:
>
> On Wed, Jan 22, 2020 at 10:23:04AM +0200, Adrian Bunk wrote:
> > On Tue, Dec 24, 2019 at 10:18:37PM -0500, Sandro Tosi wrote:
> > > On Sun, Dec 22, 2019 at 4:22 PM Dmitry Shachnev  
> > > wrote:
> > >...
> > > > Recently your script bumped many Python 2 removal bugs to RC, with the
> > > > intention to accelerate porting those packages to Python 3 (or getting 
> > > > them
> > > > removed). Maybe better to wait a couple of months and then just upload 
> > > > new
> > > > Sphinx and break its Python 2 reverse build-dependencies?
> > >
> > > only 49 of those 100 blocked packages are currently RC, so it will
> > > take quite more time i suspect; also some of those packages are sphinx
> > > extensions, that will have to go at the same time as sphinx maybe?
> > >...
> >
> > Complete list of packages that currently still build depend on
> > python-sphinx in testing is below.
>
> Annotated current list below.

i've been working thru python-sphinx rdeps and the current list is:

Checking reverse dependencies...
# Broken Depends:
funkload: funkload-doc
sphinx-patchqueue: python-sphinx-patchqueue

# Broken Build-Depends:
brian: python-sphinx
dh-virtualenv: python-sphinx
dipy: python-sphinx (>= 1.0)
django-ratelimit: python-sphinx
funkload: python-sphinx
ganeti: python-sphinx (>= 1.0.7+dfsg)
ghc: python-sphinx
iptables-converter: python-sphinx
iptables-optimizer: python-sphinx (>= 1.2.3)
mini-buildd: python-sphinx (>= 1.1.3)
nipype: python-sphinx (>= 0.6)
pebl: python-sphinx
pycassa: python-sphinx
pymvpa2: python-sphinx
pynifti: python-sphinx
pypy: python-sphinx (>= 1.0.7+dfsg)
pypy3: python-sphinx (>= 1.0.7+dfsg)
python-neuroshare: python-sphinx (>= 1.0.7+dfsg)
python-pysqlite2: python-sphinx (>= 0.6.1)
python-versuchung: python-sphinx
renpy: python-sphinx
sphinx-patchqueue: python-sphinx
vmm: python-sphinx
xapian-bindings: python-sphinx

except for the list below, all of them are not in testing, so i will
simply ignore them as they are already RC and dont deserve to be
waited on for this migration

* ghc, just uploaded a fix
* pypy/pypy3, i'm in discussion with the maintainer, i think the
approach we're gonna use here is to drop the -doc packages: the code
for pypy is still python2 and the documentation build requires to
access some pypy modules, so it cant be migrated to python3 anytime
soon
* xapian-bindings is #953949: the maintainer needs a bit of nudging
,but most likely we can just remove the documentation from the
python-xapian package and call it a day.

with these results i think we are good to upload the latest,
python3-only, version of sphinx in unstable right now.

What do you think?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#953777: Incorrect fix [Was: php-doctrine-cache_1.10.0-4_source.changes ACCEPTED into unstable]

[David Prévot]

Control: reopen -1
Control: reassign -1 php-apcu
Control: found -1 5.1.18+4.0.11-1

Le 23/03/2020 à 09:13, Ondřej Surý a écrit :

> I disagree that all of the added dependencies are wrong.
[…] > The autopkgtest needs to at least depend on php-cli.

Yet, the autopkgtest does not call php-cli. Instead, it calls phpunit
(that, again, already depends on php-cli, php-xml, and php-mbstring). So
no, please revert that change at least in the VCS(s).

php-doctrine-cache works both with php7.3 (x)or php7.4, nothing to fix
there a priori.

> Also the dependencies are already tight

No, the problem you’re currently facing is that php-apcu can be
installed on testing, pulls some php7.4-* related packages, but does not
enforce running php7.4 (nor installing the other php7.4 extensions). You
should be able to fix it by adding a Break : php7.3-common to php-apcu
(so that php7.3 related packages can’t be installed, and the php7.4 gets
pulled instead).

Feel free to double check the failing autopkgtest logs linked from the
PTS .

> I already filled RoM bug against php7.3, that’s the ultimate fix for
> all failing autopkgtests

No it’s not, and can’t work anyway (removing php7.3 from unstable won’t
make it disappear from testing until a suitable replacement is ready,
but the autopkgtest regressions currently prevents php7.4 to migrate).
You may want to get in touch with the release team and ask them for an
exception to let all the php7.4 packages pass in one shot, but they may
ask you to add the Break previously suggested anyway first.

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#954824: chromium: Enable PipeWire support in WebRTC

[Jan Medlock]

Package: chromium
Version: 80.0.3987.149-1
Severity: wishlist

Dear Maintainer,
Please consider enabling PipeWire support for WebRTC to enable screen
sharing under Wayland.

See, for example:
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/oEtkQUfwcus

Thanks,
Jan Medlock

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

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

Versions of packages chromium depends on:
ii  chromium-common80.0.3987.149-1
ii  libasound2 1.2.2-2.1
ii  libatk-bridge2.0-0 2.34.1-3
ii  libatk1.0-02.34.1-1
ii  libatomic1 10-20200321-1
ii  libatspi2.0-0  2.36.0-2
ii  libavcodec-extra58 [libavcodec58]  7:4.2.2-1+b1
ii  libavformat58  7:4.2.2-1+b1
ii  libavutil567:4.2.2-1+b1
ii  libc6  2.30-2
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libcups2   2.3.1-11
ii  libdbus-1-31.12.16-2
ii  libdrm22.4.100-4
ii  libevent-2.1-7 2.1.11-stable-1
ii  libexpat1  2.2.9-1
ii  libflac8   1.3.3-1
ii  libfontconfig1 2.13.1-2+b1
ii  libfreetype6   2.10.1-2
ii  libgcc-s1  10-20200321-1
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-3
ii  libglib2.0-0   2.64.1-1
ii  libgtk-3-0 3.24.14-1
ii  libharfbuzz0b  2.6.4-1
ii  libicu63   63.2-3
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libjsoncpp11.7.4-3.1
ii  liblcms2-2 2.9-4+b1
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.25-1
ii  libnss32:3.50-1
ii  libopenjp2-7   2.3.1-1
ii  libopus0   1.3-1+b1
ii  libpango-1.0-0 1.42.4-8
ii  libpangocairo-1.0-01.42.4-8
ii  libpci31:3.6.4-1
ii  libpng16-161.6.37-2
ii  libpulse0  13.0-5
ii  libre2-5   20200101+dfsg-1
ii  libsnappy1v5   1.1.8-1
ii  libstdc++6 10-20200321-1
ii  libva2 2.7.0~pre1-1
ii  libvpx61.8.2-1
ii  libwebp6   0.6.1-2+b1
ii  libwebpdemux2  0.6.1-2+b1
ii  libwebpmux30.6.1-2+b1
ii  libx11-6   2:1.6.9-2
ii  libx11-xcb12:1.6.9-2
ii  libxcb11.13.1-5
ii  libxcomposite1 1:0.4.4-2
ii  libxcursor11:1.2.0-2
ii  libxdamage11:1.1.5-1
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxi6 2:1.7.9-1
ii  libxml22.9.10+dfsg-4
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  libxslt1.1 1.1.34-4
ii  libxss11:1.2.3-1
ii  libxtst6   2:1.2.3-1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  80.0.3987.149-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+5
ii  xdg-utils  1.1.3-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox   80.0.3987.149-1
ii  fonts-liberation   1:1.07.4-11
ii  gnome-shell [notification-daemon]  3.34.4-1
ii  libgl1-mesa-dri20.0.2-1
pn  libu2f-udev
ii  notification-daemon3.20.0-4
ii  system-config-printer  1.5.12-1
ii  upower 0.99.11-1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  10-20200321-1
ii  libc6   2.30-2
ii  libgcc-s1   10-20200321-1
ii  libstdc++6  10-20200321-1

-- no debconf information

Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi

[Alkis Georgopoulos]

The two-liner patch made it upstream:

http://w1.fi/cgit/hostap/commit/?id=7546c489a95a033c78331915fcdfa0e6fd74d563

It would be awesome if it was cherrypicked/backported, as it's rather 
significant and it solves this issue.

Bug#943097: fixed in ghc 8.8.3-1~exp1

[Sandro Tosi]

> All it would take to fix #943097 in unstable is to just replace
> python-sphinx with python3-sphinx: i just finished a test rebuild and
> the documentation builds just fine.
>
> I dont know what your plans are to upload the ghc version in
> experimental (with this fix) to unstable is, but if you want i can
> upload a really simple NMU to make the change above; this will allow
> to decrease the reverse dependencies of python-sphinx, so that we can
> remove it.

i've just uploaded ghc with the only change to replace python-sphinx
with python3-sphinx, commits in the team git repo -- thanks!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#954821: Regression: cannot use external drive using a JMicron JMS566 chipset

[Cyril Roelandt]

Package: linux-image-amd64
Version: 5.4.19-1
Severity: normal

Dear Maintainer,

I own a WD Blue 1TB hard drive that I use in combination with an Icy Box
IB-273StU3-B enclosure in order to plug it to my laptop using USB. It
worked fine with all the Linux versions I tried, up until 5.4.


Using Linux 5.3
---
Everything works as expected when I plug the drive:

# dmesg -T
[Sun Mar 22 23:48:39 2020] usb 2-2: new SuperSpeed Gen 1 USB device number 2 
using xhci_hcd
[Sun Mar 22 23:48:39 2020] usb 2-2: New USB device found, idVendor=357d, 
idProduct=7788, bcdDevice= 1.14
[Sun Mar 22 23:48:39 2020] usb 2-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[Sun Mar 22 23:48:39 2020] usb 2-2: Product: USB to ATA/ATAPI Bridge
[Sun Mar 22 23:48:39 2020] usb 2-2: Manufacturer: JMicron
[Sun Mar 22 23:48:39 2020] usb 2-2: SerialNumber: 74D7851513309E5
[Sun Mar 22 23:48:39 2020] usbcore: registered new interface driver usb-storage
[Sun Mar 22 23:48:39 2020] scsi host6: uas
[Sun Mar 22 23:48:39 2020] usbcore: registered new interface driver uas
[Sun Mar 22 23:48:39 2020] scsi 6:0:0:0: Direct-Access WDC WD10 
JPVT-00A1YT0 0114 PQ: 0 ANSI: 6
[Sun Mar 22 23:48:39 2020] sd 6:0:0:0: Attached scsi generic sg1 type 0
[Sun Mar 22 23:48:39 2020] sd 6:0:0:0: [sdb] Spinning up disk...
[Sun Mar 22 23:48:40 2020] ..ready
[Sun Mar 22 23:48:41 2020] sd 6:0:0:0: [sdb] 1953525168 512-byte logical 
blocks: (1.00 TB/932 GiB)
[Sun Mar 22 23:48:41 2020] sd 6:0:0:0: [sdb] 4096-byte physical blocks
[Sun Mar 22 23:48:41 2020] sd 6:0:0:0: [sdb] Write Protect is off
[Sun Mar 22 23:48:41 2020] sd 6:0:0:0: [sdb] Mode Sense: 53 00 10 08
[Sun Mar 22 23:48:41 2020] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, supports DPO and FUA
[Sun Mar 22 23:48:41 2020] sd 6:0:0:0: [sdb] Optimal transfer size 33553920 
bytes not a multiple of physical block size (4096 bytes)
[Sun Mar 22 23:48:41 2020]  sdb: sdb1
[Sun Mar 22 23:48:41 2020] sd 6:0:0:0: [sdb] Attached SCSI disk


Using Linux 5.4
---

# uname -a
Linux Susan 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux

# mkdir /tmp/mnt

# mount /dev/sdb1 /tmp/mnt
mount: /tmp/mnt: can't read superblock on /dev/sdb1.

# fsck -y /dev/sdb1
fsck from util-linux 2.34
e2fsck 1.45.6 (20-Mar-2020)
/dev/sdb1: clean, 2951657/61054976 files, 115035523/244190208 blocks

# dmesg -T 
[Mon Mar 23 18:43:06 2020] usb 3-2: new SuperSpeed Gen 1 USB device number 8 
using xhci_hcd
[Mon Mar 23 18:43:06 2020] usb 3-2: New USB device found, idVendor=357d, 
idProduct=7788, bcdDevice= 1.14
[Mon Mar 23 18:43:06 2020] usb 3-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[Mon Mar 23 18:43:06 2020] usb 3-2: Product: USB to ATA/ATAPI Bridge
[Mon Mar 23 18:43:06 2020] usb 3-2: Manufacturer: JMicron
[Mon Mar 23 18:43:06 2020] usb 3-2: SerialNumber: 74D7851513309E5
[Mon Mar 23 18:43:06 2020] usb 3-2: UAS is blacklisted for this device, using 
usb-storage instead
[Mon Mar 23 18:43:06 2020] usb-storage 3-2:1.0: USB Mass Storage device detected
[Mon Mar 23 18:43:06 2020] usb-storage 3-2:1.0: Quirks match for vid 357d pid 
7788: 480
[Mon Mar 23 18:43:06 2020] scsi host6: usb-storage 3-2:1.0
[Mon Mar 23 18:43:07 2020] scsi 6:0:0:0: Direct-Access WDC WD10 
JPVT-00A1YT0 0114 PQ: 0 ANSI: 6
[Mon Mar 23 18:43:07 2020] sd 6:0:0:0: Attached scsi generic sg1 type 0
[Mon Mar 23 18:43:07 2020] sd 6:0:0:0: [sdb] Spinning up disk...
[Mon Mar 23 18:43:08 2020] ..ready
[Mon Mar 23 18:43:09 2020] sd 6:0:0:0: [sdb] 1953525168 512-byte logical 
blocks: (1.00 TB/932 GiB)
[Mon Mar 23 18:43:09 2020] sd 6:0:0:0: [sdb] Write Protect is off
[Mon Mar 23 18:43:09 2020] sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
[Mon Mar 23 18:43:09 2020] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, supports DPO and FUA
[Mon Mar 23 18:43:09 2020]  sdb: sdb1
[Mon Mar 23 18:43:09 2020] sd 6:0:0:0: [sdb] Attached SCSI disk
[Mon Mar 23 18:43:30 2020] sd 6:0:0:0: [sdb] tag#0 FAILED Result: 
hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Mon Mar 23 18:43:30 2020] sd 6:0:0:0: [sdb] tag#0 Sense Key : Illegal Request 
[current] 
[Mon Mar 23 18:43:30 2020] sd 6:0:0:0: [sdb] tag#0 Add. Sense: Invalid field in 
cdb
[Mon Mar 23 18:43:30 2020] sd 6:0:0:0: [sdb] tag#0 CDB: Write(10) 2a 08 00 00 
08 00 00 00 08 00
[Mon Mar 23 18:43:30 2020] blk_update_request: critical target error, dev sdb, 
sector 2048 op 0x1:(WRITE) flags 0x20800 phys_seg 1 prio class 0
[Mon Mar 23 18:43:30 2020] Buffer I/O error on dev sdb1, logical block 0, lost 
sync page write
[Mon Mar 23 18:43:30 2020] EXT4-fs (sdb1): I/O error while writing superblock
[Mon Mar 23 18:43:30 2020] EXT4-fs (sdb1): mount failed

# lsusb 
Bus 003 Device 008: ID 357d:7788 Sharkoon QuickPort XT


Other considerations

This enclosure works as expected with another drive: I tried with an old
Fujitsu 250GB drive and was able to mount the partitions.

The WD drive works with a similar enclosure: the Icy Box IB-268U3-B
enclosure. It has

Bug#953873: Fix for issue #953873

[Mark Moll]

Fix is here:

https://github.com/ompl/ompl/commit/962961fb86a6395d14c35f655dc439377a0cfbec

Best,

Mark

Bug#954820: postfix's autopkgtest on arm64 is flaky; this is blocking e2fsprogs

[Theodore Y. Ts'o]

Package: postfix
Version: 3.5.0-1
Severity: normal

Postfix autopkgtest on arm64 seems to be super flakey.  This is
currently blocking e2fsprogs:

https://qa.debian.org/excuses.php?package=e2fsprogs
https://ci.debian.net/data/autopkgtest/testing/arm64/p/postfix/4630231/log.gz

This seems to be a fairly common occurence.  See the history here:

https://ci.debian.net/packages/p/postfix/testing/arm64/

The cause appears to be running out of pty's on the arm64 CI system,
plus postfix explicitly declaring a dependency on e2fsprogs due to its
use of chattr.

If you can't fix postfix's flaky autopkg test, can you please revert the
explicit dependency on e2fsprogs?

Many thanks!

- Ted

Bug#954819: lintian: Please update the old and ancient python-versions tags to warn about py3versions -r

[Scott Kitterman]

Package: lintian
Version: 2.59.0
Severity: normal
Tags: patch

Recently we've been seeing a number of autopkgtest failures related to
the python3.8 as default python3 transition due to use of py3versions -r
with no related X-Python3-Version field falling back to all supported
versions.  This is the correct behavior, but it has unfortunate
consequences.

I think it would be good to help mitigate future instances of these
problems if we addeed information to the tags to also check for
py3verions -r and see if it still gives what's needed for the package.

Please see the attached patch.  I'm not set on the wording, but I
believe it's in the ball park.

Scott K
diff -Nru lintian-2.59.0/debian/changelog lintian-2.59.0+/debian/changelog
--- lintian-2.59.0/debian/changelog 2020-03-22 16:22:08.0 -0400
+++ lintian-2.59.0+/debian/changelog2020-03-23 20:55:28.0 -0400
@@ -1,3 +1,10 @@
+lintian (2.59.0+) UNRELEASED; urgency=medium
+
+  * Update old and ancient python-version-field tag text to suggest also
+checking for incorrect use of py3verions -r 
+
+ -- Scott Kitterman   Mon, 23 Mar 2020 20:55:28 -0400
+
 lintian (2.59.0) unstable; urgency=medium
 
   [ Chris Lamb ]
diff -Nru lintian-2.59.0/tags/a/ancient-python-version-field.desc 
lintian-2.59.0+/tags/a/ancient-python-version-field.desc
--- lintian-2.59.0/tags/a/ancient-python-version-field.desc 2020-03-22 
16:22:08.0 -0400
+++ lintian-2.59.0+/tags/a/ancient-python-version-field.desc2020-03-23 
20:55:28.0 -0400
@@ -7,4 +7,7 @@
  associated Python version is satisfied by the current "oldstable"
  distribution of Debian and is therefore unnecessary.
  .
- Please remove or update the reference.
+ Please remove or update the reference.  If removing, please also check
+ for the use of py3versions -r in debian/control, debian/rules, and debian/
+ tests/.  Without an operative Python3-Version field py3versions will fall
+ back to all supported versions, which may not be appropriate.
diff -Nru lintian-2.59.0/tags/o/old-python-version-field.desc 
lintian-2.59.0+/tags/o/old-python-version-field.desc
--- lintian-2.59.0/tags/o/old-python-version-field.desc 2020-03-22 
16:22:08.0 -0400
+++ lintian-2.59.0+/tags/o/old-python-version-field.desc2020-03-23 
20:55:28.0 -0400
@@ -8,4 +8,7 @@
  distribution of Debian and may be unnecessary.
  .
  Please remove or update the reference. This warning should be ignored
- if you wish to support "sloppy" backports.
+ if you wish to support "sloppy" backports.If removing, please also check
+ for the use of py3versions -r in debian/control, debian/rules, and debian/
+ tests/.  Without an operative Python3-Version field py3versions will fall
+ back to all supported versions, which may not be appropriate.

Bug#954818: mirror submission for mirror.cloroformo.org

[Francisco]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.cloroformo.org
Type: leaf
Archive-architecture: amd64
Archive-http: /debian/
Maintainer: Francisco 
Country: ES Spain
Location: Merida
Comment: Homeserver 200Mbits




Trace Url: http://mirror.cloroformo.org/debian/project/trace/
Trace Url: 
http://mirror.cloroformo.org/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.cloroformo.org/debian/project/trace/mirror.cloroformo.org

Bug#951893: subversion FTBFS with swig 4.0.1

[James McCoy]

On Mon, Mar 23, 2020 at 12:50:42PM -0300, Lucas Kanashiro wrote:
> diff -Nru subversion-1.13.0/debian/control 
> subversion-1.13.0.new/debian/control
> --- subversion-1.13.0/debian/control  2020-01-19 10:59:14.0 -0300
> +++ subversion-1.13.0.new/debian/control  2020-03-23 11:39:46.474677200 
> -0300
> @@ -32,7 +32,7 @@
> rename,
> ruby,
> ruby-dev,
> -   swig,
> +   swig3.0,

I had forgotten that multiple versions of swig were still in the
archive.  This will work around the issue until next upstream release
happens.
> zlib1g-dev
>  Build-Conflicts: libsvn-dev (<< 1.13~)
>  Rules-Requires-Root: no
> diff -Nru subversion-1.13.0/debian/patches/fix-swig-ruby-includes.patch 
> subversion-1.13.0.new/debian/patches/fix-swig-ruby-includes.patch
> --- subversion-1.13.0/debian/patches/fix-swig-ruby-includes.patch 
> 1969-12-31 21:00:00.0 -0300
> +++ subversion-1.13.0.new/debian/patches/fix-swig-ruby-includes.patch 
> 2020-03-23 11:39:46.450677157 -0300
> @@ -0,0 +1,15 @@
> +Description: Do not include ruby include subdir which has headers that
> + clash with standard ones, such as assert.h.
> +Author: Dimitri John Ledkov 
> +
> +--- a/build/ac-macros/swig.m4
>  b/build/ac-macros/swig.m4
> +@@ -168,7 +168,7 @@
> + AC_CACHE_CHECK([for Ruby include path], [svn_cv_ruby_includes],[
> + if test -d "$rbconfig_rubyhdrdir"; then
> +   dnl Ruby >=1.9
> +-  svn_cv_ruby_includes="-I. -I$rbconfig_rubyhdrdir 
> -I$rbconfig_rubyhdrdir/ruby -I$rbconfig_rubyhdrdir/ruby/backward"
> ++  svn_cv_ruby_includes="-I. -I$rbconfig_rubyhdrdir 
> -I$rbconfig_rubyhdrdir/ruby/backward"

The use of /ruby looks like a very old change, which isn't needed
anymore.  I'll forward this upstream.

Thanks for the info and patches.  I'll get a new upload ready soon.

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

Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>

[James McCoy]

Looping in upstream:

On Sun, Mar 22, 2020 at 02:57:54PM +0100, Lucas Nussbaum wrote:
> Version: 1.3.9-8

This is the same version of the serf package that's been in Debian since
2019/12/31, so something else seems to have changed.

> [...]
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > [...]
> > Trailer-Test: f
> > 140691743627136:error:14095126:SSL routines:ssl3_read_n:unexpected eof 
> > while reading:../ssl/record/rec_layer_s3.c:302:
> > ..F...
> > 
> > There was 1 failure:
> > 1) test_ssltunnel_basic_auth_server_has_keepalive_off: 
> > test/test_context.c:2138: expected <0> but was <120199>

Running a bisect against what's changed in the archive, shows that the
test started failing when OpenSSL's version changed from 1.1.1d-2 to
1.1.1e-1.

Looking at OpenSSL's changelog, it seems this was a change on their end
that's affecting serf.

 Changes between 1.1.1d and 1.1.1e [17 Mar 2020]
  *) Properly detect EOF while reading in libssl. Previously if we hit an EOF
 while reading in libssl then we would report an error back to the
 application (SSL_ERROR_SYSCALL) but errno would be 0. We now add
 an error to the stack (which means we instead return SSL_ERROR_SSL) and
 therefore give a hint as to what went wrong.
 [Matt Caswell]

I guess serf needs to adapt to this change in behavior.

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

Bug#954272: slurmd: SLURM not working with OpenMPI

[Gennaro Oliva]

Hi Lars,

On Thu, Mar 19, 2020 at 03:16:15PM +0100, Lars Veldscholte wrote:
> A simple test like `srun hostname` works, even on multiple cores. However, 
> when trying to use MPI, it crashes with the following error message:
> 
> *** An error occurred in MPI_Init
> *** on a NULL communicator
> *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
> ***and potentially your MPI job)
> 
> This happens even in the most simple "Hello World" case, as long as the 
> program is MPI-enabled.
> 
> I am trying to use OpenMPI (4.0.2) from the Debian repositories. `srun --mpi 
> list` returns:
> 
> srun: MPI types are...
> srun: openmpi
> srun: pmi2
> srun: none
> 
> I have tried all options, but the result is the same in all cases.
> 
> Maybe this is user error, as this is my first time setting up SLURM, but I 
> have not been able to find any possible causes/solutions and I am kind of 
> stuck at this point.

I don't know why srun doesn't execute openmpi directly, and I'll try to
investigate this issue but as a workaround you can use both sbatch and
salloc as in [1]:

salloc -n 4 mpirun mympiprogram ...

or

sbatch -n 4 mympiprogram.sh

where mympiprogram.sh is something like:

#!/bin/sh
mpirun mympiprogram ...

Notice you don't need to specify the number of processes to mpirun, as
it takes it from SLURM.

[1] https://www.open-mpi.org/faq/?category=slurm

Best regards,
-- 
Gennaro Oliva

Bug#954792: xfsdump: xfsrestore does not recreate missing inventory information

[Nathan Scott]

On Tue, Mar 24, 2020 at 1:57 AM root  wrote:
> [...]
> I noticed this with xfsrestore 3.1.6 (on a Debian 9.12 host), then I git 
> cloned xfsdump-dev, built from source and observed the same behaviour in 
> xfsrestore 3.1.9.
>

Best to discuss this with the (upstream) XFS maintainers as it's not
something specific to the Debian packaging of xfsdump AFAICT.

cheers.

--
Nathan

Bug#954017: xscreensaver: epicycle screensaver braws part of its figure in black on black background

[James Youngman]

Apologies.   I had a missing build dependency.   Yes, this builds and
solves the problem.   At cb5f289d06418e1ab7c316c2d38ae960092bd7fe.

Bug#954817: linux-image-5.4.0-4-amd64: NULL pointer dereference in i915_active_acquire since Linux 5.4

[Tom Yang]

Package: src:linux
Version: 5.4.19-1
Severity: important
Tags: patch

Dear Maintainer,

Since kernel 5.4.x I am getting crashes during some graphic rendering poccess 
like playing videos. I found the following patch might fix this problem. 
The patch already got into kernel 5.5.x but still not into 5.4.x. Could you 
patch it into kernel 5.4.x? Or release the kernel 5.5 version? Thanks!

Patchwork: https://patchwork.freedesktop.org/patch/345789/?series=70930&rev=3
See also: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.5.y&id=e85ade1f50aae464ce196672faa7a099fd1721ed

-- Package-specific info:
** Version:
Linux version 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.4.0-4-amd64 
root=UUID=bc9fa405-daee-4f2a-a27a-44e1c0513187 ro quiet

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Mar 16 18:39:24 Server kernel: [606320.517436] BUG: kernel NULL pointer 
dereference, address: 0040

Mar 16 18:39:24 Server kernel: [606320.517453] #PF: supervisor read access in 
kernel mode

Mar 16 18:39:24 Server kernel: [606320.517454] #PF: error_code(0x) - 
not-present page

Mar 16 18:39:24 Server kernel: [606320.517455] PGD 0 P4D 0

Mar 16 18:39:24 Server kernel: [606320.517461] Oops:  [#1] SMP PTI

Mar 16 18:39:24 Server kernel: [606320.517469] CPU: 3 PID: 2072967 Comm: xfwm4 
Tainted: G  OE5.4.0-4-amd64 #1 Debian 5.4.19-1

Mar 16 18:39:24 Server kernel: [606320.517471] Hardware name: To Be Filled By 
O.E.M. To Be Filled By O.E.M./H310M-ITX/ac, BIOS P3.10 09/27>

Mar 16 18:39:24 Server kernel: [606320.517745] RIP: 
0010:i915_active_acquire+0x9/0x70 [i915]

Mar 16 18:39:24 Server kernel: [606320.517751] Code: 00 00 00 48 c7 46 58 00 00 
00 00 c7 46 38 00 00 00 00 48 c7 c6 0a a0 65 c0 e9 33 90 7>

Mar 16 18:39:24 Server kernel: [606320.517753] RSP: 0018:a06400e07a40 
EFLAGS: 00010286

Mar 16 18:39:24 Server kernel: [606320.517757] RAX:  RBX: 
8da74554f480 RCX: 

Mar 16 18:39:24 Server kernel: [606320.517759] RDX: 8da642d61200 RSI: 
8da74554f480 RDI: 0008

Mar 16 18:39:24 Server kernel: [606320.517760] RBP: 8da642d61200 R08: 
8da74a4db988 R09: 8da74a4db988

Mar 16 18:39:24 Server kernel: [606320.517761] R10: a000 R11: 
 R12: 0008

Mar 16 18:39:24 Server kernel: [606320.517763] R13: 0004 R14: 
8da642d61200 R15: 401c

Mar 16 18:39:24 Server kernel: [606320.517765] FS: 7f5f29303f00() 
GS:8da8a5f8() knlGS:

Mar 16 18:39:24 Server kernel: [606320.517767] CS: 0010 DS:  ES:  CR0: 
80050033

Mar 16 18:39:24 Server kernel: [606320.517767] CR2: 0040 CR3: 
79d4a006 CR4: 003606e0

Mar 16 18:39:24 Server kernel: [606320.517768] Call Trace:

Mar 16 18:39:24 Server kernel: [606320.517910] i915_active_ref+0x21/0x210 [i915]

Mar 16 18:39:24 Server kernel: [606320.518049] ? intel_fbc_deactivate+0x38/0x60 
[i915]

Mar 16 18:39:24 Server kernel: [606320.518182] 
i915_vma_move_to_active+0x6e/0xf0 [i915]

Mar 16 18:39:24 Server kernel: [606320.518371] 
i915_gem_do_execbuffer+0xc62/0x1520 [i915]

Mar 16 18:39:24 Server kernel: [606320.518404] ? _cond_resched+0x15/0x30

Mar 16 18:39:24 Server kernel: [606320.518416] ? mutex_lock+0xe/0x30

Mar 16 18:39:24 Server kernel: [606320.518439] ? 
unix_stream_read_generic+0x1f7/0x8f0

Mar 16 18:39:24 Server kernel: [606320.518456] ? __kmalloc_node+0x1f5/0x300

Mar 16 18:39:24 Server kernel: [606320.518636] 
i915_gem_execbuffer2_ioctl+0x1df/0x3d0 [i915]

Mar 16 18:39:24 Server kernel: [606320.518764] ? 
i915_gem_madvise_ioctl+0x13a/0x290 [i915]

Mar 16 18:39:24 Server kernel: [606320.518874] ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]

Mar 16 18:39:24 Server kernel: [606320.518904] drm_ioctl_kernel+0xaa/0xf0 [drm]

Mar 16 18:39:24 Server kernel: [606320.518912] drm_ioctl+0x208/0x390 [drm]

Mar 16 18:39:24 Server kernel: [606320.518936] ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]

Mar 16 18:39:24 Server kernel: [606320.518941] do_vfs_ioctl+0x40e/0x670

Mar 16 18:39:24 Server kernel: [606320.518944] ksys_ioctl+0x5e/0x90

Mar 16 18:39:24 Server kernel: [606320.518945] __x64_sys_ioctl+0x16/0x20

Mar 16 18:39:24 Server kernel: [606320.518947] do_syscall_64+0x52/0x160

Mar 16 18:39:24 Server kernel: [606320.518950] 
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Mar 16 18:39:24 Server kernel: [606320.518953] RIP: 0033:0x7f5f2a7dd497

Mar 16 18:39:24 Server kernel: [606320.518955] Code: 00 00 90 48 8b 05 f9 79 0c 
00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1>

Mar 16 18:39:24 Server kernel: [606320.518956] RSP: 002b:7ffc4b8c1ef8 
EFLAGS: 0246 ORIG_RAX: 0010

Mar 16 18:39:24 Server kernel: [606320.5

Bug#954778: linux-image-amd64: if using make bindeb-pkg there is a warning about the missing debug package

[Ben Hutchings]

Control: tag -1 upstream

On Mon, 2020-03-23 at 12:31 +0100, Reinhard Karcher wrote:
[...]
> I attach a patch to include the debug package in the
> control file only if it is built later

Please send the patch upstream (linux-kbu...@vger.kernel.org),
following instructions at
,
and cc this bug report (954...@bugs.debian.org).

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.



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

Bug#954017: xscreensaver: epicycle screensaver braws part of its figure in black on black background

[James Youngman]

It doesn't build at all for me.

horizon:~/packages/Xscreensaver/debian-salsa/xscreensaver$ fakeroot
./debian/rules binary
dh_testdir
dh_testroot
dh_prep
/usr/bin/make 
install_prefix=/home/james/packages/Xscreensaver/debian-salsa/xscreensaver/debian/tmp
\
GTK_DATADIR=/usr/share KDEDIR=/usr install
[...]
/usr/bin/install -c -m 644 zh_TW.gmo
/home/james/packages/Xscreensaver/debian-salsa/xscreensaver/debian/tmp/usr/share/locale/zh_TW/LC_MESSAGES/xscreensaver.mo
make[2]: Leaving directory
'/home/james/packages/Xscreensaver/debian-salsa/xscreensaver/po'
make[1]: Leaving directory
'/home/james/packages/Xscreensaver/debian-salsa/xscreensaver'
dh_installdirs -a
dh_installdocs -a
dh_installchangelogs -a
# Install .desktop files used by gnome-screensaver etc
mkdir -p debian/tmp/usr/share/applications/screensavers
cp debian/screensavers-desktop-files/*.desktop \
debian/tmp/usr/share/applications/screensavers/
for i in debian/tmp/usr/share/applications/screensavers/*; do \
cat debian/screensavers-desktop.stub >> ${i}; done
mv debian/tmp/usr/share/man/man6/xscreensaver-gl-helper.6x \
   debian/tmp/usr/share/man/man1/xscreensaver-gl-helper.1
mv: cannot stat
'debian/tmp/usr/share/man/man6/xscreensaver-gl-helper.6x': No such
file or directory
make: *** [debian/rules:101: binary-arch] Error 1
horizon:~/packages/Xscreensaver/debian-salsa/xscreensaver$ echo $?
2
horizon:~/packages/Xscreensaver/debian-salsa/xscreensaver$ find .
-name '*screensaver-gl-helper*'
./debian/tmp/usr/share/man/man6/xscreensaver-gl-helper.6
./debian/tmp/usr/bin/xscreensaver-gl-helper
./hacks/glx/xscreensaver-gl-helper.o
./hacks/glx/xscreensaver-gl-helper.man
./hacks/glx/xscreensaver-gl-helper
./hacks/glx/xscreensaver-gl-helper.c
horizon:~/packages/Xscreensaver/debian-salsa/xscreensaver$ cat .git/HEAD
ref: refs/heads/master
horizon:~/packages/Xscreensaver/debian-salsa/xscreensaver$ cat
.git/refs/heads/master
cb5f289d06418e1ab7c316c2d38ae960092bd7fe

On Mon, Mar 23, 2020 at 7:01 PM Tormod Volden  wrote:
>
> tag 954017 pending
> thanks
>
>
> Hi James,
>
> Thanks for the report. I suppose this was a bug in 5.42 that was fixed
> in 5.43. It would be nice if you can confirm this by trying our 5.43
> packaging from:
> https://salsa.debian.org/debian/xscreensaver
>
> Regards,
> Tormod
>
>
> On Sun, Mar 15, 2020 at 8:15 PM James Youngman wrote:
> >
> > Package: xscreensaver
> > Version: 5.42+dfsg1-1
> > Severity: normal
> >
> > If you look closely at the output of the epicycle screenhack, part of
> > each curve is drawn in black on black.  This seems most often to occur
> > at the part of the figure that is next the brightest drawn part.
> >
> > I built the pristine upstream xscreensaver-5.43 code (and ran it
> > without installing).  It does not exhibit this problem.

Bug#782636: fubar's 2020 Stimulus Package

[fubar Family]

At a hastily prepared press conference, babyjesus along with the rest of the 
fubar brain trust announced the fubar Stimulus Package:

"In these trying times we need to act quickly and compassioniately to offer aid 
to our fellow fubarians who are suffering through countless hardships."

The fubar Stimulus Package is available to every fubarian until April 22nd and 
contains:

* 10 free coins.
* 1 free Minirang Power-Up.
* 2020 fubar Stimulus Package achievement unlock.

Log in to fubar: 
https://fubar.com/recallclick.php?email=782...@bugs.debian.org&r=RubWFQAT6135adX%2FYPJSrPA89tkVq7A5.37

When asked by a reporter, "What do you say to the Americans who are scared 
right now?" babyjesus said, "We all need to stay calm, listen to the directions 
of our amazing healthcare professionals and take care of those close to us. Oh, 
and don't forget to rate and like back!!"



Download the fubar mobile app\n
Available at the App Store: 
https://itunes.apple.com/app/apple-store/id455311703?pt=395928&ct=email \n
Get it on Google Play: 
https://play.google.com/store/apps/details?id=com.fubar.mobile&referrer=utm_source%3Demail%26utm_medium%3Demail%26utm_campaign%3Demail



To stop receiving reminders from fubar, please adjust your email settings 
here:\n
$recall_link.2

Bug#746415: gnome-terminal: will not start with non-utf-8 locale

[Abou Al Montacir]

I was facing this issue and resolved it by changing the language in Gnome
settings as follows

The ossue was that Gnome was using a strange encoding that is not supported by
gnome terminal server.
-- 
Cheers,
Abou Al Montacir



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

Bug#954393: please Breaks: libc6-dev-${DEB_HOST_ARCH}-cross (<< ${CURRENT_UPSTREAM_VERSION})

[Aurelien Jarno]

On 2020-03-21 07:34, Helmut Grohne wrote:
> Package: libc6-dev
> Version: 2.30-2
> Severity: wishlist
> 
> Every time a new glibc upstream release gets uploaded,
> cross-toolchain-base breaks in difficult to diagnose ways. This seems to
> happen, because gcc uses the libc6-dev:somearch headers together with
> libc6-dev-somearch-cross libraries.
> 
> Would you agree to have libc6-dev declare
> 
> Breaks: libc6-dev-${DEB_HOST_ARCH}-cross (<< ${CURRENT_UPSTREAM_VERSION}~)
> 

On the principle yes. Now I have to find a way to do it in a not too
ugly way, as ${DEB_HOST_ARCH} is not something supported by dpkg-dev. I
guess it probably means writing directly to substvars.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#928902: spectrwm FTCBFS: uses build architecture build tools

[Andrea Bolognani]

On Sun, May 26, 2019 at 03:03:13PM +0200, Helmut Grohne wrote:
> On Sun, May 26, 2019 at 10:00:46AM +0200, Andrea Bolognani wrote:
> > Can you please provide instructions I can use to reproduce the build
> > failure? The way you tackled it looks sensible enough, but I'd like
> > to play around a bit myself :)
> 
> sbuild¹: Pass --host=somearch.
> pbuilder: Pass --host-arch somearch
> dpkg-buildpackage: DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --build=any 
> --host-arch somearch --profiles cross,nocheck

Hi Helmut,

it's been an embarrassingly long time, I know :(

Anyway, I'm updating the spectrwm package and wanted to make sure
cross-building works fine once the new version hits the archive.
I have already both reproduced the issue you reported, and verified
that your changes address it.

I am still polishing debian/rules, for which I've landed on a slighly
different solution than you had, but in the meantime I would like to
submit the linux/Makefile changes for consideration upstream, as they
are in no way Debian-specific.

I have written a commit message and prepared a git-compatible patch,
which you can find attached. Of course I've retained full authorship.
Are you okay with me submitting it upstream?

Thank you for your patches, and your patience :)

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.
From a6fdbde54a42c190218066ac28de11b3c7995cae Mon Sep 17 00:00:00 2001
From: Helmut Grohne 
Date: Sun, 12 May 2019 19:59:22 +0200
Subject: [PATCH] linux: Accept user-provided pkg-config command

When cross-building, it's necessary to use versions of the various
toolchain commands that have been built specifically to target the
desired architecture, and that are named accordingly.

In practice, the make invocation will look something like

  $ make CC=aarch64-linux-gnu-gcc \
 PKG_CONFIG=aarch64-linux-gnu-pkg-config

However, whereas $(CC) is a built-in make variable and so it
behaves correctly out of the box, for $(PKG_CONFIG) we have to do
some work ourselves.
---
 linux/Makefile | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/linux/Makefile b/linux/Makefile
index 4016c2b..105f0f0 100644
--- a/linux/Makefile
+++ b/linux/Makefile
@@ -6,6 +6,7 @@ DATAROOTDIR  ?= $(PREFIX)/share
 MANDIR   ?= $(DATAROOTDIR)/man
 DOCDIR   ?= $(DATAROOTDIR)/doc/spectrwm
 XSESSIONSDIR ?= $(DATAROOTDIR)/xsessions
+PKG_CONFIG   ?= pkg-config
 
 BUILDVERSION= $(shell sh $(CURDIR)/../buildver.sh)
 LIBVERSION  = $(shell .  $(CURDIR)/../lib/shlib_version; echo $$major.$$minor)
@@ -21,12 +22,12 @@ endif
 
 BIN_CFLAGS   = -fPIE
 BIN_LDFLAGS  = -fPIE -pie
-BIN_CPPFLAGS = $(shell pkg-config --cflags x11 x11-xcb xcb-icccm xcb-keysyms xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft)
-BIN_LDLIBS   = $(shell pkg-config --libs   x11 x11-xcb xcb-icccm xcb-keysyms xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft)
+BIN_CPPFLAGS = $(shell $(PKG_CONFIG) --cflags x11 x11-xcb xcb-icccm xcb-keysyms xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft)
+BIN_LDLIBS   = $(shell $(PKG_CONFIG) --libs   x11 x11-xcb xcb-icccm xcb-keysyms xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft)
 LIB_CFLAGS   = -fPIC
 LIB_LDFLAGS  = -fPIC -shared
-LIB_CPPFLAGS = $(shell pkg-config --cflags x11)
-LIB_LDLIBS   = $(shell pkg-config --libs   x11) -ldl
+LIB_CPPFLAGS = $(shell $(PKG_CONFIG) --cflags x11)
+LIB_LDLIBS   = $(shell $(PKG_CONFIG) --libs   x11) -ldl
 
 all: spectrwm libswmhack.so.$(LIBVERSION)
 
-- 
2.25.1



signature.asc
Description: PGP signature

Bug#954747:

[Damon Lynch]

An update regarding gir1.2-unity-5.0: an Ubuntu desktop team member
let me know that in Debian you can have a depends added for Ubuntu
that is generated dynamically. The example he gave me was at the
bottom section:

https://salsa.debian.org/utopia-team/udisks2/-/blob/master/debian/rules

Luckily that will work just fine.

Thanks,
Damon

Bug#954815: apt-key fails if umask of calling user is 0222

[Florian Streibelt]

Package: apt
Version: 2.0.0
Severity: important

Dear Maintainers,

when calling 'apt update' with a umask of 0222 set in the shell of the calling
user, e.g. root, the verification of signatures by apt-key, which is called in
the background, will fail due to denied permissions.


To reproduce:

root@localhorst:~# umask 0222
root@localhorst:~# apt update
Hit:1 http://ftp.de.debian.org/debian bullseye InRelease
Hit:2 http://security.debian.org/debian-security bullseye-security InRelease
Hit:3 http://ftp.de.debian.org/debian bullseye-updates InRelease
Hit:4 http://ftp.de.debian.org/debian unstable InRelease
Err:1 http://ftp.de.debian.org/debian bullseye InRelease
  Unknown error executing apt-key
Err:2 http://security.debian.org/debian-security bullseye-security InRelease
  Unknown error executing apt-key
[...]



In difference:

root@localhorst:~# apt update
Hit:1 http://prerelease.keybase.io/deb stable InRelease
Hit:2 http://ftp.de.debian.org/debian bullseye InRelease
Hit:3 http://security.debian.org/debian-security bullseye-security InRelease
Hit:4 http://ftp.de.debian.org/debian bullseye-updates InRelease
[...]






-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (/etc/apt/preferences.d/testing present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/keybase.list present, but not submitted) --


-- (/etc/apt/sources.list.d/skype-stable.list present, but not submitted) --


-- (/etc/apt/sources.list.d/steam.list present, but not submitted) --


-- (/etc/apt/sources.list.d/teamviewer.list present, but not submitted) --


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

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.19-2
ii  libapt-pkg6.0   2.0.0
ii  libc6   2.29-10
ii  libgcc-s1   10-20200222-1
ii  libgnutls30 3.6.12-2
ii  libseccomp2 2.4.2-2
ii  libstdc++6  10-20200222-1

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.12-1
ii  dpkg-dev1.19.7
ii  gnupg   2.2.19-2
ii  gnupg1  1.4.23-1+b1
ii  powermgmt-base  1.36
ii  synaptic0.90

-- no debconf information

Bug#953883: Please backport version 20 for buster

[Enrico Zini]

On Fri, Mar 20, 2020 at 05:58:05PM -, Chris Lamb wrote:

> I'm inferring from the way you reference it that you have difficulty
> getting these incantations right, but I must also admit that I rarely
> ever get these right myself without some assistance. Indeed, I see a
> "Breaks" that was likely one misguided attempt of mine to address this.
> 
> Perhaps we can get some outside assistance on this so we would feel
> a bit more confident?

Indeed, this is out of my routine packaging work. I went digging and I
*think* the trick is in policy 7.6.2; at least, I'd give this one a try:


7.6.2. Replacing whole packages, forcing their removal
--

Second, "Replaces" allows the packaging system to resolve which
package should be removed when there is a conflict (see Conflicting
binary packages - Conflicts). This usage only takes effect when the
two packages *do* conflict, so that the two usages of this field do
not interfere with each other.

In this situation, the package declared as being replaced can be a
virtual package, so for example, all mail transport agents (MTAs)
would have the following fields in their control files:

   Provides: mail-transport-agent
   Conflicts: mail-transport-agent
   Replaces: mail-transport-agent

ensuring that only one MTA can be unpacked at any one time. See
Virtual packages - Provides for more information about this example.



Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#934479: fails to detect linux update on arm64 (Re: false negative: linux-image-4.19.0.5-powerpc64le)

[Diego Arroyo]

Hello Thomas,

I could not reproduce it with last kernel update in buster powerpc64le.

If it happens again I will provide you the output.

Best Regards,

Diego Arroyo

Bug#954023: stretch-pu: package amd64-microcode/3.20181128.1~deb9u1

[Henrique de Moraes Holschuh]

On Sat, 21 Mar 2020, Adam D. Barratt wrote:
> On Sun, 2020-03-15 at 21:37 +0100, Anton Gladky wrote:
> > I have prepared an update for amd64-microcode for Debian Stretch,
> > which fixes CVE-2017-5715. Please see an attached debdiff.
> > 
> > This is the newer upstream version, which fixes CVE-2017-5715.
> > Security team marked this CVE for Stretch as  [1].
> 
> Do you have any input / thoughts on this proposed update?

The microcode might be safe enough, we don't have regressions reported
against the lastest one (which is just a revert by AMD of an update that
did cause regressions when not applied through UEFI).

But that's with recent kernels.

I have no idea about the kernel codepaths it might activate, though, if
new MSRs are exposed.

-- 
  Henrique Holschuh

Bug#954812: [Python-modules-team] Bug#954812: pythonmagick: autopkgtest regression: cannot import name '_PythonMagick'

[Scott Kitterman]

The problem here is that py3versions -r falls back to supported versions when 
no X-Python3-Versions header field is present in debian/control and pythonmagic 
is only built for the current version:

https://packages.debian.org/sid/amd64/python3-pythonmagick/filelist

(shows only python3.8 objects)

This is hidden behind redirecting stderr to /Dev/null.

Solutions:

Preferred: build for all supported python3 versions, change the -r to -s and 
ditch the redirect.

Less preferred:. Change the -r to -d (default) and ditch the redirect.

You may also need to allow stderr in debian/tests/control.

Scott K

On March 23, 2020 8:43:19 PM UTC, Paul Gevers  wrote:
>Source: pythonmagick
>Version: 0.9.19-6
>X-Debbugs-CC: debian...@lists.debian.org
>Severity: serious
>User: debian...@lists.debian.org
>Usertags: regression
>
>Dear maintainer(s),
>
>With a recent upload of pythonmagick the autopkgtest of pythonmagick
>fails in testing when that autopkgtest is run with the binary packages
>of pythonmagick from unstable. It passes when run with only packages
>from testing. In tabular form:
>
>   passfail
>pythonmagick   from testing0.9.19-6
>versioned deps [0] from testingfrom unstable
>all others from testingfrom testing
>
>I copied some of the output at the bottom of this report.
>
>Currently this regression is blocking the migration to testing [1]. Can
>you please investigate the situation and fix it?
>
>More information about this bug and the reason for filing it can be
>found on
>https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
>Paul
>
>[0] You can see what packages were added from the second line of the
>log
>file quoted below. The migration software adds source package from
>unstable to the list if they are needed to install packages from
>pythonmagick/0.9.19-6. I.e. due to versioned dependencies or
>breaks/conflicts.
>[1] https://qa.debian.org/excuses.php?package=pythonmagick
>
>https://ci.debian.net/data/autopkgtest/testing/amd64/p/pythonmagick/4632912/log.gz
>autopkgtest [18:24:16]: test python3: [---
>+ py3versions -r
>+ cd /tmp/autopkgtest-lxc.eflqupv1/downtmp/autopkgtest_tmp
>+ echo Testing with python3.7:
>Testing with python3.7:
>+ python3.7
>Traceback (most recent call last):
>  File "", line 1, in 
>  File "/usr/lib/python3/dist-packages/PythonMagick/__init__.py", line
>1, in 
>from . import _PythonMagick
>ImportError: cannot import name '_PythonMagick' from 'PythonMagick'
>(/usr/lib/python3/dist-packages/PythonMagick/__init__.py)
>autopkgtest [18:24:17]: test python3: ---]

Bug#954814: ITP: r-cran-mediana -- clinical trial simulations

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-mediana -- clinical trial simulations
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-mediana
  Version : 1.0.8
  Upstream Author : Gautier Paux, Alex Dmitrienko.
* URL : https://cran.r-project.org/package=Mediana
* License : GPL-2
  Programming Lang: GNU R
  Description : clinical trial simulations
 Provides a general framework for clinical trial simulations based on the
 Clinical Scenario Evaluation (CSE) approach. The package supports a
 broad class of data models (including clinical trials with continuous,
 binary, survival-type and count-type endpoints as well as multivariate
 outcomes that are based on combinations of different endpoints),
 analysis strategies and commonly used evaluation criteria.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-mediana

Bug#954807: apt upgrade sometimes marks packages as manually installed

[Piotr Engelking]

Julian Andres Klode :

> This is not a bug, but a feature. You ran the equivalent of
> apt install libc6 && apt upgrade, and that causes libc6 to be
> manually installed, because you manually requested it to be
> installed.

Hmm... What is the difference between apt install  and apt upgrade
, then? I would naively expect the first to mark the package as
manually installed, and the second not to. Is there a way to to upgrade
a package to a particular release without marking it as manually
installed?

Also, when the package listed as argument to apt upgrade is not at the
requested version, it is not marked as manually installed, exactly as I
would expect.

Bug#954813: r-cran-rlang breaks r-cran-ggplot2 autopkgtest: `out` not identical to `exp`

[Paul Gevers]

Source: r-cran-rlang, r-cran-ggplot2
Control: found -1 r-cran-rlang/0.4.5-1
Control: found -1 r-cran-ggplot2/3.2.1+dfsg-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of r-cran-rlang the autopkgtest of r-cran-ggplot2
fails in testing when that autopkgtest is run with the binary packages
of r-cran-rlang from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
r-cran-rlang   from testing0.4.5-1
r-cran-ggplot2 from testing3.2.1+dfsg-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of r-cran-rlang to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=r-cran-rlang

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

autopkgtest [21:29:08]: test run-unit-test: [---
BEGIN TEST testthat.R

R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(testthat)
> library(ggplot2)
>
> test_check("ggplot2")
── 1. Failure: as_facets_list() coerces lists (@test-facet-.r#40)
─
`out` not identical to `exp`.
Component 3: Attributes: < Component “class”: Lengths (2, 1) differ
(string compare on first 1) >

══ testthat results
═══
[ OK: 1072 | SKIPPED: 113 | WARNINGS: 0 | FAILED: 1 ]
1. Failure: as_facets_list() coerces lists (@test-facet-.r#40)

Error: testthat unit tests failed
Execution halted
autopkgtest [21:29:47]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#954351: can you look into this a bit more.

[shirish शिरीष]

at bottom :-

On 23/03/2020, shirish शिरीष  wrote:
> Dear Giovanni,
>
> I casually looked at
> https://github.com/rareylab/RingDecomposerLib/archive/v1.1.3_rdkit.tar.gz..
> First of all the correct link should be
> https://github.com/rareylab/RingDecomposerLib/archive/v1.1.3_rdkit.tar.gz
>  (notice the absence of ..)
>
> I couldn't find either RDKitUtils or the cmake file that you hve
> mentioned. There are a bunch of  cmakelists.tdt but nothing which goes
> to line 153.
>
> Could you please look into it.
>
> --
>   Regards,
>   Shirish Agarwal  शिरीष अग्रवाल
>   My quotes in this email licensed under CC 3.0
> http://creativecommons.org/licenses/by-nc/3.0/
> http://flossexperiences.wordpress.com
>
> E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
>

please disregard the above, the issue is with rdkit, hence filing it
with upstream.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#954812: pythonmagick: autopkgtest regression: cannot import name '_PythonMagick'

[Paul Gevers]

Source: pythonmagick
Version: 0.9.19-6
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of pythonmagick the autopkgtest of pythonmagick
fails in testing when that autopkgtest is run with the binary packages
of pythonmagick from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
pythonmagick   from testing0.9.19-6
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
pythonmagick/0.9.19-6. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=pythonmagick

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pythonmagick/4632912/log.gz
autopkgtest [18:24:16]: test python3: [---
+ py3versions -r
+ cd /tmp/autopkgtest-lxc.eflqupv1/downtmp/autopkgtest_tmp
+ echo Testing with python3.7:
Testing with python3.7:
+ python3.7
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/PythonMagick/__init__.py", line
1, in 
from . import _PythonMagick
ImportError: cannot import name '_PythonMagick' from 'PythonMagick'
(/usr/lib/python3/dist-packages/PythonMagick/__init__.py)
autopkgtest [18:24:17]: test python3: ---]




signature.asc
Description: OpenPGP digital signature

Bug#954810: zim: CVE-2020-10870

[Salvatore Bonaccorso]

Source: zim
Version: 0.72.0-1
Severity: important
Tags: security upstream
Control: found -1 0.68-1
Control: found -1 0.65-4

Hi,

The following vulnerability was published for zim.

CVE-2020-10870[0]:
| Zim through 0.72.1 creates temporary directories with predictable
| names. A malicious user could predict and create Zim's temporary
| directories and prevent other users from being able to start Zim,
| resulting in a denial of service.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-10870
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10870
[1] https://github.com/zim-desktop-wiki/zim-desktop-wiki/issues/1028

Regards,
Salvatore

Bug#954811: git tag -h: "the field 'creatordate' requires access to object data"

[Jakub Wilk]

Package: git
Version: 1:2.26.0~rc2-1
Severity: minor

I've set tag.sort=creatordate in my global config, and now I can't get 
help for "git tag":


  $ git tag -h
  fatal: not a git repository, but the field 'creatordate' requires access to 
object data


-- System Information:
Architecture: i386

Versions of packages git depends on:
ii  libc62.30-2
ii  libcurl3-gnutls  7.68.0-1
ii  libexpat12.2.9-1
ii  libpcre2-8-0 10.34-7
ii  zlib1g   1:1.2.11.dfsg-2
ii  perl 5.30.0-9
ii  liberror-perl0.17029-1
ii  git-man  1:2.26.0~rc2-1

--
Jakub Wilk

Bug#954809: golang-gitlab-yawning-bsaes -- a portable pure-Go constant time AES implementation

[Cecylia Bocovich]

Package: wnpp
Severity: wishlist
Owner: Cecylia Bocovich 

* Package name: golang-gitlab-yawning-bsaes
  Version : 0.0~git20190805.0a714cd-1
  Upstream Author : Yawning Angel 
* URL : https://gitlab.com/yawning/bsaes
* License : MIT
  Programming Lang: Go
  Description : a portable pure-Go constant time AES implementation
bsaes is a portable pure-Go constant time AES implementation based on
the excellent code from BearSSL.  On appropriate systems, with a
sufficiently recent Go runtime, it will transparently call crypto/aes
when NewCipher is invoked.


This library is needed for golang-gitlab-yawning-utls (#954209), which
is needed to update obfs4proxy to the latest version (v0.0.11).

Bug#953098: xscreensaver: Crashes with XIO: fatal IO error

[Tormod Volden]

Jens, can you please also attach an Xorg log from the crash? If I
understand the original report right, the X session continued
otherwise as normal, so I guess the X server didn't crash. It could
have run out of memory temporarily, or xscreensaver requested
something out of reach, like loads of memory.

Does the timestamp on your log indicate that xscreensaver died just
after killing molecule?

xscreensaver also has a -sync option to help debug X troubles,
although I don't know if it can help here, can you try with that?

Tormod

On Sat, Mar 14, 2020 at 9:51 PM Jamie Zawinski  wrote:
>
> As far as I know, an XIO error means the X server dropped the connection to 
> the xscreensaver client. So either the X server itself crashed, or it decided 
> to disconnect xscreensaver for some unknown reason.
>
> If the client had done something wrong, X11-protocol-wise, this would have 
> been a more verbose "X" error, not an "XIO" error.
>
> Maybe this is the kernel OOM-killer shooting down random long-running 
> processes, as it sometimes likes to do?
>
> "Resource temporarily unavailable" sure sounds like it could be the X11 
> server trying to say that it ran out of memory.

Bug#954351: can you look into this a bit more.

[shirish शिरीष]

Dear Giovanni,

I casually looked at
https://github.com/rareylab/RingDecomposerLib/archive/v1.1.3_rdkit.tar.gz..
First of all the correct link should be
https://github.com/rareylab/RingDecomposerLib/archive/v1.1.3_rdkit.tar.gz
 (notice the absence of ..)

I couldn't find either RDKitUtils or the cmake file that you hve
mentioned. There are a bunch of  cmakelists.tdt but nothing which goes
to line 153.

Could you please look into it.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#954808: memcached: buffer overflow vulnerability

[Salvatore Bonaccorso]

Source: memcached
Version: 1.6.1-1
Severity: important
Tags: security upstream fixed-upstream
Forwarded: https://github.com/memcached/memcached/issues/629

Hi

Please see https://github.com/memcached/memcached/issues/629 for the
report. it is fixed in 1.6.2 upstream.

Regards,
Salvatore

Bug#954807: apt upgrade sometimes marks packages as manually installed

[Piotr Engelking]

Package: apt
Version: 2.0.0
Severity: normal


When a package listed as an argument to apt upgrade is already at the
requested version, it is marked as manually installed:

# apt-mark showmanual libc6
# apt upgrade libc6
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6 is already the newest version (2.30-2).
libc6 set to manually installed.
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
# apt-mark showmanual libc6
libc6
#

Please do not mark packages listed as arguments to apt upgrade as
manually installed.


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

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.19-3
ii  libapt-pkg6.0   2.0.0
ii  libc6   2.30-2
ii  libgcc-s1   10-20200312-2
ii  libgnutls30 3.6.12-2
ii  libseccomp2 2.4.3-1
ii  libstdc++6  10-20200312-2

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
ii  apt-doc  2.0.0
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.19.7
ii  gnupg2.2.19-3
pn  powermgmt-base   

-- no debconf information

Bug#953777:

[David Prévot]

Hi Ondřej,

Le 23/03/2020 à 00:53, Debian FTP Masters a écrit :
[…]
> Source: php-doctrine-cache
[…]
> Maintainer: Debian PHP PEAR Maintainers 
[…]
>* The autopkgtest dependencies were underspecified (Closes: #953777)

I had a quick look at the fix. It’s useless: phpunit already depend on
php-cli, php-xml, and php-mbstring.

https://salsa.debian.org/php-team/pear/php-doctrine-cache/-/commit/77782beaad3a125d97fd1e8541d4c6a1d150b785

#953777 is about the lack of tight versioning dependency between PHP
extensions.

The test log shows a mix of php-7.3 and php-7.4 extensions installed:
php7.3-mbstring php7.3-sqlite3 php7.3-xml php7.4-cli php7.4-common
php7.4-json (the autopkgtest is about *partial* upgrade for migrations).

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-doctrine-cache/4542910/log.gz

You may argue that it’s a flow in autopkgtest, but anyway, you can’t fix
it by adding useless dependencies in a consumer (using php extensions)
package. You may want to (at least temporarily, since it defeat the main
purpose of having various PHP versions co-installable) tighten the
dependencies from php-7.4 (e.g, Breaks: php7.3-mbstring, php-7.3-xml,
etc.), or try and get an exception from the release team.

Regards

David



signature.asc
Description: OpenPGP digital signature
___
pkg-php-pear mailing list
pkg-php-p...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-php-pear

Bug#953777: Incorrect fix [Was: php-doctrine-cache_1.10.0-4_source.changes ACCEPTED into unstable]

[Ondřej Surý]

David,

I disagree that all of the added dependencies are wrong. I believe you should 
declare all the dependencies that the autopkgtest requires and that was not 
full filled. The autopkgtest needs to at least depend on php-cli.

Also the dependencies are already tight, it’s just that phpX.Y-foo also 
provides php-foo, so the dependency solver could pick any. But in case you 
explicitly pull the required package, you should get the real meta-package, and 
not just the one with provides.

I already filled RoM bug against php7.3, that’s the ultimate fix for all 
failing autopkgtests, but I think the fixes are correct because they help the 
dependency solver to pick right package.

Ondřej 
--
Ondřej Surý 

> On 23 Mar 2020, at 19:33, David Prévot  wrote:
> 
> Hi Ondřej,
> 
> Le 23/03/2020 à 00:53, Debian FTP Masters a écrit :
> […]
>> Source: php-doctrine-cache
> […]
>> Maintainer: Debian PHP PEAR Maintainers 
>> 
> […]
>>   * The autopkgtest dependencies were underspecified (Closes: #953777)
> 
> I had a quick look at the fix. It’s useless: phpunit already depend on
> php-cli, php-xml, and php-mbstring.
> 
> https://salsa.debian.org/php-team/pear/php-doctrine-cache/-/commit/77782beaad3a125d97fd1e8541d4c6a1d150b785
> 
> #953777 is about the lack of tight versioning dependency between PHP
> extensions.
> 
> The test log shows a mix of php-7.3 and php-7.4 extensions installed:
> php7.3-mbstring php7.3-sqlite3 php7.3-xml php7.4-cli php7.4-common
> php7.4-json (the autopkgtest is about *partial* upgrade for migrations).
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-doctrine-cache/4542910/log.gz
> 
> You may argue that it’s a flow in autopkgtest, but anyway, you can’t fix
> it by adding useless dependencies in a consumer (using php extensions)
> package. You may want to (at least temporarily, since it defeat the main
> purpose of having various PHP versions co-installable) tighten the
> dependencies from php-7.4 (e.g, Breaks: php7.3-mbstring, php-7.3-xml,
> etc.), or try and get an exception from the release team.
> 
> Regards
> 
> David
> 

Bug#954242: qgis-providers: postinst failure: free(): invalid pointer

[Piotr Engelking]

Sebastiaan Couwenberg :

> So for some reason not all packages in the qgis dependency chain that
> were rebuilt for the proj transition were upgraded on your systems,
> that's an unusual situation but not a bug in qgis.

The current version of libgeotiff5 in testing is 1.5.1-2, so it is not
surprising it wasn't updated yet. If it needs to be updated for the
current version of qgis to work, it needs to be listed as a dependency
(by qgis or by one of the packages that qgis depends on). So yes, it is
a bug (not necessarily in your package, it is hard for me to say which
one is responsible here), see bullseye RC policy §2.

Bug#954806: gcc-9: Optimizes away something it shouldn't

[Asher Gordon]

Package: gcc-9
Version: 9.3.0-3
Severity: normal

Dear Maintainer,

I am writing a general purpose convenience library called Mu (for
Miscellaneous Utilities). It includes an option parsing module intended
to be a replacement for getopt_long().

Options are defined in structures which include various information,
including an optional callback which will be called when the option is
found. The parse_opts() function has a flag `OPT_HELP' (or
`OPT_HELP_SHORT' or `OPT_HELP_LONG') which makes it automatically add a
'-h' and/or a '--help' option which calls a callback to print a usage
message.

The problem is, when the test program (test.c) is compiled with
optimization, the data fields (set at options.c:127-131) passed to the
callback are optimized out. This causes a segmentation fault and/or
error message when './test' is passed '-h' or '--help'. Note that when
the program is compiled without optimization, no memory errors are
reported when run under Valgrind (although memory errors *are* reported
when the program is compiled with optimization).

I thought that the problem may have been that I was casting the data
pointer to (void *), but I tried creating a test program to test that,
and that didn't seem to be the problem.

To compile the program with optimization, I ran:

$ make CC=gcc-9 CFLAGS='-Wall -O1' clean all

And without optimization:

$ make CC=gcc-9 CFLAGS='-Wall -O0' clean all

Note that the problem can be reproduced with GCC 10 also
(CC=gcc-10). Also note that no warnings are reported with -Wall, not
even with -O3. Three warnings are reported with -Werror, but I don't
think they are serious or relevant. Here they are, just in case
(compiled with -O3 to catch warnings it might not otherwise):

$ make CC=gcc-9 CFLAGS='-Wall -Wextra -O3' clean all
rm -f *.o test
gcc-9 -Wall -Wextra -O3   -c -o test.o test.c
gcc-9 -Wall -Wextra -O3   -c -o compat.o compat.c
gcc-9 -Wall -Wextra -O3   -c -o format.o format.c
format.c: In function ‘format_list’:
format.c:277:36: warning: comparison of integer expressions of different 
signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
  277 | if (width && size + char_width > width - *col) {
  |^
In file included from format.c:34:
format.c:303:27: warning: comparison of integer expressions of different 
signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
  303 |  assert(index + tab_width > width - *col);
  |   ^
format.c:314:19: warning: comparison of integer expressions of different 
signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
  314 |  assert(index + 1 > width - *col);
  |   ^
gcc-9 -Wall -Wextra -O3   -c -o io.o io.c
gcc-9 -Wall -Wextra -O3   -c -o options.o options.c
gcc-9 -Wall -Wextra -O3   -c -o safe.o safe.c
gcc-9   test.o compat.o format.o io.o options.o safe.o   -o test

Also note that when compiled with Clang (CC=clang), even with -O3, the
program works as expected and no memory errors are reported by Valgrind.

Note that only the -O* and all the -O* options trigger the bug. I tried
manually passing all the -f* options which (according to the
documentation) are enabled by the various -O* options. However,
strangely, I could not reproduce the bug that way.

The following patch adds a nop() function to options.c that is used to
prevent the data fields from being optimized out. When this patch is
applied, the issue is no longer present, even when compiled with -O3
(with gcc-9 or gcc-10).
--- options.c~	2020-03-23 14:23:08.625333110 -0400
+++ options.c	2020-03-23 14:23:17.841369826 -0400
@@ -81,6 +81,13 @@
 static int free_opts(const char *, const OPTION *);
 static int format_help_callback(void *, char *);
 
+static void nop(const void *data, ...) {
+  /* We have to do this so GCC doesn't optimize calls to us away. */
+  va_list ap;
+  va_start(ap, data);
+  va_end(ap);
+}
+
 /*
  * Parse options. Returns zero on success or nonzero on error, in
  * which case an error message will be printed to `stderr'. The last
@@ -137,6 +144,7 @@
 opt->callback_none	= format_help_callback;
 opt->data		= &data;
 opt->help		= "print this help and exit";
+nop(data.prog_name, data.usage, data.desc, data.notes, data.options);
   }
   else {
 /* This is slightly evil (casting it to a non-const), but we know
Since I was not able write a simpler program that triggers the bug, I
have attached the source tarball (mu.tar.gz). README.Bugs says that I
should provide the *.i files, so I have included them in the
tarball. Different .i files are produced under optimization, so I have
included the ones produced with '-O0 --save-temps'. I have also attached
a patch (nop_preprocessed.patch) that adds the nop() function to the
preprocessed options.i.

Here is the output of 'gcc-9 -v' and 'gcc-10 -v':

$ gcc-9 -v
Using b

Bug#954378: tcpdump: Support pcapng captures wiht snaplen 524288

[Romain Francoise]

I just uploaded the backport, it may take a few days before it appears
in the archive.

Bug#952022: ruby-puppet-syntax: FTBFS: ERROR: Test "ruby2.7" failed: LoadError:

[Daniel Leidert]

Am Montag, den 23.03.2020, 19:28 +0100 schrieb Daniel Leidert:

[..]
> Thanks. This actually brought me on the right track. I just uploaded the
> fixed package.

The last three messages (#31, #36, #41) were reported against the wrong
package. They are related to #952024 instead. Please ignore them. The last mail
related to this report is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952022#24

Regards, Daniel


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

Bug#954017: xscreensaver: epicycle screensaver braws part of its figure in black on black background

[Tormod Volden]

tag 954017 pending
thanks


Hi James,

Thanks for the report. I suppose this was a bug in 5.42 that was fixed
in 5.43. It would be nice if you can confirm this by trying our 5.43
packaging from:
https://salsa.debian.org/debian/xscreensaver

Regards,
Tormod


On Sun, Mar 15, 2020 at 8:15 PM James Youngman wrote:
>
> Package: xscreensaver
> Version: 5.42+dfsg1-1
> Severity: normal
>
> If you look closely at the output of the epicycle screenhack, part of
> each curve is drawn in black on black.  This seems most often to occur
> at the part of the figure that is next the brightest drawn part.
>
> I built the pristine upstream xscreensaver-5.43 code (and ran it
> without installing).  It does not exhibit this problem.

Bug#954805: src:xapers: Fails autopkgtest due to test assumptions about paths

[Scott Kitterman]

Package: src:xapers
Version: 0.8.2-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The following autopkgtest log extracted from [1] should be enough to
show the problem.  It is currently showing up as a regression for
python3.8 as default, but this doesn't seem related at all.

Scott K

Note: Using FTBFS as a tag because it is the closest we have for
autopkgtest failures.

 FAIL   search --output=bibtex single
--- all.48.expected 2020-03-23 13:11:53.768226199 +
+++ all.48.output   2020-03-23 13:11:53.768226199 +
@@ -3,6 +3,6 @@
 title = "Creation of the γ-verses",
 year = "2011",
 eprint = "1235",
-file = ":XAPERS_ROOT/01/1.pdf:pdf"
+file = 
":/tmp/autopkgtest-lxc.cg\_m28kl/downtmp/build.i4p/src/test/tmp.all/docs/01/1.pdf:pdf"
 }

 FAIL   bibtex multiple
--- all.49.expected 2020-03-23 13:11:53.940223633 +
+++ all.49.output   2020-03-23 13:11:53.936223692 +
@@ -10,7 +10,7 @@
 year = "2012",
 month = "Sep",
 pages = "2092",
-file = ":XAPERS_ROOT/02/2 file.pdf:pdf"
+file = 
":/tmp/autopkgtest-lxc.cg\_m28kl/downtmp/build.i4p/src/test/tmp.all/docs/02/2
 file.pdf:pdf"
 }

 @article{arxiv:1235,
@@ -18,7 +18,7 @@
 title = "Creation of the γ-verses",
 year = "2011",
 eprint = "1235",
-file = ":XAPERS_ROOT/01/1.pdf:pdf"
+file = 
":/tmp/autopkgtest-lxc.cg\_m28kl/downtmp/build.i4p/src/test/tmp.all/docs/01/1.pdf:pdf"
 }

 @article{30929234,
No bibtex for doc id:5.

[1] https://ci.debian.net/data/autopkgtest/testing/amd64/x/xapers/4639691/log.gz

Bug#953881: transition: ruby2.7 only

[Lucas Kanashiro]

Hi,

On 21/03/2020 08:09, Emilio Pozuelo Monfort wrote:
> And the others as well. There are a few build failures, and ruby-pgplot needs 
> a
> binary upload on amd64+i386. Could you take care of that and file bugs for the
> packages that failed to build?

Thanks Emilio. Antonio already did a binary upload for ruby-pgplot and I
filed bugs against those packages which are failing to build:

* libprelude -> #954785 (it includes a patch)

* subversion -> #951893 (actually this is a bug with the new swig 4 but
I attached a patch to the bug to make it build with swig 3 which also
fixes our problem)

* uwsgi -> #954787 (it includes a patch)

* weechat -> #954789 (it includes a patch)

I'd like to ask you to rebuild src:passenger on armel and armhf, and
src:vim on ppc64el and s390x. In Ubuntu I rebuilt those packages without
changes and they worked fine.

Thanks in advance!

-- 
Lucas Kanashiro

Bug#954747:

[Damon Lynch]

I today learned that libunity and its gobject introspection bindings
are not packaged in Debian. Rapid Photo Downloader will still run
without gir1.2-unity-5.0.

If packaging libunity and its bindings would cause a non-trivial delay
to packaging this new release of Rapid Photo Downloader, I think it
best to update the rapid-photo-downloader package without
gir1.2-unity-5.0, and then if and when libunity and its bindings are
packaged, updating the rapid-photo-downloader package to include
gir1.2-unity-5.0.

Any thoughts?

Thanks,
Damon

Bug#954242: qgis-providers: postinst failure: free(): invalid pointer

[Piotr Engelking]

Sebastiaan Couwenberg :

> Not on my system.
>
> I have libc6 (2.30-2) since 2020-03-14 06:59:08.
>
> qgis-provides was upgrade from 3.10.3+dfsg-1 to 3.10.3+dfsg-1+b1 on
> 2020-03-19 05:38:47.
>
> It upgraded without issues:
>
>  Setting up qgis-providers (3.10.3+dfsg-1+b1) ...
>  Setting up libqgis-customwidgets (3.10.3+dfsg-1+b1) ...

After some testing, it looks that the bug is present with libgeotiff5 1.5.1-2:

# cp /usr/share/qgis/resources/srs-template.db
/usr/share/qgis/resources/srs.db && /usr/lib/qgis/crssync
free(): invalid pointer
Aborted
#

and absent with libgeotiff5 1.5.1-2+b1:

# cp /usr/share/qgis/resources/srs-template.db
/usr/share/qgis/resources/srs.db && /usr/lib/qgis/crssync
#

Bug#952022: ruby-puppet-syntax: FTBFS: ERROR: Test "ruby2.7" failed: LoadError:

[Daniel Leidert]

Am Montag, den 23.03.2020, 18:13 +0100 schrieb Stig Sandbeck Mathisen:
> Daniel Leidert  writes:
> 
> > Package: src:ruby-puppet-syntax
> > Followup-For: Bug #952022
> > 
> > The formentioned issue can probably be closed by applying this patch:
> > 
> > --- a/lib/rspec-puppet/support.rb
> > +++ b/lib/rspec-puppet/support.rb
> > @@ -440,7 +440,7 @@
> >  end
> >  
> >  def escape_special_chars(string)
> > -  string.gsub!(/\$/, "\\$")
> > +  string.gsub(/\$/, "\\$")
> >string
> >  end
> > 
> > But then there are new errors (see below). I'll stop here and leave
> > this to someone more experienced. So if anyone wants to go on, please
> > feel free to do so.
> > 
> > Regards, Daniel
> 
> I think that change turns the subroutine into a noop.
> 
> string.gsub(pattern,replacement) returns the changed string, and does
> not change the original object. The output in this instance is
> discarded.
> 
> string.gsub!(pattern,replacement) modifies the object.
>
> The subroutine then returns the original or changed string.

Thanks. This actually brought me on the right track. I just uploaded the fixed
package.

Regards, Daniel


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

Bug#954804: release.debian.org: Need release team intervention to disentagle python-pip from python3.8 as default

[Scott Kitterman]

Package: release.debian.org
Severity: normal

Python-pip is actually ready to migrate, but there are problems that
will take manual intervention to address:

1.  Autopkgtest regressions marked against doit and logbook:

Both tests are RC buggy (and bugs filed).  It's true that updating pip
unmasked the bugs, but they were RC buggy before due to using packages
downloaded from the internet to run tests.  Also, logbook can't be fixed
in Testing until after the python3.8 as default (python3-defaults)
transition is complete.

2.  Python-pip needs python-msgpack to migrate:

Python-msgpack is trapped behind waiting for borgbackup to migrate and
it's stuck behind python3.8 as default.  The Unstable python-msgpack
will break the borgbackup in Testing, so merely force updating
python-msgpack may not be a great idea.  This could be unblocked either
by forcing python-msgpack or a temporary removal of borgbackup from
Testing.

This will also enable python-virtualenv to migrate in a few days after
the updated Tox is in testing.  

Thanks,

Scott K

Bug#954765: git: git pull downloads all objects again

[Sven Joachim]

On 2020-03-23 07:10 +0100, Sven Joachim wrote:

> Package: git
> Version: 1:2.26.0~rc2-1
> Severity: important
>
> I have a git repository for the Linux kernel where I track both Linus'
> and the stable repository.
>
> ,
> | $ git remote --verbose show
> | origin  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> (fetch)
> | origin  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> (push)
> | stable  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 
> (fetch)
> | stable  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 
> (push)
> `
>
> A few days ago, after the update to 2.26.0-rc2, I fetched from the
> stable tree.  This triggered a run of "git gc --auto" in the background
> as there were more than 6700 loose objects.
>
> This morning I pulled from Linus' tree, and it downloaded _a lot_ of
> objects.  Both that and resolving deltas took quite some time, as one
> might imagine.
>
> ,
> | $ git pull
> | remote: Enumerating objects: 7226920, done.
> | remote: Counting objects: 100% (7226920/7226920), done.
> | remote: Compressing objects: 100% (1098637/1098637), done.
> | remote: Total 7226920 (delta 6082531), reused 7224317 (delta 6080838)
> | Receiving objects: 100% (7226920/7226920), 1.18 GiB | 3.95 MiB/s, done.
> | Resolving deltas: 100% (6082531/6082531), done.
> `

Additionally, the size of the .git directory ballooned to ~3.5 GiB after
that.  Running "git gc" manually reduced it to ~2 GiB which I think is
normal.

Cheers,
   Sven

Bug#954803: lintian: no-md5sums-control-file tag should not be triggered for udebs

[Sven Joachim]

Package: lintian
Version: 2.59.0
Severity: normal

The following is not supposed to happen, I think:

,
| $ lintian libtinfo6-udeb_6.2-1_amd64.udeb
| I: libtinfo6-udeb udeb: no-md5sums-control-file
`

AFAIK it is normal for udebs not to ship an md5sums control file, and
dh_md5sums does not create one.


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

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

Versions of packages lintian depends on:
ii  binutils 2.34-5
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.19-3
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+b3
ii  libclone-perl0.43-2
ii  libdevel-size-perl   0.83-1+b1
ii  libdigest-sha-perl   6.02-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  libjson-maybexs-perl 1.004000-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.008001-2
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.81+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

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

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

-- no debconf information

Bug#954802: logcheck: Support mail size limits

[Noah Meyerhans]

Package: logcheck
Version: 1.3.18
Severity: normal

It's generally considered to be good practice to configure size limits on
messages at the MTA level.  Logcheck should have the ability to limit the
size of its generated to comply with such limits.  I'd propose that it
should be configurable via logcheck.conf (rather than trying to autodetect
it or something like that).  Ideally logcheck would split the message
across multiple emails if it has more data to send, but even just
truncating the message, with a warning, is probably better than the
current behavior of generating a message that the SMTP server won't
accept.

Thanks for maintaining logcheck!

noah

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

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

Versions of packages logcheck depends on:
ii  adduser3.115
ii  cron [cron-daemon] 3.0pl1-128+deb9u1
ii  exim4-daemon-light [mail-transport-agent]  4.89-2+deb9u6
ii  lockfile-progs 0.1.17+b1
ii  logtail1.3.18
ii  mime-construct 1.11+nmu2
ii  rsyslog [system-log-daemon]8.24.0-1

Versions of packages logcheck recommends:
ii  logcheck-database  1.3.18

Versions of packages logcheck suggests:
pn  syslog-summary  

-- Configuration Files:
/etc/logcheck/logcheck.conf [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.conf'
/etc/logcheck/logcheck.logfiles [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.logfiles'

-- no debconf information

Bug#944197: HELP needed for uploading a new upstream version of the Rheolef package

[Anton Gladky]

I think I sponsored this package some time ago and I will try to have
a look again.

Anton

Am Mo., 23. März 2020 um 18:33 Uhr schrieb Pierre Saramito
:
>
> Hi Andreas Tille,
>
> > From Andreas:
> > Currently I can only support Covid-19 related
> > packages (which we try to assemble in Debian Med team currently)
>
> Let me known if I could help the Debian Med team ?
> I remain "confined" at home, but I could help (test pkg, ect) ?
>
>
> > please find some other sponsor from Debian Science project.
>
> Is there somebody from the Debian science project
> to just help me for uploading the Rheolef-7.1-1 pkg ?
> The debianization is ready and well-tested at
>https://salsa.debian.org/science-team/rheolef
> It closes the two FTBFS bugs: #944197 and #946116
>
>
> Best wishes,
>
> Pierre
>
> --
> pierre.saram...@imag.fr
> Directeur de Recherche CNRS
> Laboratoire Jean Kuntzmann, Grenoble, France
> http://ljk.imag.fr/membres/Pierre.Saramito
>

Bug#954794: New packages must not declare themselves Essential

[Sean Whitton]

Hello,

On Mon 23 Mar 2020 at 04:29PM +01, Bill Allombert wrote:

> I do not think this proposal make sense _as a Debian policy change_.
> What I mean is that if the release team decide that some new packages
> need to be marked Essential: yes for some technical reason, then either
> policy will be ignored and this change will be reverted. Or maybe the
> bug will be serious but not RC.
>
> Remember as Manoj used to say, policy is no a stick to beat people with.

I'm inclined to agree with Bill here.

In particular, it is not clear to me we have a project consensus that
the requirement to seek consensus on debian-devel is not sufficient.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#953641: DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats

[Francois Marier]

On 2020-03-12 at 12:29:54, Bálint Réczey wrote:
> Do you still observe the messages?
> This should have been fixed in python-apt in #944091 in version 1.9.1

I haven't seen the messages in a while now. I guess it's all fixed.

Francois

-- 
https://fmarier.org/

Bug#944197: HELP needed for uploading a new upstream version of the Rheolef package

[Andreas Tille]

Hi Pierre,

On Mon, Mar 23, 2020 at 04:24:13PM +, Pierre Saramito wrote:
> 
> Let me known if I could help the Debian Med team ?
> I remain "confined" at home, but I could help (test pkg, ect) ?

We'll about to post an announcement for the upcomming
virtual COVID-19 hackathon.

I admit I could definitely help to package streamlit[1].
I do not even have an idea how to start with this package.

Kind regards

   Andreas.
 

[1] https://salsa.debian.org/science-team/streamlit 

-- 
http://fam-tille.de

Bug#952022: ruby-puppet-syntax: FTBFS: ERROR: Test "ruby2.7" failed: LoadError:

[Stig Sandbeck Mathisen]

Daniel Leidert  writes:

> Package: src:ruby-puppet-syntax
> Followup-For: Bug #952022
>
> The formentioned issue can probably be closed by applying this patch:
>
> --- a/lib/rspec-puppet/support.rb
> +++ b/lib/rspec-puppet/support.rb
> @@ -440,7 +440,7 @@
>  end
>  
>  def escape_special_chars(string)
> -  string.gsub!(/\$/, "\\$")
> +  string.gsub(/\$/, "\\$")
>string
>  end
>
> But then there are new errors (see below). I'll stop here and leave
> this to someone more experienced. So if anyone wants to go on, please
> feel free to do so.
>
> Regards, Daniel

I think that change turns the subroutine into a noop.

string.gsub(pattern,replacement) returns the changed string, and does
not change the original object. The output in this instance is
discarded.

string.gsub!(pattern,replacement) modifies the object.

The subroutine then returns the original or changed string.

See https://ruby-doc.org/core-2.7.0/String.html

-- 
Stig Sandbeck Mathisen
Debian Developer


signature.asc
Description: PGP signature

Bug#952061: Info received (Bug#952061: ibsim: FTBFS: umad2sim.c:110:30: error: ‘UMAD_DEV_DIR’ undeclared here (not in a function))

[Tzafrir Cohen]

Hi,

I had little time to work on this, but as it happened, I submitted a
pull request with deb packaging (internal) to the Github project and
tested its building.

It builds indeed fine with rdma-core, it seems.

-- Tzafrir

Bug#944502: Please merge https://salsa.debian.org/libvirt-team/libosinfo/-/merge_requests/1

[Laurent Bigonville]

Hey Guido,

Do you think you could merge the following merge request for libosinfo?

https://salsa.debian.org/libvirt-team/libosinfo/-/merge_requests/1

Kind regards,

Laurent Bigonville

Bug#954801: linux-image-5.4.0-4-amd64: Wireless can't follow some AP's frequency changes in 5 GHz band.

[Miguel A. Vallejo]

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

Dear Maintainer,

I'm experiencing too frecuent WiFi disconnects because the kernel
can't follow or does not understand some AP's frequency changes in the
5 GHz band because of DFS.

For example:

Mar 23 13:54:13 waterhole wpa_supplicant[557]: wlx8c882bxx:
CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5260 ht_enabled=1 ch_offset=1
ch_width=80 MHz cf1=5290 cf2=0
Mar 23 13:54:14 waterhole kernel: [ 8890.628927] wlx8c882bxx: AP
a0:64:8f:xx:xx:xx tries to chanswitch to same channel, ignore
Mar 23 13:54:14 waterhole kernel: [ 8890.628932] wlx8c882bxx: AP
VHT information is invalid, disable VHT
Mar 23 13:54:14 waterhole kernel: [ 8890.628937] wlx8c882bxx: AP
a0:64:8f:xx:xx:xx changed bandwidth, new config is 5260 MHz, width 2
(5270/0 MHz)
Mar 23 13:54:14 waterhole kernel: [ 8890.628939] wlx8c882bxx: AP
a0:64:8f:xx:xx:xx changed bandwidth in a way we can't support -
disconnect
Mar 23 13:54:14 waterhole kernel: [ 8890.628941] wlx8c882bxx:
failed to follow AP a0:64:8f:xx:xx:xx bandwidth change, disconnect
Mar 23 13:54:14 waterhole wpa_supplicant[557]: wlx8c882bxx:
CTRL-EVENT-CHANNEL-SWITCH freq=5260 ht_enabled=1 ch_offset=1
ch_width=80 MHz cf1=5290 cf2=0
Mar 23 13:54:14 waterhole wpa_supplicant[557]: wlx8c882bxx:
CTRL-EVENT-DISCONNECTED bssid=a0:64:8f:xx:xx:xx reason=3
locally_generated=1
Mar 23 13:54:14 waterhole NetworkManager[537]: 
[1584968054.8423] sup-iface[0x557d8e27e110,wlx8c882bxx]:
connection disconnected (reason -3)
Mar 23 13:54:14 waterhole NetworkManager[537]: 
[1584968054.8484] device (wlx8c882bxx): supplicant interface
state: completed -> disconnected
Mar 23 13:54:14 waterhole NetworkManager[537]: 
[1584968054.9478] device (wlx8c882bxx): supplicant interface
state: disconnected -> scanning

Frequency changes to a totally different channel seems to work just
fine, but this kind of changes "to the same channel" produces a
disconnect. My Debian workstation seems to be the only device
disconnected with these frequency changes, other devices like phones,
tablets, or chromecast, connected to the same AP in the 5 GHz band
does not get disconnected.

I'm using a dual band MT7612U 802.11ac wireless stick, but I confirmed
the same problem with a dual band RT3572 802.11n wireless stick.


-- Package-specific info:
** Version:
Linux version 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc
version 9.2.1 20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1
(2020-02-13)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.4.0-4-amd64
root=UUID=ead92695-df4d-4d3a-bcef-821e9595c77b ro quiet


** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: wlx8c882bxx:  mtu 1500 qdisc
noqueue state UP group default qlen 1000
link/ether 8c:88:2b:00:09:64 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global dynamic
noprefixroute wlx8c882bxx
   valid_lft 40493sec preferred_lft 40493sec
inet6 fe80::f538:4992:786:9449/64 scope link noprefixroute
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed
multicast|bytespackets errs drop fifo colls carrier compressed
wlx8c882bxx: 2052858850 15925900   230 0  0
 0 51767728  375986000 0   0  0
lo: 556  12000 0  0 0
556  12000 0   0  0


** USB devices:
Bus 002 Device 002: ID 0e8d:7612 MediaTek Inc. Wireless
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bug#954718: grub-installer: update templates for UEFI and other media than hard disks

[John Paul Adrian Glaubitz]

On 3/23/20 5:43 PM, Holger Wansing wrote:
>> It's not always easy to tell reliably if you're installing to a
>> virtual device. It's still a "drive" as far as most people are
>> concerned, so I'd just stick with that.
> 
> Just trying to improve the old situation "Installing to a hard disk / drive".
> If people think we should stay at that old situation, feel free to ignore this
> bugreport.
> Otherwise provide a better patch, if you can.

I understand your motivation but I don't think you can come up with a
one-fits-all in this situation as there are just too many different
possible combinations of boot loader installation locations (boot sector,
EFI directory, chainloader) and disk types.

While I totally agree that Linux isn't exclusively installed to hard disks *,
I don't think the messages are particularly misleading, especially since
the GRUB sources itself still use the "hard disk" terminology everywhere.

I think "hard disk" is just understood as the generic term for a system
disk on which the operating system is installed and I assume everyone
who understands the concept of disks and partitions would also know
why it's called "hard disk".

Adrian

* = Installing to other drives than hard-disks isn't actually that new,
the NeXT Cube from 1990 didn't actually have a hard disk but an
MO disk as its primary disk drive.

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

Bug#954799: ITA fatsort -- utility for sorting FAT directory structures

[Sebastian Dröge]

On Mon, 2020-03-23 at 17:27 +0100, Jordi Sayol wrote:
> 
> The current maintainer of the fatsort package has given me permission
> to adopt it, so I'll do it if there isn't any inconvenience.

Thanks for taking it over, please just go ahead :)


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

Bug#954718: grub-installer: update templates for UEFI and other media than hard disks

[Holger Wansing]

Hi,

Steve McIntyre  wrote:
> On Sun, Mar 22, 2020 at 04:09:53PM +0100, John Paul Adrian Glaubitz wrote:
> >On 3/22/20 3:59 PM, Holger Wansing wrote:
> >> - MBR is outdated -> UEFI came as a successor;
> >
> >What about the boot mechanisms of all other architectures?
> >
> >Open-Firmware machines use GRUB as well and they have a boot sector.
> >
> >Other architectures use GRUB via chainloading with uboot, so you need
> >to include this well if you want to be comprehensive. And s390x
> >supports GRUB as well.
> >
> >Do you want to include all these, too?
> 
> ACK. Probably worth using more generic terminology if we can. Instead
> of talking about MBR or UEFI at all, maybe just aim for "primary
> drive" or similar?
> 
> >> - hard disks are no longer the only/mainly used storage media (depending on
> >>   architecture); these days we are installing OS'es on SD cards or USB 
> >>   thumbdrives for example.
> >
> >What about virtual devices? Is "drive" appropriate in these cases or should
> >it be "disk image"?
> 
> It's not always easy to tell reliably if you're installing to a
> virtual device. It's still a "drive" as far as most people are
> concerned, so I'd just stick with that.

Just trying to improve the old situation "Installing to a hard disk / drive".
If people think we should stay at that old situation, feel free to ignore this
bugreport.
Otherwise provide a better patch, if you can.


Holger




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

Bug#954729: src:mesa: X won't start after upgrading mesa

[Timo Aaltonen]

On 23.3.2020 18.25, Chow Loong Jin wrote:
> On Mon, Mar 23, 2020 at 01:21:23PM +0200, Timo Aaltonen wrote:
>> On 22.3.2020 20.02, Timo Aaltonen wrote:
>>> On 22.3.2020 17.38, Chow Loong Jin wrote:
 Package: src:mesa
 Version: 20.0.2-1
 Severity: critical
 Justification: breaks the whole system

 Dear Maintainer,

> * What led up to the situation?

 Upgraded mesa packages from 19.3.3-1 to 20.0.2-1.

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

 Tried to boot

> * What was the outcome of this action?

 X wouldn't start (log attached)

> * What outcome did you expect instead?

 X starts.

>>>
>>> Your kernel (4.9) is probably too old for the new iris dri driver.
>>
>> Requires at least 4.16 (while sid has 5.4):
> 
> Thanks. We tried upgrading the kernel to 5.4.0-4, but X didn't start,
> and before we could log into a TTY, it spat a bunch of nouveau-related
> kernel messages and started shutting down on its own.
> 
> Attached is a kern.log that includes a 5.4.0-4-amd64 boot and a
> subsequent successful 4.9.0-7-amd64 boot.
> 

I guess you need to blacklist nouveau for now. File a separate bug on
the kernel for that.


-- 
t



signature.asc
Description: OpenPGP digital signature

Bug#944197: HELP needed for uploading a new upstream version of the Rheolef package

[Pierre Saramito]

Hi Andreas Tille,


From Andreas:
Currently I can only support Covid-19 related
packages (which we try to assemble in Debian Med team currently)


Let me known if I could help the Debian Med team ?
I remain "confined" at home, but I could help (test pkg, ect) ?



please find some other sponsor from Debian Science project.


Is there somebody from the Debian science project
to just help me for uploading the Rheolef-7.1-1 pkg ?
The debianization is ready and well-tested at
  https://salsa.debian.org/science-team/rheolef
It closes the two FTBFS bugs: #944197 and #946116


Best wishes,

Pierre

--
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://ljk.imag.fr/membres/Pierre.Saramito

Bug#954800: baloo-kf5: baloo_file 5.62.0-2 (current testing) crashes on amd64 on database creation

[Joe Kays]

Package: baloo-kf5
Version: 5.62.0-2.1
Severity: important
Tags: newcomer

Dear Maintainer,

current version of baloo_file crashes on database creation on my amd64
(multiarch enabled) system.

The problem is that in engine/database.cpp line 139:

rc = mdb_env_open(..)

returns a non-zero exit code (12: out of memory).

This can be fixed by changing line 125:

size_t sizeInGByte = 256;

to

size_t sizeInGByte = 8;

If I remember correctly 9 was the highest working on my system with 16GB RAM
and ~5GB used (if that has anything to do with it).

I have absolutely no idea why this fixes the problem, but I hope someone else
does and this bug report helps. Thanks!

Best regards
Joe Kays



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

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

Versions of packages baloo-kf5 depends on:
ii  kio  5.62.1-2+b1
ii  libc62.30-2
ii  libkf5baloo5 5.62.0-2.1
ii  libkf5balooengine5   5.62.0-2.1
ii  libkf5configcore55.62.0-1+b1
ii  libkf5coreaddons55.62.0-1
ii  libkf5crash5 5.62.0-1+b1
ii  libkf5dbusaddons55.62.0-1
ii  libkf5filemetadata3  5.62.0-1+b1
ii  libkf5i18n5  5.62.0-1
ii  libkf5idletime5  5.62.0-1+b1
ii  libkf5kiocore5   5.62.1-2+b1
ii  libkf5solid5 5.62.0-2
ii  libqt5core5a 5.12.5+dfsg-9
ii  libqt5dbus5  5.12.5+dfsg-9
ii  libqt5gui5   5.12.5+dfsg-9
ii  libqt5qml5   5.12.5-5
ii  libqt5widgets5   5.12.5+dfsg-9
ii  libstdc++6   10-20200312-2

baloo-kf5 recommends no packages.

baloo-kf5 suggests no packages.

-- no debconf information

Bug#954799: ITA fatsort -- utility for sorting FAT directory structures

[Jordi Sayol]

Package: wnpp
Severity: normal
X-Debbugs-CC: sl...@debian.org

The current maintainer of the fatsort package has given me permission to adopt 
it, so I'll do it if there isn't any inconvenience.

Bug#954448: nextcloud-desktop: Nextcloud client behaves different if started from menu, ~/.config/autostart or from fresh login

[Erich Minderlein]

Please be aware that the pstree-trees must be swapped for a correct 
reference. nextcloud shall be attachde to mate-panel,

not to x-session manager
--

mit freundlichen Grüßen
with the beste regards

cordiallement

Erich |\/|inderlei|\|
--

Bug#954798: lintian: field-too-long checksums-sha256 error

[David Mohammed]

Package: lintian
Version: 2.59.0
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 sbuild -d unstable for the latest version of my package budgie-extras
 threw a policy errors for this particular field

E: budgie-extras changes: field-too-long Checksums-Sha256 (5432 chars > 5000)
E: budgie-extras buildinfo: field-too-long Checksums-Sha256 (5321 chars > 5000)

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

Note - no additional binaries were added in this upload - the new
version of lintian threw up these issues
   * What was the outcome of this action?
 E: budgie-extras changes: field-too-long Checksums-Sha256 (5432
chars > 5000)
 E: budgie-extras buildinfo: field-too-long Checksums-Sha256 (5321
chars > 5000)
   * What outcome did you expect instead?
 I wasnt expecting this issue.  It does seem a little restrictive especially
 since the sha256 field checksum for each of the binaries is relatively long
 as you would expect.
 I suppose I could "split" the package rather artificially - maybe
 one python based binaries and one vala based binaries with the current
 budgie-extras package as a "metapackage" - I'm really seeking advice
 how too proceed - I don't want to upload the fixes with these
 lintian errors that break policy

attached are the changes and buildinfo files


budgie-extras_0.94.0-1_amd64.buildinfo
Description: Binary data


budgie-extras_0.94.0-1_amd64.changes
Description: Binary data

Bug#954797: ITP: thom2 -- Thomson TO7 Emulator

[Jean Philippe EIMER]

Package: wnpp
Severity: wishlist
Owner: Jean Philippe EIMER 

* Package name: thom2
  Version : 2.3.0
  Upstream Author : Jean Philippe EIMER 
* URL : https://sourceforge.net/projects/thom2/
* License : GPL
  Programming Lang: C
  Description : Thomson TO7 Emulator

GTK2/GTK3 Thomson TO7 Emulator for Linux.
The Thomson TO7 is a French personal computer popular in the 1980s.
It's based on the 6809 processor, and runs a 1982 Microsoft Basic.

This emulator needs binary/ROM files to be copied in /usr/share/thom.
They are not provided in the package for copyright reasons, but can be
downloaded from: http://dcmoto.free.fr
* to770.rom : mandatory, main ROM
* cd90-640.rom : optional, for floppy disk
* memo7/basic.m7 or memo7/basic128.m7 : mandatory, interface and for programs
written in Basic

Thom2 is a fork of Thom, an old and unmaintained version from Sylvain Huet and
Eric Botcazou.
It provides several updates, enhancements and improvements.

Bug#951893: subversion FTBFS with swig 4.0.1

[Lucas Kanashiro]

On Sat, 22 Feb 2020 22:04:09 -0500 James McCoy  wrote:
>
> I might need to wait for the next upstream release.

FWIW, we applied the attached patch in Ubuntu to make src:subversion
build against swig 3.0 for now. If you could apply this patch it'd be
great because at the moment we are trying to rebuild src:subversion to
remove ruby 2.5 support from the archive and it is failing due to the
lack of swig 4.0 support:

https://release.debian.org/transitions/html/ruby2.5-rm.html

-- 
Lucas Kanashiro

diff -Nru subversion-1.13.0/debian/control subversion-1.13.0.new/debian/control
--- subversion-1.13.0/debian/control2020-01-19 10:59:14.0 -0300
+++ subversion-1.13.0.new/debian/control2020-03-23 11:39:46.474677200 
-0300
@@ -32,7 +32,7 @@
rename,
ruby,
ruby-dev,
-   swig,
+   swig3.0,
zlib1g-dev
 Build-Conflicts: libsvn-dev (<< 1.13~)
 Rules-Requires-Root: no
diff -Nru subversion-1.13.0/debian/patches/fix-swig-ruby-includes.patch 
subversion-1.13.0.new/debian/patches/fix-swig-ruby-includes.patch
--- subversion-1.13.0/debian/patches/fix-swig-ruby-includes.patch   
1969-12-31 21:00:00.0 -0300
+++ subversion-1.13.0.new/debian/patches/fix-swig-ruby-includes.patch   
2020-03-23 11:39:46.450677157 -0300
@@ -0,0 +1,15 @@
+Description: Do not include ruby include subdir which has headers that
+ clash with standard ones, such as assert.h.
+Author: Dimitri John Ledkov 
+
+--- a/build/ac-macros/swig.m4
 b/build/ac-macros/swig.m4
+@@ -168,7 +168,7 @@
+ AC_CACHE_CHECK([for Ruby include path], [svn_cv_ruby_includes],[
+ if test -d "$rbconfig_rubyhdrdir"; then
+   dnl Ruby >=1.9
+-  svn_cv_ruby_includes="-I. -I$rbconfig_rubyhdrdir 
-I$rbconfig_rubyhdrdir/ruby -I$rbconfig_rubyhdrdir/ruby/backward"
++  svn_cv_ruby_includes="-I. -I$rbconfig_rubyhdrdir 
-I$rbconfig_rubyhdrdir/ruby/backward"
+   if test -d "$rbconfig_rubyarchhdrdir"; then
+ dnl Ruby >=2.0
+ svn_cv_ruby_includes="$svn_cv_ruby_includes 
-I$rbconfig_rubyarchhdrdir"
diff -Nru subversion-1.13.0/debian/patches/series 
subversion-1.13.0.new/debian/patches/series
--- subversion-1.13.0/debian/patches/series 2020-01-19 10:59:14.0 
-0300
+++ subversion-1.13.0.new/debian/patches/series 2020-03-23 11:39:46.450677157 
-0300
@@ -11,3 +11,4 @@
 examples-compile-instructions
 workaround_EINVAL_on_kfreebsd
 use-python2-as-the-interpreter-now-for-tests-not-python.patch
+fix-swig-ruby-includes.patch
diff -Nru subversion-1.13.0/debian/rules subversion-1.13.0.new/debian/rules
--- subversion-1.13.0/debian/rules  2020-01-19 10:59:14.0 -0300
+++ subversion-1.13.0.new/debian/rules  2020-03-23 11:39:46.474677200 -0300
@@ -100,7 +100,7 @@
--with-sasl=/usr \
--with-editor=/usr/bin/editor \
--with-ruby-sitedir=/usr/lib/ruby \
-   --with-swig=/usr/bin/swig \
+   --with-swig=/usr/bin/swig3.0 \
--with-lz4 \
--with-utf8proc \
CFLAGS="$(CFLAGS)" \

Bug#953062: Update

[Ryan A. Pavlik]

So, with 2020.03+dfsg1-1 uploaded (which contains the Build-Depends on
libqt5opengl5-desktop-dev, as appears to be the intended behavior), I
still see the following on https://tracker.debian.org/pkg/meshlab:

Migration status for meshlab (- to 2020.03+dfsg1-1): BLOCKED:
Rejected/violates migration policy/introduces a regression
Issues preventing migration:
meshlab unsatisfiable Build-Depends(-Arch) on armel: libqt5opengl5-
desktop-dev
meshlab unsatisfiable Build-Depends(-Arch) on armhf: libqt5opengl5-
desktop-dev

Using Debian code-search, I've looked for other packages with that
build-dep, and all of the ones I've looked at have "any" as their
binary architecture, just like meshlab - they don't explicitly list all
non-armel+armhf arches. (Have looked at openms, doomsday, krita,
qwtplot3d, enki-aseba, dustrac, deepin-movie-reborn, fracplanet)

Does someone need to authorize some override to allow migration into
testing? (Given the lack of desktop OpenGL, I don't expect meshlab to
be buildable for armel/armhf any time soon.)

Ryan

Bug#954796: sqldeveloper.19.2.1.247.2212 requires libgail-common

[Harald Dunkel]

Package: sqldeveloper-package
Version: 0.5.4

Apparently sqldeveloper.19.2.1.247.2212 (generated via 
make-sqldeveloper-package)
has some additional dependencies:


 Oracle SQL Developer
 Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights reserved.

Gtk-Message: 11:42:49.640: Failed to load module "gail"

** (java:31781): WARNING **: 11:42:49.674: 
(../atk-adaptor/bridge.c:993):atk_bridge_adaptor_init: runtime check failed: 
(root)


After installing libgail-common this message went away.


Can you reproduce this problem?

Regards
Harri

Bug#952025: ruby-grape: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: spec = parsers(**options)[api_format]

[Daniel Leidert]

Package: src:ruby-grape
Followup-For: Bug #952025

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This issue has already been fixed upstream. The patch probably was:
https://github.com/ruby-grape/grape/commit/84320ad4aa1083b6d2dd396d697d0426c560e2a5.patch

Release version 1.3.0 has this fix included and is in experimental. Maybe this
should be uploaded to unstable then?

Regards, Daniel


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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl541ekACgkQS80FZ8KW
0F3xVhAAiuMD9+VPlM5oEa9iknj0507ANJqVOZFRsbEFeEZRNx/XcCD1Dgsm8fOX
ceD2p0vZhsQxxsxr0ugGYKTeJQXJcyGZeByJPRf9qZeqDYrXpNbTp2RB9E47QwyX
VAG6zc1lm5L3ZpqA/n1+0d4XFCpVX658UvAOFmQ8PSL+zlbCvvCVrBZjZsv+zQNw
+VNmguD8F8enjOgvq1wkLQhf8Up9isYGjBvo3JEpYIaJbm+TvpCY2f3EDnm3zVZI
aCy42Tof1NOjMulfMvWCPWQHOIX7kM4g9KGQ8gfz1k5I8Yb0MLrhqIZ1co2nW5L8
PPVIEka/3kTj5b2fce7dt2FNoNTdV09037yL+p7Oj0Fdbqiwyu9zIIgIQmHnfoMh
cAkQ2bfJKci7OY/S4aecptXds8Q7XsP7vcZaQH0Ww9SSdFKF026suoPuKPDG2Ntm
K25wp3eljz47Ga8TWTRpdMEAV1eqrb1PHRgOJGEwd3xnc36TGs4itPxaEw5gWJbl
HDQjlyJPpEQvNpCNyWYBWssU+HNEt0gc53o1ouKut3+X5Ry0u+n7jtJrooDUgGiL
WNvYX8VW522uq/lbv9SZUoESxt12iIlc5MZx+ZFRNNp1YiJkTnb01oLt9DS/M3Tc
IQmrCFgviAAH65BaMoTk9PtStSCOTyweZM/qqC1gwFCSV2A8lXc=
=NaMr
-END PGP SIGNATURE-

Bug#954794: New packages must not declare themselves Essential

[Bill Allombert]

On Mon, Mar 23, 2020 at 08:00:04AM -0700, Josh Triplett wrote:
> Package: debian-policy
> Version: 4.5.0.0
> Severity: normal
> Tags: patch
> 
> Previously discussed on the mailing list, which led to a request for
> concrete Policy language.

I do not think this proposal make sense _as a Debian policy change_.
What I mean is that if the release team decide that some new packages
need to be marked Essential: yes for some technical reason, then either
policy will be ignored and this change will be reverted. Or maybe the
bug will be serious but not RC.

Remember as Manoj used to say, policy is no a stick to beat people with.

Cheers,
Bill.

Bug#954795: debtree: Error with 'gcc' as argument

[Alexandros Prekates]

Package: debtree
Version: 1.0.10+nmu1
Severity: normal

Dear Maintainer,

While executing 'debtree gcc' i get
..
..
..
"gcc" -> "gcc" [color=red];
"gcc" -> "gcc:amd64" [arrowhead=inv,color=green];
"gcc:amd64" [shape=octagon];
"gcc" -> "gcc-x86-64-linux-gnu" [arrowhead=inv,color=green];
Can't use string ("") as a HASH ref while "strict refs" in use at
/usr/bin/debtree line 325.



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

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

Versions of packages debtree depends on:
ii  dctrl-tools  2.24-3
ii  libapt-pkg-perl  0.1.34+b1
ii  perl 5.28.1-6
ii  ucf  3.0038+nmu1

Versions of packages debtree recommends:
ii  graphviz  2.40.1-6

debtree suggests no packages.

-- no debconf information

Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform

[Alexandre Viau]

On Mon, Mar 23, 2020 at 11:21 AM Felix Salfelder  wrote:
> Afaiu, the bottleneck will be opendht. opendht is already packaged, but
> too old.

No, it won't. Why would it be a bottleneck?

Newer OpenDHT versions also **require restinio**.

We need to package restinio. This is the first step. Nothing else.

If you are really interested in helping with the efforts to update
Jami, it is the place to start.

Bug#950198: RFH: ring -- Secure and distributed voice, video and chat platform

[Felix Salfelder]

Dear Alexandre.

> It looks like you are trying to do many things at once.
>
> Instead of trying to fix everything in one go, I would suggest that we
> pick one problem and move from there.

Thanks for your feedback.

I tried to update my Jami installation, when connections to newer Jami
clients broke down, unfortunately. The fresh version is working for me.

> How about we start by packaging restinio in Debian? I'd gladly sponsor
> such an upload.

I can see an upper bound to the efforts required to update Jami. The
restinio package is not my primary interest. But will try to allocate
some time for it [1].

Afaiu, the bottleneck will be opendht. opendht is already packaged, but
too old. The required version is unreleased (2.0.0rc2). What does it
take to have a release candidate in Debian?

best regards
felix

[1] https://salsa.debian.org/felixs-guest/restinio

Bug#954794: New packages must not declare themselves Essential

[Josh Triplett]

Package: debian-policy
Version: 4.5.0.0
Severity: normal
Tags: patch

Previously discussed on the mailing list, which led to a request for
concrete Policy language.

Over the years, "Essential" has made it difficult to reduce installation
size, to reduce chroot/container size, or to coordinate various
transitions. Removing something from the Essential set requires tracking
down every package using it, adding a dependency, carefully managing a
transition across Debian releases, and risking breakage of third-party
packages outside Debian.

Add language to Policy that still allows existing Essential packages to
refactor or transition to different packages (coordinated via
debian-devel) but does not allow new Essential packages.

Also add language that allows packages to declare dependencies on
Essential packages as part of transitions (such dependencies would
previously violate Policy, technically), and soften language that
connects "base system" with "essential".

This change does not propose eliminating the concept of Essential, nor
does it propose that any specific package become non-Essential.

Patch attached; also available at
https://salsa.debian.org/josh-guest/policy/ on the branch
no-new-essential.

- Josh Triplett
>From a4b263709ed183e8b353c669e0e56e225ef8c818 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Josh Triplett 
Date: Mon, 23 Mar 2020 07:11:27 -0700
Subject: [PATCH] New packages must not declare themselves Essential

Over the years, "Essential" has made it difficult to reduce installation
size, to reduce chroot/container size, or to coordinate various
transitions. Removing something from the Essential set requires tracking
down every package using it, adding a dependency, carefully managing a
transition across Debian releases, and risking breakage of third-party
packages outside Debian.

Add language to Policy that still allows existing Essential packages to
refactor or transition to different packages (coordinated via
debian-devel) but does not allow new Essential packages.

Also add language that allows packages to declare dependencies on
Essential packages as part of transitions (such dependencies would
previously violate Policy, technically), and soften language that
connects "base system" with "essential".

This change does not propose eliminating the concept of Essential, nor
does it propose that any specific package become non-Essential.
---
 policy/ch-binary.rst | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
index 74a1690..ac0623f 100644
--- a/policy/ch-binary.rst
+++ b/policy/ch-binary.rst
@@ -247,7 +247,9 @@ package.
 
 Packages are not required to declare any dependencies they have on other
 packages which are marked ``Essential`` (see below), and should not do
-so unless they depend on a particular version of that package.  [#]_
+so unless they depend on a particular version of that package, or unless
+part of a transition to make the ``Essential`` package no longer
+``Essential``.  [#]_
 
 Sometimes, unpacking one package requires that another package be first
 unpacked *and* configured. In this case, the depending package must
@@ -299,7 +301,7 @@ are allowed to form part of the base system, in order to 
keep the
 required disk usage very small.
 
 The base system consists of all those packages with priority
-``required`` or ``important``. Many of them will be tagged ``essential``
+``required`` or ``important``. Some of them are tagged ``essential``
 (see below).
 
 .. _s3.8:
@@ -335,9 +337,14 @@ never done. Any capability added to an ``essential`` 
package therefore
 creates an obligation to support that capability as part of the
 Essential set in perpetuity.
 
-You must not tag any packages ``essential`` before this has been
-discussed on the ``debian-devel`` mailing list and a consensus about
-doing that has been reached.
+New packages must not declare themselves ``essential``, even if this
+requires many other packages to declare explicit dependencies on them.
+Existing ``essential`` packages may continue to use the ``essential``
+flag in new versions. If an existing ``essential`` package needs to
+change its packaging structure in a way that would introduce a new
+package with the ``essential`` flag, this must be discussed on the
+``debian-devel`` mailing list and a consensus and transition strategy
+for doing so must be reached."
 
 .. _s-maintscripts:
 
-- 
2.26.0.rc2

Bug#954783: Non-functioning gnome-apps after mate-session due to surviving CLUTTER_BACKEND env var

[Simon McVittie]

Control: reassign -1 
libclutter-1.0-0,gnome-session-common,debian-mate-default-settings
Control: found -1 clutter-gtk/1.8.4-4
Control: found -1 gnome-session/3.30.1-2
Control: found -1 mate-session-manager/1.24.0-2

On Mon, 23 Mar 2020 at 13:32:58 +0100, Dimitri Schwarz wrote:
> In short: When running a mate session the environment-variable
> CLUTTER_BACKEND=x11 is set. This variable survives a logout and relogin into
> the GNOME wayland-session, which doesn't override it. The result is a bunch
> of not launchable clutter-gtk applications.

I think this is at least partially a debian-mate-default-settings bug. For
now I've assigned it to all three involved packages (clutter uses the
variable, MATE sets it, GNOME doesn't unset it); it might make sense to
change more than one of these packages.

Full text quoted for the MATE maintainers:

> To reproduce the issue:
>  * Install debian 10.3.0 with gnome and mate environment
>  * Optional:
>  * Login into GNOME (wayland) Session
>  * Run `env | grep -Ei 'x11|wayland'`
> XDG_SESSION_TYPE=wayland
> WAYLAND_DISPLAY=wayland-0
>  * Note: CLUTTER_BACKEND is not set
>  * Launch `gnome-control-center` via graphical environment or console
> * Works fine
>  * Logout
>  * Login into MATE session
>  * `env | grep -Ei 'x11|wayland'`
> CLUTTER_BACKEND=x11
> XDG_SESSION_TYPE=x11
>  * `sudo grep -Ri CLUTTER_BACKEND /etc/`
> /etc/X11/Xsession.d/99mate-environment:export CLUTTER_BACKEND=x11
>  * Logout
>  * Login into GNOME (wayland) session
>  * `env | grep -Ei 'x11|wayland'`
> CLUTTER_BACKEND=x11 # <- survived!
> XDG_SESSION_TYPE=wayland
> WAYLAND_DISPLAY=wayland-0
>  * Launch `gnome-control-center` via graphical environment or console
>  * Observe it doesn't startup
> (gnome-control-center:4399): Clutter-Gtk-ERROR **: 12:23:42.914: *** 
> Unsupported backend.
>  * In fact all of the following apps terminate the same way
>  * `compgen -c | while read cmd; do [ -n "$(which $cmd)" ] && ldd 
> $(which $cmd) | grep -q clutter-gtk && echo $cmd; done`
> cheese
> totem
> evolution
> gnome-control-center
> gnome-contacts
> cheese
> totem
> evolution
> gnome-control-center
> gnome-contacts
> gnome-nibbles
> swell-foop
> lightsoff
> quadrapassel
>  * Now launch `CLUTTER_BACKEND=wayland gnome-control-center`
> * Works fine
> 
> So I suppose the surviving of session-variables is the core issue here. In
> case of it beeng rather a feature than a bug, I suppose gnome should set
> CLUTTER_BACKEND explicitly aswell. Or maybe clutter-gtk shall respect this
> constellation of CLUTTER_BACKEND and GDK_WAYLAND_DISPLAY?

For context, GNOME normally provides both a Wayland compositor
(gnome-shell's native protocol) and an X11 display (Xwayland, backed by
gnome-shell). I think MATE only has an X11 display (Xorg).

Clutter is a scene-graph library that is essentially unmaintained
upstream, but unfortunately some important apps that started using it
when it was the next big thing are still using it, both within GNOME
(Totem is a good example) and outside GNOME. It is meant to be replaced
by the GSK layer in GTK 4, but GTK 4 is not yet stable, and until it
is, we don't have any properly maintained scene-graph available. Some
upstream and downstream GNOME developers keep Clutter on life-support so
that apps like Totem will still work, but our ability to make significant
changes is very limited. Clutter's supporting library Cogl is in a
similar situation.

To give you an idea of the size of the problem, Clutter is sufficiently
unmaintained that the mutter compositor used in GNOME (and Budgie)
now contains its own fork of Clutter and Cogl, with the parts that it
doesn't use deleted to reduce maintenance effort.

Meanwhile, GTK 3 prefers to use Wayland when available, via the "wayland"
backend in GDK. It can also use X11, via the "x11" backend (which will
be used in MATE and other X11-only desktop environments, or in GNOME
when Wayland is disabled, or when forced with GDK_BACKEND=x11).

Clutter *also* works on either Wayland or X11. It has a "new" backend,
gdk (which uses the same GDK library as GTK does), and an "old" backend,
x11 (which is X11-only). By default it will switch between backends
automatically, and I think it prefers the "gdk" backend, but it will
use x11 if forced via CLUTTER_BACKEND=x11 (as MATE currently does).

If we ever get into a situation where GTK has chosen to use Wayland,
but Clutter has chosen to use the x11 backend, then we have a problem,
because those are not a combination that can work: Clutter isn't going
to get very far by trying to integrate with a GTK application that is
using an incompatible display protocol. Ordinarily, this doe

Bug#952022: ruby-puppet-syntax: FTBFS: ERROR: Test "ruby2.7" failed: LoadError:

[Daniel Leidert]

Package: src:ruby-puppet-syntax
Followup-For: Bug #952022

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The formentioned issue can probably be closed by applying this patch:

- --- a/lib/rspec-puppet/support.rb
+++ b/lib/rspec-puppet/support.rb
@@ -440,7 +440,7 @@
 end
 
 def escape_special_chars(string)
- -  string.gsub!(/\$/, "\\$")
+  string.gsub(/\$/, "\\$")
   string
 end

But then there are new errors (see below). I'll stop here and leave this to
someone more experienced. So if anyone wants to go on, please feel free to do
so.

Regards, Daniel



Failures:

  1) escape is expected to contain File[/tmp/escape] with content =~ /\$MSG foo/
 Failure/Error: Puppet::Resource::Catalog.indirection.find(node.name, 
:use_node => node)

 Puppet::ParseErrorWithIssue:
   Could not parse for environment rp_env: Illegal variable name, The given 
name 'MSG' does not conform to the naming rule 
/^((::)?[a-z]\w*)*((::)?[a-z_]\w*)$/ (line: 52, column: 31) on node (node's 
fully qualified domain name)
 # ./lib/rspec-puppet/adapters.rb:84:in `catalog'
 # ./lib/rspec-puppet/adapters.rb:162:in `catalog'
 # ./lib/rspec-puppet/support.rb:415:in `build_catalog_without_cache'
 # ./lib/rspec-puppet/support.rb:426:in `block in build_catalog'
 # ./lib/rspec-puppet/cache.rb:17:in `get'
 # ./lib/rspec-puppet/support.rb:425:in `build_catalog'
 # ./lib/rspec-puppet/support.rb:90:in `block in load_catalogue'
 # ./lib/rspec-puppet/support.rb:376:in `with_vardir'
 # ./lib/rspec-puppet/support.rb:83:in `load_catalogue'
 # ./lib/rspec-puppet/example/class_example_group.rb:7:in `catalogue'
 # ./lib/rspec-puppet/support.rb:12:in `block in subject'
 # ./lib/rspec-puppet/matchers/create_generic.rb:84:in `matches?'
 # ./spec/classes/escape_spec.rb:6:in `block (2 levels) in '

  2) escape::def is expected to contain File[/tmp/bla] with content =~ /bar 
\$BLA/
 Failure/Error: Puppet::Resource::Catalog.indirection.find(node.name, 
:use_node => node)

 Puppet::ParseErrorWithIssue:
   Could not parse for environment rp_env: Illegal variable name, The given 
name 'BLA' does not conform to the naming rule 
/^((::)?[a-z]\w*)*((::)?[a-z_]\w*)$/ (line: 52, column: 43) on node (node's 
fully qualified domain name)
 # ./lib/rspec-puppet/adapters.rb:84:in `catalog'
 # ./lib/rspec-puppet/adapters.rb:162:in `catalog'
 # ./lib/rspec-puppet/support.rb:415:in `build_catalog_without_cache'
 # ./lib/rspec-puppet/support.rb:426:in `block in build_catalog'
 # ./lib/rspec-puppet/cache.rb:17:in `get'
 # ./lib/rspec-puppet/support.rb:425:in `build_catalog'
 # ./lib/rspec-puppet/support.rb:90:in `block in load_catalogue'
 # ./lib/rspec-puppet/support.rb:376:in `with_vardir'
 # ./lib/rspec-puppet/support.rb:83:in `load_catalogue'
 # ./lib/rspec-puppet/example/define_example_group.rb:7:in `catalogue'
 # ./lib/rspec-puppet/support.rb:12:in `block in subject'
 # ./lib/rspec-puppet/matchers/create_generic.rb:84:in `matches?'
 # ./spec/defines/escape_def_spec.rb:7:in `block (2 levels) in '




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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl54zT4ACgkQS80FZ8KW
0F16iRAAhCzC8ny3ofA8J3tjEAQ2/E+bP8FR7fH+WmGxvKhkdNMpZPMpsrjHvgu8
8A434pd+E4wzAAPbnmcuv6iNSqJS9KVU4pkaTXEpSdgGaa+9WqUO6I0adBC2kZ0Y
mjQa4/sLiWCjd5vLsqgG2idNwhMQLUc3AxIBTdBHRJSsPB0pYRfv3iRUSKT4m1Te
Wd4YsW9W7pyUmCNkEfmnEMLzOnkkIqA8a/+JJPRYhPUD+eTIBIWBB2DAZLQKbgwt
eMfwkIlvo5AlE916t9B6iPZRt2ScEXseJp7DGUBa/wxXFj0HIwq5qi5EgPHgAKQO
v4g23yU9dApPImIowTK0obsHkUuy6fu/aA3uePtVyC6dprwJIw8+E7VAQJG+awuz
E3/mMZzj5PAMYg1pb/EgSFifRY1kRb68vtmOZ+kch9opgIKt//MG8iaX//f9O4o0
XwR/YLgcmYLUp+UhPUevW+vhVUR5Z/rUk3YXrD+8SASmzAimxYfQcOvv+2hPlNTh
GBis3FDKztnXuUhBt+cRMr+ISnJiIzhh7hviwgBO7E6/8wow/UDX5pwwVvzc71Ad
sgtFVFxRdeXn1XxI0zJem1vHJXh6nNr2I7FZv8sI7hGaPKlT3o+wsF5P+VusDzFR
NggIa0eEl8EC5PjJcMTyVND8wRysYC9XE1e6CxZleq6VEtfqefI=
=E+Lb
-END PGP SIGNATURE-

Bug#954793: ITP: golang-github-caddyserver-certmagic -- Automatic HTTPS using Let's Encrypt

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 

* Package name: golang-github-caddyserver-certmagic
  Version : 0.10.4-1
  Upstream Author : Caddy
* URL : https://github.com/caddyserver/certmagic
* License : Apache-2.0
  Programming Lang: Go
  Description : Automatic HTTPS using Let's Encrypt

Mature and reliable ACME client integration for Go.
Provides a simple interface for a go HTTP server:
- handles redirection to HTTPS automatically
- obtain and renew TLS certificates
- staples OCSP responses

CertMagic supports the full suite of ACME features.

It's a dependency of acme-dns package, and looks quite nice on its own.

Bug#954792: xfsdump: xfsrestore does not recreate missing inventory information

[root]

Package: xfsdump
Version: 3.1.6+nmu2+b1
Severity: normal

Dear Maintainer,

The xfsrestore man page states:

"
 An additional media file is placed at the end of each dump stream.  This media 
file contains the inventory information for the cur‐
 rent dump session.  If the online inventory files in 
/var/lib/xfsdump/inventory are missing information for the current  dump  ses‐
 sion,  then  the inventory information in the media file is automatically 
added to the files in /var/lib/xfsdump/inventory.  If you
 wish to incorporate the inventory information from the media file without 
restoring any data, you may do so using the -t option:

# xfsrestore -t -f /dev/tape

 This is useful to rebuild the inventory database if it is ever lost or 
corrupted.
"

However, I am observing that xfsrestore does not add this missing inventory 
information.

To reproduce

1) dump an XFS filesystem and note how new inventory information appears in 
/var/lib/xfs‐dump/inventory

For example (using a 50MiB loop device to demonstrate)

# ls /var/lib/xfsdump/inventory

Note the inventory files.

# dd if=/dev/zero of=/tmp/dump_test.img bs=$((1024*1024)) count=50
# mkfs.xfs /tmp/dump_test.img
# mount /tmp/dump_test.img /mnt -o loop
# xfsdump -F -L0 -f /tmp/dump_test.dump /mnt
# umount /mnt

# ls -l /var/lib/xfsdump/inventory

Note how the xfsdump will have created an inventory file

2) remove inventory file from /var/lib/xfs‐dump/inventory

rm previously noted file.

3) list contents of dump file

# xfsrestore -t -f /tmp/dump_test.dump

4) Observe xfsrestore has not recreated the missing inventory information (file 
deleted in 2)


This behaviour is inconsistent with the man page which indicates that 
xfsrestore can be used to rebuild the inventory database if it is ever lost or 
corrupted.

I noticed this with xfsrestore 3.1.6 (on a Debian 9.12 host), then I git cloned 
xfsdump-dev, built from source and observed the same behaviour in xfsrestore 
3.1.9.




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

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

Versions of packages xfsdump depends on:
ii  libattr1 1:2.4.47-2+b2
ii  libc62.24-11+deb9u4
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libtinfo56.0+20161126-1+deb9u2
ii  libuuid1 2.29.2-1+deb9u1
ii  xfsprogs 4.9.0+nmu1

xfsdump recommends no packages.

Versions of packages xfsdump suggests:
ii  acl2.2.52-3+b1
ii  attr   1:2.4.47-2+b2
pn  quota  

-- no debconf information

Bug#954788: nvidia-legacy-check can't be installed

[Andreas Beckmann]

On 23/03/2020 15.16, Stefano Simonucci wrote:
> when I try to install the package nvidia-legacy-check (in order to install 
> nvidia-cuda-toolkit) I get the 
> following message:
> *** The following unsupported devices are present in the machine:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119M [GeForce 
> GT 
> 520MX] [10de:1051] (rev a1)
> Aborting nvidia driver installation.

> So I'm not able to install nvidia-cuda-toolkit with my GPU.

Because it wouldn't work.

The corresponding NEWS entry in the driver packages:

nvidia-graphics-drivers (396.18-1) experimental; urgency=medium

  LEGACY GPUs: If you have a GeForce 410M/510/605/610M/705M/710M/810M/820M,
  GeForce GT 415M/420/420M/425M/430/435M/440/445M/520/520M/520MX/525M/530,
  GeForce GT 540M/545/550M/555M/560M/610/620/620M/625/625M/630/630M/635M,
  GeForce GT 640/640M/645/705/720M/730, GeForce GTS 450,
  GeForce GTX 460/460M/465/470/470M/480/480M/485M/550/555/560/570/570M/580,
  GeForce GTX 580M/590/670M/675M, NVS 310/315/4200M/5200M/5400M,
  Quadro 500M/600/1000M/2000/2000M/3000M/4000/4000M/5000/5000M/5010M/6000,
  Quadro 7000, Quadro NVS 4200M, Tesla C2050/C2070/C2075/M2070/M2075/M2090,
  Tesla T20, i.e., any GPU based on the GF100/GF100M/GF100GL/GF100GLM,
  GF104/GF104M/GF104GLM, GF106/GF106M/GF106GL/GF106GLM,
  GF108/GF108M/GF108GL/GF108GLM, GF110/GF110GL, GF114/GF114M, GF116/GF116M,
  GF117M, GF119/GF119M chips or a variant thereof (that is anything from
  the Fermi architecture),
  DO NOT INSTALL THIS RELEASE!!!
  Use the nvidia-legacy-390xx-driver, nvidia-legacy-390xx-kernel-dkms
  packages instead.

 -- Andreas Beckmann   Sun, 22 Apr 2018 13:59:45 +0200

IIRC, CUDA 9.1 (in stretch-backports) was the last CUDA toolkit version
that works with the 390 legacy driver series.

Andreas

Bug#954791: Please reenable plugins that have been ported to GTK3 and/or webkit2gtk-4.0

[Laurent Bigonville]

Source: geany-plugins
Version: 1.36+dfsg-1
Severity: wishlist
Control: forwarded -1 
https://salsa.debian.org/geany-team/geany-plugins/-/merge_requests/1

Hi,

Could you please reeanble the plugins that have been ported to GTK3 and/or 
webkit2gtk-4.0

Pull request is ready at 
https://salsa.debian.org/geany-team/geany-plugins/-/merge_requests/1

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy