Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0

[Sebastiaan Couwenberg]

On 2/24/21 8:04 AM, Kai Pastor, DG0YT wrote:
> Am 24.02.21 um 05:55 schrieb Sebastiaan Couwenberg:
>> On 2/24/21 12:58 AM, Kai Pastor, DG0YT wrote:
>>> Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg:
 It's good practice to include the Find modules for any dependencies
 that
 are not part of cmake itself to not need upstream projects to install
 cmake modules for them.
>>> I think it is deprecated legacy practice, not good practice. Find
>>> modules are poorly standardized, poorly maintained, and poorly tested.
>>> It would be much better to provide PROJ config files as soon as
>>> possible, instead of letting more developers start using PROJ with
>>> non-standard find modules picked from random internet locations.
>>>
>>> I wonder if there is a blocker for building debian PROJ with CMake. I
>>> build PROJ for Android, macOS, Windows from Debian tarballs - with
>>> cmake, not using debian/rules.
>>> https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake
>>>
>> Switching from autotools to cmake is generally a regression, cmake
>> doesn't handle multiarch as well, and because it uses absolute paths
>> instead of relative paths it hinders reproducible builds.
>>
>> See the recent discussion on the geos-devel lists for example:
>>
>>   https://lists.osgeo.org/pipermail/geos-devel/2021-January/010078.html
> 
> From the mailing list post and its links I learn that
> 
> a) actively maintained projects do fix reported build system issues
> quickly.
> 
> b) there is some confusion about dealing with CMAKE_BUILD_TYPE, NDEBUG
> and reproducible paths.
> 
> I would agree that many projects have shortcoming in how they use CMake,
> partly due to past shortcomings of CMake and its documentation, partly
> due to ignorance of cross-platform building and packaging. But IMO it
> goes to far when you imply that CMake is to blame for issues with paths
> and reproducibility.

CMake uses abolute paths, whereas autotools uses relative paths. How is
CMake not to blame from issues that arise from that?

> (Is there a Debian documentation for how to prepare CMake projects to
> help with Debian multi-arch?)

No that I know of, it would be good to have this in the upstream guide:

 https://wiki.debian.org/UpstreamGuide

FWIW cmake/ProjInstallPath.cmake uses CMAKE_INSTALL_LIBDIR so it would
do the right thing.

>>> The CMake build of PROJ doesn't seem to provide a pkgconfig file, but
>>> even for mips64el, the single proj.pc looks much less complex than the
>>> set of cmake config files, or the patch proposed for FindProj4.cmake.
>> We're not going to switch to cmake for the proj package as long as
>> autotools is supported, because that is the best build system from a
>> packaging point of view.
> 
> Okay, so this covers your packaging point of view where autotools are
> already available. But it doesn't align with my requirements as a
> developer, and also not with my experience in single-arch
> bundling/packaging third-party components for Android, macOS, Windows.
> 
> (And I wouldn't even say that CMake is the best system for some purpose.)

PROJ supports CMake in addition to autotools for platforms like Windows
for similar reasons.

You're not the only upstream who is unhappy that the proj package in
Debian doesn't install the CMake bits, and as explained to support
projects using CMake better PROJ should also install the cmake bits when
it's built with Autotools.

No one has been willing to implement that so far. That is the problem we
need to solve. At least there is an upstream issue for it now:

 https://github.com/OSGeo/PROJ/issues/2546

>> The best solution for downstream projects not wanting to include their
>> own FindProj modules is to update the autotools build system to also
>> install the cmake bits. Perhaps you can provide a patch for that which
>> PROJ upstream can merge?
> 
> No, I don't think learning autotools and then teaching autotools to
> provide CMake config files, possibly for multi-arch, is a good use of my
> resources. But you may ask for patches for PROJ's CMake build system.
> Multiarch if I can test/verify in an amd_64 environment.

Since your more comfortable with CMake, maybe you can help upstream the
pkg-config patch so that the Fedora package doesn't have to patch the
CMake build to have proj.pc installed.

We really need to get downstream projects more involved in PROJ
development to help support their needs.

Kind Regards,

Bas

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

Bug#983440: Man page several versions out of step with the program

[積丹尼 Dan Jacobson]

Package: black
Version: 20.8b1-4
File: /usr/share/man/man1/black.1.gz

Man page several versions out of step with the program. E.g.,
$ black --py36
...
Error: no such option: --py36

Bug#983179: zfs-dkms: fails to build with backports kernel 5.10.0-0.bpo.3-amd64

[Antonio Russo]

Control: fixed -1 2.0.2-1

Hello,

Unfortunately, it took a while to get 2.0 into backports.  This should
now be resolved.  That said, if you look at the bug reports for ZFS,
there's a recurring theme---people often upgrade their kernel and find
that ZFS is not compatible.  You point out:

> btw: Is there any way I can tell the kernel installer or the initramfs
> creation to fail if the the ZFS module has not been compiled?

I think that we should consider

 - Warning the user if the ZFS does not explicitly support an installed
   version of Linux
 - Warning the user more loudly if the DKMS build fails

The second of these is a DKMS feature, I think.

Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#983095: pidgin: 5353/udp probe every 2 sec

[Richard Laager]

I am not able to reproduce this. Do you have a packet capture?

Specifically, I'd like to know what sort of request it is.

--
Richard

Bug#983331: zfs-linux: zfs_zrele_async can cause txg sync deadlocks

[Antonio Russo]

Control: found -1 0.8.6-1
Control: fixed -1 2.0.2-1

Thank you for reporting this.  Are you running stable (0.7.12) and affected by 
this?
Backports and bullseye should now have the fix you mention.

Best,
Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#980935: pyzo: Crash at startup with python3.9

[Alexis Bienvenüe]

Hi.

On Fri, 19 Feb 2021 16:35:29 +0100 Gianfranco Costamagna
 wrote:
> Due to freeze, I can upload the patch on this bug right now, and
maybe we can upload your changes in git to unstable once the current
one goes in testing?
> 
> I'm doing some git work to polish the packaging, I'll try to rebase
your changes and push later today

Excellent : thanks a lot.

Alexis Bienvenüe.

Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0

[Kai Pastor, DG0YT]

Am 24.02.21 um 05:55 schrieb Sebastiaan Couwenberg:

On 2/24/21 12:58 AM, Kai Pastor, DG0YT wrote:

Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg:

It's good practice to include the Find modules for any dependencies that
are not part of cmake itself to not need upstream projects to install
cmake modules for them.

I think it is deprecated legacy practice, not good practice. Find
modules are poorly standardized, poorly maintained, and poorly tested.
It would be much better to provide PROJ config files as soon as
possible, instead of letting more developers start using PROJ with
non-standard find modules picked from random internet locations.

I wonder if there is a blocker for building debian PROJ with CMake. I
build PROJ for Android, macOS, Windows from Debian tarballs - with
cmake, not using debian/rules.
https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake

Switching from autotools to cmake is generally a regression, cmake
doesn't handle multiarch as well, and because it uses absolute paths
instead of relative paths it hinders reproducible builds.

See the recent discussion on the geos-devel lists for example:

  https://lists.osgeo.org/pipermail/geos-devel/2021-January/010078.html


From the mailing list post and its links I learn that

a) actively maintained projects do fix reported build system issues quickly.

b) there is some confusion about dealing with CMAKE_BUILD_TYPE, NDEBUG 
and reproducible paths.


I would agree that many projects have shortcoming in how they use CMake, 
partly due to past shortcomings of CMake and its documentation, partly 
due to ignorance of cross-platform building and packaging. But IMO it 
goes to far when you imply that CMake is to blame for issues with paths 
and reproducibility.


(Is there a Debian documentation for how to prepare CMake projects to 
help with Debian multi-arch?)



The CMake build of PROJ doesn't seem to provide a pkgconfig file, but
even for mips64el, the single proj.pc looks much less complex than the
set of cmake config files, or the patch proposed for FindProj4.cmake.

We're not going to switch to cmake for the proj package as long as
autotools is supported, because that is the best build system from a
packaging point of view.


Okay, so this covers your packaging point of view where autotools are 
already available. But it doesn't align with my requirements as a 
developer, and also not with my experience in single-arch 
bundling/packaging third-party components for Android, macOS, Windows.


(And I wouldn't even say that CMake is the best system for some purpose.)


The best solution for downstream projects not wanting to include their
own FindProj modules is to update the autotools build system to also
install the cmake bits. Perhaps you can provide a patch for that which
PROJ upstream can merge?


No, I don't think learning autotools and then teaching autotools to 
provide CMake config files, possibly for multi-arch, is a good use of my 
resources. But you may ask for patches for PROJ's CMake build system. 
Multiarch if I can test/verify in an amd_64 environment.


Kai

Bug#983439: allow to build the package without udebs

[Matthias Klose]

Package: src: libdebian-installer
Version: 0.120
Tags: patch

allow to build the package without udebs.

patch at
http://launchpadlibrarian.net/524724757/libdebian-installer_0.120ubuntu2_0.120ubuntu3.diff.gz

Bug#983438: allow to build without udeb package

[Matthias Klose]

Package: src:fuse3
Version: 3.10.2-1
Tags: patch

allow to build without udeb package.

patch at
http://launchpadlibrarian.net/524724106/fuse3_3.10.2-1build2_3.10.2-1ubuntu1.diff.gz

Bug#983437: allow to build without udeb package

[Matthias Klose]

Package: src:espeakup
Version: 1:0.80-19
Tags: patch

allow to build without udeb package

patch at
http://launchpadlibrarian.net/524721927/espeakup_1%3A0.80-19build1_1%3A0.80-19ubuntu1.diff.gz

Bug#983065: debian-policy: Downgrades are not allowed / Package upgrades must have a greater version than previous packages of the same name in the same suite

[Sean Whitton]

Hello Axel,

On Thu 18 Feb 2021 at 11:01PM +01, Axel Beckert wrote:

> I know this is very obvious, but if you read
>
> * https://www.debian.org/Bugs/Developer#severities and
> * https://release.debian.org/testing/rc_policy.txt
>
> it seems as if it should be listed somewhere in the policy that package
> downgrades MUST not happen during upgrades within the same suite
> (i.e. also not during dist-upgrades from e.g. oldstable to stable).
>
> I searched for "downgrad" (case-insensitively) in the whole policy and
> read at least the sections 3.2 "The version of a package" and 5.6.12
> "Version". (If it's documented elsewhere in the policy, it might need a
> pointer to there in these sections.)
>
> Reason for this bug report:
>
> After reading https://release.debian.org/testing/rc_policy.txt,
> especially after word "complete" this paragraph …
>
>   The purpose of this document is to be a correct, complete and
>   canonical list of issues that merit a "serious" bug under the clause
>   "a severe violation of Debian policy".
>
> … I really had a hard time arguing why https://bugs.debian.org/983018 is
> actually release-critical, despite I was 100% sure that it is. Luckily
> the maintainer did not start discussing but just fixed it. :-)
> X-Debugs-Cc'ing the release team for the involvement of rc_policy.txt.

Thanks, yes, let's document this in Policy.

There would seem to be two things to write down:

- .debs are not expected to support downgrades, either in their
  maintainer scripts or in any other aspects

- something about using version numbers correctly so that apt doesn't
  want to downgrade / doesn't get blocked because a downgrade would seem
  to be required

> The best written source I so far found was
> https://wiki.debian.org/SystemDowngrade and hence outside the policy.
>
> I suggest to add maybe a section 3.2.3 at
> https://www.debian.org/doc/debian-policy/ch-binary.html#the-version-of-a-package
> with a text like this:
>
> ---8<---
> 3.2.3 Version numbers of upgrades within one suite
>
> Version numbers of succeeding package upgrades within the same suite
> MUST be strictly greater than the one of the previous package.
>
> Package downgrades within one suite or when dist-upgrading from an old
> stable to a new stable release MUST not happen.
>
> See 5.6.12.1. Epochs should be used sparingly for cases where you need
> to package an upstream release with a lower upstream version
> number. Even in that case the package version itself MUST be greater.
> --->8---

I don't think this text is clear enough -- Policy is about the contents
of packages, but it's phrased in terms of things which will happen -- it
refers to upgrades and to downgrades.

Could you try writing this in terms of what contents of packages must be
avoided in order to avoid the situations you describe?

Also, I think the thing about not supporting downgrades should be
somewhere too.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#983218: cockpit: please use correct Debian logo

[Martin Pitt]

Control: reassign -1 debconf
Control: forcemerge 983200 -1

Hello again,

Martin Pitt [2021-02-23 15:48 +0100]:
> Philip Hands [2021-02-21 10:28 +0100]:
> > Rather than waiting for debconf to be updated to provide you with a new 
> > image to
> > play with, I'd suggest going to the source, and using the SVG here:
> > 
> >   https://www.debian.org/logos/openlogo-nd.svg
> 
> Thanks, very well spotted! That's what I did, and I rendered it (in GIMP) as
> 48x48. I submitted it here: 
> https://github.com/cockpit-project/cockpit/pull/15408

Sorry, this was a thinko. Our *source code* contains a
src/branding/debian/favicon.ico, but it's not actually being used. The deb just
installs it as a symlink to the generic distro-wide icon from debconf:

   lrwxrwxrwx 1 root root 32 Feb  4 14:48 
/usr/share/cockpit/branding/debian/favicon.ico -> 
../../../pixmaps/debian-logo.png

So I'm marking this a duplicate of the debconf bug, and will submit an upstream
PR to just remove the obsolete logo file from the source.

Thanks!

Martin

Bug#983395: podman lacks a runtime dependency on rootlesskit

[Shengjing Zhu]

On Wed, Feb 24, 2021 at 06:47:20AM +0200, Andrei POPESCU wrote:
> Control: reassign -1 src:libpod 3.0.0+dfsg1-2
> 
> On Ma, 23 feb 21, 14:26:12, Andrej Shadura wrote:
> > Package: src:podman
> > Version: 3.0.0+dfsg1-2
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > I get an error message when I try to run podman:
> > 
> > Error: Cannot connect to the Podman socket, make sure there is a Podman 
> > REST API service running.:
> > cannot find newuidmap: exec: "newuidmap": executable file not found in $PATH
> > 
> > Installing package rootlesskit fixes the issue.

The errors look like you don't have "newuidmap" binary, instead of 
"rootlesskit".
For newuidmap, it's provided by uidmap, which is in podman's Recommends.

Bug#983436: i386-cpuinfo.h missing in gcc-10-plugin-dev

[Boris Kolpackov]

Package: gcc-10-plugin-dev
Version: 10.2.1-6

After upgrading from GCC 10.1 to 10.2 I now get the following error
when building a program that relies on the GCC plugin API:

g++-10 -I/tmp/build/odb-2.5.0-b.20.20201208151514.398c7ad035b4 
-I/tmp/build/odb-2.5.0-b.20.20201208151514.398c7ad035b4 
-I/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include -DODB_GXX_NAME="g++-10" 
-DODB_BUILD2 -I/tmp/build/libcutl-1.11.0-b.8.20200801112455.4c8104756b92 
-I/tmp/build/libcutl-1.11.0-b.8.20200801112455.4c8104756b92 -DLIBCUTL_BUILD2 
-DLIBCUTL_SHARED -I/tmp/build/libstudxml-1.1.0-b.9.20210202082911.e729667b0f34 
-I/tmp/build/libstudxml-1.1.0-b.9.20210202082911.e729667b0f34 
-DLIBSTUDXML_SHARED -Wall -Werror -fPIC -std=c++2a -o 
odb-2.5.0-b.20.20201208151514.398c7ad035b4/odb/pragma.so.o -c -x c++ 
/tmp/build/odb-2.5.0-b.20.20201208151514.398c7ad035b4/odb/pragma.cxx

In file included from /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/tm.h:26,
 from 
