Bug#1063866: ddcci-dkms: failed to compile DKMS module for linux 6.5.0

[Jeff Becker (probably not evil)]

Package: ddcci-dkms
Version: 0.4.2-4
Severity: important

Dear Maintainer,

after trying to install package via apt it reports that the DKMS module could
not be compilled, giving the following output:

root@desu:~# apt install ddcci-dkms
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
ddcci-dkms
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/21.7 kB of archives.
After this operation, 95.2 kB of additional disk space will be used.
Selecting previously unselected package ddcci-dkms.
(Reading database ... 1401185 files and directories currently installed.)
Preparing to unpack .../ddcci-dkms_0.4.2-4_all.deb ...
Unpacking ddcci-dkms (0.4.2-4) ...
Setting up ddcci-dkms (0.4.2-4) ...
Loading new ddcci-0.4.2 DKMS files...
Building for 6.5.0-0.deb12.4-amd64
Building initial module for 6.5.0-0.deb12.4-amd64
Error! Bad return status for module build on kernel: 6.5.0-0.deb12.4-amd64
(x86_64)
Consult /var/lib/dkms/ddcci/0.4.2/build/make.log for more information.
dpkg: error processing package ddcci-dkms (--configure):
installed ddcci-dkms package post-installation script subprocess returned error
exit status 10
Errors were encountered while processing:
ddcci-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)


contents of make.log is include as an attached file.


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ddcci-dkms depends on:
ii  dkms  3.0.10-8+deb12u1

ddcci-dkms recommends no packages.

ddcci-dkms suggests no packages.

-- no debconf information
DKMS make.log for ddcci-0.4.2 for kernel 6.5.0-0.deb12.4-amd64 (x86_64)
Tue Feb 13 14:32:20 EST 2024
make: Entering directory '/var/lib/dkms/ddcci/0.4.2/build'
make -C "ddcci"
make[1]: Entering directory '/var/lib/dkms/ddcci/0.4.2/build/ddcci'
make -C "/lib/modules/6.5.0-0.deb12.4-amd64/build" 
M="/var/lib/dkms/ddcci/0.4.2/build/ddcci" modules
make[2]: Entering directory '/usr/src/linux-headers-6.5.0-0.deb12.4-amd64'
  CC [M]  /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.o
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:42:34: error: macro 
"DEFINE_SEMAPHORE" requires 2 arguments, but only 1 given
   42 | static DEFINE_SEMAPHORE(core_lock);
  |  ^
In file included from 
/usr/src/linux-headers-6.5.0-0.deb12.4-common/include/linux/fs.h:25,
 from /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:19:
/usr/src/linux-headers-6.5.0-0.deb12.4-common/include/linux/semaphore.h:34: 
note: macro "DEFINE_SEMAPHORE" defined here
   34 | #define DEFINE_SEMAPHORE(_name, _n) \
  | 
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:42:8: error: type defaults to 
‘int’ in declaration of ‘DEFINE_SEMAPHORE’ [-Werror=implicit-int]
   42 | static DEFINE_SEMAPHORE(core_lock);
  |^~~~
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c: In function 
‘ddcci_device_release’:
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1002:23: error: ‘core_lock’ 
undeclared (first use in this function); did you mean ‘file_lock’?
 1002 | down(_lock);
  |   ^
  |   file_lock
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1002:23: note: each undeclared 
identifier is reported only once for each function it appears in
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c: At top level:
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1053:27: error: initialization of 
‘int (*)(const struct device *, struct kobj_uevent_env *)’ from incompatible 
pointer type ‘int (*)(struct device *, struct kobj_uevent_env *)’ 
[-Werror=incompatible-pointer-types]
 1053 | .uevent = ddcci_device_uevent,
  |   ^~~
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1053:27: note: (near 
initialization for ‘ddcci_device_type.uevent’)
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1056:27: error: initialization of 
‘char * (*)(const struct device *, umode_t *, kuid_t *, kgid_t *)’ {aka ‘char * 
(*)(const struct device *, short unsigned int *, kuid_t *, kgid_t *)’} from 
incompatible pointer type ‘char * (*)(struct device *, umode_t *, kuid_t *, 
kgid_t *)’ {aka ‘char * (*)(struct device *, short unsigned int *, kuid_t *, 
kgid_t *)’} [-Werror=incompatible-pointer-types]
 1056 | .devnode= ddcci_devnode
  |   ^
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1056:27: note: (near 
initialization for ‘ddcci_device_type.devnode’)

Bug#1025664: closed by Phil Wyett (reply to philip.wy...@kathenas.org) (rednotebook: Paste ’ with ' highlighted inserts at incorrect position)

[Jeff]

reopen 1025664
thanks

I can still reproduce this in v2.31 in testing.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055567: Error: gscan2pdf fails to compile

[Jeff]

On 20/11/2023 17:51, Soumyanath Chatterjee wrote:
soumyanath@ganak-desktop:~$ LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ 
gscan2pdf


This one works.

Please suggest what changes I need to make to run it normally


For me, this isn't a problem with gscan2pdf, but with the way that 
libsane was compiled (or better, linked) against libusb.


i.e. the problem can only be fixed by a new version of libsane.

As you are using Ubuntu, I suggest you raise a bug against the libsane 
package:


https://packages.ubuntu.com/search?keywords=libsane


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055567: Error: gscan2pdf fails to compile

[Jeff]

What about:

sudo ldconfig

cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf

If you start gscan2pdf as follows:

LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ gscan2pdf

?

Can you start xsane, simple-scan or scanimage ?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055567: Error: gscan2pdf fails to compile

[Jeff]

It looks like the version of libusb libsane was built against is not the 
same as the one you are running with.


There are some similarities here: 
https://askubuntu.com/questions/1264001/error-installing-xsane-sane-hplip-etc-with-undefined-symbol-libusb-set-optio


What does the following return?

apt-cache policy libsane1 libsane-common libimage-sane-perl libusb-1.0


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055567: Error: gscan2pdf fails to compile

[Jeff]

Please reinstall the packages:

sudo apt reinstall libsane1 libimage-sane-perl

and try to start gscan2pdf again.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055567: Error: gscan2pdf fails to compile

[jeff]

On 15/11/2023 12:19, Soumyanath Chatterjee wrote:

I find line 8 is commented out


I take it, therefore, that you didn't comment out the line yourself 
sometime in the past?


How did you install gscan2pdf?


ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1
lrwxrwxrwx 1 root root 17 Sep 17  2020 
/usr/lib/x86_64-linux-gnu/libsane.so.1-> libsane.so.1.0.29


What about

ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1.0.29

?

Bug#1055567: Error: gscan2pdf fails to compile

[Jeff]

On 13/11/2023 16:24, Soumyanath Chatterjee wrote:

  DB<1> use Image::Sane ':all';
Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so' for 
module Image::Sane: /usr/lib/x86_64-linux-gnu/libsane.so.1: undefined 
symbol: l

ibusb_set_option at /usr/share/perl/5.30/XSLoader.pm line 93.
at /usr/lib/x86_64-linux-gnu/perl5/5.30/Image/Sane.pm line 144.


If that failed, my first question is why you didn't see the same failure 
from the same line in /usr/share/perl5/Gscan2pdf/Scanner/Options.pm ? 
What do you see in line 8 of that file?


What do you get from

ldd /usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so

ls -l /usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so

ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1

?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055567: Error: gscan2pdf fails to compile

[Jeff]

Please start an interactive Perl session with:

perl -d -e 1

Then execute the following:

use Image::Sane ':all';
print SANE_NAME_PAGE_HEIGHT, "\n";

and report the response.

Afterwards, you can quit with q



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055567: Error: gscan2pdf fails to compile

[Jeff]

Please start gscan2pdf from the command line with the --log option:

gscan2pdf --log=log

then quit, and post the log file, which gscan2pdf should have compressed 
with xz.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055567: Error: gscan2pdf fails to compile

[Jeff]

How are you starting gscan2pdf?

What does the following return?

apt list libimage-sane-perl

Regards

Jeff


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1034465: reportbug: dhcpcd -U results in "Bad system call"

[Jeff Kletsky]

On 4/15/23 11:11 PM, Martin-Éric Racine wrote:


[...]
Noted.

In principle, I have version 10 ready to upload. However, given the
Bookworm freeze, the best I could do is push it to experimental.


Thanks for your time and efforts on this.

I did not realize that Bookworm's development cycle had progressed that far.

With the package functional for its primary use and a work-around 
available, that seems like a very reasonable course of action.

Bug#1034465: reportbug: dhcpcd -U results in "Bad system call"

[Jeff Kletsky]

Package: dhcpcd
Version: 9.4.1-21
Severity: important
Tags: newcomer upstream
X-Debbugs-Cc: debian-b...@allycomm.com

Dear Maintainer,

TL;DR -- Apparently fixed upstream in dhcpcd-9.5.0 or later (-10.0.0 available)

   * What led up to the situation?

Installed later version of nftables from "testing" which brought in a newer 
version of libc

While dhcpcd5/dhcpcd runs and obtains leases, the -U / --dumplease function 
fails with either
"Bad system call" or, if running under sudo, with "dhcpcd_readdumptimeout"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Trying the versions of dhcpcd from testing and unstable did not resolve the 
issue.

Building locally from deb source (either stable or testing/unstable) 
against the newer version of libc did not resolve the issue.

The issue appears to be impacting other systems that have later versions of libc
than does Debian Bullseye. Searching the upstream dhcpcd archive revealed



was reported by a user on Arch Linux, dhcpcd version 9.4.1 and  glibc version 
2.36

rsmarples indicates "Fixed in dhcpcd-9.5.0"

His comment appears to be roughly coincident with the release of dhcpcd-10.0.0

   * What was the outcome of this action?
   * What outcome did you expect instead?

At the present time, there is not a straightforward way for me to dump the 
DHCPv6
lease information.  The dhcpcd -U command's output is used for scripts to adjust
firewall settings on an as-needed basis.  Regrettably, Comcast's reliability
is not very good and IPv6 allocations change with every outage during the winter
storms and occasionally for no apparent reason.  I can work around this locally.

