Bug#1032818: Add debian/watch file when updating leptonlib version
Please apply the attached patch when updating the version of the leptonlib package. This adds a debian/watch file to allow checking for new upstream versionsof Leptonica automatically. https://wiki.debian.org/debian/watch diff -Nru leptonlib-1.82.0/debian/watch leptonlib-1.82.0/debian/watch --- leptonlib-1.82.0/debian/watch 1969-12-31 19:00:00.0 -0500 +++ leptonlib-1.82.0/debian/watch 2021-12-31 18:20:26.0 -0500 @@ -0,0 +1,4 @@ +version=4 +opts="searchmode=plain" \ +https://api.github.com/repos/DanBloomberg/leptonica/releases?per_page=50 \ +https://github.com/[^/]+/[^/]+/releases/download/[^/]+/leptonica@ANY_VERSION@@ARCHIVE_EXT@ smime.p7s Description: S/MIME Cryptographic Signature
Bug#1032818: leptonlib: New version 1.83.1
Source: leptonlib Leptonica version 1.83.1 was released on January 26, 2023. https://github.com/DanBloomberg/leptonica/releases/tag/1.83.1 https://github.com/DanBloomberg/leptonica/releases/download/1.83.1/leptonica-1.83.1.tar.gz
Bug#942176: libsane: Canon LiDE 220 works up to 1200 dpi only
On 3/29/2022 8:13 AM, David Ward wrote: The 32-bit overflow issue with the backend should be fixed now in libsane1 1.1.1-5. With that installed, can you please try xsane again? Is there still an issue with colors? If you experience segmentation faults, can you please try to obtain a backtrace? https://wiki.debian.org/HowToGetABacktrace Thanks, David This was sent to the wrong bug mail address. Please reply to bug 1006592.
Bug#1006592: xsane: wrong colors with 2400/4800 dpi scans using Canon LiDE 220
Philipp, On 2/21/2022 5:01 AM, Philipp Klaus Krause wrote: On 12/9/2020 8:22 AM, Philipp Klaus Krause wrote: Summary: The situation improved somewhat, but is still far from perfect: There is still an odd waiting time when starting to scan at 2400 or 4800 (at 1200 and below the scan starts nearly instantly, after less than second). At 4800 colors ar wrong. Once one of these problems appears, it affects all resolutions until restarting xsane: Having done a scan at 2400 or 4800, subsequent scans at lower resolutions also have the waiting time at the start. Having done a scan at 2400 or 4800, where black appeared as bordeaux, subsequent scans at lower resolutions also have wrong colors. You mentioned that you are using GIMP to launch xsane. The problem with the colors could be occurring there. Can we rule that out? What happens if you run "scanimage" from the command-line — does it produce an image with the correct colors? Due to a gimp bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994429) I haven't launched xsane from gimp for a while. But your request still helped track down the issue a bit further: I have not been able to reproduce the bug using scanimage from the command line¹ (did various scans at 2400 and 4800 dpi today, using Debian testing). Both speed and color were fine using scanimage from the command line. But I can reproduce the bug using xsane started from the command line (also tested today). I also got a segfault in xsane once (just at the end of a 4800 dpi scan). Philipp ¹ I do get a different bug with scanimage though: For a full-size scan at 4800 dpi, two thirds of the image are just gray. The 32-bit overflow issue with the backend should be fixed now in libsane1 1.1.1-5. With that installed, can you please try xsane again? Is there still an issue with colors? If you experience segmentation faults, can you please try to obtain a backtrace? https://wiki.debian.org/HowToGetABacktrace Thanks, David
Bug#942176: libsane: Canon LiDE 220 works up to 1200 dpi only
Philipp, On 2/21/2022 5:01 AM, Philipp Klaus Krause wrote: On 12/9/2020 8:22 AM, Philipp Klaus Krause wrote: Summary: The situation improved somewhat, but is still far from perfect: There is still an odd waiting time when starting to scan at 2400 or 4800 (at 1200 and below the scan starts nearly instantly, after less than second). At 4800 colors ar wrong. Once one of these problems appears, it affects all resolutions until restarting xsane: Having done a scan at 2400 or 4800, subsequent scans at lower resolutions also have the waiting time at the start. Having done a scan at 2400 or 4800, where black appeared as bordeaux, subsequent scans at lower resolutions also have wrong colors. You mentioned that you are using GIMP to launch xsane. The problem with the colors could be occurring there. Can we rule that out? What happens if you run "scanimage" from the command-line — does it produce an image with the correct colors? Due to a gimp bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994429) I haven't launched xsane from gimp for a while. But your request still helped track down the issue a bit further: I have not been able to reproduce the bug using scanimage from the command line¹ (did various scans at 2400 and 4800 dpi today, using Debian testing). Both speed and color were fine using scanimage from the command line. But I can reproduce the bug using xsane started from the command line (also tested today). I also got a segfault in xsane once (just at the end of a 4800 dpi scan). Philipp ¹ I do get a different bug with scanimage though: For a full-size scan at 4800 dpi, two thirds of the image are just gray. The 32-bit overflow issue with the backend should be fixed now in libsane1 1.1.1-5. With that installed, can you please try xsane again? Is there still an issue with colors? If you experience segmentation faults, can you please try to obtain a backtrace? https://wiki.debian.org/HowToGetABacktrace Thanks, David
Bug#993350: Still problems
On 3/15/2022 7:15 AM, ael wrote: In fact there are still outstanding problems which are mentioned earlier in this bug. Separate problems need to be tracked in separate bugs, even if they affect the same hardware. Please see: https://www.debian.org/Bugs/Reporting This bug in Debian was reported by Hans Georg Colle when using sane-backends version 1.0.32-4. It was fixed by a upstream change to the epson2 driver in sane-backends version 1.1.1, related to setting the focusSupport flag on specific hardware. He has confirmed this fix. https://gitlab.com/sane-project/backends/-/issues/445 https://gitlab.com/sane-project/backends/-/merge_requests/604 Wolfram Sang, the upstream maintainer, is aware of the remaining bugs. I infer that he hasn't had time to track them down as yet, but he has said that he is investigating. The same is true upstream: different problems in each backend are tracked as separate issues. It is more helpful to the upstream maintainers to use their issue tracker to report and follow individual issues, rather than their mailing list. It avoids that question by making clear the status of each issue. https://gitlab.com/sane-project/backends/-/issues As I recall, the main problem is with very large scans which fail. Less important is that xsane "hangs" when the [CANCEL] button is pressed instead of recovering gracefully. It is very important to distinguish where the bugs are occurring here. An issue should only be attributed to xsane if it cannot be reproduced by using the "scanimage" command (or a different frontend, such as simple-scan). The issues that have been identified so far are in the epson2 backend. The sane backends and the xsane frontend are in two different code bases that have separate upstream maintainers, and are separately packaged in Debian. https://gitlab.com/sane-project/backends/ https://gitlab.com/sane-project/frontend/xsane Thanks for your help! David
Bug#1005091: Reminder: Pull request for sane-backends package Debian source repository
Jörg — a friendly reminder that this pull request is ready for review. (See the bottom of this message). Please refer to our earlier discussion below; I have added a comment. On Mon, 07 Feb 2022 at 19:17:48 -0500, David Ward wrote: > On Mon, 07 Feb 2022 at 23:35:49 +0100, Jörg Frings-Fürst wrote: > > On Mon, 07 Feb 2022 at 03:09:25 -0500, David Ward wrote: > > > saned is a daemon used to share scanners over the network. > > > > > > This belongs in its own package. Users should be able to install > > > and run the other command-line utilities — in particular, > > > scanimage — without installing saned (even if it is disabled). > > > This is analogous to cupsd, which is provided in a separate > > > package from the rest of CUPS. > > > > > > As with any daemon, there is an attack surface with saned [*]. > > > Also note that there are Debian-based containers which make use of > > > scanimage but not saned, and these could benefit from having them > > > in separate packages. > > > > > > > > > I would suggest this be achieved as follows: > > > > > > 1) move all files related to saned out of "sane-utils", and into a > > >new package named "sane-dameon"; > > > 2) move all remaining files out of "sane-utils", and into a new > > >package named "libsane-utils"; > > > 3) retain "sane-utils" as a virtual package that depends on both > > >packages above, to ensure upgrades work as expected. > > > > > > > > > [*] https://www.debian.org/lts/security/2017/dla-940.en.html > > > > I already thought about splitting the packages during the transition > > to libsane1. > > > > Unlike cups, which hardly makes sense without a daemon, saned is not > > absolutely necessary. > > That is exactly why we should split it out as a separate package. > > The user should be able to choose not to install saned, without that > choice preventing the user from running scanimage. I would very kindly > point out that Fedora and Red Hat do split these out as separate > packages. > > > Also, saned is not activated by default during installation. So I > > don't see any problem in the installation, even from a security > > point of view. > > That is not the reality of how organizations approach security though. > Even if the daemon is not activated, it may still be a compliance > issue to have a daemon with a known vulnerability present on the > system at all. It is best to not install daemons that are never used, > in order to reduce the amount of time spent applying security updates > to unused software. In the Securing Debian Manual, section 3.6 — "Install the minimum amount of software required" — explains this using the same reasoning. https://www.debian.org/doc/manuals/securing-debian-manual/ch03s06.en.html "Since you already know what the system is for (don't you?) you should only install software that is really needed for it to work. Any unnecessary tool that is installed might be used by a user that wants to compromise the system or by an external intruder that has gotten shell access (or remote code execution through an exploitable service)." > This also did not address my point about Debian-based Docker > containers which use scanimage, such as scanservjs. Containers often > try to include only the minimum software required, and typically they > do not even have systemd or any init system. Can you please review the pull request below? (See the "Merge workflow" described in gitworkflows(7): to apply these changes, you can simply run "git pull https://salsa.debian.org/dpward/sane-backends.git develop".) Thank you, David -- The following changes since commit fc21048b997b1515a98c5c26fbf2501bdab207f1: Merge tag 'debian/1.1.1-4' into develop (2022-02-28 08:16:14 +0100) are available in the Git repository at: https://salsa.debian.org/dpward/sane-backends.git develop for you to fetch changes up to b8466bacadf79f655b69b4ca8c03a9aef103a05f: Split sane-utils package into sane-daemon and libsane-utils (2022-03-10 17:30:08 -0500) David Ward (6): Remove remaining support for RUN parameter in sysvinit service d/rules: Replace override_dh_installman-* with explicit file lists d/rules: Use override_dh_auto_install-arch for removing rpaths d/*.README.Debian: Fix references to the libsane1 package d/*.README.Debian: Adjust to reflect current permissions Split sane-utils package into sane-daemon and libsane-utils
Bug#942176: libsane: Canon LiDE 220 works up to 1200 dpi only
tags 942176 + fixed-upstream stop This was a 32-bit integer overflow issue. Note that a full size, 4800 dpi color scan produces an image that is > 6 GiB uncompressed.
Bug#942176: libsane: Canon LiDE 220 works up to 1200 dpi only
On 2/27/2022 6:55 PM, David Ward wrote: Both issues have just been reproduced upstream. Discussion at: https://gitlab.com/sane-project/backends/-/merge_requests/374#note_856438189 Cloning this bug in Debian, since there seem to be separate issues in the backend (libsane1) and the graphical frontend (xsane). Let me clarify that first: The issue in the backend seems to have been reproduced. When trying to use xsane instead of scanimage, one of the developers also got a segfault. Without backtraces, it is not clear if that is related to what you encountered. That also means there wasn't an image produced by xsane, so there was no confirmation about wrong colors. I would assume the upstream priority is fixing the backend first. In any case, still cloning this bug.
Bug#942176: libsane: Canon LiDE 220 works up to 1200 dpi only
On 2/21/2022 5:01 AM, Philipp Klaus Krause wrote: I have not been able to reproduce the bug using scanimage from the command line¹ (did various scans at 2400 and 4800 dpi today, using Debian testing). Both speed and color were fine using scanimage from the command line. But I can reproduce the bug using xsane started from the command line (also tested today). I also got a segfault in xsane once (just at the end of a 4800 dpi scan). Philipp ¹ I do get a different bug with scanimage though: For a full-size scan at 4800 dpi, two thirds of the image are just gray. Both issues have just been reproduced upstream. Discussion at: https://gitlab.com/sane-project/backends/-/merge_requests/374#note_856438189 Cloning this bug in Debian, since there seem to be separate issues in the backend (libsane1) and the graphical frontend (xsane).
Bug#942176: libsane: Canon LiDE 220 works up to 1200 dpi only
On 2/21/2022 5:01 AM, Philipp Klaus Krause wrote: I do get a different bug with scanimage though: For a full-size scan at 4800 dpi, two thirds of the image are just gray. Does the problem you see from scanimage happen with version 1.1.1 (of libsane1, libsane-common, sane-utils, etc.)?
Bug#1005737: Purging sane-utils deletes the scanner group, created by libsane1
Package: sane-utils Version: 1.1.1-2 Severity: serious (The original title and description of this bug were inaccurate; please disregard those. The existing pull request has been updated.) When the libsane1 package is installed, a "scanner" group is created on the system, which has access to the device nodes for local scanners. If the sane-utils package is also installed, it creates a "saned" user and group for running the network daemon. By default, the "saned" user is added to the "scanner" group, so that the daemon has access to local scanners (but this behavior is controlled using debconf). If the sane-utils package is purged, it not only deletes the "saned" user and group, but it also unconditionally deletes the "scanner" group, which it did not create and which libsane1 still uses for device node permissions. (Assuming sane-utils was purged alone, attempting to reinstall it will also fail during the configure phase, since the "saned" user cannot be added to the missing "scanner" group.)
Bug#998656: sane-avision: adds a blank a4 page at the bottom of the scan
On 11/5/2021 1:59 PM, Bertrand Marc wrote: After upgrading to bullseye, scanning with my HP Scanjet 5300C (ID 03f0:0701 HP, Inc ScanJet 5300c/5370c) became difficult. Please note that it was working fine with buster, except that it required the attached /etc/sane.d/avision.conf and works with 300 and 600 ppp (but not 150). With the same /etc/sane.d/avision.conf as in buster, it now adds a second blank a4 page at the bottom of any scan (see attached picture). Force-a4 option in /etc/sane.d/avision.conf doesn't change anything. Forcing a4 with simple-scan sometimes produces a4 with half bottom blank (randomly). * What happens if you don't choose any options in /etc/sane.d/avision.conf? I would make note of the last paragraph of the "Configuration" section in the sane-avision(5) man page. * This might be the "double height" problem with the HP ScanJet 5300C mentioned upstream: https://gitlab.com/sane-project/backends/-/issues/393 There is a fix for it in version 1.0.32 (and version 1.1.1 in sid). Could you please try that to see if it makes a difference? * If these do not help, can you try running "scanimage" with increased verbosity?
Bug#983332: sane-utils: incorrectly identifies Wifi USB dongles as scanners
On 2/23/2021 8:13 AM, Martin-Éric Racine wrote: $ sudo sane-find-scanner found USB scanner (vendor=0x04a9 [Canon], product=0x2220 [CanoScan], chip=LM9830) at libusb:002:003 found USB scanner (vendor=0x0411 [Ralink], product=0x00e8 [802.11 n WLAN]) at libusb:001:004 found USB scanner (vendor=0x0b05 [Ralink], product=0x179d [802.11 n WLAN]) at libusb:001:003 What is the output of: $ sudo sane-find-scanner -v -v The relevant source code is here: https://gitlab.com/sane-project/backends/-/blob/1.1.1/tools/sane-find-scanner.c#L1039-1060 Apparently, this assumes that if your USB device exposes even /one/ interface where the device class or interface class is "vendor-specific", then it is a scanner. That is almost certainly the problem.
Bug#942176: libsane: Canon LiDE 220 works up to 1200 dpi only
It seems very likely that the original problem is an upstream bug in SANE. There are a few issues reported there specifically against the Canon LiDE 220 that sound very similar: https://gitlab.com/sane-project/backends/-/issues/439 https://gitlab.com/sane-project/backends/-/issues/518 On 12/9/2020 8:22 AM, Philipp Klaus Krause wrote: Summary: The situation improved somewhat, but is still far from perfect: There is still an odd waiting time when starting to scan at 2400 or 4800 (at 1200 and below the scan starts nearly instantly, after less than second). At 4800 colors ar wrong. Once one of these problems appears, it affects all resolutions until restarting xsane: Having done a scan at 2400 or 4800, subsequent scans at lower resolutions also have the waiting time at the start. Having done a scan at 2400 or 4800, where black appeared as bordeaux, subsequent scans at lower resolutions also have wrong colors. You mentioned that you are using GIMP to launch xsane. The problem with the colors could be occurring there. Can we rule that out? What happens if you run "scanimage" from the command-line — does it produce an image with the correct colors?
Bug#983349: hplip
On 8/29/2021 4:12 AM, alain wrote: $ dpkg -l sane-backends dpkg-query: aucun paquet ne correspond à sane-backends sane-backends is the source package name. You cannot install that. Please run "sudo apt upgrade libsane-common". $ cat /etc/debian_version bookworm/sid $ dpkg-query -l 'hplip*' 'libsane*' 'sane*' | cat Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===-===--=== ii hplip 3.21.12+dfsg0-1 amd64 HP Linux Printing and Imaging System (HPLIP) ii hplip-data 3.21.12+dfsg0-1 all HP Linux Printing and Imaging - data files un hplip-doc (no description available) ii hplip-gui 3.21.12+dfsg0-1 all HP Linux Printing and Imaging - GUI utilities (Qt-based) un libsane (no description available) ii libsane-common 1.1.1-2 all API library for scanners -- documentation and support files ii libsane-hpaio:amd64 3.21.12+dfsg0-1 amd64 HP SANE backend for multi-function peripherals ii libsane1:amd64 1.1.1-2 amd64 API library for scanners ii sane-utils 1.1.1-2 amd64 API library for scanners -- utilities
Bug#1005091: Pull request for sane-backends package Debian source repository
The following changes since commit 14e37bc19c5065d445e0b2dc405c3144331c5660:
d/changelog: Change distribution to unstable, Change date and time
(2022-02-07 20:37:06 +0100)
are available in the Git repository at:
https://salsa.debian.org/dpward/sane-backends.git develop
for you to fetch changes up to ac8816eb1dabbaf4b303edf52a1c0cb4e9fd45a7:
d/*.README.Debian: Adjust to reflect current permissions
(2022-02-13 22:22:46 -0500)
David Ward (9):
Move sane-umax_pp(5) to libsane-common, and remove umax_pp(5) symlink
d/rules: Replace override_dh_installman-* with explicit file lists
d/rules: Use override_dh_auto_install-arch for removing rpaths
Split sane-utils package into sane-daemon and libsane-utils
d/sane-daemon.postrm: Do not delete scanner group
Remove leftover handling related to RUN parameter
d/*.README.Debian: Fix references to the libsane1 package
d/*.README.Debian: Fix instructions for sysvinit
d/*.README.Debian: Adjust to reflect current permissions
debian/changelog | 28
debian/control | 73
.../{sane-utils.install => libsane-utils.install} | 2 -
debian/libsane-utils.manpages | 3 +
debian/libsane1.README.Debian | 44 +---
debian/not-installed | 1 +
debian/po/POTFILES.in | 2 +-
debian/po/ca.po | 67 ++
debian/po/cs.po | 62 ++---
debian/po/da.po | 64 ++
debian/po/de.po | 68
++-
debian/po/es.po | 69
++-
debian/po/eu.po | 66 ++
debian/po/fi.po | 66 ++
debian/po/fr.po | 68
++-
debian/po/gl.po | 79
++
debian/po/it.po | 65 ++
debian/po/ja.po | 65 ++
debian/po/nl.po | 68
++-
debian/po/pl.po | 65 ++
debian/po/pt.po | 64 ++
debian/po/pt_BR.po | 67 ++
debian/po/ru.po | 64 ++
debian/po/sk.po | 63 ++---
debian/po/sv.po | 64 ++
debian/po/templates.pot | 51 ++
debian/po/vi.po | 65 ++
debian/po/zh_CN.po | 61 ++---
debian/rules | 34 +++---
...ils.README.Debian => sane-daemon.README.Debian} | 51 ++
debian/{sane-utils.config => sane-daemon.config} | 0
debian/{sane-utils.dirs => sane-daemon.dirs} | 0
debian/sane-daemon.install | 2 +
debian/sane-daemon.links | 1 +
...{sane-utils.logrotate => sane-daemon.logrotate} | 0
debian/sane-daemon.manpages | 1 +
.../{sane-utils.postinst => sane-daemon.postinst} | 14
debian/{sane-utils.postrm => sane-daemon.postrm} | 1 -
...ils.saned.default => sane-daemon.saned.default} | 2 +-
...ane-utils.saned.init => sane-daemon.saned.init} | 1 -
...utils.saned.socket => sane-daemon.saned.socket} | 0
...s.saned@.service => sane-daemon.saned@.service} | 0
debian/sane-daemon.templates | 15
debian/sane-utils.links | 2 -
debian/sane-utils.maintscript | 1 +
debian/sane-utils.manpages | 3 -
debian/sane-utils.templates | 35 --
47 files changed, 283 insertions(+), 1404 deletions(-)
rename debian/{sane-utils.install => libsane-utils.install} (69%)
create mode 100644 debian/libsane-utils.manpages
rename debian/{sane-utils.README.Debian => sane-daemon.README.Debian}
(51%)
rename debian/{sane-utils.config => sane-daemon.config} (100%)
rename debian/{sane-utils.dirs => sane-daemon.dirs} (100%)
create mode 100644 debian/sane-daemon.install
create mode 100644 debian/sane-daemon.links
rename debian/{sane-utils.logrotate => sane-daemon.logrotate} (100%)
create mode 100644 debian/sane-daemon.manpages
rename debian/{sane-utils.postinst => sane-daemo
Bug#1005736: sane-umax_pp(5) does not describe umax_pp command-line utility
Package: sane-utils Version: 1.1.1-2 SANE provides a backend driver named umax_pp to supports Umax parallel port flatbed scanners. This is a library (libsane-umax_pp.so.1) found in the Debian package libsane1. SANE also includes a command-line utility named umax_pp for testing, which is found in the Debian package sane-utils. As of package version 1.0.27-1, the man page sane-umax_pp(5) was moved to the sane-utils package, along with a symbolic link located at umax_pp(5). However, this man page is only for the driver; it provides no information at all about the command-line utility. Even worse, the man page is not present on the system if the driver is installed but the command-line utilities are not. This change needs to be reversed, by moving sane-umax_pp(5) back into the libsane-common package, and removing the umax_pp(5) symbolic link. If a man page is desired for the umax_pp utility, it will have to be written.
Bug#1005737: Purging package deletes the scanner group, which belongs to system
Package: sane-utils Version: 1.1.1-2 Debian includes a "scanner" group when the operating system is installed. When installing the sane-utils package, the newly-created "saned" user is added to this group by default. If the sane-utils package is purged though, the "scanner" group is deleted along with the "saned" user. This should not happen, since the group does not belong to SANE. Attempting to install the sane-utils package again will actually fail during configuration, because the "saned" user cannot be added to the "scanner" group which no longer exists. (Although this is the default behavior, a debconf question asks if the "saned" user should be added to this group.)
Bug#1005091: Split saned out of sane-utils into a separate package
> > Hi Jörg, > Unlike cups, which hardly makes sense without a daemon, saned is not > absolutely necessary. > That is exactly why we should split it out as a separate package. The user should be able to choose not to install saned, without that choice preventing the user from running scanimage. I would very kindly point out that Fedora and Red Hat do split these out as separate packages. Also, saned is not activated by default during installation. So I don't see > any problem in the installation, even from a security point of view. > That is not the reality of how organizations approach security though. Even if the daemon is not activated, it may still be a compliance issue to have a daemon with a known vulnerability present on the system at all. It is best to not install daemons that are never used, in order to reduce the amount of time spent applying security updates to unused software. This also did not address my point about Debian-based Docker containers which use scanimage, such as scanservjs. Containers often try to include only the minimum software required, and typically they do not even have systemd or any init system. As in bug #987800, I therefore see no reason for splitting. > I am in the process of submitting a merge request for the Debian packaging files. Could you kindly keep this bug open, and let's take a look at that once I submit it? Thank you, David
Bug#1005091: Split saned out of sane-utils into a separate package
Package: sane-utils Version: 1.1.1-1 saned is a daemon used to share scanners over the networks. This belongs in its own package. Users should be able to install and run the other command-line utilities - in particular, scanimage - without installing saned (even if it is disabled). This is analogous to cupsd, which is provided in a separate package from the rest of CUPS. As with any daemon, there is an attack surface with saned*. Also note that there are Debian-based containers which make use of scanimage but not saned, and these could benefit from splitting it. I would suggest this be achieved as follows: 1) move all files related to saned out of "sane-utils", and into a new package named "sane-dameon"; 2) move all remaining files out of "sane-utils", and into a new package named "libsane-utils"; 3) retain "sane-utils" as a virtual package that depends on both packages above, to ensure upgrades work as expected. Thank you, David * https://www.debian.org/lts/security/2017/dla-940.en.html
Bug#1001403: debhelper: claims it needs perl 5.24, but it seems to require 5.28
On 12/9/2021 11:15 AM, Mattia Rizzolo wrote:
Source: debhelper
Version: 13.5.2
Hi Niels!
I was looking at backporting 13.5.2 all the way to ubuntu 18.04 bionic,
which ships with perl 5.26.
However, it seems that commit 3b2fe5334b88e38197fa24d9459544e50466fc92
"Dh_Lib.pm: Use state feature (by using v5.24)" doesn't make it a
no-change rebuild.
| debian/rules clean
|./run dh clean --without autoreconf --with build-stamp
|Initialization of state variables in list context currently forbidden at
/build/debhelper-13.5.2ubuntu1~bpo18.04.1/lib/Debian/Debhelper/Dh_Lib.pm line 2026, near
");"
|BEGIN not safe after errors--compilation aborted at
/build/debhelper-13.5.2ubuntu1~bpo18.04.1/lib/Debian/Debhelper/Dh_Lib.pm line
2748.
|Compilation failed in require at ./dh line 15.
|BEGIN failed--compilation aborted at ./dh line 15.
|debian/rules:15: recipe for target 'clean' failed
Whilst it's true that perl 5.24 introduced the state feature, being able
to initialized a persistant hash or array is a feature that has been
introduced with perl 5.28.
https://perldoc.perl.org/perl5280delta#Initialisation-of-aggregate-state-variables
I'm not sure if I should ask you to fully support perl 5.26, or perhaps
just bump the requirement; I'll leave the choice to you, however of
course I'd prefer the former :)
Incidentally, I believe that this is the background of
24fbbbfb116fc07e1ed2a09eb4e5f6713a74e361, so IMHO you should either bump
_that_ `use`, or, if you elect to support 5.26, revert it in favour of
not using `state` in that form.
Commit 24fbbbfb116f was partially reverted:
https://tracker.debian.org/news/1247918/accepted-debhelper-134nmu1-source-into-unstable/
So I agree that either your patch below should be applied, or commit
3b2fe5334b88 should be reverted, to bring the code in line with the
stated requirement for Perl 5.24+. (This would also allow it to run on
EPEL 8.)
Additionally, the remainder of commit 24fbbbfb116f should be reverted,
since dh_missing only requires Perl 5.24+ (not 5.28+).
Also, if you go the route of not supporting old perl, could you please
consider documenting this in d/control too?
Now, with the little tiny perl knowledge I had I did this. Following
this change, and reverting 24fbbbfb116fc07e1ed2a09eb4e5f6713a74e361,
debhlper builds fine at the very least. I'll have to do some tests to
see if it actually works fine too, but I'm optimistic :)
|diff --git a/lib/Debian/Debhelper/Dh_Lib.pm b/lib/Debian/Debhelper/Dh_Lib.pm
|index 2fefad69..30c30256 100644
|--- a/lib/Debian/Debhelper/Dh_Lib.pm
|+++ b/lib/Debian/Debhelper/Dh_Lib.pm
|@@ -2014,6 +2014,8 @@ sub _parse_debian_control {
| # - Takes an optional keyword; if passed, this will return true if the
keyword is listed in R^3 (Rules-Requires-Root)
| # - If the optional keyword is omitted or not present in R^3 and R^3 is not
'binary-targets', then returns false
| # - Returns true otherwise (i.e. keyword is in R^3 or R^3 is 'binary-targets')
|+{
|+my %rrr;
| sub should_use_root {
|my ($keyword) = @_;
|my $rrr_env = $ENV{'DEB_RULES_REQUIRES_ROOT'} // 'binary-targets';
|@@ -2023,10 +2025,11 @@ sub should_use_root {
|return 1 if $rrr_env eq 'binary-targets';
|return 0 if not defined($keyword);
|
|- state %rrr = map { $_ => 1 } split(' ', $rrr_env);
|+ %rrr = map { $_ => 1 } split(' ', $rrr_env) if not %rrr;
|return 1 if exists($rrr{$keyword});
|return 0;
| }
|+}
|
| # Returns the "gain root command" as a list suitable for passing as a part of the
command to "doit()"
| sub gain_root_cmd {
|@@ -2139,11 +2142,16 @@ sub is_udeb {
|return $package_types{$package} eq 'udeb';
| }
|
|+{
|+my %packages_to_process;
| sub process_pkg {
|my ($package) = @_;
|- state %packages_to_process = map { $_ => 1 } @{$dh{DOPACKAGES}};
|+ if (not %packages_to_process) {
|+ %packages_to_process = map { $_ => 1 } @{$dh{DOPACKAGES}};
|+ }
|return $packages_to_process{$package} // 0;
| }
|+}
|
| # Only useful for dh(1)
| sub bd_dh_sequences {
|@@ -2938,12 +2946,15 @@ sub perl_cross_incdir {
|return $incdir;
| }
|
|+{
|+my %known_packages;
| sub is_known_package {
|my ($package) = @_;
|- state %known_packages = map { $_ => 1 } getpackages();
|+ %known_packages = map { $_ => 1 } getpackages() if not %known_packages;
|return 1 if exists($known_packages{$package});
|return 0
| }
|+}
|
| sub assert_opt_is_known_package {
|my ($package, $method) = @_;
|
/
Bug#945914: Sound broken on Intel Baytrail and Broadwell platforms (regression from bug 940726)
Package: linux Version: 5.3.7-1 Severity: important Owner: Salvatore Bonaccorso Tags: patch The kernel configuration change from Debian bug 940726 is invalid, according to Intel: https://bugzilla.kernel.org/show_bug.cgi?id=204237#c15 The options for the SST and SOF drivers for Baytrail/Broadwell cannot both be set. This will be enforced via Kconfig beginning in Linux 5.5-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=df7257e544faf838c3e7ad6b4e89ffe59e87f5e1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=a6955fe0e2309feeab5ec71e4b0dcbe498f4f497 Intel does not consider SOF ready on these platforms yet. https://github.com/thesofproject/linux/pull/1382#discussion_r344755772 The following two lines that were just added in debian/config/amd64/config need to be removed: CONFIG_SND_SOC_SOF_BAYTRAIL_SUPPORT=y CONFIG_SND_SOC_SOF_BROADWELL_SUPPORT=y This is applicable to sid, bullseye, and buster-backports. Thank you. diff --git a/debian/config/amd64/config b/debian/config/amd64/config index 1e35491..161a760 100644 --- a/debian/config/amd64/config +++ b/debian/config/amd64/config @@ -295,8 +295,6 @@ CONFIG_SND_SOC_SOF_ACPI=m ## file: sound/soc/sof/intel/Kconfig ## CONFIG_SND_SOC_SOF_INTEL_TOPLEVEL=y -CONFIG_SND_SOC_SOF_BAYTRAIL_SUPPORT=y -CONFIG_SND_SOC_SOF_BROADWELL_SUPPORT=y CONFIG_SND_SOC_SOF_MERRIFIELD_SUPPORT=y CONFIG_SND_SOC_SOF_APOLLOLAKE_SUPPORT=y CONFIG_SND_SOC_SOF_GEMINILAKE_SUPPORT=y
Bug#940726: linux-source-5.2: Enable SOF audio driver and back-port fixes required to 5.2 kernel
On 11/10/19 1:05 PM, David Ward wrote: Unfortunately, this has caused a regression. The SST and SOF drivers cannot both be enabled for the same Intel platform in the kernel configuration, according to Intel. https://bugzilla.kernel.org/show_bug.cgi?id=204237#c15 To clarify, the statement above applies to the Baytrail and Broadwell platforms (only). These lines that were just added in debian/config/amd64/config need to be removed: CONFIG_SND_SOC_SOF_BAYTRAIL_SUPPORT=y CONFIG_SND_SOC_SOF_BROADWELL_SUPPORT=y This will be enforced via Kconfig beginning in Linux 5.5-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=df7257e544faf838c3e7ad6b4e89ffe59e87f5e1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=a6955fe0e2309feeab5ec71e4b0dcbe498f4f497 The SOF drivers/firmware for the Broadwell and Baytrail platforms have issues, and Intel does not consider them ready for use in distributions yet: https://github.com/thesofproject/linux/pull/1382#discussion_r344755772 Thank you.
Bug#940726: linux-source-5.2: Enable SOF audio driver and back-port fixes required to 5.2 kernel
Unfortunately, this has caused a regression. The SST and SOF drivers cannot both be enabled for the same Intel platform in the kernel configuration, according to Intel. https://bugzilla.kernel.org/show_bug.cgi?id=204237#c15 As described in the bug, this change causes a loss of sound on the Intel Broadwell platform (and even significantly degrades system performance when attempting to play sound).
Bug#630239: netbase: add mobility-header to /etc/protocols
Package: netbase Version: 4.45 Severity: wishlist Please add protocol 135 (Mobility Header for IPv6) to /etc/protocols. This entry is registered by IANA and is labeled as mobility-header in FreeBSD and NetBSD's /etc/protocols file. iproute2's xfrm selectors have special handling for this protocol, and this change will allow it to be specified by name instead of number at the command line. -- System Information: Debian Release: squeeze/sid APT prefers natty-updates APT policy: (500, 'natty-updates'), (500, 'natty-security'), (500, 'natty') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-8-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages netbase depends on: ii initscripts2.87dsf-4ubuntu23 scripts for initializing and shutt ii lsb-base 4.0-0ubuntu11 Linux Standard Base 4.0 init scrip ii upstart [upstart-job] 0.9.7-1 event-based init daemon Versions of packages netbase recommends: ii ifupdown 0.6.10ubuntu4 high level tools to configure netw netbase suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#271769: kernel-image-2.6.8-1-k7-smp: ATA detect failed on my AMD768 mb
I have this same problem, accept its only with the 2.6.8-3-k7 kernel and its a different chipset. I resolved it by installing the 2.6.8-3-686 kernel and all IDE disks detected correctly. I could, however, get the disks to be detected, if once I booted up off my SCSI disks I ran fdisk on each HDD and then simply quit. It seemed to turn them on. Not a very practical solution though. Regards David Ward aka DaveQB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
