Bug#1034369: C++ help needed (Was: Bug#1034369: libcereal: autopkgtest regression on non x86: cc1plus: all warnings being treated as errors)

[Andreas Tille]

Control: tags -1 help

Hi,

I guess the fix will boil down to a type casting in this line

  
https://salsa.debian.org/med-team/libcereal/-/blob/master/unittests/map.hpp#L65

 o_esplmap.insert({random_value(gen),  { random_value(gen), 
random_value(gen) }});

unfortunately my C++ knowledge is too limited to know whether it is
really that simple nor how exactly this line needs to be fixed.  The fix
should be tested at least on arm64 (since the test passes on amd64).

Any help would be welcome
Andreas.

Am Thu, Apr 13, 2023 at 08:00:27PM +0200 schrieb Paul Gevers:
> 
> https://ci.debian.net/data/autopkgtest/testing/arm64/libc/libcereal/32116422/log.gz
> 
> [ 25%] Building CXX object unittests/CMakeFiles/test_map.dir/map.cpp.o
> In file included from
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:28:
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: In 
> instantiation of ‘void test_map() [with IArchive = 
> cereal::BinaryInputArchive; OArchive = cereal::BinaryOutputArchive]’:
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:34:68:
>  required from here
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43:
>  error: narrowing conversion of ‘random_value(gen)’ from 
> ‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
> [-Werror=narrowing]
>65 |   o_esplmap.insert({random_value(gen),  { 
> random_value(gen), random_value(gen) }});
>   | ~~^
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: In 
> instantiation of ‘void test_map() [with IArchive = 
> cereal::PortableBinaryInputArchive; OArchive = 
> cereal::PortableBinaryOutputArchive]’:
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:39:84:
>  required from here
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43:
>  error: narrowing conversion of ‘random_value(gen)’ from 
> ‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
> [-Werror=narrowing]
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: In 
> instantiation of ‘void test_map() [with IArchive = cereal::XMLInputArchive; 
> OArchive = cereal::XMLOutputArchive]’:
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:44:62:
>  required from here
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43:
>  error: narrowing conversion of ‘random_value(gen)’ from 
> ‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
> [-Werror=narrowing]
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: In 
> instantiation of ‘void test_map() [with IArchive = cereal::JSONInputArchive;
> OArchive = cereal::JSONOutputArchive]’:
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:49:64:
>  required from here
> /tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43:
>  error: narrowing conversion of ‘random_value(gen)’ from 
> ‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
> [-Werror=narrowing]
> cc1plus: all warnings being treated as errors
> make[2]: *** [unittests/CMakeFiles/test_map.dir/build.make:76:
> unittests/CMakeFiles/test_map.dir/map.cpp.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:556:
> unittests/CMakeFiles/test_map.dir/all] Error 2
> make: *** [Makefile:146: all] Error 2




> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Processed: C++ help needed (Was: Bug#1034369: libcereal: autopkgtest regression on non x86: cc1plus: all warnings being treated as errors)

[Debian Bug Tracking System]

Processing control commands:

> tags -1 help
Bug #1034369 [src:libcereal] libcereal: autopkgtest regression on non x86: 
cc1plus: all warnings being treated as errors
Added tag(s) help.

-- 
1034369: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034369
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034349: bedtools: autopkgtest fails on bookworm kernel: ulimit: error setting limit (Operation not permitted)

[Andreas Tille]

Hi Paul,

Am Thu, Apr 13, 2023 at 10:28:13PM +0200 schrieb Paul Gevers:
> Thanks for the quick fix. There is good news. Thanks to discussions on IRC
> we found a change to the lxc configuration that will enable us to circumvent
> the issue. Which means that you can drop the workaround in a future upload.

Does this mean you want me to revert the change?  IMHO the package is
perfectly fine without the ulimit call and reverting the change just
creates more noise than needed.  So I would prefer to keep the package
as is.

Thanks a lot for all your hard work on the release

 Andreas.

-- 
http://fam-tille.de

Bug#1034389: installation-reports: bookworm cannot install base system

[Steve Witt]

Package: installation-reports
Severity: grave
Tags: d-i
Justification: renders package unusable

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: debian-bookworm-DI-rc1-amd64-DVD-1.iso
Date: 

Machine: Lenovo Thinkpad P16
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [0]
Detect network card:[0]
Configure network:  [0]
Detect media:   [0]
Load installer modules: [0]
Clock/timezone setup:   [0]
User/password setup:[0]
Detect hard drives: [0]
Partition hard drives:  [0]
Install base system:[E]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:



Tried installing in both expert mode, and normal mode. After
partitioning the disks went to the 'Install the base system' step. It
failed with the text: Cannot install base system. The installer cannot
figure out how to install the base system. If found no installable
image, and no valid mirror was configured.


Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - RC 1 installer"
X_INSTALLATION_MEDIUM=DVD image on USB thumb drive

==
Installer hardware-summary:
==
uname -a: Linux wren 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-1 
(2023-09-19) x86_64 GNU/Linux

Processed: tagging 1021330, tagging 1034215, tagging 1034232, tagging 1034210

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 1021330 - moreinfo
Bug #1021330 {Done: Andreas Beckmann } [nvidia-cuda-dev] 
nvidia-cuda-dev appears to break nvidia xorg
Removed tag(s) moreinfo.
> tags 1034215 + experimental
Bug #1034215 [drkonqi] drkonqi: dh_installsystemd doesn't handle files in 
/usr/lib/systemd/system
Added tag(s) experimental.
> tags 1034232 + experimental
Bug #1034232 [nvme-cli] nvme-cli: dh_installsystemd doesn't handle files in 
/usr/lib/systemd/system
Added tag(s) experimental.
> tags 1034210 + experimental
Bug #1034210 [python3-charon] python3-charon: dh_installsystemd doesn't handle 
files in /usr/lib/systemd/system
Added tag(s) experimental.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1021330: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021330
1034210: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034210
1034215: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034215
1034232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034232
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034349: bedtools: autopkgtest fails on bookworm kernel: ulimit: error setting limit (Operation not permitted)

[Paul Gevers]

Hi Andreas (and others)

On Thu, 13 Apr 2023 12:42:04 +0200 Paul Gevers  wrote:
Your package has an autopkgtest, great. However, it fails when the host 
is running a bookworm kernel. I have upgrade several of the 
ci.debian.net hosts (arm64, i386, ppc64el and s390x) to bookworm and 
that's where the failure happens. I confirm that running the test on 
amd64 with a bookworm kernel fails in the same way. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


Thanks for the quick fix. There is good news. Thanks to discussions on 
IRC we found a change to the lxc configuration that will enable us to 
circumvent the issue. Which means that you can drop the workaround in a 
future upload. Sorry for the noise.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034310: Upstream issue

[Marco Mattiolo]

Hi Rainer,

I'm not Digikam's maintainer, then maybe not the help you were looking for.

But I noticed your bug report looks same as an issue reported upstream 
[1] on a different platform: if those issues are really the same, then 
it's not Debian-specific bug. I would suggest following developer's 
indication in the linked bug report, both trying a newer version and 
collecting backtrace.


In the end, all of that will be useful for developers to find out what 
is going wrong and for Debian maintainers to cherry-pick a fix into 
stable release.


Kind regards

Marco

[1] https://bugs.kde.org/show_bug.cgi?id=466170

Processed: severity of 1031370 is grave

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 1031370 grave
Bug #1031370 [src:python-werkzeug] python-werkzeug: CVE-2023-23934 
CVE-2023-25577
Severity set to 'grave' from 'important'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1031370: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031370
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: found 1034042 in 2.15.0+ds1-2

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 1034042 2.15.0+ds1-2
Bug #1034042 [src:openvswitch] openvswitch: CVE-2023-1668: Remote traffic 
denial of service via crafted packets with IP proto 0
Marked as found in versions openvswitch/2.15.0+ds1-2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1034042: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034042
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: libcereal: autopkgtest regression on non x86: cc1plus: all warnings being treated as errors

[Debian Bug Tracking System]

Processing control commands:

> tags -1 bookworm-ignore
Bug #1034369 [src:libcereal] libcereal: autopkgtest regression on non x86: 
cc1plus: all warnings being treated as errors
Added tag(s) bookworm-ignore.

-- 
1034369: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034369
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034369: libcereal: autopkgtest regression on non x86: cc1plus: all warnings being treated as errors

[Paul Gevers]

Source: libcereal
Version: 1.3.2+dfsg-4
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on all 
architectures except amd64 and i386 since August 2022. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report. (src:gcc-defaults switching to gcc-12 migrated on 
2022-08-10 to testing)


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/libc/libcereal/32116422/log.gz

[ 25%] Building CXX object unittests/CMakeFiles/test_map.dir/map.cpp.o
In file included from 
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:28:
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: 
In instantiation of ‘void test_map() [with IArchive = 
cereal::BinaryInputArchive; OArchive = cereal::BinaryOutputArchive]’:
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:34:68: 
  required from here
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43: 
error: narrowing conversion of ‘random_value(gen)’ from 
‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
[-Werror=narrowing]
   65 |   o_esplmap.insert({random_value(gen),  { 
random_value(gen), random_value(gen) }});

  | ~~^
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: 
In instantiation of ‘void test_map() [with IArchive = 
cereal::PortableBinaryInputArchive; OArchive = 
cereal::PortableBinaryOutputArchive]’:
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:39:84: 
  required from here
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43: 
error: narrowing conversion of ‘random_value(gen)’ from 
‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
[-Werror=narrowing]
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: 
In instantiation of ‘void test_map() [with IArchive = 
cereal::XMLInputArchive; OArchive = cereal::XMLOutputArchive]’:
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:44:62: 
  required from here
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43: 
error: narrowing conversion of ‘random_value(gen)’ from 
‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
[-Werror=narrowing]
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp: 
In instantiation of ‘void test_map() [with IArchive = 
cereal::JSONInputArchive; OArchive = cereal::JSONOutputArchive]’:
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.cpp:49:64: 
  required from here
/tmp/autopkgtest-lxc.nn60praz/downtmp/autopkgtest_tmp/unittests/map.hpp:65:43: 
error: narrowing conversion of ‘random_value(gen)’ from 
‘std::enable_if::type’ {aka ‘char’} to ‘signed char’ 
[-Werror=narrowing]

cc1plus: all warnings being treated as errors
make[2]: *** [unittests/CMakeFiles/test_map.dir/build.make:76: 
unittests/CMakeFiles/test_map.dir/map.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:556: 
unittests/CMakeFiles/test_map.dir/all] Error 2

make: *** [Makefile:146: all] Error 2


OpenPGP_signature
Description: OpenPGP digital signature

Processed: tagging 1034212

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 1034212 + pending
Bug #1034212 [amazon-ec2-net-utils] amazon-ec2-net-utils: dh_installsystemd 
doesn't handle files in /usr/lib/systemd/system
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1034212: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034212
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Paul Gevers]