I did try to rebase https://salsa.debian.org/debian/dhcpcd5 onto the upstream 
dhcpcd-10.0.0 tag but found that I did not have enough knowldge of the code
to resolve the merge conflicts.

Building form upstream source at dhcpcd-10.0.0, without the Debian patches

  ./configure --prefix=/opt
  make
  sudo make install

and replacing the running version with the local build restores the -U 
functionality.

Just using the 10.0.0 build with the running 9.4.1 version was not sucessful, 
returning
"dhcpcd is not running" (though it was). This was not further pursued.

I have not tried building 9.5


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable'), (90, 'testing'), (80, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages dhcpcd depends on:
ii  dhcpcd-base 9.4.1-21
ii  lsb-base11.1.0
ii  sysvinit-utils  2.96-7+deb11u1

dhcpcd recommends no packages.

Versions of packages dhcpcd suggests:
pn  dhcpcd-gtk  

-- no debconf information

Bug#1030982: gscan2pdf: Segmentation fault

[jeff]

severity 1030982 normal
thanks

Reducing the severity down to normal until the problem can be reproduced 
and debugged.

Bug#1030982: gscan2pdf: Not a JPEG file: starts with 0x00 0x00 (was: Segmentation fault)

[Jeff]

On 11/02/2023 15:50, Janusz S. Bień wrote:

The failure log was
[log1 (application/octet-stream, attachment)]


That file ends with:

DEBUG - signal 'started-process' emitted with message: Scanning page 1 of 1
INFO - gscan2pdf: scanning image of size 1275x1784 pixels at 24 bits/pixel
INFO - gscan2pdf: acquiring RGB frame

So you are saying that in the terminal, you then additionally received 
the message:


Not a JPEG file: starts with 0x00 0x00

and then it segfaulted?

And that now you can't reproduce the problem?

What happens if you try the following from the command line:

scanimage --device="xerox_mfp:tcp  192.168.0.155" --batch

?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030982: gscan2pdf: Segmentation fault

[Jeff]

I still don't understand. The log you provided covered a successful 
scan, with a couple of post-processing steps.


Please provide a log where the scan job failed.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030982: gscan2pdf: Segmentation fault

[Jeff]

In the log you provide, you seem to have a successful scan. Is the 
problem therefore only the warning message?


If the other device does not work, please provide a log file created 
when scanning with the other device.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030982: gscan2pdf: Segmentation fault

[Jeff]

There's no segfault there.

Please start gscan2pdf from the command line with the --log=log
option, if necessary, hit OK to select the crashed session, reproduce 
the problem (i.e. the segfaul), quit, and post the log file, which

gscan2pdf may have compressed with xz.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030982: gscan2pdf: Segmentation fault

[Jeff]

Please start gscan2pdf from the command line with the --log=log option, 
reproduce the problem, quit, and post the log file, which gscan2pdf may 
have compressed with xz.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Jeff King]

On Tue, Jan 24, 2023 at 02:32:07PM +0100, Santiago Ruano Rincón wrote:

> > Tests yesterday seem to indicate successful results, but again I've only
> > tested a few combinations in a VM (to keep the feedback loop short).
> > 
> > From the installer team point of view, I'd welcome a swift upload with
> > this patch, possibly with urgency=high so that the fix reaches testing
> > soon. This will another blocker out of the way for the next D-I release!
> 
> Just uploaded with your patched patch.

Thanks, I just booted with 0.8.41, and the result looks good to me!

-Peff

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Jeff King]

On Mon, Jan 23, 2023 at 03:55:50PM +0100, Santiago Ruano Rincón wrote:

> > That seems needlessly convoluted. What about this:
> > 
> > [Service]
> > Type=oneshot
> > EnvironmentFile=-/etc/default/networking
> > ExecStart=/sbin/ifup -a --read-environment
> > ExecStart=-/sbin/ifup -a --read-environment --allow=hotplug
> > ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
> > RemainAfterExit=true
> > TimeoutStartSec=5min
> > 
> > "start" and "restart" configure all existing "auto" and "allow-hotplug"
> > interfaces.
> > Missing "allow-hotplug" interfaces do not be marked as configured (so that
> > they can be configured by udev) and do not make "start" or "restart" fail.
> 
> Thanks everybody for the inputs. I've applied Paul's solution, and the
> generated .deb can be downloaded from here:
> 
> https://salsa.debian.org/debian/ifupdown/-/jobs/3841392/artifacts/raw/debian/output/ifupdown_0.8.41~1.gbp3a6fae+salsaci+20230123+42_amd64.deb
> 
> Would it be possible for you (Oleg, Paul, Jeff, kibi et al.) to give it
> a try?

I tried it, and it still results in a 10-second pause during startup
while broadcasting dhcp over eth0. Which is not too surprising. You
can't get around that if you run "ifup --allow=hotplug", and it's
reasonable for systemd to wait for the process to finish, even if the
exit code doesn't affect success.

That may be an acceptable casualty for fixing the other problems, but I
suspect it's something that many laptop users will encounter (they have
wifi that is normally used and an ethernet port that is not; d-i sets
only the wifi as "auto").

I didn't test it, but I believe Cyril's approach to avoid trying to
bring up hotplug interfaces at all (unless during restart) would fix
that.

-Peff

Bug#1022843: ifupdown: network down after systemctl restart

[Jeff King]

On Sat, Oct 29, 2022 at 10:33:26AM +, Oleg A. Arkhangelsky wrote:

> Since the unit type is oneshot, we can have multiple ExecStart statements.
> 
> Note that we have to use '--ignore-errors'. Otherwise if we have real
> hotplug interface that is not present at the moment of restart, `ifup`
> returns non-zero and systemd unit fail.
> 
> 
> diff --git a/debian/networking.service b/debian/networking.service
> index 593172b..7ad246b 100644
> --- a/debian/networking.service
> +++ b/debian/networking.service
> @@ -16,6 +16,7 @@ WantedBy=network-online.target
>  Type=oneshot
>  EnvironmentFile=-/etc/default/networking
>  ExecStart=/sbin/ifup -a --read-environment
> +ExecStart=/sbin/ifup -a --allow=hotplug --ignore-errors --read-environment

This has the minor downside that on system startup, we'll spend time
trying to bring up allow-hotplug interfaces, even if they're not
available. So on my system, for example, with:

  allow-hotplug eth0
  iface eth0 inet dhcp

  auto wlan0
  iface wlan0 inet manual
  wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

this introduces a 10-second lag to the boot process as the dhcp client
broadcasts over eth0, which has no cable plugged in (it's udhcpc in my
case, but I imagine it would be the same for any client).

It's definitely less bad than the problem you were fixing. But it makes
me wonder if the solution here is neglecting the reason that these
interfaces are marked allow-hotplug and not "auto" in the first place.

-Peff

Bug#1027689: Success

[Jeff Sacksteder]

The patch resolves the issue with no other apparent side effects.

This is my primary daily-use desktop system.

Bug#1027689: Akregator Update

[Jeff Sacksteder]

Package: Akregator
Version: 4:20.08.3-1

As of 11.6, Stable continues to include Akregator 4:20.08.3-1, which
includes this bug:

https://bugs.kde.org/show_bug.cgi?id=429444
https://invent.kde.org/pim/akregator/-/commit/546db72108cba99a1881e97349ce55db5d1da88e

Testing includes 4:22.08.3-1 and presumably fixes this. Can it be added to
Stable?

Bug#1026879: (gnucash: Date format does not respect preferences)

[Jeff]

Indeed. I've just build a deb for 4.13 and the problem is solved.

Would you mind uploading 4.13?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026879: Acknowledgement (gnucash: Date format does not respect preferences)

[Jeff]

It looks like this has been fixed in 4.13:

https://lists.gnucash.org/pipermail/gnucash-user/2022-December/104391.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026205: Unpaper errors for every scanned page

[Jeff]

On 19/12/2022 13:59, martin f krafft wrote:

Regarding the following, written by "Jeff" on 2022-12-19 at 09:26 Uhr +:

Yup. This patch fixes things:

I just tried with the patch applied, and I still get

[image2 @ 0x5609ccef9e40] The specified filename
'/home/ssd/madduck/.tmp/gscan2pdf-uiWw/eLwbJ_5EFR.pnm' does not
contain an image sequence pattern or a pattern is invalid.

for every page, even after clicking to "Hide all these messages"


Looks like temporary files can have underscores as well. Please try this 
instead (word instead of alnum).


diff --git a/lib/Gscan2pdf/Dialog/MultipleMessage.pm 
b/lib/Gscan2pdf/Dialog/MultipleMessage.pm

index f74779b1..8a48abaf 100644
--- a/lib/Gscan2pdf/Dialog/MultipleMessage.pm
+++ b/lib/Gscan2pdf/Dialog/MultipleMessage.pm
@@ -23,6 +23,10 @@ my $INTREGEX = qr{^(.*)   # start of message
   \b[[:digit:]]+\b # integer
   (.*)$   # rest of message
  }xsm;
