Bug#1085912: chkboot: assumes system boots from /dev/sda

[Damyan Ivanov]

Package: chkboot
Version: 1.3-8.2
Severity: important

Hi,

After removing the last HDD from my system, chkboot started to complain 
with:

===
CHKBOOT ALERT!

Changes have been detected in your boot files!
The following list of files contained in have changed since the last time this 
script was run (filename sha512):
cat: /var/lib/chkboot/boot-differences: Отказан достъп

This notification will continue to appear until you either run "chkboot" again 
as root or restart your computer
===

The 'boot-differences' file is only readable by root and the root group, 
causing the message 'Отказан достъп' (Access denied), but it doesn't contain 
anything anyway:

===
root@pc1:/var/lib/chkboot# cat boot-differences
List of changed files on 23.10.2024 (ср) 12:38:01 EEST:

root@pc1:/var/lib/chkboot#
===

Running chkboot by hand leads to:

===
$ LANG=C sudo chkboot
diff: /var/lib/chkboot/DISKHEAD-last: No such file or directory
diff: /var/lib/chkboot/DISKHEAD-20241023-124645: No such file or directory
===

Running chkboot with 'bash -x' reveals that it tries to dd the first sector of 
/dev/sda into DISKHEAD-$stamp. There is no /dev/sda on my system anymore so 
that fails. Strangely, there is no error message displayed. Later, the 
DISKHEAD-latest symlink is pointed to the non-existing DISKHEAD-$stamp, leading 
to the error messages above.


Not sure what the right solution is. Skip boot sector checking if there is no 
/dev/sda? Checksum all EFI partitions?


-- Damyan


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.11.4-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chkboot depends on:
ii  init-system-helpers  1.67

chkboot recommends no packages.

Versions of packages chkboot suggests:
ii  x11-utils  7.7+7
ii  zenity 4.0.2-1

-- debconf-show failed

Bug#1082945: ITP: libmsoffice-word-surgeon-perl -- Perl module for modifying docx documents using regular expressions

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmsoffice-word-surgeon-perl
  Version : 2.08
  Upstream Author : Laurent Dami 
* URL : https://metacpan.org/release/MsOffice-Word-Surgeon
* License : Artistic-2.0
  Programming Lang: Perl
  Description : Perl module for modifying docx documents using regular 
expressions

MsOffice::Word::Surgeon supports a few operations for modifying or extracting
text from Microsoft Word documents in '.docx' format -- therefore the name
'surgeon'. There is no functionality for creating Word documents from
scratch.

The package is a dependency of libmsoffice-word-template-perl (ITP #1082943)
and will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1082942: ITP: libcarp-object-perl -- object-oriented replacement for Carp or Carp::Clan Perl modules

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcarp-object-perl
  Version : 1.02
  Upstream Author : Laurent Dami 
* URL : https://metacpan.org/release/Carp-Object
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : object-oriented replacement for Carp or Carp::Clan Perl 
modules

Carp::Object is an object-oriented alternative to Carp/croak or
Carp::Clan/croak, for reporting errors in modules from the perspective of the
caller instead of reporting the internal implementation line where the error
occurs.

Carp or Carp::Clan were designed long ago, at a time when Perl had no support
yet for object-oriented programming; therefore they only have a functional
API that is not very well suited for extensions. The present module attemps
to mimic the same behaviour, but with an object-oriented implementation that
offers more tuning options, and also supports errors raised as Exception
objects.

Unlike Carp or Carp::Clan, where the presentation of stack frames is
hard-coded, here it is delegated to Devel::StackTrace. This means that
clients can also take advantage of options in Devel::StackTrace to tune the
output -- or even replace it by another class.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1082943: ITP: libmsoffice-word-template-perl -- Perl module for creating Microsoft Word documents from Word templates

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmsoffice-word-template-perl
  Version : 2.04
  Upstream Author : Laurent Dami 
* URL : https://metacpan.org/release/MsOffice-Word-Template
* License : Artistic-2.0
  Programming Lang: Perl
  Description : Perl module for creating Microsoft Word documents from Word 
templates

MsOffice::Word::Template module treats a Microsoft Word document as a
template for generating other documents. The idea is similar to the "mail
merge" functionality in Word, but with much richer possibilities. The whole
power of a Perl templating engine can be exploited, for example for

 * dealing with complex, nested datastructures

 * using control directives for loops, conditionals, subroutines, etc.

 * defining custom data processing functions or macros

Template authors just use basic highlighing in MsWord to mark the templating
directives.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1082799: ITP: libmoosex-abstractmethod-perl -- Declare methods requirements that must be satisfied

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmoosex-abstractmethod-perl
  Version : 0.004
  Upstream Author : Chris Weyl 
* URL : https://metacpan.org/release/MooseX-AbstractMethod
* License : LGPL-2.1
  Programming Lang: Perl
  Description : Declare methods requirements that must be satisfied

Moosex::AbstractMethod allows classes to flag certain methods as being
required to be implemented by a subclass, much as a Moose::Role does with
'requires'.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1082781: qemu-system-misc: file conflict with opensbi 1.5.1-1 still present in 1:9.1.0+ds-6

[Damyan Ivanov]

Package: qemu-system-misc
Version: 1:9.1.0+ds-6
Followup-For: Bug #1082781

Control: reopen -1
Control: found -1 1:9.1.0+ds-6

The file conflict with opensbi 1.5.1-1 is still here:

 Unpacking opensbi (1.5.1-1) ...
 Selecting previously unselected package qemu-system-misc.
 Preparing to unpack .../qemu-system-misc_1%3a9.1.0+ds-6_amd64.deb ...
 Unpacking qemu-system-misc (1:9.1.0+ds-6) ...
 dpkg: error processing archive 
/var/cache/apt/archives/qemu-system-misc_1%3a9.1.0+ds-6_amd64.deb (--unpack):
  trying to overwrite 
'/usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.bin', which is also in 
package opensbi 1.5.1-1
 Errors were encountered while processing:
  /var/cache/apt/archives/qemu-system-misc_1%3a9.1.0+ds-6_amd64.deb

The contents of the binary package seem strange:

 $ dpkg-deb -c /var/cache/apt/archives/qemu-system-misc_1%3a9.1.0+ds-6_amd64.deb
 drwxr-xr-x root/root 0 2024-09-26 05:49 ./
 drwxr-xr-x root/root 0 2024-09-26 05:49 ./usr/
 …
 lrwxrwxrwx root/root 0 2024-09-26 05:49 ./\\ -> 
/usr/share/qemu/opensbi-riscv32-generic-fw_dynamic.bin
 …
 lrwxrwxrwx root/root 0 2024-09-26 05:49 
./usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.bin -> /\\
 …


-- Damyan

Bug#1082617: amanda-common: extremely inefficient output reading during restore/verify

[Damyan Ivanov]

Package: amanda-common
Version: 1:3.5.1-11+deb12u1
Severity: normal
Tags: upsteram,patch

Hi,

Currently, amrestore reads the "tar" program output and writes it to a debug 
file. The problem is that that output is read one byte at a time, which is very 
very inefficient and takes unreasonable amount of time for big dumps.

I run verification of the completed dumps and it is much slower than the dump 
itself - days vs. hours. The system load is heavily CPU-bound on the restore 
process.

The patch below reads the output in larger chunks and uses the Perl's 
instruments for splitting it into lines which are then forwarded to the debug 
logs as usual.

This makes the dump verification complete in a reasonable time and during that 
the system load is as expected - I/O and decompression.


Thanks for considering,
Damyan


--8<--8<---
--- /usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Restore.pm-ORIG
2024-09-16 11:00:39.045205405 +0300
+++ /usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Restore.pm 2024-09-23 
14:41:25.973046593 +0300
@@ -551,7 +551,7 @@
 $self->{'all_filter'}->{$src} = 1;
 $src->set_callback( sub {
my $b;
-   my $n_read = POSIX::read($fd, $b, 1);
+   my $n_read = POSIX::read($fd, $b, 4096*16);
if (!defined $n_read) {
   return;
} elsif ($n_read == 0) {
@@ -563,9 +563,8 @@
   }
} else {
   $buffer .= $b;
-  if ($b eq "\n") {
-   my $line = $buffer;
-   chomp $line;
+  while ($buffer =~ s/^([^\n]*)\n//) {
+   my $line = $1;
 #  if (length($line) > 1) {
   if ($line !~ /trailing garbage ignored/) {
my $msg_severity;
@@ -586,7 +585,6 @@
line=> $line));
   }
 #  }
-   $buffer = "";
   }
}
 });
--8<--8<---

Bug#1079031: dracut-install: symbol lookup error in dracut-install leads to mostly empty initrd

[Damyan Ivanov]

Package: dracut-install
Version: 103-1
Severity: grave

 $ sudo update-initramfs -k 6.10.4-amd64 -u
 update-initramfs: Generating /boot/initrd.img-6.10.4-amd64
 /usr/lib/dracut/dracut-install: symbol lookup error: 
/usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, 
version LIBKMOD_5
 /usr/lib/dracut/dracut-install: symbol lookup error: 
/usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, 
version LIBKMOD_5
 /usr/lib/dracut/dracut-install: symbol lookup error: 
/usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, 
version LIBKMOD_5

The resulting initrd contains much less:

 $ sudo lsinitramfs /boot/initrd.img-6.10.4-amd64|wc -l
 586

Compare this with an initrd generated with dracut-install version 102-3:

 $ sudo lsinitramfs /boot/initrd.img-6.10.3-amd64|wc -l
 1845

The much smaller initrd contains only 5 kernel modules and misses USB support,
disk encryption, md, lvm... it is totally unusable.

Here's a link to the working dracut-install version:

https://snapshot.debian.org/package/dracut/102-3/#dracut-install_102-3


-- Damyan

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.10.3-amd64
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dracut-install depends on:
ii  libc6 2.39-7
ii  libkmod2  33+20240816-1

dracut-install recommends no packages.

dracut-install suggests no packages.

Bug#1065474: syncthing-gtk: regular expression syntax warnings

[Damyan Ivanov]

Package: syncthing-gtk
Version: 0.9.4.4+ds+git20221205+12a9702d29ab-2
Severity: minor

Hi,

During package configuration, the following warnings are issued:

Setting up syncthing-gtk (0.9.4.4+ds+git20221205+12a9702d29ab-2) ...
/usr/lib/python3/dist-packages/syncthing_gtk/app.py:924: SyntaxWarning: 
invalid escape sequence '\('
  version = re.search("protocol \(([^\)]+)\)", message)
/usr/lib/python3/dist-packages/syncthing_gtk/foldereditor.py:24: 
SyntaxWarning: invalid escape sequence '\-'
  RE_GEN_ID = re.compile("([a-zA-Z0-9\-\._]{1,64}).*")


-- Damyan


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.7-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages syncthing-gtk depends on:
ii  gir1.2-glib-2.0 1.78.1-16
ii  gir1.2-gtk-3.0  3.24.41-1.1
ii  gir1.2-notify-0.7   0.8.3-1
ii  gir1.2-rsvg-2.0 2.54.7+dfsg-2
ii  libgtk-3-0t64 [libgtk-3-0]  3.24.41-1.1
ii  python3 3.11.8-1
ii  python3-bcrypt  3.2.2-1
ii  python3-dateutil2.8.2-3
ii  python3-gi  3.47.0-3
ii  python3-gi-cairo3.47.0-3

Versions of packages syncthing-gtk recommends:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.93-1
ii  syncthing1.27.2~ds4-1

Versions of packages syncthing-gtk suggests:
ii  python3-nautilus  4.0-1+b1

-- no debconf information

Bug#1061241: endless-sky: debian/copyright incomplete

[Damyan Ivanov]

Package: endless-sky
Version: 0.10.4-1
Severity: serious
Justification: Policy 2.3, 12.5

The upgrade to 0.10.4 missed the changes in upstream licensing and 
copyright notices.

The changes in the summary, as supplied by upstream, can be seen at
https://salsa.debian.org/games-team/endless-sky/-/commit/d7fef4cf2282a3ab364133093e5f156bc5f1d790#521307ddb67a4abc14248801dae5e5989aca76c1

Note that this 'copyright' file looks much like Debian's 
'debian/copyright' but fails some expectations like listing general 
Files: patterns before more specific ones so it can't be used verbatim.


-- Damyan


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.11-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages endless-sky depends on:
ii  endless-sky-data  0.10.4-1
ii  libc6 2.37-13
ii  libgcc-s1 13.2.0-10
ii  libglew2.22.2.0-4+b1
ii  libglx0   1.7.0-1
ii  libjpeg62-turbo   1:2.1.5-2+b2
ii  libmad0   0.15.1b-10.1+b1
ii  libopenal11:1.23.1-4
ii  libopengl01.7.0-1
ii  libpng16-16   1.6.40-3
ii  libsdl2-2.0-0 2.28.5+dfsg-3
ii  libstdc++613.2.0-10
ii  libuuid1  2.39.3-6

endless-sky recommends no packages.

endless-sky suggests no packages.

-- no debconf information

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Damyan Ivanov]

-=| Trent W. Buck, 08.08.2023 10:51:17 +1000 |=-
> On Tue 13 Dec 2022 22:04:40 +0200, Damyan Ivanov wrote:
> > The package is more or less ready at
> > <https://salsa.debian.org/games-team/endless-sky> (-high-dpi at
> > <https://salsa.debian.org/games-team/endless-sky-high-dpi>, probably
> > needs a bit more work).
> 
> FYI I had a go this morning and got a "clean room" version working with 
> cmake+ninja, ignoring scons.
> This seems to be consistent with what upstream docs currently recommend.
> 
> https://github.com/cyberitsolutions/bootstrap2020/tree/twb/debian-12-PrisonPC.packages/endless-sky/debian
> 
> I only got it working enough for me, so e.g. debian/copyright isn't set up 
> properly.
> It builds and installs and runs, though - I did the tutorial mission string 
> as a test.
> 
> I did not get the tests working, because I think cmake+make was
> starting $(nproc) separate instances of the game at once to do tests,
> and my laptop kept OOMing.  I didn't go back after I switchde to cmake+ninja.
> 
> Looking at Damyan's version from last year,
> I think the only novel/interesting thing in mine is the rules file.
> The rest is pretty boring.
> I also used upstream's current README text for Description, instead
> of Michael's original description from 5+ years ago.

Thanks!

I think I integrated your work in the salsa repository and version 
0.10.2-1 is very close to be ready for uploading. Even the tests seem 
to run locally (I need to try to disable debug tests which are very 
slow).

The only thing to fix are the lintian warnings about debian/copyright. 
These need some careful investigation and/or discussion with the 
upstream authors to get right.


-- Damyan

Bug#1030658: More info needed on the RC bug you opened

[Damyan Ivanov]

-=| Martin Quinson, 22.02.2023 08:58:42 +0100 |=-
> tag 1030658 +moreinfo
> thanks
> 
> Hello Damyan,
> 
> sorry for not noticing this bug before, I thought I was subscribed to the
> package.

No problem.

Today, however, everything works again. I tried on two systems 
tracking sid, including the one I used to report the issue. Strange.

> It looks like a missing dependency to me. Could you please give me 
> the output
> of `ldd /usr/bin/zeal` ?

linux-vdso.so.1 (0x7fff9f3be000)
libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 
(0x7fa243c0)
libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 
(0x7fa24360)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fa2434a1000)
libQt5Concurrent.so.5 => /lib/x86_64-linux-gnu/libQt5Concurrent.so.5 
(0x7fa2443a)
libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 
(0x7fa242c0)
libQt5Network.so.5 => /lib/x86_64-linux-gnu/libQt5Network.so.5 
(0x7fa2432f7000)
libQt5WebEngineWidgets.so.5 => 
/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5 (0x7fa244352000)
libQt5WebEngineCore.so.5 => 
/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 (0x7fa23aa0)
libQt5WebChannel.so.5 => /lib/x86_64-linux-gnu/libQt5WebChannel.so.5 
(0x7fa24432c000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7fa242abe000)
libQt5X11Extras.so.5 => /lib/x86_64-linux-gnu/libQt5X11Extras.so.5 
(0x7fa244325000)
libxcb-keysyms.so.1 => /lib/x86_64-linux-gnu/libxcb-keysyms.so.1 
(0x7fa23a60)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x7fa2442f9000)
libarchive.so.13 => /lib/x86_64-linux-gnu/libarchive.so.13 
(0x7fa23a938000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fa23a20)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fa2442d9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa23a41f000)
/lib64/ld-linux-x86-64.so.2 (0x7fa24451f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa23a859000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fa2442b8000)
libdouble-conversion.so.3 => 
/lib/x86_64-linux-gnu/libdouble-conversion.so.3 (0x7fa243beb000)
libicui18n.so.72 => /lib/x86_64-linux-gnu/libicui18n.so.72 
(0x7fa239e0)
libicuuc.so.72 => /lib/x86_64-linux-gnu/libicuuc.so.72 
(0x7fa239c02000)
libpcre2-16.so.0 => /lib/x86_64-linux-gnu/libpcre2-16.so.0 
(0x7fa243b5d000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fa23a144000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 
(0x7fa239aca000)
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x7fa239a43000)
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 
(0x7fa242a88000)
libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 
(0x7fa23993f000)
libmd4c.so.0 => /lib/x86_64-linux-gnu/libmd4c.so.0 (0x7fa2432e5000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7fa23a807000)
libQt5Quick.so.5 => /lib/x86_64-linux-gnu/libQt5Quick.so.5 
(0x7fa23920)
libQt5PrintSupport.so.5 => 
/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5 (0x7fa2398cb000)
libQt5QuickWidgets.so.5 => 
/lib/x86_64-linux-gnu/libQt5QuickWidgets.so.5 (0x7fa2432d)
libQt5Qml.so.5 => /lib/x86_64-linux-gnu/libQt5Qml.so.5 
(0x7fa238c0)
libQt5Positioning.so.5 => /lib/x86_64-linux-gnu/libQt5Positioning.so.5 
(0x7fa23983d000)
libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x7fa2390a7000)
libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so 
(0x7fa23980b000)
libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x7fa2397c9000)
libevent-2.1.so.7 => /lib/x86_64-linux-gnu/libevent-2.1.so.7 
(0x7fa239772000)
libjpeg.so.62 => /lib/x86_64-linux-gnu/libjpeg.so.62 
(0x7fa238b6d000)
libopus.so.0 => /lib/x86_64-linux-gnu/libopus.so.0 (0x7fa238b0f000)
libvpx.so.7 => /lib/x86_64-linux-gnu/libvpx.so.7 (0x7fa23880)
libXcomposite.so.1 => /lib/x86_64-linux-gnu/libXcomposite.so.1 
(0x7fa2442ab000)
libXdamage.so.1 => /lib/x86_64-linux-gnu/libXdamage.so.1 
(0x7fa243b58000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x7fa242a73000)
libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 
(0x7fa242a6b000)
libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 
(0x7fa23a137000)
libXtst.so.6 => /lib/x86_64-linux-gnu/libXtst.so.6 (0x7fa242a63000)
libwebpmux.so.3 => /lib/x86_64-linux-gnu/libwebpmux.so.3 
(0x7fa23a12b000)
libwebpdemux.so.2 => /lib/x86_64-linux-gnu/libwebpdemux.so.2 
(0x7fa23976c000)
libwebp.so.7 => /lib/x86_64-linux-gnu/libwebp.so

