Bug#1054028: (no subject)
Hello Thanks for your work. Unfortunately, I've stepped down from rakudo maintenance, and nobody stepped up to replace me. I guess that your patch will be merged once a new maintainer is found for rakudo. All the best
Bug#1069753: libuv1: y2k38 known upstream issue on 32-bits archs
On Wednesday, 24 April 2024 09:48:55 CEST you wrote: > on 32-bits archs, nodejs fails some y2k38 tests. > > It is a well-known issue that has been fixed in libuv master branch, > https://github.com/libuv/libuv/issues/3864 > but might not be fixed anytime soon in 1.x branch. > > Indeed, fixing it breaks API. > > However, in Debian, I think we can just do that, as long as we patch > reverse dependencies on libuv1. I disagree. Some people may be using libuv1 in a program not handled by Debian. Breaking the API means changing the SONAME of the lib. According to Debian policy, this means creating a libuv2 package. > What do you think about that ? We should wait for an upstream libuv v2. All the best.
Bug#1069247: libconfig-model-dpkg-perl: test failures
On Sunday, 21 April 2024 18:07:00 CEST Julian Andres Klode wrote: > This should be fixed in apt git already, just needs an upload, > which is waiting-ish for some more merges Given [1], I need to ask... Is this a definitive fix or will this feature come back with apt 3.0 ? All the best [1] https://salsa.debian.org/apt-team/apt/-/commit/fc35b4d7d95b2848db482021df4f4500ac142080
Bug#1069247: libconfig-model-dpkg-perl: test failures
On Thursday, 18 April 2024 19:21:55 CEST you wrote: > Source: libconfig-model-dpkg-perl > Version: 3.004 > Severity: serious > Tags: ftbfs > Justification: fails to build from source This really looks like a bug with prove: $ perl t/reorder.t ok 1 - test re-ordered list 1..1 $ prove -l -v -p t/reorder.t t/reorder.t .. ok 1 - test re-ordered list 1..1 Failed 1/1 subtests Test Summary Report --- t/reorder.t (Wstat: 0 Tests: 0 Failed: 0) Parse errors: Bad plan. You planned 1 tests but ran 0. Files=1, Tests=0, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.92 cusr 0.07 csys = 1.01 CPU) Result: FAIL I can't see what's wrong with the output of reorder test... I'll try to dig this later on.. All the best
Bug#1063484: libuv1: CVE-2024-24806
On Wednesday, 6 March 2024 21:07:56 CET Salvatore Bonaccorso wrote: > Thank you very much. Looks good to me, feel free to upload as well to > security-master (and build as well with -sa). Done. All the best
Bug#1063484: libuv1: CVE-2024-24806
On Thu, 29 Feb 2024 21:53:07 +0100 Salvatore Bonaccorso wrote: > libuv1 is as well affected in bullseye and it's still supported. Can > you have a look as well at this version? The same patch (with a refresh) applies to bullseye. I can also prepare an upload. All the best
Bug#1063484: libuv1: CVE-2024-24806
On Thu, 08 Feb 2024 20:51:30 +0100 Salvatore Bonaccorso
wrote:
> Note, that the advisory at [1] mentions that affected versions are
> only > 1.45.x. Looking at the git changes, is it not introduced after
> 6dd44caa35b4 ("unix,win: support IDNA 2008 in uv_getaddrinfo()") in
> v1.24.0?
The advisory has been changed and list v1.24.0 as affected version.
I'm going to pacakge v1.48 to fix this issue in unstable.
I'm still pondering what should be done for stable which ships a libuv 1.44.2
All the best
Bug#1055937: lcdproc: package is missing files and functionalities
Hi On Tue, 14 Nov 2023 09:00:11 -0500 Frederic wrote: > Package is missing files and functionalities about USB Yes, some usb drivers were removed a while ago because they use a deprecated libusb. > Problem #1 > Locally merge PR #200 and #201 (especially #201 for USB interface) No. I'll wait for a new upstream release. You can help there to get this merged upstream. On my side, I've asked for a new release, > Problem #2 > The debian package is missing the /etc/LCDd.conf configuration file, > obviously nothing can work without it. > File is in the root of git master. > While you're in it, change the "DriverPath=" line with the proper directory like /usr/lib/x86_64-linux-gnu/lcdproc/ for instance. No. By default, this is managed by cme. Please reconfigure your package to have LCDd.conf installed (and tuned for your machine, including the DriverPath line) > Problem #3 > The package was not compiled with USB support, meaning except if you have an old PC with a parallel port and an adapter to do some bit banging, it's useless... > you need to install both libusb-1.0-0-dev and libusb-dev then: > ./configure --enable-libusb --enable libusb-1-0 --enable-drivers=all libusb-dev is deprecated since 2016 (see https://bugs.debian.org/cgi-bin/ bugreport.cgi?bug=810428). This led to the removal of some drivers. libusb-1-0 is enabled. Most drivers are provided with lcdproc and lcdproc-extra-drivers. Some drivers are missing due to incompatibilities. (See hhttps://github.com/ lcdproc/lcdproc/issues/13 ) > Problem #4 > Mixed up the init.d between the server and the client... fix it: > cp scripts/init-LCDd.LSB /etc/init.d/LCDd > cp scripts/init-lcdproc.LSB /etc/init.d/lcdproc lcdproc is managed by systemd and runs LCDd /etc/init.d/lcdproc is a sysv fallback The services is provided as lcdproc so the service name matches the package name (mismatched names is frowned upon) lcdproc and lcdvc are not installed as daemon. All the best
Bug#1057567: libconfig-model-lcdproc-perl: FTBFS: Cannot determine local time zone
Hi On Tuesday, 5 December 2023 23:06:12 CET you wrote: > Wrote documentation in lib/Config/Model/models/LCDd/yard2LCD.pod Cannot > determine local time zone > [DZ] beginning to build Config-Model-LcdProc I've seen this error from time to time. I don't know the exact algorithm used to determine the time zone, but usually, setting TZ to an appropriate value fixed this issue. Could you check the config of your build deamon and add such a variable ? All the best
Bug#1057335: libperl-languageserver-perl: language server exits on error with «Can't "continue" outside a when block»
Package: libperl-languageserver-perl Version: 2.6.1-2 Severity: important Dear Maintainer, With the latest package, the language server always exits on error with: Can't "continue" outside a when block at /usr/share/perl5/Perl/LanguageServer/Parser.pm line 181. I'm using perl language server via emacs and lsp-mode. This bug happens whenever a Perl file is loaded. Looks like a "continue" statement was not cleaned up with perl5.38 patch that was added to last release. I've tried to fix the issue, but I'm a bit lost in the huge if/then/else statement. I'll let you fix this. All the best -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libperl-languageserver-perl depends on: ii libanyevent-aio-perl 1.1-2 ii libanyevent-perl 7.170-2+b3 ii libclass-refresh-perl 0.07-2 ii libcompiler-lexer-perl 0.23-3+b1 ii libcoro-perl 6.570-3+b1 ii libdata-dump-perl 1.25-1 ii libencode-locale-perl 1.05-3 ii libhash-safekeys-perl 0.04-1+b1 ii libio-aio-perl 4.80-1 ii libjson-perl 4.1-1 ii libmoose-perl 2.2206-1 ii libpadwalker-perl 2.5-1+b3 ii libscalar-list-utils-perl 1:1.63-1+b1 ii perl 5.36.0-10 ii perl-base [libscalar-list-utils-perl] 5.36.0-10 libperl-languageserver-perl recommends no packages. libperl-languageserver-perl suggests no packages. -- no debconf information
Bug#1057007: libconfig-model-tkui-perl: autopkgtest for libconfig-model-itself-perl fails with libconfig-model-tkui-perl 1.377
On Saturday, 2 December 2023 12:32:02 CET you wrote: > Git bisect shows that the following commit leads to the loop: > > https://github.com/dod38fr/config-model-tk-ui/commit/b3bd74328e3ded903790ee8 > 042699821a8d10bf4 Fixed upstream in v1.378
Bug#1057007: libconfig-model-tkui-perl: autopkgtest for libconfig-model-itself-perl fails with libconfig-model-tkui-perl 1.377
On Saturday, 2 December 2023 12:05:54 CET Dominique Dumont wrote: > With TkUI, a loop may be hard to spot as callback function are likely to be > involved. Git bisect shows that the following commit leads to the loop: https://github.com/dod38fr/config-model-tk-ui/commit/b3bd74328e3ded903790ee8042699821a8d10bf4
Bug#1057007: libconfig-model-tkui-perl: autopkgtest for libconfig-model-itself-perl fails with libconfig-model-tkui-perl 1.377
On Monday, 27 November 2023 21:53:07 CET you wrote: > I'm sorry I don't even have an idea where this is showing a problem, > much less what that may be caused by.. :-/ No worry. This tests shows that there's a loop in the data structure reference (See https://metacpan.org/pod/Test::Memory::Cycle#SYNOPSIS for more explanation). This may be a problem as memory loop cannot be garbage collected which may lead to a memory leak. With TkU, a loop may be hard to spot as callback function are likely to be involved. I'll check this out. All the best
Bug#1054981: libtk-objeditor-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2
On Sunday, 29 October 2023 01:09:21 CET you wrote: > This seems to be broken by libtk-objscanner-perl 2.018-1 (building in > a testing chroot with 2.017-2 still works). > > Dominique, I think that's a case for you :) ack. I'll handle it upstream. No need to open a bug there. All the best
Bug#1001045: libconfig-model-dpkg-perl: scan-copyright reports empty license
On Sat, 17 Jun 2023 18:26:12 +0200 Dominique Dumont wrote: > Then I would suggest to override the license information reported by licensecheck. > > For details, please see > > https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme#filling-missing-information This is not a bug on libconfig-model-dpkg-perl, closing.
Bug#1053888: dh-dist-zilla: does not run 'dzil clean' on dh_clean
Package: dh-dist-zilla Version: 1.4.1 Severity: normal Dear Maintainer, Due to bug #1049036, I have to run cleanup files generated by dzil build. These files are handled upstream by this config in dist.ini: [Run::Clean] run = rm -rf lib/Config/Model/models/ Unfortunately, "dzil clean" is not called by default when running dh_clean. Could you add that to dh-dist-zilla ? All the best -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-dist-zilla depends on: ii debhelper 13.11.6 ii libdist-zilla-perl 6.030-1 ii perl5.36.0-9 Versions of packages dh-dist-zilla recommends: ii devscripts 2.23.6 Versions of packages dh-dist-zilla suggests: ii libdist-zilla-app-command-authordebs-perl 0.003-2 ii pristine-tar 1.50 ii xz-utils 5.4.4-0.1 -- no debconf information
Bug#1017581: Please install documentation
Hi Sorry for the late reply. On Thu, 18 Aug 2022 00:01:36 +0100 Ian Jackson wrote: > It would be ncie to install this documentation somewhere suitable. As > manpages would be ideal, assuming the .rst files are suitable for > that, but HTML in /usr/share/doc/ would do nicely as well. libuv documentation can indeed be built as HTML files. However, lintian then complains about vendored js files and about privacy breach: W: libuv1-dev: embedded-javascript-library please use libjs-jquery [usr/share/doc/libuv1-dev/html/_static/jquery.js] N: N: This package contains an embedded copy of JavaScript libraries that are N: now available in their own packages (for example, JQuery, Prototype, N: Mochikit or "Cropper"). Please depend on the appropriate package and N: symlink the library into the appropriate location. N: N: Please refer to Embedded code copies (Section 4.13) in the Debian Policy N: Manual for details. N: N: Visibility: warning N: Show-Always: no N: Check: languages/javascript/embedded N: N: W: libuv1-dev: embedded-javascript-library please use libjs-underscore [usr/share/doc/libuv1-dev/html/_static/underscore.js] N: W: libuv1-dev: embedded-javascript-library please use sphinx [usr/share/doc/libuv1-dev/html/_static/doctools.js] N: W: libuv1-dev: embedded-javascript-library please use sphinx [usr/share/doc/libuv1-dev/html/_static/language_data.js] N: W: libuv1-dev: embedded-javascript-library please use sphinx [usr/share/doc/libuv1-dev/html/_static/searchtools.js] N: W: libuv1-dev: privacy-breach-generic [https://www.youtube-nocookie.com/embed/ngn60vdsxq4; frameborder="0"\nallowfullscreen>] (https://www.youtube-nocookie.com/embed/ngn60vdsxq4) [usr/share/doc/libuv1-dev/html/guide/basics.html] N: N: This package creates a potential privacy breach by fetching data from an N: external website at runtime. Please remove these scripts or external HTML N: resources. N: N: Please replace any scripts, images, or other remote resources with N: non-remote resources. It is preferable to replace them with text and links N: but local copies of the remote resources are also acceptable as long as N: they don't also make calls to remote services. Please ensure that the N: remote resources are suitable for Debian main before making local copies N: of them. N: N: Visibility: warning N: Show-Always: no N: Check: files/privacy-breach N: Since these docs are available online, I won't invest more time in fixing these issues and will continue to ship libuv1-dev without HTML doc. All the best
Bug#1052168: libconfig-model-dpkg-perl: maps @copyright{} to no-info-found
On Mon, 18 Sep 2023 18:26:45 +0200 Andreas Metzler wrote:
> something in libconfig-model-dpkg-perl seems to have changed, when
> upgrading guile-gnutls with "cme update dpkg-copyright" the generated
> file moved from
>
> Files: doc/gnutls-guile.texi
> Copyright: @copyright{} 2001-2023, Free Software Foundation, Inc.
> License: GFDL-1.3+
>
> to
>
> Files: doc/gnutls-guile.texi
> Copyright: no-info-found
> License: GFDL-1.3+
Sigh... I've tried to filter out cases where licensecheck latches on lines
containing "(c)" like the following one:
(c)**b <= a and (c+1)**b > a
The line you've shown was seen as garbage and removed because it begins with a
non-alphanumeric char.
I'll update the cleanup_copyright function in Software::Copyright::Statement
to cope with this case.
All the best
Bug#1010604: Support commonly used providers like github.com and gitlab.com within watch file
On Tue, 13 Sep 2022 18:05:23 +0200 Bastian Germann wrote:
> Now the release pages of both Gitlab and GitHub generate their hrefs via
> JavaScript which kills uscan for them.
> See #1019696. They should both have an API to handle this.
Github has such an API.
For instance, here's a call that retrieve the URLs of the last assets of
libtommath on Github:
$ curl -q https://api.github.com/repos/libtom/libtommath/releases | jq
'.[0].assets[] | select( .name | test("xz")) | .browser_download_url'
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 180k 100 180k0 0 1019k 0 --:--:-- --:--:-- --:--:-- 1021k
"https://github.com/libtom/libtommath/releases/download/v1.2.1/ltm-1.2.1.tar.xz;
"https://github.com/libtom/libtommath/releases/download/v1.2.1/ltm-1.2.1.tar.xz.asc;
Bug#1001045: libconfig-model-dpkg-perl: scan-copyright reports empty license
On Mon, 13 Dec 2021 14:24:24 +0530 Vignesh Raman wrote: > Have reported the bug in licensecheck - http://bugs.debian.org/1001615 Looks like this bug won't be fixed in licensecheck. Then I would suggest to override the license information reported by licensecheck. For details, please see https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme#filling-missing-information HTH
Bug#1033406: licensecheck: scan-copyrights fails to create copyright file for texlive-extra
Hi Sorry for the late reply On Mon, 3 Apr 2023 19:07:05 +0530 Vignesh Raman wrote: > Yes. I'm getting the same error messages. You should have begun with a copy of the error messages you got. I've spent quite some time wondering out what could wrong. Well, let's bygones be bygones. This problem concerns a zone that I've rewritten these past months to ease its maintenance. Running the new scan-copyright on texlive proves to be quite challenging from a performance point of view, so please be patient. All the best.
Bug#1033406: licensecheck: scan-copyrights fails to create copyright file for texlive-extra
On Thu, 30 Mar 2023 08:15:44 +0530 Vignesh Raman wrote: > Could you please look into this issue with the details provided? Thank you. With the setup you mentionned, I get this error message: Invalid year range: 2012-11-06 at /home/domi/private/debian-dev/perl-stuff/libconfig-model-dpkg-perl/lib/Dpkg/Copyright/Scanner.pm line 723. Invalid year range: 2015-01-11 at /home/domi/private/debian-dev/perl-stuff/libconfig-model-dpkg-perl/lib/Dpkg/Copyright/Scanner.pm line 723. Can't call method "consolidate" on an undefined value at /home/domi/private/debian-dev/perl-stuff/libconfig-model-dpkg-perl/lib/Dpkg/Copyright/Scanner.pm line 731. Are you getting this error message as well ? All the best
Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed
Hi I've created a merge request [1] on devscript to fix this issue All the best [1] https://salsa.debian.org/debian/devscripts/-/merge_requests/343
Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed
Hello
Turns out that Perl module Net::SMTP supports SSL since 2014 [1], but bts still
use Net::SMTPS which is an old wrapper around Net::SMTP.
I've patched bts to use Net::SMTP instead of Net::STMPS and I can connect to
Daniel's server:
$ perl -MDevel::SimpleTrace scripts/bts.pl --smtp-host smtps://mail.wgdd.de
usertag 1029588 + dod-test-with-tls
Net::SMTP::_SSL>>> Net::SMTP::_SSL
Net::SMTP::_SSL>>> IO::Socket::SSL(2.081)
Net::SMTP::_SSL>>> IO::Socket::IP(0.41)
Net::SMTP::_SSL>>> IO::Socket(1.49)
Net::SMTP::_SSL>>> IO::Handle(1.48)
Net::SMTP::_SSL>>> Exporter(5.77)
Net::SMTP::_SSL>>> Net::SMTP(3.14)
Net::SMTP::_SSL>>> Net::Cmd(3.14)
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 220 mail.wgdd.de ESMTP Postfix
(Debian/GNU)
Net::SMTP::_SSL=GLOB(0x5590e82e5878)>>> EHLO free.fr
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-mail.wgdd.de
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-PIPELINING
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-SIZE
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-ETRN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-AUTH PLAIN LOGIN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-AUTH=PLAIN LOGIN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-ENHANCEDSTATUSCODES
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-8BITMIME
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-DSN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-SMTPUTF8
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250 CHUNKING
Net::SMTP::_SSL=GLOB(0x5590e82e5878)>>> MAIL FROM:
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250 2.1.0 Ok
Net::SMTP::_SSL=GLOB(0x5590e82e5878)>>> RCPT TO:
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 554 5.7.1
<91-175-103-119.subs.proxad.net[91.175.103.119]>: Client host rejected: Access
denied
bts.pl: failed to set SMTP recipient cont...@bugs.debian.org
()
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(scripts/bts.pl:2848)
at main::(scripts/bts.pl:834)
bts fails later probably because of my mail config (proxad system is free.fr
mail server).
Anyhow, the failure occurs after bts is connected to Daniel's server.
Could you test bts with the patch below ? (feel free to remove the Debug
argument)
All the best
[1] https://metacpan.org/dist/libnet/changes#L256
diff --git a/scripts/bts.pl b/scripts/bts.pl
index 7449c7ca..6ed35437 100755
--- a/scripts/bts.pl
+++ b/scripts/bts.pl
@@ -106,7 +106,7 @@ sub have_lwp() {
sub have_smtps() {
return ($smtps_broken ? 0 : 1) if defined $smtps_broken;
-eval { require Net::SMTPS; };
+eval { require Net::SMTP; };
if ($@) {
if ($@ =~ m%^Can\'t locate Net/SMTPS%) {
@@ -2703,11 +2703,12 @@ sub send_mail {
$port ||= '465';
if (have_smtps) {
-$smtp = Net::SMTPS->new(
+$smtp = Net::SMTP->new(
$host,
Port => $port,
Hello => $smtphelo,
-doSSL => 'ssl'
+SSL => 1,
+Debug => 1,
)
or die
"$progname: failed to open SMTPS connection to $smtphost\n($@)\n";
@@ -2720,11 +2721,10 @@ sub send_mail {
$port ||= '25';
if (have_smtps) {
-$smtp = Net::SMTPS->new(
+$smtp = Net::SMTP->new(
$host,
Port => $port,
Hello => $smtphelo,
-doSSL => 'starttls'
)
or die
"$progname: failed to open SMTP connection to $smtphost\n($@)\n";
Bug#1033406: licensecheck: scan-copyrights fails to create copyright file for texlive-extra
On Fri, 24 Mar 2023 21:22:33 +0530 Vignesh Raman wrote: > Only when we run scan-copyrights with all the source files, it crashes. With texlive-extra-2022.20230122 source, scan-copyright emits some warnings but does not fail. Could you try scan-copyright on your side by running this command in texlive-extra directory ? $ scan-copyright > copyright.debian Since the source is quite big (the output of license-check weights 32MB), it's possible that your system runs out of memory. Please check for kernel message. On my system, scan-copyright uses ~130MB when scanning texlive-extra. All the best
Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed
On Wed, 22 Mar 2023 15:22:34 +0100 Lee Garrett wrote: > While this setup might work for some people, this has IMHO quite a few hefty > drawbacks and requires me to maintain a MTA on my local machine. I could > elaborate, but I don't think it's on-topic for this bug report. Agreed. > I'm sure that bts supports STARTTLS. I am using bts with my MTA on 587/tcp, > which enforces STARTTLS and requires credentials (I just double-checked via > swaks). With the old libio-socket-ssl-perl 2.069-1 this works, so it's > clearly a > regression. BTS uses SSL when the host URL begins with smpts or ssmtp (see [1]), and STARTTLS otherwise. It may be a regression, but I need more data before reporting this problem upstream. Daniel, could you apply the patch below on bts.pl and try again ? You should get more traces when bts is trying to connect to your server. All the best [1] https://salsa.debian.org/debian/devscripts/-/blob/master/scripts/bts.pl#L2697 diff --git a/scripts/bts.pl b/scripts/bts.pl index 7449c7ca..f280e9a1 100755 --- a/scripts/bts.pl +++ b/scripts/bts.pl @@ -64,6 +64,9 @@ use Encode; use URI 1.37; use URI::QueryParam; +use IO::Socket::SSL; +$IO::Socket::SSL::DEBUG=2; + use Scalar::Util qw(looks_like_number); use POSIX qw(locale_h strftime);
Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed
On Tue, 14 Feb 2023 22:21:26 +0100 Lee Garrett wrote: > Bumped severity as this makes bts currently unusable, and probably > breaks for quite a few DDs their workflow. This does not break on my system where bts is connected to local sendmail (which is the default setup). Which hints at a workaround: have bts connect to local sendmail and have sendmail forward the mail to the SMTPS server. The change mentioned by Daniel affects only a setup where the host if configured via its IP address, not via a host name: See the change in SSL.pm in commit https://github.com/noxxi/p5-io-socket-ssl/commit/c0a063b70f0a3ad033da0a51923c65bd2ff118a0 Which is not the case here: $ perl -S -MDevel::SimpleTrace bts --smtp-host smtps://mail.wgdd.de usertag 1029588 + dod-test-with-tls bts: failed to open SMTPS connection to smtps://mail.wgdd.de (hostname verification failed) at main::send_mail(mail.wgdd.de) at main::mailbtsall(/usr/bin/bts:2839) at main::(/usr/bin/bts:825) Unfortunately, I can no longer investigate this issue as it looks like that my IP address is now blacklisted on Daniel's server: $ perl -MDevel::SimpleTrace scripts/bts.pl --smtp-host smtps://mail.wgdd.de usertag 1029588 + dod-test-with-tls bts.pl: failed to open SMTPS connection to smtps://mail.wgdd.de (Connection refused) at main::send_mail(mail.wgdd.de) at main::mailbtsall(scripts/bts.pl:2849) at main::(scripts/bts.pl:834) On a hunch, I would guess that Daniel's server is configured to handle STARTTLS, which is not supported by bts. But I cannot verify this. In any case this does not explain why Daniel sees bts working with libio-socket-ssl-perl 2.077 but not with 2.078. All the best
Bug#1027686: Rakudo transition is stuck ?
Hi Nothing is happening in rakudo transition [1], no package are rebuilt. Is there a way to unblock this transition ? All the best [1] https://release.debian.org/transitions/html/rakudo.html
Bug#1027686: transition: rakudo
On Wednesday, 18 January 2023 03:03:37 CET M. Zhou wrote: > I have uploaded moarvm, nqp, and rakudo to unstable. > They turned green on release architectures. > The ppc64el buildd lags a little bit but I believe the result will be > green as well based on the previous no-change build in experimental. Unfortunately, there was still a mistmatch between the "Provides" field generated for rakudo (Provides: raku-api-2022.12+af50a328) and the "Depends" field generated by dh-raku 0.14 (Depends: raku-api-2022.12). I've fixed this problem in dh-raku 0.15 which I uploaded to unstable this morning. I don't know if something needs to be done on rakudo transition to cope with this hiccup. Sorry for the mess Dod
Bug#1027686: transition: rakudo
On Sunday, 15 January 2023 15:21:55 CET Sebastian Ramacher wrote: > > I've found where compiler-id is computed. I'm going patch rakudo in > > experimental so that compiler-id depends only on source files and nqp > > version. This patch will land in experimental. > > Okay, please let me know once it's available in experimental. Done with rakudo 2022.12-1~exp3 I've patched the compiler id to be a sha1 of "Debian-". I've verified that compiler id is the same for the arch that are built. Is it still time to trigger a transition to fix all raku modules ? (there's no impact outside of raku modules) All the best.
Bug#1027686: transition: rakudo
On Wed, 11 Jan 2023 18:45:41 +0100 Dominique Dumont wrote: > > Can the computation of the ID be patched to be independent of the > > build path? > > I haven't figured out completely how this compiler-id is created. I've found where compiler-id is computed. I'm going patch rakudo in experimental so that compiler-id depends only on source files and nqp version. This patch will land in experimental. All the best
Bug#1027686: transition: rakudo
On Tuesday, 10 January 2023 11:21:32 CET Sebastian Ramacher wrote: > Control: tags -1 moreinfo > > On 2023-01-09 13:54:08 -0500, M. Zhou wrote: > > I missed the detail that the compiler ID even changes for different > > architecture.. which may not be good. > > Is it required that the build path of the compiler influences the ID? Well, I don't know. I've created an issue upstream on that topic, but Raku devs are not really responsive on this issue. (see https://github.com/rakudo/rakudo/issues/5099) > Can the computation of the ID be patched to be independent of the > build path? I haven't figured out completely how this compiler-id is created. > I think it's too late to change this shortly before the freeze starts. > If fixing the compiler ID computation is not possible, I prefer to delay > this transition to trixie. Agreed. Unfortunately, a lot of raku modules are currently broken or will break in stable if rakudo needs to be updated. Hence my proposal to switch back to perform pre-compilation at installation time (detailed in my previous mail in this thread) All the best.
Bug#1027686: transition: rakudo
On Monday, 9 January 2023 19:54:08 CET M. Zhou wrote: > Is it possible for us to slightly modify the postinst script to > recompile the cache locally when the compiler id mismatches? I'd rather not. Untangling pre-compilation issues is hard enough. In case of problem I dont' want to wonder whether the failure comes from files compiled on Debian server or on user's machine. > The fallback script rakudo-helper.pl can at least make sure > a raku-* package is still functional even without a matching > compiler ID. In that case we don't have to add the compiler ID > to the virtual package name, and every architecture can track > the same and consistent virtual package dependency. Given the state of Raku's compiler-id, I think the only sane way (or rather which will preserve my sanity) is to go back to perform pre-compilation at installation time. This require: - an update of dh-raku to restore compilation at installation time. - a modification of all raku modules to: - remove dependency on raku-api* - go back to arch:all - depend on next dh-raku version Thoughts ?
Bug#1027686: transition: rakudo
On Saturday, 7 January 2023 11:58:29 CET you wrote: > > Unfortunately, the compiler-id also depends on the build directory. Which > > means that the compiler id changes between arches. > > This should be fixed first. Otherwise every rebuild of the compiler will > require all reverse dependencies to be rebuilt too. That does not sound > like a good solution. Agreed, but that's a long story with upstream: https://github.com/rakudo/rakudo/issues/5099 All the best
Bug#1027686: transition: rakudo
On Sunday, 1 January 2023 22:38:43 CET M. Zhou wrote: > Specifically, the pre-compiled cache shipped in reverse dependencies > relies on a matching compiler ID. Hence, we added the compiler ID into the > virtual package to ensure cache compatibility: raku-api-2022.12+e556a5c0 > The compiler ID will change when code is modified. Unfortunately, the compiler-id also depends on the build directory. Which means that the compiler id changes between arches. > Albeit adding the compiler ID may not sound like an ideal solution, > this seems like what we can do before the freeze. Unfortunately, yes. > Ben file: > > title = "rakudo"; > is_affected = .depends ~ "raku-api-2022.07" | .depends ~ > "raku-api-2022.12+e556a5c0"; is_good = .depends ~ > "raku-api-2022.12+e556a5c0"; > is_bad = .depends ~ "raku-api-2022.07"; I'm afraid this will break when rakudo is rebuilt in unstable. I may have missed something, but why not keep the following lines as ben file: Affected: .depends ~ /(^|\s)raku-api-/ Good: !.edos-debcheck ~ /uninstallable/ Bad: .edos-debcheck ~ /uninstallable/ This is what is currently specified in https://release.debian.org/transitions/html/rakudo.html All the best
Bug#1026984: Possible fix for pan crash
Hi piorunz, could you try the fix proposed there: https://gitlab.gnome.org/GNOME/pan/-/merge_requests/41 All the best Dod
Bug#1026984: Info received (Bug#1026984: Acknowledgement (pan: segfault when opening a newsgroup))
On Sun, 25 Dec 2022 20:00:15 + piorunz wrote: > I've managed to download symbols and run gdb again: > > coredumpctl gdb 3417359 > bt > (32000+ lines omitted) > last 10 lines: This looks like a recursive call gone bad. Could you send me the whole backtrace ? All the best
Bug#1023576: Need to change the way raku-api is built (will breaks modules)
Hi Following bug #1023576 and [1], the dependency between raku modules and rakudo version needs to be tightened. Until now, every raku-module depends on raku-api- (currently is raku-api-2022-07). The idea is to lock the pre-compiled files contained in a raku-module package to a specific rakudo version. Turns out this is not enough. The pre-compiled files are specific to raku compiler id, which changes whenever nqp or rakudo sources are changed. This source change occurred only on nqp or rakudo upgrades, until I had to patch rakudo source code to fix a bug (#1019579). To fix this, I need to make sure that a module is dependent on a rakudo version with a matching compiler-id. I see no other solution than to change the way rakudo is built to include the compiler id in raku-api (well, only the first 8 chars, because compiler id is quite long). I.e. the next version of rakudo will have this in its control file: Provides: raku-api-2022.07+a6fe09f2 And dh-raku-build will be modified to inject this dependency in raku modules. E.g.: Depends: raku-api-2022.07+a6fe09f2 So, the plan is: - upload a new dh-raku (which will produce non installable raku module package until rakudo is updated) - upload a new version of rakudo in experimental - trigger a transition so that all raku modules are rebuilt with new rakudo and new dh-raku Until the transition is complete, raku in Debian/unstable will be a mess. If anyone has a better idea, I'm all ears ... Dod [1] https://github.com/rakudo/rakudo/issues/5099
Bug#1023068: /usr/share/perl5/Config/Model/Dpkg/Dependency.pm: warning with perl 5.36
On Saturday, 29 October 2022 23:15:05 CET you wrote: > Use of @_ in numeric gt (>) with signatured subroutine is experimental at > /usr/share/perl5/Config/Model/Dpkg/Dependency.pm line 344. A real bug was hidden there. Thanks for the heads-up
Bug#1022804: azure-cli: terraform fails due to azure-cli error: unexpected keyword argument 'allow_broker'
Package: azure-cli Version: 2.41.0-1 Severity: normal Dear Maintainer, With Debian's azure-cli, terraform authentication fails with the following error: $ terraform apply ╷ │ Error: obtaining Authorization Token from the Azure CLI: parsing json result from the Azure CLI: waiting for the Azure CLI: exit status 1: ERROR: The command failed with an unexpected error. Here is the traceback: │ ERROR: ClientApplication.__init__() got an unexpected keyword argument 'allow_broker' │ Traceback (most recent call last): │ File "/usr/lib/python3/dist-packages/knack/cli.py", line 233, in invoke │ cmd_result = self.invocation.execute(args) │ File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 663, in execute │ raise ex │ File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 726, in _run_jobs_serially │ results.append(self._run_job(expanded_arg, cmd_copy)) │ File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 697, in _run_job │ result = cmd_copy(params) │ File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 333, in __call__ │ return self.handler(*args, **kwargs) │ File "/usr/lib/python3/dist-packages/azure/cli/core/commands/command_operation.py", line 121, in handler │ return op(**command_args) │ File "/usr/lib/python3/dist-packages/azure/cli/command_modules/profile/custom.py", line 66, in get_access_token │ creds, subscription, tenant = profile.get_raw_token(subscription=subscription, resource=resource, scopes=scopes, │ File "/usr/lib/python3/dist-packages/azure/cli/core/_profile.py", line 382, in get_raw_token │ credential = self._create_credential(account, tenant) │ File "/usr/lib/python3/dist-packages/azure/cli/core/_profile.py", line 592, in _create_credential │ return identity.get_user_credential(username_or_sp_id) │ File "/usr/lib/python3/dist-packages/azure/cli/core/auth/identity.py", line 224, in get_user_credential │ return UserCredential(self.client_id, username, **self._msal_app_kwargs) │ File "/usr/lib/python3/dist-packages/azure/cli/core/auth/msal_authentication.py", line 39, in __init__ │ super().__init__(client_id, **kwargs) │ File "/usr/lib/python3/dist-packages/msal/application.py", line 1525, in __init__ │ super(PublicClientApplication, self).__init__( │ TypeError: ClientApplication.__init__() got an unexpected keyword argument 'allow_broker' │ To open an issue, please run: 'az feedback' On the other hand, terraform works fine when using the azure-cli package provided by Microsoft: $ sudo apt install azure-cli=2.41.0-1~bullseye [snip] The following packages will be DOWNGRADED: azure-cli [snip] dpkg: warning: downgrading azure-cli from 2.41.0-1 to 2.41.0-1~bullseye (Reading database ... 717725 files and directories currently installed.) Preparing to unpack .../azure-cli_2.41.0-1~bullseye_all.deb ... Unpacking azure-cli (2.41.0-1~bullseye) over (2.41.0-1) ... Setting up azure-cli (2.41.0-1~bullseye) ... [snip] $ terraform apply module.seira-azure.random_integer.subnet-nb: Refreshing state... [id=154] [snip] All the best -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages azure-cli depends on: ii python33.10.6-1 ii python3-azure-cli 2.41.0-1 azure-cli recommends no packages. azure-cli suggests no packages. -- no debconf information
Bug#1021773: libconfig-model-dpkg-perl: tweak example in docs for fix.(scanned.)copyright does not work
On Saturday, 22 October 2022 12:09:30 CEST you wrote: > Thank you. This does not throw an error, but does not work as expected > either: > (sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.9$ cat > debian/fix.scanned.copyright ! Files:"*" Copyright=~"s/, Free Software$/, > Free Software Foundation, Inc./" > (sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.9$ > > debian/copyright && cme update dpkg-copyright > /dev/null 2>&1 > (sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.9$ grep ', Free > Software$' debian/copyright Copyright: 2007-2012, 2014-2016, 2019, 2021, > 2022, Free Software > Copyright: 2004, 2005, 2007-2009, 2011-2015, Free Software Hmm, Looking at guile-gnutls copyright file [1], I see that this entry is correct: Files: * Copyright: 1985, 1986, 1988, 1990-2021, Free Software Foundation, Inc. License: GPL-3+ whereas the following entry is not: Files: guile/modules/gnutls.in Copyright: 2007-2012, 2014-2016, 2019, 2021, 2022, Free Software License: LGPL-2.1+ So, I assume you want to apply the instruction specified in fix.scanned.copyright to change all copyright entries. Which is not the case because "! Files:"*"Copyright=~"s/, Free Software$/, Free Software Foundation, Inc./" applies *only* on: Files: * Copyright: 1985, 1986, 1988, 1990-2021, Free Software Foundation, Inc. License: GPL-3+ If you want to fix all copyright entries, you should use the foreach_match instruction [2]. For instance, starting from [1], I can fix the wrong copyright entries with (note the Files argument is different): $ cme modify dpkg-copyright '! Files:~/.*/ Copyright=~"s/, Free Software$/, Free Software Foundation, Inc./"' Warning in 'Files:"build-aux/ltmain.sh" License short_name': licensecheck found an ambiguous license statement. Please: - check the source code to find the actual license association - override this value using "override-license" parameter in "debian/fill.copyright.blanks.yml" file. See "Filling the blanks" section in Dpkg::Copyright::Scanner(3pm) man page for details (this cannot be fixed with 'cme fix' command) Offending value: '(GPL-2+ and/or GPL-3+) with Libtool exception' Changes applied to dpkg-copyright configuration: - Files:"guile/modules/gnutls.in" Copyright: '2007-2012, 2014-2016, 2019, 2021, 2022, Free Software' -> '2007-2012, 2014-2016, 2019, 2021, 2022, Free Software Founda[...]' - Files:"m4/ltoptions.m4 m4/ltsugar.m4 m4/lt~obsolete.m4" Copyright: '2004, 2005, 2007-2009, 2011-2015, Free Software' -> '2004, 2005, 2007-2009, 2011-2015, Free Software Foundation, [...]' $ git diff diff --git a/debian/copyright b/debian/copyright index 17dcb21..9660ba5 100644 --- a/debian/copyright +++ b/debian/copyright @@ -78,7 +78,7 @@ Copyright: 1985, 1986, 1988, 1990-2018, Free Software Foundation, Inc. License: GPL-3+ Files: guile/modules/gnutls.in -Copyright: 2007-2012, 2014-2016, 2019, 2021, 2022, Free Software +Copyright: 2007-2012, 2014-2016, 2019, 2021, 2022, Free Software Foundation, Inc. License: LGPL-2.1+ Files: guile/modules/gnutls/build/* @@ -108,7 +108,7 @@ License: LGPL-3+ Files: m4/ltoptions.m4 m4/ltsugar.m4 m4/lt~obsolete.m4 -Copyright: 2004, 2005, 2007-2009, 2011-2015, Free Software +Copyright: 2004, 2005, 2007-2009, 2011-2015, Free Software Foundation, Inc. License: FSFULLR The following command also works fine if you want a more readable version: $ cme modify dpkg-copyright '! Files:.foreach_match(.*) Copyright=~"s/, Free Software$/, Free Software Foundation, Inc./"' .foreach_match(/.*/) also works. You can use the instruction passed to cme modify command in debian/fix.scanned.copyright HTH [1] https://salsa.debian.org/gnutls-team/guile-gnutls/-/blob/main/debian/copyright [2] https://metacpan.org/pod/Config::Model::Loader#xxx:.foreach_match(yy)-or-xxx:~yy
Bug#1021773: libconfig-model-dpkg-perl: tweak example in docs for fix.(scanned.)copyright does not work
On Friday, 14 October 2022 15:07:56 CEST you wrote: > The docs for Config::Model::Dpkg::Copyright list dthis example for > tweaking: > > ! Files:'*' Copyright=~s/\s*".*// Arg, I got it. This behavior is due to a limitation of Config::Model::Loader where only double quote can be used. Here, you've used single quote with Files: argument. So cme has created a Files entry with «'*'» instead of «*». And this entry has no copyright statement, hence the error. This error message does mention the problematic entrym but it's hard to see because of the single within double quotes: > Note: loading debian/fix.scanned.copyright fixes from copyright fix files > Configuration item 'Dpkg::Copyright' has a user error: > Error while applying fix.scanned.copyright file: > Configuration item 'Files:"'*'" Copyright' has a wrong value: > Undefined mandatory value. I'm updating Config::Model::Loader to allow single and double quote. But this has a side effect: a s/// instruction with space will have to be quoted. The following should work with current and future version of Config::Model::Loader ! Files:"*" Copyright=~"s/, Free Software$/, Free Software Foundation, Inc./" HTH
Bug#1021773: libconfig-model-dpkg-perl: tweak example in docs for fix.(scanned.)copyright does not work
On Friday, 14 October 2022 15:07:56 CEST you wrote: > Note: loading debian/fix.scanned.copyright fixes from copyright fix files > Configuration item 'Dpkg::Copyright' has a user error: > Error while applying fix.scanned.copyright file: > Configuration item 'Files:"'*'" Copyright' has a wrong value: > Undefined mandatory value. I've reproduced this message with a copyright that contains: Copyright: "2009-2011, Dominique Dumont " Note the quite at the beginning of the copyright statement. With this quote at the beginning of the statement, the substitution command s/\s*".*// matches the whole statement, so it removes its content, which triggers the "Undefined mandatory value". HTH
Bug#1021773: libconfig-model-dpkg-perl: tweak example in docs for fix.(scanned.)copyright does not work
On Friday, 14 October 2022 15:07:56 CEST you wrote: > Note: loading debian/fix.scanned.copyright fixes from copyright fix files > Configuration item 'Dpkg::Copyright' has a user error: > Error while applying fix.scanned.copyright file: > Configuration item 'Files:"'*'" Copyright' has a wrong value: > Undefined mandatory value. This can happen if the s/\s*".*// results in a blank copyright. What is the content of the copyright file before running "cme update" ? All the best
Bug#1020898: Uninstallable due to file conflict A37F26876B58371B70EDD889AD69F064C90AC2C6
On Wed, 28 Sep 2022 12:17:48 +0200 Dominique Dumont wrote: > I'll have to reach out to upstream to investigate. I've a fix from upstream for rakudo package. The fix is added in rakudo 2020.07-2 I need to re-upload the affected module packages to depend on that version of rakudo (so the package is rebuilt without the conflicting file). I will not upload a new version of perl6-readline. This package is replaced by raku-readline and has a RM bug filed. All the best Dod
Bug#1020898: Uninstallable due to file conflict A37F26876B58371B70EDD889AD69F064C90AC2C6
On Wednesday, 28 September 2022 10:39:57 CEST Guillem Jover wrote: > [ Filing against all affected packages because it's not clear to me which > one needs to be fixed. ] > > These packages all contain (at least) these same filenames: > > ,--- > perl6-readline: > /usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A > 37F26876B58371B70EDD889AD69F064C90AC2C6 perl6-readline: > /usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A > 37F26876B58371B70EDD889AD69F064C90AC2C6.repo-id Sigh.. This precompiled file should be provided by rakudo package. I'm afraid all raku-* packages are impacted. I'll have to reach out to upstream to investigate. All the best
Bug#1020788: dh-raku: Failed to create directory '/sbuild-nonexistent/.raku/short'
On Mon, 26 Sep 2022 21:26:45 +0300 Adrian Bunk wrote: > Package: dh-raku > Version: 0.13 I knew this was not a good version number ;-) I'll fix this soon. Thanks for the report. All the best
Bug#1019579: raku-json-unmarshal: trying to overwrite '/usr/lib/perl6/vendor/precomp/C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package rak
On Mon, 12 Sep 2022 17:21:45 +0300 Adrian Bunk wrote: > Unpacking raku-json-unmarshal (0.10-1) ... > dpkg: error processing archive /tmp/apt-dpkg-install-Kxnez1/92-raku-json- unmarshal_0.10-1_arm64.deb (--unpack): > trying to overwrite '/usr/lib/perl6/vendor/precomp/ C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/ C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package raku-json- marshal 0.0.23-1 > ... This bug is due to the fact that raku-json-fast package does not contain the precompiled file for JSON::Fast. This package is a dependency of both raku-json-unmarshal and raku-json- marshal. So the build process of both package recompile JSON::Fast and both ship the precompiled file. Hence the collision. The issue with JSON::Fast precompilation is tracked there: https://github.com/rakudo/rakudo/issues/4907 All the best
Bug#1019935: xorriso: Please make Multi-Arch: foreign
On Saturday, 17 September 2022 09:35:35 CEST Thomas Schmitt wrote: > Seems plausible if xorriso gets it. > > Dominique: Do you agree ? Yes. > My cheat sheet says that i shall add new sections with "UNRELEASED" instead > of "unstable" and that you change this word when uploading. > So i wonder why it is "unstable" but did not make it into Sid or Testing. Actually, you did set it to unstable in commit 06434fcf33b824059a20f5c788cd399cf2fd4ee8, but I was not aware of (or I forgot :-/ ) the need to upload this package. > Shall i add the new changelog entry to 1.5.4-3 and change it back to > "UNRELEASED" or shall i make a new "(1.5.4-4) UNRELEASED" ? Before the actual upload, this line is just a way to communicate with your sponsor(s). This does not matter much when you have only one sponsor. This is more critical in big teams like debian-perl team where you have many contributors and sponsors and sponsors have tools to check which package should be reviewed or uploaded. Only the debian/1.* tag indicates that the package was uploaded. All the best
Bug#1019579: raku-json-unmarshal: trying to overwrite '/usr/lib/perl6/vendor/precomp/C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package rak
On Monday, 12 September 2022 16:21:45 CEST Adrian Bunk wrote: > ... > Unpacking raku-json-unmarshal (0.10-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-Kxnez1/92-raku-json-unmarshal_0.10-1_arm64.deb > (--unpack): trying to overwrite > '/usr/lib/perl6/vendor/precomp/C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/ > C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package > raku-json-marshal 0.0.23-1 ... > ok. I don't' really understand what's going on with these precompiled files. I've asked for help upstream. Thanks for the heads-up All the best.
Bug#1016795: RM: perl6-readline -- ROM; obsolete, replaced by raku-readline
Package: ftp.debian.org Severity: normal Hello Following Perl6 rename to Raku, all raku modules are renamed with the pattern raku-. raku-readline is now in unstable, so it's time to remove perl6-readline. All the best
Bug#1016641: RM: software-copyright -- ROM; wrong source package name, replaced with new one
Package: ftp.debian.org Severity: normal Hi I've messed up when I created software-copyright source package. It should have been libsoftware-copyright-perl. libsoftware-copyright-perl source package is now in Debian unstable. It's time to remove software-copyright source package. Sorry for the blunder All the best
Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
On Sunday, 31 July 2022 16:35:12 CEST Jérémy Lal wrote: > Indeed, sorry for my somewhat irritated tone - it just happens that it was > the second time libuv1 was updated during a nodejs transition, and the > upstream bug it creates on nodejs hasn't been fixed yet, so it shoots the > transition in the guts. > Nodejs depends heavily on libuv1... I understand your furstration. Sorry about the mess. > Maybe a simple approach would be to upload libuv1 updates to experimental > first, and wait a week to see how it scares the others :) That I can do. All the best.
Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
On Saturday, 30 July 2022 19:36:26 CEST you wrote: > libuv1 is a library, you're supposed to manage the transition: > https://wiki.debian.org/Teams/ReleaseTeam/Transitions This page applies when the new version breaks the ABI or API. This was not the case. There was no symbol change. The SO version of libuv1 has not changed since the transition between libuv and libuv1. > In particular, rebuild all reverse build dependencies and check they won't break is highly desirable. > There are tools and services in debian to do that (though honestly it's not so easy to setup). I'm already stretched quite thin. I'll see what I can do. In any case, I'd be happy to handover libuv1 to people willing to better maintain this package. All the best.
Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1
On Saturday, 30 July 2022 17:25:29 CEST you wrote: > libuv1 maintainer: please avoid uploading new versions when nodejs is > in transition... I package libuv1 because it's a dependency of moarvm. I don't follow nodejs releases, so I was not aware of on-going transition and I did not expect problems because only the minor version number was increased. On the other hand, I have no problem with delaying uploads of libuv1 provided someone warns me of issues in other packages. All the best
Bug#1015913: /usr/share/perl5/Config/Model/models/Dpkg/Control.pl: failure applying Dpkg::Control fixes when current directory is single character
On Monday, 25 July 2022 10:19:18 CEST you wrote: > I guess I can tweak the formula > l30 to return undef when the match regex (L35) cannot be satisfied. Which uncovered a bug in libconfig-model-perl. Fixing this bug will also require libconfig-model-perl 2.151 All the best
Bug#1015913: /usr/share/perl5/Config/Model/models/Dpkg/Control.pl: failure applying Dpkg::Control fixes when current directory is single character
Hi
On Saturday, 23 July 2022 20:31:40 CEST you wrote:
> Configuration item 'source Source' has a wrong value:
> computed value error:
> value '1' does not match regexp \w[\w+\-\.]{1,}
> value is computed from 'use Cwd; getcwd =~ m!/([^/]+)$!; $1;'
Right. This is one case where cme tries to be too smart.
The Source parameter is set up to have $PWD as default value [1] and the value
is checked to match a name with more than one char [2].
> In the real case the root_dir argument points to an existing package
> directory containing 'debian/control' and all, e.g:
>
> $ sudo apt install dh-make-perl
> $ mkdir -p ~/tmp/1
> $ cd ~/tmp/1
> $ dh-make-perl --cpan Alias
But this default value does not makes sense. I guess I can tweak the formula
l30 to return undef when the match regex (L35) cannot be satisfied. Then user
must manually set the Source value before saving because this value is
mandatory (L34)
> I hope this is enough to reproduce and diagnose the problem.
Sure, thanks for the boiled down step. This will go in the non reg test suite
;-)
All the best
[1]
https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/-/blob/master/lib/Config/Model/models/Dpkg/Control/Source.pl#L28
[2]
https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/-/blob/master/lib/Config/Model/models/Dpkg/Control/Source.pl#L35
Bug#1015110: raku-getopt-long: FTBFS: Failed to create directory '/usr/lib/perl6/site/short' with mode '0o777': Failed to mkdir: Permission denied
On Saturday, 16 July 2022 15:55:05 CEST Lucas Nussbaum wrote: > > Could not find Getopt::Long in: > > /<>/debian/tmp/home/.raku The real issue is the error above which comes from a bug in dh-raku. The failed attempt to create directory '/usr/lib/perl6/site/short' is a warning. I'll deal with it later. All the best
Bug#1014095: azure-cli: az error: no module 'azure.mgmt.containerservice.v2022_04_01'
Package: azure-cli Version: 2.37.0-2 Severity: important Dear Maintainer, az cli fails due to a missing dependency: $ az aks get-upgrades --resource-group alilo-dev --name alilo-dev The command failed with an unexpected error. Here is the traceback: No module named 'azure.mgmt.containerservice.v2022_04_01' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/knack/cli.py", line 231, in invoke cmd_result = self.invocation.execute(args) File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 561, in execute self.commands_loader.load_arguments(command) File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 515, in load_arguments self.command_table[command].load_arguments() # this loads the arguments via reflection File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 318, in load_arguments super(AzCliCommand, self).load_arguments() File "/usr/lib/python3/dist-packages/knack/commands.py", line 104, in load_arguments cmd_args = self.arguments_loader() File "/usr/lib/python3/dist-packages/azure/cli/core/commands/command_operation.py", line 125, in arguments_loader op = self.get_op_handler(self.op_path) File "/usr/lib/python3/dist-packages/azure/cli/core/commands/command_operation.py", line 59, in get_op_handler handler = import_module(mod_to_import) File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1050, in _gcd_import File "", line 1027, in _find_and_load File "", line 992, in _find_and_load_unlocked File "", line 241, in _call_with_frames_removed File "", line 1050, in _gcd_import File "", line 1027, in _find_and_load File "", line 992, in _find_and_load_unlocked File "", line 241, in _call_with_frames_removed File "", line 1050, in _gcd_import File "", line 1027, in _find_and_load File "", line 1004, in _find_and_load_unlocked ModuleNotFoundError: No module named 'azure.mgmt.containerservice.v2022_04_01' To open an issue, please run: 'az feedback' Can you check what goind on ? All the best -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 azure-cli depends on: ii python33.10.4-1+b1 ii python3-azure-cli 2.37.0-2 azure-cli recommends no packages. azure-cli suggests no packages. -- no debconf information
Bug#1002720: O: bino -- 3D video player
On Tuesday, 28 June 2022 17:56:13 CEST you wrote: > As Daniel has prepared a package for version 1.6.8, I'm going to upload this > version with my sponsor hat. Unfortunately, the package does not build on sid. So I won't upload version 1.6.8. All the best
Bug#1002720: O: bino -- 3D video player
On Tue, 28 Dec 2021 08:05:05 +0100 Daniel Schaal wrote: > Package: wnpp > Severity: normal > X-Debbugs-Cc: daniel@schaal.email > Control: affects -1 src:bino > > I intend to orphan the bino package. As Daniel has prepared a package for version 1.6.8, I'm going to upload this version with my sponsor hat. That said, I will not maintain this package, so its orphan status stands. All the best Dod
Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way
On Tuesday, 21 June 2022 22:40:52 CEST gregor herrmann wrote: > > Would that work out for you? > > Yup. > I'm cc'ing dod as the Config::Model::* tsar to make sure I'm not > missing anything. All good. Thanks for the follow-up > > If so: What are your requirements for such a transition? Do we have to > > just care about Unstable and Testing or are Stable-Backports a topic, > > too? > > I believe we never backported libconfig-model-dpkg-perl. Dominique? Not that I know of. > So I guess we can just depend on a new enough lintian or lintian-data > with /usr/share/lintian/data/debian-policy/latest.txt (or whatever) > and use it, and from the lintian side you can then add a versioned > Breaks on old libconfig-model-dpkg-perl versions still using > private/latest-policy-version, when you remove it. Sounds good to me. All the best
Bug#1013313: libisoburn: Add autopkgtest
On Tuesday, 21 June 2022 20:13:16 CEST Thomas Schmitt wrote:
>case ${RET_GREP} in
>0) # found
> ;;
You may want to log this case which leads to a test failure
>1) # not found
> echo "${SELF}: Log file looks clear." # | tee -a ${CLOG}
> +ok=1
> ;;
> *) #
> echo "${SELF}: grep returned EXIT CODE: ${RET_GREP}." # |
> tee -a ${CLOG} ;;
>esac
> + if test "$ok" = 0 && test "$exit_value" = 0
> + then
> + exit_value=1
> + fi
Fine with me
> With my sponsored packaging helper's hat on, Cc-ing Dominique Dumont
>
> to get an opinion from under the sponsor's hat:
> > +++ libisoburn-1.5.4/debian/tests/control
>
> I don't find this described in
> https://www.debian.org/doc/manuals/maint-guide
> Google finds me
> https://people.debian.org/~eriberto/README.package-tests.html
There's also
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst
This field is also supported by 'cme edit dpkg'.
>
> > +Test-Command: cd ./releng && ./run_all_auto -x $(which xorriso)
> > +Depends: xorriso, g++, libburn-dev, libisofs-dev
>
> At which occasion will this be run ?
This change is required to run these tests in Debian's (or Ubuntu's) CI. Since
releng tests are not run when
building the package, UI guess the intent is to run releng tests every now and
then.
I dont' know exactly when these Ci tests are run. I assume that Ubuntu runs
them from time to time to
check for bitrot in old packages.
An alternative is to run these tests in debian/rules so they are run at package
build time.
This assumes that these tests are reliable.
> Does this have influence on the dependencies of the binary packages ?
No. Dependencies required for the tests can be declared in
debian/tests/control. Without this declaration, the tests deps are
assumed to be the deps of the source package.
All the best
Bug#779364: pan: Crash when opening article with layered attachments
Hello Karl On Sun, 1 Mar 2015 10:31:13 -0800 (PST) Karl Kornel wrote: > I am having an issue with Pan, where it is crashing when I try to open certain > articles. In 2015, you reported a bug on Pan which crashed when opening some articles. The backtrace shows a problem with g_mime_multipart_encrypted_decrypt (). I guess that the crash was triggered by utf-8 encoded character that can be found in the article mentioned in the bug report [1]. A lot of related to utf-8 and gmime are now fixed in Pan which is now v.0150. Could you try again ? If not, if the leland group public ? We hope to be able to reproduce this bug. All the best [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779364
Bug#1000179: cme update dpkg-copyright should detect cpoyright holders for apache license
On Friday, 19 November 2021 18:03:57 CEST you wrote: > I'm reluctant to set --lines 0 option when calling licensecheck as this > could really slow down copyright update (which is already not that fast on > big packages) All in all, slow is better than wrong. I'm going to use --lines 0 option. Dod
Bug#1000179: cme update dpkg-copyright should detect copyright holders for apache license
On Sat, 20 Nov 2021 11:24:42 +0100 Jonas Smedegaard wrote: > Would be interesting to know some actual numbers for this - to not rely > on cargo cult. For the records, the timing tests of licensecheck --lines 0 are reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960681#70
Bug#1011335: libssl3: using SSL is not possible in Kmail with the update to OpenSSL3
On Fri, 20 May 2022 11:31:47 +0200 merlin wrote: > On my computer the system installed is a Debian Sid AMD64 and I use Kmail to > receive or send messages, for 4 days I could not receive or send messages using > Kmail. > When sending a message I had and I have the following error: transport > interrupted TLS initialization failed. > When receiving messages from Yahoo or Free mailboxes I have the error: > unable to connect to server pop. the server immediately terminated the > connection. > After research the problem seems to come from SSL and precisely SSL in Debian > SID is migrating to SSL3. I use Kontact (similar to kmail) on Debian/sid, updated today and I don't have any issue with smtp.free.fr or imap.free.fr Free recommends to use STARTTLS on smtp connection [1]. Could check your configuration ? All the best PS: this reply is posted via smtp.free.fr [1] https://assistance.free.fr/articles/configurer-de-maniere-avancee-votre-logiciel-de-messagerie-609
Bug#1009023: libconfig-model-dpkg-perl: warning output suggests incorrect config filename
On Wednesday, 6 April 2022 07:57:45 CEST you wrote: > I think this should be "fill.copyright.blanks.yml" (the suggested filename > didn't work). You're right. I've fixed this message. The commit is now in git and will be part of next release. Thanks for the report. All the best
Bug#1008151: RM: perl6 -- ROM; perl6 replaced by raku
Package: ftp.debian.org Severity: normal Hi Perl6 language was renamed Raku. Hence perl6 metapackage is now replaced by raku. Hence this removal. All the best Dod
Bug#1008111: RM: perl6-zef -- ROM; replaced by raku-zef following Perl6 rename to Raku
Package: ftp.debian.org Severity: normal Hi Perl6 was renamed to Raku, so I'm (slowly) renaming perl6 package to raku packages. perl6-zef is now superseded by raku-zef. All the best Dod
Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?
Hi On Monday, 21 March 2022 09:57:59 CET Thorsten Leemhuis wrote: > Dominique/Salvatore/Eric, what's the status of this regression? > According to the debian bug tracker the problem is solved with 5.16 and > 5.17, but was 5.15 ever fixed? I don't think so. On kernel side, the commit fixing this issue is e55a3aea418269266d84f426b3bd70794d3389c8 . According to the logs of [1] , this commit landed in v5.17-rc3 HTH [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?
On Sunday, 20 February 2022 17:36:20 CET Salvatore Bonaccorso wrote: > Okay great :). This commit landed in 5.16.8 for the 5.16.y series. I > did upload 5.16.10-1 (but the signed packages are yet missing). Can > you test this one to confirm the issue is fixed? I confirm that suspend works fine with: Linux ylum 5.16.0-2-amd64 #1 SMP PREEMPT Debian 5.16.10-1 (2022-02-18) x86_64 GNU/Linux All the best
Bug#1002496: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled
On Wednesday, 9 February 2022 19:36:16 CET Chris Lamb wrote: > > Unfortunately, the build of perl6-zef with cowbuilder is already broken > > with cowbuilder. The nonexistant home dir leads to build failures. > > Ah, shame. Although I wasn't experiencing a build failure, I was > getting the same or similar warnings when building "perl6-readline". Sorry, I got confused. The pre-compilation phase works fine with HOME set to a non-existent directory. On the other hand, zef tests require a writable HOME directory. I've changed dh_raku_test to set HOME to debian/tmp/home (and cleanup afterwards). With these changes, perl6-zef builds without problems. This does not change the reproducible build issue. All the best Dod
Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?
On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote: > Does the system actually suspend? Not really. The screens looks like it's going to suspend, but it does come back after 10s or so. The light mounted in the middle of the power button does not switch off. > Is this system S0i3 or regular S3? I'm not sure how to check that. After a bit of reading on the Internet [1], I hope that the following information answers that question. Please get back to me if that's not the case. Looks like my system supports both Soi3 and S3 $ cat /sys/power/state freeze mem disk I get the same result running these 2 commands as root: # echo freeze > /sys/power/state # echo mem > /sys/power/state > Does this patch help by any chance? > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i > d=e55a3aea418269266d84f426b3bd70794d3389c8 yes, with this patch: - the suspend issue is solved - kernel logs no longer show messages like "failed to send message" or "*ERROR* suspend of IP block failed" while suspending All the best [1] https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/ hibernate-issues
Bug#1005005: linux-image-5.15.0-3-amd64: suspend failure with admgpu
On Fri, 11 Feb 2022 08:58:51 +0100 Dominique Dumont wrote: > Now I need to investigate whether the failed suspend or kernel message are > related to my external usb device (a usb-c hub with LAN and HDMI output). They are not. I get the same behavior and kernel messages on 5.15.0-3 without the usb-c device. All the best
Bug#1005005: linux-image-5.15.0-3-amd64: suspend failure with admgpu
On Tuesday, 8 February 2022 08:11:46 CET Salvatore Bonaccorso wrote: > Does this help? It did: $ git bisect good 3c196f0510912645c7c5d9107706003f67c3 is the first bad commit commit 3c196f0510912645c7c5d9107706003f67c3 Author: Alex Deucher Date: Fri Nov 12 11:25:30 2021 -0500 drm/amdgpu: always reset the asic in suspend (v2) [ Upstream commit daf8de0874ab5b74b38a38726fdd3d07ef98a7ee ] If the platform suspend happens to fail and the power rail is not turned off, the GPU will be in an unknown state on resume, so reset the asic so that it will be in a known good state on resume even if the platform suspend failed. v2: handle s0ix Acked-by: Luben Tuikov Acked-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Note that the amdgpu error message and kernel warnings are always shown in kernel logs. They are not related to the failing suspend. Now I need to investigate whether the failed suspend or kernel message are related to my external usb device (a usb-c hub with LAN and HDMI output). All the best
Bug#1002496: dh-perl6 vs. dh-raku: reproducibility issues with vendor/precompiled
On Thursday, 27 January 2022 19:40:14 CET Chris Lamb wrote:
> It probably isn't a good idea that Debian package builds inherits anything
> from the build user's home directory anyway, so the following should be
> okay:
>
> --- a/dh_raku_build
> +++ b/dh_raku_build
> @@ -39,6 +39,7 @@ foreach my $pkg (getpackages()) {
> --from=. --to=debian/tmp/pre-compiled!;
> doit({
> update_env => {
> +HOME => "/nonexistent",
> RAKUDO_RERESOLVE_DEPENDENCIES => 0,
> }
> },@cmd);
Unfortunately, the build of perl6-zef with cowbuilder is already broken with
cowbuilder. The nonexistant home dir leads to build failures.
I get a lot of warnings like:
WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you
can mark it as handled by calling .Bool, .so, .not, or .defined methods. The
Failure was:
Failed to create directory '/nonexistent/.raku/short' with mode '0o777': Failed
to mkdir: No such file or directory
in sub MAIN at /usr/bin/prove6 line 3
in block at /usr/bin/prove6 line 1
And the build fails with:
===SORRY!=== Error while compiling
/usr/lib/perl6/vendor/sources/B4401FC2C8E71132AE0D3CE2C47A7D2FBB0D50F1
Could not find Getopt::Long in:
inst#/nonexistent/.raku
inst#/usr/lib/perl6/site
inst#/usr/lib/perl6/vendor
inst#/usr/lib/perl6/core
ap#
nqp#
perl5#
at /usr/lib/perl6/vendor/sources/B4401FC2C8E71132AE0D3CE2C47A7D2FBB0D50F1:2
dh_raku_test: error: /usr/bin/prove6 -l -v returned exit code 1
All the best
Bug#1005005: linux-image-5.15.0-3-amd64: suspend failure with admgpu
On Tuesday, 8 February 2022 08:11:46 CET Salvatore Bonaccorso wrote: > > > (5.16.7-1 should land soon as well). > > > I'll try it when it's available 5.16.7-1 is also broken > > > Any chance > > > you can bisect the commit introducing the issue? > Some help is here: > > https://wiki.debian.org/DebianKernel/GitBisect > > and > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html > > Does this help? Yes. I should be able to bisect this issue. All the best
Bug#1005005: linux-image-5.15.0-3-amd64: suspend failure with admgpu
On Saturday, 5 February 2022 21:25:03 CET Salvatore Bonaccorso wrote: > Does the issue persist if you upgrade to the most recent 5.16.y > version? 5.16.4-1~exp1 yes > (5.16.7-1 should land soon as well). I'll try it when it's available > Any chance > you can bisect the commit introducing the issue? It's been a while since I've compiled my own kernel. Do you have a documentation that explains the process to compile a kernel (or only module amdgpu) using Debian config ? All the best
Bug#1005005: linux-image-5.15.0-3-amd64: suspend failure with admgpu
Package: src:linux Version: 5.15.15-2 Severity: normal Tags: upstream Dear Maintainer, Since upgrade to linux-image-5.15.0-3-amd6, suspending my machine no longer works correctly: the screen goes blank as usual, but comes back after 10s or so. The most relevant kernel logs are: [ 257.531771] PM: suspend entry (s2idle) [ 257.610570] Filesystems sync: 0.078 seconds [ 257.610723] (NULL device *): firmware: direct-loading firmware regulatory.db [ 257.610726] (NULL device *): firmware: direct-loading firmware regulatory.db.p7s [ 257.610745] (NULL device *): firmware: direct-loading firmware intel/ibt-17-16-1.ddc [ 257.610954] (NULL device *): firmware: direct-loading firmware intel/ibt-17-16-1.sfi [ 257.610986] (NULL device *): firmware: direct-loading firmware iwlwifi-9000-pu-b0-jf-b0-46.ucode [ 257.611211] (NULL device *): firmware: direct-loading firmware i915/kbl_dmc_ver1_04.bin [ 257.726247] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 257.728699] OOM killer disabled. [ 257.728700] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 257.730085] printk: Suspending console(s) (use no_console_suspend to debug) [ 257.839817] amdgpu: last message was failed ret is 65535 [ 257.839842] amdgpu: failed to send message 261 ret is 65535 [ ... lots of failed message ...] [ 257.840748] [ cut here ] [ 257.840751] WARNING: CPU: 4 PID: 58 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2014 dm_suspend+0x19e/0x1c0 [amdgpu] [ 257.841665] Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_counter xt_addrtype nft_compat nf_tables libcrc32c nfnetlink br_netfilter bridge stp llc xfrm_user xfrm_algo nvme_fabrics typec_displayport cmac algif_hash algif_skcipher af_alg overlay bnep binfmt_misc nls_ascii nls_cp437 squashfs vfat fat loop x86_pkg_temp_thermal intel_powerclamp mei_hdcp snd_sof_pci_intel_cnl coretemp dell_rbtn intel_rapl_msr snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci kvm_intel snd_sof_xtensa_dsp snd_hda_codec_hdmi snd_sof soundwire_bus btusb btrtl kvm snd_ctl_led snd_soc_skl btbcm btintel dell_laptop irqbypass iwlmvm snd_soc_hdac_hda rapl bluetooth snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_codec_realtek snd_soc_acpi_intel_match snd_soc_acpi dell_smm_hwmon snd_hda_codec_generic intel_cstate ledtrig_audio mac80211 snd_soc_core [ 257.841816] dell_wmi intel_uncore snd_compress dell_smbios jitterentropy_rng dcdbas snd_hda_intel sha512_ssse3 serio_raw pcspkr libarc4 snd_intel_dspcfg sha512_generic efi_pstore dell_wmi_descriptor uvcvideo snd_intel_sdw_acpi iwlwifi snd_usb_audio snd_hda_codec dell_wmi_sysman videobuf2_vmalloc videobuf2_memops firmware_attributes_class iTCO_wdt videobuf2_v4l2 intel_pmc_bxt snd_hda_core drbg iTCO_vendor_support snd_usbmidi_lib videobuf2_common intel_wmi_thunderbolt wmi_bmof ee1004 watchdog snd_hwdep ansi_cprng joydev snd_rawmidi hid_multitouch videodev cfg80211 snd_seq_device mc snd_pcm processor_thermal_device_pci_legacy processor_thermal_device snd_timer processor_thermal_rfim processor_thermal_mbox ucsi_acpi processor_thermal_rapl snd mei_me typec_ucsi intel_rapl_common ecdh_generic roles soundcore mei ecc rfkill intel_soc_dts_iosf intel_pch_thermal typec int3403_thermal evdev int340x_thermal_zone dell_smo8800 intel_hid int3400_thermal intel_pmc_core acpi_thermal_rel acpi_pad [ 257.841935] sparse_keymap ac parport_pc ppdev sunrpc lp parport fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt dm_mod hid_jabra usbhid r8152 mii hid_generic amdgpu i915 rtsx_pci_sdmmc mmc_core crc32_pclmul crc32c_intel ghash_clmulni_intel gpu_sched nvme aesni_intel e1000e crypto_simd cryptd nvme_core i2c_algo_bit drm_ttm_helper ptp t10_pi ttm psmouse pps_core xhci_pci i2c_i801 drm_kms_helper thunderbolt crc_t10dif xhci_hcd cec i2c_smbus rc_core crct10dif_generic crct10dif_pclmul crct10dif_common rtsx_pci drm usbcore i2c_hid_acpi intel_lpss_pci i2c_hid intel_lpss idma64 usb_common hid wmi battery button video [ 257.842049] CPU: 4 PID: 58 Comm: kworker/u16:7 Not tainted 5.15.0-3-amd64 #1 Debian 5.15.15-2 [ 257.842057] Hardware name: Dell Inc. Precision 3540/0M14W7, BIOS 1.9.1 07/06/2020 [ 257.842062] Workqueue: events_unbound async_run_entry_fn [ 257.842075] RIP: 0010:dm_suspend+0x19e/0x1c0 [amdgpu] [ 257.842795] Code: ff 31 d2 4c 89 e6 4c 89 ef e8 4e d7 15 00 83 f8 01 74 1e 89 c2 48 c7 c6 40 36 f5 c0 48 c7 c7 50 bc 01 c1 e8 14 89 61 ff eb c2 <0f> 0b e9 95 fe ff ff 4c 89 e6 4c 89 ef e8 60 26 15 00 eb ae e8 d9 [ 257.842801] RSP: 0018:ac778029fcf0 EFLAGS: 00010286 [ 257.842808] RAX: RBX: 9e72cb1b5b08 RCX: 0027 [ 257.842812] RDX: 0009 RSI:
Bug#1004206: libconfig-model-dpkg-perl: update-my-copyright-year duplicates single year
On Saturday, 22 January 2022 19:30:05 CET you wrote: > -Copyright: 2022, gregor herrmann > +Copyright: 2022, 2022, gregor herrmann I can't believe I missed this simple test case ... Thanks for the report. Dod
Bug#1003159: dh-raku: please make the contents of "$pkg.dh-raku.list" files reproducible
On Wed, 05 Jan 2022 11:52:06 + "Chris Lamb" wrote: > However, we can easily fix the dh-raku.list files. For that, please > see and apply the attached patch. Applied. This fix will be part of next dh-raku release. Thanks for the patch. Dod
Bug#992649: run-parts in /usr/bin breaks systemd-cron
On Sun, 2 Jan 2022 19:03:28 +0100 Alexandre Detiste wrote: > ./configure --runparts="/usr/bin/env run-parts" The changelog of debianutils 5.0-1 (Aug 2021) shows: * Move run-parts to /usr/bin I guess there are 2 ways to fix this. Either a compat link (or a script with a deprecation warning) should be provided by debianutils as /bin/run-parts or systemd-cron should be modified to use /usr/bin/run-parts. What's preventing such a fix ? Note that locate is also impacted by this bug : $ locate foobarbaz locate: warning: database ‘/var/cache/locate/locatedb’ is more than 8 jours old (actual age is 135,0 jours) All the best Dod
Bug#764901: linux-image-3.16-2-amd64: Suspend results in shutdown
On Friday, 7 January 2022 12:29:21 CET Diederik de Haas wrote: > You went to all that trouble to find a 7+ year old bug, with a title that > doesn't convey a link with dkms compilation issue, unarchive the bug and > respond to that, but you missed the (1st) response of a kernel maintainer? Not exactly. I'm stumbled upon this bug while upgrading an old system in production. I did not dare reboot the system without fixing initramfs creation. This bug report actually gave me a hint that dkms could help, so I've added the work-around I've found to this bug report. I hope this will save some time to the next ops that will have to upgrade a Debian 7 production system in vmware. All the best
Bug#764901: linux-image-3.16-2-amd64: Suspend results in shutdown
On Sat, 11 Oct 2014 21:44:53 -0600 David Zundel wrote: > Attempted re-installation of linux-image-3.16-2-amd64 generates an error > report: > Error! Bad return status for module build on kernel: 3.16-2-amd64 > (x86_64) > Consult /var/lib/dkms/open-vm-tools/2012.05.21/build/make.log for more > information. I've seen this problem while upgrading a Debian 7 machine to Debian 8 (don't ask...): update-initramfs: deferring update (trigger activated) Paramétrage de linux-image-3.16.0-6-amd64 (3.16.56-1+deb8u1) ... /etc/kernel/postinst.d/dkms: Error! Bad return status for module build on kernel: 3.16.0-6-amd64 (x86_64) Consult /var/lib/dkms/open-vm-tools/2012.05.21/build/make.log for more information. /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-3.16.0-6-amd64 /etc/kernel/postinst.d/zz-update-grub: GRUB >= 2.00 has been unpacked but not yet configured. grub-mkconfig will not work until the upgrade is complete. It should run later as part of configuring the new GRUB packages. Turns out that the compilation failure happens because dkms is trying to compile the Debian 7 version of open-vm-tools (2012.05.21) with Debian 8 kernel (3.16.0-6). dkms shows that both versions of open-vm-tools are present: $ sudo dkms status open-vm-tools, 2012.05.21, 3.2.0-6-amd64, x86_64: installed open-vm-tools, 9.4.6, 3.16.0-6-amd64, x86_64: installed I don't know if there's a bug with dkms or open-vm-tools which trigger a compilation of old open-vm-tools with newer kernel, but removing the old open-vm-tools from dkms does solve this issue: $ sudo dkms remove -m open-vm-tools -v 2012.05.21 --all Uninstall Beginning Module: open-vm-tools Version: 2012.05.21 Kernel: 3.2.0-6-amd64 (x86_64) - [...] $ sudo dkms status open-vm-tools, 9.4.6, 3.16.0-6-amd64, x86_64: installed At this point, the following command finishes the module compilation without problem: $sudo dpkg-reconfigure linux-image-3.16.0-6-amd64 /etc/kernel/postinst.d/initramfs-tools: [...] HTH
Bug#1002782: libconfig-model-backend-augeas-perl: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 255
On Tuesday, 28 December 2021 21:16:18 CET you wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. Ack. These tests are broken by augeas 1.13.0. I'll fix this upstream. Thanks for the report. Dod
Bug#1002828: lintian: please add rakudo as known interpreter
Package: lintian Version: 2.114.0 Severity: normal Dear Maintainer, When building prove6 package, lintian issues this warning: W: prove6: unusual-interpreter /usr/bin/raku [usr/bin/prove6] /usr/bin/raku is Raku (formely Perl6) interpreter provided by rakudo package. Could you add raku to the list of known interpreters ? All the best Dod -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.37-10 ii bzip2 1.0.8-5 ii diffstat1.64-1 ii dpkg1.21.1 ii dpkg-dev1.21.1 ii file1:5.41-2 ii gettext 0.21-4 ii gpg 2.2.27-3 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.40 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.27-1 ii libconst-fast-perl 0.014-1.1 ii libcpanel-json-xs-perl 4.27-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-1 ii libdevel-size-perl 0.83-1+b2 pn libdigest-sha-perl ii libdpkg-perl1.21.1 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libio-interactive-perl 1.023-1 ii libio-prompt-tiny-perl 0.003-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.005004-3 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.120-1 ii libperlio-gzip-perl 0.19-1+b7 ii libperlio-utf8-strict-perl 0.008-1+b1 ii libproc-processtable-perl 0.634-1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libsort-versions-perl 1.62-1 ii libsyntax-keyword-try-perl 0.26-1 ii libterm-readkey-perl2.38-1+b2 ii libtext-glob-perl 0.11-2 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.13-1 ii libtext-xslate-perl 3.5.9-1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.10-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.83+ds-1 ii lzip1.22-4 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.32.1-6 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.60-1 -- no debconf information
Bug#1002692: need permanent tracker for rakudo
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi I'm currently changing the way Raku (aka Perl6) modules are built. The build process involves creating pre-compiled files (a bit like pyc files for Python). These files used to be created at installation time. I'm experimenting with package perl6-readline to perform the pre-compilation at build time. The main drawback is that pre-compiled files depend on the version of rakudo that did the compilation. All Raku modules must be rebuilt when a new verions of rakudo is built. Like Perl, Rakudo now provides a virtual package with an api version. For instance: Provides: raku-api-2021.09 And perl6-readline depends on raku-api-2021.09 To trigger the rebuild of Raku modules, I'd like you to set up a permanent tracker with the following Ben file: title = "Rakudo"; is_affected = .depends ~ /^raku-api-/; is_good = !.edos-debcheck ~ /uninstallable/; is_bad = .edos-debcheck ~ /uninstallable/; Is it possible ? All the best Dod
Bug#1002496: perl6-readline: Strange files under /usr/lib/perl6/vendor/dist?
Hi On Thursday, 23 December 2021 10:19:50 CET Chris Lamb wrote: > The latest version of perl6-readline seems to ship a number of > interesting-looking files under /usr/lib/perl6/vendor, such as: > > /usr/lib/perl6/vendor/dist/A8475E6287F45455F9F68569C07ADC25AA5BEFDF > > Is this some kind of .pyc equivalent for Perl 6? Either way, I'd love > to know more as these files appear to be unreproducible. Yes, theses are Raku modules pre-compiled at build time. A more detailed explanation is provided on Debian wiki: https://wiki.debian.org/Perl6PreCompProposal I don't really know why the pre-compilation is not reproducible. As a matter of fact, neither rakudo, nqp or moarvm are reproducible. I've never found the time or energy to find why. All the best Dod
Bug#892058: Your Debian key is expiring
On Thursday, 16 December 2021 04:59:12 CET you wrote: > If you like this service, please leave a favorable comment here [2]. Thanks for the heads-up. I would probably have forgotten to renew my key without this reminder. All the best
Bug#1001045: libconfig-model-dpkg-perl: scan-copyright reports empty license
On Monday, 13 December 2021 08:32:17 CET you wrote: > Checked with licensecheck version v3.1.1 and v3.2.14. Unknown license is > reported for Bitstream license file. ok, so the bug lies with licensecheck. Could you check whether licensecheck has a similar bug report ?
Bug#1001045: libconfig-model-dpkg-perl: scan-copyright reports empty license
On Fri, 03 Dec 2021 10:01:05 +0530 Vignesh Raman wrote: > scan-copyrights does not recognize bitstream license and empty license is reported > for fonts-dejavu (https://packages.debian.org/bullseye/fonts-dejavu). Could you check if licensecheck finds the correct information in these files ? (cme relies on licensecheck output to create the copyright data. So if licensecheck fails to retrieve copyright data, cme will output lackluster copyright information) All the best
Bug#960681: Bug#513967:l icensecheck: fails to detect license at end (option --tail is broken)
On Saturday, 20 November 2021 11:15:59 CET Jonas Smedegaard wrote: > I would appreciate some numbers about actual slowdown. Fair enough. Here are some measurements where the cell content is the "real" time given by time command. This table is to be viewed with a monospace font. licensecheck command is: ┌ │ licensecheck --lines 0 --encoding utf8 --copyright --machine --shortname-scheme=debian,spdx --recursive . └ This is also the command used internally by cme. ━━━ package plain cme with licensecheck licensecheck cmelines=0 with lines=0 ─── pan 0m2.694s 0m6.553s 0m4.571s 0m9.303s moarvm 0m3.768s 0m41.772s 0m3.900s 0m40.274s nqp 0m3.057s 0m3.635s 0m3.682s 0m9.955s rakudo 0m3.448s 0m9.784s 0m11.358s 0m17.517s systemd 4m30.489s 4m59.546s 4m31.644s 5m2.661s ━━━ The result is surprising as using --lines 0 can be lead to similar time or 10 times longer... cme can take less time because more files are skipped. All the best
Bug#960681: Bug#513967:l icensecheck: fails to detect license at end (option --tail is broken)
On Thu, 12 Apr 2018 23:26:53 +0200 Jonas Smedegaard wrote: > It is (slower but) more reliable to use "--lines 0". Indeed. I have a similar case with #1000179 where licensecheck does not get copyright assignment from a LICENSE file: $ licensecheck --copyright LICENSE LICENSE: *No copyright* Apache License 2.0 But it gets the copyright with --lines option: $ licensecheck --copyright LICENSE -l 0 LICENSE: Apache License 2.0 [Copyright: patent, trademark, and / license to reproduce, prepare Derivative Works of, / License. Subject to the terms and conditions of / 2017 Sourced Technologies S.L.] Would it be possible to use --lines 0 with files containing a lot of capital letters (like LICENSE.* README*) and so on... These files tend to be relatively short compared to other source files. HTH
Bug#1000179: cme update dpkg-copyright should detect cpoyright holders for apache license
On Fri, 19 Nov 2021 17:47:09 +0100 Dominique Dumont wrote: > $ licensecheck LICENSE > LICENSE: *No copyright* Apache License 2.0 See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960681 This bug indicated a work-around that set --lines 0 option so that licensechecl parses the whole file I'm reluctant to set --lines 0 option when calling licensecheck as this could really slow down copyright update (which is already not that fast on big packages) All the best
Bug#1000179: cme update dpkg-copyright should detect cpoyright holders for apache license
Hi Unfortunately, cme dpkg relies on licensecheck to get copyright info from files. licensecheck does not detect the copyright statement from LICENSE file: $ licensecheck LICENSE LICENSE: *No copyright* Apache License 2.0 In this case, cme assumes this is a plain license file and skips this file hence you get no information for golang-github-go-git-go-billy For the record, golang-github-go-git-go-billy can be found there: https://salsa.debian.org/go-team/packages/golang-github-go-git-go-billy All the best
Bug#996998: libconfig-model-dpkg-perl: scan-copyrights fails for package rust-coreutils
On Wednesday, 3 November 2021 07:28:52 CET you wrote: > I'm facing an issue where I'm unable to find a good and bad commit in > one distribution. > > *Bullseye:* > Updated libconfig-model-dpkg-perl from 2.143 to 2.153 and the crash was > still seen. > *Bookworm:* > Downgraded libconfig-model-dpkg-perl from 2.153 to 2.143 and it worked fine. > The original error message is: "toml parse error at line 253: expected key- value pair, table, or array of tables but got bool". cme with dpkg uses Toml::Tiny. The command "apt-cache policy libtoml-tiny-perl" shows that bullseye has version 0.11 and unstable has version 0.15. Toml::Tiny change log shows that version 0.14 has a lot of bug fixes. I guess that the issue you've seen is fixed by Toml::Tiny 0.14 All the best
Bug#996998: libconfig-model-dpkg-perl: scan-copyrights fails for package rust-coreutils
On Friday, 29 October 2021 14:48:29 CEST you wrote: > Please could you provide the commit which fixes the crash with > rust-coreutils package. Thank you. I'm not sure which commit did fix this issue. I'll let you bisect libconfig-model-dpkg-perl. All the best
Bug#996998: libconfig-model-dpkg-perl: scan-copyrights fails for package rust-coreutils
On Thursday, 28 October 2021 08:32:02 CEST you wrote: > Thanks for checking. Please could you try with the sources from > https://packages.debian.org/experimental/rust-coreutils I've got no crash with libconfig-model-dpkg-perl 2.153. Although I see a lot of entries with unknown licenses: Files: src/uucore/src/lib/features/process.rs Copyright: Maciej Dziardziel / Jian Zeng License: UNKNOWN Files: src/uucore/src/lib/features/signals.rs Copyright: Maciej Dziardziel License: UNKNOWN Files: src/uucore/src/lib/features/wide.rs Copyright: Peter Atashian License: UNKNOWN Files: src/uucore/src/lib/mods/* Copyright: Rolf Morel License: UNKNOWN I need to check whether all toml files are parsed, or just the top level one. In any case, you need to upgrade libconfig-model-dpkg-perl All the best
Bug#997838: ITP: libdist-zilla-plugin-signature-perl -- sign releases with Module::Signature
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-signature-perl Version : 1.100930 Upstream Author : Graham Barr * URL : https://metacpan.org/release/Dist-Zilla-Plugin-Signature * License : perl Programming Lang: Perl Description : sign releases with Module::Signature Dist::Zilla::Plugin::Signature will sign a distribution using Module::Signature. This plugin should appear after any other AfterBuild plugin in your dist.ini file to ensure that no files are modified after it has been run The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