+my $TEMPFILEREGEX = qr{^(.*)   # start of message
+  gscan2pdf[-][[:alnum:]]+/[[:word:]]+ # temp filename
+  (.*)$   # rest of message
+ }xsm;

 sub INIT_INSTANCE {
 my $self = shift;
@@ -266,6 +270,9 @@ sub munge_message {
 sub filter_message {
 my ($message) = @_;
 $message =~ s/\s+$//xsm;
+while ( $message =~ /$TEMPFILEREGEX/xsmo ) {
+$message =~ s/$TEMPFILEREGEX/$1%%t$2/xsmo;
+}
 while ( $message =~ /$HEXREGEX/xsmo ) {
 $message =~ s/$HEXREGEX/$1%%x$2/xsmo;
 }



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026205: Unpaper errors for every scanned page

[Jeff]

On 17/12/2022 10:00, martin f krafft wrote:

Regarding the following, written by "Jeff" on 2022-12-16 at 16:44 Uhr +:

I think that this is this bug in unpaper:

https://github.com/unpaper/unpaper/issues/113
<https://github.com/unpaper/unpaper/issues/113>

Okay, but gscan2pdf makes it an error, and I do wonder if it's possible 
to hide them…


Yup. This patch fixes things:

diff --git a/lib/Gscan2pdf/Dialog/MultipleMessage.pm 
b/lib/Gscan2pdf/Dialog/MultipleMessage.pm

index f74779b1..862c7c50 100644
--- a/lib/Gscan2pdf/Dialog/MultipleMessage.pm
+++ b/lib/Gscan2pdf/Dialog/MultipleMessage.pm
@@ -23,6 +23,10 @@ my $INTREGEX = qr{^(.*)   # start of message
   \b[[:digit:]]+\b # integer
   (.*)$   # rest of message
  }xsm;
+my $TEMPFILEREGEX = qr{^(.*)   # start of message
+  gscan2pdf[-][[:alnum:]]+/[[:alnum:]]+ # temp filename
+  (.*)$   # rest of message
+ }xsm;

 sub INIT_INSTANCE {
 my $self = shift;
@@ -266,6 +270,9 @@ sub munge_message {
 sub filter_message {
 my ($message) = @_;
 $message =~ s/\s+$//xsm;
+while ( $message =~ /$TEMPFILEREGEX/xsmo ) {
+$message =~ s/$TEMPFILEREGEX/$1%%t$2/xsmo;
+}
 while ( $message =~ /$HEXREGEX/xsmo ) {
 $message =~ s/$HEXREGEX/$1%%x$2/xsmo;
 }

It will be in the next release.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026205: Unpaper errors for every scanned page

[Jeff]

Thanks for the report.

On 16/12/2022 11:05, martin f krafft wrote:

for every page processed by unpaper, I get two errors:

 1. [image2 @ 0x558772ceee40] The specified filename
'/home/ssd/madduck/.tmp/gscan2pdf-SMFz/OHSkXwKy5v.pnm' does not
contain an image sequence pattern or a pattern is invalid.
 2. [image2 @ 0x558772ceee40] Use a pattern such as %03d for an image
sequence or use the -update option (with -frames:v 1 if needed) to
write a single image.


I think that this is this bug in unpaper:

https://github.com/unpaper/unpaper/issues/113



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023659: gscan2pdf: can't use unpaper as it gives errors

[Jeff]

reassign 1023659 unpaper 7.0.0-0.1
thanks


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023659: gscan2pdf: can't use unpaper as it gives errors

[Jeff]

On 08/11/2022 15:06, Francesco Potortì wrote:

If I enable the "Postprocessing / Clean up images" option with default values, 
I get errors from unpaper.  Here they are:

[image2 @ 0x564ee7da3540] Encoder did not produce proper pts, making some up.
[image2 @ 0x564ee7da3540] The specified filename 
'/tmp/gscan2pdf-EBri/SGOfFcr2Nn.pnm' does not contain an image sequence pattern 
or a pattern is invalid.
[image2 @ 0x564ee7da3540] Use a pattern such as %03d for an image sequence or 
use the -update option (with -frames:v 1 if needed) to write a single image.

The file mentioned in the second of the three error messages does not exist.


I think that these are warnings, not errors, as I get output from 
unpaper despite them.


Because of errors/warnings like this, the message window that displays 
them gives you the possibility to hide them in the future. This works 
for the first and third messages, but not the second (because the 
filename changes every time).


I could take a look at the logic that parses the messages and see if I 
improve it.


However, I'm not sure there is any point, as I see this bug report:

https://github.com/unpaper/unpaper/issues/113

which is fixed by this commit:

https://github.com/unpaper/unpaper/commit/a2a88fe837fd6770ac94f08b2eb841f0dc9d2430

So I am tempted to reassign this to unpaper.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022864: gscan2pdf: unnecessary test dependency on autopkgtest?

[Jeff]

gscan2pdf doesn't depend on autopkgtest directly. It has:

Testsuite: autopkgtest-pkg-perl

in the control file. Is that somehow incorrect?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022749: python3.10: python 3.10 incompatible with setuptools>=60.0.0

[Jeff Epler]

Package: python3.10
Severity: normal
X-Debbugs-Cc: jep...@gmail.com

Dear Maintainer,

Hi!

Apologies to bringing this to your attention as a bystander, but I've become
aware
of an incompatibility between setuptools >= 60.0.0 and debian's python package.

I'm not actually using an affected version of Debian, but this has repeatedly
affected people "on the internet" as well as people I've helped as part of my
work with Adafruit.

Some people responding on github about the issue have pointed a virtual finger
at Debian, but as far as I can tell they have not filed a debian bug so the
Debian maintainers may not be aware of the issue.

Here's how the bug can be reproduced in Debian. I ran these lines in a
throwaway environment with `docker run -it debian:testing`:

apt-get -qq update && apt-get -qq install python3 python3-pip; pip install -U
virtualenv setuptools; virtualenv venv; ls -l venv/bin/python

This fails, because files were created under venv/local/bin instead.

Here's the "best" github issue about the problem that I've encountered,
including a project member's statement about their view of how Debian could
resolve the problem:
https://github.com/pypa/setuptools/issues/3278#issuecomment-1118317549



[note: the below information pertains to my development machine, I produced
the problem above in the `debian:testing` docker image:

```
REPOSITORY   TAG   IMAGE ID   CREATED SIZE
debian   testing   500fdde3aee4   About an hour ago   118MB
```

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3.10 depends on:
ii  libc62.31-13+deb11u4
ii  libgcc-s110.2.1-6
ii  libpython3.9 3.9.2-1
pn  libqgis-core3.10.14  
ii  libqt5core5a 5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6

python3.10 recommends no packages.

Bug#1012250: gscan2pdf: flaky autopkgtest: regularly times out

[Jeff]

This morning, I see that for s390x in testing, there was a timeout and 
failure (both in 380_cancel_user_defined_with_pids), as well as two passes:


https://ci.debian.net/packages/g/gscan2pdf/testing/s390x/

armel had a failure that was unrelated to gscan2pdf:

https://ci.debian.net/data/autopkgtest/testing/armel/g/gscan2pdf/26567445/log.gz

I also see that all the other architectures have passes, but this is not 
reflected by the summary page:


https://ci.debian.net/packages/g/gscan2pdf/

Any idea why?

Given that gscan2pdf is a desktop app, I assume there are no users on 
s390x. Hence, I'm not sure of the value of debugging on s390x. According to:


https://www.debian.org/doc/debian-policy/ch-source.html

DEB_HOST_ARCH and DEB_TARGET_ARCH should be set. I'm tempted to test for 
s390x in the test target in debian/rules and skip accordingly. Objections?


Given that the packages in stable are, well, stable, and I made no 
changes to those parts of gscan2pdf, I wonder what happened in the rest 
of the environment between stable and testing. I'd be interested to 
confirm this by pushing the stable version of gscan2pdf through testing 
s390x a couple of times.


Regards

Jeff


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012250: Fixing CI bugs for a package on the REJECT list

[Jeff]

Hi Paul,

On 01/10/2022 11:06, Paul Gevers wrote:
I have triggered several runs (about 15 or so) and they all passed. I 
have removed the block and am lowering the severity of this bug for now.


What bothers me about this is that these flaky tests do not occur with 
the buildd hosts:


Well, the failure didn't happen that often, so maybe it just didn't 
happen on the buildd. Also, maybe it's something relatively new (and you 
only had X chances on the buildds).


We'll keep monitoring.


Thanks for this. I'll keep looking at the CI builds and will try to 
diagnose the timeouts when they happen.


Regards

Jeff


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012250: Fixing CI bugs for a package on the REJECT list

[Jeff]

Hi Paul,

On 26/09/2022 19:46, Paul Gevers wrote:

The bug has a user specified for the usertag and explicitly mentions:
"""
Don't hesitate to reach out if you need help [...]
"""

So, either using debian...@lists.debian.org or the submitter's address 
(mine) seems appropriate.


In which case, I evidently misunderstood. I had assumed that replying to 
the bug mail would do the same.



In this case:
we can trigger the test from the backside, such that you can get a fresh 
log, but I prefer to only do that coordinated and after you give it a 
try to enable more diagnostic logging, because apparently in the 
original logs there wasn't enough information for you.


I also offer to run the test (once or twice) manually and get 
information out of the testbed, if you tell me the exact commands you 
want me to run in the testbed.


Please trigger a new run. I can't add more diagnostics until I know where.

What bothers me about this is that these flaky tests do not occur with 
the buildd hosts:


https://buildd.debian.org/status/logs.php?pkg=gscan2pdf=all

The only failure took 7 minutes, not 27 hours.

So how do the CI hosts diff from the buildd ones?

Thanks for your help.

Regards

Jeff


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020458: gscan2pdf: Test t351_unpaper fails two tests with unpaper 7.0.0

[Jeff]

Thanks for the report.

This has been fixed upstream (but not yet in a release):

https://sourceforge.net/p/gscan2pdf/bugs/404/

https://sourceforge.net/p/gscan2pdf/code/ci/608c52b8f1ccb31c8572c8c5b62ae31f67196092/

I'll get a new release out ASAP.

Regards

Jeff


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012250: gscan2pdf: flaky autopkgtest: regularly times out

[Jeff]

This is proving hard to nail down.

The examples you give all time-out on different tests.

I've never had a timeout problem whilst testing interactively or in a 
local schroot.


I see the status on the runs that time out is always "tmpfail". What 
does tmpfail mean? How is the status determined?


The timeouts seem rare and even then something that has only recently 
started. Changes to gscan2pdf in the last year have only been cosmetic, 
and I wonder therefore if a dependency is causing this.


I see error messages such as:

AT-SPI: Error retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not 
provided by any .service files


Which according to

https://gist.github.com/jeffcogswell/62395900725acef1c0a5a608f7eb7a05

Might be fixed with

  sudo apt install at-spi2-core

On the other hand, this seems very hacky, as these really shouldn't have 
anything to do with gscan2pdf - maybe a dependency, e.g. gtk+.


But these also occur in runs which pass, such as:

https://ci.debian.net/data/autopkgtest/stable/amd64/g/gscan2pdf/23364484/log.gz

I'd be grateful for any suggestions

Regards

Jeff


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012789: Can you check if Img works at all?

[Jeff Epler]

Thanks for tryting LinuxCNC on aarch64. I don't know of anyone presently
using such a configuration.

As far as the "undefined symbol" message:

Please check whether in "wish", it works to "package require Img" or
whether the same error occurs. If it's the same error then may point to a
general problem between libtk-img and libtiff.

As far as the "LIBGL: Error while gathering supported extension
(eglInitialize: EGL_BAD_DISPLAY), default to none" message:

Most UIs for LinuxCNC require working OpenGL. You can try a different UI
such as tklinuxcnc, it doesn't use OpenGL and probably also doesn't use
Img. However, it's much less friendly (IMO)

Jeff

Bug#1010051: ghostscript: crash converting PDF to PNG

[Jeff]

Control: tags unblock -1 by 1007752
Control: notforwarded -1
Control: tags block 1009448 by -1


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010051: ghostscript: crash converting PDF to PNG

[Jeff]

Control: tags -1 - bookworm confirmed fixed-upstream ftbfs
thanks


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009448: libpdf-builder-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2

[Jeff]

In test 13, libpdf-builder-perl produces the attached PDF, which neither 
Firefox nor Evince complains about, and prior to v9.56.0, ghostscript 
accepted happily.


With v9.56.1:

$ gs -q -dNOPAUSE -dBATCH -sDEVICE=pnggray -g20x20 -dPDFFitPage 
-dUseCropBox -sOutputFile=out.png out.pdf

Error: /typecheck in --runpdf--
Operand stack:
   --dict:6/14(L)--   --dict:6/14(L)--   --dict:6/14(L)--   MediaBox 
--nostringval--   20.0   20.0   20.0   20.0   false   20.0   2

Execution stack:
   %interp_exit   .runexec2   --nostringval--   runpdf 
--nostringval--   2   %stopped_push   --nostringval--   runpdf   runpdf 
  false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1 
3   %oparray_pop   1977   1   3   %oparray_pop   1978   1   3 
%oparray_pop   runpdf   runpdf   2   1   1   runpdf 
%for_pos_int_continue   runpdf   runpdf   runpdf

Dictionary stack:
   --dict:765/1123(ro)(G)--   --dict:0/20(G)--   --dict:76/200(L)-- 
--dict:18/20(L)--

Current allocation mode is local
Last OS error: No such file or directory
GPL Ghostscript 9.56.1: Unrecoverable error, exit code 1
free(): double free detected in tcache 2

As ghostscript is only used by the tests for comparison purposes, and 
this does not affect the output of libpdf-builder-perl, I propose that 
we forward this to ghostscript and skip these two tests until we have a fix.


out.pdf
Description: Adobe PDF document


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009448: libpdf-builder-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2

[Jeff]

forwarded 1009448 
https://github.com/PhilterPaper/Perl-PDF-Builder/issues/184

thanks


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009448: libpdf-builder-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2

[Jeff]

To confirm - I've just put the 3 packages for gs 9.56.1 (and nothing 
else) from sid on my testing machine, and now I see the same failures.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009448: libpdf-builder-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2

[Jeff]

My machine running testing currently has ghostscript 9.55.0, and there 
it still builds fine. So I'm guessing the problem is between 9.55.0 and 
9.56.0.


Indeed since the failure with 9.56.0, 9.56.1 has been uploaded.

I've just tried building it with 9.56.1 but it still has the same two 
failures.


I'll do some debugging.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009448: libpdf-builder-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2

[Jeff]

Going through what changed between the previous successful build

https://buildd.debian.org/status/fetch.php?pkg=libpdf-builder-perl=all=3.023-1=1631870648=0

and the failure:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libpdf-builder-perl.html

I see the following changes in the dependency versions:

libbrotli1_1.0.9-2+b2 -> b3
libfreetype6_2.10.4+dfsg-1 -> 2.11.1+dfsg-1
fontconfig-config_2.13.1-4.2 -> .4
libfontconfig1_2.13.1-4.2 -> .4
libaom0_1.0.0.errata1-3 -> libaom3_3.3.0-1
libdav1d5_0.9.2-1 -> +b1
libnuma1_2.0.12-1+b1 -> 2.0.14-3
libx265-192_3.4-2 -> -199_3.5-2
libheif1_1.12.0-2+b1 -> b3
libjpeg62-turbo_1%3a2.0.6-4 -> 1%3a2.1.2-1
libglib2.0-0_2.68.4-1 -> 2.72.1-1
libltdl7_2.4.6-15 -> 2.4.7-3
libopenjp2-7_2.4.0-3 -> -6
libdeflate0_1.7-2 -> 1.10-2
libwebp6_0.6.1-2.1 -> libwebp7_1.2.2-2+b1
libtiff5_4.3.0-2 -> -6
libwebpdemux2_0.6.1-2.1 -> 1.2.2-2+b1
libwebpmux3_0.6.1-2.1 -> 1.2.2-2+b1
libmd0_1.0.3-3 -> 1.0.4-1
libbsd0_0.11.3-1 -> 0.11.6-1
libx11-data_2%3a1.7.2-2 -> 2%3a1.7.5-1
libx11-6_2%3a1.7.2-2+b1 -> 2%3a1.7.5-1
libxml2_2.9.12+dfsg-4 -> 2.9.13+dfsg-1
libmagickcore-6.q16-6_8%3a6.9.11.60+dfsg-1.3 -> +b2
libmagickwand-6.q16-6_8%3a6.9.11.60+dfsg-1.3 -> +b2
imagemagick-6.q16_8%3a6.9.11.60+dfsg-1.3 -> +b2
libmagic-mgc_1%3a5.39-3 -> 1%3a5.41-3
libmagic1_1%3a5.39-3 -> 1%3a5.41-3
file_1%3a5.39-3 -> 1%3a5.41-3
autotools-dev_20180224.1+nmu1 -> 20220109.1
automake_1%3a1.16.4-2 -> 1%3a1.16.5-1.3
autopoint_0.21-4 -> -6
libdebhelper-perl_13.5.1 -> 13.7.1
libtool_2.4.6-15 -> 2.4.7-3
libfile-stripnondeterminism-perl_1.12.0-1 -> 1.13.0-1
dh-strip-nondeterminism_1.12.0-1 -> 1.13.0-1
libelf1_0.185-2 -> 0.186-1
gettext_0.21-4 -> -6
debhelper_13.5.1 -> 13.7.1
libgs9-common_9.54.0~dfsg-5 -> 9.56.0~dfsg-1
libgs9_9.54.0~dfsg-5 -> 9.56.0~dfsg-1
ghostscript_9.54.0~dfsg-5 -> 9.56.0~dfsg-1
libdbus-1-3_1.12.20-2 -> 1.14.0-1
libcups2_2.3.3op2-7 -> 2.4.1op1-2
libgd3_2.3.0-2 -> +b1
libgd-perl_2.73-1+b1 -> 2.76-2+b1
libgraphics-tiff-perl_16-1 -> 18-1+b1
libimage-png-libpng-perl_0.57-1 -> -2+b1
libpadwalker-perl_2.5-1+b1 -> b2

The libcms2 version is identical, so I don't think that is the problem.

If I have interpreted the versioning correctly, the imagemagick change 
should be negligible.


However, the ghostscript change is not, and indeed the error messages 
look like they come from ghostscript:


Error: /typecheck in --runpdf--
Operand stack:
   --dict:6/14(L)--   --dict:6/14(L)--   --dict:6/14(L)--   MediaBox 
--nostringval--   20.0   20.0   20.0   20.0   false   20.0   2

Execution stack:
   %interp_exit   .runexec2   --nostringval--   runpdf 
--nostringval--   2   %stopped_push   --nostringval--   runpdf   runpdf 
 false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3 
  %oparray_pop   1977   1   3   %oparray_pop   1978   1   3 
%oparray_pop   runpdf   runpdf   2   1   1   runpdf 
%for_pos_int_continue   runpdf   runpdf   runpdf

Dictionary stack:
   --dict:765/1123(ro)(G)--   --dict:0/20(G)--   --dict:76/200(L)-- 
--dict:18/20(L)--

Current allocation mode is local
Last OS error: No such file or directory


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009257: Option to convert white to transparency

[Jeff]

On 11/04/2022 15:35, martin f krafft wrote:
Then I think a better UI/UX for user-defined tools, and possibly the 
ability to invoke any subset of them automatically during the scan would 
do just fine.


I'm sure the UI/UX could be improved. I'd love to hear any suggestions.

If you look at the post-processing tab of the scan window, you should be 
able to invoke any of the user-defined tools as part of your workflow.


Also, have a look at how Geeqie does user-defined actions, using 
|.desktop| entries. Not the nicest, but it's a standard, and means it 
can easily be brought into the menus.


Having units like |.desktop| files also means we could start a |contrib| 
collection for gscan2pdf, rather than providing them all off the shelf 
for everyone.


I'd not seen Geeqie before. Thanks for the heads-up.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009257: Option to convert white to transparency

[Jeff]

On 10/04/2022 20:36, martin f krafft wrote:

Regarding the following, written by "Jeff" on 2022-04-10 at 12:52 Uhr +:

Can't this be achieved with a user defined tool?

Sure thing, for instance:

|convert -size 2480x3508 -depth 300x300 -transparent white in.pdf out.pdf |

I see four problems with this though:

 1.

This operation would be a lot faster on the PNM files, rather than
first writing the PDF, and then basically accessing the PDF bitmaps
page-wise for this operation;


The user-defined tools operate on the source images, not the resulting 
PDF. I think you might be mixing them up with the post-save hook, which 
does operate on the PDF.



 3.

A user-defined tool does not have access to the resolution to be
used, unlike gscan2pdf. I can calculate the dimensions, but only if
I have the resolution;


The user-defined tools currently offer 3 variables, %i for input 
filename, %o for output filename, and %r for resolution.


I understand your point, but the argument can be made about all of the 
post-processing tools built-in, and the question becomes which one of 
those are so commonly used that they should be built-in. I never use 
unsharp mask, negation, brigthness/contrast, or even OCR, but they are 
built-in.


Absolutely. I was not suggesting it shouldn't be added, only provide a 
workaround until I found time to do so.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009257: Option to convert white to transparency

[Jeff]

Can't this be achieved with a user defined tool?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008724: gscan2pdf: date out of range after changing date before saving

[Jeff]

On 31/03/2022 11:20, bwak...@gmail.com wrote:

gscan2pdf crashes after changing the date to to 1934-1-1 or 1934-01-01
just before saving to pdf

Date::Calc::Date_to_Time(): date out of range at
/usr/bin/site_perl/gscan2pdf line 2817


Good catch. Most file systems don't support file dates before 1970. I 
thought I had put in test cases for all code like this, but this one 
obviously got away.


Thanks for the report. Fixed in the next release.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006009: fixed in libwebp 1.2.2-1

[Jeff Breidenbach]

Yes, I made a mistake with respect to 1.2.2. Upstream's official patch is
here. I am going to attempt a high urgency upload during the next houw with
1.2.2 + this patch. If that fails for any reason, NMU welcome without
delay.

https://chromium.googlesource.com/webm/libwebp/+/4f1839957115fa4713ed745ceb898657361a1195

>

Bug#1003548: transition: libwebp

[Jeff Breidenbach]

libwebp 1.2.1-7 has been successfully uploaded to unstable.

Anthony and Iustin, help is very strongly appreciated for the NMUs.

Bug#1003548: transition: libwebp

[Jeff Breidenbach]

# remove the moreinfo tag
tags 1003548 - moreinfo
thanks

Sebastian, may we move forward with ibwebp?

Bug#1003548: transition: libwebp

[Jeff Breidenbach]

To make it super clear, here is the updated formal request with updated Ben
file.

===

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

Hello Release Team,

We would like to transition libwebp to a new upstream version 1.2.1-6
that is already uploaded and built in experimental. No build problems
are expected in the reverse dependencies either. This was tested by
rebuilding a subset of packages listed on the transition web page:

https://release.debian.org/transitions/html/auto-libwebp.html

Please let us know if we can proceed with the upload to unstable. Also
a binNMU rebuild of reverse dependencies would be required afterwards.


Ben file:

title = "libwebp";
is_affected = .depends ~ "libwebp6" | .depends ~ "libwebp7";
is_good = .depends ~ "libwebp7";
is_bad = .depends ~ "libwebp6";

Bug#1003548: transition: libwebp

[Jeff Breidenbach]

The package has been corrected with version 1.2.1-6 which has
been uploaded to experimental.

Please let us know if we can proceed with the upload to unstable. Also
a binNMU rebuild of reverse dependencies would be required afterwards.

Bug#1002807: reportbug: Linux Debian AMD64 5.10.84-1: I/O Scheduler DEADLINE w/ Bad I/O Performance After Installation

[jeff]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: important
X-Debbugs-Cc: jeffredbea...@gmail.com

1) I prepared a USB flash drive with the newest net installation image (dd
if=/image.iso of=/dev/drive)
2) I restarted the physical (non-virtualized) computer and installed the
system. I noticed, I have not proof but I think, it took way longer than it
should have even from a USB 2.0 interface. By the way, the drive is a 3.0.
3) The system was near unusable. Any ordinary user would have not been able to
use the system.
4) I noticed the disk cache (using command line utility top) was not utilizing
hardly any memory.
5) I went under /sys/ and found the IO scheduler for the block devices was
DEADLINE. It only showed DEADLINE and NOP.
6) I think it might should have CFQ. I'm not an expert on this area.
7) I tweaked the tunables so writes had a 30 second goal and reads had a 5
second goal. I might have tweaked another parameter or two.
8) The system regained about 80% of the performance I would expect. I still
don't think it is running as well as it could.