Hi,

On 13-04-2023 18:17, Shengjing Zhu wrote:

Maybe you haven't rebuilt the lxc image with the new timezone, so it
still uses UTC+8.


That's what I thought so later too. Let's see what tomorrow brings.


Anyway, I've staged the change in git
https://salsa.debian.org/go-team/packages/golang-github-azure-go-autorest/-/commit/73b09d0

Great.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034350: gnutls28: autopkgtest regression everywhere except amd64: src/nonexist-builddir/gnutls_ktls: not found

[Andreas Metzler]

On 2023-04-13 Paul Gevers  wrote:
> Source: gnutls28
> Version: 3.7.9-1
> Severity: serious
> Control: tags -1 bookworm-ignore
> User: debian...@lists.debian.org
> Usertags: regression

> Dear maintainer(s),

> Your package has an autopkgtest, great. However, it fails everywhere but on
> amd64. If I understand correctly, the 32 bits architecture failures are due
> to datefudge/faketime (bug 1031553) and started in September 2022. The 64
> bits architectures started to fail more recently in March 2023. Because some
> hosts on ci.debian.net have been upgraded to bookworm recently, I was
> fearing/suspecting it might be kernel related, but running the test on an
> amd64/bookworm kernel passes. Can you please investigate the situation and
> fix it?
[...]

Thank you. Looks like this did not fail on amd64 since thes machines do
not have the tls module loaded while arm64 has.