/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/backend.h:28,
 from 
/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/gcc-plugin.h:30,
 from 
/tmp/build/odb-2.5.0-b.20.20201208151514.398c7ad035b4/odb/gcc.hxx:47,
 from 
/tmp/build/odb-2.5.0-b.20.20201208151514.398c7ad035b4/odb/pragma.cxx:4:
/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386.h:2500:10: 
fatal error: common/config/i386/i386-cpuinfo.h: No such file or directory
 2500 | #include "common/config/i386/i386-cpuinfo.h"

I see this has already been fixed in 10.2.1-20 that is currently only
available in experimental. It would be helpful if this fix is
propagated to testing (and to the final stable version) despite the
freeze since currently plugin support is unusable.

Bug#983401: [Pkg-zfsonlinux-devel] Bug#983401: zfs-zed: Update of zfs-zed from buster-backports fails.

[Andreas Christ]

Dear Antonio, dear Yurii,

Yes, I remember following the guide on the openzfs site
when I set up the zfs volume as Yurii pointed out. I did
not remember creating the symlink. Sorry for creating
confusion.

Best,

Andreas





On 2/24/21 1:07 AM, Antonio Russo wrote:

Control: tag -1 patch

Hello Andreas,

Deleting these old symlinks from (presumably) another ZFS packaging is indeed
the correct fix.  I do think we could handle this case slightly more nicely,
and I've opened an MR on salsa [1] that should fix this.

Best,
Antonio

[1] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/38

Bug#983091: xapian-core FTBFS on i386: test failure

[Olly Betts]

On Tue, Feb 23, 2021 at 10:22:39PM +0200, Adrian Bunk wrote:
> On Tue, Feb 23, 2021 at 07:52:42PM +, Olly Betts wrote:
> >...
> > As you note, on i386 the test was only run with the SSE build before
> > the recent debian/rules modernisation, but that doesn't explain why
> > m68k now fails.  Looking at older m68k logs, it seems the testsuite
> > wasn't being run, though I'm not seeing why not.
> >...
> 
> m68k and sh4 are building with nocheck.
> 
> nocheck handling was lost in the debian/rules rewrite.

I dropped that handling as I thought dh_auto_test now handled it by
default, but checking the docs I see that is only on in compat level 13
and up (which I avoided to aid backporting.)

Thanks for the pointer.

Cheers,
Olly

Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0

[Sebastiaan Couwenberg]

On 2/24/21 12:58 AM, Kai Pastor, DG0YT wrote:
> Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg:
>> It's good practice to include the Find modules for any dependencies that
>> are not part of cmake itself to not need upstream projects to install
>> cmake modules for them.
> 
> I think it is deprecated legacy practice, not good practice. Find
> modules are poorly standardized, poorly maintained, and poorly tested.
> It would be much better to provide PROJ config files as soon as
> possible, instead of letting more developers start using PROJ with
> non-standard find modules picked from random internet locations.
> 
> I wonder if there is a blocker for building debian PROJ with CMake. I
> build PROJ for Android, macOS, Windows from Debian tarballs - with
> cmake, not using debian/rules.
> https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake

Switching from autotools to cmake is generally a regression, cmake
doesn't handle multiarch as well, and because it uses absolute paths
instead of relative paths it hinders reproducible builds.

See the recent discussion on the geos-devel lists for example:

 https://lists.osgeo.org/pipermail/geos-devel/2021-January/010078.html

> The CMake build of PROJ doesn't seem to provide a pkgconfig file, but
> even for mips64el, the single proj.pc looks much less complex than the
> set of cmake config files, or the patch proposed for FindProj4.cmake.

We're not going to switch to cmake for the proj package as long as
autotools is supported, because that is the best build system from a
packaging point of view.

The best solution for downstream projects not wanting to include their
own FindProj modules is to update the autotools build system to also
install the cmake bits. Perhaps you can provide a patch for that which
PROJ upstream can merge?

Kind Regards,

Bas

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

Bug#983395: podman lacks a runtime dependency on rootlesskit

[Andrei POPESCU]

Control: reassign -1 src:libpod 3.0.0+dfsg1-2

On Ma, 23 feb 21, 14:26:12, Andrej Shadura wrote:
> Package: src:podman
> Version: 3.0.0+dfsg1-2
> Severity: important
> 
> Dear Maintainer,
> 
> I get an error message when I try to run podman:
> 
> Error: Cannot connect to the Podman socket, make sure there is a Podman REST 
> API service running.:
> cannot find newuidmap: exec: "newuidmap": executable file not found in $PATH
> 
> Installing package rootlesskit fixes the issue.
> 
> -- 
> Cheers,
>   Andrej

Reassigning to correct (source) package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#983401: [Pkg-zfsonlinux-devel] Bug#983401: zfs-zed: Update of zfs-zed from buster-backports fails.

[Antonio Russo]

Control: tag -1 patch

Hello Andreas,

Deleting these old symlinks from (presumably) another ZFS packaging is indeed
the correct fix.  I do think we could handle this case slightly more nicely,
and I've opened an MR on salsa [1] that should fix this.

Best,
Antonio

[1] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/38

Bug#983434: Make libdebuginfod use https://debuginfod.debian.net by default

[Sergio Durigan Junior]

Source: elfutils
Version: 0.183-1
Severity: normal
Owner: Sergio Durigan Junior 

Hi,

With the advent of the new https://debuginfod.debian.net service, we
can now make libdebuginfod install the proper files necessary to have
everyone using our instance transparently.

I intend to submit a Merge Request on salsa soon to implement that.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#983433: libemail-outlook-message-perl: msgconvert: missing dependency on libemail-message-perl

[Paul Wise]

Package: libemail-outlook-message-perl
Version: 0.920-1
Severity: serious
Control: found -1 0.919-4~bpo10+1
X-Debbugs-CC: Olly Betts 

Due to a change in msgconvert, libemail-outlook-message-perl is missing
a dependency on libemail-message-perl in bullseye and buster-backports,
but not in Debian buster or stretch.

I wasn't sure whether this was deliberate or not, but the needed
dependency on libemail-message-perl does not appear in Recommends or
Suggests either so I figure it was just missed.

I note that all the upstream metadata files indicate that the Perl
Email::Address module is required so Depends seems correct.

Looking at the debdiff between buster & buster-backports it looks like
this was introduced in buster-backports by the fix for mbox separators
(#904664) and in bullseye by the upstream release adding that patch.

   $ sudo chronic apt install -y libemail-outlook-message-perl 
   
   $ msgconvert
   Can't locate Email/Address.pm in @INC (you may need to install the 
Email::Address module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 
/usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 
/usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/bin/msgconvert line 8.
   BEGIN failed--compilation aborted at /usr/bin/msgconvert line 8.
   
   $ grep Email::Address `which msgconvert`
   use Email::Address;
   my @from_addr = Email::Address->parse($mail->header('From'));
   
   $ chronic apt source -qq libemail-outlook-message-perl
   
   $ (cd libemail-outlook-message-perl*/ ; grep -r Email::Address )
   Checking for repositories in /home/pabs/tmp-context-arXYMcHaIE ...
   META.json:"Email::Address" : "0",
   Makefile.PL:   'Email::Address' => '0',
   script/msgconvert:use Email::Address;
   script/msgconvert:my @from_addr = 
Email::Address->parse($mail->header('From'));
   Build.PL:'Email::Address' => '0',
   META.yml:  Email::Address: '0'

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

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

Versions of packages libemail-outlook-message-perl depends on:
ii  libemail-mime-contenttype-perl  1.026-1
ii  libemail-mime-perl  1.949-1
ii  libemail-sender-perl1.300035-1
ii  libemail-simple-perl2.216-1
ii  libio-all-perl  0.87-1
ii  libio-string-perl   1.08-3.1
ii  libole-storage-lite-perl0.20-1
ii  perl5.32.1-2

libemail-outlook-message-perl recommends no packages.

libemail-outlook-message-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#983432: debci: sudo is prohibited by user debci

[Ryutaroh Matsumoto]

Package: debci
Version: 2.15
Severity: normal

Dear Maintainer,

Autopkg test scripts in some packages assume that
an ordinary user (e.g. debci) in the testbed can do
"sudo" in qemu testbeds, see, for example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983367#10
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983367#15
for src:gvfs and src:libnfs.

If /usr/share/debci/backends/qemu/customize.sh adds the user debci
to the group sudo, the above test failures should be worked around.

Best regards, Ryutaroh Matsumoto

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

Kernel: Linux 5.9.16-raspi4b (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debci depends on:
ii  adduser 3.118
ii  amqp-tools  0.10.0-1
ii  curl7.74.0-1.1
ii  dctrl-tools 2.24-3
ii  debian-archive-keyring  2019.1
ii  debootstrap 1.0.123
ii  devscripts  2.20.5
ii  distro-info 1.0
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4
ii  jq  1.6-2.1
ii  libjs-bootstrap 3.4.1+dfsg-2
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-flot   4.2.1+dfsg-5
ii  moreutils   0.65-1
ii  netcat-traditional  1.10-46
ii  parallel20161222-1.1
ii  patchutils  0.4.2-1
ii  retry   1.0.4-2
ii  rsync   3.2.3-4
ii  ruby1:2.7+2
ii  ruby-activerecord   2:6.0.3.5+dfsg-1
ii  ruby-bunny  2.14.4-4
ii  ruby-erubi  1.9.0-1
ii  ruby-kaminari-activerecord  1.2.1-1
ii  ruby-pg 1.2.3-1+b1
ii  ruby-sinatra2.0.8.1-2
ii  ruby-sinatra-contrib2.0.8.1-2
ii  ruby-sqlite31.4.2-3
ii  ruby-thor   1.0.1-1
ii  sudo1.9.5p2-2

Versions of packages debci recommends:
ii  systemd-timesyncd [time-daemon]  247.3-1

Versions of packages debci suggests:
pn  apt-cacher-ng  

-- no debconf information

Bug#983431: The Description should mention it is a "Python2 to Python3 converter"

[積丹尼 Dan Jacobson]

Package: python3-lib2to3
Version: 3.9.2-1

The Description should mention it is a "Python2 to Python3 converter".

Bug#983430: admin.c: fix an "else" selection

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 3be12c5873e833204fc12cb872cb1eb2cf65eb72 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 24 Feb 2021 01:33:25 +
>Subject: [PATCH] admin.c: fix "else" selection

  Fix an "else" selection and delete diagnostic messages.

  Delete a space at the start of a line, which should be empty.

Signed-off-by: Bjarni Ingi Gislason 
---
 admin.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/admin.c b/admin.c
index 3029e45..bb33404 100644
--- a/admin.c
+++ b/admin.c
@@ -207,19 +207,16 @@ find_files(group_header * gh)
return;
}
if (db_data_subdirs) {
-   tprintf("admin.c:find_files: printing files in %s with a pager\n", 
db_data_directory);
sprintf(command, "cd %s ; ls -l [0-9] | %s", db_data_directory, 
pager);
}
else {
-   tprintf("admin.c:find_files: printing files in %s with a \
-pager\n", db_data_directory);
sprintf(command, "ls -l %s | %s", db_data_directory, pager);
-} else {
-   tprintf("admin.c:find_files: printing file in %s without a \
-pager\n", db_data_path(name, gh, '*'));
+   }
+}
+else {
sprintf(command, "ls -l %s", db_data_path(name, gh, '*'));
 }
-
+
 system(command);
 }
 
-- 
2.30.0



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#977374: ITP: vdf -- package for working with Valve's text and binary KeyValue format

[Simon McVittie]

On Tue, 23 Feb 2021 at 17:06:58 +, Simon McVittie wrote:
> On Tue, 23 Feb 2021 at 16:50:41 +, Stephan Lachnit wrote:
> > If you already have stuff, send me the link to the salsa repo once uploaded
> 
> Will do!

https://salsa.debian.org/games-team/python-vdf

(The upstream name seemed really ambiguous, so I gave the source package
name a python- prefix.)

smcv

Bug#983429: mosquitto: /run/mosquitto is on a tmpfs and should be created dynamically

[Alexandre Detiste]

Package: mosquitto
Version: 2.0.7-3
Severity: minor

/run/mosquitto shows up in cruft-ng report as existing in dpkg database
but missing from the filesystem, if service has been disabled before boot.

please create /run/mosquitto dynamically on boot

fix_permissions() in postinst seams not enough.

Greetings,


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

Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mosquitto depends on:
ii  adduser  3.118
ii  libc62.31-9
ii  libcjson11.7.14-1
ii  libdlt2  2.18.6-1
ii  libmosquitto12.0.7-3
ii  libssl1.11.1.1j-1
ii  libsystemd0  247.3-1
ii  libwebsockets16  4.0.20-2
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0

mosquitto recommends no packages.

Versions of packages mosquitto suggests:
pn  apparmor  

-- no debconf information

Bug#983428: update-alternatives: warning: forcing reinstallation of alternative /usr/share/info/emacs/emacs.info.gz because link group emacs.info.gz is broken

[積丹尼 Dan Jacobson]

Package: emacs-common-non-dfsg
Version: 1:27.1+1-2

We see:

Setting up emacs-common-non-dfsg (1:27.1+1-2) ...
update-alternatives: warning: forcing reinstallation of alternative 
/usr/share/info/emacs/emacs.info.gz because link group emacs.info.gz is broken

Bug#983427: libpam-runtime: please add support for DPKG_ROOT

[Johannes 'josch' Schauer]

Package: libpam-runtime
Version: 1.4.0-4.1
Severity: wishlist
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support

Hi,

since dpkg 1.18.5, dpkg sets the variable DPKG_ROOT when invoking
maintainer scripts. Usually that variable is empty but when calling dpkg
with --root and --force-script-chrootless, dpkg will set DPKG_ROOT to
the new root directory. In that mode, maintainer scripts are called
without chroot(1) around them, and thus have to be able to possibly
operate on the path from DPKG_ROOT instead of working on /. This is
useful for bootstrapping, creating chroots for foreign architectures
where utilities from inside the chroot cannot be executed, avoiding
dependency loops between postinst scripts, installation without
requiring superuser privileges and for creating installations that do
not even contain dpkg. See
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap for more
information.

To see the problem, you can run:

$ mmdebstrap --mode=chrootless --variant=custom --include=libpam-runtime 
unstable /dev/null
[...]
Setting up libpam-runtime (1.4.0-4.1) ...
open(/var/lib/pam/seen) failed: Permission denied at /usr/sbin/pam-auth-update 
line 232,  line 11.
dpkg: error processing package libpam-runtime (--configure):
 installed libpam-runtime package post-installation script subprocess returned 
error exit status 13
Errors were encountered while processing:
 libpam-runtime
E: Sub-process /usr/bin/dpkg returned an error code (1)

The following patch fixes the problem:

diff --git a/debian/libpam-runtime.postinst b/debian/libpam-runtime.postinst
index 518e8d24..053fdae2 100644
--- a/debian/libpam-runtime.postinst
+++ b/debian/libpam-runtime.postinst
@@ -29,7 +29,7 @@ then
done
 fi
 
-pam-auth-update --package $force
+pam-auth-update --root "$DPKG_ROOT" --package $force
 
 if [ -n "$force" ]; then
