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]

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

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

Bug#1061035: marked as pending in libconfig-model-dpkg-perl

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:

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

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#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

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

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

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

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

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: >

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/

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 >

Bug#1016670: marked as pending in libconfig-model-dpkg-perl

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:

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

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

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

Bug#1015034: closing 1015034, closing 1015110

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

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

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#996697: libconfig-model-dpkg-perl: FTBFS: t/lintian.t fails

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:

Bug#992439: libconfig-model-dpkg-perl: blocks fails autopkgtest with recent licensecheck

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

Bug#990561: libuv1: CVE-2021-22918

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

Bug#990219: libprotocol-acme-perl implements ACMEv1 protocol which is no longer usable

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

Bug#987095: transitive_closure corrupted results, after vertex deleted

I've created a bug upstream: https://github.com/graphviz-perl/Graph/issues/20 All the best

Bug#987095: transitive_closure corrupted results, after vertex deleted

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

Bug#978226: perl6-zef: FTBFS: Errors while processing: rakudo raku-getopt-long raku-tap-harness prove6 sbuild-build-depends-main-dummy

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 > > ===SORRY!=== Error while compiling > >

Bug#971244: nqp-data: Missing Breaks/Replaces headers: trying to overwrite '/usr/share/nqp/lib/MASTNodes.moarvm', which is also in package nqp 2020.06+dfsg-1

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

Bug#969578: rakudo 2020.08.2-1 breaks perl6-* modules

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

Bug#961878: libuv1: autopkgtest regression: ./gyp_uv.py: No such file or directory

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

Bug#961878: libuv1: autopkgtest regression: ./gyp_uv.py: No such file or directory

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

Bug#959000: rakudo: fails to configure: missing dependency on libipc-system-simple-perl

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

Bug#952170: libconfig-model-dpkg-perl: FTBFS: dh_auto_test: error: perl Build test --verbose 1 returned exit code 255

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

Bug#942364: [patch] perl6-* (vendored) packages out of the reach of perl6 path

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

Bug#935290: moar digging

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

Bug#935290: moar digging

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

Bug#935290: moar digging

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

Bug#932637: nmu now in the delayed queue

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

Bug#935290: rakudo: FTBFS on amd64

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

Bug#935290: rakudo: FTBFS on amd64

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'm a

Bug#935290: rakudo: FTBFS on amd64

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, >

Bug#935290: rakudo: FTBFS on amd64

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

Bug#935453: libconfig-model-tkui-perl breaks libconfig-model-itself-perl autopkgtest

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

Bug#935453: libconfig-model-tkui-perl breaks libconfig-model-itself-perl autopkgtest

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

Bug#926872: evolution: Spaces in mail view disappeared with recent updates

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

Bug#926872: evolution: Spaces in mail view disappeared with recent updates

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

Bug#924762: further information: window manager

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

Bug#921779: Bug#919413: cascade of FTBFS

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.

Bug#917036: Swaggers is indeed a goner

For the record, here's the deprecation notice of Swagger2: https://metacpan.org/pod/release/JHTHORSEN/Swagger2-0.89/lib/Swagger2.pm HTH

Bug#920597: Last docker.io update - not start

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

Bug#920597: Last docker.io update - not start

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: > >

Bug#917718: libuv1: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

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

Bug#917430: libconfig-model-dpkg-perl: test failures with newer Config::Model

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

Bug#905614: Patch invalid

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

Bug#911403: Please always include a copyright notice in 'LicenseWithSummary::summary_or_text'

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

Bug#911403: Please always include a copyright notice in 'LicenseWithSummary::summary_or_text'

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

Bug#911403: Please always include a copyright notice in 'LicenseWithSummary::summary_or_text'

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

Bug#909698: rakudo: perl6-tap-harness fails to configure: Could not open /usr/share/perl6/install-dist.p6. Failed to stat file: no such file or directory

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

Bug#870418: How much longer should Shutter remain in sid?

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

Bug#902107: closing 902107

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

Bug#899021: libembperl-perl: FTBFS with Perl 5.27, unmaintained upstream

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

Bug#897963: libconfig-model-systemd-perl: FTBFS: Can't locate object method "exists" via package

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

Bug#897960: libconfig-model-tkui-perl: FTBFS: Can't call method "exists" on an undefined value

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