The test should be properly blacklisted instead since a) gnutls is built
without ktls support and b) because it is not a pure shell test using
gnutls-bin. Should be trivial to fix, will do.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1034226: marked as done (cloudflare-ddns: dh_installsystemd doesn't handle files in /usr/lib/systemd/system)

[Debian Bug Tracking System]

Your message dated Thu, 13 Apr 2023 16:48:55 +
with message-id 
and subject line Bug#1034226: fixed in cloudflare-ddns 2.0.0-4
has caused the Debian Bug report #1034226,
regarding cloudflare-ddns: dh_installsystemd doesn't handle files in 
/usr/lib/systemd/system
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1034226: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034226
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: cloudflare-ddns
Version: 2.0.0-3   
Severity: serious
Tags: sid bookworm
User: debhel...@packages.debian.org
Usertags: systemd-files-in-usr-bookworm

Dear Maintainer,

It seems that your package cloudflare-ddns is shipping files (.service, .socket 
or
.timer) in /usr/lib/systemd/system.

This is not supported by the version of dh_installsystemd/debhelper currently
in unstable and bookworm (See: #1031695). That means that currently your
service might not be enabled at boot and/or started as expected.

With the freeze currently in effect, debhelper will not be fixed for bookworm.

As a result, could you please move these files to /lib/systemd/system instead
so they are properly detected by debhelper?
As soon as debhelper is supporting (not until bookworm+1 aka Trixie) you will
be able to move them back to the newer location.

Note that bookworm is currently in hard freeze, please limit the changes you
are uploading to the ones fixing RC bugs.  Also note that you might have to
request a freeze exception to the release team.
See: https://release.debian.org/testing/freeze_policy.html

Feel free to contact me if you have any questions.

Kind regards,
Laurent Bigonville

The list of packages has been generated with the following command:
apt-file search -x '^/usr/lib/systemd/system/.*\.(service|timer|socket)$'|cut 
-d: -f1|sort -u
--- End Message ---
--- Begin Message ---
Source: cloudflare-ddns
Source-Version: 2.0.0-4
Done: Andrea Pappacoda 

We believe that the bug you reported is fixed in the latest version of
cloudflare-ddns, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1034...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andrea Pappacoda  (supplier of updated cloudflare-ddns 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 13 Apr 2023 15:29:29 +0200
Source: cloudflare-ddns
Architecture: source
Version: 2.0.0-4
Distribution: unstable
Urgency: medium
Maintainer: Andrea Pappacoda 
Changed-By: Andrea Pappacoda 
Closes: 1034226
Changes:
 cloudflare-ddns (2.0.0-4) unstable; urgency=medium
 .
   * d/patches: use systemd.pc to get systemd paths.
 Using systemd.pc to get systemd unit and sysusers.d paths avoids having
 to hardcode paths, which leads to issues when files have to be installed
 outside of /usr, like with unit files in bookworm.
 Thanks to Andreas Henriksson for the patch! (Closes: #1034226)
Checksums-Sha1:
 ec9f2432376cf9aea1cd406d8f199020fd35775b 1745 cloudflare-ddns_2.0.0-4.dsc
 d684c43bc11bc9349ae40271192fa6a1f041b232 14416 
cloudflare-ddns_2.0.0-4.debian.tar.xz
 5104b4086c6a8219a163fe3d0e103a976bcbf785 9159 
cloudflare-ddns_2.0.0-4_amd64.buildinfo
Checksums-Sha256:
 01b52c20c7eaae3340732e52e6332fb878e9f47b86e0aeca1b7db88b6a388e32 1745 
cloudflare-ddns_2.0.0-4.dsc
 723ea9ea6bfce6909b2b7e02792d3cb30ff72ed45ea83bd1dce64e39eeb81e33 14416 
cloudflare-ddns_2.0.0-4.debian.tar.xz
 abc054bc5760079fe9984e5608e0555dd8f5b0f279d2f53710f1ddc0f768b31b 9159 
cloudflare-ddns_2.0.0-4_amd64.buildinfo
Files:
 436547045cf61fd5f65a518600dae933 1745 admin optional 
cloudflare-ddns_2.0.0-4.dsc
 304f41306492693d2dad7423ebd6f445 14416 admin optional 
cloudflare-ddns_2.0.0-4.debian.tar.xz
 1c0c13c57d2531af04b490bcb3e4491b 9159 admin optional 
cloudflare-ddns_2.0.0-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZDguTwAKCRBKkgiiRVB3
p+3eAP9/Zj5bCXpYkAk5ERMRjxDQTpvzCvSvs0XO5HoBqo/4PAD+L6e/uJ/Zhhxo
fD2c6U9lgbB4XFvTPbS4pxoYbbagawM=
=fhmN
-END PGP SIGNATURE End Message ---

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Shengjing Zhu]

On Thu, Apr 13, 2023 at 10:15 PM Paul Gevers  wrote:
>
> Hi,
>
> On 13-04-2023 15:39, Paul Gevers wrote:
> >> Looks like it was caused by the UTC+8 timezone in the testbed.
> >>
> >> I agree it's nice to have the tests not depending on the system
> >> timezone. But do we really want to bother with that? Could you just
> >> ensure all testbeds have the same timezone?
> >
> > In my opinion we should do both. You don't want people to go figure this
> > out if they try to run the tests themselves in their own timezone. Also,
> > we are only in control of the hosts that Debian uses. Any downstream may
> > run into the same problems.
>
> I have changed the timezone on all our hosts, but your test still fails.
>
> https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-azure-go-autorest/32859920/log.gz
> is the test I just scheduled. It failed in the same way.

Maybe you haven't rebuilt the lxc image with the new timezone, so it
still uses UTC+8.

Anyway, I've staged the change in git
https://salsa.debian.org/go-team/packages/golang-github-azure-go-autorest/-/commit/73b09d0


--
Shengjing Zhu

Processed: haveged: autopkgtest fails on bookworm kernel: service fails to start

[Debian Bug Tracking System]

Processing control commands:

> tags -1 bookworm-ignore
Bug #1034361 [src:haveged] haveged: autopkgtest fails on bookworm kernel: 
service fails to start
Added tag(s) bookworm-ignore.

-- 
1034361: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034361
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034361: haveged: autopkgtest fails on bookworm kernel: service fails to start

[Paul Gevers]

Source: haveged
Version: 1.9.14-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails when the host 
is running a bookworm kernel. I have upgrade several of the 
ci.debian.net hosts (arm64, i386, ppc64el and s390x) to bookworm and 
that's where the failure happens. I confirm that running the test on 
amd64 with a bookworm kernel fails in the same way. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore, however, I have a strong suspicion that it points 
out that the package is broken. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/h/haveged/32696042/log.gz

autopkgtest [01:12:21]: test check-service: [---
failed
haveged service is not active
× haveged.service - Entropy Daemon based on the HAVEGE algorithm
 Loaded: loaded (/lib/systemd/system/haveged.service; enabled; 
preset: enabled)
 Active: failed (Result: exit-code) since Fri 2023-04-07 01:12:20 
CST; 1s ago

   Duration: 1ms
   Docs: man:haveged(8)
 http://www.issihosts.com/haveged/
Process: 1104 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
$DAEMON_ARGS (code=exited, status=225/NETWORK)

   Main PID: 1104 (code=exited, status=225/NETWORK)
CPU: 1ms
autopkgtest [01:12:21]: test check-service: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Paul Gevers]

Hi,

On 13-04-2023 15:39, Paul Gevers wrote:

Looks like it was caused by the UTC+8 timezone in the testbed.

I agree it's nice to have the tests not depending on the system
timezone. But do we really want to bother with that? Could you just
ensure all testbeds have the same timezone?


In my opinion we should do both. You don't want people to go figure this 
out if they try to run the tests themselves in their own timezone. Also, 
we are only in control of the hosts that Debian uses. Any downstream may 
run into the same problems.


I have changed the timezone on all our hosts, but your test still fails.

https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-azure-go-autorest/32859920/log.gz 
is the test I just scheduled. It failed in the same way.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034358: libvncclient1: license conflict with libsasl2

[Bastian Germann]

Package: libvncclient1
Version: 0.9.14+dfsg-1
Severity: serious

Hi,

libvncclient1 depends on libsasl2-2, which is licensed under CMU's BSD-3-Clause-Attribution license and covered by the 
RSA-MD license. They have clauses in place, which are known to be incompatible with GPL (libvncclient1's license).

There are several possible solutions to this problem:

1) Build without SASL support. The affected symbols GetTLSCipherBits, HandleSASLAuth, and ReadFromSASL are not used by 
any of the reverse dependencies.


2) Support my request at #996892.

3) Ask upstream to add a license exception for libsasl2-2, similar to the one 
that was required by Debian for OpenSSL
for a long time.

Thanks for your consideration,
Bastian

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Paul Gevers]

Hi Shengjing,

On 13-04-2023 14:56, Shengjing Zhu wrote:

On Thu, Apr 13, 2023 at 8:12 PM Paul Gevers  wrote:


=== RUN   TestLogReqRespNoBody
  logger_test.go:90: request header doesn't match:
(2023-04-12T19:18:59.1355402+08:00) INFO: REQUEST: GET
https://fakething/dot/com
--- FAIL: TestLogReqRespNoBody (0.01s)
=== RUN   TestLogReqRespWithBody
  logger_test.go:155: request header doesn't match:
(2023-04-12T19:18:59.1420497+08:00) INFO: REQUEST: GET
https://fakething/dot/com
--- FAIL: TestLogReqRespWithBody (0.01s)
FAIL
FAILgithub.com/Azure/go-autorest/logger 0.017s


Looks like it was caused by the UTC+8 timezone in the testbed.

I agree it's nice to have the tests not depending on the system
timezone. But do we really want to bother with that? Could you just
ensure all testbeds have the same timezone?


In my opinion we should do both. You don't want people to go figure this 
out if they try to run the tests themselves in their own timezone. Also, 
we are only in control of the hosts that Debian uses. Any downstream may 
run into the same problems.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Processed: Bug#1034226 marked as pending in cloudflare-ddns

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #1034226 [cloudflare-ddns] cloudflare-ddns: dh_installsystemd doesn't 
handle files in /usr/lib/systemd/system
Added tag(s) pending.

-- 
1034226: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034226
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034226: marked as pending in cloudflare-ddns

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1034226 in cloudflare-ddns reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/tachi/cloudflare-ddns/-/commit/f82000e4cc2f6b71c504935862371ba5b6cdc0a7


d/patches: use systemd.pc to get systemd paths

Using systemd.pc to get systemd unit and sysusers.d paths avoids having
to hardcode paths, which leads to issues when files have to be installed
outside of /usr, like with unit files in bookworm.

Closes: #1034226
Thanks: Andreas Henriksson for the patch!


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1034226

Bug#1034349: marked as done (bedtools: autopkgtest fails on bookworm kernel: ulimit: error setting limit (Operation not permitted))

[Debian Bug Tracking System]

Your message dated Thu, 13 Apr 2023 13:19:05 +
with message-id 
and subject line Bug#1034349: fixed in bedtools 2.30.0+dfsg-3
has caused the Debian Bug report #1034349,
regarding bedtools: autopkgtest fails on bookworm kernel: ulimit: error setting 
limit (Operation not permitted)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1034349: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034349
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Source: bedtools
Version: 2.30.0+dfsg-2
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails when the host 
is running a bookworm kernel. I have upgrade several of the 
ci.debian.net hosts (arm64, i386, ppc64el and s390x) to bookworm and 
that's where the failure happens. I confirm that running the test on 
amd64 with a bookworm kernel fails in the same way. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/b/bedtools/32856831/log.gz

autopkgtest [18:36:06]: test run-unit-test: [---
test.sh: 4: ulimit: error setting limit (Operation not permitted)
autopkgtest [18:36:07]: test run-unit-test: ---]


OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: bedtools
Source-Version: 2.30.0+dfsg-3
Done: Andreas Tille 