rm -f /etc/pam.d/common-auth.pam-old \
diff --git a/debian/local/pam-auth-update b/debian/local/pam-auth-update
index 6d17ab72..18fd898c 100644
--- a/debian/local/pam-auth-update
+++ b/debian/local/pam-auth-update
@@ -82,6 +82,11 @@ while ($#ARGV >= 0) {
$force = 1;
} elsif ($opt eq '--package') {
$package = 1;
+   } elsif ($opt eq '--root') {
+   my $rootdir = shift @ARGV;
+   $savedir = "$rootdir/$savedir";
+   $confdir = "$rootdir/$confdir";
+   $inputdir = "$rootdir/$inputdir";
} elsif ($opt eq '--remove') {
while ($#ARGV >= 0) {
last if ($ARGV[0] =~ /^--/);


Possibly, more is needed to correctly implement DPKG_ROOT support, but
with above patch, it is possible to run above mmdebstrap command
successfully.

Thanks!

cheers, josch

Bug#983426: plocate: install packages used in cron job: powermgmt-base nocache

[Paul Wise]

Package: plocate
Version: 1.1.4-1
Severity: important
Usertags: sysvinit

The cron job uses on_ac_power (from powermgmt-base) and nocache, I
think it would be appropriate to install on those packages, with an
alternative of systemd-sysv so that they get installed on systems that
are not running systemd. The nocache package isn't available on all
architectures so maybe it would be best to use Recommends for this.

   Recommends: systemd-sysv | powermgmt-base, systemd-sysv | nocache

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

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

Versions of packages plocate depends on:
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6
ii  liburing1   0.7-3
ii  libzstd1    1.4.8+dfsg-2

plocate recommends no packages.

plocate suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#856877: schroot: Please mount a new instance of /dev/pts

[Simon McVittie]

On Sun, 05 Mar 2017 at 19:23:40 +, Simon McVittie wrote:
> the preferred way to
> set up /dev/pts inside containers in recent kernels is to mount a new
> instance of the devpts filesystem on /dev/pts
...
> In particular, this would make the chroots created by debootstrap
> versions 1.0.76 to 1.0.88 (inclusive) work as expected.
...
> A nice side-effect of this change, which I discovered while testing a
> cut-down version of the same code in a new debootstrap autopkgtest, is
> that it makes script(1) work inside "schroot --sbuild" inside a LXC
> container on a Debian jessie kernel. Previously, that would have failed.

On Tue, 23 Feb 2021 at 23:55:07 +, Simon McVittie wrote:
> schroot: Default profile doesn't provide a working /dev/ptmx inside lxc >= 3
...
> The same patch I proposed in 2017 for #856877 resolves this, setting
> up a working /dev/ptmx.  Under lxc 2 it's a symlink to /dev/ptx/ptmx,
> and under lxc >= 3 it's a device node.
>¯
> Under lxc 4, that patch also provides a working /dev/console.

Here's the patch I proposed in 2017, with an updated commit message.

Also available as a merge request:
https://salsa.debian.org/debian/schroot/-/merge_requests/2

smcv
From: Simon McVittie 
Date: Mon, 20 Feb 2017 10:43:24 +
Subject: Mount a new instance of /dev/pts in the chroot

This avoids various failure modes when schroot is run inside some other
container manager, such as lxc, most commonly manifesting as inability
to run programs that create pseudo-terminals such as script(1).

Mounting a new instance of devpts is considered to be
best-practice for container managers in Linux >= v2.6.29 with
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y. That config option was made
unconditional in v4.7.

This has some assumptions, which cannot be avoided if we are going to
mount /dev/pts using schroot's fstab:

* If the kernel is older than v4.7, it is assumed to be v2.6.29 or
  later with CONFIG_DEVPTS_MULTIPLE_INSTANCES=y. Users of older kernels,
  or intermediate versions with CONFIG_DEVPTS_MULTIPLE_INSTANCES=n,
  can revert this change via /etc.

* gid 5 must be the right owner for ptys. This is correct for Debian
  (it's the hard-coded tty group specified in base-passwd) and probably
  many other distributions (it's systemd's configure-time default) but
  not necessarily correct everywhere. However, if the host system and the
  chroot disagree on the right gid, schroot's previous behaviour would
  have been wrong anyway, because it bind-mounted the host's /dev/pts.

* /dev/ptmx inside the chroot must be either a real device node (as
  created by debootstrap < 1.0.76, and debootstrap >= 1.0.89 if possible)
  or a symlink to pts/ptmx (as created by debootstrap between 1.0.76 and
  1.0.88 inclusive, and by debootstrap >= 1.0.89 if run in a container
  whose seccomp rules do not allow it to create the device node, such
  as systemd-nspawn).

Bind-mounting /dev/pts/ptmx over /dev/ptmx, so that we get the
new instance's /dev/ptmx equivalent instead of the host's, can only
be done from code, so I have done it in the 10mount hook instead of
in the fstab.

To keep the host system terminal on which we were invoked (which might
itself be a pty, from a different instance of /dev/pts) available to
the chroot, bind-mount it onto /dev/console. This is the same trick
used in the lxc and systemd-nspawn Linux container managers.

Bug-Debian: https://bugs.debian.org/856877
Bug-Debian: https://bugs.debian.org/983423
Signed-off-by: Simon McVittie 
---
 etc/profile-templates/buildd/linux/fstab  |  2 +-
 etc/profile-templates/default/linux/fstab |  2 +-
 etc/profile-templates/desktop/linux/fstab |  2 +-
 etc/profile-templates/sbuild/linux/fstab  |  2 +-
 etc/setup.d/10mount   | 27 +++
 5 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/etc/profile-templates/buildd/linux/fstab b/etc/profile-templates/buildd/linux/fstab
index 26efe88..f2f6136 100644
--- a/etc/profile-templates/buildd/linux/fstab
+++ b/etc/profile-templates/buildd/linux/fstab
@@ -1,4 +1,4 @@
-/dev/pts/dev/ptsnonerw,bind 0   0
+/dev/pts/dev/ptsdevpts  rw,newinstance,ptmxmode=666,mode=620,gid=5 0 0
 tmpfs   /dev/shmtmpfs   defaults0   0
 # Mount a large scratch space for the build, so we don't use up
 # space on an LVM snapshot of the chroot itself.
diff --git a/etc/profile-templates/default/linux/fstab b/etc/profile-templates/default/linux/fstab
index 777f0ed..181ed80 100644
--- a/etc/profile-templates/default/linux/fstab
+++ b/etc/profile-templates/default/linux/fstab
@@ -1,5 +1,5 @@
 /dev/devnonerw,bind 0   0
-/dev/pts/dev/ptsnonerw,bind 0   0
+/dev/pts/dev/ptsdevpts  rw,newinstance,ptmxmode=666,mode=620,gid=5 0 0
 /home   /home   nonerw,bind 0   0
 /tmp/tmpnonerw,bind 0   0
 

Bug#983425: debconf: please add support for DPKG_ROOT

[Johannes 'josch' Schauer]

Package: debconf
Version: 1.5.74
Severity: wishlist
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support

Hi,

since dpkg 1.18.5, dpkg sets the variable DPKG_ROOT when invoking
maintainer scripts. Usually that variable is empty but when calling dpkg
with --root and --force-script-chrootless, dpkg will set DPKG_ROOT to
the new root directory. In that mode, maintainer scripts are called
without chroot(1) around them, and thus have to be able to possibly
operate on the path from DPKG_ROOT instead of working on /. This is
useful for bootstrapping, creating chroots for foreign architectures
where utilities from inside the chroot cannot be executed, avoiding
dependency loops between postinst scripts, installation without
requiring superuser privileges and for creating installations that do
not even contain dpkg. See
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap for more
information.

Currently, missing support for DPKG_ROOT in debconf is the single
biggest blocker in making all Essential:yes packages successfully
install with --root and --force-script-chrootless. Me and Helmut Grohne
happened to work on adding DPKG_ROOT support to debconf at the same
time, so now we have two patches which both work.

helmut: 
https://salsa.debian.org/josch/debconf/-/commit/4336c589fd6cb25e20f1753986bc86a74b668846

josch: 
https://salsa.debian.org/josch/debconf/-/commit/b84d965da3c56f33fed7e4f0899bc21c34578fcd

Could you review either and give us feedback so that we can prepare a
patch that is fit for inclusion into debconf?

To try it out, you have to install the changed debconf package directly
on your machine and *not* into the chroot, because in chrootless mode,
the maintainer script will call the tools as they are installed on the
machine running it. You can see how it currently fails by running:

mmdebstrap --mode=chrootless --variant=custom --include=debconf unstable 
/dev/null
[...]
Setting up debconf (1.5.74) ...
debconf: DbDriver "passwords" warning: could not open 
/var/cache/debconf/passwords.dat: Permission denied
debconf: DbDriver "config": could not write /var/cache/debconf/config.dat-new: 
Permission denied
dpkg: error processing package debconf (--configure):
 installed debconf package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 debconf
E: Sub-process /usr/bin/dpkg returned an error code (1)

However, with the changes from above commits, the command will succeed.

Thanks!

cheers, josch

Bug#983424: plocate-updatedb.service: PrivateTmp=true blocks indexing /tmp when removed from PRUNEPATHS

[Paul Wise]

Package: plocate
Version: 1.1.4-1
Severity: important
File: /lib/systemd/system/plocate-updatedb.service

I have emptied PRUNEPATHS since I want all real files indexed including
the files in the /tmp directory. The PrivateTmp=true setting in the
plocate-updatedb systemd service blocks /tmp from being indexed.

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

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

Versions of packages plocate depends on:
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6
ii  liburing1   0.7-3
ii  libzstd11.4.8+dfsg-2

plocate recommends no packages.

plocate suggests no packages.

-- Configuration Files:
/etc/updatedb.conf changed:
PRUNE_BIND_MOUNTS="yes"
# disabled PRUNEPATHS since I want all real files visible
PRUNEPATHS=""
PRUNEFS="NFS afs autofs binfmt_misc ceph cgroup cgroup2 cifs coda configfs 
curlftpfs debugfs devfs devpts devtmpfs ecryptfs ftpfs fuse.ceph fuse.glusterfs 
fuse.gvfsd-fuse fuse.mfs fuse.rozofs fuse.sshfs fusectl fusesmb hugetlbfs 
iso9660 lustre lustre_lite mfs mqueue ncpfs nfs nfs4 ocfs ocfs2 proc pstore 
rpc_pipefs securityfs shfs smbfs sysfs tmpfs tracefs udev udf usbfs"

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0

[Kai Pastor, DG0YT]

Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg:

A patch for that was just submitted to this bugreport.


Thanks.


It's good practice to include the Find modules for any dependencies that
are not part of cmake itself to not need upstream projects to install
cmake modules for them.


I think it is deprecated legacy practice, not good practice. Find 
modules are poorly standardized, poorly maintained, and poorly tested. 
It would be much better to provide PROJ config files as soon as 
possible, instead of letting more developers start using PROJ with 
non-standard find modules picked from random internet locations.


I wonder if there is a blocker for building debian PROJ with CMake. I 
build PROJ for Android, macOS, Windows from Debian tarballs - with 
cmake, not using debian/rules.

https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake

The CMake build of PROJ doesn't seem to provide a pkgconfig file, but 
even for mips64el, the single proj.pc looks much less complex than the 
set of cmake config files, or the patch proposed for FindProj4.cmake.


Kind regards,
Kai

Bug#983423: schroot: Default profile doesn't provide a working /dev/ptmx inside lxc >= 3

[Simon McVittie]

Package: schroot
Version: 1.6.10-11
Severity: normal

Steps to reproduce
--

(Replace or remove the http proxy http://192.168.122.1:3142 as required.)

sudo apt install lxc autopkgtest
(configure lxc as per [1])
sudo AUTOPKGTEST_APT_PROXY=http://192.168.122.1:3142 autopkgtest-build-lxc 
debian sid amd64
sudo lxc-copy --ephemeral -n autopkgtest-sid-amd64 -N temp
sudo lxc-attach -n temp

and then inside the lxc container:

apt install debootstrap schroot
http_proxy=http://192.168.122.1:3142 debootstrap sid /sid
cat > /etc/schroot/chroot.d/sid = 3 it's a device node.

Under lxc 4, that patch also provides a working /dev/console.

I'll re-send the patch with both bug numbers included when I have a
bug number for this report.

smcv

Bug#983360: multipath-tools: autopkgtest failure on the qemu testbed

[Ryutaroh Matsumoto]

> Other than the tests, does multipath-tools work proper for you ?
> From the logs you've shared, multipath does report to see the iSCSI
> LUNs. Now whether a proper map was created or not, is not clear from
> the logs.

I have seen no problems in bin. packages from src:multipath-tools.
I run autopkgtest qemu on all packages with standard priority and
in task-gnome-desktop, and reported all the errors I observed (as
tests finished) except the packages already erred on ci.debian.net.
Some of them turned out to be real errors...

Best regards, Ryutaroh

Bug#700808:

[J. Smith]

This was 8 years and 4 Emacs major releases ago.
If this is still an issue with Emacs 27.1, I suggest opening a new report with 
upstream directly.

Bug#624210:

[J. Smith]

I can't reproduce this.
This report is 10 years old, refers to an Emacs 4 major versions ago, and has 
seen no comments.
I suggest closing it, and opening a new report with upstream Emacs if this is 
still an issue.

Bug#983422: lxc: autopkg tests always fail on qemu testbed

[Ryutaroh Matsumoto]

Source: lxc
Version: 4.0.6-1
Severity: normal
Tags: sid bullseye
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: cgroupv2
Control: block -1 by 961578

Dear Maintainer,

I believe the following issue is a bug in the testsuit and
not a bug in the lxc itself.

I made my qemu testbed by debci setup -f -s sid -a amd64 -b qemu.
Then I run autopkgtest -B -U -u debci lxc -- qemu

The four tests always fail. The relevant part of the full log is as follows.
The full log is also attached.


from summary:
exercise FAIL timed out
unprivileged-containers FAIL non-zero exit status 1

from exercise-stdout:

FAIL: lxc-tests: /usr/bin/lxc-test-cgpath
---
cgpath.c:73 lxc_cmd_get_cgroup_path returned NULL
---

FAIL: lxc-tests: /usr/bin/lxc-test-no-new-privs
---
+ DONE=0
+ trap cleanup EXIT SIGHUP SIGINT SIGTERM
+ '[' '!' -d /etc/lxc ']'
+ ARCH=i386
+ type dpkg
++ dpkg --print-architecture
+ ARCH=amd64
+ lxc-create -t download -n c1 -- -d ubuntu -r xenial -a amd64
Setting up the GPG keyring
Downloading the image index
WARNING: Failed to download the file over HTTPs
 The file was instead download over HTTP 
A server replay attack may be possible!
Downloading the rootfs
Downloading the metadata
The image cache is now ready
Unpacking the rootfs

---
You just created an Ubuntu xenial amd64 (20210223_07:42) container.

To enable SSH, run: apt install openssh-server
No default root or user password are set by LXC.
+ echo 'lxc.no_new_privs = 1'
+ lxc-start -n c1
++ lxc-info -n c1 -p -H
+ p1=14124
+ '[' 14124 '!=' -1 ']'
+ sleep 5s
+ lxc-attach -n c1 --clear-env -- apt update -y

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Err:1 http://security.ubuntu.com/ubuntu xenial-security InRelease
  Temporary failure resolving 'security.ubuntu.com'
Err:2 http://archive.ubuntu.com/ubuntu xenial InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease
  Temporary failure resolving 'archive.ubuntu.com'


FAIL: lxc-tests: /usr/bin/lxc-test-usernsexec
---
as test-userns executing /usr/bin/lxc-test-usernsexec 
/usr/bin/lxc-test-usernsexec: line 295: sudo: command not found
---

SUMMARY: pass=38, fail=3, ignored=0

from unprivileged-containers-stderr:
+ mkdir -p /home/debci/.config/lxc
+ tee /home/debci/.config/lxc/default.conf
+ lxc-create -t download -n mycontainer -- -d debian -r buster -a amd64
lxc-create: mycontainer: confile.c: set_config_idmaps: 1940 Invalid argument - 
Failed to parse id mappings
lxc-create: mycontainer: parse.c: lxc_file_for_each_line_mmap: 131 Failed to 
parse config file "/home/debci/.config/lxc/default.conf" at line "lxc.idmap = u 
0 "
lxc-create: mycontainer: conf.c: userns_exec_mapped_root: 4489 No uid mapping 
for container root
lxc-create: mycontainer: lxccontainer.c: do_storage_create: 1292 Error chowning 
"/home/debci/.local/share/lxc/mycontainer/rootfs" to container root
lxc-create: mycontainer: conf.c: suggest_default_idmap: 4806 You do not have 
subuids or subgids allocated
lxc-create: mycontainer: conf.c: suggest_default_idmap: 4807 Unprivileged 
containers require subuids and subgids
lxc-create: mycontainer: lxccontainer.c: do_lxcapi_create: 1871 Failed to 
create (none) storage for mycontainer
lxc-create: mycontainer: tools/lxc_create.c: main: 319 Failed to create 
container mycontainer


Best regards, Ryutaroh Matsumoto

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

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


lxc-log.tar.xz
Description: application/xz

Bug#983421: init-system-helpers: please respect DPKG_ROOT when checking for /usr/sbin/policy-rc.d

[Johannes 'josch' Schauer]

Package: init-system-helpers
Version: 1.60+nmu1
Severity: wishlist
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support

Hi,

if dpkg (since 1.18.5) is run with --force-script-chrootless, it sets
the variable DPKG_ROOT to the directory into which dpkg will install the
requested packages. This is useful for bootstrapping, creating chroots
for foreign architectures where utilities from inside the chroot cannot
be executed, avoiding dependency loops between postinst scripts,
installation without requiring superuser privileges and for creating
installations that do not even contain dpkg. See
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap for more
information.

Currently, when maintainer scripts are run, /usr/sbin/policy-rc.d is
checked to avoid starting services. But instead, the scripts should
check "$DPKG_ROOT/usr/sbin/policy-rc.d". In normal situations, the
$DPKG_ROOT variable is empty, so this will work as usual. But if dpkg is
run with --root and --force-script-chrootless then /usr/sbin/policy-rc.d
from the new root directory will be used.

Please consider applying the following patch:

diff --git a/script/deb-systemd-invoke b/script/deb-systemd-invoke
index d8dab1a..67e3e1d 100755
--- a/script/deb-systemd-invoke
+++ b/script/deb-systemd-invoke
@@ -58,6 +58,9 @@ if (@ARGV < 2) {
 }

 my $policyhelper = '/usr/sbin/policy-rc.d';
+if (defined $ENV{DPKG_ROOT} && $ENV{DPKG_ROOT} ne "") {
+$policyhelper = $ENV{DPKG_ROOT} . $policyhelper;
+}
 my @units = @ARGV;
 my $action = shift @units;
 if (-x $policyhelper) {
diff --git a/script/invoke-rc.d b/script/invoke-rc.d
index 71cc3f1..ca1bdbe 100755
--- a/script/invoke-rc.d
+++ b/script/invoke-rc.d
@@ -23,7 +23,7 @@

 # Constants
 RUNLEVELHELPER=/sbin/runlevel
-POLICYHELPER=/usr/sbin/policy-rc.d
+POLICYHELPER=$DPKG_ROOT/usr/sbin/policy-rc.d
 INITDPREFIX=/etc/init.d/
 RCDPREFIX=/etc/rc



Thanks!

cheers, josch

Bug#942335: tt-rss: Debconf preseed of "self_url_path" overwritten by config script

[Nicolas Peninguy]

Hello,

I was hit by this bug, trying to automate my config with Ansible.

Even setting tt-rss/self_url_path after package install, and running 
"dpkg-reconfigure -f noninteractive tt-rss" will fail, because it will 
read the old value from the existing config file, and overwrite the 
debconf value.


I will have to directly patch the config file, which I tried to avoid.

Thanks,

Nicolas

Bug#983087: sbuild-createchroot misses usr/libexec/qemu-binfmt/ directory

[Johannes Schauer Marin Rodrigues]

Hi Roger,

Quoting Roger Leigh (2021-02-23 22:41:32)
> On 22 Feb 2021, at 12:00, Johannes Schauer Marin Rodrigues  
> wrote:
> > 
> >>> Michael, your change in qemu introduced this problem. Schroot is currently
> >>> orphaned. Since you are responsible for this change in qemu, could you 
> >>> make an
> >>> NMU of schroot with above fix? Thanks!
> >> 
> >> Oww.. orphan.. that's pity.
> > 
> > Indeed. On the plus side, it means we can just NMU things without waiting 
> > for
> > maintainer action. ;)
> 
> You can always open a MR against the upstream GitLab repo (branch
> schroot-1.6) for any modifications you make to the code (not the Debian
> packaging).  https://gitlab.com/codelibre/schroot
> 

cool to hear from you again! And nice to see that there are new commits in the
upstream git repo. :)

Also feel free to ping me once there is a new schroot upstream version that
needs packaging.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#971444:

[J. Smith]

Using the recipe from the OP, it works fine for me in Emacs 27.1.

Bug#983420: nntp.c: fix use of mkstemp()

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 1fd28131cea7a322dd3ac8f0a449ba44a893f519 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Tue, 23 Feb 2021 20:42:59 +
>Subject: [PATCH] nntp.c: fix use of mkstemp()

nntp.c: fix use of mkstemp()

Signed-off-by: Bjarni Ingi Gislason 
---
 nntp.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/nntp.c b/nntp.c
index 0466bdf..ccd02da 100644
--- a/nntp.c
+++ b/nntp.c
@@ -996,11 +996,15 @@ nntp_get_active(void)
 if (!is_connected && connect_server() < 0)
return -1;
 
-new_name = mkstemp(relative(db_directory, ".actXX"));
+/*new_name = mkstemp(relative(db_directory, ".actXX")); */
+new_name = relative(db_directory, ".actXX");
 
 switch (n = ask_server("LIST")) {
case OK_GROUPS:
-   new = open_file(new_name, OPEN_CREATE_RW | MUST_EXIST);
+/* new = open_file(new_name, OPEN_CREATE_RW | MUST_EXIST); */
+   fd = mkstemp(new_name); /* new_name changed to actual name*/
+   new = fdopen(fd, r+);
+
if (copy_text(new) == 0) {
if (fflush(new) != EOF)
break;
@@ -1051,12 +1055,20 @@ nntp_get_newsgroups(void)
 {
 char   *new_name;
 FILE   *new;
-int n;
+int fd, n;
+
+/* Make a more secure temporary file than with "mktemp"
+  Have to add unlink function
+*/
+new_name = relative(tmp_directory, "nngrXX");
+fd = mkstemp(new_name);
 
-new_name = mkstemp(relative(tmp_directory, "nngrXX"));
-new = open_file(new_name, OPEN_CREATE_RW | OPEN_UNLINK);
-if (new == NULL)
+if (fd == -1) {
return NULL;
+}
+
+new = fdopen(fd, "r+");
+unlink(new_name);
 
 if (!is_connected && connect_server() < 0)
goto err;
-- 
2.30.0



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#982258: [pkg-gnupg-maint] Bug#982258: gpgv1: Consider removing parts of the tools which aren't recommended to be used

[Russ Allbery]

Daniel Kahn Gillmor  writes:

> for (a) and (c), do we have a sample of a usenet control message

The last articles in:

http://ftp.isc.org/usenet/control/rec/rec.ponds.moderated.gz

are generated in essentially the same way Big Eight control messages are
still currently being generated.  (I've been trying to find time to switch
over, but haven't yet.)

> and key that are in use today?

http://ftp.isc.org/usenet/news.announce.newgroups/PGP.PUBLICKEY

and more generally nearly all of the keys in:

https://git.eyrie.org/?p=usenet/control-archive.git;a=tree;f=keys;hb=HEAD

Only a few have been converted to modern keys.

> Is there an estimate of how many of those keys are still relied upon?

Among those still actively issuing control messages (a lot of these
hierarchies have stopped), my guess would be around 5-10.

> Here are some features that it sounds to me like we could "safely"
> remove or disable in gpg1, while encouraging users who needed that
> specific functionality to migrate to modern gpg:

>  - secret key generation
>  - encryption
>  - keyserver and other network access (including auto-key-locate?)
>  - certification (aka "keysigning")
>  - trust models other than direct (and always)?

None of this is used by the Usenet machinery.

-- 
Russ Allbery (ea...@eyrie.org) 

Bug#983087: sbuild-createchroot misses usr/libexec/qemu-binfmt/ directory

[Roger Leigh]

On 22 Feb 2021, at 12:00, Johannes Schauer Marin Rodrigues  
wrote:
> 
>>> Michael, your change in qemu introduced this problem. Schroot is currently
>>> orphaned. Since you are responsible for this change in qemu, could you make 
>>> an
>>> NMU of schroot with above fix? Thanks!
>> 
>> Oww.. orphan.. that's pity.
> 
> Indeed. On the plus side, it means we can just NMU things without waiting for
> maintainer action. ;)

You can always open a MR against the upstream GitLab repo (branch schroot-1.6) 
for any modifications you make to the code (not the Debian packaging).  
https://gitlab.com/codelibre/schroot  

Regards,
Roger

Bug#983419: liburi-perl: URI nntps support

[Eric Wong]

Package: liburi-perl
Version: 1.76-1
Severity: wishlist
Tags: upstream

While URI::snews exists for NNTP over TLS, "nntps" is the IANA-registered name:

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=nntps

Also, "nntps" (not "snews") is present in /etc/services shipped with Debian.

Thanks in advance for forwarding to upstream to me.  Upstream uses
a proprietary bug tracker with both an unacceptable Terms-of-Service
and JavaScript CAPTCHA.

Bug#982258: [pkg-gnupg-maint] Bug#982258: gpgv1: Consider removing parts of the tools which aren't recommended to be used

[Daniel Kahn Gillmor]

On Sun 2021-02-07 20:19:19 +, Dominic Hargreaves wrote:
> In the discussion at [1] it was suggested that perhaps gnupg1 could be
> updated to explicitly remove support for operations other than
> decrypting old messages.

that discussion suggests that the only two things that people are likely
to still use GnuPG for are:

 a) signing with old keys that gpg2 thinks are too weak to consider using
 b) decrypting old messages

Surely from (a) it follows that there are others who need:

 c) verifying signatures from those old keys(?)

For (b), do we have a sample of an old message that modern gpg is unable
to decrypt, along with a sample key?

for (a) and (c), do we have a sample of a usenet control message and key
that are in use today?  Is there an estimate of how many of those keys
are still relied upon?

Here are some features that it sounds to me like we could "safely"
remove or disable in gpg1, while encouraging users who needed that
specific functionality to migrate to modern gpg:

 - secret key generation
 - encryption
 - keyserver and other network access (including auto-key-locate?)
 - certification (aka "keysigning")
 - trust models other than direct (and always)?

Any thoughts?

--dkg


signature.asc
Description: PGP signature

Bug#983316: openvswitch-switch: Hard-coded log levels, no way to configure them

[Ben Pfaff]

On Mon, Feb 22, 2021 at 12:25:22PM +0100, Benjamin Drung wrote:
> Package: openvswitch-switch
> Version: 2.15.0+ds1-2
> Severity: normal
> 
> Hi,
> 
> Since we run into a log spam issue (probably upstream bug #135 [1]), we
> want to raise the log level and disable the logging to file (syslog is
> enough for us).
> 
> Sadly `/usr/share/openvswitch/scripts/ovs-ctl` (called by
> ovsdb-server.service) hard-codes the log levels and has no way to
> configure them:
> 
> ```
> set "$@" -vconsole:emer -vsyslog:err -vfile:info
> ```
> 
> Please support configuring the log levels via
> `/etc/default/openvswitch-switch`.

I think you can do that already in /etc/default/openvswitch-switch with
OVS_CTL_OPTS='--ovs-vswitchd-options=-vwhatever'
It can undoubtedly be improved (I'm not sure multiword options will
work).

Open vSwitch works pretty hard to not spam log files, so I'd encourage
you to report whatever excessive logging you're seeing to upstream.

Bug#981368: xserver-xorg-video-intel: Xserver becomes unresponsive with some worloads. maybe related to video rendering

[Jörg Mechnich]

Looks like this was actually a bug in the i915 module:

https://gitlab.freedesktop.org/drm/intel/-/issues/2905

There is a linked issue #2923
"deadlock in intel_atomic_cleanup_work (kernel 5.10.5)"
that seems to fit the descriptions in this thread here.

After upgrading to a custom 5.10.17 kernel, I don't seem to experience 
the same issue anymore while still using the intel Xorg driver.


I agree that this report could be closed now.

Cheers and thanks for keeping the intel driver alive, still performs 
significantly better on my particular system than the modesetting driver!


--
Jörg Mechnich
Stellv. Abteilungsleitung Digitale Bibliotheksdienste

Universität Mannheim
Universitätsbibliothek
Schloss Schneckenhof West, SN281, 68131 Mannheim

Tel: +49 621 181-2965
E-Mail: joerg.mechn...@bib.uni-mannheim.de



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983417: urlview crops very long URLs

[Alexandre Lymberopoulos]

Package: urlview
Version: 0.9-21+b1
Severity: normal

Dear Maintainer,

I use urlview with mutt. I noticed that some *very* long URLs are
cropped. As an example the following URL, with 431 characters,

http://url2099.vitalbrazilsp.com.br/ls/click?upn=7Hf8vZpOdesy4FvzLClOv4cwwel9sRbGRhnPqnCBawoEjoHxJ6AwnV2XDr4actLKCtxOWpJMfvPBXD82pHKf4xJHXgCHR0bUTw-2BziDqlAPY-3DMVsu_G0c-2FRmGAqNpDZToWvrbnd-2Bplgl2lbxt2XV-2F4fRWN7oHI-2BuuIBrEfHvJMHYWXTsmiJ7APZjBe7udH3CLzGLTgTmE1999UoIeh-2Fca6XBhN-2BV0vkldpPXIPxdgkEhow9jPC6s7tpIp1mFTWiHmFW6OBBxZ5XaMpRkyJa7ISArsD57-2B-2BzfjugP3BMfUAH96QmSVA8BC7qvEzOEfGVKh6-2FyOIMCpOnmb6g7W3tOG5eAJoGJE-3D

is read as

http://url2099.vitalbrazilsp.com.br/ls/click?upn=7Hf8vZpOdesy4FvzLClOv4cwwel9sRbGRhnPqnCBawoEjoHxJ6AwnV2XDr4actLKCtxOWpJMfvPBXD82pHKf4xJHXgCHR0bUTw-2BziDqlAPY-3DMVsu_G0c-2FRmGAqNpDZToWvrbnd-2Bplgl2lbxt2XV-2F4fRWN7oHI-2BuuIBrEfHvJMHYWXTsmiJ7APZjBe7udH3CLzGLTgTmE1999UoIeh-2Fca6XBhN-2BV0vkldpPXIPxdgkEhow9jPC6s7tpIp1mFTWiHmFW6OBBxZ5XaMpRkyJa

with just the first 346 characters.

It doesn't seem to have and "bizarre" characters in this URL. I may provide 
further details or run any tests upon request.

Thanks in advance.

Best, Alexandre

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

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

Versions of packages urlview depends on:
ii  libc6   2.31-9
ii  libncurses6 6.2+20201114-2
ii  libtinfo6   6.2+20201114-2
ii  sensible-utils  0.0.14

Versions of packages urlview recommends:
ii  chromium [www-browser]  88.0.4324.146-1
ii  firefox [www-browser]   85.0.1-1
ii  w3m [www-browser]   0.5.3+git20210102-2

Versions of packages urlview suggests:
ii  mutt   2.0.5-1
ii  ncftp  2:3.2.5-2.2
ii  wget   1.21-1+b1

-- no debconf information

Bug#983380: sane: HP ENVY 5536 doesn't scan anymore with simple-scan and xsane (hp-scan : error I/O=9)

[Brian Potkin]

On Tue 23 Feb 2021 at 11:49:46 +0100, Jörg Frings-Fürst wrote:

reassign 983380 libsane1
thanks

On Tue 23 Feb 2021 at 11:49:46 +0100, Jörg Frings-Fürst wrote:

> reassign 983380 hplip 3.21.2+dfsg1-1
> severity 983380 normal
> thanks
>
> Hello alain,
>
> thank you for spending your time helping to make Debian better with
> this bug report.
>
> In the past, the error message "error: SANE: Error during device I/O
> (code=9)" always meant an error in the hplip package. In addition, the
> version hplip 3.21.2+dfsg1-1 is also heavily buggy.
>
> I therefore assign the error to the hplip package.

Hello Jörg,

There isn't any bug in hplip. Please see #983349:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983349

I would have closed the report but it has information relating to a
failure of libsane-escl. Therefore, I reassigned the bug to libsane1
for the attention of its maintainer.

Regards,

Brian.

Bug#983340: unblock/preapproval: perl/5.32.1-3 with cross build fixes

[Paul Gevers]

Control: tags -1 confirmed

Hi Niko,

On 22-02-2021 17:03, Niko Tyni wrote:
> This is a pre-approval request as perl is part of build-essential and
> currently frozen.

Ack, thanks.

> The debdiff is unfortunately big; I'm only attaching the diffstat.

We'd still like to have it attached to this bug please, for completeness
and future reference.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977374: ITP: vdf -- package for working with Valve's text and binary KeyValue format

[Stephan Lachnit]

> Did you get anywhere with this? I think the steam package is likely to
> benefit from having this in the archive: the upstream steam-launcher
> package, as repackaged in Debian as steam, already makes use of this code
> for some maintenance tools, although the shipped package doesn't use it
> at runtime.

Oh cool, I didn't know there are use cases outside of protontricks besides
some funny scraping tools.

It lost a bit track of this due to Proton 5.13 not working with protontricks
(at least when I checked last time), so I haven't done anything yet.

> I already maintain some Python libraries, and this one looks straightforward
> to package. May I co-maintain? I actually already have nearly-working
> packaging, although if you already have packaging I'm happy to take a look
> at that instead.

Cool, yeah I don't mind. I wanted to maintain it the Games team, I suggest we
can just add us both as uploaders.
I also have packaged Python libraries before, it shouldn't have any surpises.
If you already have stuff, send me the link to the salsa repo once uploaded,
I can also do a bit of the chore if you want.

> I don't think this needs to be in contrib, I think it would be fine
> in main: the VDF format is associated with non-free Valve products,
> but there's nothing inherently non-free about it. It's a file format
> that anyone could use, like JSON.

Yeah this was before the longer discussion on debian-devel-games.
I agree, main should be fine.

Regards,
Stephan

Bug#983407: Pam: Multiple issues Affecting Upgrades

[Sam Hartman]

> "Paul" == Paul Gevers  writes:

Paul> Just to elaborate, that set is frozen because bits that
Paul> influence a lot of builds can become difficult to manage if a
Paul> bug sneaks in. So it's good to discuss here how much pam can
Paul> influence the built artifacts.  Hence, it's not so much we
Paul> want to prevent it in bullseye, but it's potential impact for
Paul> the release process is already in unstable.

Nod.
Having broken pam for everyone once, I'm very aware of that kind of
issue.
I certainly wouldn't change pam for non-important issues at this point.
My concern would be that we might break things and impact development or
buildds *or* that we might break upgrades.
(Doc changes are of course fine--the standard freeze policy stuff).

At one level, pam probably doesn't matter that much for buildds because
most things don't involve authentication.
And yet enough links against libpam that it  can be a big deal if it
fails.  Also, if it fails to upgrade, it could create a mess that way.

--Sam

Bug#983316: openvswitch-switch: Hard-coded log levels, no way to configure them

[Thomas Goirand]

On 2/22/21 12:25 PM, Benjamin Drung wrote:
> Package: openvswitch-switch
> Version: 2.15.0+ds1-2
> Severity: normal
> 
> Hi,
> 
> Since we run into a log spam issue (probably upstream bug #135 [1]), we
> want to raise the log level and disable the logging to file (syslog is
> enough for us).
> 
> Sadly `/usr/share/openvswitch/scripts/ovs-ctl` (called by
> ovsdb-server.service) hard-codes the log levels and has no way to
> configure them:
> 
> ```
> set "$@" -vconsole:emer -vsyslog:err -vfile:info
> ```
> 
> Please support configuring the log levels via
> `/etc/default/openvswitch-switch`.
> 
> [1] https://github.com/openvswitch/ovs-issues/issues/135
> 

Hi,

I'm sorry, but I have no idea how to translate this bug report into some
action that I should take as the package maintainer. Shouldn't this be
reported upstream, rather than as a Debian bug?

Cheers,

Thomas Goirand (zigo)

Bug#983091: xapian-core FTBFS on i386: test failure

[Adrian Bunk]

On Tue, Feb 23, 2021 at 07:52:42PM +, Olly Betts wrote:
>...
> As you note, on i386 the test was only run with the SSE build before
> the recent debian/rules modernisation, but that doesn't explain why
> m68k now fails.  Looking at older m68k logs, it seems the testsuite
> wasn't being run, though I'm not seeing why not.
>...

m68k and sh4 are building with nocheck.

nocheck handling was lost in the debian/rules rewrite.

> Cheers,
> Olly

cu
Adrian

Bug#983403: ITP: vhba-dkms -- Kernel module that provides a Virtual SCSI HBA, part of the CDEmu software suite

[Matteo Bini]

Package: wnpp
Severity: wishlist
Owner: Matteo Bini 

* Package name: vhba-dkms
  Version : 20200106
  Upstream Author : Chia-I Wu 
* URL : https://cdemu.sourceforge.io/about/vhba/
* License : GPLv2
  Programming Lang: C
  Description : Kernel module that provides a Virtual SCSI HBA, part of the
CDEmu software suite

VHBA (Virtual SCSI Host Bus Adapter) is a kernel module which
acts as a low-level SCSI driver and which provides the SCSI layer with a
virtual SCSI adapter which can have multiple virtual devices.
It is part of the CDEmu software suite.

Its typical use in the CDEmu software suite is to provide virtual devices
that emulates real SCSI Optical (CD-ROM) devices. It works in cooperation with
the CDEmu daemon and libMirage to emulate an Optical (CD-ROM) drive and disc
with information contained in a disc image. For your information, a disc image
is just a copy of the information stored on an actual disc.

Bug#983402: ITP: vhba-dkms -- Kernel module that provides a Virtual SCSI HBA, part of the CDEmu software suite

[Matteo Bini]

Package: wnpp
Severity: wishlist
Owner: Matteo Bini 

* Package name: vhba-dkms
  Version : 20200106
  Upstream Author : Chia-I Wu 
* URL : https://cdemu.sourceforge.io/about/vhba/
* License : GPLv2
  Programming Lang: C
  Description : Kernel module that provides a Virtual SCSI HBA, part of the
CDEmu software suite

VHBA (Virtual SCSI Host Bus Adapter) is a kernel module which
acts as a low-level SCSI driver and which provides the SCSI layer with a
virtual SCSI adapter which can have multiple virtual devices.
It is part of the CDEmu software suite.

Its typical use in the CDEmu software suite is to provide virtual devices
that emulates real SCSI Optical (CD-ROM) devices. It works in cooperation with
the CDEmu daemon and libMirage to emulate an Optical (CD-ROM) drive and disc
with information contained in a disc image. For your information, a disc image
is just a copy of the information stored on an actual disc.


vhba-dkms_20200106-1_all.deb
Description: application/vnd.debian.binary-package

Bug#983415: ircd-hybrid: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: ircd-hybrid 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of ircd-hybrid debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#983414: virtuoso-opensource: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: virtuoso-opensource 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of virtuoso-opensource
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#983413: prometheus-smokeping-prober: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: prometheus-smokeping-prober 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of prometheus-smokeping-
prober debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#983407: Pam: Multiple issues Affecting Upgrades

[Paul Gevers]

Hi Sam,

On 23-02-2021 20:09, Sam Hartman wrote:
> Ah, I thought essential as well as build-essential was frozen.
> Pam is not technically essential but is pre-depends for several
> essentials.

Aha, I may have missed that in my list when generating the list:
https://release.debian.org/bullseye/essential-and-build-essential.txt

I'll update that list.

Just to elaborate, that set is frozen because bits that influence a lot
of builds can become difficult to manage if a bug sneaks in. So it's
good to discuss here how much pam can influence the built artifacts.
Hence, it's not so much we want to prevent it in bullseye, but it's
potential impact for the release process is already in unstable.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983091: xapian-core FTBFS on i386: test failure

[Olly Betts]

On Sat, Feb 20, 2021 at 07:24:52PM +, Olly Betts wrote:
> On Fri, Feb 19, 2021 at 11:36:46AM +0200, Adrian Bunk wrote:
> > With the old debian/rules the test was only run with
> > the SSE build.
> > 
> > If exact results are required and the x87 excess precision is unwanted,
> > test with the non-SSE build can be fixed with:
> > 
> > --- debian/rules.old2021-02-18 15:12:59.097207579 +
> > +++ debian/rules2021-02-18 15:13:51.537168694 +
> > @@ -51,6 +51,10 @@
> >  
> >  export DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
> >  
> > +ifneq (,$(filter $(DEB_HOST_ARCH), i386 m68k))
> > +export DEB_CXXFLAGS_MAINT_APPEND += -ffloat-store
> > +endif
> > +
> >  # For i386 and *-i386.
> >  ifeq ($(patsubst %-i386,i386,$(DEB_HOST_ARCH)), i386)
> >  XAPIAN_BUILD_SSE := 1
> 
> Thanks for the report, and for tracking this down to excess precision.
> 
> The upstream code is meant to address excess precision in the small
> number of places where it matters but I guess there's a newer instance
> that hasn't been caught before, or a newer testcase uncovers an existing
> problem (or perhaps newer GCC optimises differently and that's uncovered
> this.)
> 
> The SSE2 build will get used by more i386 systems, so the overhead
> from -ffloat-store won't affect many there at least, but it is a bit of
> heavy hammer.  I'll take a look and see if I can fix this in a more
> targetted way.  If not applying this for bullseye seems reasonable.
> Or we could change the tests back to run just for the SSE2 build for
> now - in real world use exact results are rarely a requirement, but
> performance often is.

Investigating on i386 I found that all the failures apart from ordecay1
appear to actually be from the effects of excess precision on testcase
code itself (and looking at the m68k log, ordecay1 actually passes
there.)

As you note, on i386 the test was only run with the SSE build before
the recent debian/rules modernisation, but that doesn't explain why
m68k now fails.  Looking at older m68k logs, it seems the testsuite
wasn't being run, though I'm not seeing why not.

I think given where we are in the bullseye freeze the least invasive
change here makes sense, which is to not run the tests for the i386
non-SSE build (they are run for the SSE build, which is the build
which gets used on SSE2-capable machines, which is most of them)
or on m68k (which isn't ideal, but it isn't a release architecture
currently.)  This essentially restores the testing situation to what
it was prior to my modernisation of debian/rules in the previous
upload.

Longer term, sorting out ordecay1 and the testsuite issues (perhaps
building the testsuite with -ffloat-store on affected platforms.)

Cheers,
Olly

Bug#983365: linphone-desktop: chat messages

[Bernhard Schmidt]

Control: tags -1 help

Dear David,

> 1- chat messages (history) are not displayed when I launch the app,
> although I can see they are in the .local/share/linphone/linphone.db
> file (using sqliteb or sqlitebrowser);
> 
> 2- when someone sends me a message, it 'pops' a notification with the
> message text (even if I am in front of the app) but the message is not
> displayed by the application itself, nor the little numbered circle that
> appears (on the appimage 4.2.5 version, to compare) i the left panel,
> in(on top of) the user 'entry', nor in the user chat 'room'.
> 
> I also verified that the message isn't added in the chat_message_content
> of the linphone.db table, and i can see the following 'trace' in the
> terminal i used to launchh the app:
> 
> [22:11:12:653][0x1ff9eb0][Info]components/sip-addresses/SipAddressesModel.cpp:485:
>  "Update (`sip:sender.na...@sip.linphone.org`, 
> `sip:my.n...@sip.linphone.org`) from chat message."

Thanks for your report. Unfortunately I'm extremely swamped for the next
couple of weeks. I have also never used the Chat feature. For this
reason I'm tagging this bug as "help".

Two short questions:
In Bug#983369 a few minutes later you wrote the date in the history is
wrong, although in this bug it reads like you cannot display the history
at all. Which one is correct?

Did you start a fresh linphone profile or is the sqlite database
upgraded from an older version? Could you (for a test) move it away to
have it recreated?

I fully understand choosing an RC severity, but I'm at a loss debugging
this and I lack the time to dig into it, so this bug might make
linphone-desktop miss the Bullseye release unless someone steps up to
debug this.

Bernhard

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

[Dirk Eddelbuettel]

Graham, Martin,

So I logged back onto the s390x box we can access.  Matrix 1.13-2 does fail
the factorization test when doing

_R_CHECK_FORCE_SUGGESTS_=false R CMD check --no-manual \
  --no-vignettes Matrix_1.3-2.tar.gz

and Matrix 1.2-18 passes it. So Graham was right all-along that there was
something in the 1.3-0 transition.  Now, is that ultimately Matrix or the
underlying QR code it uses?  I don't know.  But it reasonably easy for me to
get access (and install the required packages) so once Martin has time to
think through an approach or two I can likely test it.

Best,  Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#980929: reportbug and installation-report

[Nis Martensen]

Hi,

On 18.02.2021 18.04, Holger Wansing wrote:
> Now merged.

Thanks!

> Will upload at the weekend, I think.

A new reportbug upload will follow within 24 hours after you upload.

 Nis

Bug#983412: libc-bin: please add support for DPKG_ROOT to the postinst

[Johannes 'josch' Schauer]

Package: libc-bin
Version: 2.31-9
Severity: wishlist
Tags: patch
User: debian-d...@lists.debian.org

Dear maintainers,

this is a followup on

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910685

and makes libc-bin work with DPKG_ROOT set. Namely, the call to ldconfig
has to respect "$DPKG_ROOT" as it would otherwise attempt to modify the
real root instead of the new root directory.

Note, that this is again not a full solution because this will only work
when building a similar architecture chroot. It is still an improvement
of the status quo and having DPKG_ROOT work for same-architecture
chroots is already useful.

To test, I run:

mmdebstrap --mode=chrootless --variant=custom 
--include=bsdutils,coreutils,debianutils,diffutils,dpkg,findutils,grep,gzip,hostname,init-system-helpers,ncurses-base,ncurses-bin,perl-base,sed,tar,libc-bin
 unstable /dev/null

Without the patch this fails with:

ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied

With the patch above command succeeds. The patch:

diff --git a/debian/debhelper.in/libc-bin.postinst 
b/debian/debhelper.in/libc-bin.postinst
index 802a3ad0..7fc320c5 100644
--- a/debian/debhelper.in/libc-bin.postinst
+++ b/debian/debhelper.in/libc-bin.postinst
@@ -40,15 +40,15 @@ update_to_current_default() {
 }
 
 if [ "$1" = "configure" ] && [ "$2" = "" ] ; then
-  install_from_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf
+  install_from_default "$DPKG_ROOT/usr/share/libc-bin/nsswitch.conf" 
"$DPKG_ROOT/etc/nsswitch.conf"
 fi
 
 if [ "$1" = "configure" ] && [ "$2" != "" ]; then
-  update_to_current_default /usr/share/libc-bin/nsswitch.conf 
/etc/nsswitch.conf
+  update_to_current_default "$DPKG_ROOT/usr/share/libc-bin/nsswitch.conf" 
"$DPKG_ROOT/etc/nsswitch.conf"
 fi
 
 if [ "$1" = "triggered" ] || [ "$1" = "configure" ]; then
-  ldconfig || ldconfig --verbose
+  ldconfig -r "$DPKG_ROOT/" || ldconfig --verbose -r "$DPKG_ROOT/"
   exit 0
 fi
 

Note, that adding DPKG_ROOT is not strictly necessary for
update_to_current_default because currently, DPKG_ROOT will only be used
for initial installations and not for upgrades.

Thanks!

cheers, josch

Bug#983398: ZFS 2.0 update - buster

[Daniel Garcia Sanchez]

Hi Mo,

Thanks for open the bug.

On Tue, Feb 23, 2021 at 3:22 PM M. Zhou  wrote:
>
> Hi Daniel,
>
>
> Could you please briefly describe the configuration of your
> ZFS so the others can try to reproduce the problem?

I recently installed ZFS on root using the following guide:
https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html

The configuration of my system is:
- I use native ZFS encryption
- I use old legacy Bios to boot
- I  use an ext4 partition for the boot partitin and the rest of the
system is in a single ZFS pool (with datasets) as described in the
"root on ZFS" guide.

> And is there any existing bug similar to the one you
> have encountered? See:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=zfs-linux

I do not know if those bugs are related. I'll try to reproduce the bug
using a virtual machine. I'll keep you posted!

Bug#983399: filter for portscans detected by scanlogd

[Mike Gabriel]

Package: fail2ban
Severity: whislist
Tags: patch

Hi,

today I worked on a fail2ban filter rule that is able to filter out  
log lines from scanlogd. The scanlogd daemon is a port scan detector.


This is my /etc/fail2ban/filter.d/scanlogd.conf file:

```
# Fail2Ban filter for port scans detected by scanlogd

[Definition]

failregex = scanlogd:\ \ to\ .*\ ports\ .*

ignoreregex =

# Author: Mike Gabriel 
```

Hope, this is helpful.

Mike


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpNGgfAHNsmz.pgp
Description: Digitale PGP-Signatur

Bug#983394: apt-cacher-ng suddently stopped working

[Eduard Bloch]

Hallo,
* nicoo [Tue, Feb 23 2021, 02:16:25PM]:

>   Fetched 53,0 kB in 1s (67,0 kB/s)
>   Reading package lists... Done
>   Building dependency tree... Done
>   1 package can be upgraded. Run 'apt list --upgradable' to see it.
>   W: Failed to fetch 
> http://localhost:3142/debian/dists/bullseye/InRelease  502  Mirror blocked 
> due to repeated errors [IP: 127.0.0.1 3142]
>   W: Failed to fetch 
> http://localhost:3142/debian/dists/experimental/InRelease  502  Mirror 
> blocked due to repeated errors [IP: 127.0.0.1 3142]
>   W: Failed to fetch http://localhost:3142/debian/dists/sid/InRelease  
> 502  Mirror blocked due to repeated errors [IP: 127.0.0.1 3142]
>   W: Some index files failed to download. They have been ignored, or old 
> ones used instead.
>
> This is what happens in syslog at the same time:
>
>   systemd[1]: Started Apt-Cacher NG software download proxy.
>   apt-cacher-ng[1540]: [warn] Call to getaddrinfo_async with no 
> evdns_base configured.
>   apt-cacher-ng[1540]: [warn] Call to getaddrinfo_async with no 
> evdns_base configured.
>   apt-cacher-ng[1540]: [warn] Call to getaddrinfo_async with no 
> evdns_base configured.

See #982984 and the fixed version suggested there. Or just test
https://www.unix-ag.uni-kl.de/~bloch/acng/snap3.6.1/ and please report
whether it solves your issue.

Thanks, Eduard.

Bug#983407: Pam: Multiple issues Affecting Upgrades

[Sam Hartman]

> "Paul" == Paul Gevers  writes:

Paul> On 23-02-2021 19:17, Sam Hartman wrote:
>> This is just a FYI, opened as a bug because you've expressed a
Paul> If it's in time to migrate before March 12, there's nothing to
Paul> unblock.  We're still only in soft freeze and pam is not on
Paul> our build-essentials list.

Ah, I thought essential as well as build-essential was frozen.
Pam is not technically essential but is pre-depends for several
essentials.

>> or I may want to ask for additional review before I'm ready to
>> recommend inclusion in testing.

Paul> Be aware that we're no PAM experts. At least, I have no clue.

Nod, I was thinking of asking more broadly than debian-release if only
because you are busy.
Review will mostly be on the maintainer script and debconf side; the pam
specific bits are not interesting.

>> * 982530: removal of pam_tally

Paul> Severity currently is "normal", sounds like that not correct?
Paul> At least it means it's not on our radar.

Definitely wrong.
Wasn't sure whether it should be serious or grave.
Admittedly leaving it as normal seems wrong.
I have upgraded to serious.

>> Plan is to detect the situation and scream in the preinst.  Down
>> side is that means new strings that need translation (debconf
>> templates)

Paul> And how about mentioning this in the release notes?

Will do that too.

>> * 982295: pam won't deal with upgrades without an init script

Paul> "Only" severity important, again, do you think that is
Paul> correct?

Possibly.  This one is important or serious.
It's serious if there's some package that breaks badly that has actually
removed its init script.
I haven't dug around to prove that it's RC, and felt uncomfortable
upgrading a bug in Steve's package (even though I'm an uploader) without
proof.

Bug#898177: [related feature respect /etc/mailname] Re: please add MAILFROM to cron

[Christian Kastner]

On 2021-02-23 09:03, Tomas Pospisek wrote:
> On Mon, 22 Feb 2021, Christian Kastner wrote:
> Oh, this is news indeed. I think Javier hasn't been working on for the
> last 3 years [1]? So I'd say you Christian have been cron's defacto
> maintainer?

While possibly so, I must note that effective with the last upload, I
have removed myself from the Uploaders field, and therefore no longer am
a cron maintainer.
 
> So if the plan to migrate Debian's cron to cronie has been abandoned
> (by you) and instead the plan is to drop cron and instead use systemd
> timers as the default "cron" mechanism in Debian then I think this
> defacto decision should be communicated clearly.

The default "cron" mechanism in Debian will continue to be, well, cron.
This is defined by the Debian Policy, and hence would need a Policy
change, which almost certainly won't happen fast, and without
discussion.

The switch to systemd timers is just something that I have observed in
practice. Packages shipping both timers and crontabs, with the latter
being no-ops when systemd is detected. I, personally, believe that this
is the right practice.

The switch to cronie as default "cron" is indeed something that I
possibly could have effected alone (as it doesn't require a Policy
change), but recently abandoned.

> As you might have seen I have added some suggestions on how people
> could help with the migration from cron to cronie on cron's Debian
> wiki page [2]. If the plan to migrate to cronie has been abandoned
> then such initiatives do not make sense any more...?

I think those suggestions are still spot on, and I believe migrating
from cron to cronie is still the right thing to do.

I'm just the wrong person for driving this :-) In the meantime, I have
become fully occupied with other projects within Debian, and simply
cannot drive this effort, or continue to be a maintainer at all.

However, if anyone else wants to take over the effort, and I can help as
a mentor and/or upload sponsor, feel free to do so. I have filed an RFA
for cronie a while ago (#974038) and have received pings from some
interested parties, but no results yet.

My plans for cronie were probably too big anyway: instead of carrying
over all of our features, perhaps it would be better to stick with
standard "upstream" cronie instead, and to focus on making the switching
process as easy as possible. If anyone wants to try this, feel free to
contact me any time.

Best,
Christian

> [1] 
> https://metadata.ftp-master.debian.org/changelogs//main/c/cron/cron_3.0pl1-137_changelog
> [2] https://wiki.debian.org/cron?action=diff=9=10<

Bug#983327: qgis: FTBFS with PROJ 8.0.0

[Sebastiaan Couwenberg]

Control: tags -1 fixed-upstream

https://github.com/qgis/QGIS/commit/fc1ac8bef8dcc3194857ecd32519aca4867b4fa1

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

Bug#983407: Pam: Multiple issues Affecting Upgrades

[Paul Gevers]

Control: tags -1 moreinfo

Hi Sam

On 23-02-2021 19:17, Sam Hartman wrote:
> This is just a FYI, opened as a bug because you've expressed a
> preference for that communication style.

Ack.

> I hope to have something in experimental or unstable by end of this
> week.  Depending on my confidence in the fixes, I may be ready for an
> unblock at that point

If it's in time to migrate before March 12, there's nothing to unblock.
We're still only in soft freeze and pam is not on our build-essentials list.

> or I may want to ask for additional review
> before I'm ready to recommend inclusion in testing.

Be aware that we're no PAM experts. At least, I have no clue.

> * 982530: removal of pam_tally

Severity currently is "normal", sounds like that not correct? At least
it means it's not on our radar.

> Plan is to detect the situation and scream in the preinst.
> Down side is that means new strings that need translation (debconf templates)

And how about mentioning this in the release notes?

> * 982295: pam won't deal with upgrades without an init script

"Only" severity important, again, do you think that is correct?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983411: brian: tests should be run with pytest instead of nosetest

[Étienne Mollier]

Source: brian
Version: 2.4.2-6
Severity: normal

Greetings,

While upstreaming a patch for "brian", the upstream author has
been kind enough to have a look at the build logs, and notify us
that the test suite should probably be better run with pytest,
instead of the current nosetest based invocation[1].  Note that
there is also a risk that the test suite uses way more compute
power than it does as is.

[1]: https://github.com/brian-team/brian2/pull/1277

This bug is to document the issue on Debian side.

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#983410: i2p: new upstream 0.9.49

[jonatan]

Package: i2p
Version: 0.9.49
Severity: Normal

Please consider to upgrade to the current upstream version (0.9.49).

Best regards
Jonatan

Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0

[Kai Pastor, DG0YT]

Am 21.02.21 um 16:32 schrieb Bas Couwenberg:

Source: openorienteering-mapper
Version: 0.9.4-2
Severity: important
Tags: upstream ftbfs
User: debian-...@lists.debian.org
Usertags: proj-8.0
Control: forwarded -1 https://github.com/OpenOrienteering/mapper/issues/1214

Dear Maintainer,

Your package FTBFS with PROJ 8.0.0:

  CMake Error at 
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
Could NOT find PROJ4 (missing: PROJ4_INCLUDE_DIR)

It needs to be ported to use proj.h instead of proj_api.h which has been 
removed.

Kind Regards,

Bas


Mapper source code is ported to use proj.h for modern PROJ. However, the 
embedded fallback FindPROJ4.cmake module isn't, and possible won't.


Does Debian build PROJ 8.0.0 with cmake? Debian doesn't seem to provide 
the cmake config files for PROJ. openorienteering-mapper is meant to 
pick up these config files. If it finds a recent PROJ in that way, it 
won't use proj_api.h.


Regards, Kai

Bug#983409: raspi-firmware: /etc/kernel/postinst.d/z50-raspi-firmware fails to ignore old-dkms initrds

[Colm Buckley]

Package: raspi-firmware
Version: 1.20200601-3~bpo10+1
Severity: normal
Tags: patch

Dear Maintainer,

The /etc/kernel/postinst.d/z50-raspi-firmware script which copies the kernel
and initrd to /boot/firmware, fails to ignore any old initrds which were renamed
by DKMS (usually of the form initrd.img-version-arch.old-dkms). These usually 
compare
as "newer" than the correct initrd, so lead to incorrect config.txt contents and
possible boot failure.

I'd suggest modifying this script as below; summarized as:

  # move this line to earlier in the script
  arch=$(dpkg --print-architecture)

  latest_kernel=$(ls -1 /boot/vmlinuz-*$arch | sort -V -r | head -1)
  [...]
  latest_initrd=$(ls -1 /boot/initrd.img-*$arch | sort -V -r | head -1)

- ie: looking specifically for kernels and initrds which end in the current
architecture name.

Not sure if this needs to go upstream. I suspect that the kernel and initrd
detection in this script could use a real reworking, see also bug #966503.

Thanks,

Colm


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.9.0-0.bpo.5-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages raspi-firmware depends on:
ii  dosfstools  4.1-2
ii  dpkg1.19.7

raspi-firmware recommends no packages.

raspi-firmware suggests no packages.

-- Configuration Files:
/etc/kernel/postinst.d/z50-raspi-firmware changed:
set -e
exec &2
eval set -- "$DEB_MAINT_PARAMS"
case "$1" in
  configure|remove)
;;
  *)
exit 0
;;
esac
if ischroot ; then
  true # chroot detected - skip mount point check
elif test -e /usr/bin/systemd-detect-virt && systemd-detect-virt -q ; then
  true # virtualization detected - skip mount point check
elif ! mountpoint -q /boot/firmware; then
  echo "raspi-firmware: missing /boot/firmware, did you forget to mount it?" >&2
  exit 1
fi
mkdir -p /boot/firmware
arch=$(dpkg --print-architecture)
latest_kernel=$(ls -1 /boot/vmlinuz-*$arch | sort -V -r | head -1)
if [ -z "$latest_kernel" ]; then
  echo "raspi-firmware: no kernel found in /boot/vmlinuz-*$arch, cannot 
populate /boot/firmware"
  exit 0
fi
latest_initrd=$(ls -1 /boot/initrd.img-*$arch | sort -V -r | head -1)
if [ -z "$latest_initrd" ]; then
  echo "raspi-firmware: no initrd found in /boot/initrd.img-*$arch, cannot 
populate /boot/firmware"
  exit 0
fi
CMA=64M
ROOTPART=$(findmnt -n --output=source /) || true
if [ -z "$ROOTPART" ]; then ROOTPART=/dev/mmcblk0p2;fi
KERNEL="auto"
INITRAMFS="auto"
CONSOLES="auto"
if [ -r /etc/default/raspi-firmware ]; then
. /etc/default/raspi-firmware
fi
if [ "arm64" = "$arch" ]; then
  dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}/broadcom"
else
  # there is no vendor subdirectory for armhf
  dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}"
