On Wed, 23 Apr 2025 09:34:34 + (UTC) Thorsten Alteholz
wrote:
> I am not really sure why you request the removal of an arch:all package from
a specific architecture.
I admit I'm quite confused about the removal from specific arch process.
Anyway, I logged this bug because https://tracker.d
Source: planner
Version: 0.14.92-1
Severity: minor
Dear Maintainer,
When running
$ apt show planner
I get:
Homepage: https://wiki.gnome.org/action/show/Apps/Planner
Which is invalid.
The correct URL is https://wiki.gnome.org/Apps/Planner
Could you fix your control file ?
All the best
--
Hi
On Wednesday, 23 April 2025 10:11:46 Central European Summer Time Emanuele
Rocca wrote:
> On 2025-04-23 09:55, Dominique Dumont wrote:
> > Currently, moarvm and nqp packages have a bug on arm that can't be
> > reproduced. This bug triggers a random crash and can trip buil
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: r...@packages.debian.org, debian-...@lists.debian.org,
debian-...@lists.debian.org
Control: affects -1 + src:raku
User: ftp.debian@packages.debian.org
Usertags: remove
User: debian-...@lists.debian.org
Usertags: arm64 armel armhf
User: deb
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pro...@packages.debian.org, debian-...@lists.debian.org,
debian-...@lists.debian.org
Control: affects -1 + src:prove6
User: ftp.debian@packages.debian.org
Usertags: remove
User: debian-...@lists.debian.org
Usertags: arm64 armel armhf
User:
On Friday, 18 April 2025 11:34:55 Central European Summer Time you wrote:
> I found the answer which is yes.
I was wrong.
The problems comes from all raku modules package which are Architecture: any.
(sigh.. they used to be arch all).
Anyway, all these packages (19) must be removed from all arm
On Monday, 7 April 2025 16:08:16 Central European Summer Time Walter Lozano
wrote:
> Thank you! I have skipped the problematic files in my setup, but I was I
> wanted to share this with you in case you have a better approach.
On second thought, we can assume that a corrupted file would be upstrea
On Sunday, 6 April 2025 18:14:32 Central European Summer Time you wrote:
> Is it possible that you haven't pushed your changes to the salsa
> repo?
Arg... yes... sorry about that.
I've just pushed my changes.
All the best
On Thursday, 3 April 2025 18:03:59 Central European Summer Time you wrote:
> While running scan-copyrights on eslint the following error is triggered:
>
> malformed JSON string, neither tag, array, object, number, string or atom,
> at character offset 0 (before "\x{feff}{\n"priv...") at
> /usr
On Thursday, 3 April 2025 17:32:26 Central European Summer Time you wrote:
> toml syntax error on line 6ensecheck
> -->| invalid-value
>
> This seems to be caused by the following files which are part of internal
> test with invalid data:
>
> - src/tools/cargo/tests/testsuite/cargo_add/in
On Thursday, 3 April 2025 17:27:52 Central European Summer Time you wrote:
> Jelmer Vernooij vs Jelmer Vernooij, note ij vs ij, making the merge of
> copyrights fail.
Bugs comes from Sofware::Copyright where I used NFKD function instead of NFC.
I'll fix this upstream.
All the best
On Thursday, 3 April 2025 19:26:19 Central European Summer Time you wrote:
> Source: libconfig-model-itself-perl
> Version: 2.023-1
> Severity: serious
> Tags: ftbfs trixie sid
> Justification: we love autopkgtests; blocks libpath-tiny-perl's migration
It's indeed an issue with new version of Path
Hi
On Wednesday, 12 March 2025 13:28:24 Central European Summer Time Dominique
Dumont wrote:
> moarvm was removed from testing and unstable on arm*. Now nqp and
> rakudo must also be removed.
Any news on this removal request ?
All the best
On Thursday, 27 March 2025 02:45:09 Central European Standard Time you wrote:
> I had been seeing an odd order for fields in several packages I've
> been fixing lately and was wondering what had caused those. Today
> after seeing a commit with tool attribution I realized it was
> «cme fix» performi
On Thursday, 27 March 2025 02:23:44 Central European Standard Time you wrote:
> I've been noticing and fixing lately several packages where they had
> instances of «Debian GNU» which looked rather odd. I just realized now
> that it looks like «cme fix» might have introduced those!
Indeed.
> I thi
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: n...@packages.debian.org, debian-...@lists.debian.org,
debian-...@lists.debian.org
Control: affects -1 + src:nqp
User: ftp.debian@packages.debian.org
Usertags: remove
User: debian-...@lists.debian.org
Usertags: arm64 armel armhf
User: debi
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: rak...@packages.debian.org, debian-...@lists.debian.org,
debian-...@lists.debian.org
Control: affects -1 + src:rakudo
User: ftp.debian@packages.debian.org
Usertags: remove
User: debian-...@lists.debian.org
Usertags: arm64 armel armhf
User:
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: moa...@packages.debian.org, debian-...@lists.debian.org,
debian-...@lists.debian.org
Control: affects -1 + src:moarvm
User: ftp.debian@packages.debian.org
Usertags: remove
User: debian-...@lists.debian.org
Usertags: arm64 armel armhf
User:
Hi Andreas,
Thank you for your help with the package. Please feel free to assign
the maintainership to a team of your choice.
Best
-Dominique
On Fri, Mar 7, 2025 at 4:30 AM Andreas Tille wrote:
> Source: django-tastypie
> Version: 0.13.3-1.1
> Severity: important
> X-Debb
Hi
On Saturday 1 February 2025 23:12:43 CET you wrote:
> I saw that there is libuv1 1.49.2 in experimental.
> May I know whether the plan is to have it in unstable/testing soon?
> Bug 1073595 has been blocking works on ocaml-luv and haxe.
I've uploaded 1.50.0 in unstable.
All the best
On Mon, 20 Jan 2025 09:26:28 +0100 Ondřej Surý wrote:
> Could you
> please update the version in unstable, so this end up in trixie. We hope this
> could give the BIND 9 a boost in authoritative performance as it will avoid
> the uv_udp_send() callbacks and still use sendmmsg() internally.
Unfo
On Mon, 13 Jan 2025 16:05:15 -0300 Walter Lozano
wrote:
> As a workaround I have used
> [snip]
>
> but hopefully you will provide a better solution.
Thanks for the suggestion.
I've done a similar modification to fix this problem.
All the best
On Thursday, 26 December 2024 13:52:02 CET Walter Lozano wrote:
> I see, thanks for clarifying. I wonder if there is a kind of
> specification which mentions that copyright notice should be utf-8 or if
> it is just the common case.
AFAIK, there's no specification. But this makes licensecheck and c
Hi
This failure is due to a combination of issues.
Some author of texlive-extra got creative to specify their copyright years:
- 2023 -20** by Romain NOEL
- 2011-.. Maïeul Rouquette
This leads to error when parsing copyright ranges and this triggers the error
you've seen.
I'll change Softwar
On Saturday, 30 November 2024 12:04:41 CET Timo Paulssen wrote:
> Dear Gianfranco, I will have to ask you to delay, or maybe cancel, this
> NMU. Please read on if you would like to know the reasoning:
Timo, I think Gianfranco is not subscribed to
pkg-rakudo-de...@alioth-lists.debian.net, so he pr
Dominique Martinet wrote on Wed, Nov 20, 2024 at 11:17:26AM +0900:
> Looking further into the configure arguments, I've trimmed down the
> difference to --disable-pie: just adding that flag makes my hand build
> reproduce this.
Ah, I just remembered why I wanted to build manuall
tem part of the dpkg build does leave pie on so there must have
been a reason?)
> Yes, that's what I'd love to see more closely. Please give me a few
> days now once you've a working solutions (many of them actually), -
> I'm on a business trip now, will have a closer look when I'll return.
No hurry here, I've just been feeding my curiosity.
The two open questions I had left yesterday are now solved so I'll leave
the resolution to you on your own time.
Cheers,
--
Dominique
Package: qemu-user-static
Version: 1:7.2+dfsg-7+deb12u7
Severity: important
Dear Maintainer,
After upgrading my system from linux 6.1.99 to linux 6.1.112 I've
started seeing segfaults in aarch64 containers running software builds.
The following reproduces a segfault almost consistently on two of
On Friday, 1 November 2024 12:53:38 CET Emilio Pozuelo Monfort wrote:
> This is preventing the ongoing transition from completing. Just retrying the
> build until it happens to finish is not a good solution in case future
> updates need to happen, particularly for security updates.
Agreed.
I'll l
On Tuesday, 29 October 2024 09:09:41 CET you wrote:
> Go ahead.
Done.
Thanks for the quick reply
All the best
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: rak...@packages.debian.org
Control: affects -1 + src:rakudo
User: release.debian@packages.debian.org
Usertags: transition
Hi
rakudo and its sibling packages (moarvm and nqp) have an API that
change at every release. This requires a re
Confirmed. wormhole is also broken on my system.
Note that upstream version is now 0.16.0
All the best
Hi
In my case, I have to remove the /usr/lib/x86_64-linux-gnu/libssl.so.1.1
file which was pending to solve the problem.
This file was manually installed.
Have a nice day
Regards
Dominique
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
Hi,
configure already provide the --enable/disable-gtk2 flag that is on by default.
But of course if someone can port that interface to GT3 or later, it would be
great. So I let that bug open.
--
Reply to this email directly or view it on GitHub:
https://github.com/alsaplayer/alsaplayer/iss
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 ?
e (in lib/Config/Model/Dpkg/Dependency.pm)
> /usr/share/dpkg/ostable or Dpkg::Arch's get_valid_arches() instead of
> hardcoding architectures?
>
> What do you think, Dominique?
Well, ostable file does not mention loong64 arch.
And get_valid_arches returns quite a lot of architec
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
4G-:384M is
probably sensible?
(lowest value coming from ubuntu's settings, would need to test how much
is needed for a system with 384MB but I'd be reluctant to take half of
its ram for crashkernel)
> (I specify x86_64 because using 512M-:192M breaks crashkernel more on my i386
> testbeds.)
(Can't help about i386 though)
Thanks,
--
Dominique Martinet
at busybox also support as short
option only...), and I since hurried to forget about it)
--
Dominique Martinet | Asmadeus
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
need to look into why system gems cannot be
used with jruby...
--
Dominique Martinet | Asmadeus
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
Alberto Garcia wrote on Fri, Oct 20, 2023 at 04:19:55PM +0200:
> On Wed, Oct 18, 2023 at 05:06:16PM +0900, Dominique Martinet wrote:
> > After upgrading my system to the latest security updates surf no
> > longer displays anything.
>
> I had a look at this, the proble
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
something in the GPU acceleration code broke for small users of
webkitgtk...
I don't have much time to look further right now, but I'll keep looking
as time permits...
Thanks,
--
Dominique
Package: surf
Version: 2.0+git20201107-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: dominique.marti...@atmark-techno.com
Dear Maintainer,
After upgrading my system to the latest security updates surf no longer
displays anything.
The pages actually load, hovering on lin
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
On the server with sympa package, it takes more than 2 minutes when the
services are up !
---
# time /usr/sbin/needrestart
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No
Package: libnet-server-perl
Version: 2.013-1
Severity: normal
Dear Maintainer,
Each time there is a connection in Munin (using the lib-netserver-perl package
as tcp server),
a log is generated :
munin-node: Use of uninitialized value in numeric eq (==) at
/usr/share/perl5/Net/Server/Fork.pm lin
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
erly.
(I'd test the proposed package, but I do not have any stable system with
a destkop environment available right now, sorry)
Thank you for your time and explanations, I'll follow up on salsa unless
prompted here.
--
Dominique
Hi Simon,
Dominique Martinet wrote on Mon, Nov 28, 2022 at 11:47:07AM +0900:
> > I've added it to <https://wiki.debian.org/Gnome/BullseyeUpdates>.
>
> Thank you!
Just a follow-up on this proposed updates mechanism -- it looks like
this wasn't included in the de
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
Simon McVittie wrote on Fri, Nov 25, 2022 at 05:00:11PM +:
> On Thu, 29 Sep 2022 at 08:42:40 +0900, Dominique Martinet wrote:
> > when using GTK on platforms with a GLES-only GL implementation like some
> > raspberry pi or iMX platforms with vivante driver, GTK fails to
> &
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
Hi,
Dominique Martinet wrote on Thu, Sep 29, 2022 at 08:42:40AM +0900:
> when using GTK on platforms with a GLES-only GL implementation like some
> raspberry pi or iMX platforms with vivante driver, GTK fails to
> initialize its GL stack because it tries to bind to regular GL first
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
e, so just downgrading the requested version from
2 to 1 as follow fixes wev for me:
>From bdbad4e1e58d090654e2f5e804659bb8709f2f45 Mon Sep 17 00:00:00 2001
From: Dominique Martinet
Date: Wed, 5 Oct 2022 11:19:27 +0900
Subject: [PATCH] protocols: lower xdg_wm_base requirement to 1
We do not nee
ese logs?
I do not see anything on stdout/stderr with the gcc build, but I would
assume this to be logged elsewhere or perhaps only if some magic env var
is set?
Thanks,
--
Dominique
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
1 - 100 of 2179 matches
Mail list logo