We believe that the bug you reported is fixed in the latest version of
bedtools, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1034...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Tille  (supplier of updated bedtools package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 13 Apr 2023 14:12:15 +0200
Source: bedtools
Architecture: source
Version: 2.30.0+dfsg-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 

Changed-By: Andreas Tille 
Closes: 1034349
Changes:
 bedtools (2.30.0+dfsg-3) unstable; urgency=medium
 .
   * Do not use ulimit in test
 Closes: #1034349
   * Override false positive (see lintian bug #1017966)
Checksums-Sha1:
 5a7ea2463f20f8c2a872fb63bd365166cb762c86  bedtools_2.30.0+dfsg-3.dsc
 c8adce284cb001babdcb16d3653ede79e9481852 13576 
bedtools_2.30.0+dfsg-3.debian.tar.xz
 b65851d0b67ffad47675fe792256979985531877 7192 
bedtools_2.30.0+dfsg-3_amd64.buildinfo
Checksums-Sha256:
 36627642d6cb5f25cf0f37a4ffd314fdf82a4c41dbe7363c6b7c13fe025d731c  
bedtools_2.30.0+dfsg-3.dsc
 3817f07ab60db5687c8d4132ddf15a5379eb7290c8a99edd40e496b4459dbd51 13576 
bedtools_2.30.0+dfsg-3.debian.tar.xz
 9f164b45e5a01c66be409b4b2e59f8f8fdb5a92438589099589b009427ad7b8f 7192 
bedtools_2.30.0+dfsg-3_amd64.buildinfo
Files:
 82c9ee909f775cf4778ba54ef1fed28c  science optional 
bedtools_2.30.0+dfsg-3.dsc
 fad2decc8304bbb04216740c4887c796 13576 science optional 
bedtools_2.30.0+dfsg-3.debian.tar.xz
 d680efda6168f03acb90e1cf3fda3425 7192 science optional 
bedtools_2.30.0+dfsg-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmQ3/qQRHHRpbGxlQGRl
Ymlhbi5vcmcACgkQV4oElNHGRtGP8w//Yzr1e/MyZWdql8YZK1pH1013jzS8wPm1
gkmru4LrfBuL+rUDr9ZBcn+GKnoQBRyH14+OVNk1PfG3eHBb1ZYL+IhUTnd58ywa
g+i+Z9IB/3/Oo0/cLajRkVMLa+UwwO4BJ3pnPxOxUpdWt/Tc/wWOJ9SzF2AiakEM
2bLtTtJiHtOH5TC+ZlajhVWSQssTQEqxdUjckXqcgnznSYzDL462BjNCcL+Rxuzb
OEF6/Yhu4qguA1XsylcPBT9hPDdo8cZ+GO2nGxgBc8RuLESzpmK/iA+G9NernXiX
3aCD0bcJIyXTyFGhma1CCUYgH+AbLFQiu99qWvKV+hb0UaP8EqRpVm7fhe5GnCxn

Bug#1033913: marked as done (partman-auto-lvm: Broken "Guided - use entire disk and set up LVM" in UEFI mode)

[Debian Bug Tracking System]

Your message dated Thu, 13 Apr 2023 13:03:56 +
with message-id 
and subject line Bug#1033913: fixed in partman-efi 99
has caused the Debian Bug report #1033913,
regarding partman-auto-lvm: Broken "Guided - use entire disk and set up LVM" in 
UEFI mode
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1033913: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033913
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: partman-auto-lvm
Version: 87
Severity: serious
Justification: Maintainer says so

TL;DR: Answering “Yes” to the “Force UEFI installation?” makes sure the
installer pulls the right bootloader packages, despite misreading the
situation.

I've discovered this while testing D-I Bookworm RC 1 but also confirmed
it already existed in D-I Bookworm Alpha 2, and I'm therefore filing it
against the version found in the previous release (and deciding not to
block the Bookworm RC 1 release on it).



For baremetal tests on laptops requiring various firmware packages, I've
been using guided partitioning since forever, with one of these:
 - Guided - use entire disk
 - Guided - use entire disk and set up encrypted LVM

The former is used most of the time since it's slightly faster (fewer
prompts), while the latter is only used once in a while, to make sure a
“real” laptop-oriented install works fine (since every laptop should be
encrypted in my opinion).

Since I had just tested “Guided - use entire disk” in a virtual machine,
I decided to pick this instead when switching to the first laptop
(Asus Vivobook S14/S15 but that's very likely not a factor):
 - Guided - use entire disk and set up LVM

And… *WOW!*

The first surprise is this prompt:

Force UEFI installation?

This machine's firmware has started the installer in UEFI mode but
it looks like there may be existing operating systems already
installed using "BIOS compatibility mode". If you continue to
install Debian in UEFI mode, it might be difficult to reboot the
machine into any BIOS-mode operating systems later.

If you wish to install in UEFI mode and don't care about keeping the
ability to boot one of the existing systems, you have the option to
force that here. If you wish to keep the option to boot an existing
operating system, you should choose NOT to force UEFI installation
here.

which defaults to No.

That's very surprising since the only operating system prior to the
installation was a Debian system, which was getting entirely erased (due
to using the full disk), and was installed in UEFI mode anyway.

I went for the default choice, since we expect the installer to make
smart suggestions, and unsuspecting users shouldn't have to know better.

That means we end up with installing grub-pc instead of grub-efi-amd64
and shim, being prompted where to install GRUB, and of course when it's
time to reboot, the UEFI firmware rightfully refuses to boot anything
since there's absolutely no signature whatsoever, which isn't a great
idea under Secure Boot:

Secure Boot Violation

Invalid signature detected. Check Secure Boot Policy in Setup.


Some additional info:
 - As mentioned in TL;DR, this can be worked around by answering Yes to
   “Force UEFI installation?”.
 - It doesn't seem to be dependent on possible traces of an existing
   system prior to the installation: Debian installed on the entire disk
   or with encrypted LVM on the entire disk doesn't seem to make a
   difference. Starting with a wiped disk (writing ~ 2 GB worth of
   zeros at the beginning of the disk) doesn't make a difference either.
 - It very much looks like the intermediary states are slightly
   different when setting up LVM and when setting up encrypted LVM, and
   the LVM case case leads to some confusion in partman-efi's
   /lib/partman/init.d/50efi (which logs to /var/log/partman rather than
   to /var/log/syslog): “Found 0 ESPs, 3 non-ESPs”.
 - I'm filing this issue against partman-auto-lvm though, for
   discoverability purposes.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
--- End Message ---
--- Begin Message ---
Source: partman-efi
Source-Version: 99
Done: Steve McIntyre <93...@debian.org>

We believe that the bug you reported is fixed in the latest version of
partman-efi, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have 

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Shengjing Zhu]

On Thu, Apr 13, 2023 at 8:12 PM Paul Gevers  wrote:
>
> === RUN   TestLogReqRespNoBody
>  logger_test.go:90: request header doesn't match:
> (2023-04-12T19:18:59.1355402+08:00) INFO: REQUEST: GET
> https://fakething/dot/com
> --- FAIL: TestLogReqRespNoBody (0.01s)
> === RUN   TestLogReqRespWithBody
>  logger_test.go:155: request header doesn't match:
> (2023-04-12T19:18:59.1420497+08:00) INFO: REQUEST: GET
> https://fakething/dot/com
> --- FAIL: TestLogReqRespWithBody (0.01s)
> FAIL
> FAILgithub.com/Azure/go-autorest/logger 0.017s

Looks like it was caused by the UTC+8 timezone in the testbed.

I agree it's nice to have the tests not depending on the system
timezone. But do we really want to bother with that? Could you just
ensure all testbeds have the same timezone?

-- 
Shengjing Zhu

Processed: image-factory: FTBFS in testing: AssertionError: pylint found issues:

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 1033424 patch
Bug #1033424 [src:image-factory] image-factory: FTBFS in testing: 
AssertionError: pylint found issues:
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1033424: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033424
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034352: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Paul Gevers]