fi
if [ "$KERNEL" = "auto" ]; then
  for dtb in ${dtb_path}/bcm*.dtb; do
[ -e "${dtb}" ] && cp "${dtb}" /boot/firmware/
  done
  latest_kernel_basename=$(basename "$latest_kernel")
  latest_initrd_basename=$(basename "$latest_initrd")
  KERNEL=${latest_kernel_basename}
  cp "$latest_kernel" /boot/firmware/
  cp "$latest_initrd" /boot/firmware/
  if [ "$CONSOLES" = "auto" ]; then
  serial="ttyS1,115200"
  fi
fi
: >/boot/firmware/config.txt
if [ "$arch" = "arm64" ]; then
  cat >/boot/firmware/config.txt <>/boot/firmware/config.txt <>/boot/firmware/config.txt <>/boot/firmware/config.txt 

Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0

[Sebastiaan Couwenberg]

On 2/23/21 7:47 PM, Kai Pastor, DG0YT wrote:
> Am 21.02.21 um 16:32 schrieb Bas Couwenberg:
>> Source: openorienteering-mapper
>> Version: 0.9.4-2
>> Severity: important
>> Tags: upstream ftbfs
>> User: debian-...@lists.debian.org
>> Usertags: proj-8.0
>> Control: forwarded -1
>> https://github.com/OpenOrienteering/mapper/issues/1214
>>
>> Dear Maintainer,
>>
>> Your package FTBFS with PROJ 8.0.0:
>>
>>   CMake Error at
>> /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165
>> (message):
>>     Could NOT find PROJ4 (missing: PROJ4_INCLUDE_DIR)
>>
>> It needs to be ported to use proj.h instead of proj_api.h which has
>> been removed.
>>
>> Kind Regards,
>>
>> Bas
> 
> Mapper source code is ported to use proj.h for modern PROJ. However, the
> embedded fallback FindPROJ4.cmake module isn't, and possible won't.