Bug#897962: libconfig-model-dpkg-perl: FTBFS: io_handle backend parameter is deprecated, please use file_path parameter

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

Bug#895180: rakudo: dependency on nqp is too strict

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 between rakudo a

Bug#895180: rakudo: dependency on nqp is too strict

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

Bug#891304: closing 891304

close 891304 0.124-1 thanks The FTBS was fixed upstream in version 0.124. Thanks for the report All the best

Bug#891693: rakudo: fails to upgrade from 'testing' - trying to overwrite /usr/lib/perl6/runtime/dynext/libperl6_ops_moar.so

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

Bug#862373: solved upstream: Unconditionally instantiates objects from yaml data

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

Bug#888582: closing 888582

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

Bug#862373: solved upstream: Unconditionally instantiates objects from yaml data

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

Bug#862373: Unconditionally instantiates objects from yaml data

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 unbless f

Bug#862373: Unconditionally instantiates objects from yaml data

On Fri, 12 May 2017 08:03:12 +0200 Dominique Dumont <d...@debian.org> 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

Bug#875617: pan: Crashes when launching

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

Bug#862373: Unconditionally instantiates objects from yaml data

> 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") ?

Bug#861958: lintian: insecure YAML validation [CVE-2017-8829]

Ive logged a bug to upstream YAML parser library: https://github.com/ingydotnet/yaml-pm/issues/176 HTH

Bug#861958: lintian: insecure YAML validation

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

Bug#851579: lcdproc: fails to install: post-installation script returned error exit status 10

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]

Bug#851579: lcdproc: fails to install: post-installation script returned error exit status 10

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

Bug#799097: mrtg-rrd: Regression after the fix for bug #787608.

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)

Bug#849777: shutter: CVE-2016-10081: Insecure use of perl exec()

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 --

Bug#849777: shutter: CVE-2016-10081: Insecure use of perl exec()

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

Bug#818926: perl6-panda: panda doesn't start up / find needed libraries

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

Bug#849659: hd44780 driver linked with wrong sem_wait

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

Bug#756253: Another workaround

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

Bug#841343: rakudo: FTBFS on arm64, powerpc and ppc64 - testsuite errors

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

Bug#838583: libconfig-model-lcdproc-perl: FTBFS with "Syntax error: spurious char at command end"

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

Bug#837682: libconfig-model-itself-perl: FTBFS in unstable (failing tests)

On Tue, 13 Sep 2016 16:46:47 +0200 Dominique Dumont <d...@debian.org> 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 on

Bug#837682: libconfig-model-itself-perl: FTBFS in unstable (failing tests)

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. > >

Bug#818926: perl6-panda: panda doesn't start up / find needed libraries

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-

Bug#837133: libconfig-model-itself-perl: FTBFS: t/load_write_itself.t failure

On Fri, 9 Sep 2016 09:37:54 +0300 Niko Tyni wrote: > Load command error: > command: 'upstream_default=#' > Syntax error: spurious char at command end: '=#'. Did you forget double quotes ? This is a bug in Config::Model::Loader which is now trapped since

Bug#837261: libconfig-model-dpkg-perl: FTBFS: Tests failures

On Sat, 10 Sep 2016 09:44:10 +0200 Lucas Nussbaum wrote: > Relevant part (hopefully): > > Test Summary Report > > --- > > t/model_tests.t(Wstat: 65280 Tests: 814 Failed: 0) > > Non-zero exit status: 255 This means that t/model_tests.t

Bug#836679: flash-kernel: cannot configure kernel 4.7 with new flash-kernel

On Sunday, September 4, 2016 12:34:03 PM CEST you wrote: > Maybe the real bug is that the signed package doesn't contain the > DTBs. Indeed. This issue has also been reported in #836255. On the other hand the error message returned by flash-kernel could be improved. When the dtb is missing,

Bug#830403: closing 830403

close 830403 2.048-1 thanks Got the wrong number in changelog -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org

Bug#830403: libconfig-model-lcdproc-perl: FTBFS: Attribute (instance) does not pass the type constraint because: Validation failed for 'Config::Model::Instance' with value undef at /usr/lib/x86_64-lin

Model generation from lcdproc/LCDd.conf broke with Config::Model::Itself 2.005 I'll fix that upsream. Thanks for the report. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org

  1   2   3   >