Source: golang-github-azure-go-autorest
Version: 14.2.0+git20220726.711dde1-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on arm64 only 
since July 2022. Can you please investigate the situation and fix it? I 
copied some of the output at the bottom of this report. I'd like to note 
that our arm64 workers are all hosted in China, which *might* be of 
relevance as this test seems to be testing against the internet (I could 
be wrong). If it is testing against the internet, it requires the 
needs-internet restriction (although that currently doesn't change 
anything).


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-azure-go-autorest/32818576/log.gz

=== RUN   TestLogReqRespNoBody
logger_test.go:90: request header doesn't match: 
(2023-04-12T19:18:59.1355402+08:00) INFO: REQUEST: GET 
https://fakething/dot/com

--- FAIL: TestLogReqRespNoBody (0.01s)
=== RUN   TestLogReqRespWithBody
logger_test.go:155: request header doesn't match: 
(2023-04-12T19:18:59.1420497+08:00) INFO: REQUEST: GET 
https://fakething/dot/com

--- FAIL: TestLogReqRespWithBody (0.01s)
FAIL
FAILgithub.com/Azure/go-autorest/logger 0.017s


OpenPGP_signature
Description: OpenPGP digital signature

Processed: golang-github-azure-go-autorest: autopkgtest regression on arm64: request header doesn't match

[Debian Bug Tracking System]

Processing control commands:

> tags -1 bookworm-ignore
Bug #1034352 [src:golang-github-azure-go-autorest] 
golang-github-azure-go-autorest: autopkgtest regression on arm64: request 
header doesn't match
Added tag(s) bookworm-ignore.

-- 
1034352: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034352
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: gnutls28: autopkgtest regression everywhere except amd64: src/nonexist-builddir/gnutls_ktls: not found

[Debian Bug Tracking System]

Processing control commands:

> tags -1 bookworm-ignore
Bug #1034350 [src:gnutls28] gnutls28: autopkgtest regression everywhere except 
amd64: src/nonexist-builddir/gnutls_ktls: not found
Added tag(s) bookworm-ignore.

-- 
1034350: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034350
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034350: gnutls28: autopkgtest regression everywhere except amd64: src/nonexist-builddir/gnutls_ktls: not found

[Paul Gevers]

Source: gnutls28
Version: 3.7.9-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails everywhere but 
on amd64. If I understand correctly, the 32 bits architecture failures 
are due to datefudge/faketime (bug 1031553) and started in September 
2022. The 64 bits architectures started to fail more recently in March 
2023. Because some hosts on ci.debian.net have been upgraded to bookworm 
recently, I was fearing/suspecting it might be kernel related, but 
running the test on an amd64/bookworm kernel passes. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/g/gnutls28/32726537/log.gz

https://ci.debian.net/data/autopkgtest/testing/arm64/g/gnutls28/32726537/log.gz

running [83]../../tests/ktls.sh ...
/proc/modules:tls 114688 0 - Live 0x
../../tests/ktls.sh: 40: 
/tmp/autopkgtest-lxc.p44qznnk/downtmp/build.Wzp/src/nonexist-builddir/gnutls_ktls: 
not found

FAIL [83]../../tests/ktls.sh


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034349: bedtools: autopkgtest fails on bookworm kernel: ulimit: error setting limit (Operation not permitted)

[Paul Gevers]

Source: bedtools
Version: 2.30.0+dfsg-2
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails when the host 
is running a bookworm kernel. I have upgrade several of the 
ci.debian.net hosts (arm64, i386, ppc64el and s390x) to bookworm and 
that's where the failure happens. I confirm that running the test on 
amd64 with a bookworm kernel fails in the same way. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/b/bedtools/32856831/log.gz