Without the fixes the system would be a severe problem for any user to the
point they would not utilize the system.

Thank you for making such a great distribution!!! I have always used Debian. So
sorry for reporting the bug!


-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/kmcguire/.reportbugrc:
reportbug_version "7.10.3+deb11u1"
mode novice
ui gtk
realname "jeff"
email "jeffredbea...@gmail.com"
no-cc
list-cc-me
smtphost reportbug.debian.org

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3+deb11u1
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
pn  debconf-utils 
pn  debsums   
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.39-3
ii  gnupg 2.2.27-2
pn  python3-urwid 
pn  reportbug-gtk 
ii  xdg-utils 1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.2.4
ii  file   1:5.39-3
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information

Bug#1001904: mesaflash: Maintainer address bounces

[Jeff Epler]

Is there a specific sender address that it will suffice to whitelist, or
does the list need to permit mail from any address, regardless of
subscription status?

Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]

[Jeff Blake]

On Wed, 15 Dec 2021 21:08:28 +0100 Stephen Kitt  wrote:
> Hi Jeff,
> 
> On Tue, 14 Dec 2021 09:13:42 +0000, Jeff Blake  wrote:
> [...]
> > Inspector and convertutf are the worst offenders in terms of being
> > unnecessary and complex. The disable/catapult.patch could also be dropped,
> > since profiling might be desirable to some users.
> 
> convertutf at least is required for licensing reasons — it replaces code
> which is stripped from the upstream tarball because it’s not DFSG-free. See
> https://lintian.debian.org/tags/license-problem-convert-utf-code for details.
> 
> Regards,
> 
> Stephen