Bug#1030697: libjs-bootstrap5: not co-installable with libjs-bootstrap4

[Damyan Ivanov]

Package: libjs-bootstrap5
Version: 5.2.3+dfsg-7
Followup-For: Bug #1030697

Control: found -1 5.2.3+dfsg-7

Still can't install the package with libjs-bootstrap4 installed:

 Preparing to unpack .../libjs-bootstrap5_5.2.3+dfsg-7_all.deb ...
 Unpacking libjs-bootstrap5 (5.2.3+dfsg-7) ...
 dpkg: error processing archive 
/var/cache/apt/archives/libjs-bootstrap5_5.2.3+dfsg-7_all.deb (--unpack):
  trying to overwrite '/usr/share/nodejs/bootstrap/package.json', which is also 
in package libjs-bootstrap4 4.6.1+dfsg1-4
 Errors were encountered while processing:
  /var/cache/apt/archives/libjs-bootstrap5_5.2.3+dfsg-7_all.deb


-- Damyan

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-4-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libjs-bootstrap5 depends on:
ii  libjs-popper.js  1.16.1+ds-6

libjs-bootstrap5 recommends no packages.

Versions of packages libjs-bootstrap5 suggests:
ii  bootstrap-icons   1.10.3+dfsg-1
ii  libjs-bootstrap5-doc  5.2.3+dfsg-7

Bug#1030658: fail to retrieve docset info: TLS initialization failed (caused by unresolved OpenSSL symbols)

[Damyan Ivanov]

Package: zeal
Version: 1:0.6.1+git20220714+6fee23-2
Severity: grave

This problem makes it impossible to download docsets and start using Zeal, thus 
the severity.

I observe this error since months, so it is not related to a recent change in 
some other package. Sorry for not reporting it earlier.

Trying to retrieve docsets fails with:

Download failed!

Error: TLS initialization failed
URL: https://api.zealdocs.org/v1/docsets

[Cancel][Retry]

The console contains the following:
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_init_crypto
qt.network.ssl: QSslSocket: cannot resolve ASN1_STRING_get0_data
qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_reset
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_up_ref
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_CTX_new
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_param_check
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_CTX_free
qt.network.ssl: QSslSocket: cannot resolve RSA_bits
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_new_null
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_push
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_free
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_num
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_pop_free
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_value
qt.network.ssl: QSslSocket: cannot resolve DH_get0_pqg
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_options
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_get_security_level
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_security_level
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_ciphersuites
qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_use_session_callback
qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_is_resumable
qt.network.ssl: QSslSocket: cannot resolve SSL_get_client_random
qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_get_master_key
qt.network.ssl: QSslSocket: cannot resolve SSL_session_reused
qt.network.ssl: QSslSocket: cannot resolve SSL_set_options
qt.network.ssl: QSslSocket: cannot resolve TLS_method
qt.network.ssl: QSslSocket: cannot resolve TLS_client_method
qt.network.ssl: QSslSocket: cannot resolve TLS_server_method
qt.network.ssl: QSslSocket: cannot resolve X509_up_ref
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get0_chain
qt.network.ssl: QSslSocket: cannot resolve X509_getm_notBefore
qt.network.ssl: QSslSocket: cannot resolve X509_getm_notAfter
qt.network.ssl: QSslSocket: cannot resolve X509_get_version
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_set_verify_cb
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_set_ex_data
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_get_ex_data
qt.network.ssl: QSslSocket: cannot resolve OpenSSL_version_num
qt.network.ssl: QSslSocket: cannot resolve OpenSSL_version
qt.network.ssl: Incompatible version of OpenSSL
qt.network.ssl: QSslSocket: cannot call unresolved function d2i_X509
(repeats numerous times)
qt.network.ssl: QSslSocket::connectToHostEncrypted: TLS initialization failed

Rebuilding the package using current unstable didn't help.


-- Damyan


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages zeal depends on:
ii  libarchive13 3.6.2-1
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libqt5concurrent55.15.8+dfsg-2
ii  libqt5core5a 5.15.8+dfsg-2
ii  libqt5gui5   5.15.8+dfsg-2
ii  libqt5network5   5.15.8+dfsg-2
ii  libqt5sql5-sqlite5.15.8+dfsg-2
ii  libqt5webchannel55.15.8-2
ii  libqt5webenginecore5 5.15.12+dfsg-3
ii  libqt5webenginewidgets5  5.15.12+dfsg-3
ii  libqt5widgets5   5.15.8+dfsg-2
ii  libqt5x11extras5 5.15.8-2
ii  libsqlite3-0 3.40.1-1
ii  libstdc++6   12.2.0-14
ii  libx11-6 2:1.8.3-3
ii  libxcb-keysyms1  0.4.0-1+b2
ii  libxcb1  1.15-1

zeal recommends no packages.

zeal suggests no packages.

-- no debconf information

Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705

[Damyan Ivanov]

-=| Jose M Calhariz, 02.02.2023 19:20:23 + |=-
> This is my first security update, can I ask what is the procedure or 
> where is documented?

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-security-building

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-security


-- Damyan


> On January 28, 2023 12:59:09 PM GMT+00:00, Salvatore Bonaccorso
>  wrote:
> 
> Source: amanda
> Version: 1:3.5.1-9
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerabilities were published for amanda.
> 
> CVE-2022-37704[0], CVE-2022-37705[1].
> 
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2022-37704
> https://www.cve.org/CVERecord?id=CVE-2022-37704
> [1] https://security-tracker.debian.org/tracker/CVE-2022-37705
> https://www.cve.org/CVERecord?id=CVE-2022-37705
> [2] https://github.com/zmanda/amanda/issues/192
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore
> 

Bug#1028520: flamerobin: Crash on opening SQL Editor

[Damyan Ivanov]

Control: tag -1 confirmed

-=| Elmar Haneke, 12.01.2023 10:20:32 +0100 |=-
> Package: flamerobin
> Version: 0.9.6.ds.1-1+b2
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Problem is reproducable with
> - start flamerobin
> - connect to some database
> - select context-Menu "open SQL Editor"

I can reproduce this.

After some fiddling, I managed to see the two error messages that 
appear briefly before flamerobin is terminated. One is the standard 
"An error has occurred, do you want to try and continue", and the 
other says "can't open file 
'/usr/share/dlamerobin/xml-styles/stylers.xml' (error 2: No such file 
or directory)".

This is understandable, since the file in question is removed from the 
sources for the Debian package due to missing licensing information.

I'll see if another file can be used by default and if upstream can 
clarify on the licensing.


-- Damyan

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Damyan Ivanov]

A quick update.

The package is more or less ready at 
 (-high-dpi at 
, probably 
needs a bit more work). However, the confusing copyright statements 
issue¹ is a show stopper.

Can you guys do something about it?

 ¹ https://github.com/endless-sky/endless-sky/issues/7711


-- Damyan

Bug#1002856: RFP: openrgb -- Control RGB devices

[Damyan Ivanov]

-=| Olek Wojnar, 04.12.2022 21:25:04 -0500 |=-
> Hi there,
> 
> > I just had a quick look at the source code. The problem are the vendored
> > headers in the dependencies/ folder. Per debian policy they need to be
> > packaged themselves.
> 
> I was just looking at this package as well and I was a bit confused by your
> comment. What exactly are you seeing in the dependencies folder that would
> require separate library packages?

Basically everything that is not authored by the OpenRGB developers as 
part of OpenRGB? I would guess most of the content under dependencies 
is just copied from somewhere for convenience.

> Could you also please point me to the policy that requires this?

 4.13. Embedded code copies
 ==

 Some software packages include in their distribution convenience 
 copies of code from other software packages, generally so that users 
 compiling from source don’t have to download multiple packages. 
 Debian packages should not make use of these convenience copies 
 unless the included package is explicitly intended to be used in this 
 way.  [17]
 If the included code is already in the Debian archive in the form of 
 a library, the Debian packaging should ensure that binary packages 
 reference the libraries already in Debian and the convenience copy is 
 not used. If the included code is not already in Debian, it should be 
 packaged separately as a prerequisite if possible.  [18]

 [17] For example, parts of the GNU build system work like this.

 [18] Having multiple copies of the same code in Debian is 
  inefficient, often creates either static linking or shared 
  library conflicts, and, most importantly, increases the 
  difficulty of handling security vulnerabilities in the 
  duplicated code.

So it is not strictly required, but a strong recommendation:

 * The terms *should* and *should not*, and the adjective 
   *recommended*, denote best practices. Non-conformance with these 
   guidelines will generally be considered a bug, but will not 
   necessarily render a package unsuitable for distribution. These 
   statements correspond to bug severities of *important*, *normal*, 
   and *minor*. They are collectively called *Policy recommendations*.

If you go with the bundles, don't forget to add them to the security 
tracker at 
https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies



 -- Damyan, hoping for the best

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Damyan Ivanov]

Hi!

[dropped most of CC]

Sorry it took me so long to respond.

-=| quyykk, 18.11.2022 14:06:02 + |=-
> On Sun, Nov 13, 2022, 14:13 Damyan Ivanov,  
> wrote:
> 
> Hello Zitchas,
> 
> -=| Zitchas Z, 11.11.2022 14:24:57 -0700 |=-
> > Good day everyone,
> >
> > To start off, I have a few questions for you in regards to this.
> Sorry for the
> > quantity, I haven't been part of the process of getting a game into
> Debian
> > before, so I'm not sure on done of the terminology or what it
> entails.
> 
> In short: I am volunteering to maintain the Debian package (plus
> endless-sky-high-dpi) and this doesn't require that you do anything
> but produce the great game you already do :) Maybe answer
> a copyright/license question or respond to a bug report/patch from
> time to time, but that should be business as usual.
> 
> 
> Feel free to CC me for any questions/bugs/etc. (Is there a way to subscribe to
> emails
> from a specific package, or do I have to subscribe to the mailing list?)

There is. You need to register on <https://tracker.debian.org/>, then 
go to <https://tracker.debian.org/endless-sky> and press the 
'Subscribe' button. Same on 
<https://tracker.debian.org/endless-sky-high-dpi>. Alternatively you 
can subscribe using email only, see 
<https://qa.pages.debian.net/distro-tracker/usage/messages.html#subscribing-to-a-package>

> 
> I looked at the patches you made, and we can upstream them easily, if that's
> fine by you.

Yes, but there is no rush. I will submit them as PRs on github 
eventually.
> Some of the fixes you made to the copyright file have actually 
> already been
> fixed upstream
> (but aren't in an actual release yet).

There are more (minor) problems with the copyright summary. I will 
create issues/PRs about them for easier tracking (one already created 
- #7711).


Best regards,
Damyan

Bug#1024249: wordpress: update to 5.7.8+dfsg1-0+deb11u1 have missing dependencies in bullseye-security

[Damyan Ivanov]

Package: wordpress
Version: 5.7.8+dfsg1-0+deb11u1
Followup-For: Bug #1024249

severity 1024249 grave

The unsatisfiable dependencies make the package uninstallable using only 
bullseye + bullseye-security, raising the severity.


-- Damyan

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Damyan Ivanov]

Hello Zitchas,

-=| Zitchas Z, 11.11.2022 14:24:57 -0700 |=-
> Good day everyone,
> 
> To start off, I have a few questions for you in regards to this. Sorry for the
> quantity, I haven't been part of the process of getting a game into Debian
> before, so I'm not sure on done of the terminology or what it entails.

In short: I am volunteering to maintain the Debian package (plus 
endless-sky-high-dpi) and this doesn't require that you do anything 
but produce the great game you already do :)  Maybe answer 
a copyright/license question or respond to a bug report/patch from 
time to time, but that should be business as usual.


> 1. What do we need to do to facilitate updates to Endless Sky being 
> packaged and made available here?

Technically, somebody with a key in the keyring needs to upload 
a "source package" to the Debian infrastructure. This gets built 
automatically on the various architectures supported by Debian and the 
results are made (automatically) available for download through the 
Debian package repositories, mirrored worldwide.

Such Debian "source package" usually requires only an additional 
"debian/" directory along with the upstream sources. debian/ contains 
various metadata and instructions for building the binary packages.

So far the source package was taken care of by Michael and uploaded by 
a couple of Debian developers.

> 2. There had been mention of having someone as co-maintainer, sponsor/mentor,
> and the option of having this under the group maintenance of the Debian Games
> group. What would be involved in each of these options? Are these mutually
> exclusive options, or complimentary?

"Maintainer" would be the primary contact about the package. The 
person doing most of the work. Co-maintainers are other people who 
help and are also considered "authority" about what is done and how 
with regard to the packaging.

"Sponsor" would be somebody with a key in the keyring who can upload 
the package, after a review. "Mentor" would be someone who guides the 
maintainer and helps them learn. Usually the mentor is also a sponsor.

With the Games team option, the team would be "maintainer" with 
individual members who have interest in the package listed as 
co-maintainers.

This is the option that seems natural to me, with Michael stepping 
down[0] from maintainer position. I am interested in the package so 
I'll be listed as co-maintainer. Having the team as maintainer allows 
other team members to help when needed.

[0] https://lists.debian.org/debian-devel-games/2022/11/msg8.html

> 3. What sort of long term commitment do we need of someone takes on
> responsibility for handling this? Is this someone who just needs to do a 
> build,
> test, and upload the game each update? Is there likely to be additional 
> editing
> and adjustment required?

You can see the history of the Git repository[1] in which I worked on 
the upgrade to 0.9.16 for the details but in short, the one big thing 
I had to do to was to make sure that all copyright/licensing changes 
are properly reflected in the debian/copyright file. By the way, I am 
impressed of how good this is presented upstream. Really made the job 
easier :)

[1] https://salsa.debian.org/dmn/endless-sky

> have our
> GitHub repository setup to automatically build releases for MacOS, Windows, 
> and
> an appimage. Can the Debian build feasibly be done alongside these?

I guess you can make a CI produce .deb packages, but these can't be 
made part of the official Debian repositories, not without a real 
person with a key in the Debian keyring uploading the source package 
(after a review).

> 5. Does whoever does this require any permissions beyond the publicly 
> available
> source code and data? (There is no secret data/code, it is all 
> publicly
> visible).

Preparing the source package needs someone doing the work. Uploading 
to Debian requires a GPG key in the keyring. This is much more 
involved and requires completing the New maintainer process[2]

[2] https://www.debian.org/devel/join/


Not sure if my answers settle down your questions. I am happy to try 
to clarify any dim points.


-- Damyan


signature.asc
Description: PGP signature

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Damyan Ivanov]

(resent with the correct games team address; sorry for the duplicate)

-=| Job Bautista, 01.08.2020 08:13:08 + |=-
> Just in case someone wonders if this is being worked on, MZ uploaded a 
> 0.9.12-1 package at mentors.debian.net[1]. He's just waiting for a sponsor to 
> upload it to the main archive. If you want, you can dget the dsc file and 
> build the package yourself.
> 
> Regards,
> 
> Job Bautista
> 
> [1]: https://mentors.debian.net/package/endless-sky/

Two years later, this is no longer available and endless-sky is at 
version 0.9.16.1.

I have taken the liberty to upgrade the package (locally) from 
0.9.8-1.2 to 0.9.16.1 and started a salsa project to track the 
changes. The result is at . 
It is not 100% ready yet, but looks quite nice. At this point I wonder 
how to proceed.

Michael, would you like a co-maintainer for the Debian package? 
Perhaps even a group-maintenance under the Debian Games Team (cc-ed)? 
Either should help timely upgrades in Debian.

Thanks for the great additions to the storyline :)


-- Damyan


signature.asc
Description: PGP signature

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Damyan Ivanov]

-=| Job Bautista, 01.08.2020 08:13:08 + |=-
> Just in case someone wonders if this is being worked on, MZ uploaded a 
> 0.9.12-1 package at mentors.debian.net[1]. He's just waiting for a sponsor to 
> upload it to the main archive. If you want, you can dget the dsc file and 
> build the package yourself.
> 
> Regards,
> 
> Job Bautista
> 
> [1]: https://mentors.debian.net/package/endless-sky/

Two years later, this is no longer available and endless-sky is at 
version 0.9.16.1.

I have taken the liberty to upgrade the package (locally) from 
0.9.8-1.2 to 0.9.16.1 and started a salsa project to track the 
changes. The result is at . 
It is not 100% ready yet, but looks quite nice. At this point I wonder 
how to proceed.

Michael, would you like a co-maintainer for the Debian package? 
Perhaps even a group-maintenance under the Debian Games Team (cc-ed)? 
Either should help timely upgrades in Debian.

Thanks for the great additions to the storyline :)


-- Damyan


signature.asc
Description: PGP signature

Bug#1021817: firebird3.0: undistributable source files

[Damyan Ivanov]

Source: firebird3.0
Version: 3.0.1.32609.ds4-14
Severity: serious
Tags: upstream
Justification: Policy 2.1 (DFSG)
Forwarded: https://github.com/FirebirdSQL/firebird/issues/7349

Four files in src/intl/ contain contradictory statements from Unicode Inc, 
claiming that the file cannot be redistributed, and from Inprise Corporation, 
claiming it is licensed under the Interbase Public License (which allows 
redistribution; it is an MPL-like license).

src/intl/charsets/cs_big5.h
src/intl/charsets/cs_jis_0208_1990.h
src/intl/charsets/cs_next.h
src/intl/charsets/cs_sjis.h

Hopefully this can be resolved upstream. Otherwise the four files above would 
need to be excluded from the sources used by the Debian package and therefore 
lose support for the corresponding national character sets.

-- Damyan

Bug#1020438: ITP: libtwiggy-tls-perl -- Twiggy server with TLS support

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtwiggy-tls-perl
  Version : 0.0020
  Upstream Author : Serhii Zasenko 
* URL : https://metacpan.org/release/Twiggy-TLS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Twiggy server with TLS support

Twiggy is a lightweight and fast HTTP iserver that can run PSGI 
applications.

Twiggy::TLS adds TLS support via Twiggy::Server::TLS - a subclass of
Twiggy::Server.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1017375: liblexical-accessor-perl: test failure with Sub::HandlesVia 0.034

[Damyan Ivanov]

-=| gregor herrmann, 17.08.2022 17:59:41 +0200 |=-
> This should be fixed with libsub-handlesvia-perl 0.035, judging from
> the following upstream commit:
> …
> Also Changes say:
>  - Sub::HandlesVia::CodeGenerator method_installer is now a rw attribute as
>Sub::Accessor::Small was relying on that.
> 
> 
> I'm going to upload libsub-handlesvia-perl now, then we can depend on
> the fixed version to close this bug, I guess?

build-time and run-time dependency version bumped, all tests pass, so 
uploaded.

Thank you for the investigation.


-- Damyan

Bug#1017528: aborts at startup: Using libsoup2 and libsoup3 in the same process is not supported