autopkgtest [18:36:06]: test run-unit-test: [---
test.sh: 4: ulimit: error setting limit (Operation not permitted)
autopkgtest [18:36:07]: test run-unit-test: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Processed: bedtools: autopkgtest fails on bookworm kernel: ulimit: error setting limit (Operation not permitted)

[Debian Bug Tracking System]

Processing control commands:

> tags -1 bookworm-ignore
Bug #1034349 [src:bedtools] bedtools: autopkgtest fails on bookworm kernel: 
ulimit: error setting limit (Operation not permitted)
Added tag(s) bookworm-ignore.

-- 
1034349: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034349
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount

[Debian Bug Tracking System]

Processing control commands:

> severity -1 normal
Bug #1034346 [usrmerge] usrmerge: fails to install on Xen VPS due to 
/lib/modules mount
Severity set to 'normal' from 'serious'

-- 
1034346: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034346
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount

[Marco d'Itri]

Control: severity -1 normal

On Apr 13, Hans-Christoph Steiner  wrote:

> I have some VPSes which are based on Xen, so the kernel comes from the host,
> and the VPS has no kernel installed.  /lib/modules is mounted but not via
> /etc/fstab.  When trying to upgrade from bullseye to bookworm, I get:
Then fix it as suggested, but not via fstab?
Looks like this is a documentation issue.
What do you think should be changed here, exactly?

> To continue the conversion please:
> - replace '/lib/modules/' with '/usr/lib/modules/' in /etc/fstab
> - reboot
> - try again

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1034348: at: autopkgtest regression on arm64: Either at.20377 doesn't exist or the content differs.

[Paul Gevers]

Source: at
Version: 3.2.5-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on 
arm(64|el|hf) since September 2022 (and slightly longer on s390x). Can 
you please investigate the situation and fix it? I copied some of the 
output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/a/at/32696040/log.gz

autopkgtest [01:12:17]: test basic-usage: [---
+ TMPFILE=at.20377
++ mktemp -d
+ WORKDIR=/tmp/tmp.7IsxZpWEJn
+ trap 'rm -rf /tmp/tmp.7IsxZpWEJn' 0 INT QUIT ABRT PIPE TERM
++ atq
++ wc -l
+ JOBS_BEFORE=0
+ at now + 1 minute
++ date
warning: commands will be executed using /bin/sh
+ echo 'echo Fri Apr  7 01:12:17 CST 2023 > /tmp/tmp.7IsxZpWEJn/at.20377'
job 1 at Fri Apr  7 01:13:00 2023
+ sleep 2
+ test -f at.20377
+ echo 'OK, at.20377 doesn'\''t exist yet; expected..'
OK, at.20377 doesn't exist yet; expected..
++ atq
++ wc -l
+ JOBS_AFTER=1
+ [[ 1 -eq 1 ]]
+ echo 'OK, 1 new queued job exists..'
+ sleep 58
OK, 1 new queued job exists..
+ grep -Fq UTC /tmp/tmp.7IsxZpWEJn/at.20377
+ echo 'Either at.20377 doesn'\''t exist or the content differs.'
+ exit 1
Either at.20377 doesn't exist or the content differs.
+ rm -rf /tmp/tmp.7IsxZpWEJn
autopkgtest [01:13:18]: test basic-usage: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Processed: at: autopkgtest regression on arm64: Either at.20377 doesn't exist or the content differs.

[Debian Bug Tracking System]

Processing control commands:

> tags -1 bookworm-ignore
Bug #1034348 [src:at] at: autopkgtest regression on arm64: Either at.20377 
doesn't exist or the content differs.
Added tag(s) bookworm-ignore.

-- 
1034348: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034348
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount

[Hans-Christoph Steiner]

Package: usrmerge
Version: 25
Severity: serious

I have some VPSes which are based on Xen, so the kernel comes from the host, and 
the VPS has no kernel installed.  /lib/modules is mounted but not via 
/etc/fstab.  When trying to upgrade from bullseye to bookworm, I get:


Preparing to unpack .../archives/usrmerge_35_all.deb ...
Unpacking usrmerge (35) ...
Setting up usrmerge (35) ...

FATAL ERROR:

/lib/modules/ is a mount point.
Probably this system is using User Mode Linux.

To continue the conversion please:
- replace '/lib/modules/' with '/usr/lib/modules/' in /etc/fstab
- reboot
- try again

E: usrmerge failed.
dpkg: error processing package usrmerge (--configure):
 installed usrmerge package post-installation script subprocess returned error 
exit status 1

Errors were encountered while processing:
 usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)


Here is some more info which should hopefully be helpful:

# umount /lib/modules/
umount: /lib/modules/: target is busy.
# lsof /lib/modules
COMMANDPID USER  FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd-u 1145 root memREG   0,20   1503845 
/lib/modules/5.10.104/modules.symbols.bin
systemd-u 1145 root memREG   0,20   3224788 
/lib/modules/5.10.104/modules.alias.bin
systemd-u 1145 root memREG   0,20   119456   10 
/lib/modules/5.10.104/modules.dep.bin
systemd-u 1145 root memREG   0,20 76634 
/lib/modules/5.10.104/modules.builtin.bin

# ps -ef|grep 1145
root  1145 1  0 09:29 ?00:00:00 /lib/systemd/systemd-udevd
root 16599 25980  0 10:11 pts/100:00:00 grep 1145
# dpkg -l linux*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description
+++-===---===
un  linux-kernel-log-daemon   (no description available)
ii  linux-libc-dev:amd646.1.20-1 amd64Linux support headers for 
userspace development

# mount |grep /lib
modules on /lib/modules type tmpfs (rw,relatime,size=102400k,mode=700)
# cat /etc/fstab

/dev/xvda1  /   xfs defaults0   0
proc/proc   procdefaults0   0
#

Processed: Re: Bug#1034219: debomatic: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 1034219 + patch
Bug #1034219 [debomatic] debomatic: dh_installsystemd doesn't handle files in 
/usr/lib/systemd/system
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1034219: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034219
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034219: debomatic: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Luca Falavigna]

tags 1034219 + patch
thanks


Hi Laurent, hi Andreas,

First of all, thanks for the bug report and for the discussion so far!

Il giorno mer 12 apr 2023 alle ore 10:51 Andreas Henriksson
 ha scritto:
> I'm not sure exactly what the best option is to adress this for pybuild
> using packages, but my guess would be to have some debian/rules hack
> that moves the file (if it's not already located in the same path as
> returned by `pkg-config --variable=systemdsystemunitdir systemd`) after
> dh_install has run probably.

I made a patch adjusting upstream setup.py file to create a symlink of
usr/lb to lib, this is the easiest way to let the buildsystem to
handle with the correct path.

I built the package on debomatic itself where we can see the unit file
is now shipped under /lib/systemd/system:
http://debomatic-amd64.debian.net/distribution#unstable/debomatic/0.26-2/contents

Do you think this will be enough to solve the bug?

-- 
Cheers,
Luca


bug1034219.debdiff
Description: Binary data