Bug#1069247: libconfig-model-dpkg-perl: test failures

[Dominique Dumont]

On Sunday, 21 April 2024 18:07:00 CEST Julian Andres Klode wrote:
> This should be fixed in apt git already, just needs an upload,
> which is waiting-ish for some more merges

Given [1], I need to ask... 

Is this a definitive fix or will this feature come back with apt 3.0 ?

All the best

[1] 
https://salsa.debian.org/apt-team/apt/-/commit/fc35b4d7d95b2848db482021df4f4500ac142080

Bug#1069247: libconfig-model-dpkg-perl: test failures

[Dominique Dumont]

On Thursday, 18 April 2024 19:21:55 CEST you wrote:
> Source: libconfig-model-dpkg-perl
> Version: 3.004
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source

This really looks like a bug with prove:

$ perl t/reorder.t 
ok 1 -  test re-ordered list
1..1
$ prove -l -v -p t/reorder.t 
t/reorder.t .. 
ok 1 -  test re-ordered list
1..1
Failed 1/1 subtests 

Test Summary Report
---
t/reorder.t (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=1, Tests=0,  1 wallclock secs ( 0.02 usr  0.00 sys +  0.92 cusr  0.07 
csys =  1.01 CPU)
Result: FAIL


I can't see what's wrong with the output of reorder test...

I'll try to dig this later on..

All the best

Bug#1063484: libuv1: CVE-2024-24806

[Dominique Dumont]

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

[Dominique Dumont]

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

[Dominique Dumont]

On Thu, 08 Feb 2024 20:51:30 +0100 Salvatore Bonaccorso  
wrote:
> Note, that the advisory at [1] mentions that affected versions are
> only > 1.45.x. Looking at the git changes, is it not introduced after
> 6dd44caa35b4 ("unix,win: support IDNA 2008 in uv_getaddrinfo()") in
> v1.24.0?

The advisory has been changed and list v1.24.0 as affected version.

I'm going to pacakge v1.48 to fix this issue in unstable.

I'm still pondering what should be done for stable which ships a libuv 1.44.2

All the best

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

[Dominique Dumont]

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-model-dpkg-perl/-/commit/9a1eac67854c15b47e70ddef065d204404dd39e3


fix grant/by-dir test

The convertion from "-present" to current year is tested in
Software::Copyright tests. There's no need to test this here.

Closes: #1061035


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1061035

Bug#1057567: libconfig-model-lcdproc-perl: FTBFS: Cannot determine local time zone

[Dominique Dumont]

Hi

On Tuesday, 5 December 2023 23:06:12 CET you wrote:
> Wrote documentation in lib/Config/Model/models/LCDd/yard2LCD.pod Cannot
> determine local time zone
> [DZ] beginning to build Config-Model-LcdProc

I've seen this error from time to time. I don't know the exact algorithm used 
to determine the time zone, but usually, setting TZ to an appropriate value 
fixed this issue.

Could you check the config of your build deamon and add such a variable ?

All the best

Bug#1054981: libtk-objeditor-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2

[Dominique Dumont]

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

[Dominique Dumont]

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

[Dominique Dumont]

Hello

Turns out that Perl module Net::SMTP supports SSL since 2014 [1], but bts still 
use Net::SMTPS which is an old wrapper around Net::SMTP.

I've patched bts to use Net::SMTP instead of Net::STMPS and I can connect to 
Daniel's server:

$ perl -MDevel::SimpleTrace scripts/bts.pl --smtp-host smtps://mail.wgdd.de 
usertag 1029588 + dod-test-with-tls
Net::SMTP::_SSL>>> Net::SMTP::_SSL
Net::SMTP::_SSL>>>   IO::Socket::SSL(2.081)
Net::SMTP::_SSL>>> IO::Socket::IP(0.41)
Net::SMTP::_SSL>>>   IO::Socket(1.49)
Net::SMTP::_SSL>>> IO::Handle(1.48)
Net::SMTP::_SSL>>>   Exporter(5.77)
Net::SMTP::_SSL>>>   Net::SMTP(3.14)
Net::SMTP::_SSL>>> Net::Cmd(3.14)
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 220 mail.wgdd.de ESMTP Postfix 
(Debian/GNU)
Net::SMTP::_SSL=GLOB(0x5590e82e5878)>>> EHLO free.fr
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-mail.wgdd.de
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-PIPELINING
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-SIZE
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-ETRN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-AUTH PLAIN LOGIN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-AUTH=PLAIN LOGIN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-ENHANCEDSTATUSCODES
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-8BITMIME
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-DSN
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250-SMTPUTF8
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250 CHUNKING
Net::SMTP::_SSL=GLOB(0x5590e82e5878)>>> MAIL FROM:
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 250 2.1.0 Ok
Net::SMTP::_SSL=GLOB(0x5590e82e5878)>>> RCPT TO:
Net::SMTP::_SSL=GLOB(0x5590e82e5878)<<< 554 5.7.1 
<91-175-103-119.subs.proxad.net[91.175.103.119]>: Client host rejected: Access 
denied
bts.pl: failed to set SMTP recipient cont...@bugs.debian.org
()
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(scripts/bts.pl:2848)
at main::(scripts/bts.pl:834)

bts fails later probably because of my mail config (proxad system is free.fr 
mail server).

Anyhow, the failure occurs after bts is connected to Daniel's server.

Could you test bts with the patch below ? (feel free to remove the Debug 
argument)

All the best

[1] https://metacpan.org/dist/libnet/changes#L256


diff --git a/scripts/bts.pl b/scripts/bts.pl
index 7449c7ca..6ed35437 100755
--- a/scripts/bts.pl
+++ b/scripts/bts.pl
@@ -106,7 +106,7 @@ sub have_lwp() {
 
 sub have_smtps() {
 return ($smtps_broken ? 0 : 1) if defined $smtps_broken;
-eval { require Net::SMTPS; };
+eval { require Net::SMTP; };
 
 if ($@) {
 if ($@ =~ m%^Can\'t locate Net/SMTPS%) {
@@ -2703,11 +2703,12 @@ sub send_mail {
 $port ||= '465';
 
 if (have_smtps) {
-$smtp = Net::SMTPS->new(
+$smtp = Net::SMTP->new(
 $host,
 Port  => $port,
 Hello => $smtphelo,
-doSSL => 'ssl'
+SSL => 1,
+Debug => 1,
   )
   or die
 "$progname: failed to open SMTPS connection to $smtphost\n($@)\n";
@@ -2720,11 +2721,10 @@ sub send_mail {
 $port ||= '25';
 
 if (have_smtps) {
-$smtp = Net::SMTPS->new(
+$smtp = Net::SMTP->new(
 $host,
 Port  => $port,
 Hello => $smtphelo,
-doSSL => 'starttls'
   )
   or die
 "$progname: failed to open SMTP connection to $smtphost\n($@)\n";

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

[Dominique Dumont]

On Wed, 22 Mar 2023 15:22:34 +0100 Lee Garrett  wrote:
> While this setup might work for some people, this has IMHO quite a few hefty 
> drawbacks and requires me to maintain a MTA on my local machine. I could 
> elaborate, but I don't think it's on-topic for this bug report.

Agreed.

> I'm sure that bts supports STARTTLS. I am using bts with my MTA on 587/tcp, 
> which enforces STARTTLS and requires credentials (I just double-checked via 
> swaks). With the old libio-socket-ssl-perl 2.069-1 this works, so it's 
> clearly a 
> regression.

BTS uses SSL when the host URL begins with smpts or ssmtp (see [1]), and 
STARTTLS otherwise.

It may be a regression, but I need more data before reporting this problem 
upstream.

Daniel, could you apply the patch below on bts.pl and try again ? You should 
get more traces when 
bts is trying to connect to your server. 

All the best

[1] 
https://salsa.debian.org/debian/devscripts/-/blob/master/scripts/bts.pl#L2697

diff --git a/scripts/bts.pl b/scripts/bts.pl
index 7449c7ca..f280e9a1 100755
--- a/scripts/bts.pl
+++ b/scripts/bts.pl
@@ -64,6 +64,9 @@ use Encode;
 use URI 1.37;
 use URI::QueryParam;
 
+use IO::Socket::SSL;
+$IO::Socket::SSL::DEBUG=2;
+
 use Scalar::Util qw(looks_like_number);
 use POSIX qw(locale_h strftime);

Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed

[Dominique Dumont]

On Tue, 14 Feb 2023 22:21:26 +0100 Lee Garrett  wrote:
> Bumped severity as this makes bts currently unusable, and probably 
> breaks for quite a few DDs their workflow.

This does not break on my system where bts is connected to local sendmail 
(which is the default setup).

Which hints at a workaround: have bts connect to local sendmail and have 
sendmail forward the mail to the SMTPS server.

The change mentioned by Daniel affects only a setup where the host if 
configured via its IP address, not via a host name:
See the change in SSL.pm in commit 
https://github.com/noxxi/p5-io-socket-ssl/commit/c0a063b70f0a3ad033da0a51923c65bd2ff118a0

Which is not the case here:

$ perl -S -MDevel::SimpleTrace bts --smtp-host smtps://mail.wgdd.de usertag 
1029588 + dod-test-with-tls
bts: failed to open SMTPS connection to smtps://mail.wgdd.de
(hostname verification failed)
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(/usr/bin/bts:2839)
at main::(/usr/bin/bts:825)

Unfortunately, I can no longer investigate this issue as it looks like that my 
IP address is now blacklisted on Daniel's server:

$ perl -MDevel::SimpleTrace scripts/bts.pl --smtp-host smtps://mail.wgdd.de 
usertag 1029588 + dod-test-with-tls
bts.pl: failed to open SMTPS connection to smtps://mail.wgdd.de
(Connection refused)
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(scripts/bts.pl:2849)
at main::(scripts/bts.pl:834)

On a hunch, I would guess that Daniel's server is configured to handle 
STARTTLS, which is not supported by bts. But I cannot verify this. 
In any case this does not explain why Daniel sees bts working with 
libio-socket-ssl-perl 2.077 but not with 2.078.

All the best

Bug#1023576: Need to change the way raku-api is built (will breaks modules)

[Dominique Dumont]

Hi

Following bug #1023576 and [1], the dependency between raku modules and rakudo 
version needs to be tightened.

Until now, every raku-module depends on raku-api- (currently is 
raku-api-2022-07). The idea is to lock the pre-compiled files contained in a 
raku-module package to a specific rakudo version.

Turns out this is not enough. The pre-compiled files are specific to raku 
compiler id, which changes whenever nqp or rakudo sources are changed.

This source change occurred only on nqp or rakudo upgrades, until I had to 
patch rakudo source code to fix a bug (#1019579).

To fix this, I need to make sure that a module is dependent on a rakudo version 
with a matching compiler-id. 

I see no other solution than to change the way rakudo is built to include the 
compiler id in raku-api (well, only the first 8 chars, because compiler id is 
quite long).

I.e. the next version of rakudo will have this in its control file:

 Provides: raku-api-2022.07+a6fe09f2

And dh-raku-build will be modified to inject this dependency in raku modules. 
E.g.:

 Depends: raku-api-2022.07+a6fe09f2

So, the plan is:
- upload a new dh-raku (which will produce non installable raku module package 
until rakudo is updated)
- upload a new version of rakudo in experimental
- trigger a transition so that all raku modules are rebuilt with new rakudo 
and new dh-raku

Until the transition is complete, raku in Debian/unstable will be a mess.

If anyone has a better idea, I'm all ears ...

Dod

[1] https://github.com/rakudo/rakudo/issues/5099

Bug#1020898: Uninstallable due to file conflict A37F26876B58371B70EDD889AD69F064C90AC2C6

[Dominique Dumont]

On Wed, 28 Sep 2022 12:17:48 +0200 Dominique Dumont  wrote:
> I'll have to reach out to upstream to investigate.

I've a fix from upstream for rakudo package. The fix is added in rakudo 
2020.07-2

I need to re-upload the affected module packages to depend on that version of 
rakudo (so the package is rebuilt without the conflicting file).

I will not upload a new version of perl6-readline. This package is replaced by 
raku-readline and has a RM bug filed.

All the best

Dod

Bug#1020898: Uninstallable due to file conflict A37F26876B58371B70EDD889AD69F064C90AC2C6

[Dominique Dumont]

On Wednesday, 28 September 2022 10:39:57 CEST Guillem Jover wrote:
> [ Filing against all affected packages because it's not clear to me which
>   one needs to be fixed. ]
> 
> These packages all contain (at least) these same filenames:
> 
>   ,---
>   perl6-readline:
> /usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A
> 37F26876B58371B70EDD889AD69F064C90AC2C6 perl6-readline:
> /usr/lib/perl6/vendor/precomp/DA3B96DAB7BC165C334BF96F9941B4C9DBA4BAE7/A3/A
> 37F26876B58371B70EDD889AD69F064C90AC2C6.repo-id

Sigh.. This precompiled file should be provided by rakudo package.

I'm afraid all raku-* packages are impacted.

I'll have to reach out to upstream to investigate.

All the best

Bug#1020788: dh-raku: Failed to create directory '/sbuild-nonexistent/.raku/short'

[Dominique Dumont]

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

[Dominique Dumont]

On Mon, 12 Sep 2022 17:21:45 +0300 Adrian Bunk  wrote:
> Unpacking raku-json-unmarshal (0.10-1) ...
> dpkg: error processing archive /tmp/apt-dpkg-install-Kxnez1/92-raku-json-
unmarshal_0.10-1_arm64.deb (--unpack):
>  trying to overwrite '/usr/lib/perl6/vendor/precomp/
C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/
C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package raku-json-
marshal 0.0.23-1
> ...

This bug is due to the fact that raku-json-fast package does not contain the 
precompiled file for JSON::Fast.

This package is a dependency of both raku-json-unmarshal and raku-json-
marshal. So the build process of both package recompile JSON::Fast and both 
ship the precompiled file. Hence the collision.

The issue with JSON::Fast precompilation is tracked there:

https://github.com/rakudo/rakudo/issues/4907

All the best

Bug#1019579: raku-json-unmarshal: trying to overwrite '/usr/lib/perl6/vendor/precomp/C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package rak

[Dominique Dumont]

On Monday, 12 September 2022 16:21:45 CEST Adrian Bunk wrote:
> ...
> Unpacking raku-json-unmarshal (0.10-1) ...
> dpkg: error processing archive
> /tmp/apt-dpkg-install-Kxnez1/92-raku-json-unmarshal_0.10-1_arm64.deb
> (--unpack): trying to overwrite
> '/usr/lib/perl6/vendor/precomp/C847F303DB03DE97DCB92EFEE90C0526E0D4FDF0/C1/
> C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package
> raku-json-marshal 0.0.23-1 ...
> 

ok. I don't' really understand what's going on with these precompiled files.

I've asked for help upstream.

Thanks for the heads-up

All the best.

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

[Dominique Dumont]

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-model-dpkg-perl/-/commit/522848cbf14008062b10b98a7d0a4f5e947465be


Test: set Source value when needed

Closes: #1016670
Thanks: gregoa for the bug report

This bug is related to 1015913

This commit fixes autopkgtest failures. Looks like autopkgtest runs in
a directory that cannot be used as default Source value. So Source
value remains undef.

This is a problem because Source value is mandatory and is used to
compute the default value of Vcs-Browser.  So when Computation of
Vcs-Browser tries to Source, the mandatory check kicks in and exit on
error.

Here the solution is to set a dummy value before Vcs-Browser is
read (which triggers the computation of its default value).


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1016670

Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1

[Dominique Dumont]

On Sunday, 31 July 2022 16:35:12 CEST Jérémy Lal wrote:
> Indeed, sorry for my somewhat irritated tone - it just happens that it was
> the second time libuv1 was updated during a nodejs transition, and the
> upstream bug it creates on nodejs hasn't been fixed yet, so it shoots the
> transition in the guts.
> Nodejs depends heavily on libuv1...

I understand your furstration. Sorry about the mess.

> Maybe a simple approach would be to upload libuv1 updates to experimental
> first, and wait a week to see how it scares the others :)

That I can do.

All the best.

Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1

[Dominique Dumont]

On Saturday, 30 July 2022 19:36:26 CEST you wrote:
> libuv1 is a library, you're supposed to manage the transition:
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions

This page applies when the new version breaks the ABI or API. This was not the 
case. There was no symbol change. The SO version of libuv1 has not changed 
since the transition between libuv and libuv1.

> In particular, rebuild all reverse build dependencies and check they won't 
break is highly desirable.
> There are tools and services in debian to do that (though honestly it's not 
so easy to setup).

I'm already stretched quite thin. I'll see what I can do.

In any case, I'd be happy to handover libuv1 to people willing to better 
maintain this package.

All the best.

Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1

[Dominique Dumont]

On Saturday, 30 July 2022 17:25:29 CEST you wrote:
> libuv1 maintainer: please avoid uploading new versions when nodejs is
> in transition...

I package libuv1 because it's a dependency of moarvm.

I don't follow nodejs releases, so I was not aware of on-going transition and 
I did not expect problems because only the minor version number was increased. 

On the other hand, I have no problem with delaying uploads of libuv1 provided 
someone warns me of issues in other packages.

All the best

Bug#1015034: closing 1015034, closing 1015110

[Dominique Dumont]

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

[Dominique Dumont]

On Saturday, 16 July 2022 15:55:05 CEST Lucas Nussbaum wrote:
> > Could not find Getopt::Long in:
> > /<>/debian/tmp/home/.raku

The real issue is the error above which comes from a bug in dh-raku.

The failed attempt to create directory '/usr/lib/perl6/site/short' is a 
warning. I'll deal with it later.

All the best

Bug#1002782: libconfig-model-backend-augeas-perl: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 255

[Dominique Dumont]

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

[Dominique Dumont]

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

but breaks on this entry:

Renamed-From:
 shlib-calls-exit

I need to replace the basic parsing with a proper parser for dpkg files.

All the best

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

[Dominique Dumont]

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
> 
> #   Failed test 'check scikit-learn copyright'
> #   at t/scanner/scan-copyright.t line 27.
> # --- t/scanner/examples/scikit-learn.out Thu Aug 19 00:15:51 2021
> # +++ /tmp/cKnQzIwFn2 Thu Aug 19 14:57:19 2021
> # @@ -2,3 +2,7 @@
> #  Copyright: 2007-2019, The scikit-learn developers.
> #  License: BSD-3-clause
> #  
> # +Files: sklearn/*
> # +Copyright: no-info-found
> # +License: BSD-3-clause
> # +
> #v-

Actually, this is related to:

https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/-/commit/fb4dbe585de59a8aeb5d01904869a7f3415e35a5

(Note: I found this commit while checking the history of t/scanner/examples/
scikit-learn.out)

> And I still can't reproduce the failure locally.
> *sigh*

I can reproduce this bug locally with libregexp-pattern-license-perl_3.4.0-1 
which is the version used in the FTBS build.

This bug is gone after installing libregexp-pattern-license-perl/unstable.

HTH

Bug#990561: libuv1: CVE-2021-22918

[Dominique Dumont]

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 buster and backport are also vulnerables.

I will upload a new package to unstable soon.

All the best.

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

[Dominique Dumont]

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 module is deprecated,
as shown uptream:

https://metacpan.org/pod/Protocol::ACME

This module is replaced by Net::ACME2:

https://metacpan.org/pod/Net::ACME2

Unfortunately, this information comes too late for bulleyes.

Anyway, I think this module should be removed from bulleyes as the
ACMEv1 API was removed.

All the best

Dod

-- System Information: Debian Release: 11.0 APT prefers unstable APT
policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libprotocol-acme-perl depends on:
ii  libcrypt-format-perl  0.10-1
ii  libcrypt-openssl-bignum-perl  0.09-1+b3
ii  libcrypt-openssl-rsa-perl 0.31-1+b3
ii  libcrypt-rsa-parse-perl   0.044-1
ii  libjson-perl  4.03000-1
ii  liblog-any-perl   1.709-1
ii  perl  5.32.1-4

libprotocol-acme-perl recommends no packages.

libprotocol-acme-perl suggests no packages.

-- no debconf information

Bug#987095: transitive_closure corrupted results, after vertex deleted

[Dominique Dumont]

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

[Dominique Dumont]

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 first bad commit
commit 3ded9c7a25bf190fda5add1a13ed4f9b54082db7
Author: Ed J 
Date:   Mon Dec 14 13:34:32 2020 +

all AdjacencyMap store _i as array-refs

 lib/Graph/AdjacencyMap.pm|  6 +-
 lib/Graph/AdjacencyMap/Heavy.pm  | 10 --
 lib/Graph/AdjacencyMap/Light.pm  |  9 ++---
 lib/Graph/AdjacencyMap/Vertex.pm |  8 ++--
 lib/Graph/AdjacencyMatrix.pm | 17 ++--
 lib/Graph/BitMatrix.pm   | 42 +
+--
 6 files changed, 34 insertions(+), 58 deletions(-)

All the best

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

[Dominique Dumont]

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
> > //vendor#sources/B4401FC2C8E71132AE0D3CE2C47A7D2FBB0D50F1 (App::Prove6)
> > Could not find Getopt::Long in:
> > CompUnit::Repository::Staging#name(vendor)#/tmp/qcmENjAngJ/build

prove6's /usr/share/perl6/debian-sources/prove6/prove6.p6deps file is empty. So 
rakudo does not build raku-getopt-long before prove6.

This is due to a bug in dh_perl6 which was fixed in version 0.4. I'll re-upload 
prove6 with a versioned dependency on dh_perl6 to fix this bug.

All the best

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

[Dominique Dumont]

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

[Dominique Dumont]

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 looking in the 
right place.

This is a regression compared to 2020.06.

On the other hand, shipping pre-compiled modules in /usr/lib may no longer be 
necessary if the pre-compiled files are binary independent. I need to check 
this point.

All the best

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

[Dominique Dumont]

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 library, I don't think that patching the build 
system to test an installed library is worth the effort, so I'm going to remove 
 
autopkgtest from libuv

I'm sorry that I did not realize sooner what was going on inside libuv build 
system.

All the best

Dod

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

[Dominique Dumont]

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 of autotools and the package builds fine.

Unfortunately, I don't see a way to build the test executable without building 
and linking a local libuv.

In this condition, is using autopkgtest on livuv1 worth the trouble ?

All the best

Dod

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

[Dominique Dumont]

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 allows the upgrade to proceed.

Indeed. It also caused build failures for raku modules...

I'm fixing this.

Thanks for the report.

All the best

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

[Dominique Dumont]

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

Dod

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

[Dominique Dumont]

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 best

Dod

Bug#935290: moar digging

[Dominique Dumont]

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 for '/usr/share/perl6/runtime/
perl6.moarvm': no such file or directory

/usr/share/perl6 is not a link on my machine:

$ ll /usr/share/perl6
total 8
drwxr-xr-x 5 root root 4096 Aug 31 19:28 debian-sources
-rw-r--r-- 1 root root   41 Jun 22  2018 previous-compiler-id

May be because /usr/share/perl6 existed before rakudo 2019-07 installation.

All the best

Dod

Bug#935290: moar digging

[Dominique Dumont]

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

Mo Zhou, can you follow-up and, if possible, release rakudo on unstable ?

All the best

Bug#935290: moar digging

[Dominique Dumont]

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

Thanks for digging this problem :-)

All the best

Dod

Bug#932637: nmu now in the delayed queue

[Dominique Dumont]

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.

I'm waiting for an upstream fix for rakudo. Probably with next release.

All the best

Dod

Bug#935290: rakudo: FTBFS on amd64

[Dominique Dumont]

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 do a git pull before trying. So I'm not able to 
build rakudo 2019-07 with libuv1 1.30.1 . I've nor tried as root user. Sorry 
about the confusion.

> I'm recently too busy to dig into these issues.

No problem. There's an upstream bug related to a similar issue on Arch linux:
https://github.com/rakudo/rakudo/issues/3090

I'm following up there.

All the best

Bug#935290: rakudo: FTBFS on amd64

[Dominique Dumont]

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 able to build rakudo 2019-07 on my system with latest 
libuv1.

I mean that I've built and installed new moarvm, then built and installed new 
nqp. Then rakudo builds fine.

Mho Zou, can you check on your side if your can build rakudo on your system ?

All the best

Dod

Bug#935290: rakudo: FTBFS on amd64

[Dominique Dumont]

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/debian/rakudo/usr/lib/perl6/core not
> writeable
>   in block  at
> /home/lumin/Debian/perl6/rakudo/tools/build/install-core-dist.p6 line
> 33

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.

All the best

Bug#935290: rakudo: FTBFS on amd64

[Dominique Dumont]

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 version of libuv1 is not 100% backward compatible.

Since rakudo 2019-07 (uploaded in experimental by Mho Zou) builds fine, I guess 
we should update rakudo, nqp and moar in unstable to fix this FTBS.

Mho Zou, could you upload your work in unstable ?

All the best

Dod

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

[Dominique Dumont]

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 
patch this test in libconfig-model-itself-perl.

Then I'll try to find a better solution upstream.

All the best

-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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 
inheritance, less so :-( )

I've released libconfig-model-itself-perl 2.018 with a change that fixes the 
tests with libconfig-model-tkui-perl 1.370 (but probably break with 1.369).

The log from auotpkgtest [1] in  the setup that should work shows this error:

ok 3 - Read all models from wr_root/load_write_itself/lib/Config/Model/models
Configuration item 'application:fstab model' has a wrong value:
reference type does not know 'Fstab'. Expected 'Itself::Application' or 
'Itself::CargoElement' or 'Itself::Class' or 'Itself::CommonElement' or 
'Itself::CommonElement::Assert' or 'Itself::CommonElement::WarnIfMatch' or 
'Itself::ComputedValue' or 'Itself::ConfigAccept' or 'Itself::ConfigReadWrite' 
or 'Itself::ConfigReadWrite::DefaultLayer' or 'Itself::Element' or 
'Itself::MigratedValue' or 'Itself::Model' or 'Itself::NonWarpableElement' or 
'Itself::WarpOnlyElement' or 'Itself::WarpValue' or 
'Itself::WarpableCargoElement' or 'Itself::WarpableElement'
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 2 just after 3.
Dubious, test returned 2 (wstat 512, 0x200)

This looks like cme is able to find the file /usr/share/perl5/Config/Model/
system.d/fstab , but is not able to load /usr/share/perl5/Config/Model/models/
Fstab.pl. Even though both files are provided by libconfig-model-perl. 

Given that I cannot reproduce this issue on my system, I guess that the setup 
of perl library in autopkgtest is different than the default setup.  I need to 
check how these files are found.

In any case the root cause for the failure of libconfig-model-itself-perl 2.018 
with libconfig-model-tkui-perl 1.370  is not the regression brought by 
libconfig-model-tkui-perl 1.370


All the best

[1] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/libc/libconfig-model-itself-perl/2796602/log.gz
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=libconfig-model-tkui-perl
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libconfig-model-it
> self-perl/2794069/log.gz
> 
> not ok 3 - edit is in test mode
> #   Failed test 'edit is in test mode'
> #   at t/cme-meta-edit.t line 34.
> #   'Reading model from /usr/share/perl5/Config/Model
> # '
> # doesn't match '(?^:Test mode: quit)'
> 1..3
> # Looks like you failed 1 test of 3.
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/3 subtests
> t/cme-meta-plugin.t 
> Prototype mismatch: sub CORE::GLOBAL::exit: none vs (;$) at
> /usr/lib/x86_64-linux-gnu/perl5/5.28/Tk.pm line 415.
> ok 1 - compiled
> not ok 2 - threw no exceptions
> #   Failed test 'threw no exceptions'
> #   at t/cme-meta-plugin.t line 52.
> #  got: 'Can't call method "fetch_element" on an undefined value
> at /usr/share/perl5/Config/Model/Itself/TkEditUI.pm line 80.
> #  at /usr/lib/x86_64-linux-gnu/perl5/5.28/Tk/Widget.pm line 203.
> # '
> # expected: undef
> ok 3 - edit plugin and quit
> not ok 4 - edit plugin is in test mode
> #   Failed test 'edit plugin is in test mode'
> #   at t/cme-meta-plugin.t line 57.
> #   'Preparing plugin my-plugin for model Fstab found in
> /usr/share/perl5/Config/Model
> # Use -dev option to create a plugin for a local model (i.e. in
> wr_test/plugin-ui)
> # '
> # doesn't match '(?^:Test mode: save and quit)'
> not ok 5 - check content of
> wr_test/plugin-ui/models/Fstab.d/my-plugin/Fstab/CommonOptions.pl
> #   Failed test 'check content of
> wr_test/plugin-ui/models/Fstab.d/my-plugin/Fstab/CommonOptions.pl'
> #   at t/cme-meta-plugin.t line 59.
> # Could not open file
> wr_test/plugin-ui/models/Fstab.d/my-plugin/Fstab/CommonOptions.pl: No
> such file or directory
> 1..5
> # Looks like you failed 3 tests of 5.
> 
> [...]
> 
> Test Summary Report
> ---
> t/cme-meta-edit.t(Wstat: 256 Tests: 3 Failed: 1)
>   Failed test:  3
>   Non-zero exit status: 1
> t/cme-meta-plugin.t  (Wstat: 768 Tests: 5 Failed: 3)
>   Failed tests:  2, 4-5
>   Non-zero exit status: 3
> t/itself-editor.t(Wstat: 6400 Tests: 6 Failed: 0)
>   Non-zero exit status: 25
>   Parse errors: No plan found in TAP output
> Files=11, Tests=85, 162 wallclock secs ( 0.07 usr  0.02 sys + 158.99
> cusr  2.99 csys = 162.07 CPU)
> Result: FAIL
> autopkgtest [17:14:40]: test autodep8-perl-build-deps:
> ---]


-- 

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

[Dominique Dumont]

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 spaces no matter how I set up the fonts.

What locale are you using ?

Could you try with "LC_ALL=C evolution" ?

All the best

Dod

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

[Dominique Dumont]

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 check that the mail source does contain the missing white spaces ?

Could you reproduce this bug with different font settings ?

All the best

Bug#924762: further information: window manager

[Dominique Dumont]

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 reproduce the bug while passing "-T foo" option to emacs ?
This will set the widget title to "foo" instead of "mär19"

HTH

Bug#921779: Bug#919413: cascade of FTBFS

[Dominique Dumont]

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.

We had a similar issue with libmojolicious-perl. This package now:
- removes jquery from source tarball [1] using debian/copyright Files-excluded 
parameter
- depends on libjs-jquery
- provides a symlink to Debian's query instead of the regular jquery file using 
  debian/libmojolicious-perl.links file [2]



HTH

[1] 
https://salsa.debian.org/perl-team/modules/packages/libmojolicious-perl/blob/master/debian/copyright#L7
[2] 
https://salsa.debian.org/perl-team/modules/packages/libmojolicious-perl/blob/master/debian/libmojolicious-perl.links

Bug#917036: Swaggers is indeed a goner

[Dominique Dumont]

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

[Dominique Dumont]

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

[Dominique Dumont]

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-shim": executable file not found in $PATH: unknown.
> 
> Apologies for troubles. I've fixed that in just uploaded 18.09.1+dfsg1-4.

Now, docker.io upgrade fails with:

Unpacking docker.io (18.09.1+dfsg1-4) over (18.06.1+dfsg1-3) ...
dpkg: error processing archive 
/var/cache/apt/archives/docker.io_18.09.1+dfsg1-4_amd64.deb (--unpack):
 trying to overwrite '/usr/bin/containerd-shim', which is also in package 
containerd 0.2.3+git20170126.85.aa8187d~ds1-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

I've fixed this problem by remove containerd pacakge.

But docker fails to start with:
$ docker run -ti alpine sh
docker: Error response from daemon: failed to start shim: exec: 
"docker-containerd-shim": executable file not found in $PATH: unknown.


All the best

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

[Dominique Dumont]

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 is 
greater than zero. Do you happen to know what that particular password file 
entry looks like?

Can you check the setup of the test system that showed this bug and reply on 
github ? [1]


All the best

[1] https://github.com/libuv/libuv/issues/2131

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

[Dominique Dumont]

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 the new value of standard-version. I've updated the tests, not by 
increasing the standard-version values set in the test fixtures (aka the 
debian/control files used by the tests), but by changing the tests to expect a 
warning about standard-version. This way the tests won't break at the next 
policy update.

> 
> Backend error: YAML::XS::Load Error: The problem:
> 
> invalid trailing UTF-8 octet
> 
> was found at document: 0
> Prototype mismatch: sub Config::Model::Tester::DEBUG () vs none at /usr/
share/perl5/Log/Log4perl.pm line 564.

This is another error where UTF-8 data was not handled properly with YAML::XS. 
This is fixed in libconfig-model-backend-yaml-perl 2.133. I've not updated the 
versioned dependency on libconfig-model-dpkg-perl because libconfig-model-
backend-yaml-perl is only in unstable at version 2.133.

Thanks for the report.

All the best

Bug#905614: Patch invalid

[Dominique Dumont]

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 of mushy brain and 
has changed his mind :-/

I'll use your patch more or less as-is. Sorry for the confusion.

All the best

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

[Dominique Dumont]

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 meaningful consumers of the
> summary_or_text method? 

Absolutely not. But keeping backward compat with already published modules is 
one of the best values of the Perl community. I intend to keep that promise as 
much as possible

> Your posting [1] restricts uses to Debian

Debian and its 100+ derivates. 

> , and
> a search on codesearch.debian.net shows no other packages that rely on
> the current implementation that produces a copyright notice with a
> full text but not with a summary. Why is the current implementation
> worth keeping? 

Because we can't be sure that nobody will be impacted. A user may be relying 
on summary_or_text but has not (or will not) publish her or his code.

> Please forgive me if I appear insistent. It's the only
> question I have.

No problem. You're right to challenge what is not clear :-)

All the best

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

[Dominique Dumont]

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

All the best

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

[Dominique Dumont]

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 about un-deprecating debian_text method and putting your code there 
?

All the best

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

[Dominique Dumont]

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 deprecated and exec /usr/share/perl6/tools/install-dist.p6.

This solution is not ideal. We will later provide a dh-install-p6 script. 
Until then, this hack should do.

Thoughts ?

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

[Dominique Dumont]

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 don't remember seeing this offer. No matter.

Shutter also needs to be ported on the replacement of libgoocanvas-perl.

All in all, I guess that 2 or 3 weeks of full time work are required to port 
shutter to more recent libraries. I don't have that kind of free time.

Sadly, I think the only option left is to remove shutter from Debian.

All the best

Bug#902107: closing 902107

[Dominique Dumont]

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

[Dominique Dumont]

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 afraid it's now completely obsoleted by 
modern JavaScript frameworks.  

> So I suggest that rather than
> spending any more time maintaining it, we remove it from Debian.

Agreed.

All the best

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

[Dominique Dumont]

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

I'll fix this upstream asap,

All the best

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

[Dominique Dumont]

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

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

[Dominique Dumont]

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

[Dominique Dumont]

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

All the best

[1] https://github.com/rakudo/rakudo/issues/1257#issuecomment-380568163

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

[Dominique Dumont]

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 agreed to 
change this strong dependency. [1]

I'm going to open a bug upstream to have this issue tracked.

All the best

[1] https://salsa.debian.org/perl6-team/rakudo/raw/master/debian/README.source

Bug#891304: closing 891304

[Dominique Dumont]

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

[Dominique Dumont]

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+Replaces relation.

Indeed... I'll fix this asap.

Thanks for the report.

All the best

Dod

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

[Dominique Dumont]

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

[Dominique Dumont]

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

[Dominique Dumont]

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 this applies to lintian. (I'll check what's required for cme).

All the best
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#862373: Unconditionally instantiates objects from yaml data

[Dominique Dumont]

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 from Data::Structure::Util to sanitize a 
data 
structure coming from untrusted source. 

This solution is probably easier than replacing YAML::XS with YAML::TIny (which 
is 
not always possible and behave differently with utf8)

All the best

[1] 
https://github.com/ingydotnet/yaml-libyaml-pm/issues/45#issuecomment-343678829
[2] 
https://github.com/ingydotnet/yaml-libyaml-pm/issues/45#issuecomment-343679429
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#862373: Unconditionally instantiates objects from yaml data

[Dominique Dumont]

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 the downside:
- application using YAML may need to be updated
- there's no similar method (yet ?) in other YAML implementations.

This is not an ideal solution, but is better than nothing...

Thoughts ?

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#875617: pan: Crashes when launching

[Dominique Dumont]

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 looks like this upstream 
report:

https://bugzilla.gnome.org/show_bug.cgi?id=754921

Can you try the workaroung shown there ?

All the best
-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org

Bug#862373: Unconditionally instantiates objects from yaml data

[Dominique Dumont]

> 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") ? "yes" : "no";'
yes
$ perl -E 'say UNIVERSAL->can("DESTROY") ? "yes" : "no";'
no
$ perl -MGetopt::Long -E 'say Getopt::Long->can("DESTROY") ? "yes" : "no";'
no

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

Ive logged a bug to upstream YAML parser library:

https://github.com/ingydotnet/yaml-pm/issues/176

HTH

Bug#861958: lintian: insecure YAML validation

[Dominique Dumont]

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 drop-in replacement.

> This module is happy to deserialize objects of any existing Perl class. For
> Lintian, the File::Temp::Dir class can be abused to remove arbitrary
> directory trees. (There might be other exciting ways to exploit this bug,
> but I'm too lazy to investigate further.)

I wonder if this behavior should be considered as a YAML bug...

All the best
-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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/packages/cme.git/commit/?id=fb45650

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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

All the best
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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) = @_;
> > > 
> > > -   return @{$target->{args}} if defined @{$target->{args}};
> > > +   return @{$target->{args}} if exists $target->{args};

A more defensive way is 

 return @{$target->{args}} if  ref($target->{args}) eq 'ARRAY';

> > > 
> > > my $noi = 1 if $target->{options}{noi};
> > > my $noo = 1 if $target->{options}{noo};
> > > 
> > > @@ -521,7 +521,7 @@ sub common_args($$$)
> > > 
> > > $target->{rrd} = $dir . '/' . $tdir . $name . '.rrd';
> > > 
> > > %{$target->{options}} = ()
> > > 
> > > -   unless defined %{$target->{options}};
> > > +   unless %{$target->{options}};

unless ref(target->{options}) eq 'HASH'

> > > 
> > > $dir = $cfg->{workdir};
> > > $dir = $cfg->{imagedir}
> > > 
> > > @@ -908,7 +908,7 @@ EOF
> > > 
> > > print $directories{$dir}{bodytag};
> > > 
> > > my $subdirs_printed;
> > > 
> > > -   if (defined @{$directories{$dir}{subdir}}) {
> > > +   if (exists $directories{$dir}{subdir}) {

if (ref($directories{$dir}{subdir}) eq 'ARRAY')

> > > 
> > > $subdirs_printed = 1;
> > > print < > >  
> > >  MRTG subdirectories in the directory $dir1
> > > 
> > > @@ -921,7 +921,7 @@ EOF
> > > 
> > > print "\n";
> > > 
> > > }
> > > 
> > > -   if (defined @{$directories{$dir}{target}}) {
> > > +   if (exists $directories{$dir}{target}) {

if (ref($directories{$dir}{target}) eq 'ARRAY')

> > > 
> > > print "\n" if defined $subdirs_printed;
> > > print < > >  
> > >  MRTG graphs in the directory $dir1

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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 upload this soon :-) as a nmu :-(

All the best
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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 can be done with 
zef:

https://github.com/ugexe/zef/issues/117

As for perl6-panda, I guess this package should be completely removed from 
Debian.

Thoughts ?

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#849659: hd44780 driver linked with wrong sem_wait

[Dominique Dumont]

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

[Dominique Dumont]

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

[Dominique Dumont]

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/bugreport.cgi?bug=841354

We'll handle powerpc and ppc64 once all arm arches are fine.

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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. I'll upload a new package soon.

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#837682: libconfig-model-itself-perl: FTBFS in unstable (failing tests)

[Dominique Dumont]

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 my side :-$ 
I can eschew a rewrite of model loader (for now...)

To be on the safe side, I need to update upstream both libconfig-model-perl 
and libconfig-model-itself-perl.

The first is done, the latter will be released in the next few days.

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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 expert to tell, so I leave that detail to you. If you
> need to reassign, just do. This time I'm using affects just from the
> beginning as an experiment to see if it works.

Confirmed :-(

Here's what I get on my system:
$ perl -I lib t/itself.t e
ok 1 - compiled
ok 2 - loaded Master model
ok 3 - created master_model instance
ok 4 - loaded some data in master_model instance
ok 5 - dumped master instance
ok 6 - Read Itself::Model and created instance
Configuration item has a configuration model declaration error:
load error: couldn't do 
.//usr/share/perl5/Config/Model/models/Itself/ConfigWR.d/augeas-backend.pl: No 
such file or directory
Exception thrown  at /usr/share/perl5/Config/Model/Exception.pm line 69.

Config::Model::Exception::rethrow(Config::Model::Exception::ModelDeclaration=HASH(0x39b3088))
 called at /usr/share/perl5/Config/Model/Exception.pm line 64

Config::Model::Exception::throw("Config::Model::Exception::ModelDeclaration", 
"message", "load error: couldn't do .//usr/share/perl5/Config/Model/model"...) 
called at /usr/share/perl5/Config/Model.pm line 1267
Config::Model::_do_model_file(Config::Model=HASH(0x2e88c50), 
"/usr/share/perl5/Config/Model/models/Itself/ConfigWR.d/augeas"...) called at 
/usr/share/perl5/Config/Model.pm line 1227
Config::Model::_load_model_in_hash(Config::Model=HASH(0x2e88c50), 
HASH(0x2ab1808), 
"/usr/share/perl5/Config/Model/models/Itself/ConfigWR.d/augeas"...) called at 
/usr/share/perl5/Config/Model.pm line 1204
Config::Model::load(Config::Model=HASH(0x2e88c50), "Itself::Class") 
called at /usr/share/perl5/Config/Model.pm line 1316
Config::Model::get_model(Config::Model=HASH(0x2e88c50), 
"Itself::Class") called at /usr/share/perl5/Config/Model/Role/NodeLoader.pm 
line 27

Config::Model::Role::NodeLoader::load_node(Config::Model::HashId=HASH(0x398a4a8),
 "element_name", "class", "index_value", "MasterModel", "instance", 
Config::Model::Instance=HASH(0x38b4780), "parent", 
Config::Model::Node=HASH(0x38c4218), ...) called at 
/usr/share/perl5/Config/Model/AnyId.pm line 889

Config::Model::AnyId::auto_vivify(Config::Model::HashId=HASH(0x398a4a8), 
"MasterModel") called at /usr/share/perl5/Config/Model/AnyId.pm line 688

Config::Model::AnyId::fetch_with_id(Config::Model::HashId=HASH(0x398a4a8), 
"MasterModel") called at lib/Config/Model/Itself.pm line 332
Config::Model::Itself::read_all(Config::Model::Itself=HASH(0x38c3e10), 
"root_model", "MasterModel", "legacy", "ignore") called at t/itself.t line 113


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

Thanks fo r the report

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[Dominique Dumont]

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 
Config::Model v2.089.

This bug is fixed in Config::Model 2.090 that will be packaged soon.

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

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

[Dominique Dumont]

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 exited on error.

The logs contains:

# Beginning subtest dpkg pan-copyright-upgrade-update
ok 813 - Copied dpkg example pan-copyright-upgrade-update
ok 814 - Read configuration and created instance with init() method without 
warning check
# updating config with quiet 1 in t/scanner/examples/pan.in
writing back cache file
Dubious, test returned 255 (wstat 65280, 0xff00)
All 814 subtests passed 

The last line here is a bit confusing, it means all tests were fine before the 
program crashed.

This is due to an error in the test which is now trapped by Config::Model 
since v2.089. 

This is fixed in git and will be uploaded quite soon.

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

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

[Dominique Dumont]

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, flash-kernel shows:

# flash-kernel
DTB: sun7i-a20-olinuxino-lime.dtb
Couldn't find 

Reading that, I thought that the dtb file was found, but something else was 
wrong.

Could you improve this error message ?

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#830403: closing 830403

[Dominique Dumont]

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

[Dominique Dumont]

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