[Damyan Ivanov]

Package: gtranslator
Version: 42.0-1
Severity: grave

On an up to date unstable, gtranslator aborts at startup:

(gtranslator:58389): libsoup-ERROR **: 13:25:11.006: libsoup3 symbols 
detected. Using libsoup2 and libsoup3 in the same process is not supported.
zsh: trace trap (core dumped)  gtranslator bg.po

Surprisingly, ldd doesn't show libsoup2 in the linked libraries:

$ ldd /usr/bin/gtranslator|grep soup
libsoup-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libsoup-3.0.so.0 
(0x7fb803048000)


-- Damyan


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gtranslator depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gsettings-desktop-schemas42.0-1
ii  iso-codes4.11.0-1
ii  libatk1.0-0  2.38.0-1
ii  libc62.34-4
ii  libcairo21.16.0-6
ii  libgda-5.0-4 5.2.10-2
ii  libgettextpo00.21-8
ii  libglib2.0-0 2.72.3-1+b1
ii  libgspell-1-21.11.1-1
ii  libgtk-3-0   3.24.34-1
ii  libgtksourceview-4-0 4.8.3-1
ii  libhandy-1-0 1.7.90-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libpango-1.0-0   1.50.9+ds-1
ii  libsoup-3.0-03.1.3-1
ii  libxml2  2.9.14+dfsg-1+b1

gtranslator recommends no packages.

Versions of packages gtranslator suggests:
pn  libpeas-1.0-python2loader  

-- debconf-show failed

Bug#1017375: liblexical-accessor-perl: test failure with Sub::HandlesVia 0.034

[Damyan Ivanov]

Package: liblexical-accessor-perl
Version: 0.014-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

t/30shv.t fails with:

Usage: Sub::HandlesVia::CodeGenerator::method_installer(self) at 
.../lib/Sub/HandlesVia/Toolkit/SubAccessorSmall.pm line 58.

In version 0.034, Sub::HandlesVia::CodeGenerator's method_installer field 
is read-only and the above line tries to modify it:

$gen->method_installer( sub {
my ( $method_name, $coderef ) = @_;
my $real_destination = $handles_map->{$method_name};
$realattr->install_coderef( $real_destination, $coderef );
} );



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1016369: IO::Handle ->error does not work, always saying "fine"

[Damyan Ivanov]

-=| Ian Jackson, 30.07.2022 13:42:05 +0100 |=-
> Package: perl
> Version: 5.34.0-4
> Severity: grave
> 
> To reproduce
> 
> perl -MIO::Handle -e 'open X, "<", "." or die $!; $_ = ; printf "%s %s 
> %s\n", X->error(), $!;'
> perl -MIO::Handle -e 'open X, ">", "/dev/full" or die $!; print X 1; 
> flush X; printf "%s %s %s\n", X->error(), $!; close X'
> 
> Expected output
> 
> -1 Bad file descriptor
> -1 No space left on device
> 
> Actual output
> 
> 0 Bad file descriptor
> 0 No space left on device

Thanks for the reproducer. I have converted it to a test file and have 
run that on all perl versions from blead back to 5.6.2, thanks to 
perlbrew.

Here's the test file:
===
$ cat 1016369.t
use Test::More;

plan skip_all => "IO::Handle not available" unless eval 'use IO::Handle; 1';

open(X, "<", ".") or die $!;
ok(!defined(), 'failed reading from ".", as expected');
ok(X->error,  'X->error is TRUE after reading from "."');
close X;

SKIP: {
skip "/dev/full not available", 3 unless -w '/dev/full';

open X, '>', '/dev/full' or die $!;
ok((print X "1"), "successful write to /dev/full");
ok(!X->flush, "flush after writing to /dev/full fails");
ok(X->error,  "X->error is TRUE after flushing /dev/full");
close X;
}

done_testing;
==

Digested results of `prove 1016369.t`:

'X->error is TRUE after reading from "."': all versions fail

'X->error is TRUE after flushing /dev/full': blead, 5.36.0, 5.34.3 and 
5.6.2 pass, 5.32.1 through 5.8.9 fail

> This is quite alarming.  I think it makes it in fact impossible to
> read files fully reliably in Perl.

On the other hand, it went unnoticed for many years, so it can't be 
that bad.

Note that the recommended way to read files line by line is (perldoc 
-f readline):

while ( ! eof($fh) ) {
defined( $_ = readline $fh ) or die "readline failed: $!";
...
}

This may explain why the X->error misbehaviour wasn't detected for so 
long.

> "use autodie" does not seem to help.

I think this is expected. autodie replaces the functional interface, 
lexically, not the OO one provided by IO::Handle.

> And scripts might reasonably have expected that they could defer 
> error handling by testing error() rather than each call (as one can 
> in C).

Here I concur. The behaviour of X->error is wrong and needs fixing.

> I think this used to work, but, evidently, only in the distant past,
> since my jessie chroot doesn't get this right either.

This part was what inspired my archaeological tests above. 5.6.2 was 
indeed far in the past.

> Justification for the severity:
> 
> Can cause data loss: if a file is opened but unreadable for any
> reason, the program will process the part (if any) that will is
> readable and then 

I'd use 'important' to signal that it would be nice to get this fixed 
in stable and that the package is still quite useful, but this is for 
Niko and Dominic to decide. Perhaps it doesn't matter so much in the 
end, since perl is Essential:yes.


-- Damyan

Bug#1015913: /usr/share/perl5/Config/Model/models/Dpkg/Control.pl: failure applying Dpkg::Control fixes when current directory is single character

[Damyan Ivanov]

Package: libconfig-model-dpkg-perl
Version: 2.161
Severity: normal
File: /usr/share/perl5/Config/Model/models/Dpkg/Control.pl
Tags: upstream

Hi,

Discovered when running dh-make-perl from a directory named '1'. Here's a 
reproducer. Note the name of the current directory:

 ╭─ ~/tmp/1 
 ╰─ LANG=C perl -MConfig::Model 
-wE'Config::Model->new->instance(root_class_name => "Dpkg::Control", root_dir 
=> "/non-existent")->apply_fixes'

 Reading package lists... Done
 Building dependency tree... Done
 Reading state information... Done
 Configuration item 'source Source' has a wrong value:
computed value error:
value '1' does not match regexp \w[\w+\-\.]{1,}
 value is computed from 'use Cwd; getcwd =~ m!/([^/]+)$!; $1;'

In the real case the root_dir argument points to an existing package 
directory containing 'debian/control' and all, e.g:

$ sudo apt install dh-make-perl
$ mkdir -p ~/tmp/1
$ cd ~/tmp/1
$ dh-make-perl --cpan Alias

I hope this is enough to reproduce and diagnose the problem.


-- Damyan

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libconfig-model-dpkg-perl depends on:
ii  debhelper  13.8
ii  libapt-pkg-perl0.1.40+b1
ii  libarray-intspan-perl  2.004-2
ii  libconfig-model-backend-yaml-perl  2.134-1
ii  libconfig-model-perl   2.150-1
ii  libdata-compare-perl   1.27-2
ii  libexporter-lite-perl  0.09-1
ii  liblog-log4perl-perl   1.55-1
ii  libmouse-perl  2.5.10-1+b2
ii  libparse-debcontrol-perl   2.005-5
ii  libparse-recdescent-perl   1.967015+dfsg-3
ii  libsoftware-licensemoreutils-perl  1.009-1
ii  libsort-versions-perl  1.62-2
ii  libtext-autoformat-perl1.75-1
ii  libtext-levenshtein-damerau-perl   0.41-2
ii  libtoml-tiny-perl  0.15-1
ii  liburi-perl5.12-1
ii  libwww-perl6.67-1
ii  libyaml-libyaml-perl   0.83+ds-1+b1
ii  licensecheck   3.3.0-1
ii  lintian2.115.2
ii  perl [libmodule-corelist-perl] 5.34.0-5

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.375-1

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information

Bug#1013526: libtickit-widget-scrollbox-perl: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 255

[Damyan Ivanov]

Control: retitle -1 libtickit-widget-scrollbox-perl: intermittent memory 
corruption in t/02input-key.t and t/03input-mouse.t

I can reproduce this when running 02input-key.t and 03input-key.t in 
a loop. The symptom is the same - "malloc_consolidate(): unaligned 
fastbin chunk detected" error message and the tests exits with Wstat 
134 after saying "All 14 subtests passed".

Wstat 134 is SIGABRT. Looks like a memory corruption of some sort.

After enabling core dumps, the following backtrace is observed:

(gdb) thread apply all bt

Thread 1 (Thread 0x7fbd5e0622c0 (LWP 401521)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x7fbd5e0c0546 in __GI_abort () at abort.c:79
#2  0x7fbd5e117eb8 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7fbd5e235a78 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7fbd5e11f91a in malloc_printerr (str=str@entry=0x7fbd5e237de8 
"malloc_consolidate(): unaligned fastbin chunk detected") at malloc.c:5628
#4  0x7fbd5e1209c4 in malloc_consolidate (av=av@entry=0x7fbd5e26cba0 
) at malloc.c:4709
#5  0x7fbd5e1211d0 in _int_free (av=0x7fbd5e26cba0 , 
p=0x5573c9773940, have_lock=) at malloc.c:4633
#6  0x7fbd5e1249b4 in __GI___libc_free (mem=) at 
malloc.c:3309
#7  0x5573c74b3bdf in Perl_hv_undef_flags 
(my_perl=my_perl@entry=0x5573c8b762a0, hv=hv@entry=0x5573c91ea6a0, 
flags=flags@entry=2) at ./build-static/hv.c:2115
#8  0x5573c74c5620 in Perl_sv_clear (my_perl=my_perl@entry=0x5573c8b762a0, 
orig_sv=orig_sv@entry=0x5573c91ea6a0) at ./build-static/sv.c:6864
#9  0x5573c74c4411 in Perl_sv_free2 (my_perl=my_perl@entry=0x5573c8b762a0, 
sv=0x5573c91ea6a0, rc=) at ./build-static/sv.c:7088
#10 0x5573c74c5248 in Perl_SvREFCNT_dec_NN (sv=, 
my_perl=0x5573c8b762a0) at ./build-static/inline.h:314
#11 do_clean_objs (ref=0x5573c91fb800, my_perl=0x5573c8b762a0) at 
./build-static/sv.c:533
#12 S_visit (mask=2048, flags=2048, f=, my_perl=0x5573c8b762a0) 
at ./build-static/sv.c:476
#13 Perl_sv_clean_objs (my_perl=my_perl@entry=0x5573c8b762a0) at 
./build-static/sv.c:627
#14 0x5573c741de2b in perl_destruct (my_perl=0x5573c8b762a0) at 
./build-static/perl.c:893
#15 0x5573c73f649c in main (argc=, argv=, 
env=) at ./build-static/perlmain.c:121


I've filed a wishlist #1013740 for upgrading libtickit to 0.4.2a, 
which would allow upgrading libtickit-perl to the latest upstream, 
either of which may help.

Bug#1013740: libtickit: Upgrade to 0.4.2a

[Damyan Ivanov]

Source: libtickit
Version: 0.2-5
Severity: wishlist

Please upgrade the libtickit package to version 0.4.2a, available from 
https://www.leonerd.org.uk/code/libtickit/

It is needed for the new version of libtickit-perl.


Thanks,
Damyan

Bug#1013446: RM: libobject-pad-slotattr-trigger-perl -- ROM; Renamed upstream; replacement available in Debian

[Damyan Ivanov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-perl-maintain...@alioth-lists.debian.net

Please remove libobject-pad-slotattr-trigger-perl from unstable.

It has been renamed upstream and the replacement is available in Debian·
under the libobject-perl-fieldattr-trigger-perl name.

There are three more packages with very similar names goung through the·
same change. Mentioning it so that you don't see them as duplicates :)

Thanks,
Damyan

Bug#1013445: RM: libobject-pad-slotattr-lazyinit-perl -- ROM; Renamed upstream; replacement available in Debian

[Damyan Ivanov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-perl-maintain...@alioth-lists.debian.net

Please remove libobject-pad-slotattr-lazyinit-perl from unstable.

It has been renamed upstream and the replacement is available in Debian·
under the libobject-perl-fieldattr-lazyinit-perl name.

There are three more packages with very similar names goung through the·
same change. Mentioning it so that you don't see them as duplicates :)

Thanks,
Damyan

Bug#1013444: RM: libobject-pad-slotattr-isa-perl -- ROM; Renamed upstream; replacement available in Debian

[Damyan Ivanov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-perl-maintain...@alioth-lists.debian.net

Please remove libobject-pad-slotattr-isa-perl from unstable.

It has been renamed upstream and the replacement is available in Debian·
under the libobject-perl-fieldattr-isa-perl name.

There are three more packages with very similar names goung through the·
same change. Mentioning it so that you don't see them as duplicates :)

Thanks,
Damyan

Bug#1013443: RM: libobject-pad-slotattr-final-perl -- ROM; Renamed upstream; replacement available in Debian

[Damyan Ivanov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-perl-maintain...@alioth-lists.debian.net

Please remove libobject-pad-slotattr-final-perl from unstable.

It has been renamed upstream and the replacement is available in Debian 
under the libobject-perl-fieldattr-final-perl name.

There are three more packages with very similar names goung through the 
same change. Mentioning it so that you don't see them as duplicates :)

Thanks,
Damyan

Bug#705068: Please provide dh-make library for non-perl packaging helpers

[Damyan Ivanov]

Control: tag -1 help

Almost 10 years later, I think it is obvious the dh-make-perl authors 
(me included) aren't very keen on separating the parts that are 
specific to the Debian Perl Group and providing a more universal 
library that can be used by others.

-=| Thomas Koch, 08.05.2013 19:49:19 +0200 |=-
> Some clarifications:
> 
> There is for example a lot of logic in the package 
> DhMakePerl::Command::Packaging that I'd like to reuse for java packaging. For 
> that I'd need a reliable API and some logic would need to extracted from 
> larger functions into separate functions:
> 
> * get_developer(), get_wnpp() are fine for reuse
> * fill_maintainer() has hardcoded reference to perl team
> * set_package_name() contains logic to fall back to create a perl library 
> package name
> * extract_desc() contains useful logic to format the long package description
> * ...
> 
> I think it's fine to keep all this logic in the dh-make-perl package. It 
> would 
> just be helpful to have a clear distinction between reusable code 
> that could be used for languages other than perl and code specific 
> for packaging perl.

Right. These are all good ideas. They "just" need someone to implement 
them. We won't, it seems, so I am tagging the bugreport with 'help'.

If I was going to do it, I'd try to split all DPG-specific parts into 
a ::Packaging::DPG or a similar package, sublcassing ::Packaging, and 
change dh-make-perl to use that.

Then another tool, say dh-make-java, would need to provide 
::Packaging::Java, subclassing ::Packaging with Java-specific 
functions.

Perhaps there are some perl-specific things outside ::Packaging too.

The whole thing involves identifying domain specific parts, some 
shuffling around and a lot of testing. I hope people who need this 
functionality would be able to spend the time to try it.


-- Damyan

Bug#774068: ExtUtils-MakeMaker and NO_PERLLOCAL

[Damyan Ivanov]

-=| Niko Tyni, 30.12.2014 11:47:23 +0200 |=-
> (cc'ing the debian-perl list)
> 
> On Tue, Dec 30, 2014 at 08:38:56AM +, Damyan Ivanov wrote:
> > -=| Andrew Beverley, 29.12.2014 00:16:14 + |=-
> > > Is there any harm in having the option in there, especially as the
> > > upstream version of EU-MM defaults to creating perllocal.pod files, and
> > > provides this option to prevent it happening?
> > 
> > As I see it, adding and maintaining a line to 2000+ debian/rules files 
> > is a bit of a burden. Not an unbearable one, but we embraced the tiny 
> > dh rules exactly because they made things really simple.
> > 
> > > Presumably Debian's version uses a patched version of EU-MM, which was
> > > required before this option was available.
> > 
> > I wonder if debhelper would be the right place to add this. This would 
> > solve the problem this patch solves, and maybe also simplify the patch 
> > in the perl package package [1]
> > 
> > [1] 
> > https://anonscm.debian.org/cgit/perl/perl.git/tree/debian/patches/debian/no_packlist_perllocal.diff
> 
> Right, that seems like the right long term approach to me. Ideally,
> debhelper could pass both NO_PACKLIST and NO_PERLLOCAL to EU::MM, and
> the above patch wouldn't be needed at all.
> 
> This would be a similar transition to the (still unfinished) PREFIX one,
> see #579461 and 
>  
> https://lintian.debian.org/tags/debian-rules-makemaker-prefix-is-deprecated.html
> 
> Packages not using the short form dh rules would need to be modified
> before the patch could be removed. The required steps would be something
> like
>  1) change the Perl policy to recommend NO_PACKLIST + NO_PERLLOCAL
>  2) change debhelper v9 to use them
>  3) add a lintian check and/or do a mass bug filing for the other packages
>  4) wait for (most of) the packages to be fixed
>  5) change the Perl policy to require NO_PACKLIST + NO_PERLLOCAL
>  6) remove the patch from the perl package

I've been thinking about this. Even made the changes in debhelper¹ and 
considered a possible wording for the Perl policy.

 ¹ 
https://salsa.debian.org/dmn/debhelper/-/commits/b9cdc9696464f67f0c75479383a002ff666ffd6b

Then it occured to me that this is a titanic work that would take 
months if not years - rebuilding the archive, analyzing the results, 
providing patches to the packages that need them and track their 
progress.

All this so that a patch is dropped from Debian's EU:MM and packages 
created with dh-make-perl could be built in a rather non-standard 
environment.

And perhaps the other patches to Debian's EU:MM also have some purpose 
that would still be missing, so another round of the same would be 
needed.

Somehow, to me it seems that the gain is not worth the effort. By 
a huge margin.

So how about this instead:

Add a special option to dh-make-perl like '--pristine-upstream-eumm' 
that causes it to make whatever changes are necessary to the resulting 
package for it to build with the non-standard envronment. Including 
a warning to the docs that such a package is not intented for the 
official Debian archive.

Andrew, are you still interested in this and willing to provide 
a merge request/patch that provides such an option?

If you have solved the issue by other means (e.g. --data-dir), then 
perhaps we should just close this bugreport.


-- Damyan

Bug#1012073: perl: restoring default signal handler may warn with 'SIGTERM handler "DEFAULT" not defined'

[Damyan Ivanov]