Hi Stephen,

That's a good point, however upstream Chromium currently requires version 69 of 
icu 
which only exists in Debian Experimental (via icu70). Stable and Unstable both 
have 
icu67 available.

I'm not sure what the solution would be. I suppose patching chromium to work 
with 
icu67, trying to get icu69/70 into unstable (and backporting this to 
stable/dropping 
chromium from stable) or even moving chromium to non-free would be among the 
options.


Best wishes,

Jeff

Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]

[Jeff Blake]

On Tue, 7 Dec 2021 19:43:10 +0100 Tomas Pospisek  wrote:
> On 06.12.21 20:43, Noah Meyerhans wrote:
> > On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote:
>  So what's happening with chromium in both sid and stable? I saw on 
>  d-release that it was removed from testing (#998676 and #998732), with a 
>   discussion about ending security support for it in stable.
> >>>
> >>> The problem really is lack of maintenance. In my opinion, chromium 
> >>> deserves an active *team* to support it in Debian.  <...>  The security 
> >>> team doesn't have the bandwidth to do it themselves, they need a team to 
> >>> help them.
> >>
> >> Sorry for a silly question, but whatʼs so wrong with the build done by 
> >> linuxmint.com [1], so Debian needs a whole team to duplicate their effort? 
> >>  Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in 
> >> my (limited) experience.
> >>
> > 
> > Well, you can start with the fact that the Mint chromium source packages
> > don't even include the chromium source, let alone the sources for all
> > the other things they build (NodeJS, and more).
> > 
> > The biggest difficulty, as far as I can tell from my look at Chromium
> > from several months ago, is that our patch set [1] needs a lot of
> > attention with every chromium release.  Mint doesn't apply any patches
> > at all to the source, at least none of any real complexity.
> > 
> > One lesson we may take from Mint, though, is that it's not worth trying
> > to patch Chromium as much as we'd like.  Anything that we can do to
> > simplify the Chromium packaging will help us keep the package
> > up-to-date, which in turn will help us keep our users safer.  In my
> > opinion, we should be pretty aggressive about dropping as many of the
> > Chromium patches as possible, even if that means we link against
> > bundled/vendored dependencies.
> > 
> > Legal/licensing considerations are still important and I don't know if
> > we actually *can* ship builds based on the bundled stuff.  But based on
> > the number of patches we have to disable various things [2] or build
> > against system dependencies [3], I can't help but think we'd have an
> > easier time keeping this package fresh if we could drop some of those.
> > 
> > noah
> > 
> > 1. 
> > https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series
> > 2. 
> > https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable
> > 3. 
> > https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system
> 
> I'd also like to point out, that the ungoogled-chromium project has some 
> overlap in goals with Debian and it'd possibly be interessing to join 
> forces:
> 
> https://github.com/ungoogled-software/ungoogled-chromium-debian
> 
> (I have been running an ungoogled-chromium for a while (ca. a year 
> ago?), however at that time their chrome wasn't extremely stable so I 
> gave up again. Does anybody have experience using it recently?)
> *t
> 
> 
> 


I have recently forked the debian version of ungoogled chromium [1] [2] [3] to 
(amongst other reasons) re-incorporate many of the previous debian patches and 
features [4].

I haven't had any of the major problems which have blocked the main upstream 
version of it 
over the last couple of release, and the latest chromium version builds and 
runs on both 
unstable and stable.

Most of the debian patches aren't too much bother to update, and are mainly 
context changes. 
Many of them seem worth having, but several are problematic, and if anyone 
wants to make 
maintenance easier then the low hanging fruit to delete for enhanced 
maintainability is as 
follows.


## Plainly not a good idea
debianization/optimization.patch
system/use-desktop-gl-as-default.patch

## Too complex or not worth the trouble to maintain
fixes/inspector.patch
fixes/widevine-revision.patch
system/convertutf.patch

## GCC specific
fixes/gnu-as.patch
warnings/int-in-bool-context.patch
warnings/stringop-overflow.patch

# System lib replacements which are too changeable and/or incompatible between 
stable/unstable
bullseye/ffmpeg.patch
bullseye/icu-types.patch
system/clang-format.patch
system/ffmpeg.patch
system/harfbuzz.patch


Upstream is better placed to judge optimisation levels per build target, and 
all you'll 
achieve with a flat '-O2 everywhere' is a slower binary. With upstream bundled 
clang 
(discussed below) dpkg buildflags doesn't appear to be picked up by the build 
system anyway.

The desktop gl patch is questionable since it can be set as a runtime flag in 
the existing 
debian/etc/default-flags file.

Inspector and convertutf are the worst offenders in terms of being unnecessary 
and complex. 
The disable/catapult.patch could also be dropped, since profiling might be 
desirable to some 
users.

Using gcc to build chromium was dropped by debian ages ago and is not supported 
upstream, so 
I don't see the point in patching gcc-related build 

Bug#995599: libopenmpi3: segfault in mca_btl_vader.so on 32-bit arches

[Jeff Squyres (jsquyres)]

Thanks for the investigation and confirmation!

--
Jeff Squyres
jsquy...@cisco.com<mailto:jsquy...@cisco.com>

Bug#995599: libopenmpi3: segfault in mca_btl_vader.so on 32-bit arches

[Jeff Squyres (jsquyres)]

I'm sorry, I just noticed that you replied 6 days ago, but I apparently wasn't 
notified by the Debian bug tracker.  :-(

Ok, so this is an MPI_Alltoall issue.  Does it use MPI_IN_PLACE?


On Wed, 06 Oct 2021 20:15:38 +0200 Drew Parsons  wrote:
> Source: openmpi
> Followup-For: Bug #995599
> 
> Not so simple to make a minimal test case I think.
> 
> all_to_all is defined in cpp/dolfinx/common/MPI.h in dolfinx source,
> and calls MPI_Alltoall from openmpi.
> 
> It's designed to use with graph::AdjacencyList from
> graph/AdjacencyList.h, and is called from
> compute_nonlocal_dual_graph() in mesh/graphbuild.cpp, where T is set
> to std::int64_t.
> 
> I tried grabbing dolfinx' all_to_all and use it with a pared down
> version of AdjacencyList.  But it's not triggering the segfault on an
> i386 chroot. Possibly because I haven't populated it with an actual
> graph so there's nothing to send with MPI_Alltoall.
> 
> 



-- 
Jeff Squyres
jsquy...@cisco.com

Bug#995599:

[Jeff Squyres (jsquyres)]

Can you provide a small reproducer of the issue?

Bug#914315: libwebp-dev: New versions fix disclosed heap use-after-free

[Jeff Breidenbach]

Maintainer is "less active" but still in good contact with upstream.  I was
going to package the latest version several months ago, but there was a
soname bump and transitions were not allowed due to Debian's release cycle.
Happy to work with anyone on updating webp.

Bug#987059: gscan2pdf: POD and manpage improvements

[Jeff]

Thanks for the patch. Committed upstream. This isn't critical for 
bullseye, so it won't hit unstable until after the release.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#985887: gscan2pdf: saves b scanned pages in inverted mode

[Jeff]

On 13/04/2021 15:29, Francesco Potortì wrote:

Ok, thanks.  Should I send you the log you requested previously,
relative to compression?


Did the new version of PDF::Builder solve the problem?

Did selecting compression=Auto or compression=Flate solve the problem?

If so, then another log file would be great.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985887: gscan2pdf: saves b scanned pages in inverted mode

[Jeff]

tags 985887 patch
thanks


I've cherry-picked enough of this patch to fix this from master at

https://github.com/PhilterPaper/Perl-PDF-Builder/commit/d03b59847ecfbf3c7c31b8c1901d3878dba08040#diff-44803d0b8089ee5eb36d750b5be96b6038d4f32687973371d4c67310afc81ae1

i.e. the author should be Phil Perry, who is also the upstream maintainer.
diff --git a/lib/PDF/Builder/Resource/XObject/Image/TIFF_GT.pm b/lib/PDF/Builder/Resource/XObject/Image/TIFF_GT.pm
index 00fb893..7ac0cf9 100644
--- a/lib/PDF/Builder/Resource/XObject/Image/TIFF_GT.pm
+++ b/lib/PDF/Builder/Resource/XObject/Image/TIFF_GT.pm
@@ -164,6 +164,9 @@ sub handle_generic {
 $dict->{'BitsPerComponent'} = PDFNum($tif->{'bitsPerSample'});
 $dict->{'Colors'} = PDFNum($tif->{'colorSpace'} eq 'DeviceGray'?1 :3);
 
+if (!defined $tif->{'filter'} && $tif->{'bitsPerSample'} == 1) {
+$self->{'Decode'} = PDFArray(PDFNum(1), PDFNum(0));
+}
 $stripcount = $tif->{'object'}->NumberOfStrips();
 $buffer = '';
 for my $i (0 .. $stripcount - 1) {
@@ -586,9 +589,10 @@ sub handle_ccitt {
 $decode->{'K'} = (($tif->{'ccitt'} == 4 || (defined $tif->{'g3Options'} && $tif->{'g3Options'} & 0x1))? PDFNum(-1): PDFNum(0));
 $decode->{'Columns'} = PDFNum($tif->{'imageWidth'});
 $decode->{'Rows'} = PDFNum($tif->{'imageHeight'});
-# not sure why whiteIsZero needs to be flipped around???
-$decode->{'BlackIs1'} = PDFBool($tif->{'whiteIsZero'} == 0? 1: 0);
+$decode->{'BlackIs1'} = PDFBool($tif->{'whiteIsZero'} == 1? 1: 0);
 $decode->{'DamagedRowsBeforeError'} = PDFNum(100);
+# all CCITT Fax need to flip black/white
+$self->{'Decode'} = PDFArray(PDFNum(1), PDFNum(0));
 
 # g3Options   bit 0 = 0 for 1-Dimensional, = 1 for 2-Dimensional MR
 #  aka T4Options  bit 1 = 0 (compressed data only)
@@ -640,12 +644,6 @@ sub handle_ccitt {
 sub read_tiff {
 my ($self, $pdf, $tif, %opts) = @_;
 
-# not sure why blackIsZero needs to be flipped around???
-if (defined $tif->{'blackIsZero'}) {
-$tif->{'blackIsZero'} = $tif->{'blackIsZero'} == 1? 0: 1;
-$tif->{'whiteIsZero'} = $tif->{'blackIsZero'} == 1? 0: 1;
-}
-
 $self->width($tif->{'imageWidth'});
 $self->height($tif->{'imageHeight'});
 


OpenPGP_signature
Description: OpenPGP digital signature

Bug#985887: gscan2pdf: saves b scanned pages in inverted mode

[Jeff]

On 27/03/2021 13:58, Francesco Potortì wrote:

That's because I have written my own compression script using
ghostscript and use it as post-processing tool (which I disabled when
sending the report).  It seems to do a better job at compressing than
almost all tools out there.  I have it at:
http://fly.isti.cnr.it/pub/software/unix/pdfcompress


Nonetheless. I think the bug was triggered by the compression chosen. 
Please try compression=Auto to compression=Flate, which I think should 
work around the problem.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#985887: gscan2pdf: saves b scanned pages in inverted mode

[Jeff]

Thanks for the log file. You seem to have selected compression=none 
(which resulted in a REALLY big PDF). Was that deliberate? Please try 
compression=Auto.


This seems to be a bug in PDF::Builder (libpdf-builder-perl). I'll see 
if I can work up a patch.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#985887: gscan2pdf: saves b scanned pages in inverted mode

[Jeff]

Thanks for the report.

Please start gscan2pdf from the command line:

 gscan2pdf --log=log

reproduce the problem, quit, and post the input image, log file and the 
resulting PDF.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#983677: Further information

[Jeff]

severity 983677 normal
tags 983677 moreinfo
thanks

On 05/03/2021 21:59, Rainer Dorsch wrote:

One thing which is special on my setup, maybe that triggers something on your
side, understanding in detail how gscan2pdf works: I let power management put
my PC to suspend, if I am away. I have the scanner power supply on a
switchable plug, and PC powers off the plug while to goes to suspend and powers
off the scanner. When I restart the PC the scanner is still off and I power it
on manually (by sending a command to the plug).


I imagine that if the PC suspended whilst gscan2pdf was open, then 
gscan2pdf might get confused about what settings were active in the 
backend, but changing anything that caused an option reload should 
correct things.


I assume that your trouble reproducing the problem indicates that it is 
a race condition somewhere.


> I case this does not trigger anything on your side, I suggest to close
> the issue for now and reopen it, as soon as there is new information.

For now, I'll just reduce the severity. Given that you still see the 
problem from time to time, I expect you'll find a way of reproducing it.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#983677: Further information

[Jeff]

I've been looking at this every day and am trouble reproducing this with 
the test backend, or finding something I've changed recently that can 
have caused this.


Do you know when this last worked?

Can you install some older releases (e.g. from the debian archive or 
from sourceforge[1]) and give me an idea when this last worked.


I should also note that gscan2pdf does not distinguish between paper 
sizes that were default and those which were defined by the user, so I 
suspect the problem is caused by changing to a smaller paper size. Can 
you have a play and see if you can confirm this?


If this is problem only started recently, but you can't find a gscan2pdf 
version where it worked in the past, then it might be that a change in 
the backend is triggering a bug that has always been in gscan2pdf.


[1] https://sourceforge.net/projects/gscan2pdf/files/gscan2pdf/



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983043: Acknowledgement (Failed to initialize GENET properly on RPI4 (arm64))

[Jeff Forsyth]

Discovered mdio_bcm_unimac module is missing from the installer
initrd.  This will stop the installer on the RPI4 from connecting to
the network.

On Thu, Feb 18, 2021 at 9:06 AM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 983043: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983043.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Install Team 
>
> If you wish to submit further information on this problem, please
> send it to 983...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 983043: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983043
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



-- 
"Non sibi, sed patriae"

Bug#983043: Failed to initialize GENET properly on RPI4 (arm64)

[Jeff Forsyth]

Package: installation-reports

Boot method: netboot
Image version: 
https://d-i.debian.org/daily-images/arm64/daily/netboot/debian-installer/arm64/linux
 2021-02-18 02:07 26M
Date: 2021-02-18 14:05:00

Machine: RPi4
Processor:
Memory: 4GiB
Partitions:

Output of lspci -knn (or lspci -nn):

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [E]
Detect media:   [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:

RPi 4 with 4GiB Ram.  System is netbooted using DNSMASQ, RPI-UEFI and iPXE.
Netboot Debian Installer for arm64 starts and fails at configuring the
genet ethernet card.
I have attempted to remove and reinstall the genet driver.  No effect.
ip link show has the card identified as enabcm6e4ei0.
I can put an address on the card using ip addr add.
ip link set dev down works
ip link set dev up fails with SIOCSIFFLAGS: No such device




-- 
"Non sibi, sed patriae"

Bug#982995:

[Jeff Forsyth]

This was a netboot attempt.

Bug#982995: Installation Report

[Jeff Forsyth]

Package: installation-reports

Boot method: 
Image version: 
https://d-i.debian.org/daily-images/arm64/daily/netboot/debian-installer/arm64/linux
2021-02-17 02:07
Date: 2021-02-17 19:14

Machine: RPI4
Processor:
Memory: 4G
Partitions:

Output of lspci -knn (or lspci -nn):

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[ ]
Configure network:  [ ]
Detect media:   [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:

RPI4 with 4GiB Ram.  This system is netbooted using RPI-UEFI 1.22 and
iPXE 1.2.x.

DNSMASQ send the RPI-UEFI to the RPI.  The RPI-UEFI pulls the arm64
EFI/ipxe.  The iPXE

shows a menu for booting into the Debian Installer.  The Installer
loads and starts the

interactive menu installation system.  Everything seems good until
input is required.  The

keyboard is dead.

Bug#980202: gscan2pdf tests fail

[Jeff]

reopen 980202
thanks

imagemagick 8:6.9.11.60+dfsg-1 does not include the bugfix that was 
promised here:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980202#41



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981798: imagemagick breaks gscan2pdf autopkgtest: expected format changed

[Jeff]

This is more or less a duplicate of #980202

To unblock gscan2pdf, in case -60 didn't fix things, I uploaded 
gscan2pdf-2.11.0-1 yesterday and replaced imagemagick with 
graphicsmagick for the tests in question.


However, this doesn't solve the problem in imagemagick, which is 
described in #980202, and for which imagemagick upstream claims to have 
a solutions, but evidently doesn't.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#980202: FTBFS: gscan2pdf tests fail

[Jeff]

On 23/01/2021 17:53, Cristy wrote:
Thanks for the problem report. We can reproduce it and will have a patch 
to fix it in the GIT main branch @ 
https://github.com/ImageMagick/ImageMagick6 later today. The patch will 
be available in the beta releases of ImageMagick @ 
https://imagemagick.org/download/beta/ by sometime tomorrow.


The problem was a performance optimization that broke text rendering. We 
reverted the patch. The official -58 release will be available within a 
few days.


-60 has been out for a couple of days, now. Does this fix the problem?



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980202: FTBFS: gscan2pdf tests fail

[Jeff]

This seems to be a bug in imagemagick preventing imagemagick from 
migrating from unstable to testing:


https://tracker.debian.org/pkg/imagemagick

https://ci.debian.net/packages/g/gscan2pdf/testing/amd64/



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980202: FTBFS: gscan2pdf tests fail

[Jeff]

Thanks for the head up.

I note that it built fine in sid a month ago:

https://buildd.debian.org/status/fetch.php?pkg=gscan2pdf=all=2.10.2-1=1608242025=0

but that it didn't a couple of days ago in reproducible-builds:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gscan2pdf.html

I guess something changed in the amd64 dependencies, because I can 
reproduce the problem now, too.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#979408: qpdfview: Cannot create annotation

[Jeff]

Hi Norbert,

On 06/01/2021 13:42, Norbert Preining wrote:

Yes, annotations are a PDF thingy. That you can view djvu with qpdfview
is just an "added gadget", but not all functionality is available.


DjVu documents support annotations, too. So perhaps we can turn this 
into two reports:


* at present, the user should get some feedback that qpdfview cannot
  create annotations in djvu
* a wishlist bug that the functionality be added.

Regards

Jeff



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979408: qpdfview: Cannot create annotation

[Jeff]

This seems to only affect djvu documents. With PDFs, it works as advertised.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977532: gscan2pdf: save option not available

[Jeff]

On 17/12/2020 20:05, Marc Dequènes (duck) wrote:
That's a tad rude. I understand you're preparing the release but the 
meaning of a bug is not up to discussion, problems in unstable, and even 
in experimental have always been considered bugs. As the package was 
almost unusable since my scans were lost I could even have raised the 
severity to prevent a broken version to enter testing and end-up in the 
release. I think you're confusing the severity of the bug itself and the 
priority generated by the situation (which has no real field in the BTS).


Yes, you are right. I misread 4.1.0+git201212-1 and didn't realise that 
it was the version in unstable. I apologise.


Yes it does. Using 'both' is clever and I think proposing the patch 
upstream would be a better solution (considering other distros and 
custom installs).


Thanks for the feedback. I'll push the fix ASAP.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977532: gscan2pdf: save option not available

[Jeff]

Thanks for the report.

The version of libtiff-tools in testing still outputs to stderr, so I am 
inclined to say this is not (yet) a Debian bug, and certainly not important.


Indeed, your patch will break the version of gscan2pdf in testing.

Does the attached patch also fix your problem?
diff --git a/bin/gscan2pdf b/bin/gscan2pdf
index 5f911aef..e8664d06 100755
--- a/bin/gscan2pdf
+++ b/bin/gscan2pdf
@@ -935,7 +935,7 @@ sub check_dependencies {
 'djvu', 'stderr', qr/DjVuLibre-([\d.]+)/xsm, [ 'cjb2', '--version' ]
 ],
 [
-'libtiff', 'stderr',
+'libtiff', 'both',
 qr/LIBTIFF,\sVersion\s([\d.]+)/xsm, [ 'tiffcp', '-h' ]
 ],
 
diff --git a/lib/Gscan2pdf/Document.pm b/lib/Gscan2pdf/Document.pm
index c0e0ad1c..76f832f0 100644
--- a/lib/Gscan2pdf/Document.pm
+++ b/lib/Gscan2pdf/Document.pm
@@ -2180,8 +2180,24 @@ sub program_version {
 sub _program_version {
 my ( $stream, $regex, @output ) = @_;
 my ( $status, $out,   $err )= @output;
-my $output = $stream eq 'stdout' ? $out : $err;
-if ( defined $output and $output =~ $regex ) { return $1 }
+if ( not defined $out ) { $out = q{} }
+if ( not defined $err ) { $err = q{} }
+my $output;
+given ($stream) {
+when ('stdout') {
+$output = $out
+}
+when ('stderr') {
+$output = $err
+}
+when ('both') {
+$output = $out . $err
+}
+default {
+$logger->error("Unknown stream: '$stream'");
+}
+}
+if ( $output =~ $regex ) { return $1 }
 if ( $status == $PROCESS_FAILED ) {
 $logger->info($err);
 return $PROCESS_FAILED;


OpenPGP_signature
Description: OpenPGP digital signature

Bug#973848: chromium: Unsupported version, many security bugs unfixed

[Jeff Blake]

Hi,

Good work everyone, I've read the thread with interest.

One patch I would question the need for is fixes/inspector.patch.

I'm not sure if it originally fixed a bug (it's in the fixes folder) or was 
desirable for some other reason, but things build fine without it.

It might be better to omit it for the sake of simplicity and reduced 
maintenance burden.


Regards,

Jeff Blake 

Bug#973848: chromium: Unsupported version, many security bugs unfixed

[Jeff Blake]

On Sat, 12 Dec 2020 19:47:32 +0100 Michel Le Bihan  wrote:
> Hello,
> 
> Thank you for your reply. libvpx got updated in Debian, but I can't use
> it because it's missing a lib. I also had issues with harfbuzz, so I'm
> using bundled versions of those libs as you are. I also used your ozone
> patch because it is match cleaner than mine. With that I was able to
> build Chromium, but with many lint errors and many missing patches.
> 
> BTW, have you tried opening a bug upstream or submitting your ozone
> patch upstream?
> 
> Michel Le Bihan

Hi,

I suspect that debian's libvpx might need to be build with experimental 
features enabled (similar to a previous bug report), in order to include 
the absent header files.

Are you sure that fixes/sequence-point.patch is necessary? I don't recall 
getting any warnings related to this when compiling.

Looking at the last couple of commits for the file affected by the ozone 
problem [1], it appears to be already fixed upstream.

[1] - https://tinyurl.com/yc8y4ah4


Regards,

Jeff

Bug#976865: Fwd: Bug#974900: dash removes trailing slash from script arguments

[Jeff King]

On Fri, Dec 11, 2020 at 01:03:11PM +1100, Herbert Xu wrote:

> On Thu, Dec 10, 2020 at 10:20:29AM -0500, Jeff King wrote:
> >
> > It seems like it happens for "foo/", too. If I compile:
> 
> I think the key is that dash uses GLOB_NOMAGIC.

I wondered that, too, but adding GLOB_NOMAGIC to the call doesn't seem
to change the results. This is all with libc6 2.31-5, by the way.

-Peff

Bug#976865: Fwd: Bug#974900: dash removes trailing slash from script arguments

[Jeff King]

On Thu, Dec 10, 2020 at 10:35:08PM +1100, Herbert Xu wrote:

> Yes but it's really a bug in glob(3).  It should really return
> a no-match for the case in question, rather than matching and then
> returning a filename without the slash.
> 
> IOW the pattern "foo\/" should not match a regular file foo.
> 
> Note that the problem doesn't occur for "foo/".

It seems like it happens for "foo/", too. If I compile:

-- >8 --
#include 
#include 

int main(int argc, const char **argv)
{
while (*++argv) {
glob_t r;
if (glob(*argv, 0, NULL, ))
perror(*argv);
else {
size_t i;
for (i = 0; i < r.gl_pathc; i++)
printf("%s -> %s\n", *argv, r.gl_pathv[i]);
globfree();
}
}
return 0;
}
-- >8 --

I get:

  $ rm -f foo bar
  $ touch foo
  $ ./a.out foo foo/ 'foo\/' bar bar/ 'bar\/'
  foo -> foo
  foo/ -> foo
  foo\/ -> foo
  bar: No such file or directory
  bar/: No such file or directory
  bar\/: No such file or directory

-Peff

Bug#972134: RE: chromium: please, consider moving the package to

[Jeff Blake]

 team-maintainance to properly maintain it
Message-Id: <20201209091550.4b05d60910d92ca4078eb...@gmail.com>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 2 Dec 2020 22:48:40 -0300 Leandro Cunha  
wrote:
> Hi,
> 
> Is there any dependency that needs to be packaged for the package to
> be updated? I remember seeing on the tracker that there are packages
> in python2 that according to a Debian Developer told me that it is not
> being allowed to enter the official repositories. The number of CVEs
> continues to rise. I would be happy to help.
> 
> 

libvpx is between releases and currently too old for chromium.

It's possible that openh264 is required for Webcodecs support. When building
ungoogled-chromium I used the bundled version, as an official debian package 
doesn't exist (although there is a 'deb-multimedia' one).

However, it remains to be seen if openh264 is strictly necessary, and it 
could probably be patched out.

If anyone wants to take a look, someone's posted about working to update 
chromium over at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973848



Jeff Blake 

Bug#973848: chromium: Unsupported version, many security bugs unfixed

[Jeff Blake]

On Tue, 08 Dec 2020 12:33:57 +0100 Michel Le Bihan  wrote:
> Hello,
> 
> I started work on updating the chromium package (you can see my work
> here:
> https://salsa.debian.org/mimi8/chromium/-/commit/af70b14701aaf6bdb34e23af01657676e27ba5d4
> ), but got stuck because `libvpx` is too old in Debian testing. It
> needs to be updated before I can continue work.
> 
> Michel Le Bihan
> 
> 
> 

I've managed to successfully update the ungoogled-chromium debian package [1], 
which is based upon 
the official debian package.

Until libvpx is updated (or a new release is made) you could use Chromium's 
bundled version of libvpx [2].

Feel free to have a look around my repo, as you might well encounter some of 
the same problems that 
I had in getting things to build.


Jeff Blake 


[1] https://github.com/berkley4/ungoogled-chromium-debian/commits/87.0.4280.88

[2] 
https://github.com/berkley4/ungoogled-chromium-debian/commit/05ffc529e685817aac8a9c5bb419daba17204a66

Bug#976157: thunderbird: Thunderbird refuses to decrypt inline PGP message

[Jeff]

On 03/12/2020 06:10, Carsten Schoenert wrote:

If the issue is also happen here please raise a report in the Bugzilla
issue tracker from Mozilla.


Somebody beat me to it:

https://bugzilla.mozilla.org/show_bug.cgi?id=1679018

And it looks as though it is fixed in TB79.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976157: thunderbird: Thunderbird refuses to decrypt inline PGP message

[Jeff]

Hi Carsten,

On 01/12/2020 20:43, Carsten Schoenert wrote:

yes, of course. But remember my sentence above your answer. If the
sender is using inline PGP with an HTML message the behavior is
undefined, in the end Thunderbird can't decrypt the message and there is
nothing we can do about this.


No. They are all plain text.


Without further information what the message is build of you have
problems with we can't do any useful error detection.
I expect you will have the same problems if you use an upstream version
of Thunderbird from Mozilla. If yes your bug report should go into
Bugzilla so MZLNA have a chance to fix the underlying issue (if possible).


Enigmail had no problem with these messages, and if Thunderbird cannot 
recognise them, then I cannot read them any more (including all the 
historical ones sitting my my mailbox.)


Regards

Jeff



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976157: thunderbird: Thunderbird refuses to decrypt inline PGP message

[Jeff]

Hi Carsten,

On 30/11/2020 19:42, Carsten Schoenert wrote:

is there a particular reason why you want to use inline PGP? This is an
old technique that shouldn't get used any longer, it's a dead horse.
PGP/MIME is the thing users should use instead. Thunderbird uses
PGP/MIME by default and I currently see no way to enforce inline PGP for
sending encrypted emails with Thunderbird?

You are aware that inline PGP is incompatible while using with HTML emails?


Other people send me inline PGP. I would like to be able to read what 
they have written.


I am happy sending with PGP/MIME.

Regards

Jeff



OpenPGP_signature
Description: OpenPGP digital signature

Bug#974900: dash removes trailing slash from script arguments

[Jeff King]

Package: dash
Version: 0.5.11+git20200708+dd9ef66-2
Severity: normal
Tags: upstream

With the latest version of dash, I get this behavior:

  $ touch here
  $ dash -c 'printf "%s\n" "$@"' -- here/ not-here/
  here
  not-here/

The trailing slash is stripped from the argument "here/", when the file
"here" exists in the current directory (but not from "not-here/", which
does not exist).

This is rather surprising to scripts which may not even intend for their
arguments to be files (I noticed because it breaks Git's test suite,
which expects "some-script foo/" to preserve the trailing slash, which
is meaningful in its internal path matching). And certainly it differs
from the behavior of 0.5.10.2-7, which prints "here/".

Bisection points to upstream 7638476 (shell: Enable fnmatch/glob by
default, 2020-05-28). And indeed, building locally with "./configure
--disable-fnmatch" makes the problem go away. But since that commit was
only flipping the defaults, presumably the problem was already there.
Bisecting with "--enable-fnmatch --enable-glob" shows that it comes from
6900ff6 (expand: Fix glibc glob(3) support, 2018-03-26).

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

Kernel: Linux 5.9.0-2-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 dash depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  debianutils4.11.2
ii  dpkg   1.20.5
ii  libc6  2.31-4

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#968918: Threshold function is extremely slow - Unusable - possible regression

[Jeff]

On 21/10/2020 04:35, debian-testing wrote:
> What version of gscan2pdf and imagemagick are you using to reproduce the 
> problem?  It has to be recent versions on Debian 11 and the scan or image 
> also needs to be 600dpi (300 dpi is fast).

Thanks. This was the detail that allowed me to reproduce the problem.
The following also creates a file that highlights the issue:

convert -size 5100x6600 canvas:red Untitled.jpg

I've fixed this in the upcoming release, although I couldn't find the
correct Perlmagick calls: I had to resort to imagemagick command line
calls (similar to your suggestion).

Thanks for the report.



signature.asc
Description: OpenPGP digital signature

Bug#972218: depends on liblocale-codes-perl

[Jeff]

clone 972218 -1
reassign -1 liblocale-codes-perl
retitle -1 provided by perl-modules-5.24 prevents upgrade from stretch
thanks

On 15/10/2020 19:30, Niko Tyni wrote:
>> Would you like me to duplicate the bug so that it doesn't get forgotten?
> 
> Sure, please do. Thanks for bringing this up.

Please reassign elsewhere if necessary.

Regards

Jeff



signature.asc
Description: OpenPGP digital signature

Bug#972218: depends on liblocale-codes-perl

[Jeff]

On 15/10/2020 12:52, Niko Tyni wrote:
> So it should only happen for systems upgraded from stretch. A
> workaround for gscan2pdf could be to declare a versioned dependency on
> liblocale-codes-perl (>= 3.60) or something like that so it wouldn't be
> satisfied by the old perl-modules-5.24.
> 
> Not sure if we should make perl in sid/bullseye Break perl-modules-5.24.
> I'd prefer to keep them coinstallable but I can't see any other generic
> fix.

If you don't have a generic fix in time for the next gscan2pdf release
in around ten days, I'll use your workaround. Thanks for the suggestion.

Would you like me to duplicate the bug so that it doesn't get forgotten?



signature.asc
Description: OpenPGP digital signature

Bug#972218: depends on liblocale-codes-perl

[Jeff]

On 15/10/2020 09:07, Damyan Ivanov wrote:
> 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.

Thanks for the hint.

John still has perl-modules-5.24, which provides liblocale-codes-perl.
But as his perl is probably 5.30, perl-modules-5.24 is probably not in
his @INC.

So the reason that liblocale-codes-perl wasn't pulled in when upgrading
gscan2pdf was because apt thought it was already provided by
perl-modules-5.24, which is only true for perl 5.24.

Does this mean that liblocale-codes-perl should be breaks:
perl-modules-5.24 ?

Does anyone see a better solution?

Regards

Jeff



signature.asc
Description: OpenPGP digital signature

Bug#972218: gscan2pdf should depend on liblocale-codes-perl

[Jeff]

On 14/10/2020 19:33, John Lines wrote:
> gscan2pdf in bullseye fails with 
> 
> Cant locate Locale/Language.pm
> 
> is fixed with
> 
>  apt-get install liblocale-codes-perl
> 
> but a Depends would avoid users seeing this error

Thanks for the report.

liblocale-codes-perl is already a dependency, so I don't know why
upgrading gscan2pdf didn't pull it in:

https://packages.debian.org/bullseye/gscan2pdf

I've just tested removing both packages, and installing gscan2pdf does
pull in liblocale-codes-perl as it should.



signature.asc
Description: OpenPGP digital signature

Bug#970803: lighttpd: appliation segfaults on start

[Jeff]

Package: lighttpd
Version: 1.4.55-1~bpo10+1
Severity: normal

Dear Maintainer,

  I am running the current version of Raspbian using DietPI on a RPI Zero.
  Installed lighttpd from the Buster-Backports.
  Segfault on start/restart/command line.
  Pretty simple.

-- System Information:
Debian Release: 10.4
Architecture: armhf (armv6l)

Kernel: Linux 5.4.51+
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lighttpd depends on:
ii  libattr1  1:2.4.48-4
ii  libbz2-1.01.0.6-9.2~deb10u1
ii  libc6 2.28-10+rpi1
ii  libfam0   2.7.0-17.3
ii  libpcre3  2:8.39-12
ii  libssl1.1 1.1.1d-0+deb10u3+rpt1
ii  lsb-base  10.2019051400+rpi1
ii  mime-support  3.62
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages lighttpd recommends:
ii  perl5.28.1-6
pn  spawn-fcgi  

Versions of packages lighttpd suggests:
pn  apache2-utils   
pn  lighttpd-doc
pn  lighttpd-mod-authn-gssapi   
pn  lighttpd-mod-authn-pam  
pn  lighttpd-mod-authn-sasl 
pn  lighttpd-mod-cml
pn  lighttpd-mod-geoip  
pn  lighttpd-mod-magnet 
pn  lighttpd-mod-maxminddb  
pn  lighttpd-mod-trigger-b4-dl  
pn  lighttpd-mod-vhostdb-dbi
pn  lighttpd-mod-vhostdb-pgsql  
pn  lighttpd-mod-webdav 
pn  lighttpd-modules-ldap   
pn  lighttpd-modules-mysql  
ii  openssl 1.1.1d-0+deb10u3+rpt1
pn  php-cgi 
pn  rrdtool 

-- no debconf information