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
close 1083153 0.3.7-1
thanks
remove build-dep on prove6
--
https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
close 1083150 0.0.2-3
thanks
removed build-dep on prove6
--
https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
close 1083149 0.0.7-4
thanks
removed build-dep on prove6
--
https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
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, 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
Control: tag -1 pending
Hello,
Bug #1061035 in libconfig-model-dpkg-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/perl-team/modules/packages/libconfig-mo
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
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
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 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
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 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 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
Control: tag -1 pending
Hello,
Bug #1016670 in libconfig-model-dpkg-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/perl-team/modules/packages/libconfig-mo
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
close 1015034 0.11
close 1015110 0.11
thanks
These bugs are fixed with 1015079 (similar bugs)
--
https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
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
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
On Sunday, 17 October 2021 15:23:17 CEST you wrote:
> Source: libconfig-model-dpkg-perl
> Version: 2.152
> Severity: serious
> Tags: ftbfs sid bookworm
> Justification: fails to build from source
Ack. I did a basic parsing of lintian tag files. It worked for entries like:
Renamed-From: shlib-call
On Fri, 20 Aug 2021 02:57:28 +0200 gregor herrmann wrote:
> Right, there is e.g.
> https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libconfig-model-dpkg-perl/14728439/log.gz
> with libconfig-model-dpkg-perl/2.147 licensecheck/3.2.11-1 and
>
> #v+
> not ok 7 - check scikit-learn copyright
On Friday, 2 July 2021 10:36:18 CEST you wrote:
> The patch hasn't landed in libuv.git, but here's the patch as applied
> by nodejs:
> https://github.com/nodejs/node/commit/d33aead28bcec32a2a450f884907a6d9716318
> 29
This patch modifies a file that was introduced in version 1.24.
So I guess that
Package: libprotocol-acme-perl
Version: 1.01-3
Severity: grave
Tags: upstream
Justification: renders package unusable
Dear Maintainer,
* What led up to the situation?
https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430
ACMEv1 is no longer working with Let's Encrypt, so this
I've created a bug upstream:
https://github.com/graphviz-perl/Graph/issues/20
All the best
Hi
On Sat, 17 Apr 2021 12:59:40 +0100 Ian Jackson <> The correct output, as seen
on buster:
>
> input: A-NOTA,B-A,B-NOTA
> output: A-A,A-NOTA,B-A,B-B,B-NOTA,NOTA-NOTA
> output: A-NOTA,B-A,B-NOTA,NOTA-NOTA
I've bisected this regression to:
3ded9c7a25bf190fda5add1a13ed4f9b54082db7 is the firs
On Saturday, 26 December 2020 22:40:58 CET Lucas Nussbaum wrote:
> > rakudo-helper.pl: Reinstalling all perl6 modules ...
> > (1/3) reinstall: raku-tap-harness
> > (2/3) reinstall: prove6
> > [31m===[0mSORRY![31m===[0m Error while compiling
> > //vendor#sources/B4401FC2C8E71132AE0D3CE2C47A7D2FB
On Monday, 28 September 2020 03:44:46 CEST Axel Beckert wrote:
> Looks as if Breaks and Replaces headers are missing in the nqp-data
> package and that it takes over files from the old nqp package.
Indeed. I'll fix this.
Thanks for the heads-up.
All the best
Dod
On samedi 5 septembre 2020 13:14:55 CEST gregor herrmann wrote:
> Could not find CompUnit::Repository::Staging in:
> inst#/root/.raku
> inst#/usr/share/perl6/site
> inst#/usr/share/perl6/vendor
> inst#/usr/share/perl6/core
Perl6 modules are installed in /usr/lib/perl6. Raku is not
On mardi 9 juin 2020 20:24:38 CEST you wrote:
> autopkgtest is meant to test the *installed* version of your package. It
> seems to me you meant here that you're testing a just built artifact
> instead of the system version. Then autopkgtest doesn't make much sense.
Indeed. As libuv is a only a li
On samedi 30 mai 2020 20:15:57 CEST you wrote:
> With a recent upload of libuv1 the autopkgtest of libuv1 fails in
> testing when that autopkgtest is run with the binary packages of libuv1
> from unstable.
Test method of libuv has recently changed. I've changed debian/rules to use
cmake instead o
On lundi 27 avril 2020 23:45:33 CEST Dagfinn Ilmari Mannsåker wrote:
> /usr/share/perl6/rakudo-helper.pl uses autodie and system(), which
> requires IPC::System::Simple, causing the following error when
> installing or upgrading the package:
> ..
> Manually installing libipc-system-simple-perl allo
On dimanche 23 février 2020 14:09:03 CET you wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
The failed test depend on licensecheck behavior. A bug in this package was
recently fixed, which led to this test failure.
I'll fix this test.
All the best
Do
On Wednesday, 16 October 2019 16:34:20 CEST gregor herrmann wrote:
> Ideally someone would try to update directly from -4 in unstable to
> -7 …
I was at -5, I've downgraded to -4 without much problems.
Then I've upgrade to -7 without problem and zef is working fine.
That's good news :-)
All the
On Saturday, 14 September 2019 02:37:41 CEST Mo Zhou wrote:
> Could you please verify the {moarvm,nqp,rakudo}-2019.07.1 in
> experimental? Shall I proceed and upload it to unstable?
Looks like there's an issue with /usr/share/perl6 link:
$ perl6 -e 'say "hello"'
Unhandled exception: While looking
On Thursday, 12 September 2019 08:33:00 CEST Niels Thykier wrote:
> Does rakudo build with "Rules-Requires-Root: no"[1]? If it does, then
> you can work around the bug / issue in fakeroot for sid, testing and
> stable for now by using it.
Yes ! I can now build rakudo on my laptop. Thanks for the
On Wednesday, 11 September 2019 07:21:24 CEST Robert Lemmen wrote:
> ...and it's fakeroot! it does ld_preload to map file user ids, and doing
> that it fakes stat calls, but not statx!
Excellent news.
I've relayed your findings to upstream.
Could you open a bug against fakeroot to have statx sup
On Thursday, 5 September 2019 20:45:05 CEST gregor herrmann wrote:
> What happened to this NMU?
It's in unstable
> I just noticed that the bug ist still open and perl6-readline was
> removed from testing …
The nmu version (0.1.4-3.1) cannot go in testing because rakudo is FTBS with
newer libuv
On Tuesday, 27 August 2019 18:33:30 CEST M. Zhou wrote:
> > On the other hand, I'm able to build rakudo 2019-07 on my system with
> > latest libuv1.
>
> Have you built it with the root user? The build would pass.
> Try to switch to a normal user and it would FTBFS.
Oops... Actually, I forgot to d
On Tuesday, 27 August 2019 10:04:23 CEST Dominique Dumont wrote:
> Right.. This is the same error than the one showing in the FTBS issue.
>
> I guess we need to talk to upstream. They may not have seen this issue yet
> if they use an older version of libuv.
On the other hand, I
On Tuesday, 27 August 2019 05:27:49 CEST M. Zhou wrote:
> I'm somehow
> stuck on a strange installation failure (likely permission issue):
Oops, I missed that part...
> '/home/lumin/Debian/perl6/rakudo/debian/rakudo/usr/lib/perl6/core'
> No writeable path found,
> /home/lumin/Debian/perl6/rakudo/
On mercredi 21 août 2019 13:08:42 CEST Ivo De Decker wrote:
> A binnmu of rakudo in unstable fails on amd64:
>
> https://buildd.debian.org/status/package.php?p=rakudo
Rakudo fails to build with latest version of libuv1 but it builds fine with
libuv1 1.24.1-1 (from stable).
I guess that latest
On vendredi 23 août 2019 21:37:34 CEST you wrote:
> - ./Build realclean; perl Build.PL
> - prove fails
Do'h.. I'm so used to type "perl -Ilib t/*.t" that I forgot to remove the '-
Ilib'.
Now I can reproduce this issue.
Turns out that the issue can be fixed in t/load_write_itself.t. I'm going to
On jeudi 22 août 2019 20:31:52 CEST you wrote:
> Can you please investigate the situation and reassign the
> bug to the right package?
Sure.
The change done in libconfig-model-tkui-perl 1.370 did break libconfig-model-
itself-perl 2.016 (the API change are backward compatible, the class
inherita
On Wednesday, 17 April 2019 19:03:26 CEST Boyuan Yang wrote:
> I found that this will happen when I set the default font to be Noto Sans
> CJK SC with arbitary font weight. By resetting the font to default, the
> email viewer would recover back to normal however the composer is always
> missing spa
On Thu, 11 Apr 2019 11:22:46 -0400 Boyuan Yang wrote:
> A screenshot is provided with the email here. I'm not sure if it can be
> reproduced by you, but at least this issues appears on all my machines
> running Debian Sid.
I'm using evolution 3.30.5-1 and cannot reproduce this bug.
Could you che
On Sun, 17 Mar 2019 16:38:23 +0100 zieg...@uni-freiburg.de wrote:
> I use xfce4 as a window-manager. The bug does NOT occur
> under icewm.
This looks like a bad interaction between emacs and xfce4, I'd guess then
emacs is sending the file name to xfc4 to set the widget title.
Could you try to r
On Tuesday, 12 February 2019 16:54:12 CET Andreas Tille wrote:
> I'm
> not sure how to deal with the jquery.js one since this is potentially an
> issue with lots of dependencies - I remember discussions about this
> which I did not followed.
Fortunately, jquery is available as a Debian package.
W
For the record, here's the deprecation notice of Swagger2:
https://metacpan.org/pod/release/JHTHORSEN/Swagger2-0.89/lib/Swagger2.pm
HTH
On Wednesday, 30 January 2019 11:45:33 CET Arnaud Rebillout wrote:
> Could it be a matter of `systemctl restart docker`, or something like
> that?
spot on !
docker is working fine after a restart.
Thanks for the hint.
Dod
On Mon, 28 Jan 2019 13:53:08 +1100 Dmitry Smirnov wrote:
> On Monday, 28 January 2019 2:26:00 AM AEDT Holger Schröder wrote:
> > sorry, is not solved. next problem.
> >
> > docker run -it -u0 --rm alpine:latest
> > docker: Error response from daemon: failed to start shim: exec:
> > "containerd-sh
Hello
On Sat, 29 Dec 2018 23:07:11 +0100 Lucas Nussbaum wrote:
> not ok 103 - get_passwd
> # exit code 6
> # Output from process `get_passwd`:
> # Assertion failed in test/test-get-passwd.c on line 41: len > 0
Upstream asks:
> That line asserts that the current user's shell in the password file
On Thu, 27 Dec 2018 17:56:46 +0100 gregor herrmann wrote:
> libconfig-model-dpkg-perl (both 2.119 in the archive and the version
> in git) doesn't build anymore, probably due to changes in or around
> Config::Model.
More likely, lintian was updated and some tests are too pedantic to handle
well
On Mon, 29 Oct 2018 10:08:56 -0700 Felix Lechner
wrote:
> The owner of libsoftware-licensemoreutils would like to resolve the
> issue differently. (For details, please see #911403.) The patch I
> submitted earlier is outdated. Thank you!
The owner of libsoftware-licensemoreutils had a bad case o
On Monday, 29 October 2018 16:51:45 CET you wrote:
> I am happy to provide patches and merge requests that implement your
> idea,
Thanks. But the change is trivial. I can do it on my side.
We just need to find a common ground that allow fixing #905614
> but are you sure there are other meanin
On Monday, 29 October 2018 15:21:25 CET you wrote:
> I'm not thrilled at the idea of changing the behavior of summary_or_text
> method because the implementation would no longer match its behavior.
Oops, this sentence does not make sense.
I meant that "the function name would no longer match its
On Sat, 27 Oct 2018 15:57:56 +0200 gregor herrmann wrote:
> Dominique, could you look into this patch, please?
yes, sorry for the delay.
I'm not thrilled at the idea of changing the behavior of summary_or_text
method because the implementation would no longer match its behavior.
Felix, how abo
On Thursday, 27 September 2018 01:41:11 CEST Axel Beckert wrote:
> Since it's /usr/share/perl6/rakudo-helper.pl which contains that
> erroneous path, the issue is not in perl6-tap-harness but in rakudo.
ok. Let's provide a script in /usr/share/perl6/rakudo-helper.pl that will warn
about deprecate
On Tuesday, 24 July 2018 04:32:22 CEST you wrote:
> [...] and proposed to give Dominique
>access to the upstream BZR repo so he can fix stuff directly there
>(and de facto become the only person active upstream with
>development skills). Dominique did not reply to this offer.
Hmm, I d
close 902107 1.011-1
thanks
I did not see this bug report. This issue has been fixed with
in the last release of libconfig-model-approx-perl.
Sorry about the mess
Dod
On Friday, 18 May 2018 17:08:38 CEST Dominic Hargreaves wrote:
> Currently the package has a popcon of inst: 37 / vote: 22 / recent: 1
> suggesting that it is barely used anywhere.
Reading its features, I think this module may have been a good idea when it
was created back in 1997, but I'm afrai
On Sat, 5 May 2018 11:40:48 +0300 Niko Tyni wrote:
> As noticed by ci.debian.net, this package has started failing its
> test suite on current sid, probably because of
This one is bad. Runtime is also broken.
Looks like I missed a modification when I prepared the deprecation done in
latest Conf
On Sat, 5 May 2018 11:32:04 +0300 Niko Tyni wrote:
> This also makes the package fail to build from source.
Ack. The new version revealed a bug in Config::Model::TkUI tests.
User should not be impacted. I've fixed this upstream and will package it for
Debian soon.
Thanks for your report.
All
On Saturday, 5 May 2018 10:39:06 CEST you wrote:
> As noticed by ci.debian.net, this package has started failing its
> test suite on current sid
Ack. This is fixed in git. I'll release a new version soon.
Thanks for the report.
All the best
On Monday, 9 April 2018 19:24:58 CEST Dominique Dumont wrote:
> I've already discussed this problem with upstream and they kinda agreed to
> change this strong dependency. [1]
This restriction has been lifted by upstream [1]. I'm going to change the
dependency requirement betwee
On Sunday, 8 April 2018 09:57:03 CEST Adrian Bunk wrote:
> Please relax the nqp dependency to require only
> the upstream version of nqp (similar to the
> moarvm dependency).
I'd like to, but this constraint comes from upstream.
I've already discussed this problem with upstream and they kinda agr
close 891304 0.124-1
thanks
The FTBS was fixed upstream in version 0.124.
Thanks for the report
All the best
On Wed, 28 Feb 2018 03:22:29 +0100 Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Rep
TINITA explains in this post how safely use YAML in Perl:
http://blogs.perl.org/users/tinita/2018/02/safely-load-untrusted-yaml-in-perl.html
HTH
close 888582 2018.01+dfsg-1
thanks
build target was fixed in latest release.
Thanks for the report.
--
https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Hi
Good news: object creation can now be disabled starting from YAML::XS 0.69.
That said, the default behavior is unchanged (which is reasonable).
This means that any application loading untrusted YAML data must be modified
to set $YAML::XS::LoadBlessed to 0 before loading YAML files.
I guess
On Saturday, 11 November 2017 17:17:28 CET Dominique Dumont wrote:
> This is not an ideal solution, but is better than nothing...
Got good reasons [1], upstream is not thrilled about the idea of adding
SafeLoad to YAML::XS API. So I've disabled the patch.
TINITA suggests [2] to use unbl
On Fri, 12 May 2017 08:03:12 +0200 Dominique Dumont wrote:
> > As previously mentioned in debian-perl@, there is no easy solution,
I've prepared a patch to provide a SafeLoad method. This avoids breaking
application that need to create Perl class from YAML.
On the downside:
- applic
On mardi 12 septembre 2017 17:24:36 CEST you wrote:
> 08:02 918537
> /lib/x86_64-linux-gnu/libgpg-error.so.0.21.0 Thread 4 "pool" received
> signal SIGABRT, Aborted.
> [Switching to Thread 0x7fffe3fff700 (LWP 24971)]
I can't reproduce this crash on my system. This bug
> As previously mentioned in debian-perl@, there is no easy solution,
A possibility to limit the impact is to deny object creation if the class has
a DESTROY method.
Knowing that UNIVERSAL has no DESTROY method, It's fairly easy to test:
$ perl -MFile::Temp -E 'say File::Temp->can("DESTROY") ?
Ive logged a bug to upstream YAML parser library:
https://github.com/ingydotnet/yaml-pm/issues/176
HTH
On samedi 6 mai 2017 13:01:50 CEST you wrote:
> Lintian uses the YAML::XS module to validate YAML in
> debian/upstream/metadata.
Unless debian/upstream/metadata needs fancy YAML format (e.g. anchor alias
tags ...), the easiest way out it to use YAML::Tiny instead of YAML::XS. This
should be a dr
On Monday, 16 January 2017 15:54:36 CET you wrote:
> during a test with piuparts I noticed your package failed to install.
The root cause is now fixed in dh_cme_upgrade with [1]. I will upload
a new lcdproc package once cme is updated.
All the best
[1] https://anonscm.debian.org/cgit/pkg-perl/p
On Monday, 16 January 2017 15:54:36 CET you wrote:
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
Note that this failure comes from the experimental version of lcdp
On Friday, 13 January 2017 15:24:54 CET Damyan Ivanov wrote:
> Perhaps somebody from the perl group (CC-ed) can take a look?
See below...
> > > --- a/mrtg-rrd.cgi
> > > +++ b/mrtg-rrd.cgi
> > > @@ -496,7 +496,7 @@ sub common_args($$$)
> > >
> > > {
> > >
> > > my ($name, $target, $q)
On Friday, 6 January 2017 21:57:57 CET Salvatore Bonaccorso wrote:
> Btw, it would be good/great to forward any applied patch to upstream.
Done: https://bugs.launchpad.net/shutter/+bug/1652600/comments/6
(this is a bit confusing because launchpad is usually downstream...)
All the best
--
https
On Sat, 31 Dec 2016 12:39:57 +0100 Christoph Biedl wrote:
> Christoph Biedl wrote...
>
> > The patch attached
Thanks.
I've tested the patch and it's fine.
I've also created a patch to replace all system("big string") calls to
system(@big_list) in all plugins to avoid similar problems.
I'll u
On Monday, 2 January 2017 23:20:30 CET gregor herrmann wrote:
> I'm just reading
> http://blogs.perl.org/users/steve_mynott/2017/01/rakudo-star-past-present-an
> d-future.html which mentions that Rakudo Star is moving from panda to zef.
Thanks for the link. I'm currently trying to figure out what
On Thursday, 29 December 2016 16:57:36 CET you wrote:
> Severity: grave
Downgraded to important because this problem concerns only one lcdproc driver.
All the best
Hello
I had a similar ENOSPC issue on my HP 8560w.
Modifying the boot order in bios setup fixed the issue (one may wonder for how
long...)
HTH
--
https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
On Wednesday, 19 October 2016 17:36:25 CEST James Cowgill wrote:
> rakudo FTBFS on arm64, powerpc and ppc64 with errors in the testsuite.
>
> arm64 times out during the 't/04-nativecall/02-simple-args.t' test.
Yes, see https://github.com/MoarVM/MoarVM/issues/428
and http://bugs.debian.org/cgi-bin
On Thu, 22 Sep 2016 16:21:02 + Santiago Vila wrote:
> Load command error:
> command: 'max='
> Syntax error: spurious char at command end: '='. Did you forget double
quotes ?
> Exception thrown at /usr/share/perl5/Config/Model/Exception.pm line 69.
Ack. I've fixed this upstream.
On Tue, 13 Sep 2016 16:46:47 +0200 Dominique Dumont wrote:
> Looks like I cannot find a way to handle the removal of '.' from @INC
> I may need to avoid using 'do' and revisit completely the way model files
> are loaded...
Fortunately, it was a stupid mistake o
On Tue, 13 Sep 2016 15:55:27 +0200 (CEST) Santiago Vila wrote:
> I'm reporting this against libconfig-model-itself-perl because that's
> the package which FTBFS, but of course it is completely possible (and
> maybe likely) that this is still a bug in libconfig-model-perl.
>
> But I'm no perl expe
On Monday, 5 September 2016 23:29:27 CEST gregor herrmann wrote:
> Maybe zef is in option:
> https://github.com/ugexe/zef
Thanks for the hint.
Unfortuantely, I don't know when I'll find the time to look at this issue :-/
All the best
--
https://github.com/dod38fr/ -o- http://search.cpan.org
1 - 100 of 222 matches
Mail list logo