A patch for that was just submitted to this bugreport.

> Does Debian build PROJ 8.0.0 with cmake? Debian doesn't seem to provide
> the cmake config files for PROJ.

That's an upstream issue with PROJ. When it's built with autotools it
doesn't install the cmake bits, it only does so when it's built with cmake.

It's good practice to include the Find modules for any dependencies that
are not part of cmake itself to not need upstream projects to install
cmake modules for them.

> openorienteering-mapper is meant to
> pick up these config files. If it finds a recent PROJ in that way, it
> won't use proj_api.h.

Either way the FindPROJ4.cmake included in openorienteering-mapper needs
to be updated to support PROJ 8:

 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=983254;filename=proj8.patch;msg=12

Kind Regards,

Bas

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

Bug#983408: New upstream release 0.0.24

[Marco Amadori]

Package: 0ad
Version: 0.0.23.1-5+b1
Severity: wishlist
Tags: upstream

New tarballs available at: https://play0ad.com/download/source/

-- 
ESC:wq

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Control: found -1 3.21.2+dfsg1-1

Hello there Bernhard,
(CC'ing d-arm for help)

Sadly, I could confirm on a local armhf QEMU instance that this serious bug is 
still present, in sid and bullseye; the steps in
https://bugs.debian.org/972339#10 still apply and trigger the SIGABRT.

Although I understand what you're saying in theoretical terms here, I'm 
completely at loss to propose a patch: I'm way over my head with my 10+years-
old C and gdb competences. In the absence of any interest from upstream, I 
need help to fix hplip on armhf.

(Note that amd64 is apparently also affected; see #974828)

Whoever willing to help; if you need anything from me (as maintainer), please 
ask! I'm happy to explain my use of git-debrebase, or provide a different git 
history if it helps, I mostly don't want to be in the way of a fix!

Humbly,
OdyX

Le samedi, 24 octobre 2020, 14.05:04 h CET Bernhard Übelacker a écrit :
> I could reproduce this issue too.
> 
> Attached is a valgrind run showing one invalid write
> and a gdb session showing the issue.
> 
> It looks like mallocs management data, which resides in the 8 bytes
> before a returned pointer, gets overwritten and therefore
> the free fails because "mchunk_size" is then 0.
> 
> Kind regards,
> Bernhard
> 
> 
> Old value = 6057
> New value = 0
> __memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
> warning: Source file is more recent than executable.
> 295 tst count, #4
> 1: compressBuf =  named `this'> 2: /x *(int*)(0x7f5f43e8-4) = 0x0
> (gdb) bt
> #0  __memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
> #1  0x7f55b8d2 in memcpy (__len=379, __src=,
> __dest=) at
> /usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34 #2 
> Mode9::Process (this=0x7f5e0e70, input=0x7f5e0e84) at
> prnt/hpcups/Mode9.cpp:405 #3  0x7f562de0 in Pipeline::Process
> (raster=, this=0x7f5d7340) at prnt/hpcups/Pipeline.cpp:79 #4
>  Pipeline::Execute (this=0x7f5d7340, InputRaster=) at
> prnt/hpcups/Pipeline.cpp:79 #5  0x7f562e02 in Pipeline::Execute
> (this=0x7f5e6b88, InputRaster=) at
> prnt/hpcups/Pipeline.cpp:83 #6  0x7f562e02 in Pipeline::Execute
> (this=0x7f5e6b70, InputRaster=) at
> prnt/hpcups/Pipeline.cpp:83 #7  0x7f55a20a in
> HPCupsFilter::processRasterData (this=0x7f5b87c4 ,
> cups_raster=) at prnt/hpcups/HPCupsFilter.cpp:766 #8 
> 0x7f55a6ee in HPCupsFilter::StartPrintJob (this=0x7f5b87c4 ,
> argc=6, argv=0xbefff7b4) at prnt/hpcups/HPCupsFilter.cpp:584 #9  0xb6bd9a20
> in __libc_start_main (main=0x7f5587d1 , argc=6,
> argv=0xbefff7b4, init=, fini=0x7f56ed5d <__libc_csu_fini>,
> rtld_fini=0xb6fe1075 <_dl_fini>, stack_end=0xbefff7b4) at libc-start.c:308
> #10 0x7f55889c in _start () at prnt/hpcups/HPCupsFilter.cpp:919
> 
> 
> https://sources.debian.org/src/hplip/3.21.2+dfsg1-1/prnt/hpcups/Mode9.cpp/#L
> 405


-- 
OdyX

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

Bug#983379: linux uml segfault

[Anton Ivanov]

On 23/02/2021 17:26, Ritesh Raj Sarraf wrote:

Added the debian bug report in CC.

On Tue, 2021-02-23 at 17:19 +, Anton Ivanov wrote:

The current Debian user-mode-linux package in unstable is based on
the 5.10.5 stable source which includes the mentioned patch, but is
still causing an error for some users.


After updating the tree to 5.10.5 and applying all Debian patches
from the package, I cannot reproduce the bug.

I am running it on 5.10, 5.2 and 4.19 hosts with the same parameters
without issues. Hosts are all up to date Debian 10.8 and so is the
UML userspace.



Did you mean 5.10, 5.2 and 4.19 (UML) guests ?


No. Hosts.

I have several 6core/12thread Ryzens which are used for development 
testing.


They all use identical userspace with the sole difference being the 
kernel. They all use a selection of 5.x because 4.19 does not support 
the hardware properly.


The 4.19 testing is done on my old "test farm" which is all A8s and 
Athlon X760.




We've seen this happen on Debian Testing and Unstable Host (of which
the former would soon be the next stable i.e. Debian Bullseye).






In our tests, when running the same linux uml binary (5.10) on a Debian
Stable Host, it is working fine.




OK. I will upgrade one of my systems to Debian testing to try to 
reproduce this.



--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#983345: therion: FTBFS with PROJ 8.0.0

[Sebastiaan Couwenberg]

On 2/23/21 5:51 AM, Sebastiaan Couwenberg wrote:
> On 2/22/21 11:42 PM, Wookey wrote:
>> On 2021-02-22 18:23 +0100, Bas Couwenberg wrote:
>>> Your package FTBFS with PROJ 8.0.0, it hung at `make samples`:
>>>  faketime "" /usr/bin/make samples
>>
>> This is an issue with faketime, which was added to make the package
>> reproducible. For some reason I don't understand it works on the
>> buildds bug hangs under a local sbuild build unless you do that build
>> as root.
>>
>> Fiddling with Rule-Requires-Root doesn't seem to affect this. 
>>
>> So I am pretty certain that this is an artifact of the way you are
>> doing the build test, rather than a genuine issue with Proj v8. 
>>
>> I would like to remove this issue because I have to remember to do
>> builds as root. Knowing why it works OK on the real buildds would be 
>> helpful. 
> 
> You can close this issue as notfound if you can confirm that it builds
> successfully with proj from experimental.
> 
> I don't use sbuild. I used pdebuild with --use-pdebuild-internal to not
> require the build dependencies outside the chroot for the clean target.

Logging in to the chroot and building as root doesn't resolve the issue,
sed still hangs.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
root 22506  0.0  0.1  18944 16252 pts/3S+   19:09   0:00
  \_ /usr/bin/perl /usr/bin/dpkg-buildpackage -us -uc
root 22840  0.0  0.0   2968  2260 pts/3S+   19:09   0:00
  |   \_ /usr/bin/make -f debian/rules binary
root 22841  0.0  0.1  16380 13708 pts/3S+   19:09   0:00
  |   \_ /usr/bin/perl /usr/bin/dh binary
root 28057  0.0  0.0   2972  2068 pts/3S+   19:15   0:00
  |   \_ /usr/bin/make -f debian/rules 
override_dh_auto_build-indep
root 28082  0.0  0.0   2728   628 pts/3S+   19:15   0:00
  |   \_ /bin/sh -c faketime "" /usr/bin/make samples
root 28083  0.0  0.0   2796  1928 pts/3S+   19:15   0:00
  |   \_ faketime  /usr/bin/make samples
root 28085  0.0  0.0   4524  2856 pts/3S+   19:15   0:00
  |   \_ /usr/bin/make samples
root 28088  0.0  0.0   4280  1980 pts/3S+   19:15   0:00
  |   \_ /bin/sh -c echo 8.0.0 | sed 's/\..*//'
root 28090 97.2  0.0   4848  2412 pts/3R+   19:15   5:50
  |   \_ sed s/\..*//
root 22507  0.0  0.0   2636   548 pts/3S+   19:09   0:00
  \_ tee ../therion.build

Bug#983407: Pam: Multiple issues Affecting Upgrades

[Sam Hartman]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: vor...@debian.org

Hi.  I'm writing with my pam uploader hat on to give you a heads up about two 
issues  that are kind of nasty and affect upgrades.  This is just a FYI, opened 
as a bug because you've expressed a preference for that communication style.
Feel free to close now; if this is still open when I have an unblock ready, 
I'll close and file the unblock.

I hope to have something in experimental or unstable by end of this
week.  Depending on my confidence in the fixes, I may be ready for an
unblock at that point, or I may want to ask for additional review
before I'm ready to recommend inclusion in testing.


* 982530: removal of pam_tally

Up through buster, there were pam_tally and pam_tally2 modules available to 
provide lockout.
These modules were not in the default configuration, but apparently various 
hardening guides turned them on.

They were deprecated upstream, and we've chosen to remove them from bullseye.
Unfortunately, if your pam config  includes these modules, then probably you 
can't login until you boot with rescue media and fix the pam config.
Moreover, while you probably get reasonable errors in the journal, you probably 
can't see that because you can't log in.

Plan is to detect the situation and scream in the preinst.
Down side is that means new strings that need translation (debconf templates)

* 982295: pam won't deal with upgrades without an init script

Pam restarts various services on upgrade (including buster to bullseye).  The 
consequence of not restarting can be segfaults or failed pam authentications 
going forward.  (libpam-modules gets out of sync with libpam0g and ether fails 
to dlopen or segfaults depending).
The logic in libpam0g.postinst is init-script specific.

Our current policy allows init scripts to be removed, and apparently
various users and downstreams are removing init scripts even when the
package still contains them.
I'm testing a patch to  use systemd facilities for doing restarts if booted 
with systemd as init.





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

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

Bug#981188: kodi: Crash on playing some streams with recent tvheadend+ffmpeg+libva+radeonsi

[jurek]

On Sun, 07 Feb 2021 14:59:47 + Vasyl Gello wrote:
> Hi Jurek!
>
> First of all, thanks for the test file! Stepping forward and backward
via arrow keys (+10 / -10 seconds) works for me without crash.
>
> The system is Debian bullseye reinstalled from scratch, GPU is AMD
E-300 (HP 635 laptop using radeonsi).
> -- 
> Vasyl Gello
> ==
> Certified SolidWorks Expert
>
> Mob.:+380 (98) 465 66 77
>
> E-Mail: vasek.ge...@gmail.com
>
> Skype: vasek.gello
> ==

> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Hi

I bought display port to hdmi adapter, and now I am using intel graphics
and its working fine. So I think you can close this issue.

Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

[Martin Maechler]

On Tue, Feb 23, 2021 at 3:17 PM Graham Inggs  wrote:
>
> Hi Dirk
>
> On Tue, 23 Feb 2021 at 15:34, Dirk Eddelbuettel  wrote:
> > If it were me I would turn off the autopkgtest in r-cran-glmmtmb (maybe just
> > on s390x) and move on.
>
> That would just be hiding the problem.
>
> If it is the kind of bug I described previously, it shows up more
> often on big-endian systems, but it is still present on little-endian
> systems, and will show up in the right (wrong) conditions.
>
You may be right on spot, Graham, or not..
Currently I don't have time to investigate ... also I *have* been a
bit puzzled by therankMatrix(*, "qr")   -- Matrix-only --
discrepancy that Dirk found.
I agree it *would* be good to dig further, but that needs a chunk of
dedicated time (and "free head")  which I don't have for now.

Apropos 'rabbit hole' :  Isn't the origin -- long before the Matrix
movie -- in  Lewis Carrol's  "Alice in Wonderland"  (1865 !!):
https://en.wikipedia.org/wiki/White_Rabbit   ??

Best, Martin


-- 
Martin Maechler,
Seminar fuer Statistik, ETH Zurich

Bug#983380: sane: HP ENVY 5536 doesn't scan anymore with simple-scan and xsane (hp-scan : error I/O=9)

[Dennis Filder]

Control: tag -1 + moreinfo sid

What did you change before the scanner stopped working?  I see that
you are running hplip 3.21.2 which is not yet in testing.  Does a
downgrade to 3.20.11+dfsg0-2 fix the issue?  This would be very
important to know.

Some HP devices may need a proprietary firmware plugin that Debian
cannot ship.  What have you installed for firmware?

It would also help if you could provide the following:

* output of "scanimage -d hpaio:/usb/ENVY_5530_series?serial=CN595530XD06BX 
- --dont-scan > /tmp/si.ds"
  (scanimage is from package sane-utils)

* output of "scanimage -d hpaio:/usb/ENVY_5530_series?serial=CN595530XD06BX 
- --test > /tmp/si.test"

* the relevant dmesg output

* a tshark (package tshark) trace of the USB traffic when trying to
  scan (tracing USB traffic is a bit of an advanced topic; searching
  for "wireshark" "usbmon" on the web will give you some tutorials,
  but [1] and [2] should already be good starting points).

If you can make the scanner work with a downgrade, try to do the same
with the working configuration and see what is different in the
failing one.  Use diff for that if possible.

What concerns me is that lsusb throws errors which indicates that this
might be a problem with the device itself.

Good luck!

1: https://wiki.wireshark.org/CaptureSetup/USB
2: https://superuser.com/questions/873896/wireshark-usb-traces-explanations

Bug#983359: ntfs-3g has a wrong Pre-Depends

[GCS]

Control: tags -1 +confirmed pending

Hi Steve,

Your diligence is missing from Debian, but good to see that you are
still around.

On Mon, Feb 22, 2021 at 10:36 PM Steve Langasek
 wrote:
> The ntfs-3g package has a Pre-Depends on fuse.  This is improper;
> Pre-Depends should only be used when one package is required to be
> configured before another package is unpacked.  Since ntfs-3g has no preinst
> script, this is not the case for ntfs-3g and the Pre-Depends should be moved
> to Depends.
 You are right and I don't know why it was put there in the first
place in November, 2006. Its postinst uses dpkg-statoverride on
/bin/fusermount but for that time dpkg guarantees all dependencies to
be in state unpacked at least.
Going to make the mentioned change after some testing.

Cheers,
Laszlo/GCS

Bug#923500: snapd: non-classic snap not confined

[Michael Vogt]

Just a quick update - we looked at this and we think the apparmor
support in Debian is sufficient to enable it in snaps by
default.

This is being worked on in https://github.com/snapcore/snapd/pull/9936
and once that lands I will upload to Debian. The goal is within this
week.

In addition to the spread tests we manually validated some key snaps
and did not see regressions.

With that upload we can close this bug because snaps are confined on
Debian. Snaps will see the read only version of the "base" snap
(e.g. core or core20) and only what access is granted via snap
"interfaces". 

Cheers,
 Michael

Bug#983406: libonig: Upstream changes POSIX API configure option as --enable-binary-compatible-posix-api=yes

[Hideki Yamane]

Source: libonig
Version: 6.9.6-1
Severity: important
Tags: patch

Dear Maintainer,

 Bug#958467 strike back again, it's because the change in upstream. See 
README.md.

> Version 6.9.6
> -
> * When using configure script, if you have the POSIX API enabled in an earlier
> version (disabled by default in 6.9.5) and you need application binary 
> compatibility
> with the POSIX API, specify "--enable-binary-compatible-posix-api=yes" 
> instead of
> "--enable-posix-api=yes". Starting in 6.9.6, "--enable-posix-api=yes" only 
> supports
> source-level compatibility for 6.9.5 and earlier about POSIX API. (Issue #210)

 Just replace its option solves problem.



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

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libonig-6.9.6/debian/changelog libonig-6.9.6/debian/changelog
--- libonig-6.9.6/debian/changelog  2020-11-08 21:08:04.0 +0900
+++ libonig-6.9.6/debian/changelog  2021-02-24 02:25:03.0 +0900
@@ -1,3 +1,12 @@
+libonig (6.9.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules
+- As upstream change, set "--enable-binary-compatible-posix-api=yes",
+  instead of "--enable-posix-api"
+
+ -- Hideki Yamane   Wed, 24 Feb 2021 02:25:03 +0900
+
 libonig (6.9.6-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libonig-6.9.6/debian/rules libonig-6.9.6/debian/rules
--- libonig-6.9.6/debian/rules  2020-11-08 19:46:09.0 +0900
+++ libonig-6.9.6/debian/rules  2021-02-24 02:24:56.0 +0900
@@ -17,7 +17,7 @@
dh $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-posix-api
+   dh_auto_configure -- --enable-binary-compatible-posix-api=yes
 
 override_dh_install:
$(RM) debian/tmp/usr/bin/onig-config

Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

[Dennis Filder]

I just noticed that firehol has no autopkgtests yet, but since
ci.debian.net can run those under LXC/qemu instead of chroot this
would allow for the test suite to run.  It might however be a bit of a
challenge to set that up at home if troubleshooting is needed.

Copying the one for root-unittests from firewalld seems like a good
starting point:
https://salsa.debian.org/utopia-team/firewalld/-/blob/debian/master/debian/tests/control

The maintainer apparently faced a similar problem and disabled the
test suite for buildd builds:
https://salsa.debian.org/utopia-team/firewalld/-/commit/d24a8b8b5b29708c811bcad4b9885d1665875aca
Maybe he'll be willing to help with setting this up.

The autopkgtest probably will have to specify "needs-root" to set
unprivileged_userns_clone=1 (unless the VM image already has that set
up), but the test suite itself needn't run as root.

Regards,
Dennis.

Bug#983379: linux uml segfault

[Ritesh Raj Sarraf]

Added the debian bug report in CC.

On Tue, 2021-02-23 at 17:19 +, Anton Ivanov wrote:
> > The current Debian user-mode-linux package in unstable is based on
> > the 5.10.5 stable source which includes the mentioned patch, but is
> > still causing an error for some users.
> 
> After updating the tree to 5.10.5 and applying all Debian patches
> from the package, I cannot reproduce the bug.
> 
> I am running it on 5.10, 5.2 and 4.19 hosts with the same parameters
> without issues. Hosts are all up to date Debian 10.8 and so is the
> UML userspace.
> 

Did you mean 5.10, 5.2 and 4.19 (UML) guests ?

We've seen this happen on Debian Testing and Unstable Host (of which
the former would soon be the next stable i.e. Debian Bullseye).

In our tests, when running the same linux uml binary (5.10) on a Debian
Stable Host, it is working fine.


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


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

Bug#983405: adduser: race conditions in adduser

[Brent Baccala]

Package: adduser
Version: 3.116ubuntu1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

A custom designed system service attempted to add several users near-
simultaneously.  I got two users created with the same GID.  One of them had no
home directory.

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

I deleted the users and manually re-added them.

Then I modified the custom service to protect the call to adduser with a POSIX
semaphore.

   * What was the outcome of this action?

I fixed the immediate problem by hand, and I expect that the semaphore will
prevent the same problem for this particular service.

   * What outcome did you expect instead?

adduser should protect itself against these kind of race conditions.

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



-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-135-generic (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages adduser depends on:
ii  debconf [debconf-2.0]  1.5.66ubuntu1
ii  passwd 1:4.5-1ubuntu2

adduser recommends no packages.

Versions of packages adduser suggests:
ii  ecryptfs-utils  111-0ubuntu5
ii  liblocale-gettext-perl  1.07-3build2
ii  perl5.26.1-6ubuntu0.5

-- debconf information:
  adduser/homedir-permission: true
  adduser/title:

Bug#977374: ITP: vdf -- package for working with Valve's text and binary KeyValue format

[Simon McVittie]

On Tue, 23 Feb 2021 at 16:50:41 +, Stephan Lachnit wrote:
> It lost a bit track of this due to Proton 5.13 not working with protontricks
> (at least when I checked last time), so I haven't done anything yet.

Proton 5.13+ runs in a container, using a container tool currently
maintained by, er, me :-)

I think future development is likely to need a way to inject arbitrary
commands into a running container, at which point protontricks will
probably be able to use that to make things happen inside the container -
but this hasn't been a priority so far.

> If you already have stuff, send me the link to the salsa repo once uploaded

Will do!

smcv

Bug#983404: python3-scipy: scipy 1.6.1 changed API for sparse (COO) matrices

[Drew Parsons]

Package: python3-scipy
Version: 1.6.1-1
Severity: serious
Tags: upstream
Justification: FTBFS
Control: forwarded -1 https://github.com/scipy/scipy/issues/13585
Control: affects -1 src:pandas src:qutip

scipy 1.6.1 marketed itself as "bug-fix only", but in fact introduced
a change in the API handling sparse matrices with COO constructor.

Reported upstream at https://github.com/scipy/scipy/issues/13585
with PR proposed at https://github.com/scipy/scipy/pull/13586

This causes pandas and qutip test to fail, so treating as FTBFS
(severity serious). scipy 1.6.1 is not fit for bullseye.

The signature of the problem is error messages concerning discrepancy
dtyped of COO matrices

e.g.
* pandas (pandas.tests.arrays.sparse.test_array.TestAccessor.test_from_coo):

index = pd.MultiIndex.from_arrays([[0, 0, 1, 3], [0, 2, 1, 3]])
expected = pd.Series([4, 9, 7, 5], index=index, dtype="Sparse[int]")
>   tm.assert_series_equal(result, expected)
E   AssertionError: Attributes of Series are different
E   
E   Attribute "dtype" are different
E   [left]:  Sparse[float64, nan]
E   [right]: Sparse[int64, 0]

/usr/lib/python3/dist-packages/pandas/tests/arrays/sparse/test_array.py:1196: 
AssertionError



* qutip (tests.test_piqs.TestDicke.test_lindbladian):
>   self.data = np.array(obj, copy=copy, dtype=data_dtype)
E   TypeError: can't convert complex to float

/usr/lib/python3/dist-packages/scipy/sparse/coo.py:161: TypeError

Bug#983328: scipy 1.6.1 breaks sparse (COO) matrix construction

[Drew Parsons]

qutip upstream were quick to acknowledge the scipy 1.6.1 problem in 
qutip Issue #1451 .


Confirmed as a bug in scipy 1.6.1,

https://github.com/scipy/scipy/issues/13585
https://github.com/scipy/scipy/pull/13586

Bug#965088: Re: [Pkg-privacy-maintainers] Bug#965088: Waiting for release 2.3

[syster]

> That said, we might be able to provide a backport, as this has been > 
> requested multiple times. Nodens could check with Tails if they would > want 
> a backport - which would make it more of a priority for us to > maintain a 
> backport. Quoting a reply by intrigeri from tails-dev MUC: 11:41:35 AM] 
> intrigeri: IMO, there's no rush and it's OK for us to delay the upgrade (and 
> dealing with any Tails-specific integration work) until we upgrade to 
> Bullseye. [11:42:15 AM] intrigeri: If we had any other need/requirement on 
> this front, we would have let nodens know  [11:42:46 AM] intrigeri: Thanks 
> for caring!

Bug#983326: rich: test failures with TERM=unknown

[Sandro Tosi]

On Mon, 22 Feb 2021 13:27:20 +0100 Gianfranco Costamagna
 wrote:
> Source: rich
> Version: 9.11.0-1
> Severity: important
>
> Hello, looks like the testsuite is failing with TERM=unknown, I don't really 
> know why, but calling dh_auto_test with TERM=linux seems to fix it.

please follow up at
https://github.com/willmcgugan/rich/issues/1051#issuecomment-784097262
or reply to upstream questions here and i can echo them back on gh:

```
Rich will remove all ANSI control codes with TERM=unknown. The tests
aren't accounting for that, but AFAICT Rich is working as designed.

For the sake of reproducible tests, I could control the environment variables.

What was the reason for setting TERM=unknown ? Where you testing Rich
with the env var, or influencing the output of the test runner itself?
```

Bug#983401: zfs-zed: Update of zfs-zed from buster-backports fails.

[Andreas Christ]

Package: zfs-zed
Version: 2.0.2-1~bpo10+1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I tried to upgrade the package zfs-zed to the new version in buster-backports.

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

apt-get dist-upgrade
   * What was the outcome of this action?

Setting up zfs-zed (2.0.2-1~bpo10+1) ...
Installing new version of config file /etc/init.d/zfs-zed ...
Installing new version of config file /etc/zfs/zed.d/zed-functions.sh ...
Installing new version of config file /etc/zfs/zed.d/zed.rc ...
ln: failed to create symbolic link '/etc/zfs/zed.d/history_event-zfs-list-
cacher.sh': File exists
dpkg: error processing package zfs-zed (--configure):
 installed zfs-zed package post-installation script subprocess returned error
exit status 1
Processing triggers for systemd (241-7~deb10u6) ...
Errors were encountered while processing:
 zfs-zed
E: Sub-process /usr/bin/dpkg returned an error code (1)


   * What outcome did you expect instead?

I expected the upgrade to terminate without errors.

I deleted the symlink to /etc/zfs/zed.d/history_event-zfs-list-cacher.sh. Then
the package upgraded without errors. Please see also
http://forums.debian.net/viewtopic.php?f=5=148979

Best regards,

Andreas





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

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

Versions of packages zfs-zed depends on:
ii  init-system-helpers 1.56+nmu1
ii  libc6   2.28-10
ii  libnvpair3linux 2.0.2-1~bpo10+1
ii  libudev1241-7~deb10u6
ii  libuuid12.33.1-0.1
ii  libuutil3linux  2.0.2-1~bpo10+1
ii  libzfs4linux2.0.2-1~bpo10+1
ii  zfs-dkms [zfs-modules]  2.0.2-1~bpo10+1
ii  zfsutils-linux  2.0.2-1~bpo10+1

zfs-zed recommends no packages.

zfs-zed suggests no packages.

-- no debconf information

Bug#983400: mark golang-golang-x-sync-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-golang-x-sync-dev
Version: 0.0~git20190911.cd5d95a-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:acbuild src:aerc src:alertmanager-irc-relay src:aptly 
src:cadvisor src:cfrpki src:cloudsql-proxy src:consul src:consulfs 
src:containerd src:coyim src:crowdsec src:debiman src:deck src:dh-make-golang 
src:dnscrypt-proxy src:dnss src:docker-registry src:docker.io src:etcd 
src:flannel src:fzf src:gdu src:git-lfs src:gitaly src:gitbatch 
src:gitlab-ci-multi-runner src:gitlab-workhorse src:go-dep src:go-exploitdb 
src:gocryptfs src:goiardi src:golang-github-anacrolix-dms 
src:golang-github-anacrolix-missinggo src:golang-github-appc-docker2aci 
src:golang-github-appc-spec src:golang-github-cheekybits-genny 
src:golang-github-cloudflare-cfssl src:golang-github-cloudflare-redoctober 
src:golang-github-containers-buildah src:golang-github-dnstap-golang-dnstap 
src:golang-github-francoispqt-gojay src:golang-github-golang-mock 
src:golang-github-google-wire src:golang-github-hashicorp-serf 
src:golang-github-jouyouyun-hardware src:golang-github-mmcloughlin-avo 
src:golang-github-openshift-imagebuilder src:golang-github-tinylib-msgp 
src:golang-github-ugorji-go-codec src:golang-github-xenolf-lego 
src:golang-github-xordataexchange-crypt src:golang-gogottrpc 
src:golang-golang-x-tools src:golang-v2ray-core src:golint src:gortr src:gost 
src:gotestsum src:govendor src:hugo src:influxdb src:libpod src:micro 
src:mockery src:mongo-tools src:mtail src:nomad src:nomad-driver-lxc 
src:nomad-driver-podman src:notary src:packer src:pebble src:pk4 src:prometheus 
src:prometheus-alertmanager src:prometheus-apache-exporter 
src:prometheus-bind-exporter src:prometheus-blackbox-exporter 
src:prometheus-elasticsearch-exporter src:prometheus-exporter-exporter 
src:prometheus-hacluster-exporter src:prometheus-haproxy-exporter 
src:prometheus-homeplug-exporter src:prometheus-ipmi-exporter 
src:prometheus-libvirt-exporter src:prometheus-mailexporter 
src:prometheus-mongodb-exporter src:prometheus-mqtt-exporter 
src:prometheus-mysqld-exporter src:prometheus-node-exporter 
src:prometheus-postfix-exporter src:prometheus-postgres-exporter 
src:prometheus-process-exporter src:prometheus-pushgateway 
src:prometheus-redis-exporter src:prometheus-smokeping-prober 
src:prometheus-snmp-exporter src:prometheus-sql-exporter 
src:prometheus-tplink-plug-exporter src:rawdns src:rclone src:restic src:rkt 
src:shadowsocks-v2ray-plugin src:singularity-container src:skopeo src:syncthing 
src:termshark src:victoriametrics src:vip-manager src:vuls

The affected packages cannot satisfy their cross Build-Depends, because
their transitive dependency on golang-golang-x-sync-dev is not
satisfiable. In general, Architecture: all packages can never satisfy
cross Build-Depends unless marked Multi-Arch: foreign or annotated
:native. In this case, the foreign marking is reasonable, because
golang-golang-x-sync-dev is a pure go library entirely lacking
maintainer scripts and dependencies. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru 
golang-golang-x-sync-0.0~git20190911.cd5d95a/debian/changelog 
golang-golang-x-sync-0.0~git20190911.cd5d95a/debian/changelog
--- golang-golang-x-sync-0.0~git20190911.cd5d95a/debian/changelog   
2020-02-21 14:34:42.0 +0100
+++ golang-golang-x-sync-0.0~git20190911.cd5d95a/debian/changelog   
2021-02-23 16:56:50.0 +0100
@@ -1,3 +1,10 @@
+golang-golang-x-sync (0.0~git20190911.cd5d95a-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-golang-x-sync-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 23 Feb 2021 16:56:50 +0100
+
 golang-golang-x-sync (0.0~git20190911.cd5d95a-1) unstable; urgency=medium
 
   * New upstream version 0.0~git20190911.cd5d95a
diff --minimal -Nru golang-golang-x-sync-0.0~git20190911.cd5d95a/debian/control 
golang-golang-x-sync-0.0~git20190911.cd5d95a/debian/control
--- golang-golang-x-sync-0.0~git20190911.cd5d95a/debian/control 2020-02-21 
14:34:29.0 +0100
+++ golang-golang-x-sync-0.0~git20190911.cd5d95a/debian/control 2021-02-23 
16:56:48.0 +0100
@@ -16,6 +16,7 @@
 XS-Go-Import-Path: golang.org/x/sync
 
 Package: golang-golang-x-sync-dev
+Multi-Arch: foreign
 Architecture: all
 Depends: ${shlibs:Depends},
  ${misc:Depends}