On Saturday, 31 August 2024 12:15:14 CEST you wrote:
> That would indeed be reproducible, but it has a few problems in that
> it make the patch not upstreamable, and it also might be misleading on
> Ubuntu (or any other Debian-derivative).
That's a good point.
Ok, then I'll apply this patch upstr
Hi
If that's ok with you, I'll set PLATFORM_INFO to "Debian" when
SOURCE_DATE_EPOCH is set.
This way, as upstream, I have a better hint of the origin of Pan when a user
reports a bug.
Thanks for the report.
All the best
On Wednesday, 7 August 2024 15:00:14 CEST you wrote:
> Source: pan
> Ver
Hello
On Thu, 22 Aug 2024 11:57:36 + wuruilong wrote:
> I have verified that the attached patch can be successfully compiled into a
package on the loongarch architecture, please merge the patch.
I've stepped down from rakudo maintenance.
Unfortunately, there's no volunteer to take over. I
On Thu, 4 Jul 2024 19:41:53 +0530 Praveen Arimbrathodiyil
wrote:
> XS-Ruby-Versions: all and XB-Ruby-Versions: ${ruby:Versions} are
> deprecated so cme/routine-update should remove those fields.
Are these parameters replaced by another parameter ?
Or should I simply drop them ?
All the best
On Mon, 1 Jul 2024 11:29:15 + Dimitrij Mijoski wrote:
> The latest upstream version now is v1.2024.5.
I use plantuml for work, I'll help on this package.
Andrei, could you push your latest modification to salsa ?
All the best
On Tue, 18 Jun 2024 08:56:43 +0200 julien.pu...@gmail.com wrote:
> After some poking around, they are declared in /usr/include/uv.h, but
> using objdump -T on /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0 doesn't
> show them.
This will be fixed upstream.
Can you wait for next libuv upstream release ?
On Sunday, 2 June 2024 02:53:49 CEST you wrote:
> On Sat, 01 Jun 2024 08:45:03 +, Francesco Ballarin wrote:
> > is it possible to add loong64 and riscv64 to the archs listed in
> > /usr/share/perl5/Config/Model/Dpkg/Dependency.pm
> > ?
>
> Maybe we should use (in lib/Config/Model/Dpkg/Dependen
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
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
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]
ht
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 -
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
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
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 advisor
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
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 t
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 v
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
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/
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
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
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-miss
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 c
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 doc
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 Softw
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 ret
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
htt
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 pr
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/li
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
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 sm
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
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 t
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 worka
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
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 experimenta
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 i
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 compute
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
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 whethe
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 t
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
Hi
piorunz, could you try the fix proposed there:
https://gitlab.gnome.org/GNOME/pan/-/merge_requests/41
All the best
Dod
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
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
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
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
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 Foun
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.
He
'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 thi
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' ha
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
r
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/precom
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
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/
C847F303DB03DE97DCB92EFEE90C0
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 wh
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/C847F303DB03DE9
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
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
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 t
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 versi
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 probl
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
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 t
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
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
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
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 spo
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 hav
p;& 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.
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_
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
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
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
> in
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
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
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
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
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 wit
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
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 r
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 witho
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/
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 @@ f
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/
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 i
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]
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
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
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) s
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 exa
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
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
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
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 cr
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 .p
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
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 ?
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 ?
(c
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 co
1 - 100 of 1205 matches
Mail list logo