-=| Niko Tyni, 30.05.2022 09:27:40 +0100 |=-
> On Sun, May 29, 2022 at 05:38:40PM +0000, Damyan Ivanov wrote:
> > Package: perl
> > Version: 5.34.0-4
> > Severity: normal
> 
> > While infestigating a random FTBFS in starlet (#923829), it appeared to me 
> > that 
> > the problem is actually in perl.
> 
> > #   Failed test 'No warnings'
> > #   at t/12bad_request_line.t line 24.
> > # SIGTERM handler "DEFAULT" not defined.
> > #  at /usr/share/perl5/Parallel/Prefork.pm line 71.
> > #   Parallel::Prefork::start(Parallel::Prefork=HASH(0x55cd856355b8)) called 
> > at .../lib/Plack/Handler/Starlet.pm line 78
> > #   
> > Plack::Handler::Starlet::run(Plack::Handler::Starlet=HASH(0x55cd849b0ad8), 
> > CODE(0x55cd8562ac98)) called at t/12bad_request_line.t line 28
> 
> Just a quick reply that a smaller reproducer would obviously help.

Yeah. Sorry about that. When I posted this I was already a bit tired 
chasing where the warning comes from.

Here's a cleaner reproducer:

$ cat <<'EOF' > default-signal.pl
use strict;
use warnings;
use Carp::Always;   # to get a line number for the warning

$SIG{TERM} = sub{};
while() {
my $pid = fork();
defined($pid) or die 0;

if ($pid) {
sleep(0.1);
kill TERM => $pid;
wait;
}
else {
$SIG{TERM} = "DEFAULT";
exit(0);
}
}
EOF

$ perl default-signal.pl
SIGTERM handler "DEFAULT" not defined.
 at default-signal.pl line 16.
…

On my laptop the warnings start to pour in a second or two.

If I comment out that sleep(), no warnings are shown.

> FWIW this looks somewhat similar to
> 
> https://github.com/perl/perl5/issues/10913
> 
> but I assume the 'prefork' references mean threads are not involved
> here. So perhaps unrelated after all.

This is what I looked at too and came to the same conclusion (threads 
≠ forks).


-- Damyan

Bug#1012073: perl: restoring default signal handler may warn with 'SIGTERM handler "DEFAULT" not defined'

[Damyan Ivanov]

Package: perl
Version: 5.34.0-4
Severity: normal

Control: block 923829 by -1

Hi,

While infestigating a random FTBFS in starlet (#923829), it appeared to me that 
the problem is actually in perl. To reproduce te issue, t/12bad_request_line.t 
needs to be run in a loop with the following change:

(starlet packaging repo is at
ssh://g...@salsa.debian.org/perl-team/modules/packages/starlet.git)

---
diff --git a/t/12bad_request_line.t b/t/12bad_request_line.t
index 61b4e7b..bdc8368 100644
--- a/t/12bad_request_line.t
+++ b/t/12bad_request_line.t
@@ -22,7 +22,7 @@ test_tcp(
 my $port = shift;
 local $SIG{__WARN__} = sub {
 ok 0, "No warnings";
-diag @_;
+diag Carp::longmess(@_);
 };
 my $loader = Plack::Loader->load('Starlet', port => $port);
 $loader->run(sub { [200, ['Content-Type' => 'text/plain'], ['OK']] });
---

A sample loop is this:

 while prove -l t/12bad_request_line.t; do date; done

Running this simultaneously in several terminals may help triggering the 
failure.

Eventually it fails with:

#   Failed test 'No warnings'
#   at t/12bad_request_line.t line 24.
# SIGTERM handler "DEFAULT" not defined.
#  at /usr/share/perl5/Parallel/Prefork.pm line 71.
#   Parallel::Prefork::start(Parallel::Prefork=HASH(0x55cd856355b8)) called 
at .../lib/Plack/Handler/Starlet.pm line 78
#   
Plack::Handler::Starlet::run(Plack::Handler::Starlet=HASH(0x55cd849b0ad8), 
CODE(0x55cd8562ac98)) called at t/12bad_request_line.t line 28
#   main::__ANON__(33415) called at /usr/share/perl5/Test/TCP.pm line 100
#   Test::TCP::start(Test::TCP=HASH(0x55cd8562aed8)) called at 
/usr/share/perl5/Test/TCP.pm line 82
#   Test::TCP::new("Test::TCP", "code", CODE(0x55cd8562aab8)) called at 
/usr/share/perl5/Test/TCP.pm line 28
#   Test::TCP::test_tcp("client", CODE(0x55cd854306b0), "server", 
CODE(0x55cd8562aab8)) called at t/12bad_request_line.t line 31
# Looks like you failed 1 test of 2.
t/12bad_request_line.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/2 subtests

The lines in Parallel::Prefork where the warning comes from are:
https://salsa.debian.org/perl-team/modules/packages/libparallel-prefork-perl/-/blob/master/lib/Parallel/Prefork.pm#L71

 ...
 68 unless ($pid) {
 69 # child process
 70 $self->{in_child} = 1;
 71 $SIG{$_} = 'DEFAULT' for keys %{$self->trap_signals};
 72 $SIG{CHLD} = 'DEFAULT'; # revert to original
 73 exit 0 if $self->signal_received;
 ...

Seems perfectly normal to me - signal handlers are reset in the forked child.

The only plausible source I find is line 3522 of mg.c:
https://salsa.debian.org/perl-team/interpreter/perl/-/blob/debian-5.34/mg.c#L3522

and here my idea of what is going on vanishes. I hope this is enough as a clue.


-- Damyan

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages perl depends on:
ii  dpkg   1.21.8
ii  libperl5.345.34.0-4
ii  perl-base  5.34.0-4
ii  perl-modules-5.34  5.34.0-4

Versions of packages perl recommends:
ii  netbase  6.3

Versions of packages perl suggests:
pn  libtap-harness-archive-perl  
ii  libterm-readline-gnu-perl1.42-2+b1
ii  libterm-readline-perl-perl   1.0303-2.1
ii  make 4.3-4.1
ii  perl-doc 5.34.0-4

-- no debconf information

Bug#962407: Bug#954089: libplack-perl: Please verify server identity via SSL

[Damyan Ivanov]

-=| gregor herrmann, 25.05.2022 22:24:09 +0200 |=-
> On Sun, 07 Jun 2020 17:45:41 +0100, Dominic Hargreaves wrote:
> 
> > Correction, given the amount of time that's passed and that I'm not
> > even sure if the person who responded negatively on the previous
> > issue speaks for the current maintainers, I have opened a new issue:
> > 
> > https://github.com/chansen/p5-http-tiny/issues/134
> 
> Revisiting this issue now, the state seems to be:
> 
> The upstream ticket was closed with
> 
> "On reflection, we shouldn't make this change for backwards compatibility."
> 
> So I guess we are back to the point where we have to discuss if we
> want to make the change on the Debian side and carry the patch (and
> keep the pieces if something breaks).
> 
> I think we had a tendence to say "this change makes sense" and "it
> doesn't look like huge breakage ahead" but I guess someone need to
> pick up this issue and take a deeper look.

I think we should make the change in Debian despite upstream's 
decision.

Anything that breaks was already insecure and keeping it that way is 
actually a disservice.

If I understand correctly we are talking for a fix in unstable that 
would propagate to the next stable release in the usual manner.
Contrary to a security update, this gives plenty of time for users for 
tests.


-- Damyan

Bug#995402: libclass-dbi-sweet-perl: FTBFS: test failure

[Damyan Ivanov]

Just a recording of a failed attempt to figure out what is wrong.

The problem seems to be with an internal SQL::Abstract method that is 
used by Class::DBI::Sweet (_recurse_where), which is reworked in the 
2.0 release, so a two-level join isn't handled.

It is not clear to me whether SQL:A is to blame or C:DBI:S. Should be 
the later, since SQL:A can't actually know which class/table 
corresponds to the joined alias or how to construct the join 
expression.

Anyway, If I had to decide today what happens with the package, I'd 
consider two options: removal of the package, and removal of the 
two-level join from documentation/tests.


-- Damyan

Bug#1006658: libobject-pad-perl breaks libtickit-widget-scrollbox-perl autopkgtest: malloc_consolidate(): unaligned fastbin chunk detected

[Damyan Ivanov]

Control: notfound 1006658 libtickit-widget-scrollbox-perl/0.11-1
Control: fixed 1006658 0.65-1

> With a recent upload of libobject-pad-perl the autopkgtest of
> libtickit-widget-scrollbox-perl fails in testing when that autopkgtest is
> run with the binary packages of libobject-pad-perl from unstable. It passes
> when run with only packages from testing. In tabular form:
> 
>passfail
> libobject-pad-perl from testing0.61-1
> libtickit-widget-scrollbox-perl from testing0.11-1
> all others from testingfrom testing

This seems to have fixed by itself at some point. The same version of 
libtickit-widget-scrollbox-perl now builds/tests fine with object-pad 
0.65, so marking the bug as fixed in that version.


-- Damyan

Bug#1011466: ITP: libobject-pad-fieldattr-trigger-perl -- invoke an instance method after a :writer accessor

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libobject-pad-fieldattr-trigger-perl
  Version : 0.06
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Object-Pad-FieldAttr-Trigger
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : invoke an instance method after a :writer accessor

Object::Pad::FieldAttr::Trigger provides a third-party field attribute for
Object::Pad-based classes, which declares that a named instance method shall
be invoked after a generated :writer accessor method is called.

WARNING The ability for Object::Pad to take third-party field attributes is
still new and highly experimental, and subject to much API change in future.
As a result, this module should be considered equally experimental.

This package is a replacement for libobject-pad-slotattr-trigger-perl following
the renaming and deprecation of Object::Pad::SlotAttr::Trigger upstream.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1011465: ITP: libobject-pad-fieldattr-lazyinit-perl -- lazily initialise Object::Pad fields at first read

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libobject-pad-fieldattr-lazyinit-perl
  Version : 0.05
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Object-Pad-FieldAttr-LazyInit
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : lazily initialise Object::Pad fields at first read

Object::Pad::FieldAttr::LazyInit provides a third-party field attribute for
Object::Pad-based classes, which declares that the field it is attached to
has a lazy initialisation method, which will be called the first time the
field's value is read from.

WARNING The ability for Object::Pad to take third-party field attributes is
still new and highly experimental, and subject to much API change in future.
As a result, this module should be considered equally experimental.

This package is a replacement for libobject-pad-slotattr-lazyinit-perl
following the renaming and deprecation of Object::Pad::SlotAttr::LazyInit
upstream.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1011462: ITP: libobject-pad-fieldattr-isa-perl -- apply class type constraints to Object::Pad fields

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libobject-pad-fieldattr-isa-perl
  Version : 0.03
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Object-Pad-FieldAttr-Isa
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : apply class type constraints to Object::Pad fields

Object::Pad::FieldAttr::Isa provides a third-party field attribute for
Object::Pad-based classes, which declares that values assigned to the field
must conform to a given object type.

WARNING The ability for Object::Pad to take third-party field attributes is
still new and highly experimental, and subject to much API change in future.
As a result, this module should be considered equally experimental.

This package is a replacement for libobject-pad-slotattr-isa following
the renaming and deprecation of Object::Pad::SlotAttr::Isa upstream.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1005016: libobject-pad-slotattr-final-perl: Object::Pad::SlotAttr::Final is replaced by Object::Pad::FieldAttr::Final

[Damyan Ivanov]

-=| gregor herrmann, 09.02.2022 21:18:13 +0100 |=-
> > % apt-cache --names-only search libobject-pad-slot | grep -v 
> > dbgsym
> > libobject-pad-slotattr-final-perl - declare Object::Pad slots readonly 
> > after construction
> > libobject-pad-slotattr-isa-perl - apply class type constraints to 
> > Object::Pad slots
> > libobject-pad-slotattr-lazyinit-perl - lazily initialise Object::Pad slots 
> > at first read
> > libobject-pad-slotattr-trigger-perl - invoke an instance method after a 
> > :writer accessor
> 
> Alright, making this a bit more formal:
> - cloning the bug for the 3 other affected packages
> - marking them as serious as they currently block the perl 5.34
>   transition (by way of blocking the rebuilt arch:any libobject-pad-perl
>   as it breaks the 4 autopkgtests); this could be ignored, but the
>   4 packages are doomed anyway, so an RC bug makes removal from
>   testing more transparent.

I have just uploaded libobject-pad-fieldattr-final-perl to NEW. The 
others will follow.

I guess the deprecated packages should go the RM route? Perhaps after 
the new ones are accepted?

Not sure whether the waiting for the replacements to enter unstable is 
strictly necessary. To me it just feels polite to possible users

-- Damyan

Bug#1011455: ITP: libobject-pad-fieldattr-final-perl -- declare Object::Pad fields read-only after construction

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libobject-pad-fieldattr-final-perl
  Version : 0.05
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Object-Pad-FieldAttr-Final
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : declare Object::Pad fields read-only after construction

Object::Pad::FieldAttr::Final provides a third-party field attribute for
Object::Pad-based classes, which declares that the field it is attached to
shall be set as read-only when the constructor returns, disallowing further
modification to it.

WARNING The ability for Object::Pad to take third-party field attributes is
still new and highly experimental, and subject to much API change in future.
As a result, this module should be considered equally experimental.

This package is a replacement for libobject-pad-slotattr-final-perl following
the renaming and deprecation of Object::Pad::SlotAttr::Final upstream.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1011325: drivers/upekts.so: Segmentation fault at startup

[Damyan Ivanov]

Package: biometric-driver-community-multidevice
Version: 0.9.71-1
Severity: important
File: /usr/lib/biometric-authentication/drivers/upekts.so

Hi,

Upon startup, the biometric-auth service fails with segmentation violation 
and a core dump:

 systemd[1]: Starting Authenticate by human biometric...
 biometric-authenticationd[1343]: [ NOTE] Database format version is 1.1.0
 biometric-authenticationd[1343]: [ NOTE] The database format is compatible 
with the current framework
 systemd[1]: biometric-authentication.service: Main process exited, 
code=dumped, status=11/SEGV
 systemd[1]: biometric-authentication.service: Failed with result 'core-dump'.
 systemd[1]: Failed to start Authenticate by human biometric.

Here's the stack contents:

 Thread 3 (Thread 0x7f362ad5d640 (LWP 1717)):
 #0  0x7f362f3bd87f in __GI___poll (fds=0x7f3624000b80, nfds=2, 
timeout=2000) at ../sysdeps/unix/sysv/linux/poll.c:29
 #1  0x7f362f4d9319 in ?? () from /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0
 #2  0x7f362f4d67f9 in ?? () from /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0
 #3  0x7f362f4d7d78 in libusb_handle_events_timeout_completed () from 
/usr/lib/x86_64-linux-gnu/libusb-1.0.so.0
 #4  0x7f362aff808e in ?? () from /usr/lib/x86_64-linux-gnu/libgusb.so.2
 #5  0x7f362f56859d in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
 #6  0x7f362f4afd80 in start_thread (arg=0x7f362ad5d640) at 
pthread_create.c:481
 #7  0x7f362f3c976f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 2 (Thread 0x7f362e77e640 (LWP 1716)):
 #0  0x7f362f3bd87f in __GI___poll (fds=0x7f362e77dc60, nfds=2, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
 #1  0x7f362f4de497 in ?? () from /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0
 #2  0x7f362f4afd80 in start_thread (arg=0x7f362e77e640) at 
pthread_create.c:481
 #3  0x7f362f3c976f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

 Thread 1 (Thread 0x7f362ea4cd80 (LWP 1715)):
 #0  0x7f362f8a3941 in community_ops_discover (dev=0x559071a61c80) at 
../../../../src/drivers/community-multidevice/community_ops.c:60
 #1  0x7f362f890cea in bio_device_list_init () from 
/usr/lib/x86_64-linux-gnu/libbiometric.so.0
 #2  0x55907179ef3b in ?? ()
 #3  0x55907179bc26 in ?? ()
 #4  0x7f362f2f27fd in __libc_start_main (main=0x55907179ba30, argc=1, 
argv=0x7ffc50d2cde8, init=, fini=, 
rtld_fini=, stack_end=0x7ffc50d2cdd8) at ../csu/libc-start.c:332
 #5  0x55907179be6a in ?? ()

The segmentation fault is in Thread 1 (upekts.so)

The machine is a ThinkPad X1 Carbon 5th. It has a fingerprint sensor:

 Bus 001 Device 004: ID 138a:0097 Validity Sensors, Inc.

I guess it is not supported, but still, a segmentation fault is a bit too harsh 
:)



-- Damyan


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages biometric-driver-community-multidevice depends on:
ii  biometric-utils   0.9.71-1
ii  libbiometric0 [bio-drv-api-0.10]  0.9.71-1
ii  libc6 2.33-7
ii  libfprint-2-2 1:1.94.2-1
ii  libglib2.0-0  2.72.1-1

biometric-driver-community-multidevice recommends no packages.

biometric-driver-community-multidevice suggests no packages.

-- no debconf information

Bug#961147: libcolor-calc-perl: broken by new libgraphics-colornames-perl

[Damyan Ivanov]

-=| intrigeri, 22.05.2020 08:47:25 +0200 |=-
> Hi,
> 
> Niko Tyni (2020-05-21):
> > So IMO we should either to package Graphics::ColorNames::HTML even though
> > it's deprecated, or drop Color::Calc from Debian.
> 
> > libcolor-calc-perl has just one reverse dependency AFAICS:
> > libcgi-application-plugin-authentication-perl.
> 
> I took a quick look.

Me too, a longer one :)

I just pushed a patch in Git that makes Color::Calc use '::WWW' 
instead of '::HTML', sorting hash keys so that color names are 
enumerated in a deterministic order and adapted almost all of the 
tests (mainly "gray"→"grey" and "aqua"→"cyan").

There is one test still failing, about "safe" colors.

Then I read your comments about removal :)

Uncertain what to do with the "safe" color conversion, looking at the 
aged upstream release, I decided to stop here. Maybe someone some day 
will find the patch useful.

--dam

Bug#965613: konwert: diff for NMU version 1.8-13.2

[Damyan Ivanov]

Control: tags 965613 + patch
Control: tags 965613 + pending

Dear maintainer,

I've prepared an NMU for konwert (versioned as 1.8-13.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer or speed it up.

