Bug#1050588: bookworm-pu: package nsis/3.08-3+deb12u1

[Didier 'OdyX' Raboud]

Control: tag -1 -moreinfo

Le lundi, 8 avril 2024, 12.16:34 h CEST Christian Franke a écrit :
> Jonathan Wiltshire wrote:
> > ...
> > Thanks. The bug #1050288 isn't fixed in unstable according to the BTS,
> > which is a requirement. What's the status?
> 
> The problem described in #1050288 does not longer occur since NSIS 3.09.
> The problem appeared in Debian 12 because the Mingw-w64 toolchain now
> enables ASLR (and therefore emits relocation information) by default but
> NSIS does not support relocation information. NSIS upstream addressed
> this in the build recipes of 3.09.
> 
> I could confirm that this has the desired effect:
> In the smartmontools project, we use a Debian 12 based docker image for
> reproducible CI builds (https://builds.smartmontools.org/). After
> forcibly upgrading NSIS to 3.09 from Debian trixie, the problem
> disappeared. Here the related commit:
> https://github.com/smartmontools/docker-build/commit/9b231f0
> 
> Therefore I guess that #1050288 is also fixed in unstable.

I've just now marked it as fixed. Sorry I hadn't checked that the bug was in 
the correct state.

All lights should now be green.

Best,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1068458: netdata: build and ship netdata-plugin-systemd-journal

[Didier 'OdyX' Raboud]

Source: netdata
Version: 1.44.3-2
Severity: wishlist

Dear Maintainer,

it would be really useful to have netdata-plugin-systemd-journal,
especially as a way to circumvent their future requirement to rely on
their cloud offer:
https://github.com/netdata/netdata/discussions/16136#discussioncomment-9014755

I think it mostly boils down to build-depending on libsystemd-dev and
shipping the plugin somewhere.

Happy to help; best,
OdyX

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

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1050588: bookworm-pu: package nsis/3.08-3+deb12u1

[Didier 'OdyX' Raboud]

Le samedi, 3 février 2024, 10.46:29 h CET Adam D. Barratt a écrit :
> On Sat, 2024-02-03 at 10:33 +0100, Thomas Gaugler wrote:
> > I am the maintainer of Nullsoft Scriptable Install System (NSIS) and
> > propose the changes committed into the debian/bookworm branch on the
> > 27th January 2024 to be released as updated nsis 3.08-3+deb12u1
> > packages
> > ().
> 
> Thanks, but you've still not attached a debdiff of a prepared package,
> as requsted. Pointers to git are useful, but they're not the same as an
> actual package debdiff, which sometimes reveals changes that aren't
> immediately obvious from git.
> 
> (A debdiff attached to the bug is also there in perpetuity.)

Here comes the debdiff as I would upload it.

Thanks for the reminder.

Best,
OdyXdiff -Nru nsis-3.08/debian/changelog nsis-3.08/debian/changelog
--- nsis-3.08/debian/changelog	2022-08-15 07:58:35.0 +0200
+++ nsis-3.08/debian/changelog	2024-02-05 11:18:05.0 +0100
@@ -1,3 +1,12 @@
+nsis (3.08-3+deb12u1) bookworm; urgency=medium
+
+  * Cherry-pick upstream commits to fix CVE-2023-37378 (Closes: #1040880)
+  * Use common options for nsis-doc installation
+  * Exclude Debian revison suffix from VER_REVISION
+  * Backport upstream commit to disable stub relocations (Closes: #1050288)
+
+ -- Thomas Gaugler   Mon, 05 Feb 2024 11:18:05 +0100
+
 nsis (3.08-3) unstable; urgency=medium
 
   [ Thomas Gaugler ]
diff -Nru nsis-3.08/debian/patches/CVE-2023-37378_Don-t-allow-everyone-to-delete.patch nsis-3.08/debian/patches/CVE-2023-37378_Don-t-allow-everyone-to-delete.patch
--- nsis-3.08/debian/patches/CVE-2023-37378_Don-t-allow-everyone-to-delete.patch	1970-01-01 01:00:00.0 +0100
+++ nsis-3.08/debian/patches/CVE-2023-37378_Don-t-allow-everyone-to-delete.patch	2024-02-05 11:18:05.0 +0100
@@ -0,0 +1,27 @@
+Origin: upstream, https://github.com/kichik/nsis/commit/409b5841479c44fbf33a6ba97c1146e46f965467.patch
+Bug: https://sf.net/p/nsis/bugs/1296
+Bug-Debian: https://bugs.debian.org/1040880
+
+From 409b5841479c44fbf33a6ba97c1146e46f965467 Mon Sep 17 00:00:00 2001
+From: Anders 
+Date: Wed, 21 Jun 2023 23:38:48 +
+Subject: [PATCH] Don't allow everyone to delete the uninstaller directory
+
+git-svn-id: https://svn.code.sf.net/p/nsis/code/NSIS/trunk@7396 212acab6-be3b-0410-9dea-997c60f758d6
+---
+ Source/exehead/util.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Source/exehead/util.c b/Source/exehead/util.c
+index ba682f6f75..634d4a69f8 100644
+--- a/Source/exehead/util.c
 b/Source/exehead/util.c
+@@ -62,7 +62,7 @@ const UINT32 g_restrictedacl[] = {
+   0x1000, // ACCESS_ALLOWED_ACE:ACCESS_MASK: GENERIC_ALL
+   0x0201, 0x0500, 0x0020, 0x0220, // ACCESS_ALLOWED_ACE:SID (BUILTIN\Administrators) NOTE: GetAdminGrpSid() relies on this being the first SID in the ACL
+   0x00140300, // ACCESS_ALLOWED_ACE:ACE_HEADER (ACCESS_ALLOWED_ACE_TYPE, CONTAINER_INHERIT_ACE|OBJECT_INHERIT_ACE)
+-  0x00130041, // ACCESS_ALLOWED_ACE:ACCESS_MASK: DELETE|READ_CONTROL|SYNCHRONIZE|FILE_DELETE_CHILD|FILE_LIST_DIRECTORY
++  0x001200c1, // ACCESS_ALLOWED_ACE:ACCESS_MASK: SYNCHRONIZE|READ_CONTROL|FILE_LIST_DIRECTORY|FILE_DELETE_CHILD|FILE_READ_ATTRIBUTES
+   0x0101, 0x0100, 0x // ACCESS_ALLOWED_ACE:SID (WORLD\Everyone)
+ };
+ 
diff -Nru nsis-3.08/debian/patches/CVE-2023-37378_Don-t-delete-old-uninstaller.patch nsis-3.08/debian/patches/CVE-2023-37378_Don-t-delete-old-uninstaller.patch
--- nsis-3.08/debian/patches/CVE-2023-37378_Don-t-delete-old-uninstaller.patch	1970-01-01 01:00:00.0 +0100
+++ nsis-3.08/debian/patches/CVE-2023-37378_Don-t-delete-old-uninstaller.patch	2024-02-05 11:18:05.0 +0100
@@ -0,0 +1,32 @@
+Origin: upstream, https://github.com/kichik/nsis/commit/c40cf78994e74a1a3a381a850c996b251e3277c0.patch
+Bug: https://sf.net/p/nsis/bugs/1296
+Bug-Debian: https://bugs.debian.org/1040880
+
+From c40cf78994e74a1a3a381a850c996b251e3277c0 Mon Sep 17 00:00:00 2001
+From: Anders 
+Date: Sat, 3 Jun 2023 15:10:54 +
+Subject: [PATCH] Don't delete old uninstaller if it points somewhere else
+
+git-svn-id: https://svn.code.sf.net/p/nsis/code/NSIS/trunk@7394 212acab6-be3b-0410-9dea-997c60f758d6
+---
+ Source/exehead/Main.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/Source/exehead/Main.c b/Source/exehead/Main.c
+index 78ff558c6e..e39c631671 100644
+--- a/Source/exehead/Main.c
 b/Source/exehead/Main.c
+@@ -376,10 +376,10 @@ EXTERN_C void NSISWinMainNOCRT()
+ 
+ if (ec)
+ {
+-  // Delete previous uninstaller
+-  if (DeleteFile(unexe))
++  // Delete previous uninstaller (if it is safe to do so)
++  if (!(GetFileAttributes(unexe) & FILE_ATTRIBUTE_REPARSE_POINT) && DeleteFile(unexe))
+   {
+-myDelete(state_temp_dir, DEL_DIR|DEL_RECURSE);
++myDelete(state_temp_dir, DEL_DIR);
+ if 

Bug#1060006: ITP: brpc -- Apache's brpc - Industrial-grade RPC framework

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: brpc
  Version : 1.7.0
  Upstream Contact: d...@brpc.apache.org
* URL : https://brpc.apache.org/
* License : Apache-2.0
  Programming Lang: C++
  Description : Industrial-grade RPC
 Apache bRPC is often used in high performance systems such as Search,
 Storage, Machine learning, Advertisement, Recommendation, etc

(the short and long descriptions' are really bad; suggestions welcome!

In the context of packaging typesense /
https://github.com/typesense/typesense/, it looks like brpc is needed
too, so here I come.

The currently quite messy packaging is over at
https://salsa.debian.org/typesense-team/brpc and I really welcome any
help to make that a clean addition to Debian!

Bug#1058699: ITP: blupimania -- Blupimania - A mind boggling (brain twisting) game of logic

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 
X-Debbugs-Cc: debian-de...@lists.debian.org

 Package name: blupimania
 Version : 1.6.2
 Upstream Contact: Mathieu Schroeter 
 URL : https://blupi.org/mania/
 License : GPLv3
 Programming Lang: C
 Description : Blupimania - A mind boggling (brain twisting) game of logic

 Blupi comes out of a hole holding on to a balloon. Unfortunately he
 let's it blow away. Blupi is lost, he turns to the left or the right
 and does various unpredictable things of his own. The object of the
 game is to help him find another balloon, so that he can move on to the
 next riddle.

This 1994-1995 game, first released for Smaky's, was ported to DOS in
1996, then the source code was lost. It got found again on a CD-R in
2021, then ported to SDL, which now makes it available natively on
GNU/Linux.  That piece of history can now be made avaiable to Debian!

Bug#1053342: debian/README.md is a truncated copy of upstream's

[Didier 'OdyX' Raboud]

Package: purple-lurch
Version: 0.7.0-2
Severity: wishlist
Tags: newcomer

The fix for #989590 duplicated (and truncated) upstream's README.md file
"as" debian/README.md, which is now a copy, with some Debian-specific
changes. That should rather be implemented as a patch on the upstream
file.

Bug#1037176: ITP: typesense -- Fast, typo-tolerant search engine

[Didier 'OdyX' Raboud]

Le mercredi, 7 juin 2023, 10.10:50 h CEST Bastien ROUCARIES a écrit :
> Le mer. 7 juin 2023 à 08:00, Didier 'OdyX' Raboud  a
> 
> écrit :
> > Package: wnpp
> > Severity: wishlist
> > Owner: Didier 'OdyX' Raboud 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> > 
> >   Package name: typesense
> >   Version : 0.24.1
> >   Upstream Contact: TypeSense team 
> >   URL : https://typesense.org
> >   License : GPL-3
> >   Programming Lang: C++
> > 
> > Typo-tolerant search engine optimized for instant search-as-you-type
> > experiences and developer productivity. Push data to it and then allow
> > users to search through this data via a search UI in a site or app.
> > 
> > I plan to package this under https://salsa.debian.org/debian/typesense.
> > If there's a matching packaging team, more than happy to move there!
> 
> It is useful for dyslexic people. Maybe accessibilty related team ?

It's more of a web-oriented / mobile search engine than an accessiblity 
facilitator.

That said, I've sadly noted that it build-depends on several more un-packaged 
software, namely Apache brpc (which typesense forks), braft (same), lru-cache 
(https://github.com/goldsborough/lru-cache/, never released), libfor (https://
github.com/cruppstahl/libfor, never released, little-endian only).

That'll be (much) more work than I expected, and I'll ponder on how to move 
forward here.

Best,
OdyX

Bug#1037176: ITP: typesense -- Fast, typo-tolerant search engine

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 
X-Debbugs-Cc: debian-de...@lists.debian.org

  Package name: typesense
  Version : 0.24.1
  Upstream Contact: TypeSense team 
  URL : https://typesense.org
  License : GPL-3
  Programming Lang: C++

Typo-tolerant search engine optimized for instant search-as-you-type
experiences and developer productivity. Push data to it and then allow
users to search through this data via a search UI in a site or app.

I plan to package this under https://salsa.debian.org/debian/typesense.
If there's a matching packaging team, more than happy to move there!

Bug#1032240: akonadi server fails to start since it cannot connect to mysql database

[Didier 'OdyX' Raboud]

Control: tags -1 +moreinfo
Control: severity -1 important

Le vendredi, 10 mars 2023, 21.04:56 h CEST Patrick Franz a écrit :
> the issue is connected to MariaDB when upgrading after the shutdown was
> not clean, see https://bugs.debian.org/cgi-bin/bugreport.cgi?
> bug=1032047#40
> 
> We are trying to find a solution for this.

Enrique; the mentionned bug is now fixed; do you still experience your issue?

Best,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1032383: loopback interface (lo) no longer ignored

[Didier 'OdyX' Raboud]

Package: network-manager
Version: 1.42.2-2
Severity: normal

Hello there,

the loopback interface seems no longer ignored by NetworkManager by
default;

$ LANG=C nmcli | grep -A5 ^lo
lo: connected (externally) to lo
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
inet4 127.0.0.1/8
inet6 ::1/128

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/e8618f03d7d8735946a82de8ce4257dd92328b20

This is apparently a new feature of NM 1.42, but I'm arguing that in
most usual cases, having 'lo' appear (as it appears in KDE's Plasma NM
applet for example) is quite confusing to most users who will never
customize anything with regards to the 'lo' interface.

I'd propose that src:network-manager adds a conffile with that content:

[keyfile]
unmanaged-devices=interface-name:lo

This would let the loopback interface be ignored, while allowing experts
needing this to get the new 'lo' managed interface.

Best,

OdyX

-- System Information:
Debian Release: 12.0
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager depends on:
ii  adduser 3.131
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  libaudit1   1:3.0.9-1
ii  libbluetooth3   5.66-1
ii  libc6   2.36-8
ii  libcurl3-gnutls 7.88.1-2
ii  libglib2.0-02.74.6-1
ii  libgnutls30 3.7.9-1
ii  libjansson4 2.14-2
ii  libmm-glib0 1.20.4-1
ii  libndp0 1.8-1
ii  libnewt0.52 0.52.23-1+b1
ii  libnm0  1.42.2-2
ii  libpsl5 0.21.2-1
ii  libreadline88.2-1.3
ii  libselinux1 3.4-1+b5
ii  libsystemd0 252.6-1
ii  libteamdctl01.31-1
ii  libudev1252.6-1
ii  policykit-1 122-3
ii  polkitd 122-3
ii  udev252.6-1

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  libpam-systemd   252.6-1
ii  modemmanager 1.20.4-1
ii  ppp  2.4.9-1+1.1+b1
ii  wireless-regdb   2022.06.06-1
ii  wpasupplicant2:2.10-12

Versions of packages network-manager suggests:
ii  iptables   1.8.9-2
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-P1-1.1

-- no debconf information

Bug#1031690: Regression in wayland mixed DPI setups

[Didier 'OdyX' Raboud]

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=465733
Control: tags -1 +fixed-upstream

It looks like this was fixed in https://bugs.kde.org/show_bug.cgi?id=465733, 
in the 5.27.1 Plasma release.

TIA, best,

OdyX

Le lundi, 20 février 2023 18.10:58 h CET, vous avez écrit :
> Package: plasma-workspace-wayland
> Version: 4:5.27.0-1
> Severity: important
> Tags: upstream
> 
> Hello there,
> 
> it looks like there's a regression in mixed DPI setups (one hiDPI screen
> at "150%", a lower-DPI screen at "100%"), on Wayland, for some non-KDE
> applications. In my case, flatpak firefox has too small tabs depending
> on which screen it initially got launched.
> 
> This was working much better pre-5.27.

-- 
OdyX

Bug#1031690: Regression in wayland mixed DPI setups

[Didier 'OdyX' Raboud]

Package: plasma-workspace-wayland
Version: 4:5.27.0-1
Severity: important
Tags: upstream

Hello there,

it looks like there's a regression in mixed DPI setups (one hiDPI screen
at "150%", a lower-DPI screen at "100%"), on Wayland, for some non-KDE
applications. In my case, flatpak firefox has too small tabs depending
on which screen it initially got launched.

This was working much better pre-5.27.

It looks like upstream is on this;
* https://bugs.kde.org/show_bug.cgi?id=443215
* https://bugs.kde.org/show_bug.cgi?id=465733

But I couldn't really identify directly which patch, and on which
software, to test.

Happy to build/test here.

Best,
OdyX

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-workspace-wayland depends on:
ii  kpackagetool5 5.103.0-1
ii  kwayland-integration  5.27.0-1
ii  kwin-wayland  4:5.27.0-1
ii  libc6 2.36-8
ii  libkf5configcore5 5.103.0-1
ii  libkf5configgui5  5.103.0-1
ii  libkf5configwidgets5  5.103.0-1
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5guiaddons5  5.103.0-1
ii  libkf5kcmutils5   5.103.0-1
ii  libkf5kiogui5 5.103.0-1
ii  libkf5notifications5  5.103.0-1
ii  libkf5package55.103.0-1
ii  libkf5service-bin 5.103.0-1
ii  libkf5service55.103.0-1
ii  libkworkspace5-5  4:5.27.0-1
ii  libphonon4qt5-4   4:4.11.1-4
ii  libqt5core5a  5.15.8+dfsg-2
ii  libqt5dbus5   5.15.8+dfsg-2
ii  libqt5gui55.15.8+dfsg-2
ii  libstdc++612.2.0-14
ii  phonon4qt54:4.11.1-4
ii  plasma-workspace  4:5.27.0-1
ii  qtwayland55.15.8-2

plasma-workspace-wayland recommends no packages.

plasma-workspace-wayland suggests no packages.

-- no debconf information

Bug#1029775: pyhst2: FTBFS with setuptools 66: Invalid version: '2020ca'

[Didier 'OdyX' Raboud]

Le lundi, 30 janvier 2023, 18.59:04 h CET Andreas Beckmann a écrit :
> On 28/01/2023 18.09, Didier 'OdyX' Raboud wrote:
> > So. I have a much shorter (and better) patch, that I'll upload to
> > DELAYED/5 in few minutes.
> 
> Thanks alot.

No problem.

Should I push it to unstable?

> There is now a new lintian error (not caused by your patch,
> but by some changed B-D). Since you were looking into
> the python building bits, perhaps you have an idea where this
> is originating from? Notice the difference lib vs. lib64

The code in setup.py does non-Debian stuff around guessing library paths.

A possible patch is attached, I've also pushed it on a branch:

https://salsa.debian.org/science-team/pyhst2/-/merge_requests/2

I have no idea if the resulting package works though.

Best,
OdyXDrop all CUDA-specific library path search

Fixes the superfluous /usr/lib or /usr/lib64 paths in RUNPATH

Author: Didier Raboud 
Origin: vendor

--- a/setup.py
+++ b/setup.py
@@ -261,15 +261,6 @@ def do_pyhst():
 
 cudaconfig = {'home':home, 'nvcc':nvcc,
   'include': pjoin(home, 'include')}
-lib =  pjoin(home, 'lib')
-if os.path.exists(lib+"64") andmath.log(sys.maxsize)/math.log(2) > 60: ##sys.maxint == 2**63-1:
-cudaconfig["lib"] = lib+"64"
-elif os.path.exists(lib+"32") and math.log(sys.maxsize)/math.log(2) < 60:
-cudaconfig["lib"] = lib+"32"
-elif os.path.exists(lib):
-cudaconfig["lib"] = lib
-else:
-print(("No cuda library found "))
 for key, val in cudaconfig.items():
 if not os.path.exists(val):
 raise EnvironmentError('The CUDA %s path could not be located in %s' % (key, val))
@@ -469,9 +460,7 @@ def do_pyhst():
 
 module = Extension('PyHST2_'+version+'/libgputomo',
 sources=sources,
-library_dirs=[CUDA['lib']],
 libraries=['cudart', "cublas", "cuda", "cufft", hdf5_lib],
-runtime_library_dirs=[CUDA['lib']],
 # this syntax is specific to this build system
 # we're only going to use certain compiler args with nvcc and not with gcc
 # the implementation of this trick is in customize_compiler() below
@@ -495,11 +484,8 @@ def do_pyhst():
 module = Extension(name='PyHST2_'+version+'.unsharp3D',
sources=sources ,
depends=[],
-   library_dirs=[CUDA['lib']],
libraries=['cudart','QtGui','QtCore','cudart','tiff'],

-   runtime_library_dirs=[CUDA['lib']],
-   
extra_compile_args={'gcc': ["-std=c99","-g","-fPIC", "-O3","-Wall"],
'nvcc': CUDA["arch"] + [ "--compiler-options",  "-fPIC", "-O3", "-g","-D_FORCE_INLINES" ]},
include_dirs=[numpy.get_include(), CUDA['include'], 'PyHST/Cspace',"/usr/include/qt4"] )
@@ -518,9 +504,7 @@ def do_pyhst():
 global version
 module = Extension('PyHST2_'+version+'/libprojection',
sources=["PyHST/Cspace/c_hst_project_1over.cu"],
-   library_dirs=[CUDA['lib']],
libraries=['cudart', "cuda", "cufft"],
-   runtime_library_dirs=[CUDA['lib']],
extra_compile_args={'gcc': ["-fPIC", "-O3"],
'nvcc': CUDA["arch"] + ["--compiler-options", "-fPIC,-O3" ,"-D_FORCE_INLINES"]},
include_dirs=[numpy.get_include(), CUDA['include'], 'PyHST/Cspace']+ hdf5_dirs)
@@ -542,9 +526,7 @@ def do_pyhst():
 
 module = Extension('PyHST2_'+version+'/libwavelets',
sources=sources,
-   library_dirs=[CUDA['lib']],
libraries=["cudart", "cuda", "cublas"],
-   runtime_library_dirs=[CUDA['lib']],
extra_compile_args={'gcc': ["-fPIC", "-O3"],
'nvcc': CUDA["arch"] + ["--compiler-options", "-fPIC,-O3" ,"-D_FORCE_INLINES"]},
include_dirs=[numpy.get_include(), CUDA['include'], 'PyHST/Cspace'])


signature.asc
Description: This is a digitally signed message part.

Bug#1026568: python-distutils-extra: FTBFS: AssertionError: "diff -x foo.pot -x '*.pyc' -Nur /tmp/tmp[1578 chars]n+\n" != ''

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le dimanche, 29 janvier 2023, 12.32:37 h CET Didier 'OdyX' Raboud a écrit :
> I've also pushed this to
> https://salsa.debian.org/python-team/packages/python-distutils-extra/-/merg
> e_requests/7 for review, but given the freeze and as I've tested building
> python-apt with that code and don't see any regressions, I'll upload a Team
> upload to DELAYED/5 later today.

Eh. With tumbleweed's "LGTM" on IRC, I just went ahead and uploaded this.

It looks like the autopkgtest might be failing, so I'll keep an eye on this if 
it fails or delays migration.


Regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1026568: python-distutils-extra: FTBFS: AssertionError: "diff -x foo.pot -x '*.pyc' -Nur /tmp/tmp[1578 chars]n+\n" != ''

[Didier 'OdyX' Raboud]

Control: tags -1 +patch -help

Ok. It turns out staying at a BSP helps finding the brain space to fix such 
things.

Le dimanche, 29 janvier 2023, 00.01:26 h CET Didier 'OdyX' Raboud a écrit :
> The crux of the issue is that python3-setuptools from 54.0.0
> (https://setuptools.pypa.io/en/latest/history.html#v54-0-0) does _not_ build
> the .egg-info as single file, but _only_ as directory [0].
> 
> This has the direct consequence that all tests fail for either of these
> reasons:
> * the .egg-info is not a file, and cannot be compared with the expected
> version
> * the .egg-info directory is not cleaned in clean() , hence the snapshot-vs-
> result directory comparison is always going to flag the .egg-info directory
> as resulting cruft.

Here comes a patch to fix 1 issue in the code itself, and fix all the tests to 
match that new reality.

I've also pushed this to 
https://salsa.debian.org/python-team/packages/python-distutils-extra/-/merge_requests/7
 for review, but given the freeze and as 
I've tested building python-apt with that code and don't see any regressions, 
I'll upload a Team upload to DELAYED/5 later today.

Best,

OdyXdiff --git a/DistUtilsExtra/auto.py b/DistUtilsExtra/auto.py
index 7b3cce1..6376c5e 100644
--- a/DistUtilsExtra/auto.py
+++ b/DistUtilsExtra/auto.py
@@ -85,6 +85,9 @@ def setup(**attrs):
 for d in ignore_dirs:
 if f.startswith(d + os.path.sep):
 src.remove(f)
+# Also remove files from the .egg-info directory
+if '.egg-info/' in f:
+src.remove(f)
 
 __cmdclass(attrs)
 __modules(attrs, src)
diff --git a/debian/changelog b/debian/changelog
index 6147f2f..7209f57 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+python-distutils-extra (2.47.1) UNRELEASED; urgency=medium
+
+  * Adapt tests to distutils 54+; fixes FTBFS (Closes: #1026568)
+
+ -- Didier Raboud   Sun, 29 Jan 2023 12:05:51 +0100
+
 python-distutils-extra (2.47) unstable; urgency=medium
 
   * Team upload.
diff --git a/test/auto.py b/test/auto.py
index 61286d1..17bb81a 100755
--- a/test/auto.py
+++ b/test/auto.py
@@ -51,6 +51,17 @@ setup(
 self.snapshot = None
 self.install_tree = None
 
+def assert_egg_info_directory_is_present_and_well(self):
+'''Check that no .egg-info file is present, that an egg_info directory is present and that it contains the expected files'''
+
+f = self.installed_files()
+# All files are in an .egg-info directory; no .egg-info file is created
+self.assertFalse(any([_.endswith('.egg-info') for _ in f ]))
+# There are 4 files in said directory
+self.assertEqual(len(f), 4)
+# Check that the four exist
+self.assertTrue(all([any([_.endswith(c) for c in ['PKG-INFO', 'SOURCES.txt', 'dependency_links.txt', 'top_level.txt']]) for _ in f]))
+
 #
 # actual tests come here
 #
@@ -63,10 +74,7 @@ setup(
 self.assertEqual(s, 0)
 self.assertNotIn('following files are not recognized', o)
 
-f = self.installed_files()
-# just installs the .egg_info
-self.assertEqual(len(f), 1)
-self.assertTrue(f[0].endswith('.egg-info'))
+self.assert_egg_info_directory_is_present_and_well()
 
 def test_vcs(self):
 '''Ignores revision control files'''
@@ -81,10 +89,7 @@ setup(
 self.assertEqual(s, 0)
 self.assertNotIn('following files are not recognized', o)
 
-f = self.installed_files()
-# just installs the .egg_info
-self.assertEqual(len(f), 1)
-self.assertTrue(f[0].endswith('.egg-info'))
+self.assert_egg_info_directory_is_present_and_well()
 
 def test_modules(self):
 '''Python modules'''
@@ -157,7 +162,7 @@ Exec=/usr/bin/foo-gtk
 self.assertIn('\n  stuff/super.service\n', o)
 
 f = self.installed_files()
-self.assertEqual(len(f), 4) # 3 D-BUS files plus .egg-info
+self.assertEqual(len(f), 7) # 3 D-BUS files plus 4 files in egg-info directory
 self.assertIn('/etc/dbus-1/system.d/com.example.foo.conf', f)
 self.assertIn('/usr/share/dbus-1/system-services/com.example.foo.service', f)
 self.assertIn('/usr/share/dbus-1/services/com.example.foo.gui.service', f)
@@ -178,7 +183,7 @@ Exec=/usr/bin/foo-gtk
 self.assertEqual(s, 0)
 
 f = self.installed_files()
-self.assertEqual(len(f), 3) # 2 schema files plus .egg-info
+self.assertEqual(len(f), 6) # 2 schema files plus 4 files in .egg-info directory
 self.assertIn('/usr/share/glib-2.0/schemas/org.test.myapp.gschema.xml', f)
 self.assertNotIn('gschemas.compiled', '\n'.join(f))
 
@@ -201,7 +206,7 @@ def add_info(report):
 self.assertNotIn('following files are not recognized', o)
 
 f = self.installed_files()
-self.assertEqual(len(f), 3, f) # 2 hook files plus .egg-info
+self.assertEqual(le

Bug#1026568: python-distutils-extra: FTBFS: AssertionError: "diff -x foo.pot -x '*.pyc' -Nur /tmp/tmp[1578 chars]n+\n" != ''

[Didier 'OdyX' Raboud]

Control: tags -1 +confirmed +help

Hello there from the St-Cergue BSP where I've taken a look at this RC bug.

I can confirm this still FTBFS, and doesn't in stable, so let's check why.

The crux of the issue is that python3-setuptools from 54.0.0
(https://setuptools.pypa.io/en/latest/history.html#v54-0-0) does _not_ build 
the .egg-info as single file, but _only_ as directory [0].

This has the direct consequence that all tests fail for either of these 
reasons:
* the .egg-info is not a file, and cannot be compared with the expected 
version
* the .egg-info directory is not cleaned in clean() , hence the snapshot-vs-
result directory comparison is always going to flag the .egg-info directory as 
resulting cruft.

I've trimmed down the report below with an example result, which clearly shows 
the above two things.

Btw, from the FTBFS build directory, the fastest way to reproduce this is to 
run:

 LC_ALL=C LANGUAGE= LANG=C PYTHONPATH=. python3.10 test/auto.py -v -k empty -f


So. python-distutils-extra is broken by src:setuptools which is not going to 
revert this. python3-distutils-extra has 34 reverse Build-Depends, including 
python-apt, which makes it a "key package". Even if the B-D from python-apt 
can be amended, I also identify unattended-upgrades, software-properties and 
command-not-found. It looks like this won't be easy to remove from testing; we 
need to fix it.

Suggestions on the angle to use to tackle this welcome!

Best,

OdyX


[0] Also, distutils is deprecated "soon", so all this should get nuked post-
bookworm, but that's a discussion for another time.

Le mardi, 20 décembre 2022, 18.23:15 h CET Lucas Nussbaum a écrit :
> Source: python-distutils-extra
> Version: 2.47
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221220 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > # run tests with all supported python 2 and 3 versions
> > set -e; for python in `py3versions -s`; do \
> > 
> >   echo "-- Running tests with $python "; \
> >   LC_ALL=C LANGUAGE= LANG=C PYTHONPATH=. $python test/auto.py -v; \
> > 
> > done
> > -- Running tests with python3.11 
> > (...)
> > test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py) ... FAIL
> > test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py) ... FAIL

(...)

> > ==
> > FAIL: test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py)
> > --
> > 
> > Traceback (most recent call last):
> >   File "/<>/test/auto.py", line 68, in test_empty
> >   
> > self.assertEqual(len(f), 1)
> > 
> > AssertionError: 4 != 1
> > 
> > ==
> > FAIL: test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py)
> > --
> > 
> > Traceback (most recent call last):
> >   File "/<>/test/auto.py", line 43, in tearDown
> >   
> > self.assertEqual(cruft, '', 'no cruft after cleaning:\n' + cruft)
> > 
> > AssertionError: "diff -x foo.pot -x '*.pyc' -Nur /tmp/tmp[1578 chars]n+\n"
> > != '' - diff -x foo.pot -x '*.pyc' -Nur
> > /tmp/tmp56zs21t4/s/foo.egg-info/PKG-INFO
> > /tmp/tmp15hh51oe/foo.egg-info/PKG-INFO - ---
> > /tmp/tmp56zs21t4/s/foo.egg-info/PKG-INFO1970-01-01 
00:00:00.0
> > + - +++ /tmp/tmp15hh51oe/foo.egg-info/PKG-INFO  2022-12-20
> > 09:38:33.086490908 + - @@ -0,0 +1,8 @@
> > - +Metadata-Version: 2.1
> > - +Name: foo
> > - +Version: 0.1
> > - +Summary: Test suite package
> > - +Home-page: https://foo.example.com
> > - +Author: Martin Pitt
> > - +Author-email: martin.p...@example.com
> > - +License: GPL v2 or later
> > - diff -x foo.pot -x '*.pyc' -Nur
> > /tmp/tmp56zs21t4/s/foo.egg-info/SOURCES.txt
> > /tmp/tmp15hh51oe/foo.egg-info/SOURCES.txt - ---
> > /tmp/tmp56zs21t4/s/foo.egg-info/SOURCES.txt 1970-01-01 
00:00:00.0
> > + - +++ /tmp/tmp15hh51oe/foo.egg-info/SOURCES.txt   2022-12-20
> > 09:38:33.090490943 + - @@ -0,0 +1,5 @@
> > - +setup.py
> > - +foo.egg-info/PKG-INFO
> > - +foo.egg-info/SOURCES.txt
> > - +foo.egg-info/dependency_links.txt
> > - +foo.egg-info/top_level.txt
> > - \ No newline at end of file
> > - diff -x foo.pot -x '*.pyc' -Nur
> > /tmp/tmp56zs21t4/s/foo.egg-info/dependency_links.txt
> > /tmp/tmp15hh51oe/foo.egg-info/dependency_links.txt - ---
> > /tmp/tmp56zs21t4/s/foo.egg-info/dependency_links.txt1970-01-01
> > 00:00:00.0 + - +++
> > /tmp/tmp15hh51oe/foo.egg-info/dependency_links.txt  2022-12-20
> > 09:38:33.086490908 + - @@ -0,0 +1 @@
> > - +
> > - diff -x foo.pot -x '*.pyc' -Nur
> > 

Bug#1028638: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call

[Didier 'OdyX' Raboud]

Le vendredi, 27 janvier 2023, 17.50:40 h CET Martin a écrit :
> Control: tags -1 + patch
> 
> So far only good reports about the patch by Sebastian ,
> applied in experimental.

From the St-Cergue BSP; could confirm that the crash is fixed by installing 
libproxy1v5 from experimental. Looking forward to getting this fixed in 
unstable!

Best,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1029775: pyhst2: FTBFS with setuptools 66: Invalid version: '2020ca'

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

So. I have a much shorter (and better) patch, that I'll upload to DELAYED/5 in 
few minutes.

See the attached patch, which consists of setting the setup.py version to a 
PEP-440-compliant Debian-specific version (which I have confirmed to sort 
bigger than "2020ca"). This fixes the FTBFS.

I've also pushed this as an MR on your VCS repository there:

https://salsa.debian.org/science-team/pyhst2/-/merge_requests/1

Best,

OdyX

Le samedi, 28 janvier 2023, 17.21:35 h CET Didier 'OdyX' Raboud a écrit :
> Hello there,
> 
> while at St-Cergue's BSP, I took a look at this issue, so here are my
> findings.
> 
> * I can confirm it fails to build from source in a main+contrib+non-free
> cowbuilder.
> 
> * This FTBFS is the consequence of a new requirement from setuptools; see
> this issue to get it better: https://github.com/pypa/setuptools/issues/2497
> . setuptools now imposes PEP-440-style versioning, that is, the version has
> to match this format:
> 
>   [N!]N(.N)*[{a|b|rc}N][.postN][.devN]
> 
> But pyHST2 uses the version number in some paths (such as /usr/lib/
python3/
> dist-packages/PyHST2_2020c(...) ), so it can't simply be patched to use
> "2020.3" (c ~= 3 ?). I can't login to upstream's issues tracker at
> https://gitlab.esrf.fr/mirone/pyhst2 but it's clearly something that needs
> to be fixed by a new upstream release.
> 
> The attached patch is basically a `sed 's/2020c/2021/g' -i` (also check
> aumento_versione="a" which can work, but should also be amended)  on
> concerned files. It allows to finish building, but the paths have become
> /usr/lib/python3/dist-packages/PyHST2_2021(...), which is clearly not
> upstream's intent.
> 
> I'll check if it's possible to only patch the version and not all files.
> 
> See you in a bit.
> 
> Cheers,
> 
> OdyX
> 
> Le vendredi, 27 janvier 2023, 15.37:13 h CET Andreas Beckmann a écrit :
> > Source: pyhst2
> > Version: 2020c-6
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source
> > 
> > Hi,
> > 
> > pyhst2 FTBFS with setuptools 66 that was uploaded today:
> > /usr/lib/python3/dist-packages/setuptools/dist.py:548: UserWarning: The
> > version specified ('2020ca') is an invalid version, this may not work as
> > expected with newer versions of setuptools, pip, and PyPI. Please see PEP
> > 440 for more details. warnings.warn(
> > running clean
> > removing '/build/pyhst2-2020c/.pybuild/cpython3_3.10_pyhst2/build' (and
> > everything under it) 'build/bdist.linux-x86_64' does not exist -- can't
> > clean it
> > 'build/scripts-3.10' does not exist -- can't clean it
Set a Debian-specific PEP-440-compliant version: 2020.3.20230128

This is needed since setuptools 66.0

Bug-Debian: https://bugs.debian.org/1029775
Author: Didier Raboud 
Origin: vendor

--- a/setup.py
+++ b/setup.py
@@ -88,6 +88,9 @@ global version
 global aumento_versione
 aumento_versione="a"
 
+# Debian-specific version to match PEP-440 with setuptools v66.0.0
+pep440_version = "2020.3.20230128" # 3 for c, today's date
+
 global version
 
 if DO_LINK==0:
@@ -121,7 +124,8 @@ def do_link():
 
 distrib = setup(name="pyhst2_links",
 license="GPL",
-version=version+aumento_versione,
+# Debian-specific version to fit PEP-440
+version=pep440_version,
 description=description,
 author="Alessandro Mirone",
 author_email="mir...@esrf.fr",
@@ -156,7 +160,8 @@ def do_link_unstable():
 
 distrib = setup(name="pyhst2unstable_links",
 license="GPL",
-version=version+aumento_versione,
+# Debian-specific version to fit PEP-440
+version=pep440_version,
 description=description,
 author="Alessandro Mirone",
 author_email="mir...@esrf.fr",
@@ -697,7 +702,8 @@ def do_pyhst():
 
 distrib = setup(name="PyHST2_"+version+post_fix,
 license="GPL",
-version=version+aumento_versione, ## aumenta qua versione
+# Debian-specific version to fit PEP-440
+version=pep440_version,
 description=description,
 author="Alessandro Mirone",
 author_email="mir...@esrf.fr",


signature.asc
Description: This is a digitally signed message part.

Bug#1029775: pyhst2: FTBFS with setuptools 66: Invalid version: '2020ca'

[Didier 'OdyX' Raboud]

Control: tags -1 confirmed +patch

Hello there,

while at St-Cergue's BSP, I took a look at this issue, so here are my 
findings.

* I can confirm it fails to build from source in a main+contrib+non-free 
cowbuilder.

* This FTBFS is the consequence of a new requirement from setuptools; see this 
issue to get it better: https://github.com/pypa/setuptools/issues/2497 .
setuptools now imposes PEP-440-style versioning, that is, the version has to 
match this format:

[N!]N(.N)*[{a|b|rc}N][.postN][.devN]

But pyHST2 uses the version number in some paths (such as /usr/lib/python3/
dist-packages/PyHST2_2020c(...) ), so it can't simply be patched to use 
"2020.3" (c ~= 3 ?). I can't login to upstream's issues tracker at
https://gitlab.esrf.fr/mirone/pyhst2 but it's clearly something that needs to 
be fixed by a new upstream release.

The attached patch is basically a `sed 's/2020c/2021/g' -i` (also check 
aumento_versione="a" which can work, but should also be amended)  on concerned 
files. It allows to finish building, but the paths have become 
/usr/lib/python3/dist-packages/PyHST2_2021(...), which is clearly not 
upstream's intent.

I'll check if it's possible to only patch the version and not all files.

See you in a bit.

Cheers,

OdyX

Le vendredi, 27 janvier 2023, 15.37:13 h CET Andreas Beckmann a écrit :
> Source: pyhst2
> Version: 2020c-6
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> 
> Hi,
> 
> pyhst2 FTBFS with setuptools 66 that was uploaded today:
> /usr/lib/python3/dist-packages/setuptools/dist.py:548: UserWarning: The
> version specified ('2020ca') is an invalid version, this may not work as
> expected with newer versions of setuptools, pip, and PyPI. Please see PEP
> 440 for more details. warnings.warn(
> running clean
> removing '/build/pyhst2-2020c/.pybuild/cpython3_3.10_pyhst2/build' (and
> everything under it) 'build/bdist.linux-x86_64' does not exist -- can't
> clean it
> 'build/scripts-3.10' does not exist -- can't clean it


-- 
OdyXIndex: pyhst2/PyHST/__init__.py
===
--- pyhst2.orig/PyHST/__init__.py
+++ pyhst2/PyHST/__init__.py
@@ -30,4 +30,4 @@
 # is a problem for you.
 #*/
 
-version = "2020c"
+version = "2021"
Index: pyhst2/TEST_PYHST/nonregression.py
===
--- pyhst2.orig/TEST_PYHST/nonregression.py
+++ pyhst2/TEST_PYHST/nonregression.py
@@ -67,7 +67,7 @@ casi=[   "CRAYON",  "HEIKKI",  "HELICOID
 "PATCHES_VECTORIAL",  "SINO_THRESHOLD" ]
 casi=["ID11_SNOW",  "BIG", "LENA",  "LENA_MULTIRINGS",  "MOUSSE",  "MULTIPAGANIN","NANOPOINTS",  "PATCHES_VECTORIAL",  "SINO_THRESHOLD"]
 
-LAUNCHING_INSTRUCTION  = "PyHST2_2020c  input.par"
+LAUNCHING_INSTRUCTION  = "PyHST2_2021  input.par"
 outputprefix="/home/esrf/mirone/nobackup/TEST_PYHST/RESULTS/p9/monogpu"
 # outputprefix="/tmp/TEST_PYHST/RESULTS/p9-04/"
 ###
Index: pyhst2/scripts_link/pyhst2
===
--- pyhst2.orig/scripts_link/pyhst2
+++ pyhst2/scripts_link/pyhst2
@@ -1 +1 @@
-PyHST2_2020c $*
+PyHST2_2021 $*
Index: pyhst2/scripts_link/pyhst2_info
===
--- pyhst2.orig/scripts_link/pyhst2_info
+++ pyhst2/scripts_link/pyhst2_info
@@ -1,6 +1,6 @@
 #!python
 msg = """
-The pyhst2 script launches PyHST2_2020c
+The pyhst2 script launches PyHST2_2021
 
*** PyHST2_2020a
 
Index: pyhst2/setup.py
===
--- pyhst2.orig/setup.py
+++ pyhst2/setup.py
@@ -86,7 +86,7 @@ DO_LINK  = 0
 
 global version
 global aumento_versione
-aumento_versione="a"
+aumento_versione=".1"
 
 global version
 
@@ -95,7 +95,7 @@ if DO_LINK==0:
 os.path.abspath(__file__)), "PyHST", "__init__.py"))
if l.strip().startswith("version")][0]
 else:
-version = "2020c"
+version = "2021"
 
 
 def do_link():
@@ -104,7 +104,7 @@ def do_link():
 # aumento_versione=""
 
 
-version = "2020c"
+version = "2021"
 
 packages = []
 
Index: pyhst2/stdeb_link.cfg
===
--- pyhst2.orig/stdeb_link.cfg
+++ pyhst2/stdeb_link.cfg
@@ -1,3 +1,3 @@
 [DEFAULT]
-Depends: python-pyhst2-2020c | python-pyhst2-2020c-base
-Depends3: python3-pyhst2-2020c | python3-pyhst2-2020c-base
+Depends: python-pyhst2-2021 | python-pyhst2-2021-base
+Depends3: python3-pyhst2-2021 | python3-pyhst2-2021-base


signature.asc
Description: This is a digitally signed message part.

Bug#1029046: Wayland session doesn't get back to life post-suspend

[Didier 'OdyX' Raboud]

Control: tags -1 +patch -help
Control: clone -1 -2
Control: retitle -2 Thinkpad AMD: amd_pmc module is required for correct s0ix 
(Windows mode) suspend
Control: severity -2 important

Hello there, 

My understanding is that there are two distinct bugs here; hereby splitting 
to make this clearer.

* Original bug, as retitled by Salvatore; S3 suspend is broken on some AMD
  Ryzens. This is fixed by this patch queue, also attached.
https://gitlab.freedesktop.org/superm1/linux/-/commits/mlimonci/rhbz-2162013-gitlab-2357-v4/

  In the BIOS, "S3" is "Linux mode" for suspend.

* While investigating this; it turns out modern kernels can also suspend
  on s0ix "Windows mode", but this _requires_ the `amd_pmc` module, which
  is not loaded automatically, but it really should. This doesn't look
  like an upstream bug, but rather a Debian one.

  As this only shows on Laptops with a "Windows mode" BIOS configuration
  (in a box that also shows "Linux mode"), I think it's reasonable to see
  this as a bug of only "important" level (even though not resuming from
  suspend is _bad_).

  I don't think we have seen a patch to fix this one yet though.

Best,

OdyX
Index: linux/drivers/gpio/gpiolib-acpi.c
===
--- linux.orig/drivers/gpio/gpiolib-acpi.c
+++ linux/drivers/gpio/gpiolib-acpi.c
@@ -361,7 +361,7 @@ err:
 }
 
 static bool acpi_gpio_irq_is_wake(struct device *parent,
-  struct acpi_resource_gpio *agpio)
+  const struct acpi_resource_gpio *agpio)
 {
 	unsigned int pin = agpio->pin_table[0];
 
@@ -754,7 +754,7 @@ static int acpi_populate_gpio_lookup(str
 		lookup->info.pin_config = agpio->pin_config;
 		lookup->info.debounce = agpio->debounce_timeout;
 		lookup->info.gpioint = gpioint;
-		lookup->info.wake_capable = agpio->wake_capable == ACPI_WAKE_CAPABLE;
+		lookup->info.wake_capable = acpi_gpio_irq_is_wake(>info.adev->dev, agpio);
 
 		/*
 		 * Polarity and triggering are only specified for GpioInt
@@ -1080,7 +1080,7 @@ int acpi_dev_gpio_irq_wake_get_by(struct
 dev_dbg(>dev, "IRQ %d already in use\n", irq);
 			}
 
-			if (wake_capable)
+			if (wake_capable && acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0)
 *wake_capable = info.wake_capable;
 
 			return irq;
@@ -1599,6 +1599,19 @@ static const struct dmi_system_id gpioli
 			.ignore_interrupt = "AMDI0030:00@18",
 		},
 	},
+	{
+		/*
+		 * Spurious wakeups from TP_ATTN# pin
+		 * Found in BIOS 1.7.8
+		 * https://gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1720627
+		 */
+		.matches = {
+			DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
+		},
+		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+			.ignore_wake = "ELAN0415:00@9",
+		},
+	},
 	{} /* Terminating entry */
 };
 
Index: linux/drivers/pinctrl/pinctrl-amd.c
===
--- linux.orig/drivers/pinctrl/pinctrl-amd.c
+++ linux/drivers/pinctrl/pinctrl-amd.c
@@ -365,6 +365,7 @@ static void amd_gpio_dbg_show(struct seq
 
 			} else {
 debounce_enable = "  ∅";
+time = 0;
 			}
 			snprintf(debounce_value, sizeof(debounce_value), "%u", time * unit);
 			seq_printf(s, "debounce %s ( %sus)| ", debounce_enable, debounce_value);


signature.asc
Description: This is a digitally signed message part.

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Control: tags -1 +patch

Le vendredi, 20 janvier 2023, 21.38:42 h CET Salvatore Bonaccorso a écrit :
> There is the patchset currently asked for inclusion at
> https://lore.kernel.org/stable/20230119235200.441386-1-harry.wentl...@amd.co
> m/T/#m3b5b3616eac750cfd7c9bd00ac1cf95006a6aeec which is for addressing this
> issue.

Indeed. I can confirm this fixes my issue with the attached patch on top of 
6.1.7-1, which is all 4 patches from :
 https://gitlab.freedesktop.org/hwentland/linux/-/commits/mst_regression_6.1
aka:
 https://gitlab.freedesktop.org/hwentland/linux/-/compare/
21e996306a6afaae88295858de0ffb8955173a15...1521e9dcb431f31c15a0256cb619b09cca3efc4e?
from_project_id=12209=false

I hope this can either get to 6.1 stable, or be backported / carried over by 
Debian! Happy to MR this if it makes sense!

Best,
OdyXdiff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index dacad8b85963..fbc89129e7de 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9399,6 +9399,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
 	struct drm_connector_state *old_con_state, *new_con_state;
 	struct drm_crtc *crtc;
 	struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+	struct drm_dp_mst_topology_mgr *mgr;
+	struct drm_dp_mst_topology_state *mst_state;
 	struct drm_plane *plane;
 	struct drm_plane_state *old_plane_state, *new_plane_state;
 	enum dc_status status;
@@ -9654,6 +9656,28 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
 		lock_and_validation_needed = true;
 	}
 
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+	/* set the slot info for each mst_state based on the link encoding format */
+	for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
+		struct amdgpu_dm_connector *aconnector;
+		struct drm_connector *connector;
+		struct drm_connector_list_iter iter;
+		u8 link_coding_cap;
+
+		drm_connector_list_iter_begin(dev, );
+		drm_for_each_connector_iter(connector, ) {
+			if (connector->index == mst_state->mgr->conn_base_id) {
+aconnector = to_amdgpu_dm_connector(connector);
+link_coding_cap = dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+drm_dp_mst_update_slots(mst_state, link_coding_cap);
+
+break;
+			}
+		}
+		drm_connector_list_iter_end();
+	}
+#endif
+
 	/**
 	 * Streams and planes are reset when there are changes that affect
 	 * bandwidth. Anything that affects bandwidth needs to go through
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index f72c013d3a5b..16623f73ddbe 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -120,23 +120,50 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
 }
 
 static void
-fill_dc_mst_payload_table_from_drm(struct drm_dp_mst_topology_state *mst_state,
-   struct amdgpu_dm_connector *aconnector,
+fill_dc_mst_payload_table_from_drm(struct dc_link *link,
+   bool enable,
+   struct drm_dp_mst_atomic_payload *target_payload,
    struct dc_dp_mst_stream_allocation_table *table)
 {
 	struct dc_dp_mst_stream_allocation_table new_table = { 0 };
 	struct dc_dp_mst_stream_allocation *sa;
-	struct drm_dp_mst_atomic_payload *payload;
+	struct link_mst_stream_allocation_table copy_of_link_table =
+		link->mst_stream_alloc_table;
+
+	int i;
+	int current_hw_table_stream_cnt = copy_of_link_table.stream_count;
+	struct link_mst_stream_allocation *dc_alloc;
+
+	/* TODO: refactor to set link->mst_stream_alloc_table directly if possible.*/
+	if (enable) {
+		dc_alloc =
+		_of_link_table.stream_allocations[current_hw_table_stream_cnt];
+		dc_alloc->vcp_id = target_payload->vcpi;
+		dc_alloc->slot_count = target_payload->time_slots;
+	} else {
+		for (i = 0; i < copy_of_link_table.stream_count; i++) {
+			dc_alloc =
+			_of_link_table.stream_allocations[i];
+
+			if (dc_alloc->vcp_id == target_payload->vcpi) {
+dc_alloc->vcp_id = 0;
+dc_alloc->slot_count = 0;
+break;
+			}
+		}
+		ASSERT(i != copy_of_link_table.stream_count);
+	}
 
 	/* Fill payload info*/
-	list_for_each_entry(payload, _state->payloads, next) {
-		if (payload->delete)
-			continue;
-
-		sa = _table.stream_allocations[new_table.stream_count];
-		sa->slot_count = payload->time_slots;
-		sa->vcp_id = payload->vcpi;
-		new_table.stream_count++;
+	for (i = 0; i < MAX_CONTROLLER_NUM; i++) {
+		dc_alloc =
+			_of_link_table.stream_allocations[i];
+		if (dc_alloc->vcp_id > 0 && dc_alloc->slot_count > 0) {
+			sa = _table.stream_allocations[new_table.stream_count];
+			sa->slot_count = dc_alloc->slot_count;
+			sa->vcp_id = dc_alloc->vcp_id;
+			new_table.stream_count++;
+		}
 	}
 
 	/* Overwrite the old table */
@@ -185,7 +212,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
 	 * AUX message. The sequence is slot 1-63 allocated 

Bug#1029046: Wayland session doesn't get back to life post-suspend

[Didier 'OdyX' Raboud]

Control: retitle -1 Thinkpad: amd_pmc module required for on 6.1 for correct 
suspend

Le mardi, 17 janvier 2023, 22.53:54 h CET Didier 'OdyX' Raboud a écrit :
> Le mardi, 17 janvier 2023, 15.32:37 h CET Diederik de Haas a écrit :
> > On Monday, 16 January 2023 22:33:05 CET Didier 'OdyX' Raboud wrote:
> > > This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't
> > > light up", so feel free to close the bug; I'll test if I get the same
> > > symptoms on an unpatched kernel anyway :-)
> > 
> > If this issue doesn't occur with the unpatched kernel, that would be VERY
> > important extra information!
> > https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1724186 may be
> > the same or similar finding?
> > 
> > If that issue doesn't occur with the unpatched kernel, could you add your
> > finding to that upstream/forwarded issue?
> 
> Now that I got my kernel build in place; I can actually confirm that:
> 
> On my Thinkpad X13 Gen 2a, without any dongle, hub or docking station (on
> battery), with a KDE Plasma Wayland session:
> 
> * 6.0.0-6-amd64 (6.0.12-1)
>   suspends and resumes correctly
> * 6.1.0-1-amd64 (6.1.4-1, unpatched)
>   doesn't finish suspending
> * 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, not patched)
>   doesn't finish suspending
> * 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, patched),
>   doesn't finish suspending
> 
> All three 6.1 kernels (whether patched or not) don't bring the laptop to the
> suspended state (power led 'breathing', fans off), but it's kept in an "on"
> state (power led on, fans on), from which I found that I *can* wake the
> laptop up by short-pressing the power button; the screens gets back to life
> and show my lockscreen. But from there, I can't move the mouse nor do
> anything else. Alt-SysRq-r + ctrl-alt-f2 give me a tty, but any comeback to
> tty1 only blank (not even a blank screen, just a freeze).
> 
> This seems to point to a quite severe regression in amdgpu or other amd-
> related code; I can't suspend-and-resume the laptop anymore on any 6.1
> kernel, on battery, without anything attached to it.
> 
> I'll forward the above findings to the bug you pointed to, hoping it could
> help upstream too!

OK. I've gone and done this: 
https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1727281

It turns out to get suspend to work, the `amd_pmc` module needs to be enabled
(_AND_ the BIOS needs to have the "Sleep State" toggled to Windows (from
Linux).

I _think_ Debian should make sure amd_pmc is loaded on (all?) modern AMD
laptops. I have no idea (yet) what the mechanism to make this happen is though.

-- 
OdyX

Bug#1029046: Wayland session doesn't get back to life post-suspend

[Didier 'OdyX' Raboud]

Control: found -1 6.1.6-1
Control: found -1 6.1.4-1
Control: severity -1 serious

Hello there,

Le mardi, 17 janvier 2023, 15.32:37 h CET Diederik de Haas a écrit :
> On Monday, 16 January 2023 22:33:05 CET Didier 'OdyX' Raboud wrote:
> > This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't
> > light up", so feel free to close the bug; I'll test if I get the same
> > symptoms on an unpatched kernel anyway :-)
> 
> If this issue doesn't occur with the unpatched kernel, that would be VERY
> important extra information!
> https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1724186 may be the
> same or similar finding?
> 
> If that issue doesn't occur with the unpatched kernel, could you add your
> finding to that upstream/forwarded issue?

Now that I got my kernel build in place; I can actually confirm that:

On my Thinkpad X13 Gen 2a, without any dongle, hub or docking station (on 
battery), with a KDE Plasma Wayland session:

* 6.0.0-6-amd64 (6.0.12-1)
  suspends and resumes correctly
* 6.1.0-1-amd64 (6.1.4-1, unpatched)
  doesn't finish suspending
* 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, not patched)
  doesn't finish suspending
* 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, patched),
  doesn't finish suspending

All three 6.1 kernels (whether patched or not) don't bring the laptop to the 
suspended state (power led 'breathing', fans off), but it's kept in an "on" 
state (power led on, fans on), from which I found that I *can* wake the laptop 
up by short-pressing the power button; the screens gets back to life and show 
my lockscreen. But from there, I can't move the mouse nor do anything else. 
Alt-SysRq-r + ctrl-alt-f2 give me a tty, but any comeback to tty1 only blank 
(not even a blank screen, just a freeze).

This seems to point to a quite severe regression in amdgpu or other amd-
related code; I can't suspend-and-resume the laptop anymore on any 6.1 kernel, 
on battery, without anything attached to it.

I'll forward the above findings to the bug you pointed to, hoping it could 
help upstream too!

Best,

OdyX

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Hello Salvatore,

17 janvier 2023 07:14 "Salvatore Bonaccorso"  a écrit:
> I will bite the bullet (taking full responsibility for it if
> necessary, don't blame the other kernel team members) and ask here now
> the release team: Can we let linux 6.1.4-1 despite the RC bug
> reported, migrate to testing, so we can move on to 6.1.y? Let's keep
> the bug as RC severity. I'm currently working on uploading as well
> 6.1.6 or 6.1.7 (depending on the timing) further after that to
> unstable. Unfortuantely there is still not a solution to address
> #1028451 but will contain other important fixes (including security
> ones).
> 
> Thank you for considering it,
> 
> Odyx, I feel sorry, this will knowingly impact your and others!

No problem; such is the life on the unstable/testing edge.

I'll keep a 6.0.0-6 kernel around, and will keep testing the most
recent kernels; as well as report back if these help.

Best,

OdyX

Bug#1029046: Wayland session doesn't get back to life post-suspend

[Didier 'OdyX' Raboud]

Package: linux-image-6.1.0-1-amd64
Version: 6.1.4-1
Severity: important

Hello there,

this is a regression from 6.0.0 too; after post-suspend wakeup, my
plasma wayland session stays frozen; the two DisplayPort screens light
up, backgrounds are shown, but the mouse doesn't move, nothing works.

I'm reportbug'ging this from a SysRQ-R, Ctrl-Alt-F2 text tty.

>From cursory dmesg reading, it seems amdgpu has an "IB test failed"
_before_ kernel suspend.

This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't
light up", so feel free to close the bug; I'll test if I get the same
symptoms on an unpatched kernel anyway :-)

Best,

OdyX


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.1.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.1.0-1-amd64 recommends:
ii  apparmor 3.0.8-1
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-efi-amd64  2.06-7
pn  linux-doc-6.1   

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Hello there,

I finally managed to test

https://github.com/archlinux/linux/commit/7c4fed4d2afd27d7acb8835f8e79f49c99c03cdf.patch

(which is a revert of 4d07b0bc403403438d9cf88450506240c5faf92f)

… on top of 6.1.4-1.

I can confirm (without looking into any code-related details), that the two
of my DisplayPort-connected screens light up and work correctly.

(The "first" external screen is connected with a DisplayPort-DVI converter; that
one always worked; the "second" is connected directly via DisplayPort, which 
didn't
work on unpatched 6.1.4)


14 janvier 2023 17:52 "Diederik de Haas"  a écrit:
> On Saturday, 14 January 2023 16:30:05 CET Salvatore Bonaccorso wrote:
>> On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote:
>> On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote:
>>> Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked
>>> 
>>> upstream here:
>>> https://gitlab.freedesktop.org/drm/amd/-/issues/2171
>> 
>> Thanks! About an hour ago the suggested fix was to revert commit
>> 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1
>> 
>> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#
>> s4.2.2 describes a procedure to build a kernel with the proposed patch
>> (attached).
>> 
>> OdyX: Can you try to see whether that resolves the issue?
>> 
>> Should we keep 6.1.y based kernel out of testing until this is clear?
>> As we aim though to have 6.1.y into bookworm I would see it as more
>> preferable to get 6.1.4 in for testing, we will need to followup as
>> well soonish with another interation for e.g. for fixing
>> CVE-2023-0266.
> 
> As CVE-2023-0266 is fixed in 6.1.6, I'd suggest to upload that now, which I
> believe is ready to be uploaded already.
> That should keep 6.1.y out of testing for a few more days.
> 
>> Now if it turns out that this is the same issue as the referenced
>> upstream, reverting I think we only should really revert the commit if
>> that's queued up for 6.1. There is currently some furhter discussion
>> on
>> https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com
>> /T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e40
>> 
>> Given the size of the revert, there is as well a chance to re-break
>> other parts. So preferring to closely follow upstream here, whatever
>> the decision will be.
> 
> Agreed.
> 
> I asked 'OdyX' to test the revert to make sure it would indeed fix *this*
> issue, IOW what I consider standard bug triaging.
> 
> But even Daniel Vetter has SERIOUS 'issues' with the revert, next to the other
> people who weren't happy about it. So *I* wouldn't suggest applying it to
> Debian (although I don't think my opinion should have much weight).
> 
> As for letting this bug _continue_ to prevent a migration, ie keep the RC
> status, I'm against it and for downgrading it to 'important'.
> You could opt to add a NEWS item to warn people about this potential issue.
> 
> But the original report is about the *2nd* DisplayPort being 'broken'.
> 
> On zaterdag 14 januari 2023 17:04:52 CET you wrote:
> 
>> Basically this issue breaks all usage of Displayport MST on amdgpu systems.
>> Which roughly translates to breaking external monitors for everyone using
>> an USB-C docks with multiple display outputs (which is pretty common these
>> days) on AMD laptops. As well as those like myself who daisy-chain display
>> port monitors with an amdgpu using graphics card.
> 
> I understand that would be annoying for you, but I don't think that it would
> affect the majority of our users.

Hrm. More and more laptops come with usb-c only, and dongles/docks become more
and more common.

It's clearly a serious regression, as such setups "just worked" with 6.0.

Best,

OdyX

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Hello there,

It's really time-consuming to download, reboot, wait cryptsetup prompt, fail,
reboot, wait cryptsetup prompt, type long passphrase, log in account, dpkg -i,
reboot, rinse repeat.

Anyway, I can confirm that on my Lenovo X13 AMD;

* 6.1~rc3+1~exp1 doesn't boot until the cryptsetup prompt
* 6.1~rc5+1~exp1 doesn't boot until the cryptsetup prompt
* 6.1~rc6+1~exp1 doesn't boot until the cryptsetup prompt
* 6.1~rc7+1~exp1 boots until the cryptsetup prompt, but the culprit screen
  doesn't get anything

So it seems the issue was already there in 6.1~rc7+1~exp1, but I can't rewind
further.

Hope that helps!

OdyX

11 janvier 2023 10:04 "Diederik de Haas"  a écrit:

> On Wednesday, 11 January 2023 08:33:29 CET Didier 'OdyX' Raboud wrote:
> 
>> Package: src:linux
>> Version: 6.1.4-1
>> Severity: serious
>> 
>> Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking
>> Station doesn't get any output.
> 
> Can you try the previous versions of the 6.1.x series which you can get via
> snapshot.debian.org? I recommend to start with the first 6.1-rcX version.
> 
> A `git bisect` is the best way to figure out what caused it, but the above
> procedure is the quickest way to narrow down the search space.

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Package: src:linux
Version: 6.1.4-1
Severity: serious

Hello there,

Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking
Station doesn't get any output. It is _seen_ as connected by the screen, but
apparently gets no video signal (or just blank). This is clearly a regression
from 6.0.0-6 where this was working.

I'm quite confident this is a kernel-level change (and not X11 or Plasma) as
this already appears clearly at cryptsetup password prompt (which usually goes
to all outputs, but not on 6.1.0-1 which only displays it on the laptop screen
and the 1st connected DisplayPort.

Happy to help solve this.

Best,
OdyX


-- Package-specific info:
** Version:
Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-1-amd64 root=/dev/mapper/turnagra--vg-root ro quiet 
splash cgroup_enable=memory apparmor=1 security=apparmor

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[   15.343546] input: HD-Audio Generic Headphone as 
/devices/pci:00/:00:08.1/:05:00.6/sound/card4/input38
[   15.443246] usbcore: registered new interface driver btusb
[   15.481320] bluetooth hci0: firmware: direct-loading firmware 
mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
[   15.493335] intel_rapl_common: Found RAPL domain package
[   15.493340] intel_rapl_common: Found RAPL domain core
[   15.499969] mt7921e :03:00.0: enabling device ( -> 0002)
[   15.518411] mt7921e :03:00.0: ASIC revision: 79610010
[   15.602835] mt7921e :03:00.0: firmware: direct-loading firmware 
mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
[   15.602842] mt7921e :03:00.0: HW/SW Version: 0x8a108a10, Build Time: 
20221109110918a

[   15.603213] Bluetooth: hci0: Device setup in 121459 usecs
[   15.603217] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection 
command is advertised, but not supported.
[   15.614235] mt7921e :03:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[   15.614240] mt7921e :03:00.0: WM Firmware Version: 01, Build 
Time: 20221109111005
[   15.654966] mt7921e :03:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[   15.676225] EXT4-fs (nvme0n1p2): mounting ext2 file system using the ext4 
subsystem
[   15.677063] EXT4-fs (nvme0n1p2): mounted filesystem without journal. Quota 
mode: none.
[   15.679393] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Quota 
mode: none.
[   15.679984] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Quota 
mode: none.
[   15.689038] systemd-journald[673]: Received client request to flush runtime 
journal.
[   15.692904] systemd-journald[673]: File 
/var/log/journal/554675a9a7254eeea535d3d6aa31a8a6/system.journal corrupted or 
uncleanly shut down, renaming and replacing.
[   15.849074] audit: type=1400 audit(1673421894.663:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=980 comm="apparmor_parser"
[   15.849408] audit: type=1400 audit(1673421894.663:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=966 
comm="apparmor_parser"
[   15.849475] audit: type=1400 audit(1673421894.663:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oosplash" 
pid=979 comm="apparmor_parser"
[   15.849517] audit: type=1400 audit(1673421894.663:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="torbrowser_tor" pid=974 
comm="apparmor_parser"
[   15.849866] audit: type=1400 audit(1673421894.663:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=969 
comm="apparmor_parser"
[   15.849871] audit: type=1400 audit(1673421894.663:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=969 comm="apparmor_parser"
[   15.849949] audit: type=1400 audit(1673421894.663:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=977 
comm="apparmor_parser"
[   15.849954] audit: type=1400 audit(1673421894.663:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=977 
comm="apparmor_parser"
[   15.849957] audit: type=1400 audit(1673421894.663:12): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=977 
comm="apparmor_parser"
[   15.851055] audit: type=1400 audit(1673421894.667:13): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="system_tor" pid=972 
comm="apparmor_parser"
[   16.466830] mt7921e :03:00.0 wlp3s0: renamed from wlan0
[   16.789424] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   16.789428] Bluetooth: BNEP filters: protocol multicast
[   16.789433] Bluetooth: BNEP socket layer initialized
[   16.790811] Bluetooth: MGMT ver 1.22

Bug#995792: printing text files

[Didier 'OdyX' Raboud]

Le dimanche, 30 octobre 2022, 00.43:02 h CET Thorsten Alteholz a écrit :
> The problem seems to be that it was installed on a system without need
> for it. Wouldn't there be a better package than printer-driver-all-enforce
> to add a Recommends: for it?  Maybe OdyX can shed some light on it?

The printer-driver-all metapackage was introduced as an easy way to get the 
widest possible support for all potential printing drivers.  As britney 
doesn't look (or enforce) recommends, the source package also ships printer-
driver-all-enforce that has the same recommends as depends, to abuse britney 
in keeping all drivers in testing.  The latter package was not really meant to 
be installed or used.

Anyway, when that mechanism was introduced, printer-driver-all was a 
dependency of task-printing, but for buster (or bullseye), I had decided to 
drop that task, and let cups rely on driverless printing by default.  I'd say 
printer-driver-all is still a useful "if you have printing problems, install 
that with its recommends", but definitely not as central to the printing stack 
as it used to be.

As for indexbraille, as Samuel wrote, it was a mimetype mismatch, so that's 
solved!

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le lundi, 17 octobre 2022, 04.17:59 h CEST Blake Lee a écrit :
> I hammered away basically everything but the CI. I'm not familiar enough
> with Debian's CI yet to just get it going. I'll have to research the link
> from the issue you posted when I have more time. luckily I am familiar with
> GitLab's CI in general so it shouldn't be difficult once I have a free
> block to try.

Actually, it was just a matter of configuring the repo with salsa-ci's file 
(no code change), so I just went away and did that; the pipeline ran 
successfully (minus the arm64 cross-build for an unrelated reason).

> I believe I got everything else the way it should be.

Yes. I commented and closed all issues on the repository (you could've done 
this yourself, but no problem!).

The upload is on its way to the Debian NEW queue! Once it passes the review, 
it'll be auto-built and passed on to unstable archive; but that can really 
take some time, so be patient!

Best,

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows

[Didier 'OdyX' Raboud]

Hello Blak,

Le dimanche, 25 septembre 2022, 04.45:58 h CEST Blake Lee a écrit :
> Apologies for it taking me so long to get to it.

No problem!

> I nuked the repo and is now a clean, one commit, repo with only the unstable
> debian files in the master branch.

Great, thanks! It was not a necessity to drop all past packaging work, but 
doesn't hurt.

> I've also updated the files to build with the latest upstream release.
> Tested with sbuild that it builds successfully.

For _my_ standards, the package is still missing some thinks here and there, 
which I have filed as issues on the Salsa project, under a common milestone:

https://salsa.debian.org/qt-kde-team/extras/kwin-bismuth/-/milestones/1#tab-issues

#3 can be discussed later, but the other are quite important before upload.

Comments from others welcome of course!

Best,

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1019375: Not started under wayland/plasma

[Didier 'OdyX' Raboud]

13 septembre 2022 20:33 "Axel Beckert"  a écrit
> Didier 'OdyX' Raboud wrote:
>> https://bugs.debian.org/855868 suggests that a similar script as
>> present in /etc/Xsession.d should be placed in
>> /usr/lib/systemd/user-environment-generators/ for systemd/wayland
>> systems to benefit from unburden-home-dir.
> 
> So this is only needed in the combination of Wayland AND systemd? That
> kinda sounds weird.

My understanding is rather "Wayland does not use Xsession.d, and systemd
provides an alternative to this Xsession.d mechanism that would run on these
systems. I have not found a Wayland-specific way.

>> As a temporary local configuration, I've done this;
>> 
>> # mkdir -p /etc/systemd/user-environment-generators/
>> # cp /etc/X11/Xsession.d/95unburden-home-dir 
>> /etc/systemd/user-environment-generators/
> 
> Thanks for that tip. Is there a reason why you've copied it instead of
> e.g. a symlink?

Quick test only, good point. Of course I forgot to chmod +x. But it
didn't work :-(

Re-reading the doc, it seems that doing this would be an abuse of that
user-environment-generators mechanism.

The "right" systemd mechanism seems to be a Type=oneshot
/lib/systemd/user/*.service with a Slice=session.slice.

>> Will report back if that helps.

It did not :-). I'll try with a user service and report again. If it
works I'll propose a patch.

Best,
OdyX

Bug#1019375: #1019375: Not started under wayland/plasma

[Didier 'OdyX' Raboud]

Hello again,

https://bugs.debian.org/855868 suggests that a similar script as present in 
/etc/Xsession.d should be placed in 
/usr/lib/systemd/user-environment-generators/ for systemd/wayland systems to 
benefit from unburden-home-dir.

As a temporary local configuration, I've done this;

# mkdir -p /etc/systemd/user-environment-generators/
# cp /etc/X11/Xsession.d/95unburden-home-dir 
/etc/systemd/user-environment-generators/

Will report back if that helps.

Best,
OdyX


8 septembre 2022 08:03 "Didier 'OdyX' Raboud"  a écrit:

> Package: unburden-home-dir
> Version: 0.4.2
> Severity: important
> 
> Hello Axel,
> 
> with KDE's Plasma under Wayland, unburden-home-dir isn't started at all,
> although other XSession.d scripts are.
> 
> What am I doing wrong?
> 
> Best,
> Didier
> 
> -- System Information:
> Debian Release: bookworm/sid
> APT prefers buildd-unstable
> APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1,
> 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_CH:fr
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages unburden-home-dir depends on:
> ii dpkg 1.21.9
> ii libconfig-file-perl 1.54-1
> ii libfile-basedir-perl 0.09-1
> ii libfile-rsync-perl 0.49-2
> ii libfile-touch-perl 0.12-1
> ii libfile-which-perl 1.27-1
> ii libipc-run-perl 20220807.0-1
> ii libstring-expand-perl 0.04-4
> ii libtry-tiny-perl 0.31-1
> ii perl 5.34.0-5
> 
> Versions of packages unburden-home-dir recommends:
> ii lsof 4.95.0-1
> ii x11-common 1:7.7+23
> 
> Versions of packages unburden-home-dir suggests:
> pn agedu 
> pn autotrash 
> pn bleachbit 
> pn corekeeper 
> ii eatmydata 130-2
> pn fslint 
> pn ncdu | baobab | filelight | xdiskusage | xdu 
> pn tmpreaper 
> pn unburden-home-dir-doc 
> 
> -- Configuration Files:
> /etc/default/unburden-home-dir changed:
> UNBURDEN_HOME=true
> 
> /etc/unburden-home-dir.list changed:
> m D .thumbnails thumbnails
> m D .ccache ccache
> m d .config/google-chrome/*/Thumbnails google-chrome-thumbnails-%1
> m f .config/google-chrome/*/Thumbnails-journal 
> google-chrome-thumbnails-journal-%1
> m d .config/chromium/*/Thumbnails chromium-thumbnails-%1
> m f .config/chromium/*/Thumbnails-journal chromium-thumbnails-journal-%1
> m d .mozilla/default/*/Cache mozilla-default-cache-%1
> m d .mozilla/default/*/startupCache mozilla-default-startup-cache-%1
> m d .mozilla/firefox/*/Cache firefox-cache-%1
> m d .mozilla/firefox/*/startupCache firefox-startup-cache-%1
> m d .mozilla/firefox/*/Cache.Trash firefox-cache-trash-%1
> m d .conkeror.mozdev.org/conkeror/*/Cache conkeror-cache-%1
> m d .conkeror.mozdev.org/conkeror/*/startupCache conkeror-startup-cache-%1
> m d .conkeror.mozdev.org/conkeror/*/Cache.Trash conkeror-cache-trash-%1
> m d .kazehakase/mozilla/kazehakase/Cache kazehakase-cache
> m d .galeon/mozilla/galeon/Cache galeon-cache
> m d .gnome2/epiphany/mozilla/epiphany/Cache epiphany-cache
> m d .xxxterm/cache xxxterm-cache
> m d .forg/cache forg-cache
> m d .opera/cache opera-cache
> m d .opera/cache4 opera-cache4
> m d .opera/opcache opera-opcache
> m d .opera/cacheOp opera-cacheOp
> m d .config/qupzilla/profiles/*/networkcache qupzilla-cache-%1
> m d .thunderbird/*/Cache thunderbird-cache-%1
> m d .mozilla-thunderbird/*/Cache debian-thunderbird-cache-%1
> m d .icedove/*/Cache icedove-cache-%1
> m d .buzzbird/*/Cache buzzbird-cache
> m f .aptitude/cache aptitude-cache
> m d .wesnoth*/cache wesnoth%1-cache
> m d .gaia/cache gaia-cache
> m d .googleearth/Cache google-earth-cache
> m d .java/deployment/cache java-deployment-cache
> m d .adobe/Acrobat/*/Cache adobe-acrobat-%1-cache
> m d .shotwell/thumbs shotwell-thumbs
> m D .sxiv sxiv-thumbs
> m D .devscripts_cache devscripts_cache
> r D .Trash trash
> r D .local/Trash local-trash
> r D Downloads downloads
> r D Téléchargements downloads
> 
> -- no debconf information

Bug#1019375: Not started under wayland/plasma

[Didier 'OdyX' Raboud]

Package: unburden-home-dir
Version: 0.4.2
Severity: important

Hello Axel,

with KDE's Plasma under Wayland, unburden-home-dir isn't started at all,
although other XSession.d scripts are.

What am I doing wrong?

Best,
Didier

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unburden-home-dir depends on:
ii  dpkg   1.21.9
ii  libconfig-file-perl1.54-1
ii  libfile-basedir-perl   0.09-1
ii  libfile-rsync-perl 0.49-2
ii  libfile-touch-perl 0.12-1
ii  libfile-which-perl 1.27-1
ii  libipc-run-perl20220807.0-1
ii  libstring-expand-perl  0.04-4
ii  libtry-tiny-perl   0.31-1
ii  perl   5.34.0-5

Versions of packages unburden-home-dir recommends:
ii  lsof4.95.0-1
ii  x11-common  1:7.7+23

Versions of packages unburden-home-dir suggests:
pn  agedu 
pn  autotrash 
pn  bleachbit 
pn  corekeeper
ii  eatmydata 130-2
pn  fslint
pn  ncdu | baobab | filelight | xdiskusage | xdu  
pn  tmpreaper 
pn  unburden-home-dir-doc 

-- Configuration Files:
/etc/default/unburden-home-dir changed:
UNBURDEN_HOME=true

/etc/unburden-home-dir.list changed:
m D .thumbnails thumbnails
m D .ccache ccache
m d .config/google-chrome/*/Thumbnails google-chrome-thumbnails-%1
m f .config/google-chrome/*/Thumbnails-journal 
google-chrome-thumbnails-journal-%1
m d .config/chromium/*/Thumbnails chromium-thumbnails-%1
m f .config/chromium/*/Thumbnails-journal chromium-thumbnails-journal-%1
m d .mozilla/default/*/Cache mozilla-default-cache-%1
m d .mozilla/default/*/startupCache mozilla-default-startup-cache-%1
m d .mozilla/firefox/*/Cache firefox-cache-%1
m d .mozilla/firefox/*/startupCache firefox-startup-cache-%1
m d .mozilla/firefox/*/Cache.Trash firefox-cache-trash-%1
m d .conkeror.mozdev.org/conkeror/*/Cache conkeror-cache-%1
m d .conkeror.mozdev.org/conkeror/*/startupCache conkeror-startup-cache-%1
m d .conkeror.mozdev.org/conkeror/*/Cache.Trash conkeror-cache-trash-%1
m d .kazehakase/mozilla/kazehakase/Cache kazehakase-cache
m d .galeon/mozilla/galeon/Cache galeon-cache
m d .gnome2/epiphany/mozilla/epiphany/Cache epiphany-cache
m d .xxxterm/cache xxxterm-cache
m d .forg/cache forg-cache
m d .opera/cache opera-cache
m d .opera/cache4 opera-cache4
m d .opera/opcache opera-opcache
m d .opera/cacheOp opera-cacheOp
m d .config/qupzilla/profiles/*/networkcache qupzilla-cache-%1
m d .thunderbird/*/Cache thunderbird-cache-%1
m d .mozilla-thunderbird/*/Cache debian-thunderbird-cache-%1
m d .icedove/*/Cache icedove-cache-%1
m d .buzzbird/*/Cache buzzbird-cache
m f .aptitude/cache aptitude-cache
m d .wesnoth*/cache wesnoth%1-cache
m d .gaia/cache gaia-cache
m d .googleearth/Cache google-earth-cache
m d .java/deployment/cache java-deployment-cache
m d .adobe/Acrobat/*/Cache adobe-acrobat-%1-cache
m d .shotwell/thumbs shotwell-thumbs
m D .sxiv sxiv-thumbs
m D .devscripts_cache devscripts_cache
r D .Trash trash
r D .local/Trash local-trash
r D Downloads downloads
r D Téléchargements downloads


-- no debconf information

Bug#1017130: yakuake FTBFS

[Didier 'OdyX' Raboud]

Control: tags -1 +upstream +patch +fixed-upstream

Hello,

I can confirm this is fixed in 22.08 [0]. Specifically, the commits are as 
follows:
- 
https://invent.kde.org/utilities/yakuake/-/commit/56c0b6f38968902765ffe706e2694eb50b0834f7
 (not all of it)
- 
https://invent.kde.org/utilities/yakuake/-/commit/9e691cfa077bb2e26efc14dd021da0836d70782d

I'd be happy to join the yakuake maintenance team BTW.

Best,

OdyX

[0] https://invent.kde.org/utilities/yakuake/-/commits/release/22.08/

Bug#1017555: Let's drop win32-loader from amd64/i386 and multiarch CDs

[Didier 'OdyX' Raboud]

Package: debian-cd
Version: 3.1.35
Severity: normal
Tags: d-i
X-Debbugs-Cc: win32-loa...@packages.debian.org

Following the recent discussion on d-boot [1], it seems we agreed to drop
win32-loader from the Debian CDs, as it's not likely to be very useful these
days.

win32-loader seems also present on debian-installer [2], I'll therefore clone
the bug.

As for the win32-loader package, its network version [3] is still probably
useful, and doesn't take much space on mirrors; let's keep it.

Best,
OdyX

[1] https://lists.debian.org/debian-boot/2022/07/msg00083.html
[2] https://d-i.debian.org/daily-images/amd64/20220817-00:19/build_cdrom_gtk.log



-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (100, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages debian-cd depends on:
ii  apt2.5.2
ii  bc 1.07.1-3+b1
ii  bzip2  1.0.8-5
ii  cpp4:12.1.0-3
ii  curl   7.84.0-2
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.21.9
ii  genisoimage9:1.1.11-3.4
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.21.9
pn  libfile-slurp-perl 
ii  libyaml-libyaml-perl   0.83+ds-1+b1
ii  lynx   2.9.0dev.10-1
ii  make   4.3-4.1
ii  perl [libdigest-sha-perl]  5.34.0-5
ii  tofrodos   1.7.13+ds-5
ii  wget   1.21.3-1+b2
ii  xorriso1.5.4-2

Versions of packages debian-cd recommends:
ii  dosfstools   4.2-1
pn  hfsutils 
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.33-1+really4.0.32-1
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows

[Didier 'OdyX' Raboud]

Hello there,

I found the repo; https://salsa.debian.org/qt-kde-team/extras/kwin-bismuth

One thing that struck me first is that the repository isn't in any of the 
standard git formats.
See https://dep-team.pages.debian.net/deps/dep14/ for a long description of the 
possibilities.

I can't remember what the Qt-KDE Extras practices is, so I checked; 
https://qt-kde-team.pages.debian.net/gitguidelines.html seems to be the latest 
recommendations.

Basically, I think it's reasonable to say that most Debian packages' 
repositories try to avoid mixing upstream and debian/* changes on the same 
branches. See https://wiki.debian.org/PackagingWithGit for some documentation 
on that area; specifically  
https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage is 
pretty standard nowadays.

As for what I'm concerned, my ideal repository has an upstream/latest branch 
with upstream's own history, upstream/1.2.3 tags for releases, debian/latest 
for the changes (and initial addition) in debian/*, and debian/1.2.3-1 tags 
upon releases. Now, how to go there from where you are? I'd basically start a 
new repo from scratch, start from upstream's branch tip and reconstruct (in one 
commit, or more) the debian/latest branch.

Finally, another thing that will really help testing many Debian'isms before 
going to sid is the Salsa CI pipeline: 
https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md This 
will test many many things out-of-the-box, from the repository; so it'll also 
error-out early, and before reaching the Debian archive.

I'm aware this is a lot of links, and a lot of specific quirks to learn about 
Debian specificities. But getting them right upfront will make any and all 
later collaboration much easier and faster as the repository (and package) will 
look familiar to the rest of Debian. It's really worth going through the effort!

Best,
OdyX


2 août 2022 04:43 "Blake Lee"  a écrit:
> 
> I've moved over the repository into Salsa, updated it for the latest release 
> `3.1.2`.
> 
> I've built it on my Sid desktop with sbuild, lintian reports no errors, and 
> it the software is
> working as expected.
> 
> Let me know if you see anything you would change.

Bug#1010342: Refuses to create directories for unburdening

[Didier 'OdyX' Raboud]

Control: tags -1 -moreinfo

30 avril 2022 00:17 "Axel Beckert"  a écrit:
> Didier 'OdyX' Raboud wrote:
>> With 0.4.2, after noticing my directories didn't get symlinked, I tried to
>> run unburden-home-dir by hand and I got the following error(s) (with or
>> without -F):
> 
> Thanks for the bug report!
> 
>> WARNING: Can't handle /home/didier/.cache: /tmp/.unburden-didier/cache not 
>> equal
>> /run/user/1000/.unburden-didier/cache at /usr/bin/unburden-home-dir line 
>> 245, <$list_fh> line 2
> 
> This basically means that to wants symlink files elsewhere than before.
> 
>> I haven't spent much time investigating; as 0.4.1.2 works for me now.
>> 
>> Anything I could do to help?
> 
> The output of "env | fgrep XDG_" might be helpful.

Here comes (that's on my other local user 'diidier'):

$ env | fgrep XDG
XDG_CACHE_HOME=/run/user/1001/.unburden-diidier/cache
XDG_CONFIG_DIRS=/home/diidier/.config/kdedefaults:/etc/xdg
XDG_CURRENT_DESKTOP=KDE
XDG_DATA_DIRS=/home/diidier/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
XDG_RUNTIME_DIR=/run/user/1001
XDG_SEAT=seat0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=KDE
XDG_SESSION_ID=3
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session2
XDG_SESSION_TYPE=x11
XDG_VTNR=7

> The weird thing is that there weren't any changes which explains that
> out of the box:
> (…)
> Then again, I noticed this, too, on one of my hosts. I thought I might
> have toyed with a non-standard config for testing one of the changes
> mentioned above and just uncommented this line in
> /etc/unburden-home-dir to make it work again:
> 
> #TARGETDIR=/tmp

According to etckeeper, this went commented (and still is) on the upgrade from 
0.3.3 to 0.4.

> (But before you do the same change, please read until the end of this
> mail and do "stat" that file.)
> 
> Actually this looks a bit like a result of this commit from 2015 between
> 0.3.3 and 0.4:
> 
> commit 65f632b73c7a78e6f30aae143eebb95e5bb15866
> Author: Axel Beckert 
> Date: Sun Jul 5 01:43:27 2015 +0200
> 
> Don't set TARGETDIR in config by default but compute a sane
> default value
> 
> The default value is determined as follows:
> 
> - Use $TARGETDIR if set in the configuration file.
> - Else use $XDG_RUNTIME_DIR/$UID if it exists.
> - Else use /run/user/$UID if it exists.
> - Else use $TMPDIR if it exists.
> - Else use /tmp/.
> 
> Requires new runtime dependency libfile-slurp-perl.
> 
> For coverage computation, the test suite is run twice, once with
> and once without $TMPDIR and $XDG_RUNTIME_DIR being set.
> 
> Closes: #780387
> 
> So I wonder if for some reason the /etc/unburden-home-dir conffile got
> updated this time while it didn't get update with quite a lot of
> previous updates.
> 
> Can you also send me the output of "stat /etc/unburden-home-dir" in
> case you didn't edit it since the update.

$ LANG=C stat /etc/unburden-home-dir
  File: /etc/unburden-home-dir
  Size: 119 Blocks: 2  IO Block: 1024   regular file
Device: fd01h/64769dInode: 34780   Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2022-05-02 08:44:06.0 +0200
Modify: 2016-05-13 03:15:21.0 +0200
Change: 2016-05-15 19:21:02.0 +0200
 Birth: -

What I don't understand is why the symlinks currently point to /tmp, why it 
wants to change them to /run/user/… now, and why it cannot "go through" that 
change now. Refusing to update the symlinks seems overly defensive, isn't it?

Best,

Didier

Bug#1010342: Refuses to create directories for unburdening

[Didier 'OdyX' Raboud]

Package: unburden-home-dir
Version: 0.4.2
Severity: normal

Hello Axel,

With 0.4.2, after noticing my directories didn't get symlinked, I tried to
run unburden-home-dir by hand and I got the following error(s) (with or
without -F):

WARNING: Can't handle /home/didier/.cache: /tmp/.unburden-didier/cache not 
equal /run/user/1000/.unburden-didier/cache at /usr/bin/unburden-home-dir line 
245, <$list_fh> line 2

I haven't spent much time investigating; as 0.4.1.2 works for me now.

Anything I could do to help?

Best,
Didier


-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (100, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages unburden-home-dir depends on:
ii  dpkg   1.21.7
ii  libconfig-file-perl1.54-1
ii  libfile-basedir-perl   0.09-1
ii  libfile-rsync-perl 0.49-1
ii  libfile-touch-perl 0.12-1
ii  libfile-which-perl 1.27-1
ii  libipc-run-perl20200505.0-1
ii  libstring-expand-perl  0.04-3
ii  libtry-tiny-perl   0.31-1
ii  perl   5.34.0-4

Versions of packages unburden-home-dir recommends:
ii  lsof4.95.0-1
ii  x11-common  1:7.7+23

Versions of packages unburden-home-dir suggests:
pn  agedu  
pn  autotrash  
pn  bleachbit  
pn  corekeeper 
ii  eatmydata  130-2
ii  filelight  4:21.12.3-1
pn  fslint 
pn  tmpreaper  
pn  unburden-home-dir-doc  

-- Configuration Files:
/etc/default/unburden-home-dir changed:
UNBURDEN_HOME=true

/etc/unburden-home-dir.list changed:
m D .cache cache
m D .thumbnails thumbnails
m D .ccache ccache
m d .config/google-chrome/*/Thumbnails google-chrome-thumbnails-%1
m f .config/google-chrome/*/Thumbnails-journal 
google-chrome-thumbnails-journal-%1
m d .config/chromium/*/Thumbnails chromium-thumbnails-%1
m f .config/chromium/*/Thumbnails-journal chromium-thumbnails-journal-%1
m d .mozilla/default/*/Cache mozilla-default-cache-%1
m d .mozilla/default/*/startupCache mozilla-default-startup-cache-%1
m d .mozilla/firefox/*/Cache firefox-cache-%1
m d .mozilla/firefox/*/startupCache firefox-startup-cache-%1
m d .mozilla/firefox/*/Cache.Trash firefox-cache-trash-%1
m d .conkeror.mozdev.org/conkeror/*/Cache conkeror-cache-%1
m d .conkeror.mozdev.org/conkeror/*/startupCache conkeror-startup-cache-%1
m d .conkeror.mozdev.org/conkeror/*/Cache.Trash conkeror-cache-trash-%1
m d .kazehakase/mozilla/kazehakase/Cache kazehakase-cache
m d .galeon/mozilla/galeon/Cache galeon-cache
m d .gnome2/epiphany/mozilla/epiphany/Cache epiphany-cache
m d .xxxterm/cache xxxterm-cache
m d .forg/cache forg-cache
m d .opera/cache opera-cache
m d .opera/cache4 opera-cache4
m d .opera/opcache opera-opcache
m d .opera/cacheOp opera-cacheOp
m d .config/qupzilla/profiles/*/networkcache qupzilla-cache-%1
m d .thunderbird/*/Cache thunderbird-cache-%1
m d .mozilla-thunderbird/*/Cache debian-thunderbird-cache-%1
m d .icedove/*/Cache icedove-cache-%1
m d .buzzbird/*/Cache buzzbird-cache
m f .aptitude/cache aptitude-cache
m d .wesnoth*/cache wesnoth%1-cache
m d .gaia/cache gaia-cache
m d .googleearth/Cache google-earth-cache
m d .java/deployment/cache java-deployment-cache
m d .adobe/Acrobat/*/Cache adobe-acrobat-%1-cache
m d .shotwell/thumbs shotwell-thumbs
m D .sxiv sxiv-thumbs
m D .devscripts_cache devscripts_cache
r D .Trash trash
r D .local/Trash local-trash
r D Downloads downloads
r D .mcf/tmp mcf-tmp


-- no debconf information

Bug#993779: O: usb-modeswitch-data -- mode switching data for usb-modeswitch

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: usb-modeswitch-d...@packages.debian.org
Control: affects -1 src:usb-modeswitch-data

I have orphaned the usb-modeswitch-data package for reasons independant of
this package, or of Debian. 

The package description is:
 Several new USB devices have their proprietary Windows drivers onboard,
 especially WAN dongles. When plugged in for the first time, they act
 like a flash storage and start installing the driver from there. If
 the driver is already installed, the storage device vanishes and
 a new device, such as an USB modem, shows up. This is called the
 "ZeroCD" feature.
 .
 On Debian, this is not needed, since the driver is included as a
 Linux kernel module, such as "usbserial". However, the device still
 shows up as "usb-storage" by default. usb-modeswitch solves that
 issue by sending the command which actually performs the switching
 of the device from "usb-storage" to "usbserial".
 .
 This package contains the commands data needed for usb-modeswitch.

Bug#993778: O: usb-modeswitch -- mode switching tool for controlling "flip flop" USB devices

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: usb-modeswi...@packages.debian.org
Control: affects -1 src:usb-modeswitch

I have orphaned the usb-modeswitch package for reasons independant of this 
package, or
of Debian.

The package description is:
 Several new USB devices have their proprietary Windows drivers onboard,
 especially WAN dongles. When plugged in for the first time, they act
 like a flash storage and start installing the driver from there. If
 the driver is already installed, the storage device vanishes and
 a new device, such as an USB modem, shows up. This is called the
 "ZeroCD" feature.
 .
 On Debian, this is not needed, since the driver is included as a
 Linux kernel module, such as "usbserial". However, the device still
 shows up as "usb-storage" by default. usb-modeswitch solves that
 issue by sending the command which actually performs the switching
 of the device from "usb-storage" to "usbserial".
 .
 This package contains the binaries and the brother scripts.

Bug#993777: O: simple-tpm-pk11 -- simple library for using the TPM chip to secure SSH keys

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: simple-tpm-p...@packages.debian.org
Control: affects -1 src:simple-tpm-pk11

I have orphaned the simple-tpm-pk11 package for reasons independant of this
package, or of Debian.

The package description is:
 simple-tpm-pk11 provides tools to create a key in your TPM (Trusted Platform
 Module) chip which can then be used with SSH. The package comes with a library
 that you can use as “PKCS11Provider” in your SSH configuration file.

Bug#993776: O: shatag -- tool to store file checksums in extended attributes, and work with them

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: sha...@packages.debian.org
Control: affects -1 src:shatag

I have orphaned the shatag package for reasons independant of this package, or
of Debian.

The package description is:
 Shatag is a tool for computing and caching file checksums, and do
 remote duplicate detection. Files are compared on their SHA-256 hash to
 find duplicates, and will use filesystem extended attributes to cache
 the checksum values.

Bug#993774: RM: shatag -- ROM; Orphaned, not used

[Didier 'OdyX' Raboud]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: sha...@packages.debian.org

Hello there,

As I intend to orphan src:shatag, I also don't think it should stay in Debian:
I never really used it, it has a popcon of 24, doesn't have reverse
dependencies. If someone cares enough, they could adopt it and re-upload, but
I'd rather see it removed than unmaintained.

Thanks in advance, best regards,
OdyX

Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

[Didier 'OdyX' Raboud]

Control: reopen -1
Control: tag -1 +pending

Le mercredi, 1 septembre 2021, 22.40:57 h CEST Roger Lynn a écrit :
> On 27/08/2021 14:33, Didier 'OdyX' Raboud wrote:> Control: tags -1 +wontfix
> 
> > Using Let's Encrypt is fine, allowed, and (apparently) working with CUPS,
> > but as that's clearly not a default way of working for CUPS, I'd be
> > _very_ reluctant to allow CUPS to access "all the Let's Encrypt
> > certificates" on all systems it gets installed to. Furthermore,
> > /etc/apparmor.d/usr.sbin.cupsd is a configuration file, freely
> > modifiable by the local system administrator. In other words, imposing
> > that a local system administrator needs to update that file to enable a
> > specific type of certificates is reasonable.
> 
> CUPS appears to already have access to everything in /etc/ssl/ on all
> systems, which is where I used to keep my CAcert certificates. This doesn't
> feel any different.

You're absolutely right; that's convincing to me!

Reopening, and will fix in the next upload.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#993601: O: libopenaptx -- Audio Processing Technology codec (aptX), shared libraries

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: libopena...@packages.debian.org
Control: affects -1 src:libopenaptx


I have orphaned the libopenaptx package for reasons independant of this 
package, or
of Debian.

The package description is:
 Support for aptX and aptX HD codec variants; they both operate on raw 24-bit
 signed stereo audio sample; at 6:1 fixed compress ratio for aptX; at 4:1 fixed
 compress ratio for aptX HD.
 .
 This package contains the shared libraries.

Bug#993599: O: jimtcl -- small-footprint implementation of Tcl named Jim

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: jim...@packages.debian.org
Control: affects -1 src:jimtcl

I have orphaned the jimtcl package for reasons independant of this package, or
of Debian.

The package description is:
 Jim is an opensource small-footprint implementation of the Tcl programming
 language. It implements a large subset of Tcl and adds new features like
 references with garbage collection, closures, built-in Object Oriented
 Programming system, Functional Programming commands, first-class arrays and
 UTF-8 support. All this with a binary size of about 100-200kB (depending upon
 selected options).
 .
 This package provides the Jim interactive shell.

Bug#993520: O: fosfat -- API for the Smaky file system

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: fos...@packages.debian.org
Control: affects -1 src:fosfat

I have orphaned the fosfat package for reasons independant of this package, or
of Debian.

The package description is:
 Fosfat is a C library for providing read-only access to a Smaky
 formatted disk. Currently, only a tool and a FUSE extension that
 use this library can be used for reading a directory and copying
 a file.
 .
 The Smaky is a line of mostly 8-bit personal computers and
 accompanying operating system developed at the EPFL (École
 Polytechnique Federale de Lausanne), in Switzerland, from 1974.
 .
 This package contains the libfosfat0, which provides the API for the
 Smaky file system.

Bug#993493: O: doctest -- Light and feature-rich C++ testing framework

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: doct...@packages.debian.org
Control: affects -1 src:doctest

I have orphaned the doctest package for reasons independant of this package, or
of Debian.

The package description is:
 doctest is a light and feature-rich C++98 / C++11 single-header testing
 framework for unit tests and TDD.
 .
 It is inspired by the unittest {} functionality of the D programming
 language and Python's docstrings - tests can be considered a form of
 documentation and should be able to reside near the production code
 which they test. This isn't possible (or at least practical) with any
 other testing framework for C++.

Bug#993447: O: argagg -- Argument Aggregator - Simple C++11 command line argument parser

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: arg...@packages.debian.org
Control: affects -1 src:argagg

I have orphaned the argagg package for reasons independant of this package, or
of Debian.

The package description is:
 This is yet another C++ command line argument/option parser. It was
 written as a simple and idiomatic alternative to other frameworks like
 getopt, Boost program options, TCLAP, and others. The goal is to achieve
 the majority of argument parsing needs in a simple manner with an easy
 to use API. It operates as a single pass over all arguments, recognizing
 flags prefixed by - (short) or -- (long) and aggregating them into easy
 to access structures with lots of convenience functions. It defers
 processing types until you access them, so the result structures end up
 just being pointers into the original command line argument C-strings.
 .
 argagg supports POSIX recommended argument syntax conventions.

Bug#993440: O: sdl-kitchensink -- FFmpeg and SDL2 based library for audio and video playback - Development files

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: normal
X-Debbugs-Cc: sdl-kitchens...@packages.debian.org
Control: affects -1 src:sdl-kitchensink

I have orphaned the sdl-kitchensink package for reasons independant of this
package, or of Debian.

The package description is:
 It provides FFmpeg-based audio and video playback for SDL which features:
  - Decoding video & audio via FFmpeg
  - Dumping video data on SDL_textures
  - Dumping audio data in the usual mono/stereo interleaved formats
  - Automatic audio and video conversion to SDL2 friendly formats
  - Synchronizing video & audio to clock
  - Seeking forwards and backwards
  - Bitmap & libass subtitle support
 .
 This package contains the development files.

Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

[Didier 'OdyX' Raboud]

Le vendredi, 27 août 2021, 18.31:17 h CEST Roger Lynn a écrit :
> The documentation is definitely lacking - I've been trying to work out why
> my configuration broke since upgrading to Buster 3 months ago! Even with the
> loglevel set to "debug", the logs were utterly unhelpful. Let's Encrypt is
> the most popular source of signed certificates and the upstream
> documentation at https://www.cups.org/doc/encryption.html explicitly says:
> 
> "CUPS also supports certificates created and managed by the popular Let's
> Encrypt certificate service, which are stored in the /etc/letsencrypt/live
> directory."

Right. Where do you suggest this needed apparmor edition should be documented?

-- 
OdyX

Bug#992320: Missing breaks/replaces with kdenlive-data 21.04.3-1

[Didier 'OdyX' Raboud]

Package: breeze-icon-theme
Version: 4:5.78.0-2
Severity: normal

Upgrading fails if kdenlive-data is installed:

Unpacking breeze-icon-theme (4:5.83.0-2) over (4:5.78.0-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/breeze-icon-theme_4%3a5.83.0-2_all.deb (--unpack):
 trying to overwrite 
'/usr/share/icons/breeze-dark/actions/16/add-subtitle.svg', which is also in 
package kdenlive-data 21.04.3-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/breeze-icon-theme_4%3a5.83.0-2_all.deb


-- System Information:
Debian Release: 11.0
  APT prefers buildd-unstable
  APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (100, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages breeze-icon-theme depends on:
it  hicolor-icon-theme  0.17-2

breeze-icon-theme recommends no packages.

breeze-icon-theme suggests no packages.

-- no debconf information

Bug#992024: ITP: airsane -- SANE WebScan frontend that supports Apple's AirScan protocol

[Didier 'OdyX' Raboud]

Le lundi, 9 août 2021, 11.48:09 h CEST Bastien Roucariès a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Bastien Roucariès 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: airsane
>   Version : 0.3.2
>   Upstream Author : Simul Piscator
> * URL : https://github.com/SimulPiscator/AirSane
> * License : GPL3
>   Programming Lang: C++
>   Description :  SANE WebScan frontend that supports Apple's AirScan
> protocol
> 
>  SANE WebScan frontend that supports Apple's AirScan protocol. Scanners are
> detected automatically, and published through mDNS. Acquired images may be
> transferred in JPEG, PNG, and PDF/raster format.
> 
> AirSane's intended purpose is to be used with AirScan/eSCL clients such as
> Apple's Image Capture, but a simple web interface is provided as well.

How does this compare with https://github.com/alexpevzner/sane-airscan/ / 
src:sane-airscan? Client vs Server?

Best,

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#991518: cups: CUPS web interface is not available due to missing settings

[Didier 'OdyX' Raboud]

Control: tags -1 +moreinfo

26 juillet 2021 13:03 "Anthony Gaudino"  a écrit:
> Package: cups
> Version: 2.3.3op2-3+deb11u1
> Severity: normal
> X-Debbugs-Cc: anthonygaudin...@gmail.com
> 
> Dear Maintainer,
> 
> After installing CUPS, I could not access the web interface, trying to
> access localhost:631 showed a page not found error in the browser.

Hi again Anthony,

I'm very surprised by this, as this has been working reliably for a long time, 
and no recent changes have happened at all. So I just pulled a Debian Bullseye 
install and installed CUPS on it; the cupsd.conf file had this in, which makes 
for a working webinterface:

# Only listen for connections from the local machine.
Listen localhost:631
Listen /run/cups/cups.sock

# …

# Web interface setting...
WebInterface Yes

# Restrict access to the server...

  Order allow,deny


> I figured that I would need to add some settings in the CUPS
> configuration file (/etc/cups/cupsd.conf).
> 
> If I remember correctly I added:
> ```
> 
> Order Deny,Allow
> Deny From All
> Allow From 127.0.0.1
> 
> ```
> 
> After the changes I could access the CUPS web interface.

Is your machine really just a Debian Bullseye host? (It feels like it could 
have been cross-graded from Ubuntu…).

I'd be really curious to hear how you got in this situation, as a default 
Debian Bullseye with CUPS clearly has working print jobs and an accessible 
webinterface.

Best,
OdyX

Bug#991517: cups: CUPS cant access library files because they have different names

[Didier 'OdyX' Raboud]

Control: tags -1 +moreinfo

26 juillet 2021 12:36 "Anthony Gaudino"  a écrit:
> Package: cups
> Version: 2.3.3op2-3+deb11u1
> Severity: important
> X-Debbugs-Cc: anthonygaudin...@gmail.com
> 
> Dear Maintainer,
> 
> When I try to print anything with CUPS I had the following 2 errors on
> the CUPS log:
> 
> ```
> E [23/Jul/2021:17:37:03 +0100] [Job 27] libcups.so load failure
> E [23/Jul/2021:17:37:03 +0100] [Job 27] Unable to open raster stream - : 
> Broken pipe
> ```
> 
> The printer would not print anything.
> 
> After investigating, I found out that CUPS is trying to access
> `/usr/lib/x86_64-linux-gnu/libcups.so` and 
> `/usr/lib/x86_64-linux-gnu/libcupsimage.so`
> but Debian has these files named as `libcups.so.2` and
> `libcupsimage.so.2` instead.

Hello Anthony, and thanks for your report.

It seems you're trying to use a proprietary driver looking for the libcups.so 
filename. What driver are you trying to use?

> I solved the problem for myself by just copying those files and saving
> with the names CUPS was looking for.

.so files are not meant to be files, but symlinks, and these are shipped by 
libcups2-dev.

Isn't your issue solved by merely installing libcups2-dev ?

Best,

Didier


> -- System Information:
> Debian Release: 11.0
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
> Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages cups depends on:
> ii cups-client 2.3.3op2-3+deb11u1
> ii cups-common 2.3.3op2-3+deb11u1
> ii cups-core-drivers 2.3.3op2-3+deb11u1
> ii cups-daemon 2.3.3op2-3+deb11u1
> ii cups-filters 1.28.7-1
> ii cups-ppdc 2.3.3op2-3+deb11u1
> ii cups-server-common 2.3.3op2-3+deb11u1
> ii debconf [debconf-2.0] 1.5.77
> ii ghostscript 9.53.3~dfsg-7
> ii libavahi-client3 0.8-5
> ii libavahi-common3 0.8-5
> ii libc6 2.31-13
> ii libcups2 2.3.3op2-3+deb11u1
> ii libgcc-s1 10.2.1-6
> ii libstdc++6 10.2.1-6
> ii libusb-1.0-0 2:1.0.24-3
> ii poppler-utils 20.09.0-3.1
> ii procps 2:3.3.17-5
> 
> Versions of packages cups recommends:
> ii avahi-daemon 0.8-5
> ii colord 1.4.5-3
> 
> Versions of packages cups suggests:
> pn cups-bsd 
> pn cups-pdf 
> pn foomatic-db-compressed-ppds | foomatic-db 
> pn smbclient 
> ii udev 247.3-6
> 
> -- debconf information:
> cupsys/raw-print: true
> cupsys/backend: lpd, socket, usb, snmp, dnssd

Bug#972339: more info

[Didier 'OdyX' Raboud]

Control: unarchive -1 

Hello there,

I have gotten more info from good folks at OpenSuse:

> We at openSUSE got a similar (perhaps even same?) issue
> https://bugzilla.suse.com/show_bug.cgi?id=1187232
> 
> In the end the root cause there was that the installed
> HPLIP plugin did not match the installed HPLIP, see
> https://bugzilla.suse.com/show_bug.cgi?id=1187232#c8
> 
> Perhaps this might also help you with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972339
> 
> Even if the openSUSE issue is actually a different one
> it may help to know that HPLIP programs seem to blindly
> use plugin code and may fail in arbitrary ways if the
> plugin code does not fit.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#989566: [wontfix] New 0.2.1 upstream release

[Didier 'OdyX' Raboud]

Source: libopenaptx
Version: 0.2.1
Severity: important
Tags: upstream wontfix
X-Debbugs-Cc: libopena...@packages.debian.org

Upstream released a new 0.2.1 version, with a license version update:

https://github.com/pali/libopenaptx/releases/tag/0.2.1

The changelog has:
https://github.com/pali/libopenaptx/commit/811bc18586d634042618d633727ac0281d4170b8
> License was upgraded to GPLv3+ to to make it compatible with other projects
> under Apache License 2.0 and also to explicitly make it incompatible with
> existing Freedesktop projects due to misusing of their own CoC to support
> license violation of other projects.

For some context on that issue; see:
* https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2235
* https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/664
* https://bugs.gentoo.org/785634

Most of the difference between 0.2.0 and 0.2.1 is this license change; see 
https://github.com/pali/libopenaptx/compare/0.2.0...0.2.1

In the rest of the changes, there's also a patch I proposed, which is already
in the 0.2.0-* Debian packaging.

So. Notwithstanding the license change (which, at first glance, don't seem
acceptable for Debian), the rest of the updates don't justify upgrading this
package to 0.2.1, so I'm (as maintainer) tagging this as +wontfix.

Bug#989306: cups-filters: parallel port modules force included on ARM kernels

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Hello Jonathan, and thanks for your bugreport,

It might be very old, but it was apparently never properly reported to Debian; 
so thanks for that!

Le lundi, 31 mai 2021, 20.28:39 h CEST Jonathan Lane a écrit :
> The file /etc/modules-load.d/cups.conf contains invocations to load
> modules lp, ppdev, and parport_pc, which are unavailable on the latest
> arm64 kernels in Debian 10, and will likely remain so forever, at least
> parport_pc, because ARM systems do not have PC parallel ports.  This
> results in systemd-load-modules.service reporting failure every boot.
> The fix is only including this file on architectures where those kernel
> modules are meaningful.  This is a very old bug and appears to be a
> regression, since it was known at least as far back as 2015 by the
> Ubuntu maintainers.

Would the attached patch solve this bug meaningfully? It seems to work as-is 
on amd64; could you confirm it's working on arm*?

Best,
OdyX>From 9a629787fd476efceb1885bc6fe9c9df336c689b Mon Sep 17 00:00:00 2001
From: Didier Raboud 
Date: Wed, 2 Jun 2021 20:33:19 +0200
Subject: [PATCH] Only install /etc/modules-load.d/cups-filters.conf in amd64
 i386 mips64el mipsel alpha hppa ia64 sparc64

Closes: #989306
---
 debian/rules | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 30b23d06d..7246a2fe1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
@@ -48,8 +50,11 @@ else
 	rsvg-convert debian/local/default-testpage-debian.svg -f pdf > debian/cups-filters/usr/share/cups/data/default-testpage.pdf
 endif
 
-	# Install the modules loader for lp, ppdev and parport_pc
+# Known not-present: m68k hurd-i386 kfreebsd-{amd64,i386}
+ifneq ($(filter $(DEB_HOST_ARCH),amd64 i386 mips64el mipsel alpha hppa ia64 sparc64),)
+	# Install the modules loader for lp, ppdev and parport_pc, only on allow-listed architectures where these are known-present
 	install -D -m 644 debian/local/modules-load.conf debian/cups-filters/etc/modules-load.d/cups-filters.conf
+endif
 
 	dh_apparmor -pcups-browsed --profile-name=usr.sbin.cups-browsed
 
-- 
2.32.0.rc2

Bug#989161: [pre-approval] unblock: cups/2.3.3op2-3+deb11u1

[Didier 'OdyX' Raboud]

Control: tags -1 -moreinfo

Le vendredi, 28 mai 2021, 23.21:56 h CEST Sebastian Ramacher a écrit :
> On 2021-05-27 09:03:49 +0200, Didier 'OdyX' Raboud wrote:
> > unblock cups/2.3.3op2-3+deb11u1
> 
> ACK, please remove the moreinfo tag once the new version is available in
> unstable.

Got the "Accepted cups 2.3.3op2-3+deb11u1 (source) into unstable" email, 
removing the tag.

Thanks for your work!

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#989073: cups: Samsung ML-1640 USB printer not working, needs longer USB timeout

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le mardi, 25 mai 2021, 11.00:59 h CEST Mikko Rapeli a écrit :
> Latest cups from unstable doesn't work with old USB printers anymore.
> At least Samsung ML-1640 just prints an error like
> "INTERNAL ERROR - Incomplete Session by time out".
> 
> Root cause seems to be:
> 
> https://bbs.archlinux.org/viewtopic.php?id=265299
> 
> https://github.com/OpenPrinting/cups/pull/160/commits/d2f41769f208729438414c
> 76983385f0f13ef9b7
> 
> After applying this patch printing works again:
> 
> src/cups-2.3.3op2# diff -up backend/usb-libusb.c_orig backend/usb-libusb.c
> --- backend/usb-libusb.c_orig 2021-05-25 11:41:02.981961321 +0300
> +++ backend/usb-libusb.c  2021-05-25 11:42:39.990717869 +0300
> @@ -1704,7 +1704,7 @@ static void *read_thread(void *reference
>  readstatus = libusb_bulk_transfer(g.printer->handle,
> g.printer->read_endp,
> readbuffer, rbytes,
> -   , 250);
> +   , 6);
>  if (readstatus == LIBUSB_SUCCESS && rbytes > 0)
>  {
>fprintf(stderr, "DEBUG: Read %d bytes of back-channel data...\n",
> (int)rbytes);
> 
> Please consider applying this, thanks.

Hello Mikko, and thanks for your bugreport,

This is indeed a USB printing regression, and I just filed an unblock request 
to get this fixed in Bullseye. I'll upload to experimental now too.

Best regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#989161: [pre-approval] unblock: cups/2.3.3op2-3+deb11u1

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: c...@packages.debian.org

Please approve the following update for src:cups

[ Reason ]
Mikko Rapeli reported a USB printing regression in #989073, which, lukily
enough, was already reported and fixed upstream. It matters for Bullseye's
quality to ensure smooth USB printing.

[ Impact ]
Failure to print without comprehensible error messages nor configurable ways
to fix USB printing.

[ Tests ]
There are none, but as you'll see, these patches merely extend timeouts; also,
they have been reviewed and merged upstream, by the long-term upstream author,
Michael Sweet.

[ Risks ]
Given the trivialness of the patches as well as the extended review, I
consider the risks to be negligible.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I'm also attaching the "direct" patches, as my use of git debrebase produces a
noisy debdiff. I have also picked the 2.3.3op2-3+deb11u1 version, as
2.3.3op2-4 was already uploaded in experimental; please advise if a change is
needed.

Many thanks for your work!

unblock cups/2.3.3op2-3+deb11u1
From: Zdenek Dohnal 
Date: Tue, 13 Apr 2021 15:44:14 +0200
Subject: backend/usb-libusb.c: Use 60s timeout for reading at backchannel

Some older models malfunction if timeout is too short.

Origin: upstream, https://github.com/OpenPrinting/cups/pull/174
Bug: https://github.com/OpenPrinting/cups/issues/160
Bug-Debian: https://bugs.debian.org/989073
---
 backend/usb-libusb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/backend/usb-libusb.c b/backend/usb-libusb.c
index d6b0eb4..fbb0d9d 100644
--- a/backend/usb-libusb.c
+++ b/backend/usb-libusb.c
@@ -1704,7 +1704,7 @@ static void *read_thread(void *reference)
 readstatus = libusb_bulk_transfer(g.printer->handle,
  g.printer->read_endp,
  readbuffer, rbytes,
- , 250);
+ , 6);
 if (readstatus == LIBUSB_SUCCESS && rbytes > 0)
 {
   fprintf(stderr, "DEBUG: Read %d bytes of back-channel data...\n", 
(int)rbytes);
From: Zdenek Dohnal 
Date: Tue, 13 Apr 2021 15:47:37 +0200
Subject: backend/usb-libusb.c: Revert enforcing read limits

This commit reverts the change introduced by 2.2.12 [1] - its
implementation caused a regression with Lexmark filters.

[1] 
https://github.com/apple/cups/commit/35e927f83529cd9b4bc37bcd418c50e307fced35

Origin: upstream, https://github.com/OpenPrinting/cups/pull/174
Bug: https://github.com/OpenPrinting/cups/issues/72
---
 backend/usb-libusb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/backend/usb-libusb.c b/backend/usb-libusb.c
index fbb0d9d..89b5182 100644
--- a/backend/usb-libusb.c
+++ b/backend/usb-libusb.c
@@ -1721,7 +1721,8 @@ static void *read_thread(void *reference)
 * Make sure this loop executes no more than once every 250 miliseconds...
 */
 
-if ((g.wait_eof || !g.read_thread_stop))
+if ((readstatus != LIBUSB_SUCCESS || rbytes == 0) &&
+(g.wait_eof || !g.read_thread_stop))
   usleep(25);
   }
   while (g.wait_eof || !g.read_thread_stop);
diff -Nru cups-2.3.3op2/debian/changelog cups-2.3.3op2/debian/changelog
--- cups-2.3.3op2/debian/changelog  2021-02-12 14:09:29.0 +0100
+++ cups-2.3.3op2/debian/changelog  2021-05-27 08:49:36.0 +0200
@@ -1,3 +1,12 @@
+cups (2.3.3op2-3+deb11u1) unstable; urgency=medium
+
+  * Backport 2 upstream USB backend fixes:
+- Revert enforcing read limits (caused a regression with Lexmark filters)
+- Use 60s timeout (instead of 250ms) for reading at backchannel, as some
+  older models malfunction if timeout is too short (Closes: #989073)
+
+ -- Didier Raboud   Thu, 27 May 2021 08:49:36 +0200
+
 cups (2.3.3op2-3) unstable; urgency=medium
 
   [ Helge Kreutzmann ]
diff -Nru 
cups-2.3.3op2/debian/patches/0001-backend-usb-libusb.c-Use-60s-timeout-for-reading-at-.patch
 
cups-2.3.3op2/debian/patches/0001-backend-usb-libusb.c-Use-60s-timeout-for-reading-at-.patch
--- 
cups-2.3.3op2/debian/patches/0001-backend-usb-libusb.c-Use-60s-timeout-for-reading-at-.patch
1970-01-01 01:00:00.0 +0100
+++ 
cups-2.3.3op2/debian/patches/0001-backend-usb-libusb.c-Use-60s-timeout-for-reading-at-.patch
2021-05-27 08:49:36.0 +0200
@@ -0,0 +1,26 @@
+From: Zdenek Dohnal 
+Date: Tue, 13 Apr 2021 15:44:14 +0200
+Subject: backend/usb-libusb.c: Use 60s timeout for reading at backchannel
+
+Some older models malfunction if timeout is too short.
+
+Origin: upstream, https://github.com/OpenPrinting/cups/pull/174
+Bug: https://github.com/OpenPrinting/cups/issues/160
+Bug-Debian: https://bugs.debian.org/989073
+---
+ backend/usb-libusb.c | 2 +-
+ 1 file changed, 1 

Bug#988764: cups-browsed: apparmor blocks access to /usr/share/{cups/,}/locale

[Didier 'OdyX' Raboud]

Le vendredi, 21 mai 2021, 16.26:12 h CEST Mike Gabriel a écrit :
> Basically, why not? It clutters syslog. It probably won't have
> functional consequences, but still...

Well. At this point of the freeze, I'd rather not burden the release team with 
such a non-"critical, grave, or serious" bug.

https://lists.debian.org/debian-devel-announce/2021/05/msg0.html was 19 
days ago, and has
> As the release draws nearer, fixes for non-RC bugs which do not affect a
> package's general usability will increasingly be deferred or rejected.

Feel free to ask if you feel strongly enough about this, I'll upload if it's 
accepted!

Cheers,
-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#988764: cups-browsed: apparmor blocks access to /usr/share/{cups/,}/locale

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Hello Mike, and thanks for your patch-provided bugreport.

Le mercredi, 19 mai 2021, 12.33:10 h CEST Mike Gabriel a écrit :
> With CUPS on buster and bullseye I see these messages in /var/log/syslog:
> 
> May 19 12:26:12 server03 kernel: [4563725.605605] audit: type=1400
> audit(1621419972.056:193): apparmor="DENIED" operation="open"
> profile="/usr/sbin/cups-browsed" name="/usr/share/cups/locale/"
> pid=17771 comm="cups-browsed" requested_mask="r" denied_mask="r"
> fsuid=0 ouid=0
> May 19 12:26:12 server03 kernel: [4563725.606138] audit: type=1400
> audit(1621419972.056:194): apparmor="DENIED" operation="open"
> profile="/usr/sbin/cups-browsed" name="/usr/share/locale/" pid=17771
> comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> May 19 12:27:08 server03 systemd[1]: cups-browsed.service: Succeeded.
> 
> 
> These error messages / folder access blocks can be amended by this
> change in /etc/apparmor.d/usr.sbin.cups-browsed: (…)

I'll upload to experimental in a moment. I assume it doesn't warrant rising 
severity and aiming at Bullseye, right?

Best,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#988434: (Future) FTBFS cups-filters with OpenLDAP 2.5

[Didier 'OdyX' Raboud]

Control: tags -1 +patch +pending

Hello Sergio, and thanks for your bugreport!

Le jeudi, 13 mai 2021, 03.17:54 h CEST Sergio Durigan Junior a écrit :
> We are working towards getting the new OpenLDAP version ready (2.5,
> which will soon be uploaded to experimental) and noticed that
> cups-filters FTBFS with it.  Upstream also noticed it and promptly fixed
> the problem.  I took the liberty to grab the patch, apply to the current
> version of cups-filters that is in experimental, and now I'm sending you
> the debdiff :-).

Excellent, thanks!

> FWIW, I was planning to create a Merge Request against the project on
> salsa, but it looks like the git repository hasn't been updated and
> doesn't reflect the current state of the package, so I thought it'd be
> better to open this bug.  Let me know if you prefer an MR and I will be
> happy to provide it after the repository is updated.

Hrm. The repository _is_ up-to-date, when looking at the correct branches :-)

https://salsa.debian.org/printing-team/cups-filters/-/tree/debian/experimental

In any case, I have now cherry-picked the patch and will upload to Debian 
experimental after a local test-build.

Best regards, and thanks for your work!
-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#987493: unblock: gutenprint/5.3.3-5

[Didier 'OdyX' Raboud]

Control: tags -1 -moreinfo

Le dimanche, 25 avril 2021, 11.37:23 h CEST Graham Inggs a écrit :
> On Sat, 24 Apr 2021 at 17:48, Didier 'OdyX' Raboud  wrote:
> > This is a pre-approval request for package package gutenprint.
> 
> Please go ahead and upload, and remove the moreinfo tag once the new
> version is available in unstable.

Hello Graham,

Thanks for your prompt ack and your work as release team member!

Uploaded, and built already for most archs.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#987493: unblock: gutenprint/5.3.3-5

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gutenpr...@packages.debian.org

This is a pre-approval request for package package gutenprint.

[ Reason ]
It was reported on #987457 that the gutenprint-locales packages contained no…
locales. This has apparently slipped through almost a full release cycle.

Anyway. I'd like to fix this in unstable, by building and installing the .mo
files.

[ Impact ]
No translations for gutenprint.

[ Tests ]
The patch I propose adds a non-regression test in dh_install.

[ Risks ]
I can't think of any, besides taking more disk-space for potentially unused
translations.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

unblock gutenprint/5.3.3-5
diff -Nru gutenprint-5.3.3/debian/changelog gutenprint-5.3.3/debian/changelog
--- gutenprint-5.3.3/debian/changelog   2020-02-17 08:36:42.0 +0100
+++ gutenprint-5.3.3/debian/changelog   2021-04-24 17:37:27.0 +0200
@@ -1,3 +1,9 @@
+gutenprint (5.3.3-5) unstable; urgency=medium
+
+  * Build and install translations in gettext-locales (Closes: #987457)
+
+ -- Didier Raboud   Sat, 24 Apr 2021 17:37:27 +0200
+
 gutenprint (5.3.3-4) unstable; urgency=medium
 
   * Backport upstream patch:
diff -Nru gutenprint-5.3.3/debian/rules gutenprint-5.3.3/debian/rules
--- gutenprint-5.3.3/debian/rules   2020-02-17 08:36:42.0 +0100
+++ gutenprint-5.3.3/debian/rules   2021-04-24 17:37:27.0 +0200
@@ -26,9 +26,15 @@
  $(MAINTAINER_MODE) \
  --enable-nls
 
+execute_after_dh_auto_build-indep:
+   # Build the gettext translations (#987457)
+   cd po && make update-gmo
+
 override_dh_install-indep:
dh_install -i
rm -f debian/gutenprint-locales/usr/share/locale/*/*.po
+   # Make sure at least some locales are installed (#987457)
+   test -n "$$(find debian/gutenprint-locales/usr/share/locale -name 
gutenprint.mo)"
 
 override_dh_installdocs:
dh_installdocs -pescputil --link-doc=libgutenprint9

Bug#987457: gutenprint-locales is empty

[Didier 'OdyX' Raboud]

Control: tags -1 +patch +pending

Le samedi, 24 avril 2021, 11.10:04 h CEST Adrian Bunk a écrit :
> Package: gutenprint-locales
> Version: 5.3.1-7
> Severity: grave
> 
> $ dpkg -L gutenprint-locales

Hello Adrian,

I'm not sure I agree with the severity; but it certainly needs fixing!

I'm going to ask for an unblock with the following patch, feedback welcome.

--- a/debian/rules
+++ b/debian/rules
@@ -26,9 +26,15 @@ override_dh_auto_configure:
  $(MAINTAINER_MODE) \
  --enable-nls
 
+execute_after_dh_auto_build-indep:
+   # Build the gettext translations (#987457)
+   cd po && make update-gmo
+
 override_dh_install-indep:
dh_install -i
rm -f debian/gutenprint-locales/usr/share/locale/*/*.po
+   # Make sure at least some locales are installed (#987457)
+   test -n "$$(find debian/gutenprint-locales/usr/share/locale -name 
gutenprint.mo)"
 
 override_dh_installdocs:
dh_installdocs -pescputil --link-doc=libgutenprint9


OdyX


signature.asc
Description: This is a digitally signed message part.

Bug#986532: unblock: ipp-usb/0.9.17-3

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ipp-...@packages.debian.org

Please unblock package ipp-usb

[ Reason ]
It adds a NEWS.Debian useful for upgrades' understanding (see #978561)

[ Impact ]
If not unblocked, we expect more support (via bugs) to explain how ipp-usb
and other usb-holding drivers will interact.

[ Other info ]
ipp-usb/0.9.17-3 was uploaded on March 5, in Soft freeze, but was "forgotten",
and/or had running autopkgtests. Anyway, here we are and it should be
unblocked.

Thanks in advance!

unblock ipp-usb/0.9.17-3
diff -Nru ipp-usb-0.9.17/debian/changelog ipp-usb-0.9.17/debian/changelog
--- ipp-usb-0.9.17/debian/changelog 2021-02-21 18:02:51.0 +0100
+++ ipp-usb-0.9.17/debian/changelog 2021-03-05 16:40:13.0 +0100
@@ -1,3 +1,9 @@
+ipp-usb (0.9.17-3) unstable; urgency=medium
+
+  * Add a NEWS entry to clarify ipp-usb's purpose (Closes: #978561)
+
+ -- Brian Potkin   Fri, 05 Mar 2021 16:40:13 +0100
+
 ipp-usb (0.9.17-2) unstable; urgency=medium
 
   * Let ipp-usb be Multi-Arch: foreign (Closes: #980217)
diff -Nru ipp-usb-0.9.17/debian/NEWS ipp-usb-0.9.17/debian/NEWS
--- ipp-usb-0.9.17/debian/NEWS  1970-01-01 01:00:00.0 +0100
+++ ipp-usb-0.9.17/debian/NEWS  2021-03-05 16:40:13.0 +0100
@@ -0,0 +1,14 @@
+ipp-usb (0.9.17-3) unstable; urgency=medium
+
+  ipp-usb uses the IPP-over-USB protocol to allow the setting up of a
+  driverless print queue for most USB connected modern multi-function
+  and a few modern USB-only devices. The default is to auto-setup the
+  queue with cups-browsed.
+
+  Existing or newly created queues on a USB connection for IPP-over-USB
+  capable devices using vendor drivers will not work while the ipp-usb
+  service is activated and managing the connection. Details are at
+
+  https://wiki.debian.org/CUPSDriverlessPrinting
+
+ -- Brian Potkin   Fri, 05 Mar 2021 16:40:13 +0100

Bug#986165: libcupsimage2: Upgrade fails with `m: cannot remove '/usr/share/doc/libcupsimage2': Directory not empty`

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Dear Paul,

Le mardi, 30 mars 2021, 19.11:07 h CEST Paul Menzel a écrit :
> In a Debian 10 (buster) Docker container upgrading the package
> *libcupsimage2* fails with the error below.

Thanks for your bugreport.

> ```
> # apt full-upgrade
> […]
> Preparing to unpack .../066-libcupsimage2_2.2.10-6+deb10u4_amd64.deb ...
> rm: cannot remove '/usr/share/doc/libcupsimage2': Directory not empty
> dpkg: error processing archive
> /tmp/apt-dpkg-install-XQ7mPL/066-libcupsimage2_2.2.10-6+deb10u4_amd64.deb
> (--unpack):
>   new libcupsimage2:amd64 package pre-installation script subprocess
> returned error exit status 1
> Preparing to unpack .../067-libavahi-common-data_0.7-4+deb10u1_amd64.deb ...
> […]
> # ls /usr/share/doc/libcupsimage2
> changelog.Debian.gz  changelog.gz  copyright
> ```

This seems to be because Debian Docker images setup dpkg to not unpack files 
in /usr/share/doc, but the various debian preinsts try to remove that 
directory before installation. The current CUPS' libcupsimage2 preinst has the 
following lines:

case "$1" in
upgrade)
if [ ! -L /usr/share/doc/libcupsimage2 ]; then
rm -rf /usr/share/doc/libcupsimage2
fi
;;

… These are the ones that fail.

But they have been in CUPS' maintscripts since at least 2005, and I don't see 
their point. If they were ever useful, there have been so many stable releases 
since…

I'll remove these snippets and upload to experimental.

Best regards,

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#954066: hplip (3.21.2+dfsg1-2) affected too

[Didier 'OdyX' Raboud]

Le mardi, 30 mars 2021, 19.49:24 h CEST user2304 a écrit :
> Dear Maintainer,
> 
> just a quick note, after dist-upgrading my testing-system, version of hplip
> changed to 3.21.2.
> 
> File /usr/share/hplip/data/models/models.dat is changed back to wrong model-
> name "[hp_laserjet_cp1025]" instead of "[hp_laserjet_cp_1025]".

That's normal; files in /usr/share are not dpkg conffiles, and local 
modifications will get overwritten.

Sorry, but this change won't make it in Debian bullseye; modifying upstream 
data files for such bugs is too risky (in that instance; where this looks like 
a parsing bug).

Regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le vendredi, 26 février 2021, 15.41:07 h CET Bernhard Übelacker a écrit :
> Dear Maintainer,
> with the original PPD and input files from Ian I could
> reproduce the issue and with the help of rr-debugger
> this is what I assume what happens:
> 
> - The buffer m_pPrinterBuffer is allocated here with
>the current sizes inside cups_header. [1]
> 
> - The first page got processed and for the second page
>a new cups_header record gets copied. [2]
>Unfortunately now the header contains higher sizes,
>but the buffer is not grown accordingly.
> 
> - Now to this buffer is written by a read function, and beyond
>where the management information of malloc got overwritten for
>some other random memory. [3]
> 
> - The defect in the management information of malloc is detected
>and the process is aborted. [4]
> 
> 
> The attached patch is an attempt to grow the buffer size
> if the header changes on a new page.
> This is just tested for the given crash, nothing more, therefore
> there might be side effects on replacing this buffer?

I have forwarded this upstream, but don't hold your breath; I don't expect any 
feedback from them, sadly. :-(

I'll apply this and upload to unstable once the current version migrated.

Thanks a lot for your work!

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#983491: Keyboard Layout configuration wizard - Swiss localization

[Didier 'OdyX' Raboud]

Hello Mark,

Le mercredi, 24 février 2021, 21.31:43 h CET hispeedhsx a écrit :
> I'm new to Debian and I switch from centos but I have seen this problem for
> now several years and in several distributions even I think freebsd has it
> wrong (in my opinion).
> 
> So I'm from Switzerland and I use a "Swiss Keyboard". We have people who are
> talk and write in french and italian. There are also several people writing
> rumantsch which is a little bit special.

Swiss DD here; cc'ing debian-switzerland@ for further comments if needed

> When I see the keyboards layouts in the installer from
> debian-10.8.0-amd64-netinst I see there that Debian has a "Schweizerisches
> Französisch / Swiss French" and a "Schweizerdeutsch / Swiss German"
> keyboard layout.
> 
> There is one problem with this: In Switzerland we only have 1 hardware
> keyboard layout. Italian, German and French speaking people use this
> layout.

Although Switzerland indeed has only one hardware keyboard layout (the 
keyboard markings can be identical), it has (at least) two software 
interpretations, around the right part of the keyboard.

Specifically, the en_US "; / :" key will be:
 - "é / ö" in the Swiss French variant
 - "ö / é" in the Swiss German variant

There at least two other keys with such fr <> de swaps.

See
https://en.wikipedia.org/wiki/
QWERTZ#Switzerland_(German,_French,_Italian,_Romansh),_Liechtenstein,_Luxembourg

> In short there is only one keyboard and this has to be called: Swiss =
> Schweiz

No.

> If a Swiss person is only writing in french and they don't write often
> german so they will use the AZERTY keyboard which is the same as the French
> people are using for example.

That's really not true. At the very least, it's not _universally_ true for 
french-speaking Swiss people.

As one example, I have learned (in the nineties) and still type on Swiss-
french QWERTZ keyboards, with the é under my right pinky, and so do all the 
people I know from Suisse romande (besides the obvious IT people who might 
have switched to BÉPO or en_US QWERTY). I really don't know of anyone raised 
in Suisse romande typing on AZERTY.

> I will thank you for your responses and inputs. In my opinion this is a bug
> and should be fixed even it just for the small Switzerland.

It should not be fixed, as it's not a bug. Much to the contrary, it is OK as-
is; dropping the french variant of the Swiss QWERTZ keyboard would clearly 
alienate the french-speaking swiss (and the italian-speaking swiss too 
apparently), and deprive them from using their (valid) keyboard layout.

Hereby closing the bug report.

Best regards from Vevey, in Suisse romande.
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Control: found -1 3.21.2+dfsg1-1

Hello there Bernhard,
(CC'ing d-arm for help)

Sadly, I could confirm on a local armhf QEMU instance that this serious bug is 
still present, in sid and bullseye; the steps in
https://bugs.debian.org/972339#10 still apply and trigger the SIGABRT.

Although I understand what you're saying in theoretical terms here, I'm 
completely at loss to propose a patch: I'm way over my head with my 10+years-
old C and gdb competences. In the absence of any interest from upstream, I 
need help to fix hplip on armhf.

(Note that amd64 is apparently also affected; see #974828)

Whoever willing to help; if you need anything from me (as maintainer), please 
ask! I'm happy to explain my use of git-debrebase, or provide a different git 
history if it helps, I mostly don't want to be in the way of a fix!

Humbly,
OdyX

Le samedi, 24 octobre 2020, 14.05:04 h CET Bernhard Übelacker a écrit :
> I could reproduce this issue too.
> 
> Attached is a valgrind run showing one invalid write
> and a gdb session showing the issue.
> 
> It looks like mallocs management data, which resides in the 8 bytes
> before a returned pointer, gets overwritten and therefore
> the free fails because "mchunk_size" is then 0.
> 
> Kind regards,
> Bernhard
> 
> 
> Old value = 6057
> New value = 0
> __memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
> warning: Source file is more recent than executable.
> 295 tst count, #4
> 1: compressBuf =  named `this'> 2: /x *(int*)(0x7f5f43e8-4) = 0x0
> (gdb) bt
> #0  __memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
> #1  0x7f55b8d2 in memcpy (__len=379, __src=,
> __dest=) at
> /usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34 #2 
> Mode9::Process (this=0x7f5e0e70, input=0x7f5e0e84) at
> prnt/hpcups/Mode9.cpp:405 #3  0x7f562de0 in Pipeline::Process
> (raster=, this=0x7f5d7340) at prnt/hpcups/Pipeline.cpp:79 #4
>  Pipeline::Execute (this=0x7f5d7340, InputRaster=) at
> prnt/hpcups/Pipeline.cpp:79 #5  0x7f562e02 in Pipeline::Execute
> (this=0x7f5e6b88, InputRaster=) at
> prnt/hpcups/Pipeline.cpp:83 #6  0x7f562e02 in Pipeline::Execute
> (this=0x7f5e6b70, InputRaster=) at
> prnt/hpcups/Pipeline.cpp:83 #7  0x7f55a20a in
> HPCupsFilter::processRasterData (this=0x7f5b87c4 ,
> cups_raster=) at prnt/hpcups/HPCupsFilter.cpp:766 #8 
> 0x7f55a6ee in HPCupsFilter::StartPrintJob (this=0x7f5b87c4 ,
> argc=6, argv=0xbefff7b4) at prnt/hpcups/HPCupsFilter.cpp:584 #9  0xb6bd9a20
> in __libc_start_main (main=0x7f5587d1 , argc=6,
> argv=0xbefff7b4, init=, fini=0x7f56ed5d <__libc_csu_fini>,
> rtld_fini=0xb6fe1075 <_dl_fini>, stack_end=0xbefff7b4) at libc-start.c:308
> #10 0x7f55889c in _start () at prnt/hpcups/HPCupsFilter.cpp:919
> 
> 
> https://sources.debian.org/src/hplip/3.21.2+dfsg1-1/prnt/hpcups/Mode9.cpp/#L
> 405


-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#983263: 3.21.2 should not migrate automatically (yet)

[Didier 'OdyX' Raboud]

Source: hplip
Version: 3.21.2+dfsg0-1
Severity: serious

As hplip maintainer, I'm hereby making sure that hplip 3.21.2 doesn't migrate
automatically to bullseye. It was uploaded by mistake to unstable, but two
alternatives exist:
- A) Revert to 3.20.11, because the changes are too disruptive;
- B) Allow 3.21.2 in bullseye, because the increased hardware support is worth
 it.

Let's give the autobuilders, autopkgtest runners and Debian sid users some
time in this soft freeze, to see whether there are important regressions
tilting this balance towards A).

OdyX

Bug#980217: ipp-usb: should this be Multi-Arch: foreign?

[Didier 'OdyX' Raboud]

Hello Alexander,

As ipp-usb author; do you have an opinion/advice about this?

Many thanks in advance, cheers,

OdyX

Le samedi, 16 janvier 2021, 12.19:15 h CET Simon McVittie a écrit :
> Package: ipp-usb
> Version: 0.9.16-1
> Severity: minor
> 
> A recent update to wine32:i386 on my amd64 system pulled in libsane1:i386,
> which Recommends ipp-usb. Because ipp-usb is Multi-Arch: no, apt
> interprets this as wanting to install ipp-usb:i386, which conflicts
> with ipp-usb:amd64.
> 
> ipp-usb seems to be a daemon (systemd service) that is contacted via
> IPC, conceptually similar to avahi-daemon, dbus-daemon or cups - which
> hopefully means that it doesn't matter which architecture's ipp-usb
> you have, because libsane1:amd64, libsane1:i386 and libsane1:mipsel
> all speak the same architecture-independent IPC protocol to communicate
> with ipp-usb?
> 
> If that's the case, then ipp-usb should be marked Multi-Arch: foreign,
> which means that libsane1:i386 Recommends: ipp-usb would be satisfied
> by ipp-usb:amd64.



signature.asc
Description: This is a digitally signed message part.

Bug#982838: RoM: win32-loader must not migrate automatically

[Didier 'OdyX' Raboud]

Source: win32-loader
Version: 0.10.5
Severity: serious
X-Debbugs-Cc: debian-b...@lists.debian.org, debian-rele...@lists.debian.org

win32-loader is one of the rare packages always blocked, because it has a
'byhand' counterpart per release: `/debian/tools/win32-loader/{release}`, and
therefore needs a manual action by FTP masters in sync ("around the time of")
with the unblock.

This bug exists to manually block any src:win32-loader migration without a
manual sync from FTP masters.

It'll be updated to be marked "found" in the latest version, and "notfound"
in any version allowed to migrate.

Best, for the win32-loader maintainers,
  OdyX

Bug#982606: unblock: win32-loader/0.10.4

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-b...@lists.debian.org

Please unblock package win32-loader in its 0.10.4 version

[ Reason ]
win32-loader is one of the rare packages always blocked, because it has a
'byhand' counterpart per release: `/debian/tools/win32-loader/{release}`, and
therefore needs a manual action by FTP masters in sync ("around the time of")
with the unblock.

[ Impact ]
It's been since 0.10.1 (September 2020) that it hasn't been migrated, and I (as
co-maintainer), want the 0.10.4 changes in for Bullseye.

[ Tests ]
There are no significant error reports for the version in unstable, I deem
this version as really safe to migrate. If it were a normal package, it would
have migrated for every version.

Please CC ftpmas...@debian.org when granting this unblock, for them to proceed
with their magic.

Best regards, and thanks for your work,
OdyX

unblock win32-loader/0.10.4

P.S. Yes. That's an almost verbatim copy of #967048

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Control: tags -1 +help

Hello there Paul,

Le jeudi, 11 février 2021, 16.55:09 h CET Paul Gevers a écrit :
> On Fri, 16 Oct 2020 14:23:59 +0200 Didier 'OdyX' Raboud wrote:
> > According to the 3.20.9-3 armhf auutopkgtest run for migration testing;
> > https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.g
> > z
> > 
> > hpcups sometimes crashes with free(): invalid pointer. For instance, it
> > seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd'
> > printer will let hpcups crash.
> 
> Just to have the information for the release process, do you think this
> is a regression compared to buster, or did you just found out now
> because of autopkgtest?

I found out because of autopkgtest only. I think it's a real bug (printing a 
test PDF to a specific printer should naturally work), unlikely to be fixed by 
upstream (we carry 77 patches, none of which ever got merged), on a non-
classical architecture. It's very likely not a regression from buster, but I 
couldn't formally confirm this.

> Is there any progress on this issue?

No, and I don't expect to make progress myself there; my C-fu is way too 
limited.

I hope that helps, and sure hope you're well!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#981829: Please remove Julian Andres Klode from uploaders

[Didier 'OdyX' Raboud]

Le jeudi, 4 février 2021, 12.36:32 h CET Julian Andres Klode a écrit :
> Package: src:hplip
> Severity: minor
> X-Debbugs-Cc: j...@debian.org
> 
> Hey folks, I'm not involved in hplip maintenance anymore,
> please remove me from uploaders. Thanks!

Hey Julian,

many thanks for your past hplip work! And thanks for making your maintenance 
removal request explicit!

Upload in progress :-)

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#981394: sane-airscan: zzz

[Didier 'OdyX' Raboud]

Control: retitle -1 sane-airscan: missing dependency on sane-utils
Control: severity -1 important
Control: tags -1 +pending 

Le samedi, 30 janvier 2021, 15.13:25 h CET Brian Potkin a écrit :
> On a system without a SANE frontend or libsane1, sane-airscan is
> effectively useless. I reckon there should be a Depends: on at
> least sane-utils.
> 
> I hope the severity level is not over the top.

Hello there Brian, and thanks for this bug report!

traditionally, dependencies go "top-down"; from tools to libraries, and from 
generic utils to backends, not in reverse. For example, libsane1 is 
effectively useless on its own on my laptop; and it doesn't depend on sane-
utils.

So, this missing dependency doesn't
* makes the package in question unusable by most or all users, or
* causes data loss, or
* introduces a security hole allowing access to the accounts of users who use
  the package
(definition of the "grave" severity).

It _does_ make it a no-op, and useless, but not "unuseable", I'd argue. Also, 
the side-effect of a "grave" severity is that it makes the package subject to 
auto-removal from the next stable release, as "release-critical bug". In other 
words, such a severity marks a package as unfit for release (== the release 
would be better off without this package, rather than with this bug). For all 
these reasons, an "important" severity seems much more adequate (to me).

All this said, I think it's a valid bug, and I'll therehore add a sane-utils 
"Recommends"; this will pull it by default, but not enforce it.

Best regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#980200: ITP: pappl -- C-based framework/library for developing CUPS Printer Applications

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-print...@lists.debian.org

Package name: pappl
Version : 1.0.1
Upstream Author : Michael R Sweet 
URL : hhttps://www.msweet.org/pappl
License : Apache License Version 2.0 with an (optional) exception to 
allow linking against GPL2/LGPL2 software
Programming Lang: C
Description : C-based framework/library for developing CUPS Printer 
Applications

 PAPPL is a simple C-based framework/library for developing CUPS Printer
 Applications, which are the recommended replacement for printer drivers. It
 was specifically developed to support LPrint and a future Gutenprint Printer
 Application but is sufficiently general purpose to support any kind of printer
 or driver that can be used on desktops, servers, and in embedded environments.

I'll be maintaining this under the Debian Printing Team umbrella. Current 
packaging
is hosted at https://salsa.debian.org/printing-team/pappl/.

Bug#980104: cups: reduce Build-Depends

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Hello Helmut, 

First and foremost, thank you so much for your bootstrap work!

Le mercredi, 13 janvier 2021, 20.54:16 h CET Helmut Grohne a écrit :
> cups is involved in a number of dependency cycles relevant to
> architecture bootstrap. Instead of doing the hard work of looking into
> these cycles, I looked for easily droppable build dependencies and found
> some. Given that cups is reproducible, I attempted dropping individual
> dependencies via  and compared the resulting .debs with those
> of a regular build. It turns out that a lot of dependencies can be thus
> marked without affecting build results:
>  * ghostscript
>  * libavahi-compat-libdnssd-dev
>  * libfontconfig1-dev
>  * libfreetype6-dev
>  * libijs-dev
>  * libjpeg-dev
>  * libldap2-dev
>  * libpng-dev
>  * libtiff-dev
>  * poppler-utils
>  * sharutils
> 
> There are two possible mistakes being made here: For some dependencies,
> a fallback mechanism (e.g. vendored code copy) can be available. Thus it
> might be that not everything listed above should be tagged .
> It also could be that some of these depenencies really are entirely
> unused. In that case, they should simply be dropped instead.

It seems you're right for all these!

I did some tests, including with Salsa CI, and I concur with your analysis; 
these are all likely outdated, now-superfluous Build-Dependencies.

I don't have any recollection of embedded vendoring, or code copies in CUPS, 
and would expect them to have been caught over the course of years.

Given this is all easily reversible, I'll just drop the Build-Depends as of 
now, and see where that leads.

> Beyond this, dh_apparmor is only used when cups-daemon is built. It can
> be dropped for indep-only builds.

About this too!

> Please consider applying and improving the attached patch.

Will do, thanks again!

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#980036: RM: plasma-applet-redshift-control -- ROM; Superseded by Plasma 5.17

[Didier 'OdyX' Raboud]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-qt-...@lists.debian.org

plasma-applet-redshift is a relic from an old era, before Plasma 5.17
integrated this very functionality.

It should be removed now.

Thanks in advance, best regards,

Didier

Bug#979461: Updated Homepage: header?

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le mercredi, 6 janvier 2021, 23.04:26 h CET Moritz Muehlenhoff a écrit :
> Now that src:cups follows the openprinting fork, Homepage: should also point
> to https://github.com/OpenPrinting/cups/ I suppose?

You're absolutely right. Committed and pushed.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#977198: cups service should start after nslcd service

[Didier 'OdyX' Raboud]

Ah nice.  Note that there's a typo (networ.service), and that an override 
doesn't need to copy all the lines from the original file.

Le December 18, 2020 3:29:52 PM UTC, Wolfgang Schweer  a 
écrit :
>Hi Didier,
>
>[ Didier 'OdyX' Raboud, 2020-12-18 ]
>> Therefore, instead of patching CUPS for each-and-every user
>authentication/
>> provisioning service, could Debian Edu provide a systemd override
>file 
>> instead?
>
>Yes, that has already been done, see:
>https://salsa.debian.org/debian-edu/debian-edu-config/-/commit/665390a69a5e641a83da7225e6b5f62617320ce9
> 
>> I have pushed this patch proposal to the (new) upstream:
>> 
>> https://github.com/OpenPrinting/cups/pull/69
>> 
>> Of course, if upstream accepts this, I'll backport and upload to
>Debian.
>
>Thanks a lot for caring,
>
>Wolfgang

Bug#977198: cups service should start after nslcd service

[Didier 'OdyX' Raboud]

Control: forwarded -1 https://github.com/OpenPrinting/cups/pull/69
Control: tags -1 +patch

Le samedi, 12 décembre 2020, 13.38:52 h CET Wolfgang Schweer a écrit :
> while working on Debian Edu 11 Bullseye, I noticed the cups service
> failing randomly after rebooting the system (…):
> 
> Debian Edu uses an LDAP group printer-admins in cups-files.conf like so:
> 
> SystemGroup lpadmin printer-admins
> 
> Please note that Debian Edu uses nslcd.

Therefore, instead of patching CUPS for each-and-every user authentication/
provisioning service, could Debian Edu provide a systemd override file 
instead?

Something like /etc/systemd/system/cups.service.d/debian-edu-nslcd.conf

[Unit]
Description=CUPS Scheduler service dependencies update for Debian Edu
After=nslcd.service

> After adding the nslcd.service (in addition to sssd.service and
> ypbind.service) to the cups.service unit file, things work like
> expected, this is the proposed change:
> 
> diff --git a/scheduler/cups.service.in b/scheduler/cups.service.in
> index 9e70b2973..a3fa0e83f 100644
> --- a/scheduler/cups.service.in
> +++ b/scheduler/cups.service.in
> @@ -1,7 +1,7 @@
>  [Unit]
>  Description=CUPS Scheduler
>  Documentation=man:cupsd(8)
> -After=network.target sssd.service ypbind.service
> +After=network.target sssd.service ypbind.service nslcd.service
>  Requires=cups.socket
> 
>  [Service]
> 
> Please check if the change could be accepted.

I have pushed this patch proposal to the (new) upstream:

https://github.com/OpenPrinting/cups/pull/69

Of course, if upstream accepts this, I'll backport and upload to Debian.

Best regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#976018: buster-pu: package cups/2.2.10-6+deb10u4

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-print...@lists.debian.org

#961345 affects Debian stable for certain printers/conditions; it's a daemon
crash with "invalid free()". As far as I could tell, it's likely a regression,
but due to causes external to CUPS.

This is the proposed changelog entry:
cups (2.2.10-6+deb10u4) buster; urgency=medium

  * Backport upstream fix:
- backend,scheduler/ipp.c: Fix 'printer-alert' invalid free
  (Closes: #961345)

 -- Didier Raboud   Sat, 28 Nov 2020 12:09:48 +0100

The only backported patch is from https://github.com/OpenPrinting/cups/pull/43,
which got merged upstream. Full debdiff attached.

Could I upload?

Cheers,

OdyX
diff -Nru cups-2.2.10/debian/changelog cups-2.2.10/debian/changelog
--- cups-2.2.10/debian/changelog2020-04-25 16:27:21.0 +0200
+++ cups-2.2.10/debian/changelog2020-11-28 12:09:48.0 +0100
@@ -1,3 +1,11 @@
+cups (2.2.10-6+deb10u4) buster; urgency=medium
+
+  * Backport upstream fix:
+- backend,scheduler/ipp.c: Fix 'printer-alert' invalid free
+  (Closes: #961345)
+
+ -- Didier Raboud   Sat, 28 Nov 2020 12:09:48 +0100
+
 cups (2.2.10-6+deb10u3) buster; urgency=medium
 
   * Backport upstream security fixes:
diff -Nru cups-2.2.10/debian/.git-dpm cups-2.2.10/debian/.git-dpm
--- cups-2.2.10/debian/.git-dpm 2020-04-25 16:27:21.0 +0200
+++ cups-2.2.10/debian/.git-dpm 2020-11-28 11:47:32.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-f1b7b7e074291c85366a60f7a197dea19e62c9cf
-f1b7b7e074291c85366a60f7a197dea19e62c9cf
+e512765460ec633ad43872436b243021f252a69a
+e512765460ec633ad43872436b243021f252a69a
 25b2338346ef3abbb93ea88476887cba7b2b86f8
 25b2338346ef3abbb93ea88476887cba7b2b86f8
 cups_2.2.10.orig.tar.gz
diff -Nru 
cups-2.2.10/debian/patches/0052-backend-scheduler-ipp.c-Fix-printer-alert-invalid-fr.patch
 
cups-2.2.10/debian/patches/0052-backend-scheduler-ipp.c-Fix-printer-alert-invalid-fr.patch
--- 
cups-2.2.10/debian/patches/0052-backend-scheduler-ipp.c-Fix-printer-alert-invalid-fr.patch
  1970-01-01 01:00:00.0 +0100
+++ 
cups-2.2.10/debian/patches/0052-backend-scheduler-ipp.c-Fix-printer-alert-invalid-fr.patch
  2020-11-28 11:47:32.0 +0100
@@ -0,0 +1,46 @@
+From e512765460ec633ad43872436b243021f252a69a Mon Sep 17 00:00:00 2001
+From: Zdenek Dohnal 
+Date: Mon, 9 Nov 2020 07:40:20 +0100
+Subject: backend,scheduler/ipp.c: Fix 'printer-alert' invalid free
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The fix is created by Bernhard Übelacker from apple/cups #5826.
+
+Bug-Upstream: https://github.com/OpenPrinting/apple/pull/5826
+Bug-Upstream: https://github.com/OpenPrinting/cups/pull/43
+Bug-Debian: https://bugs.debian.org/961345
+---
+ backend/ipp.c   | 2 +-
+ scheduler/ipp.c | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/backend/ipp.c b/backend/ipp.c
+index bc678f50a..3b65ea3af 100644
+--- a/backend/ipp.c
 b/backend/ipp.c
+@@ -3056,7 +3056,7 @@ report_printer_state(ipp_t *ipp) /* I - IPP response */
+   * Report alerts and messages...
+   */
+ 
+-  if ((pa = ippFindAttribute(ipp, "printer-alert", IPP_TAG_TEXT)) != NULL)
++  if ((pa = ippFindAttribute(ipp, "printer-alert", IPP_TAG_STRING)) != NULL)
+ report_attr(pa);
+ 
+   if ((pam = ippFindAttribute(ipp, "printer-alert-message",
+diff --git a/scheduler/ipp.c b/scheduler/ipp.c
+index 9be8a7f3b..cb12d49c4 100644
+--- a/scheduler/ipp.c
 b/scheduler/ipp.c
+@@ -4908,8 +4908,8 @@ copy_printer_attrs(
+   }
+ 
+   if (printer->alert && (!ra || cupsArrayFind(ra, "printer-alert")))
+-ippAddString(con->response, IPP_TAG_PRINTER, IPP_TAG_STRING,
+- "printer-alert", NULL, printer->alert);
++ippAddOctetString(con->response, IPP_TAG_PRINTER,
++ "printer-alert", printer->alert, 
(int)strlen(printer->alert));
+ 
+   if (printer->alert_description &&
+   (!ra || cupsArrayFind(ra, "printer-alert-description")))
diff -Nru cups-2.2.10/debian/patches/series cups-2.2.10/debian/patches/series
--- cups-2.2.10/debian/patches/series   2020-04-25 16:27:21.0 +0200
+++ cups-2.2.10/debian/patches/series   2020-11-28 11:47:32.0 +0100
@@ -49,3 +49,4 @@
 0049-CVE-2019-2228-Fix-ippSetValueTag-validation-of-defau.patch
 0050-CVE-2020-3898-heap-buffer-overflow-in-libcups-s-ppdF.patch
 0051-CVE-2019-8842-The-ippReadIO-function-may-under-read-.patch
+0052-backend-scheduler-ipp.c-Fix-printer-alert-invalid-fr.patch

Bug#970725: cups-client: lpoptions fails to get printer options

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le dimanche, 22 novembre 2020, 19.29:54 h CET Brian Potkin a écrit :
> found 970725 2.3.3op1-106-ga72b0140e-1
> thanks
> 
> It is not too surprising to still find the described behaviour in
> the experimental version of cups-client as it contains the patch
> "Make lpoptions list a printer's options correctly also when CUPS
> is running on an alternative port".

You're right. This patch was in the Ubuntu fork (to work best in Ubuntu snaps 
I guess), which I imported.

So I forwarded to (the new) upstream there
https://github.com/OpenPrinting/cups/pull/39

… where it got put to doubt by Michael Sweet (upstream author).

So I'll remove it from unstable and experimental.

Cheers,

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#973951: ipp-usb: Fails to restart

[Didier 'OdyX' Raboud]

Control: tags -1 +pending +upstream

Le vendredi, 20 novembre 2020, 16.30:40 h CET Jindřich Makovička a écrit :
> Without arguments, ipp-usb runs in the foreground, so the service type
> should be set to simple instead of oneshot.
> 
> [Service]
> Type=simple
> ExecStart=/sbin/ipp-usb udev

You're absolutely right; that should fix this! I'll forward this upstream too.

Regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#974603: diff NMU for colobot_0.1.12-6.1

[Didier 'OdyX' Raboud]

Dear Anton,

Le jeudi, 12 novembre 2020, 22.04:45 h CET Anton Gladky a écrit :
> I have prepared an NMU (versioned as 0.1.12-6.1) and
> uploaded to DELAYED/10.
> 
> Please feel free to tell me if I should delay it longer, cancel
> or reschedule.

Thanks a lot for your patch and upload. I've imported your patch (it's 
identical to an upstream commit, so I've imported this one, but credited you), 
and will upload later today.

Thanks for your work!

Best regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#973881: Result of 'git debrebase make-patches' with 'diff.noprefix' git config confuses dgit

[Didier 'OdyX' Raboud]

Control: retitle -1 Result of 'git debrebase make-patches' with 'diff.noprefix' 
git config confuses dpkg-buildpackage

Le lundi, 9 novembre 2020, 02.31:38 h CET Sean Whitton a écrit :
> On Fri 06 Nov 2020 at 03:19PM +01, Didier 'OdyX' Raboud wrote:
> > Package: git-debrebase
> > Version: 9.12
> > Severity: normal
> > 
> > Hello there,
> > 
> > after toggling a git diff option globally with:
> > git config --global diff.noprefix true
> > 
> > I noticed that dgit (at least build-source, but others too) started to
> > fail
> > comparing patches-applied with patches-unapplied trees.
> > 
> > I'm reporting this against git debrebase, because it seems to me that git
> > debrebase ought to always format patches in a known-to-work format, no
> > matter what the user has configured for his personal git usage.
> 
> Could you provide steps to reproduce, please?

Sure. Sorry, I should have done this upfront. Here goes; in a debian:sid
docker image:

# apt update && apt upgrade -y && apt install -y devscripts git-debrebase
# git config --global diff.noprefix true
# git clone https://salsa.debian.org/printing-team/cups-filters.git
# cd cups-filters
# gbp buildpackage -S -d
# git debrebase; git debrebase conclude; git debrebase make-patches
# dpkg-buildpackage -S

The error is:

dpkg-buildpackage: info: source package cups-filters
dpkg-buildpackage: info: source version 1.28.5-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Didier Raboud 
 dpkg-source --before-build .
dpkg-source: error: none of the filenames in ---/+++ are valid in diff 
'cups-filters/debian/patches/0001-Force-set-INITDIR-in-configure.ac-instead-of-relying.patch'
 (line 13)
dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit 
status 255


So it seems that it's unrelated with `dgit`; dpkg-buildpackage -S
already gets confused

> If you could give us a particular commit hash to check out of a
> repository somewhere to start with, that would be good.

cups-filters' above is 4a6df4ccff9e03623778011ab6554194efc1f325

Best regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#973881: Result of 'git debrebase make-patches' with 'diff.noprefix' git config confuses dgit

[Didier 'OdyX' Raboud]

Package: git-debrebase
Version: 9.12
Severity: normal

Hello there,

after toggling a git diff option globally with:
git config --global diff.noprefix true

I noticed that dgit (at least build-source, but others too) started to fail
comparing patches-applied with patches-unapplied trees.

I'm reporting this against git debrebase, because it seems to me that git
debrebase ought to always format patches in a known-to-work format, no matter
what the user has configured for his personal git usage.

Cheers,
OdyX

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Control: forwarded -1 https://bugs.launchpad.net/hplip/+bug/1901209

Le vendredi, 23 octobre 2020, 09.42:59 h CEST Didier 'OdyX' Raboud a écrit :
> As this is testable at build-time, I'll add a test for this and upload this
> to experimental. I'll report this to upstream today.

Damn. It seems the bug doesn't trigger in buildd environments. I have also 
tried building hplip on the abel.debian.org porterbox, and the build-time test 
doesn't fail there.

So it seems that there's a reproductible bug when run:
- in qemu
- in ci.debian.net's 
- in a sid chroot in abel.debian.org

… but not:
- in a buildd build;
- in a manual build in abel.debian.org.

I'm wondering what makes the build process immune to that error.

The attached script will fail in a sid chroot on armhf, and I have reported 
this to the upstream bugtracker at
https://bugs.launchpad.net/hplip/+bug/1901209

-- 
OdyX

test_972339.sh
Description: application/shellscript


signature.asc
Description: This is a digitally signed message part.

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Control: found -1 3.20.5+dfsg0-3
Control: tags -1 +bullseye +upstream

Le vendredi, 16 octobre 2020, 14.23:59 h CEST Didier 'OdyX' Raboud a écrit :
> According to the 3.20.9-3 armhf auutopkgtest run for migration testing;
> https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.gz
> 
> hpcups sometimes crashes with free(): invalid pointer. For instance, it
> seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd'
> printer will let hpcups crash.
> 
> I'd welcome assistance here as I'm no C gdb fluent person.

So.

This bug can be reproduced by the following suite of  commands on armhf:

  $ export PPD=./prnt/hp-officejet_pro_1150c.ppd.gz
  $ /usr/lib/cups/filter/pdftopdf   1 debian '' 1 '' 
print_step_1.pdf
  $ /usr/lib/cups/filter/gstoraster 1 debian '' 1 '' print_step_2.raster
  $ /usr/lib/cups/filter/hpcups 1 debian '' 1 '' print_step_3.hpcups

As I have confirmed that this is also _already_ a bug in the current bullseye
version, I'll mark this RC bug as affecting the corresponding versions, and
I'll upload a version without the autopkgtest to unstable, to let this version
migrate.

As this is testable at build-time, I'll add a test for this and upload this to 
experimental. I'll report this to upstream today.

Cheers,

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Package: printer-driver-hpcups
Version: 3.20.9+dfsg0-3
Severity: serious
Tags: upstream help

According to the 3.20.9-3 armhf auutopkgtest run for migration testing;
https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.gz

hpcups sometimes crashes with free(): invalid pointer. For instance, it
seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd'
printer will let hpcups crash.

I'd welcome assistance here as I'm no C gdb fluent person.

  
-- Package-specific info:

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages printer-driver-hpcups depends on:
ii  cups 2.3.3-3
ii  cups-filters [ghostscript-cups]  1.28.5-1
ii  libc62.31-4
ii  libcups2 2.3.3-3
ii  libdbus-1-3  1.12.20-1
ii  libgcc-s110.2.0-15
ii  libhpmud03.20.9+dfsg0-3
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  libstdc++6   10.2.0-15
ii  zlib1g   1:1.2.11.dfsg-2

printer-driver-hpcups recommends no packages.

Versions of packages printer-driver-hpcups suggests:
pn  hplip  
pn  hplip-doc  

-- no debconf information

Bug#972089: Backport hplip 3.20.5 to buster-backports

[Didier 'OdyX' Raboud]

Le mardi, 13 octobre 2020, 16.37:38 h CEST Brian Potkin a écrit :
> > It seems sane-airscan is not available on Debian 10, only on Debian 11.
> 
> Alex Pevzner provides packages for Debian 10. I use one very successfully.
> 
>   https://download.opensuse.org/repositories/home:/pzz/Debian_10/

Backporting sane-airscan is straightforward (just tried), and could make a 
nice improvement to buster(-backports).

It seems I'll upload both hplip and sane-airscan once their version reach 
bullseye.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#972098: dgit assumes 'master' as main branch

[Didier 'OdyX' Raboud]

Le mardi, 13 octobre 2020, 00.23:12 h CEST Ian Jackson a écrit :
> Didier 'OdyX' Raboud writes:
> > on various packaging repositories I routinely use dgit on, it has started
> > to fail on me with the following error:
> This is odd.  dgit doesn't normally care much about branches.

It surprised me too

> > $ dgit pbuilder
> > Format `3.0 (quilt)', need to check/update patch stack
> > examining quilt state (multiple patches, linear mode)
> > gzip: warning: GZIP environment variable is deprecated; use an alias
> > or script dgit: base trees orig=cfd69559157d8cae3e6d
> > o+d/p=08391389eaf6c31ab9dc dgit: quilt differences: src:  ## orig ## 
> >gitignores:  == orig == dgit: quilt differences:  HEAD ==
> > o+d/p   HEAD == o+d/p starting quiltify (multiple
> > patches, linear mode)
> > quiltify linearisation planning successful, executing...
> > error: pathspec 'master' did not match any file(s) known to git
> > dgit: failed command: git checkout -q master
> > 
> > dgit: error: subprocess failed with error exit status 1
> > 
> > Specifically, I'm running this dgit * command from a debian/master branch
> > (I will move to debian/main or debian/sid soon), with only the other
> > branches being upstream/latest and pristine-tar. I don't have a master
> > branch in these repositories at all.
> 
> Can you please run the command again with (let's say) -DD ?

Hereby attached.

When I asked on IRC, Sean answered this:

spwhitton | OdyX: looks like it's unconditional
spwhitton | OdyX: at the end of the 'quiltify' sub  

 
spwhitton | OdyX: should probably do something much more sophisticated

I hope it helps.

Cheers,
OdyX| git rev-parse --show-toplevel
=> `/home/didier/hack/cups-filters'
| git config -z --get-regexp --local '.*'
| git config -z --get-regexp --local '.*'
| git config -z --get-regexp --global '.*'
| git config -z --get-regexp --system '.*'
format 3.0 (quilt), quilt mode linear
Format `3.0 (quilt)', need to check/update patch stack
| git status -uall --ignored --porcelain debian/source/format debian/source/options debian/source/local-options debian/source/local-patch-header
=> `'
+ git diff --quiet HEAD
#massaging# 
massage split -F.
massage done 3 -b.
format 3.0 (quilt), quilt mode linear
| git status -uall --ignored --porcelain debian/source/format debian/source/options debian/source/local-options debian/source/local-patch-header
=> `'
+ git diff --quiet HEAD
| git clean -dn
=> `'
checking for vendor-specific debian/patches/debian.series (Dpkg::Vendor `current vendor')
checking for vendor-specific debian/patches/debian.series ((base) distro being accessed)
checking for vendor-specific debian/patches/debian.series ((nominal) distro being accessed)
| git rev-parse 'HEAD~0'
=> `4a6df4ccff9e03623778011ab6554194efc1f325'
| git symbolic-ref -q HEAD
=> `refs/heads/debian/master'
CD /home/didier/hack/cups-filters/.git/dgit/unpack
CD work
+ env PATH=/etc/perl:/usr/local/lib/x86_64-linux-gnu/perl/5.30.3:/usr/local/share/perl/5.30.3:/usr/lib/x86_64-linux-gnu/perl5/5.30:/usr/share/perl5:/usr/lib/x86_64-linux-gnu/perl-base:/usr/lib/x86_64-linux-gnu/perl/5.30:/usr/share/perl/5.30:/usr/local/lib/site_perl:/usr/share/dgit:/home/didier/go/bin:/home/didier/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games git playtree-setup .
+ git reset -q --hard 4a6df4ccff9e03623778011ab6554194efc1f325
examining quilt state (multiple patches, linear mode)
branch_is_gdr 4a6df4ccff9e03623778011ab6554194efc1f325...
branch_is_gdr  4a6df4ccff9e03623778011ab6554194efc1f325 plain
branch_is_gdr  bd36058a8c0dcec376745c6bd398379b9f5a2a08 gdr make-patches YES
+ git reset -q --hard 4a6df4ccff9e03623778011ab6554194efc1f325
+ git-debrebase --noop-ok -funclean-mixed -funclean-ordering make-patches --quiet-would-amend
| git rev-parse 'HEAD~0'
=> `4a6df4ccff9e03623778011ab6554194efc1f325'
QF linkorigs bpd ., /home/didier/hack/cups-filters/../. ?
QF linkorigs bpd .., /home/didier/hack/cups-filters/../.. ?
QF linkorigs bpd …

…
+ env GZIP=-1n tar -zcf './cups-filters_1.28.5-~~DGITFAKE.debian.tar.gz' -C /home/didier/hack/cups-filters debian/source/format debian/rules debian/control debian/changelog debian/patches
gzip: warning: GZIP environment variable is deprecated; use an alias or script
+ sh -ec 'exec dpkg-source --no-check --skip-patches -x fake.dsc >/dev/null'
CD fake
| find -name .git -prune -print0
+ env PATH=/etc/perl:/usr/local/lib/x86_64-linux-gnu/perl/5.30.3:/usr/local/share/perl/5.30.3:/usr/lib/x86_64-linux-gnu/perl5/5.30:/usr/share/perl5:/usr/lib/x86_64-linux-gnu/perl-base:/usr/lib/x86_64-linux-gnu/perl/5.30:/usr/share/perl/5.30:/usr/loc

Bug#972089: Backport hplip 3.20.5 to buster-backports

[Didier 'OdyX' Raboud]

Hello Alex, and thanks for your bugreport,

Thankfully, now with driverless printing [0] and sane-airscan [1], printers 
such as yours shouldn't need hplip anymore. (Also, hplip's code quality isn't 
monotonously upwards, so printing without hplip is often a preferable option). 
That said, the situation in sid and bullseye (current testing) is likely much 
better in these respects than in buster. Could you maybe test driverless 
printing, and/or sane-airscan?

As for the backporting; thank you for the patch removal proposals. As I've 
just uploaded 3.20.9+dfsg0-3 to unstable; it should migrate to testing in 
about 5-10 days, so , if your testing isn't successful, I'll prepare a 3.20.9 
backport. I'm testing a build as I write this.

Please report the results of your tests if you have the occasion.

Best regards, and thanks for your work!

Cheers,
OdyX



[0] https://wiki.debian.org/DriverlessPrinting
[1] https://github.com/alexpevzner/sane-airscan

Le lundi, 12 octobre 2020, 15.10:35 h CEST Alex ARNAUD a écrit :
> Package: hplip
> Severity: wishlist patch
> Tags: ||buster||
> 
> Hello,
> 
> Why I'd like this to be backported to buster-backports ?
> My new printer, an HP 2700 series is only compatible with HP Lip
> 3.20.5+. This is based on my own tests where only half of printed pages
> are printed. This is also based on the upstream table
>  ndex> where it is indicated the "HP DeskJet 2700 All-in-One Printer series"
> is compatible with 3.20.5.
> 
> What did I already do to figure this out?
> With the help of Samuel Thibault, I was able to recompile HP Lip 3.20.5
> on a Buster virtual machine and I produced two patch for it. The patches
> are attached to this mail. One is to update the debian/patches/series
> file and the second one is to refresh the patch 0072 (just a quilt
> refresh on it). I initially would like to propose a pull request on
> Salsa but there is no branch to submit the changes.
> 
> What my patch does?
> It reverts all the python3.8 specific patches because Debian Buster is
> based on Python 3.7 and because python3.7 library is named "python3.7m",
> not only python3.7.
> 
> What I think HP Lip should be backported to buster-backports?
> I think it'd be really helpful for people would like to stay on stable
> with new HP printers which require new HP Lip to have a new version in
> backports.
> 
> How do I check if it works?
> 
> 1. I upgraded the compiled packages with the following command:
> > sudo dpkg -iO .../*.deb
> 
> 2) I rebooted my virtual machine to ensure the new HP Lip version is loaded
> 
> 3) I configured my HP Desktop 3630 printer (launched with
> system-config-printer)
> 
> 4) I tried a print test job launched with system-config-printer
> 
> 5) I tried a scan with simple-scan
> 
> Result:
> Everything seems to work correctly.
> 
> Thanks in advance,
> Alex.


-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#972098: dgit assumes 'master' as main branch

[Didier 'OdyX' Raboud]

Package: dgit
Version: 9.12
Severity: important

Hello,

on various packaging repositories I routinely use dgit on, it has started to
fail on me with the following error:

$ dgit pbuilder
Format `3.0 (quilt)', need to check/update patch stack
examining quilt state (multiple patches, linear mode)
gzip: warning: GZIP environment variable is deprecated; use an alias or 
script
dgit: base trees orig=cfd69559157d8cae3e6d o+d/p=08391389eaf6c31ab9dc
dgit: quilt differences: src:  ## orig ## gitignores:  == orig ==
dgit: quilt differences:  HEAD == o+d/p   HEAD == o+d/p
starting quiltify (multiple patches, linear mode)
quiltify linearisation planning successful, executing...
error: pathspec 'master' did not match any file(s) known to git
dgit: failed command: git checkout -q master

dgit: error: subprocess failed with error exit status 1

Specifically, I'm running this dgit * command from a debian/master branch (I
will move to debian/main or debian/sid soon), with only the other branches
being upstream/latest and pristine-tar. I don't have a master branch in these
repositories at all.

My current workaround (but it's a risky one) is to run `dgit --quilt=nocheck
pbuilder` instead.

Regards,
OdyX

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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dgit depends on:
ii  apt2.1.10
ii  ca-certificates20200601
ii  coreutils  8.32-4+b1
ii  curl   7.72.0-1
ii  devscripts 2.20.4
ii  dpkg-dev   1.20.5
ii  dput-ng [dput] 1.31
ii  git [git-core] 1:2.28.0-1
ii  git-buildpackage   0.9.20
ii  libdpkg-perl   1.20.5
ii  libjson-perl   4.02000-2
ii  liblist-moreutils-perl 0.416-1+b5
ii  liblocale-gettext-perl 1.07-4
ii  libtext-csv-perl   2.00-1
ii  libtext-glob-perl  0.11-1
ii  libtext-iconv-perl 1.7-7
ii  libwww-curl-perl   4.17-7
ii  perl [libdigest-sha-perl]  5.30.3-4

Versions of packages dgit recommends:
ii  distro-info-data 0.44
ii  liburi-perl  1.76-2
ii  openssh-client [ssh-client]  1:8.3p1-1

Versions of packages dgit suggests:
ii  cowbuilder  0.89
ii  pbuilder0.230.4
ii  sbuild  0.80.0

-- no debconf information