Regards,
dam
diff -Nru konwert-1.8/debian/changelog konwert-1.8/debian/changelog
--- konwert-1.8/debian/changelog	2020-12-27 17:28:47.0 +0200
+++ konwert-1.8/debian/changelog	2022-01-11 22:13:21.0 +0200
@@ -1,3 +1,11 @@
+konwert (1.8-13.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump debhelper compatibility level from 5 to 7
+Closes: 965613 - removal of compatibility levels 5 and 6
+
+ -- Damyan Ivanov   Tue, 11 Jan 2022 20:13:21 +
+
 konwert (1.8-13.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru konwert-1.8/debian/compat konwert-1.8/debian/compat
--- konwert-1.8/debian/compat	2014-06-23 00:00:29.0 +0300
+++ konwert-1.8/debian/compat	2022-01-11 22:10:09.0 +0200
@@ -1 +1 @@
-5
+7
diff -Nru konwert-1.8/debian/control konwert-1.8/debian/control
--- konwert-1.8/debian/control	2016-08-15 12:03:45.0 +0300
+++ konwert-1.8/debian/control	2022-01-11 22:12:22.0 +0200
@@ -5,7 +5,7 @@
 Standards-Version: 3.6.2
 Vcs-Git: git://anonscm.debian.org/collab-maint/konwert.git
 Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/konwert.git
-Build-Depends: debhelper (>> 5), dh-buildinfo, bash-completion
+Build-Depends: debhelper (>= 7), dh-buildinfo, bash-completion
 
 Package: konwert
 Architecture: any

Bug#1002567: ITP: libjson-schema-modern-perl -- Validate JSON data against a schema

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libjson-schema-modern-perl
  Version : 0.533
  Upstream Author : Karen Etheridge 
* URL : https://metacpan.org/release/JSON-Schema-Modern
* License : Artistic or GPL-1+, BSD or AFL
  Programming Lang: Perl
  Description : Validate JSON data against a schema

JSON::Schema::Modern aims to be a fully-compliant JSON Schema evaluator and
validator, targeting the currently-latest Draft 2020-12
(https://json-schema.org/specification-links.html#2020-12).

The package will be maintained under the umbrella of the Debian Perl Group.

Currently the tests fail with AUTOMATED_TESTS=1 in the environment (which
happens during autopkg-testing).

Also, the licensing of share/draft* needs clearing up.

Current efforts can be tracked at
https://salsa.debian.org/perl-team/modules/packages/libjson-schema-modern-perl

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#924684: libmp3-info-perl: Unescaped left brace in regex is deprecated

[Damyan Ivanov]

Control: reassign -1 libmp3-tag-perl
Control: forcemerge 928197 -1

-=| Martin Schuster, 15.03.2019 21:21:17 +0100 |=-
> Package: libmp3-info-perl
> Version: 1.24-1.2
> Severity: normal
> 
> Using get_mp3tag()
> 
> Unescaped left brace in regex is deprecated here (and will be fatal in
> Perl 5.32), passed through in regex; marked by <-- HERE in m/^\??({ <--
> HERE ([^{}]+)}|.)/ at /usr/share/perl5/MP3/Tag.pm line 2944.
> Unescaped left brace in regex is deprecated here (and will be fatal in
> Perl 5.32), passed through in regex; marked by <-- HERE in m/^({ <--
> HERE [^{}]+}|\w)/ at /usr/share/perl5/MP3/Tag.pm line 2956.
> 
> 
> Suggested fix:
> 
> --- Tag.pm.orig 2017-07-12 21:25:22.0 +0200
> +++ Tag.pm  2019-03-15 21:16:44.760013512 +0100
> @@ -2941,7 +2941,7 @@
>local $self->{ms} = int($time * 1000 + 0.5) if defined $time;
>my ($out, %have, $c) = '';
>for my $f (@_) {
> -$have{$+}++ if $f =~ /^\??({([^{}]+)}|.)/;
> +$have{$+}++ if $f =~ /^\??(\{([^{}]+)\}|.)/;
>}
> ...

This looks like bug #9284684 in libmp3-tag-perl (already fixed via 
NMU), but filed earlier and in the wrong package. libmp3-info-perl 
doesn't ship Tag.pm.

Merging accordingly.

Bug#1001680: O: libmp3-info-perl -- Perl MP3::Info - Manipulate / fetch info from MP3 audio files

[Damyan Ivanov]

Control: retitle -1 ITA: libmp3-info-perl -- Perl MP3::Info - Manipulate / 
fetch info from MP3 audio files
Control: owner -1 !

-=| Alexander Wirt, 14.12.2021 08:13:48 +0100 |=-
> Package: wnpp
> Severity: normal
> Control: affects -1 src:libmp3-info-perl
> 
> I intend to orphan the libmp3-info-perl package. That was a dependency
> for mp3burn and I don't need it anymore.
> 
> The package description is:
>  This Perl library gives a set of function for manipulating info tags in MP3
>  files and retrieving technical information from them.
>  .
>  This package was formerly known as MPEG::MP3Info and still has a wrapper
>  for applications that refer to it using the old name.
>  .
>  The Debian package also provides a simple tool for editing MP3 tags - mp3id.

I want to take over this package for the Debian Perl Group.

Even if it is said to be deprecated upstream and there is 
a replacement by the same upstream author packaged in Debian, there 
are still reverse dependencies so it can't be dropped yet.


-- dam

Bug#999279: swish-e: diff for NMU version 2.4.7-6.1

[Damyan Ivanov]

-=| Ludovic Drolez, 17.12.2021 16:20:53 +0100 |=-
> On Thu, Dec 16, 2021 at 07:56:50AM +0000, Damyan Ivanov wrote:
> > I've prepared an NMU for swish-e (versioned as 2.4.7-6.1) and
> > uploaded it to DELAYED/7. Please feel free to tell me if I
> > should delay it longer.
> > 
> 
> That's perfect, thanks for your help!

Glad to be of service. Upload rescheduled to DELAYED/0 and should 
enter the archive within a day.

Cheers!
dam

Bug#999216: lpr: diff for NMU version 1:2008.05.17.3+nmu1

[Damyan Ivanov]

-=| Adam Majer, 16.12.2021 18:16:23 +0100 |=-
> On 12/16/21 9:37 AM, Damyan Ivanov wrote:
> > Dear maintainer,
> > 
> > I've prepared an NMU for lpr (versioned as 1:2008.05.17.3+nmu1) and
> > uploaded it to DELAYED/7. Please feel free to tell me if I
> > should delay it longer.
> > 
> > Regards.
> > 
> 
> Thank you! The upload is appreciated.

Great! Upload re-scheduled to DELAYED/0 and should enter the archive 
within a day.

-- dam

Bug#999291: xfsdump: diff for NMU version 3.1.9+0+nmu1

[Damyan Ivanov]

Control: tags 999291 + patch
Control: tags 999291 + pending

Dear maintainer,

I've prepared an NMU for xfsdump (versioned as 3.1.9+0+nmu1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru xfsdump-3.1.9+0/debian/changelog xfsdump-3.1.9+0+nmu1/debian/changelog
--- xfsdump-3.1.9+0/debian/changelog	2020-07-11 03:48:32.0 +0300
+++ xfsdump-3.1.9+0+nmu1/debian/changelog	2021-12-16 10:44:12.0 +0200
@@ -1,3 +1,11 @@
+xfsdump (3.1.9+0+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * add build-arch and build-indep targets to debian/rules
+Closes: #999291
+
+ -- Damyan Ivanov   Thu, 16 Dec 2021 08:44:12 +
+
 xfsdump (3.1.9+0) unstable; urgency=medium
 
   * In postinst, create as needed the xfsdump and xfsrestore symlinks
diff -Nru xfsdump-3.1.9+0/debian/rules xfsdump-3.1.9+0+nmu1/debian/rules
--- xfsdump-3.1.9+0/debian/rules	2020-01-31 19:30:58.0 +0200
+++ xfsdump-3.1.9+0+nmu1/debian/rules	2021-12-16 10:43:03.0 +0200
@@ -12,12 +12,16 @@
 	  INSTALL_USER=root INSTALL_GROUP=root ;
 checkdir = test -f debian/rules
 
-build: built
+build: build-arch build-indep
+
+build-arch: built
 built: config
 	@echo "== dpkg-buildpackage: build" 1>&2
 	$(MAKE) default
 	touch built
 
+build-indep:
+
 config: .census
 .census:
 	@echo "== dpkg-buildpackage: configure" 1>&2

Bug#999216: lpr: diff for NMU version 1:2008.05.17.3+nmu1

[Damyan Ivanov]

Control: tags 999216 + patch
Control: tags 999216 + pending

Dear maintainer,

I've prepared an NMU for lpr (versioned as 1:2008.05.17.3+nmu1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru lpr-2008.05.17.3/debian/changelog lpr-2008.05.17.3+nmu1/debian/changelog
--- lpr-2008.05.17.3/debian/changelog	2019-01-11 22:06:54.0 +0200
+++ lpr-2008.05.17.3+nmu1/debian/changelog	2021-12-16 10:35:18.0 +0200
@@ -1,3 +1,11 @@
+lpr (1:2008.05.17.3+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * add build-arch and build-indep targets to debian/rules
+(Closes: #999216)
+
+ -- Damyan Ivanov   Thu, 16 Dec 2021 08:35:18 +
+
 lpr (1:2008.05.17.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lpr-2008.05.17.3/debian/rules lpr-2008.05.17.3+nmu1/debian/rules
--- lpr-2008.05.17.3/debian/rules	2019-01-11 22:06:54.0 +0200
+++ lpr-2008.05.17.3+nmu1/debian/rules	2021-12-16 10:33:03.0 +0200
@@ -9,20 +9,24 @@
 CPPFLAGS = -Wall -g -O2 -D_GNU_SOURCE -D__KAME__ -I../common_source
 # -D_BSD_SOURCE
 
-build: build-stamp
-build-stamp:
+build: build-arch build-indep
+build-arch: build-arch-stamp
+build-arch-stamp:
 	dh_testdir
 	make -W CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)"
-	touch build-stamp
+	touch $@
+
+build-indep:
+# nothing to do here
 
 clean: 
 	dh_testdir
 	dh_testroot
-	rm -f build-stamp install-stamp
+	rm -f build-arch-stamp install-stamp
 	-make clean
 	dh_clean
 
-install: build-stamp
+install: build
 	dh_testdir
 	dh_testroot
 	dh_clean -k
@@ -69,4 +73,4 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#999279: swish-e: diff for NMU version 2.4.7-6.1

[Damyan Ivanov]

Control: tags 999279 + patch
Control: tags 999279 + pending

Dear maintainer,

I've prepared an NMU for swish-e (versioned as 2.4.7-6.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u swish-e-2.4.7/debian/changelog swish-e-2.4.7/debian/changelog
--- swish-e-2.4.7/debian/changelog
+++ swish-e-2.4.7/debian/changelog
@@ -1,3 +1,10 @@
+swish-e (2.4.7-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * add build-arch and build-inde targets to debian/rules (Closes: #999279)
+
+ -- Damyan Ivanov   Thu, 16 Dec 2021 07:52:44 +
+
 swish-e (2.4.7-6) unstable; urgency=medium
 
   * Fixed the zlib related build problem. Closes: #869860
diff -u swish-e-2.4.7/debian/rules swish-e-2.4.7/debian/rules
--- swish-e-2.4.7/debian/rules
+++ swish-e-2.4.7/debian/rules
@@ -26,6 +26,11 @@
 	rm -f html/search.cgi debian/files
 	rm -f SWISH-Stemmer-0.05.tar.gz
 
+build-indep:
+	# nothing
+
+build-arch: build
+
 build: build.stamp
 build.stamp:
 	dh_testdir
@@ -89,4 +94,4 @@
 
 binary-indep: build
 
-.PHONY: clean build binary binary-arch binary-indep
+.PHONY: clean build build-arch build-indep binary binary-arch binary-indep

Bug#1001778: ITP: libham-locator-perl -- Perl module for converting between Maidenhead locators and latitude/longitude

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libham-locator-perl
  Version : 0.1000
  Upstream Author : Andy Smith 
* URL : https://metacpan.org/release/Ham-Locator
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module for converting between Maidenhead locators and 
latitude/longitude

Ham::Locator provides methods for conversion between Maidenhead (QTH) locator
strings and latitude/longitude coordinates.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#999021: libexpect-perl: diff for NMU version 1.21-1.2

[Damyan Ivanov]

Control: tags 999021 + patch
Control: tags 999021 + pending

Dear maintainer,

I've prepared an NMU for libexpect-perl (versioned as 1.21-1.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.


Regards,
dam
diff -u libexpect-perl-1.21/debian/changelog libexpect-perl-1.21/debian/changelog
--- libexpect-perl-1.21/debian/changelog
+++ libexpect-perl-1.21/debian/changelog
@@ -1,3 +1,11 @@
+libexpect-perl (1.21-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Provide 'build-arch' and 'build-indep' targets in debian/rules
+    Closes: #999021
+
+ -- Damyan Ivanov   Wed, 15 Dec 2021 19:58:42 +
+
 libexpect-perl (1.21-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u libexpect-perl-1.21/debian/rules libexpect-perl-1.21/debian/rules
--- libexpect-perl-1.21/debian/rules
+++ libexpect-perl-1.21/debian/rules
@@ -7,21 +7,26 @@
 TMP	=`pwd`/debian/$(PACKAGE)
 
 
-build: build-stamp
-build-stamp:
+build: build-arch build-indep
+
+build-indep: build-indep-stamp
+build-indep-stamp:
 	dh_testdir
 
 	perl Makefile.PL INSTALLDIRS=vendor
 	$(MAKE) OPTIMIZE="-O2 -g -Wall"
 
-	touch build-stamp
+	touch $@
+
+build-arch:
+	# nothing to do here
 
 realclean: clean
 
 clean:
 	dh_testdir
 	dh_testroot
-	rm -f build-stamp
+	rm -f build-indep-stamp
 
 	[ ! -f Makefile ] || $(MAKE) distclean
 
@@ -60,4 +65,4 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#992133: firebird4.0 debian packaging

[Damyan Ivanov]

-=| Frank Doepper, 12.12.2021 15:00:19 +0100 |=-
> Hi Damyan.
> 
> Am 26.08.21 um 10:40 schrieb Damyan Ivanov:
> 
> > Simply letting debhelper do the autoreconf seems to work and the build
> > completes, no linker errors. This is in an up to date sid sbuild chroot.
> 
> Thank you for your ongoing work on firebird4.0, I've seen many commits. I've
> refreshed our jenkins/minibuildd setup and firebird4.0 now builds fine on
> sid and bookworm. Unfortunately build fails on bullseye, which is apparently
> related to autoconf 2.71 vs. 2.69:
> 
>  debian/rules binary
> ...
> configure: error: cannot find install-sh, install.sh, or shtool in 
> builds/make.new/config "."/builds/make.new/config
> 
> Maybe there is a workaround to make the autoreconf more compatible, letting
> me backport firebird4.0 to bullseye?

I have no idea. GNU autotools is a mystery to me.

Maybe invoking ./autogen.sh instead of dh_autoreconf would work? 
Perhaps backporting autoconf 2.71 to bullseye will help?


-- dam

Bug#1000760: ITP: liblinux-systemd-perl -- Perl module with bindings for systemd APIs

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: liblinux-systemd-perl
  Version : 1.201600
  Upstream Author : Ioan Rogers 
* URL : https://metacpan.org/release/Linux-Systemd
* License : LGPL-2.1
  Programming Lang: Perl
  Description : Perl module with bindings for systemd APIs

Linux::Systemd makes several systemd APIs available to Perl code:

* sd_notify(3) for startup and status notifications

* write to and read from the journal

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1000334: ITP: libnet-async-mpd-perl -- non-blocking interface to MPD (Perl module)

[Damyan Ivanov]

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libnet-async-mpd-perl
  Version : 0.005
  Upstream Author : José Joaquín Atria 
* URL : https://metacpan.org/release/Net-Async-MPD
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : non-blocking interface to MPD (Perl module)

Net::Async::MPD provides a non-blocking interface to an MPD server. It
supports all MPD commands, including command lists and waiting in idle mode
for a change to happen.

All operations can be done using synchronous (blocking) and/or asynchronous
(non-blocking) techniques and event handlers.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#999615: ITP: librole-eventemitter-perl -- Perl module providing an event emitter role

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: librole-eventemitter-perl
  Version : 0.003
  Upstream Author : Dan Book 
* URL : https://metacpan.org/release/Role-EventEmitter
* License : Artistic-2.0
  Programming Lang: Perl
  Description : Perl module providing an event emitter role

Role::EventEmitter is a simple Role::Tiny role for event emitting objects
based on Mojo::EventEmitter. This role can be applied to any hash-based
object class such as those created with Class::Tiny, Moo, or Moose.

Needed by Net::Async::MPD (ITP pending).

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#993740: patch for cron spam (#993740)

[Damyan Ivanov]

Control: tag -1 patch

I just filed a merge request¹ fixing the spurious message.

Thanks for considering.


-- Damyan

 ¹ https://salsa.debian.org/debian/man2html/-/merge_requests/1

Bug#992133: firebird4.0 debian packaging

[Damyan Ivanov]

-=| Frank Doepper, 26.08.2021 10:42:33 +0200 |=-
> I tried this (commit f89edee), but it fails again on sid with the 
> same libre2 linker error.

Bummer.

> I think that's a clash between bundled libre2 and system libre2.

Nah, the bundled libre2 is not part of the orig.tar source and can't 
interfere with the build.

> Although
> configure is called with --with-system-re2, the flags contain
> -I/<>/extern/re2, and I guess that's the problem. Maybe
> debian/patches/out/system-re2.patch needs a second look at.

I agree that removing the -I directive would be nice. This is already 
done for other bundled libraries for which upstream supports using the 
system ones. Patch updated.

-- Damyan

Bug#992133: firebird4.0 debian packaging

[Damyan Ivanov]

-=| Damyan Ivanov, 26.08.2021 09:34:04 +0300 |=-
> -=| Frank Doepper, 25.08.2021 16:58:15 +0200 |=-
> > Hi Damyan,
> > 
> > great that you are packaging firebird4.0 for Debian. Volker and I have tried
> > to build the source from
> > https://salsa.debian.org/firebird-team/firebird4.0/
> > with our mini-buildd on Debian Sid
> > at Tue, 17 Aug 2021 10:32:13 +
> > and it failed with a strange linker error:
> > 
> > /usr/bin/ld: g++  -g -O2
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -DUCHAR_TYPE=uint16_t -fno-lifetime-dse
> > -fno-strict-aliasing -Wl,-z,relro -Wl,-z,now -Wl,-z,relro -Wl,-z,now
> > -pthread-Wl,--version-script,empty.vers
> > /<>/temp/Release/alice/alice.o
> > /<>/temp/Release/alice/alice_meta.o
> > /<>/temp/Release/alice/exe.o
> > /<>/temp/Release/alice/tdr.o
> > /<>/temp/Release/alice/main/aliceMain.o
> > /<>/temp/Release/common.a -o
> > /<>/gen/Release/firebird/bin/gfix
> > -L/<>/gen/Release/firebird/lib -lfbclient -ltommath -ltomcrypt
> > -latomic -lm -ldl   -ldecFloat -lre2
> > /<>/temp/Release/common.a(SimilarToRegex.o): in function
> > `Firebird::SimilarToRegex::matches(char const*, unsigned int,
> > Firebird::Array > Firebird::EmptyStorage >*)':
> > ./gen/./src/common/SimilarToRegex.cpp:858: undefined reference to 
> > `re2::RE2::Arg::parse_stringpiece(char const*, unsigned long, void*)'
> 
> Thanks for the notice.
> 
> This is probably related to the new g++ in sid. Trying the build today 
> failed even earlier, perhaps due to the new autotools. So this needs 
> more work.

Simply letting debhelper do the autoreconf seems to work and the build 
completes, no linker errors. This is in an up to date sid sbuild 
chroot.

-- Damyan

Bug#992133: firebird4.0 debian packaging

[Damyan Ivanov]

-=| Frank Doepper, 25.08.2021 16:58:15 +0200 |=-
> Hi Damyan,
> 
> great that you are packaging firebird4.0 for Debian. Volker and I have tried
> to build the source from
> https://salsa.debian.org/firebird-team/firebird4.0/
> with our mini-buildd on Debian Sid
> at Tue, 17 Aug 2021 10:32:13 +
> and it failed with a strange linker error:
> 
> /usr/bin/ld: g++  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -DUCHAR_TYPE=uint16_t -fno-lifetime-dse
> -fno-strict-aliasing -Wl,-z,relro -Wl,-z,now -Wl,-z,relro -Wl,-z,now
> -pthread-Wl,--version-script,empty.vers
> /<>/temp/Release/alice/alice.o
> /<>/temp/Release/alice/alice_meta.o
> /<>/temp/Release/alice/exe.o
> /<>/temp/Release/alice/tdr.o
> /<>/temp/Release/alice/main/aliceMain.o
> /<>/temp/Release/common.a -o
> /<>/gen/Release/firebird/bin/gfix
> -L/<>/gen/Release/firebird/lib -lfbclient -ltommath -ltomcrypt
> -latomic -lm -ldl   -ldecFloat -lre2
> /<>/temp/Release/common.a(SimilarToRegex.o): in function
> `Firebird::SimilarToRegex::matches(char const*, unsigned int,
> Firebird::Array Firebird::EmptyStorage >*)':
> ./gen/./src/common/SimilarToRegex.cpp:858: undefined reference to 
> `re2::RE2::Arg::parse_stringpiece(char const*, unsigned long, void*)'

Thanks for the notice.

This is probably related to the new g++ in sid. Trying the build today 
failed even earlier, perhaps due to the new autotools. So this needs 
more work.

I am not sure when that work would happen. There is also work going 
upstream to fix the build on big-endian architectures. Help is 
welcome.


-- Damyan

Bug#992408: update.d/libc broken with debianutils 5.0 - run-parts not in $PATH

[Damyan Ivanov]

Package: resolvconf
Version: 1.87
Severity: important
Tags: patch

Hi,

debianutils 5.0 has moved run-parts from /bin to /usr/bin. This breaks 
etc/resolvconf/update.d/libc (part of resolvconf) which relies on run-parts, 
but sets PATH to /sbin:/bin.

The attached patch appends /usr/sbin:/usr/bin to the PATH which makes the 
script work with the change in debianutils 5.0.


Thanks for considering,
Damyan


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages resolvconf depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  lsb-base   11.1.0

resolvconf recommends no packages.

resolvconf suggests no packages.

-- debconf-show failed
diff --git a/debian/changelog b/debian/changelog
index 4e8de3d..c3ff3b9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+resolvconf (1.84+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * update.d/libc: add /usr/sbin:/usr/bin to $PATH
+fixes run-parts usage with debianutils 5.0
+
+ -- Damyan Ivanov   Wed, 18 Aug 2021 08:17:33 +
+
 resolvconf (1.84) unstable; urgency=medium
 
   [ Rob Leslie ]
diff --git a/etc/resolvconf/update.d/libc b/etc/resolvconf/update.d/libc
index 12298c7..1c4f6bc 100755
--- a/etc/resolvconf/update.d/libc
+++ b/etc/resolvconf/update.d/libc
@@ -16,7 +16,7 @@
 #
 
 set -e
-PATH=/sbin:/bin
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
 
 [ -x /lib/resolvconf/list-records ] || exit 1
 

Bug#956492: ifupdown: hardcodes path to run-parts

[Damyan Ivanov]

Package: ifupdown
Version: 0.8.36
Followup-For: Bug #956492
Control: tag -1 patch

I just got bitten by this after upgrading debianutils to version 5.0.
The symptom is that the network never goes up and running `ifup eth0` exits 
with '/bin/run-parts: not found'.

The work-around was to

  ln -s /usr/bin/run-parts /bin/

Looking at the code, run-parts is run via a shell, so removing the hardcoded 
path and relying on the shell to find it should work. See execute.c:

 113 int doit(const char *str) {
 ...
 139 case 0: /* child */
 140 execle("/bin/sh", "/bin/sh", "-c", str, NULL, 
localenv);
 141 err(127, "executing '%s' failed", str);
 ...
 169 static int execute_scripts(interface_defn *ifd, execfn *exec, char *opt) {
 ...
 180 char *command;
 181 if(asprintf(&command, "/bin/run-parts %s%s/etc/network/if-%s.d", 
ignore_failures ? "" : "--exit-on-error ", verbose ? "--verbose " : "", opt) == 
-1)
 182 err(1, "asprintf");


Please find attached a patch that removes '/bin/' on line 181 above and adjusts
all the tests under tests/ so that the package builds. This change makes 
ifupdown work with the change in debianutils 5.0.

Thanks for consireding,
Damyan
diff --git a/debian/changelog b/debian/changelog
index 88a9688..4a6c767 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ifupdown (0.8.36+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * remove hard-coded path to run-parts
+
+ -- Damyan Ivanov   Wed, 18 Aug 2021 07:41:22 +
+
 ifupdown (0.8.36) unstable; urgency=low
 
   [ Janos Lenart ]
diff --git a/tests/hurd/down.1 b/tests/hurd/down.1
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.1
+++ b/tests/hurd/down.1
@@ -1,5 +1,5 @@
 exit code: 0
 stdout
 stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.11 b/tests/hurd/down.11
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.11
+++ b/tests/hurd/down.11
@@ -1,5 +1,5 @@
 exit code: 0
 stdout
 stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.2 b/tests/hurd/down.2
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.2
+++ b/tests/hurd/down.2
@@ -1,5 +1,5 @@
 exit code: 0
 stdout
 stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.3 b/tests/hurd/down.3
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.3
+++ b/tests/hurd/down.3
@@ -1,5 +1,5 @@
 exit code: 0
 stdout
 stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.4 b/tests/hurd/down.4
index 1994a04..36db57e 100644
--- a/tests/hurd/down.4
+++ b/tests/hurd/down.4
@@ -2,6 +2,6 @@ exit code: 0
 stdout
 stderr
 ifdown: configuring interface /dev/eth0=work (inet)
-/bin/run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-down.d
 inetutils-ifconfig --interface /dev/eth0 --down
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.5 b/tests/hurd/down.5
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.5
+++ b/tests/hurd/down.5
@@ -1,5 +1,5 @@
 exit code: 0
 stdout
 stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/down.6 b/tests/hurd/down.6
index c9b53c2..374f38d 100644
--- a/tests/hurd/down.6
+++ b/tests/hurd/down.6
@@ -1,5 +1,5 @@
 exit code: 0
 stdout
 stderr
-/bin/run-parts --verbose /etc/network/if-down.d
-/bin/run-parts --verbose /etc/network/if-post-down.d
+run-parts --verbose /etc/network/if-down.d
+run-parts --verbose /etc/network/if-post-down.d
diff --git a/tests/hurd/up.1 b/tests/hurd/up.1
index 8b2b316..f7bb8b7 100644
--- a/tests/hurd/up.1
+++ b/tests/hurd/up.1
@@ -1,17 +1,17 @@
 exit code: 0
 stdout
 stderr
-/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
+run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
 inetutils-ifconfig --interface lo --address 127.0.0.1 --up
 ifup: configuring in

Bug#992133: ITP: firebird4.0 -- Firebird RDBMS (version 4.0)

[Damyan Ivanov]

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: firebird4.0
  Version : 4.0.0.2496
  Upstream Author : Firebird developers (firebird-de...@lists.sourceforge.net)
* URL : https://www.firebirdsql.org/
* License : Mostly Initial Developer Public License 1.0 (MPL-like)
  Programming Lang: C++, C
  Description : Feature-rich, scalable relational database

Firebird 4 is the next generation following firebird 3 (available as 
firebird3.0 in Debian). Compared to firebird 3, this version adds:

 * Built-in logical replication;
 * Extended length of metadata identifiers (up to 63 characters);
 * New INT128 and DECFLOAT data types, longer precision for NUMERIC/DECIMAL 
   data types;
 * Support for international time zones;
 * Configurable time-outs for connections and statements;
 * Pooling of external connections;
 * Batch operations in the API;
 * Built-in cryptographic functions;
 * New ODS (version 13) with new system and monitoring tables;
 * Maximum page size increased to 32KB.

It needs to be packaged separately because the on-disk database format is not 
compatible with firebird3.0.

The packaging is based on firebird3.0, with updated copyright and patches.

Bug#986565: unusable with current git

[Damyan Ivanov]

Package: git-flow
Version: 1.12.3-2
Followup-For: Bug #986565

Control: reopen -1 1.12.3-2

Sigh. Now git reverted to using /usr/lib again, and git-flow is broken.

Reverting the changes in 1.12.3-2 would fix it.

Reading https://bugs.debian.org/985416 (the bug report in git about changing 
the path), I am left with the impression that the proper fix is to ship 
/usr/bin/git-flow. Perhaps the other scripts need to be in /usr/bin too.


HTH,
Damyan


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git-flow depends on:
ii  git [git-core]  1:2.31.1-1
ii  git-core1:2.15.0~rc0-1

git-flow recommends no packages.

git-flow suggests no packages.

-- no debconf information

Bug#986565: unusable with current git

[Damyan Ivanov]

Package: git-flow
Version: 1.12.3-1
Severity: grave
Tags: patch

Today 'flow' is not a supported git command:

 $git flow
 git: 'flow' is not a git command. See 'git --help'.
 
 The most similar commands are
reflog
show

Running it under strace reveals that git looks for commands under 
/usr/libexec/git-core, while git-flow installs things under /usr/lib/git-core

Perhaps this is caused by a change in the search path in git and git-flow needs 
to adapt.

Replacing /usr/lib/git-core with /usr/libexec/git-core in debian/install.mk 
seems to fix the problem.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git-flow depends on:
ii  git [git-core]  1:2.31.0-1
ii  git-core1:2.15.0~rc0-1

git-flow recommends no packages.

git-flow suggests no packages.

-- debconf-show failed

Bug#985184: REminiscence no longer licensed under the GNU GPL?

[Damyan Ivanov]

Hi,

(feel free to remove 985...@bugs.debian.org from Cc if you don't want 
your reply to be archived publicly)

I contacted you about this on 1 January 2018 but perhaps that mail got 
lost.

While preparing an update of the Debian package of REminiscence, 
I noticed that all the license grants are gone from the sources. This 
makes it impossible for anybody but the original author to distribute 
REminiscence.

Was this an intentional change?

Here's the part that is present in version 0.2.1 and gone in 0.3.5+:

 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see .

The full diff is available at 
https://salsa.debian.org/games-team/reminiscence/-/commit/063a8ef67651de1f6810ad47b3002f2228e33cf1#ae0bcc2782149fe37425163d4b8132679d343fef

If you could release REminiscence with the GPL¹ licensing restored, 
I'd be happy to update the Debian package to the latest version. It 
has some features like support for SDL2 that would be really nice to 
have.

If the change was intentional, I guess our only option is to remove 
REminiscence from Debian. Sad as that would be, having a severely 
outdated package is of no service to our users.


Best regards,
Damyan

 ¹ any other free software license like BSD or Artistic would do too 
   (https://www.debian.org/social_contract#guidelines)

Bug#985490: unblock: flamerobin/0.9.3.6-2

[Damyan Ivanov]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package flamerobin

Version 0.9.3.6-2 fixes a serious bug in handling dir->symlink and symlink->dir 
migration when the package is upgraded from stable 
(https://bugs.debian.org/985289). Full source debdiff attached.

First I confirmed that the problem is present: removed the package, installed 
stable version (0.9.3~+20160512.c75f8618-2), upgraded to testing version 
(0.9.3.6-1), noted /usr/share/doc/flamerobin/html is still a symlink to 
/usr/share/flamerobin/docs instead of the reverse.

Then I tested whether the new package fixes the problem: removed the package 
again, installed the stable version and upgraded to the proposed version 
(0.9.3.6-2). /usr/share/doc/flamerobin/html now is a directory, and 
/usr/share/flamerobin/docs is a symlink to it. This is the wanted state, and 
this is what happens if the proposed version is installed anew.

I also checked that the small in-built documentation browser still finds its 
docs.


unblock flamerobin/0.9.3.6-2


Thanks,
dam
diff -Nru flamerobin-0.9.3.6/debian/changelog 
flamerobin-0.9.3.6/debian/changelog
--- flamerobin-0.9.3.6/debian/changelog 2021-01-11 10:07:02.0 +0200
+++ flamerobin-0.9.3.6/debian/changelog 2021-03-19 07:54:27.0 +0200
@@ -1,3 +1,25 @@
+flamerobin (0.9.3.6-2) unstable; urgency=medium
+
+  * ensure proper migration from docs symlink to directory and vice versa
+.
+In 0.9.3.5-1 /usr/share/flamerobin/docs was moved to
+/usr/share/doc/flamerobin/html with a symlink at the old location
+.
+Old state
+  /usr/share/doc/flamerobin/html -> ../../flamerobin/docs
+  /usr/share/flamerobin/docs -- a directory with HTML files
+New state
+  /usr/share/doc/flamerobin/html -- a directory with HTML files
+  /usr/share/flamerobin/docs -> ../doc/flamerobin/html
+.
+Since dpkg won't do dir<->symlink conversions, add maintscript for the
+two transitions. Also add Pre-Depends on dpkg 1.17.14 for maintscript
+support.
+.
+Thanks to Andreas Beckmann for reporting (Closes: #985289)
+
+ -- Damyan Ivanov   Fri, 19 Mar 2021 05:54:27 +
+
 flamerobin (0.9.3.6-1) unstable; urgency=medium
 
   * New upstream snapshot release
diff -Nru flamerobin-0.9.3.6/debian/control flamerobin-0.9.3.6/debian/control
--- flamerobin-0.9.3.6/debian/control   2021-01-11 10:02:34.0 +0200
+++ flamerobin-0.9.3.6/debian/control   2021-03-19 07:49:24.0 +0200
@@ -17,6 +17,7 @@
 
 Package: flamerobin
 Architecture: any
+Pre-Depends: dpkg (>= 1.17.14)
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Suggests: firebird3.0-server
 Description: graphical database administration tool for Firebird DBMS
diff -Nru flamerobin-0.9.3.6/debian/flamerobin.maintscript 
flamerobin-0.9.3.6/debian/flamerobin.maintscript
--- flamerobin-0.9.3.6/debian/flamerobin.maintscript1970-01-01 
02:00:00.0 +0200
+++ flamerobin-0.9.3.6/debian/flamerobin.maintscript2021-03-19 
07:49:24.0 +0200
@@ -0,0 +1,3 @@
+symlink_to_dir /usr/share/doc/flamerobin/html ../../flamerobin/docs 0.9.3.4-1
+
+dir_to_symlink /usr/share/flamerobin/docs ../doc/flamerobin/html 0.9.3.4-1

Bug#985184: reminiscence: New upstream version available

[Damyan Ivanov]

-=| Guillem Jover, 14.03.2021 04:42:07 +0100 |=-
> Upstream is at 0.4.6, which happens to have SDL2 support, which 
> among others supports Wayland natively. SDL1 is considered 
> deprecated by upstream and should be switched away from.

Unfortunately, all license statements in the source have disappeared 
somewhere between versions 0.2.1 and 0.3.5 (there is no public VCS so 
I can't say for certain).

I'll mail the author to check whether this was intentional. If it was, 
or if there's no response, I guess the only solution would be to drop 
reminiscence from Debian.


-- Damyan

Bug#979211: flamerobin: table list incomplete

[Damyan Ivanov]

Package: flamerobin
Version: 0.9.3.5-1
Severity: important
Tags: upstream
Forwarded: https://github.com/mariuz/flamerobin/issues/142

The list of tables in version 0.9.3.5 is much shorter and misses about 3/4 of 
the tables.

Screenshots available in the upstream bug report at 
https://github.com/mariuz/flamerobin/issues/142



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages flamerobin depends on:
ii  libc6 2.31-7
ii  libfbclient2  3.0.7.33374.ds4-2
ii  libgcc-s1 10.2.1-3
ii  libstdc++610.2.1-3
ii  libwxbase3.0-0v5  3.0.5.1+dfsg-2
ii  libwxgtk3.0-gtk3-0v5  3.0.5.1+dfsg-2

flamerobin recommends no packages.

Versions of packages flamerobin suggests:
ii  firebird3.0-server  3.0.7.33374.ds4-2

-- no debconf information

Bug#975747: android/libbacktrace.so.0: undefined reference to `unwindstack::RemoteMaps::GetMapsFile[abi:cxx11]() const'

[Damyan Ivanov]

Package: android-libbacktrace
Version: 1:10.0.0+r36-1~stage1.3
Followup-For: Bug #975747

Control: affects -1 zipalign

This seems to render zipalign unusable:

 $ zipalign
 zipalign: symbol lookup error: 
 /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: 
 _ZN11unwindstack12ElfInterfaceD2Ev



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages android-libbacktrace depends on:
ii  android-libbase1:10.0.0+r36-1~stage1.3
ii  android-libcutils  1:10.0.0+r36-1~stage1.3
ii  android-liblog 1:10.0.0+r36-1~stage1.3
ii  android-libunwind  10.0.0+r36-4
ii  libc6  2.31-6
ii  libgcc-s1  10.2.1-3
ii  liblzma5   5.2.4-1+b1
ii  libstdc++6 10.2.1-3

android-libbacktrace recommends no packages.

android-libbacktrace suggests no packages.

-- no debconf information

Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

[Damyan Ivanov]

-=| Damyan Ivanov, 23.11.2020 22:16:43 +0200 |=-
> -=| Sam Hartman, 23.11.2020 10:02:34 -0500 |=-
> > Here's a patch that I believe will get libapache-mod-auth-kerb 
> > working with the latest krb5.  I'll go upload a krb5 that fixes the 
> > breaks relationship.
> > 
> > I'd appreciate it if someone who actually uses 
> > libapache-mod-auth-kerb will test this patch.
> > If it gets tested, I'll NMU.  If not, I'll ask the release team to
> > remove libapache-mod-auth-kerb from testing.
> 
> I'll try to find time to test the patch tomorrow (UTC+02).

A bit late, but I succeeded in testing the patch. Upgrading libkrb5-3 
and its dependencies to 1.18.3-4 doesn't break apache2 with 
mod-auth-kerb anymore. Moreover, the basic functionality (user 
authentication against a domain controller) works as before.

I am attaching a minimal patch, with the following changes compared to 
Sam's patch:

 - removed another instance of 'have_rcache_type' usage
 - removed all but the changes in debian/changelog, 
   debian/patches/serries and the real patch to mod_auth_kerb.c that 
   lives under debian/patches/.

I think this patch can be used for a clean NMU.

Cheers,
Damyan
diff --git a/debian/changelog b/debian/changelog
index b04ca6a..f621e17 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libapache-mod-auth-kerb (5.4-2.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Always assume none replay cache type is present, Closes: #975344
+
+ -- Sam Hartman   Mon, 23 Nov 2020 09:34:53 -0500
+
 libapache-mod-auth-kerb (5.4-2.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/0011-Always-use-NONE-replay-cache-type.patch b/debian/patches/0011-Always-use-NONE-replay-cache-type.patch
new file mode 100644
index 000..71aaf40
--- /dev/null
+++ b/debian/patches/0011-Always-use-NONE-replay-cache-type.patch
@@ -0,0 +1,73 @@
+From: Sam Hartman 
+Date: Mon, 23 Nov 2020 09:30:22 -0500
+Subject: Always use NONE replay cache type
+
+It's 2020.  Any MIT Kerberos in the wild supports the none replay
+cache type.  The previous code used an internal function to detect
+that replay cache type; that function is no longer available.
+Instead, assume it is present.
+
+An alternative would be to enable the default replay cache.  It was
+originally disabled because of problems between Microsoft
+authenticators and 2004-era MIT Kerberos 1.3.  That's probably a good
+idea.  It probably closes off security attacks, although analyzing the
+impact of replays in cases where neither channel binding nor
+per-message services are used is difficult.  I believe that a replay
+cache is not strictly necessary in the common configuration where
+mod-auth-kerb is used over a TLS-protected connection where the client
+properly verifies the TLS certificate presented by the server prior to
+sending a GSS token.
+
+I have elected not to enable replay cache to affect a minimal change.
+---
+ src/mod_auth_kerb.c | 23 +--
+ 1 file changed, 1 insertion(+), 22 deletions(-)
+
+--- a/src/mod_auth_kerb.c
 b/src/mod_auth_kerb.c
+@@ -2057,27 +2057,6 @@ kerb_authenticate_user(request_rec *r)
+return ret;
+ }
+ 
+-static int
+-have_rcache_type(const char *type)
+-{
+-   krb5_error_code ret;
+-   krb5_context context;
+-   krb5_rcache id = NULL;
+-   int found;
+-
+-   ret = krb5_init_context(&context);
+-   if (ret)
+-  return 0;
+-
+-   ret = krb5_rc_resolve_full(context, &id, "none:");
+-   found = (ret == 0);
+-
+-   if (ret == 0)
+-  krb5_rc_destroy(context, id);
+-   krb5_free_context(context);
+-
+-   return found;
+-}
+ 
+ /*** 
+  Module Setup/Configuration
+@@ -2139,7 +2118,7 @@ kerb_module_init(server_rec *dummy, pool
+ #ifndef HEIMDAL
+/* Suppress the MIT replay cache.  Requires MIT Kerberos 1.4.0 or later.
+   1.3.x are covered by the hack overiding the replay calls */
+-   if (getenv("KRB5RCACHETYPE") == NULL && have_rcache_type("none"))
++   if (getenv("KRB5RCACHETYPE") == NULL )
+   putenv(strdup("KRB5RCACHETYPE=none"));
+ #endif
+ }
+@@ -2181,7 +2160,7 @@ kerb_init_handler(apr_pool_t *p, apr_poo
+ #ifndef HEIMDAL
+/* Suppress the MIT replay cache.  Requires MIT Kerberos 1.4.0 or later.
+   1.3.x are covered by the hack overiding the replay calls */
+-   if (getenv("KRB5RCACHETYPE") == NULL && have_rcache_type("none"))
++   if (getenv("KRB5RCACHETYPE") == NULL)
+   putenv(strdup("KRB5RCACHETYPE=none"));
+ #endif
+ #ifdef STANDARD20_MODULE_STUFF
diff --git a/debian/patches/series b/debian/patches/series
index d2c7173..9848ef3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@ remove_bashism.patch
 gssapi_delegation.patch
 apache24.patch
 mod_auth_kerb-krb5_kt_close.patch
+0011-Always-use-NONE-replay-cache-type.patch

Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

[Damyan Ivanov]

-=| Sam Hartman, 23.11.2020 10:02:34 -0500 |=-
> Here's a patch that I believe will get libapache-mod-auth-kerb 
> working with the latest krb5.  I'll go upload a krb5 that fixes the 
> breaks relationship.

Thank you, Sam.

> I'd appreciate it if someone who actually uses 
> libapache-mod-auth-kerb will test this patch.
> If it gets tested, I'll NMU.  If not, I'll ask the release team to
> remove libapache-mod-auth-kerb from testing.

I'll try to find time to test the patch tomorrow (UTC+02).

About removing auth-kerb from testing, this may be not so bad. I see 
Fedora have removed it, with auth-gssapi as a functional replacement. 
I plan to test that too at some point.


-- Damyan

Bug#975344: libkrb5-3: ABI breakage in 1.18: krb5_rc_resolve_full missing

[Damyan Ivanov]

Package: libkrb5-3
Version: 1.18.2-1
Severity: serious
Justification: Policy 8.6.2

Hi,

libkrb5-3 version 1.18.2-1 breaks apache2 when the kerberos authentication 
module is enabled. The error message is:

 apache2: Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error 
 on line 1 of /etc/apache2/mods-enabled/auth_kerb.load: Cannot load 
 /usr/lib/apache2/modules/mod_auth_kerb.so into server: 
 /usr/lib/apache2/modules/mod_auth_kerb.so: undefined symbol: 
 krb5_rc_resolve_full, version krb5_3_MIT

The error is gone when libkrb5-3 (along with dependencies) is downgraded to 
1.17-10.

Listing symbols with nm confirms the missing symbol.

1.17-10:
 $ nm -D  /usr/lib/x86_64-linux-gnu/libkrb5.so.3   | grep krb5_rc_resolve_full
 0006a410 T krb5_rc_resolve_full@@krb5_3_MIT
 $

1.18.2-1:
 $ nm -D  /usr/lib/x86_64-linux-gnu/libkrb5.so.3   | grep krb5_rc_resolve_full
 $

I think this is the reason for the failing CI runs on ppc64el for squid¹ and 
bind9². The other architecture strangely don't fail -- probably because the 
test sets are different -- there is no 'apache2' in the passing logs.

 ¹ https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/squid/8297228/log.gz
 ² https://ci.debian.net/data/autopkgtest/testing/ppc64el/b/bind9/8297196/log.gz

Removing a symbol deserves a soname bump, per Policy 8.6.2, thus the severity.

Looking at 88f4594e6a34c7b88bcd06ab06be2738113c226b in the packaging repository 
I see a lot of removed symbols.

krb5_rc_resolve_full disappears upstream with 
dcb853ac32779b173f39e19c0f24b0087de85771. I assume dependencies like 
libapache2-mod-auth-kerb will need to adapt to the changes.


Cheers,
Damyan

Bug#974922: libapache2-mod-perl2: "mod_perl interferes with mod_php locales, unable to use gettext translations"

[Damyan Ivanov]

Hi Claudio,
-=| Claudio Kuenzler, 16.11.2020 15:26:45 +0100 |=-
>   When using mod_perl and mod_php at the same time, mod_perl somehow 
>   interferes with PHPs ability to translate texts using gettext.
>   The PHP translation works fine using CLI but not via Apache web server.
>   
>   $ curl localhost/translate.php
>   My original English text (not translated)
> 
>   As soon as mod_perl is disabled, the translations work:
> 
>   # a2dismod perl
>   # systemctl restart apache2
> 
>   $ curl localhost/translate.php
>   Mein deutscher Text (translated)
> 
>  This happened on Debian 10. Language in the PHP script was set to 
>  de_CH.UTF-8. mod_php is 7.3.19.

It would be nice if you could share the translate.php contents (or 
a minimal version) so that the issue can be reproduced and any 
prospective fixes/workarounds be tested.


-- Damyan

Bug#973118: kgb-bot: FTBFS: dh_auto_test: error: perl Build test --verbose 1 returned exit code 255

[Damyan Ivanov]

-=| Lucas Nussbaum, 27.10.2020 18:05:31 +0100 |=-
> Source: kgb-bot
> Version: 1.57-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201027 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > …
> > #   Failed test at t/52-client-git.t line 399.
> > #  got: 'Merge branch 'allnew''
> > # expected: 'Merge branch 'allnew' into master'
> > # stopping test bot, pid 29366
> > # Removing directory /<>/t/bot
> > …

This looks like a re-occurrence of #965350 when we had:

| #   Failed test at t/52-client-git.t line 393.
| #  got: 'Merge branch 'allnew' into master'
| # expected: 'Merge branch 'allnew''

Perhaps the change in the output was reverted.

I think the idea from Jonathan to make the test more generic still 
holds. I am thinking about extending t/TestBot.pm to allow usage of 
regular expressions. The hard part would be to do this safely.

Another option would be to detect the commit message format and use 
that information in the test.

I'll look into this before 9 November (i.e. please feel free to act 
before that :) )


-- dam

Bug#972218: depends on liblocale-codes-perl

[Damyan Ivanov]

-=| Jeff, 15.10.2020 08:03:49 +0200 |=-
> Apologies for being (slightly) off-topic:
> 
> gscan2pdf-2.9.1 has a new depends on liblocale-codes-perl:
> 
> https://packages.debian.org/sid/gscan2pdf
> 
> but for (maybe only some) users upgrading from 2.9.0, apt doesn't seem
> to be pulling in liblocale-codes-perl. I've had four or five reports
> similar to this:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972218
> 
> Can anyone show me where my bug is hiding?

My clue was the list of dependencies in the reportbug boilerplate of 
#972218:

…
ii  libtry-tiny-perl  0.30-1
ii  perl-modules-5.24 [liblocale-codes-perl]  5.24.1-3+deb9u5
ii  sane-utils1.0.31-2

liblocale-codes-perl is provided by perl-modules-5.24. That's 
oldstable and perhaps an *unused* leftover from an upgrade.

My guess was that gscan2pdf misses a dependency on `perl' (missing in 
the reportbug's list). perl would bring suitable perl-modules-x.yy 
package that is actually in the search path (@INC) and provides 
Locale::Language.

However, libtry-tiny-perl has a dependency on `perl', so while I still 
think that gscan2pdf needs to depend on `perl', I don't understand how 
missing that would lead to the situation in the bug report.


Confused,
dam

Bug#971087: gnome-shell-extension-dash-to-panel: not compatible with gnome-shell 3.38

[Damyan Ivanov]

Package: gnome-shell-extension-dash-to-panel
Version: 39-1
Severity: grave
Tags: upstream patch
Justification: renders package unusable

Control: forwarded -1 
https://github.com/home-sweet-gnome/dash-to-panel/issues/1034

Hi,

With gnome-shell 3.38 entering ustable, dash-to-panel no longer loads.

This is because its metadata.json doesn't declare compatibility with shell 
3.38, but even after manually adding 3.38 to the list of supported shell 
versions, the extension fails to load with an exception:

 gnome-shell[3480]: JS ERROR: Extension dash-to-pa...@jderose9.github.com: 
TypeError: Main.overview.viewSelector.appDisplay._views is undefined
   
_init@/usr/share/gnome-shell/extensions/dash-to-pa...@jderose9.github.com/panelManager.js:67:9
   
C@/usr/share/gnome-shell/extensions/dash-to-pa...@jderose9.github.com/utils.js 
line 83 > eval:1:46
   
_enable@/usr/share/gnome-shell/extensions/dash-to-pa...@jderose9.github.com/extension.js:95:20
   
enable@/usr/share/gnome-shell/extensions/dash-to-pa...@jderose9.github.com/extension.js:65:5
   
_callExtensionEnable@resource:///org/gnome/shell/ui/extensionSystem.js:167:32
   
loadExtension@resource:///org/gnome/shell/ui/extensionSystem.js:348:26
   
_loadExtensions/<@resource:///org/gnome/shell/ui/extensionSystem.js:586:18
   
collectFromDatadirs@resource:///org/gnome/shell/misc/fileUtils.js:27:28
   
_loadExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:565:19
   
_enableAllExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:595:18
   
_sessionUpdated@resource:///org/gnome/shell/ui/extensionSystem.js:626:18
   init@resource:///org/gnome/shell/ui/extensionSystem.js:56:14
   _initializeUI@resource:///org/gnome/shell/ui/main.js:269:22
   start@resource:///org/gnome/shell/ui/main.js:159:5
   @:1:47

This is reported upstream as 
https://github.com/home-sweet-gnome/dash-to-panel/issues/1034 and comments 
there claim that the master branch is fixed.


Thank you for making this lovely extension available to Debian users!

-- dam

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-shell-extension-dash-to-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  gnome-shell  3.38.0-2
ii  gnome-shell-extension-prefs  3.38.0-2

gnome-shell-extension-dash-to-panel recommends no packages.

gnome-shell-extension-dash-to-panel suggests no packages.

-- no debconf information

Bug#960863: Help needed with perl-tk NMU

[Damyan Ivanov]

-=| Dominic Hargreaves, 13.09.2020 18:37:21 +0100 |=-
> On Sat, Sep 12, 2020 at 10:45:23PM +0300, Damyan Ivanov wrote:
> > -=| Damyan Ivanov, 11.09.2020 12:08:04 +0300 |=-
> > > I tried the "new upstream release" route because otherwise there 
> > > would be several patches to import, one of them adding 10k-lines 
> > > ppport.h
> > > 
> > > The result is at https://salsa.debian.org/dmn/perl-tk and builds with 
> > > per 5.32. There are many lintian/hardening warnings, but since this is 
> > > a NMU, the changes are bare minimum.
> > > 
> > > I haven't tested the resulting package yet, will have to find a way 
> > > to do so without disturbing the rest of the system. (perhaps 
> > > docker+vnc would help).
> > 
> > I got around to try this and the results seem acceptable to me.
> > 
> > All the examples seemed OK.
> > 
> > I tried two packages that depend on perl-tk: nama and mapivi.
> > …
> >
> So let's go ahead with your proposal, and if it comes a blocker, we 
> can consider rescheduling it.

Package uploaded to DELAYED/7-day.

Instead of attaching the NMU diff here, let me point to URL of the 
changes made: 
<https://salsa.debian.org/dmn/perl-tk/-/commits/master/>.


Greetings,
dam

Bug#970224: cryptsetup-suspend: suspending after resume requires unlocking cryptsetup

[Damyan Ivanov]

Package: cryptsetup-suspend
Version: 2:2.3.4-1+exp1
Severity: normal

Hi,

Thanks for cryptsetup-suspend, it is great!

In short, the glitch I am reporting is that there is no way to suspend the 
laptop when it has resumed, but cryptsetup hasn't been ynlocked yet. Like, just 
open and close the lid.

Imagine you are about to travel. Your laptop is suspended and thanks to 
cryptdisk-suspend, this is safer than before. You decide to quickly hack on a 
pet project and open the lid. The console asks you to unlock cryptsetup. Then 
suddenly you realize that there is no time and the bus is about to leave very 
soon, so you just close the lid, put the laptop in the bag and run. A couple of 
hours of frantic bus riding and airport checks later you open the laptop in the 
airport lounge to discover it has depleted the battery because it was on (not 
suspended) during the ride.

(imagine a sad laptop image here)

I guess the unlock-on-resume environment is quite constrained and it has no 
notion of "power management" etc, but still, the situation above is quite 
possible and that possibility adds back some "suspend is tricky" attitude I was 
happy to abandon.



Cheers,
dam


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.8.0-1-amd64 root=/dev/mapper/dx1-root ro splash

-- /etc/crypttab
nvme0n1p7_crypt UUID=c01c04b2-9b86-4b32-afca-29dae4faa01e none luks

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/dx1-root /   ext4discard,relatime,errors=remount-ro 
0   1
# /boot was on /dev/nvme0n1p6 during installation
UUID=3e10543f-ba52-4adf-8bfb-6d84ba202bd4 /boot   ext2defaults  
  0   2
# /boot/efi was on /dev/nvme0n1p2 during installation
UUID=0EB6-FFB6  /boot/efi   vfatumask=0077  0   1
#/dev/mapper/dx1-swap noneswapsw,discard0   0

none   /tmptmpfs   nosuid,size=50%,mode=1777 0 0

-- lsmod
Module  Size  Used by
xt_nat 16384  0
veth   32768  0
snd_seq_dummy  16384  0
snd_hrtimer16384  0
snd_seq86016  1 snd_seq_dummy
snd_seq_device 16384  1 snd_seq
dm_snapshot53248  0
dm_bufio   36864  1 dm_snapshot
ctr16384  2
ccm20480  6
bnep   28672  2
tun57344  1
vboxnetadp 28672  0
vboxnetflt 32768  0
nf_conntrack_netlink57344  0
xfrm_user  45056  1
xfrm_algo  16384  1 xfrm_user
cpufreq_userspace  20480  0
vboxdrv   532480  2 vboxnetadp,vboxnetflt
cpufreq_powersave  20480  0
cpufreq_conservative16384  0
sha512_ssse3   49152  0
sha512_generic 16384  1 sha512_ssse3
xt_addrtype16384  2
br_netfilter   28672  0
xt_CHECKSUM16384  2
nft_chain_nat  16384  8
xt_MASQUERADE  20480  5
nf_nat 49152  3 xt_nat,nft_chain_nat,xt_MASQUERADE
overlay   143360  0
nft_counter16384  56
nft_compat 20480  27
bridge225280  1 br_netfilter
stp16384  1 bridge
llc16384  2 bridge,stp
uvcvideo  114688  0
videobuf2_vmalloc  20480  1 uvcvideo
videobuf2_memops   20480  1 videobuf2_vmalloc
videobuf2_v4l2 28672  1 uvcvideo
videobuf2_common   57344  2 videobuf2_v4l2,uvcvideo
videodev  274432  3 videobuf2_v4l2,uvcvideo,videobuf2_common
mc 61440  4 
videodev,videobuf2_v4l2,uvcvideo,videobuf2_common
btusb  57344  0
btrtl  24576  1 btusb
btbcm  20480  1 btusb
btintel32768  1 btusb
bluetooth 712704  11 btrtl,btintel,btbcm,bnep,btusb
jitterentropy_rng  16384  1
drbg   28672  1
ansi_cprng 16384  0
ecdh_generic   16384  1 bluetooth
ecc36864  1 ecdh_generic
nf_tables 237568  196 nft_compat,nft_counter,nft_chain_nat
nfnetlink  16384  4 nft_compat,nf_conntrack_netlink,nf_tables
intel_rapl_msr 20480  0
joydev 28672  0
intel_rapl_common  32768  1 intel_rapl_msr
x86_pkg_temp_thermal20480  0
intel_powerclamp   20480  0
snd_soc_skl   180224  0
coretemp   20480  0
snd_soc_hdac_hda   24576  1 snd_soc_skl
snd_hda_ext_core   36864  2 snd_soc_hdac_hda,snd_soc_skl
snd_soc_sst_ipc20480  1 snd_soc_skl
kvm_intel 319488  0
snd_soc_sst_dsp40960  1 snd_soc_skl
snd_soc_acpi_intel_match45056  1 snd_soc_skl
snd_soc_acpi   16384  2 snd_soc_acpi_intel_match,snd_soc_skl
snd_soc_core  303104  2 sn

Bug#960863: Help needed with perl-tk NMU

[Damyan Ivanov]

-=| Damyan Ivanov, 11.09.2020 12:08:04 +0300 |=-
> I tried the "new upstream release" route because otherwise there 
> would be several patches to import, one of them adding 10k-lines 
> ppport.h
> 
> The result is at https://salsa.debian.org/dmn/perl-tk and builds with 
> per 5.32. There are many lintian/hardening warnings, but since this is 
> a NMU, the changes are bare minimum.
> 
> I haven't tested the resulting package yet, will have to find a way 
> to do so without disturbing the rest of the system. (perhaps 
> docker+vnc would help).

I got around to try this and the results seem acceptable to me.

All the examples seemed OK.

I tried two packages that depend on perl-tk: nama and mapivi.

nama seemed OK to me - no crashes, some windows appeared with menus 
buttons etc.

mapivi worked OK as long as no unicode was involved. It is a JPEG 
viewer with a file browser and unicode directory names are shown as 
latin1 garbage. When trying to open such a directory it complains on 
the console with 'Cannot cd to /path/to/spëcial: No such file or 
directory at /usr/lib/x86_64-linux-gnu/perl5/5.32/Tk/DirTree.pm'. This 
problem is also present in the version in unstable so it is not 
a regression.

Please tell me if there is another test I should perform.

Would uploading to delayed-7 in a week or so be in line with the plans 
for the arrival of 5.32 to unstable?


Cheers,
dam

Bug#960863: Help needed with perl-tk NMU

[Damyan Ivanov]

-=| Dominic Hargreaves, 10.09.2020 21:21:51 +0100 |=-
> Hi all
> 
> I didn't hear back from Colin, and so I think in order to unblock
> the perl 5.32 transition we need to NMU either a targeted fix for
> perl 5.32 compatibility, or the new upstream release. I'm not sure
> which is more appropriate given the time since the last release in
> Debian.
> 
> Any takers? I'm a bit short on time myself, these days.
> 
> See http://perl.debian.net/ for the test repository you might need
> to verify fixes.

I tried the "new upstream release" route because otherwise there would 
be several patches to import, one of them adding 10k-lines ppport.h

The result is at https://salsa.debian.org/dmn/perl-tk and builds with 
per 5.32. There are many lintian/hardening warnings, but since this is 
a NMU, the changes are bare minimum.

I haven't tested the resulting package yet, will have to find a way to 
do so without disturbing the rest of the system. (perhaps docker+vnc 
would help).


Cheers,
dam

Bug#968364: pkg-perl-tools: mojibake in dpt-forward (forwarding Debian bugs as GitHub issues)

[Damyan Ivanov]

-=| gregor herrmann, 13.08.2020 17:20:32 +0200 |=-
> Package: pkg-perl-tools
> Version: 0.62
> Severity: minor
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> In #968362 I've used the ellipsis UTF-8 character to denote an elison
> like: '[…]'.
> 
> After running `dpt forward 968362' the nice 3 dots end up in the GitHub
> issue at https://github.com/maxmind/MaxMind-DB-Writer-perl/issues/112
> as: '[�]'
> 
> Looks like there's some (UTF-8 or other) encoding directive missing
> somewhere …

I think the problem is in giving Net::GitHub::V3 a binary string 
instead of unicode string. Here's why:

Net::GitHub::V3 uses JSON::MaybeXS to construct the HTTP request 
payload. JSON::MaybeXS prefers Cpanel::JSON::XS which encodes the 
input in UTF-8.

I have tried this is a terminal that works with UTF-8:

# working
$ perl -MCpanel::JSON::XS -MEncode \
  -wE'my $test="tæst"; say $test, encode_json({test=>decode_utf8($test)})'
tæst{"test":"tæst"}

# not working
$ perl -MCpanel::JSON::XS -MEncode \
  -wE'my $test="tæst"; say $test, encode_json({test=>$test})'
tæst{"test":"tæst"}

Note the STDOUT handle has no encoding layer and there is no 'use 
utf8' in effect -- the input string is binary.

The difference is that the not working case passes a binary string. My 
guess is that encode_json() tries to encode its arguments, basically 
invoking Encode's encode_utf8() on them, resulting in double encoding. 
Something like:

$ perl -MEncode -wE'my $test="tæst"; say $test, encode_utf8($test)'
tæsttæst

The working case works because encode_json() is given an unicode 
string, which produces an utf8-encoded binary string when given to 
encode_utf8().

So my proposal is to make sure that all github related methods decode 
message contents before giving them to Net::GitHub::V3. Perhaps 
handling that in Message::edit_message:93 would be enough, but that is 
also used with non-github backends and would need testing.


-- Damyan

Bug#963731: firebird3.0-server-core: duplicate primary key values after an exception and a rollback

[Damyan Ivanov]

Package: firebird3.0-server-core
Version: 3.0.1.32609.ds4-14
Severity: important
Tags: upstream patch fixed-upstream

Control: forwarded -1 http://tracker.firebirdsql.org/browse/CORE-6343

It is possible to get duplicate values in a column declared as a primary key 
when a transaction that had inserted some new rows is rolled back after an 
exception.

Attached is the example from the upstream bug report. Transcript follows:

% FIREBIRD_LOCK=. isql-fb -user sysdba -e -i fb-core-6343.sql
Use CONNECT or CREATE DATABASE to specify a database
drop database './test.fdb';
Command error: drop database './test.fdb'
create database './test.fdb';

CREATE GLOBAL TEMPORARY TABLE GTT_TABLE (
ID INTEGER NOT NULL
) ON COMMIT DELETE ROWS;

CREATE TABLE TEST_TABLE (
ID INTEGER NOT NULL PRIMARY KEY
);

set term ^ ;
CREATE OR ALTER PROCEDURE TEST_PROC
RETURNS (
ID1 INTEGER)
AS
DECLARE VARIABLE ID2 INTEGER;
BEGIN
   INSERT INTO GTT_TABLE VALUES(1);
   INSERT INTO GTT_TABLE VALUES(2);
   INSERT INTO GTT_TABLE VALUES(3);
   FOR SELECT ID FROM GTT_TABLE
   INTO :ID1 DO
  BEGIN
INSERT INTO TEST_TABLE (ID) VALUES (:ID1);

FOR SELECT 1 FROM RDB$DATABASE INTO :ID2 DO
   IF (:ID1=3) THEN ID1 = 1/0; --in production there is 
EXCEPTION EX_NAME instead

SUSPEND;

DELETE FROM TEST_TABLE;
   END
END ^
set term ; ^

select * from test_proc;

 ID1

   1
   2
Statement failed, SQLSTATE = 22012
arithmetic exception, numeric overflow, or string truncation
-Integer divide by zero.  The code attempted to divide an integer value by an 
integer divisor of zero.
-At procedure 'TEST_PROC' line: 16, col: 41
After line 35 in file fb-core-6343.sql

rollback;
-- should result in no rows
select * from test_table;

  ID

   2
   3



select * from test_proc;

 ID1

   1
   2
Statement failed, SQLSTATE = 22012
arithmetic exception, numeric overflow, or string truncation
-Integer divide by zero.  The code attempted to divide an integer value by an 
integer divisor of zero.
-At procedure 'TEST_PROC' line: 16, col: 41
After line 40 in file fb-core-6343.sql

rollback;
-- now see the duplicates
select * from test_table;

  ID

   2
   3
   2
   3


quit;
--

Upstream commits 8b328f86ded51f4caa06fe56478788b597a34922 and 
8a837bd7fdb75e8206d8f4878a0f789f9b4fe530 have a fix which is reported 
to work. I'll confirm this is the case for the Debian package and 
upload a fixed version shortly.




This deserves a stable upload, because ensuring uniqueness of primary keys is a
critical function of a database system.

According to the upstream bug report version 3.0.1 (found in oldstable) is also
affected.


-- Damyan


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), 
LANGUAGE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firebird3.0-server-core depends on:
ii  firebird3.0-common  3.0.5.33220.ds4-2
ii  firebird3.0-common-doc  3.0.5.33220.ds4-2
ii  libc6   2.30-8
ii  libfbclient23.0.5.33220.ds4-2
ii  libgcc-s1   10.1.0-4
ii  libib-util  3.0.5.33220.ds4-2
ii  libicu6767.1-2
ii  libstdc++6  10.1.0-4

Versions of packages firebird3.0-server-core recommends:
ii  firebird3.0-utils  3.0.5.33220.ds4-2

Versions of packages firebird3.0-server-core suggests:
ii  firebird3.0-server  3.0.5.33220.ds4-2

-- no debconf information

Bug#932090: firebird3.0: Please include patch to ensure correct sizes of on-disk structures

[Damyan Ivanov]

Hello Adrian,

Sorry for the late reply.

-=| John Paul Adrian Glaubitz, 15.07.2019 00:41:49 +0200 |=-
> Source: firebird3.0
> Version: 3.0.5.33100.ds4-3
> Severity: normal
> Tags: patch
> User: debian-...@lists.debian.org
> Usertags: m68k
> 
> firebird3.0 currently fails to build from source on m68k because the native
> alignment of 16 bits on this architecture causes the on-disk structures to
> have unexpected sizes.
> 
> With the attached patch, padding is added to the affected on-disk structures
> such that the correct sizes are always guaranteed. Since this particular
> padding happens automatically and implicitly for architectures with 32 or
> 64 bits native alignment, the actual sizes and offsets of the on-disk
> structures do not change and therefore no compatibility break is going
> to occur.
> 
> Using explicit padding has the advantage that the actual sizes and offsets
> are completely visible and transparent to anyone reading the code.
> 
> I will forward this patch upstream.

Can you tell me where was the patch forwarded? I want to check whether 
it is part of some upstream branch before applying it to the debian 
package.


Thanks,
Damyan

Bug#961987: wrong opacity for .ui-widget-overlay: 0.003

[Damyan Ivanov]

Package: libjs-jquery-ui
Version: 1.12.1+dfsg-5
Severity: normal
File: /usr/share/javascript/jquery-ui/themes/base/jquery-ui.css
Tags: patch upstream

Hi,

The opacity of the ui-widget-overlay class in base theme's CSS seems 1/100th of 
the correct value. This class is applied to the shading overlay behind modal 
dialogs for example. Opacity of .003 is practically transparent.

Here's the rule for .ui-widget-overlay:

.ui-widget-overlay {
  background: #aa ;
  opacity: .003;
  filter: Alpha(Opacity=.3); /* support IE8 */
}

In 1.10.1+dfsg-1 (jessie), the rule correctly uses .3:

.ui-widget-overlay {
  background: #aa url(images/ui-bg_flat_0_aa_40x100.png) 50% 50% 
repeat-x;
  opacity: .3;
  filter: Alpha(Opacity=30);
}


Cheers,
dam

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), 
LANGUAGE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libjs-jquery-ui depends on:
ii  libjs-jquery  3.5.1+dfsg-4

Versions of packages libjs-jquery-ui recommends:
ii  javascript-common  11

Versions of packages libjs-jquery-ui suggests:
ii  libjs-jquery-ui-docs  1.12.1+dfsg-5

-- debconf-show failed

Bug#954089: libplack-perl: Please verify server identity via SSL

[Damyan Ivanov]

-=| gregor herrmann, 15.05.2020 21:14:35 +0200 |=-
> On Thu, 19 Mar 2020 14:39:13 +0200, Damyan Ivanov wrote:
> 
> > > > But to fully measure the impact, it would be nice to have the number 
> > > > of failing packages built with a patched HTTP::Tiny.
> > > I have one small concern: As the change is about checking remote SSL
> > > certs, and tests don't/can't/must not call out to the internet, is it
> > > possible that we won't really catch all potential issues?
> > Noted. The test rebuilds should be done without the usual isolation 
> > from the Internet.
> > I guess a closer inspection of the affected packages is needed.
> 
> Hi Dam and all,
> 
> did you or anyone else get to look into this rebuild effort?

I haven't. I am still at the stage of "(re-)invent an easy way to 
rebuild a list of packages with a crafted chroot". I don't see this 
changing soon, so please Dom, anybody, feel free to take the job.

> If not, Dom said that he could also try the rebuilds on
> perl.debian.net.
> 
> Notes:
> - HTTP::Tiny is in perl core and in libhttp-tiny-perl;
> - The required change looks like a one-character-patch:
>   lib/HTTP/Tiny.pm:verify_SSL   => $args{verify_SSL} || 
> $args{verify_ssl} || 0, # no verification by default
> - The tests should be run with internet enabled as much as possible.

-- dam

Bug#959474: Issues with Chinese language (all variants) when building some pages in buster

[Damyan Ivanov]

(not a Perl maintainer here)

-=| Axel Beckert, 05.05.2020 03:34:28 +0200 |=-
> → echo 包 | perl -pe 's|\s+\n|\n|sg;'
> 包
> → echo 包 | perl -M"feature unicode_strings" -pe 's|\s+\n|\n|sg;'
> �
> 
> Which kinda sounds like a Perl bug. Cc'ing the maintainers of Debian's
> perl package (not the whole Debian Perl Team), maybe they have some
> insight what actually goes wrong here and if that's indeed a Perl 
> bug.

Seems like a user (wml) bug to me (improper handling of UTF-8 encoded data):

→ echo 包赠传阅加者 | perl -CS -M"feature unicode_strings" -pe 's|\s+\n|\n|sg;'
包赠传阅加者

>From perlrun(1):

  -C [number/list]
The -C flag controls some of the Perl Unicode features.

As of 5.8.1, the -C can be followed either by a number or a list
of option letters.  The letters, their numeric values, and effects
are as follows; listing the letters is equal to summing the
numbers.

I 1   STDIN is assumed to be in UTF-8
O 2   STDOUT will be in UTF-8
E 4   STDERR will be in UTF-8
S 7   I + O + E

Perhaps the strings in wml need to be decoded from UTF-8 so that they 
aren't treated as a sequence of independent bytes?

U+0085 is "Next line (NEL)", which seems to be treated as "\n".


(
Strangely, replacing -CS with a call to STDIN->binmode("UTF-8") 
doesn't help:

 echo 包 | perl -E 'STDIN->binmode("UTF-8"); while(<>) { s|\s+\n|\n|sg; print }'
 �

Explicitly using Encode helps:

 echo 包 | perl -E 'use Encode qw(decode_utf8); while(<>) { $_ = 
decode_utf8($_); s|\s+\n|\n|sg; print }'
 Wide character in print at -e line 1, <> line 1.
 包

(whe wide character warning is expected, because STDOUT is not instructed how 
to encode unicode characters)
)

-- dam

Bug#956867: ITP: nmrpflash -- firmware flash utility for Netgear devices

[Damyan Ivanov]

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov 

* Package name: nmrpflash
  Version : 0.9.14-16-ge95526d
  Upstream Author : Joseph Lehner 
* URL : https://github.com/jclehner/nmrpflash
* License : GPL-3+
  Programming Lang: C
  Description : firmware flash utility for Netgear devices

nmrpflash uses Netgear's NMRP protocol
(http://www.chubb.wattle.id.au/PeterChubb/nmrp.html)
to flash a new firmware image to a compatible device. It has been successfully
used on a Netgear EX2700, DNG3700v2, R6220, R7000, D7000, WNR3500, R6400 and
R6800, but is likely to be compatible with many other Netgear devices.

Packaging will be developed at https://salsa.debian.org/debian/nmrpflash

Bug#945015: only-branch only takes exact branch names

[Damyan Ivanov]

-=| gregor herrmann, 19.03.2020 11:34:19 +0100 |=-
> The merge request exists, thanks Iain!
> 
> https://salsa.debian.org/kgb-team/kgb/-/merge_requests/7
> 
> To me it looks good, and I especially appreciate the added tests.
> Iain, I guess you tested the changes also with a test installation,
> as discussed on IRC?
> 
> Dam, I hope you have a moment to look at the changes as well.

Looks good to me.

This:

-  ... not grep { ... } @{...}
+  ... not any  { } @{...}

is a nice catch :)

The only things missing for me are:

 * addition of Iain in the copyright notices and debian/copyright
 * addition of the new (build) dependencies to Build.PL

But I guess these can be made at release time as well.


-- dam

Bug#954089: libplack-perl: Please verify server identity via SSL

[Damyan Ivanov]

-=| Felix Lechner, 18.03.2020 04:05:22 -0700 |=-
> Hi,
> 
> On Wed, Mar 18, 2020 at 3:18 AM Damyan Ivanov  wrote:
> >
> > Fixing the root of the problem seems better for me for two reasons:
> 
> I wish I had checked with the Debian Perl team before filing the bugs.

That would have been nice, but there's no real harm done. The problem 
is real and needs to be reported and fixed one way or another. Thank 
you for caring.

> > we may have a chance convincing
> > HTTP::Tiny's author to flip the default
> 
> Please note the module is part of Perl core. Their support may be needed also.

Certainly.

-=| gregor herrmann, 18.03.2020 17:35:11 +0100 |=-
> On Wed, 18 Mar 2020 12:18:34 +0200, Damyan Ivanov wrote:
> 
> > Fixing the root of the problem seems better for me for two 
> > reasons:
> > 
> >  1) fix what is broken instead of working around it in numerous places
> >  2) consumers outside of Debian would benefit too
> 
> I agree, also with the rest of your mail. Thanks for moving this forward!
>  
> > But to fully measure the impact, it would be nice to have the number 
> > of failing packages built with a patched HTTP::Tiny.
> 
> I have one small concern: As the change is about checking remote SSL
> certs, and tests don't/can't/must not call out to the internet, is it
> possible that we won't really catch all potential issues?

Noted. The test rebuilds should be done without the usual isolation 
from the Internet.

I guess a closer inspection of the affected packages is needed.


-- dam

Bug#954089: libplack-perl: Please verify server identity via SSL

[Damyan Ivanov]

-=| Felix Lechner, 16.03.2020 11:34:51 -0700 |=-
> On Mon, Mar 16, 2020 at 10:29 AM Damyan Ivanov  
> wrote:
> >
> > Any idea how many packages are we talking about?
> 
> Below is my working list for filing bugs. It is based on a full text
> search from codesearch.d.n.
> …

I count 30 packages that need fixing (with filed bugs or not examined 
or marked with "htto").

These would be the packages to patch if we do the "fix the client" 
way.

I was also interested in the count of failing packages when the root 
(e.g. libhttp-tiny-perl/src:perl) is fixed instead.

Fixing the root of the problem seems better for me for two reasons:

 1) fix what is broken instead of working around it in numerous places
 2) consumers outside of Debian would benefit too

2) is true even if the root fix is not applied upstream, since 
I imagine many consumers of 3rd party Perl stuff still use Debian 
packages as a base.

Note that planting work-arounds in these 30 packages with Debian 
specific patches is not good enough in my book, and taking 30 patches 
upstream is not a trivial thing. Imagine having the conversation that 
was had with HTTP::Tiny's author with 30 other authors who have 
different opinions on what is the right thing to do. I'd rather have 
two packages with Debian-specific patch.

But to fully measure the impact, it would be nice to have the number 
of failing packages built with a patched HTTP::Tiny.

I guess my contribution to this would be trying to find that number 
out. (And certainly not patching 30 packages unless other approaches 
are determined inappropriate). I can't say how long that would take, 
so please anybody, feel free to beat me to it.

If we can prove that patching HTTP::Tiny plus several failing test in 
other modules is achievable, we may have a chance convincing 
HTTP::Tiny's author to flip the default (esp. if the patches for the 
failing tests are applied upstream) -- it is 5 years later after all, 
and https is everywhere.


-- Damyan