Bug#1066034: tech-ctte: proposed constitution fix and social contract chg to make documentation accessible to all people

[Gunnar Wolf]

[ I am not part of the Technical Committee anymore, am answering just
  as a DD ]

debbug.tech-c...@sideload.33mail.com dijo [Mon, Mar 11, 2024 at 02:37:45PM 
+0100]:
> # The DSC needs to become meaningful
> 
> Chuck Zmudzinski filed a bug report saying that the Debian Social
> Contract (DSC) is “meaningless”:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028557
> 
> He is correct in the sense that there is no enforcement mechanism. At
> the same time, the Debian Constitution (DC) also neglects to
> acknowledge jurisdiction over DSC enforcement. This is a bug. I think
> it’s assumed that the technical committee is tasked with DSC
> enforcement. But this should be explicit and without guesswork.
> 
> Is the DSC a guaranteed protection whereby non-compliances have a
> complaint mechanism and corrective procedure?  Or is the DSC actually
> intended to be comparable to a meaningless pushover license?

No, the TC does not go around with a stick chasing violators of the
Social Contract. The SC is upheld by each individual Debian
contributor. Particularly, the Debian Developers have signed a
statement to follow this document when volunteering work for the
project. It is up to us all, as a group, to uphold it.

> (...)
> Problems in the DSC and calls for improvement thereof should itself be
> a transparent process. It was unclear to me where to submit this bug
> herein: tech-ctte, qa.debian.org, or general?

If you need to discuss this kind of documents, the right venue would
be the debian-proj...@lists.debian.org list. However, please modulate
a bit your tone, as this message feels to fall a bit towards
aggressive writing; you will find better echo if you approach trying
to understand instead of demanding action.

> The DSC shows “Version 1.2 ratified on October 1st, 2022.” But where
> and how?  The public should have transparent access to the
> discussions, decisions, and changes.

Debian is not a government, but a volunteer project. "The public" has
no rights: We have a committment to which we all (Developers) adhere
to. "We will not hide problems", of course, but if you want something
to change, please try pointing at specific issues that were not
handled correctly --- and for which the incorrect handling was done
purposefully so (i.e. hiding problems); we have more than once found
that we are stuck in a loophole we are unable to properly fix, and
cannot enforce our golden standard (i.e. the declassification of the
debian-private mailing list, that was supposed to happen for ~10
years, until we decided via an open discussion and vote that it just
was not be possible to do correctly.

> # DSC change proposal: make documentation accessible to ALL people
> 
> There is a growing problem of documentation being locked into walled
> gardens which discriminate against several demographics of people,
> such as blind people being forced to solve a CAPTCHA that requires
> vision. The access-restricted documentation problem is particularly
> rampant on the Linux Mint and (ironically) Ubuntu projects. Debian
> does not proactively impose any walled gardens on people at the moment
> but whenever a package makes reference to external documentation
> served from an access-restricted location, Debian passively allows
> this. Debian can (and should) do better than this. The problem and
> proposal is described in detail here:
> 
>   * https://linux.community/post/649372
>   * 
> https://kbin.social/m/debian/t/889598/Debian-Social-Contract-Should-all-Debian-users-inclusively-have-open
> 
> Those two links ↑ give two different views of the same article. I
> reference both because of a minor formatting bug in kbin.

The point you raise is interesting and worth discussing, although I
believe it would place too much of a burden on maintainers. But I feel
it is orthogonal to the main issue discussed.

Besides that, I completely agree with Christoph, in order for a
discussion to be taken seriously, I strongly recommend you to disclose
your name and a real address, and not do it from an unknown,
mission-specific sender.

Bug#1061765: Help needed to fix python-coverage-test-runner

[Gunnar Wolf]

Andreas Tille dijo [Fri, Feb 23, 2024 at 03:22:27PM +0100]:
> HI Andrius,
> 
> Am Fri, Feb 23, 2024 at 09:29:27AM +0200 schrieb Andrius Merkys:
> > > ModuleNotFoundError: No module named 'imp'
> > 
> > I had a similar problem. I worked it around by depending on
> > python3-zombie-imp, the original code did not require any modifications.
> 
> Nice hint - implemented.

Thank you very much for your work, Andreas!

Bug#1062455: ITP: tiv -- Small command-line image viewer using RGB ANSI colors and Unicode block characters to render image

[Gunnar Wolf]

Before adding yet another tool doing more or less the same, please
check whether this tool is better for all use cases. In case you
require a "modern terminal" (as mentioned by tiv's web page), consider
"chafa" instead.

I read my mail with mutt on a (often) remote system. I use a terminal
emulator capable of displaying "sixels", and by using chafa, I can
view attached images basically with no need to infer anything from the
images, as if it were a local image viewer.

My only quip about using sixels is that it takes a long time to open a
large image (compared to "cacaterm", what I used before. I think tiv's
quality is better than cacaterm's, but I'm not sure if your needs will
be better covered by chafa.

Loren M. Lang dijo [Thu, Feb 01, 2024 at 07:35:24AM -0800]:
> Package: wnpp
> Severity: wishlist
> Owner: "Loren M. Lang" 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: tiv
>   Version : 1.2.1
>   Upstream Author : Aaron Liu , Stefan Haustein 
> 
> * URL : https://github.com/stefanhaustein/TerminalImageViewer
> * License : GPL3, ASL
>   Programming Lang: C++
>   Description : Small command-line viewer using RGB colors and Unicode 
> block characters to render image
> 
> Small command-line image viewer using 24-bit RGB ANSI colors and Unicode
> block characters which create a 4x8 pixel cell for each character. With
> the use of these Unicode block characters, this can provide a higher
> resolution image for the same screen real estate.
> 
> It was compared with timg and catimg and can get out finer detail than
> those tools and make a sharper presentation. The mail_new.png icon seems
> to have a lot of fine detail with the text on the page. Here is my
> comparision case:
> 
> catimg -H 32 /usr/share/icons/mate/256x256/actions/mail_new.png
> timg -g 32x32 /usr/share/icons/mate/256x256/actions/mail_new.png
> ./tiv -h 32 -w 32 /usr/share/icons/mate/256x256/actions/mail_new.png
> 
> I am currently planning on maintaining it myself, but I am open if there
> is a team that is more appropriate to help with it. The package itself
> is very lightweight and should not require much maintenance. I will need
> a sponsor to get this package into Debian.



-- 



signature.asc
Description: PGP signature

Bug#949456: vmdb2: grub failure with mklabel gpt

[Gunnar Wolf]

close 949456
thanks

The bug was answered with documentation from upstream three years ago,
and no further action was requested by the submitter. Please reopen if
needed!

Bug#996580: Acknowledgement (vmdb2 hangs in the mkpart plugin after a lvcreate because of device mapper paths)

[Gunnar Wolf]

I am sorry for not reacting earlier to your bug.

I have found some apparent race condition or intermitent failure due
to me interrupting things at the wrong time that seem to match what
you report... but cannot really pin-point it to anything specific.

I have *not* fixed the bug. But please confirm to me: Do you still see
this bug nowadays? Is it repeatable? 

Bug#1003959: E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)

[Gunnar Wolf]

found 1003959 0.27+really.0.26-1
tags 1003959 + confirmed,upstream
thanks

Sory for taking so long to answer to this mail. I can just now only
confirm that the bug is present in my builds. However, as the upstream
author puts it, vmdb2 is "in selfish maintenance mode", so it is
unlikely he will develop a fix for this (but accepts patches!)

Bug#1021341: vmdb2: missing dependency on zerofree

[Gunnar Wolf]

I am adding a Recommends: on zerofree and will soon upload (and close
thus bug). Michael: I understand your point, but given this is a
design decision from our upstream author, I prefer adding a Cc: to
Lars and ask him to consider switching from zerofree over to fstim,
maybe he has reasons not to.

Greetings,

   -Gunnar


signature.asc
Description: PGP signature

Bug#1049448: new kernel updating problem

[Gunnar Wolf]

found: 1.20220830+ds-1
fixed: 1.20230405+ds-1
thanks

Bug#1049902: bookworm-pu: package raspi-firmware/20220830+ds-1+deb12u1

[Gunnar Wolf]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: raspi-firmw...@packages.debian.org
Control: affects -1 + src:raspi-firmware

[ Reason ]
raspi-firmware was built assuming it would be installed only in Raspberry
systems. However, now that firmware-nonfree is a proper section of Debian, and
there is firmware autodetection, it gets pulled in several AMD64 systems as
well.

When /boot/firmware is not mounted (as is the case in AMD64), postinst
fails. This yields a failure on kernel upgrades.

[ Impact ]
Many users have reported issues when upgrading the kernel.

[ Tests ]
I have not yet tested this particular version (but intend to do so soon and
report -- I want to get this reported to you first, though!), but the debdiff is
trivial, and is backported identically to the fix I sent to unstable (and is now
in testing) several weeks ago.

[ Risks ]
The code is very simple.

The only risk I can think of is that the bug might still impact users of
non-Raspberry ARM systems. However, the likelihood of having it installed is
minor (due to the available hardware being different). Besides, fixing this
(i.e. via detectng the Raspberry model from entries in /sys) would break other
use cases, such as VM-based image building.

[ 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 (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Postinst will now check whether the architecture is ARM*, and exit otherwise
without doing the firmware install dance.

[ Other info ]
A more proper fix would be to create a separate package with the wireless
Broadcom firmware. I have requested for the kernel team (maintainers of
firmware-brcm80211) to do so, but have got no positive response.

-- 

diff -Nru raspi-firmware-1.20220830+ds/debian/changelog 
raspi-firmware-20220830+ds/debian/changelog
--- raspi-firmware-1.20220830+ds/debian/changelog   2022-10-03 
09:11:55.0 -0500
+++ raspi-firmware-20220830+ds/debian/changelog 2023-08-16 09:51:39.0 
-0600
@@ -1,3 +1,10 @@
+raspi-firmware (20220830+ds-1+deb12u1) bookworm; urgency=medium
+
+  * Skip running postinst if installing on a system that's not arch:arm*
+(Closes: #1040896, #1040485, #1042070, #1040669, #1049448)
+
+ -- Gunnar Wolf   Wed, 16 Aug 2023 09:51:39 -0600
+
 raspi-firmware (1.20220830+ds-1) unstable; urgency=medium
 
   [ Gunnar Wolf ]
diff -Nru 
raspi-firmware-1.20220830+ds/debian/kernel/postinst.d/z50-raspi-firmware 
raspi-firmware-20220830+ds/debian/kernel/postinst.d/z50-raspi-firmware
--- raspi-firmware-1.20220830+ds/debian/kernel/postinst.d/z50-raspi-firmware
2022-10-03 09:11:55.0 -0500
+++ raspi-firmware-20220830+ds/debian/kernel/postinst.d/z50-raspi-firmware  
2023-08-16 09:51:39.0 -0600
@@ -27,11 +27,25 @@
   grep -q 'Raspberry Pi \(Compute Module \)*4' 
/sys/firmware/devicetree/base/model 2>/dev/null
 }
 
+is_arm_system() {
+  # Check to see if the host is running an arm-based system
+  # (i.e. whether the raspi-firmware package is useful)
+  DPKG_ARCH=$(dpkg --print-architecture)
+  case "$DPKG_ARCH" in
+arm64|armel|armhf)
+  return 0;;
+*)
+  return 1;;
+  esac
+}
 
 if ischroot ; then
   true # chroot detected - skip mount point check
 elif [ -e /usr/bin/systemd-detect-virt ] && systemd-detect-virt -q ; then
   true # virtualization detected - skip mount point check
+elif ! is_arm_system ; then
+  # Not running on an arm-based system, skip postinst.
+  exit 0
 elif ! mountpoint -q /boot/firmware ; then
   echo "raspi-firmware: missing /boot/firmware, did you forget to mount it?" 
>&2
   exit 1
diff -Nru raspi-firmware-1.20220830+ds/debian/raspi-firmware.postinst 
raspi-firmware-20220830+ds/debian/raspi-firmware.postinst
--- raspi-firmware-1.20220830+ds/debian/raspi-firmware.postinst 2022-10-03 
09:11:55.0 -0500
+++ raspi-firmware-20220830+ds/debian/raspi-firmware.postinst   2023-08-16 
09:51:39.0 -0600
@@ -3,6 +3,18 @@
 
 set -e
 
+is_arm_system() {
+  # Check to see if the host is running an arm-based system
+  # (i.e. whether the raspi-firmware package is useful)
+  DPKG_ARCH=$(dpkg --print-architecture)
+  case "$DPKG_ARCH" in
+arm64|armel|armhf)
+  return 0;;
+*)
+  return 1;;
+  esac
+}
+
 case "$1" in
   configure)
 
@@ -10,6 +22,9 @@
   true # chroot detected - skip mount point check
 elif test -e /usr/bin/systemd-detect-virt && systemd-detect-virt -q ; then
   true # virtualization detected - skip mount point check
+elif ! is_arm_system ; then
+  # Not running on an arm-based system, skip the postinst
+  exit 0
 elif ! mountpoint -q /boot/firmware; then
   echo "Error: missing /boot/firmware, did you forget to mount it?" >&2
   exit 1


signature.asc
Description: PGP signature

Bug#1049448: new kernel updating problem

[Gunnar Wolf]

Control: reassign 1049448 raspi-firmware
thanks

Hello Paul and slimshady,

I'm reassigning this bug to raspi-firmware, as it relates to an already known
issue; the fix has been uploaded already for several weeks in unstable+testing,
but I will now prepare an upload for stable as well.

I'll follow up with the diff and will open a corresponding bug on
release.debian.org as mentioned in [1].

Sorry for the much unintended noise. Thank you very much!

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable


signature.asc
Description: PGP signature

Bug#1047864: impressive: Crashes at startup: «module 'PIL.Image' has no attribute 'ANTIALIAS'»

[Gunnar Wolf]

Package: impressive
Version: 0.13.1-1
Followup-For: Bug #1047864

Checking the online documentation of Pillow (the fork of PIL that Debian ships),
the ANTIALIAS method has been renamed as LANCZOS:

https://pillow.readthedocs.io/en/stable/releasenotes/2.7.0.html

Antialias renamed to Lanczos

A new LANCZOS constant was added instead of ANTIALIAS.

When ANTIALIAS was initially added, it was the only high-quality filter
based on convolutions. It’s name was supposed to reflect this. Starting from
Pillow 2.7.0 all resize method are based on convolutions. All of them are
antialias from now on. And the real name of the ANTIALIAS filter is Lanczos
filter.

The ANTIALIAS constant is left for backward compatibility and is an alias
for LANCZOS.

This relates to a very old version (2.7.0 is from 2015)... I don't know the
actual details as to when and why this backward compatibility alias was dropped,
but it just is not provided anymore.

I prepared the patch I'm attaching to this mail and tested it (it works
correctly); I'm rebuilding and uploading a NMU for 7 days.

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

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 impressive depends on:
ii  mupdf-tools 1.22.2+ds1-1
ii  poppler-utils   22.12.0-2+b1
ii  python3 3.11.4-5+b1
ii  python3-pil 10.0.0-1
ii  python3-pygame  2.5.0-2

Versions of packages impressive recommends:
ii  ffmpeg 7:6.0-5
ii  mplayer2:1.5+svn38423-2+b1
ii  perl   5.36.0-7
ii  xdg-utils  1.1.3-4.1

Versions of packages impressive suggests:
ii  ghostscript   10.01.2~dfsg-1
pn  latex-beamer  
pn  pdftk 

-- no debconf information
diff --git a/impressive.py b/impressive.py
index 993dcee..9eb564c 100644
--- a/impressive.py
+++ b/impressive.py
@@ -2076,7 +2076,7 @@ class WipeClouds(Wipe):
 img = ImageOps.equalize(ImageOps.autocontrast(img))
 for i in range(self.blur):
 img = img.filter(ImageFilter.BLUR)
-img = img.crop((border, border, img.size[0] - 2 * border, img.size[1] 
- 2 * border)).resize((self.rx, self.ry), Image.ANTIALIAS)
+img = img.crop((border, border, img.size[0] - 2 * border, img.size[1] 
- 2 * border)).resize((self.rx, self.ry), Image.LANCZOS)
 return img2str(img)
 class WipeBrightness1(Wipe):
 """wipe based on the current slide's brightness"""
@@ -3505,16 +3505,16 @@ def RenderPDF(page, MayAdjustResolution, ZoomMode):
 # downsample a supersampled image
 if Supersample and not(ZoomMode):
 img = img.resize((int(float(out[0]) / Supersample + 0.5),
-  int(float(out[1]) / Supersample + 0.5)), 
Image.ANTIALIAS)
+  int(float(out[1]) / Supersample + 0.5)), 
Image.LANCZOS)
 parscale = False  # don't scale again
 
 # perform PAR scaling (required for pdftoppm which doesn't support 
different
 # dpi for horizontal and vertical)
 if parscale:
 if PAR > 1.0:
-img = img.resize((int(img.size[0] / PAR + 0.5), img.size[1]), 
Image.ANTIALIAS)
+img = img.resize((int(img.size[0] / PAR + 0.5), img.size[1]), 
Image.LANCZOS)
 else:
-img = img.resize((img.size[0], int(img.size[1] * PAR + 0.5)), 
Image.ANTIALIAS)
+img = img.resize((img.size[0], int(img.size[1] * PAR + 0.5)), 
Image.LANCZOS)
 
 # crop the overscan (if present)
 if Overscan:
@@ -3567,7 +3567,7 @@ def LoadImage(page, zoom=False, img=None):
 if newsize > img.size:
 filter = Image.BICUBIC
 else:
-filter = Image.ANTIALIAS
+filter = Image.LANCZOS
 return img.resize(newsize, filter)
 
 
@@ -3703,7 +3703,7 @@ def PageImage(page, ZoomMode=False, RenderMode=False):
 sy = OverviewCellY - 2 * OverviewBorder
 if HighQualityOverview:
 t0 = time.time()
-img.thumbnail((sx, sy), Image.ANTIALIAS)
+img.thumbnail((sx, sy), Image.LANCZOS)
 if (time.time() - t0) > 0.5:
 print("Note: Your system seems to be quite slow; 
falling back to a faster,", file=sys.stderr)
 print("  but slightly lower-quality overview page 
rendering mode", file=sys.stderr)
@@ -6409,7 +6409,7 @@ def main():
 if (dummy.size[0] > maxsize[0]) or (dummy.size[1] > maxsize[1]):
 size = ZoomToFit(dummy.size, maxsize, force_int=True)
 if min(size) > 0:
-dummy.thumbnail(size, Image.ANTIALIAS)
+dummy.thumbnail(size, Image.LANCZOS)
 else:
 dummy = None
 if dummy:

Bug#1047864: impressive: Crashes at startup: «module 'PIL.Image' has no attribute 'ANTIALIAS'»

[Gunnar Wolf]

Package: impressive
Version: 0.13.1-1
Severity: grave
Justification: renders package unusable

Hello again,

I have stumbled upon a new bug that affects impressive :-(

When starting up, I see the logo screen, but immediately afterwards, impressive
crashes with the following:

$ impressive test.pdf 
Welcome to Impressive version 0.13.1
Platform library: [pygame-unix] Python 3.11.4 / PyGame 2.5.0 / SDL 2.28.1
Detected screen size: 3840x2160 pixels
PDF renderer: MuPDF 1.4 or newer
OpenGL renderer: Mesa Intel(R) UHD Graphics 600 (GLK 2)
Your version of PIL is too old or incomplete, disabling OSD.
warning: ICC support is not available
warning: ICC support is not available


===
OOPS! Impressive crashed!
This shouldn't happen. Please report this incident to the author, including 
the
full output of the program, particularly the following lines. If possible,
please also send the input files you used.

Impressive version: 0.13.1
Python version: 3.11.4 (main, Jun 7 2023, 10:13:09) [GCC 12.2.0]
Impressive platform: pygame-unix
PyGame version: 2.5.0
SDL version: 2.28.1
PIL version: Pillow 10.0.0
PDF renderer: MuPDF 1.4 or newer
OpenGL vendor: Intel
OpenGL renderer: Mesa Intel(R) UHD Graphics 600 (GLK 2)
OpenGL version: 4.6 (Compatibility Profile) Mesa 23.1.4-1
Operating system: Linux 6.4.0-1-amd64 (x86_64)
Linux distribution: Debian GNU/Linux trixie/sid
Command line: /usr/bin/impressive test.pdf
Traceback (most recent call last):
  File "/usr/bin/impressive", line 6569, in run_main
main()
  File "/usr/bin/impressive", line 6486, in main
RenderPage(Pcurrent, Tcurrent)
  File "/usr/bin/impressive", line 3741, in RenderPage
gl.TexImage2D(gl.TEXTURE_2D, 0, gl.RGB, TexWidth, TexHeight, 0, gl.RGB, 
gl.UNSIGNED_BYTE, PageImage(page))

  ^^^
  File "/usr/bin/impressive", line 3706, in PageImage
img.thumbnail((sx, sy), Image.ANTIALIAS)
^^^
AttributeError: module 'PIL.Image' has no attribute 'ANTIALIAS'
$ 

I suppose this comes as a change in python3-pil's API. I got impressive to work
again by very simplisticly substituting Image.ANTIALIAS in /usr/bin/impressive,
but of course, I'm sure there are better ways to patch this issue :-)

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

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 impressive depends on:
ii  mupdf-tools 1.22.2+ds1-1
ii  poppler-utils   22.12.0-2+b1
ii  python3 3.11.4-5
ii  python3-pil 10.0.0-1
ii  python3-pygame  2.5.0-1

Versions of packages impressive recommends:
ii  ffmpeg 7:6.0-5
ii  mplayer2:1.5+svn38423-2+b1
ii  perl   5.36.0-7
ii  xdg-utils  1.1.3-4.1

Versions of packages impressive suggests:
ii  ghostscript   10.01.2~dfsg-1
pn  latex-beamer  
pn  pdftk 

-- no debconf information

Bug#1041621: kindleclip: indirectly depends on unmaintained GTK 2

[Gunnar Wolf]

Simon McVittie dijo [Fri, Jul 21, 2023 at 02:53:29PM +0100]:
> Package: kindleclip
> Version: 0.6-1.1
> Severity: important
> Tags: trixie sid
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: gtk2 oldlibs
> Control: block 967733 by -1
> X-Debbugs-Cc: ruby-gn...@packages.debian.org
> 
> kindleclip seems to be the only package in unstable that depends on
> ruby-gtk2, a GTK 2 binding for Ruby.
> (...)

Thank you very much, Simon!

I am the upstream author for kindleclip, but don't use it anymore, and
don't have the needed hardware to use it anymore.

I have filed a removal request against the package, to help allow
ruby-gtk2 to be removed.

Bug#1042873: RM: kindleclip -- ROM; Package orphaned upstream; depends on unmantained GTK 2

[Gunnar Wolf]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: kindlec...@packages.debian.org
Control: affects -1 + src:kindleclip

I am the upstream author for kindleclip. I wrote it over 10 years ago,
and it continues to work -- but I no longer have a Kindle device (and
they have added features that are not properly supported).

Kindleclip is built using ruby-gtk2, which depends on GTK2, which has
long been obsolete and will be finally removed. Please drop kindleclip
from the archive, so that ruby-gtk2 can also be removed.

Thank you!


signature.asc
Description: PGP signature

Bug#1040075: telegram-purple: Outdated version, please update

[Gunnar Wolf]

Source: telegram-purple
Version: 1.4.3-3
Severity: normal

Please consider updating this package to version 1.4.7 (currently only
1.4.3 is packaged). While the newer version is quite old already
(April 2021), it includes roughly a year of further development since
the version we are currently shipping.

Worth considering: the release notes for 1.4.7 start by saying, "Check
out tdlib-purple, which will hopefully become telegram-purple's
successor"... So it _might_ be better to look at that one instead!


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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

Bug#1040074: telegram-purple: Does not connect to the Telegram server despite reporting success

[Gunnar Wolf]

Package: telegram-purple
Version: 1.4.3-3+b1
Severity: grave
Justification: renders package unusable

For several days already, I have been unable to connect to Telegram
via Bitlbee (which uses libpurple). The log for the Bitlbee server
shows:

18:40:00 @root | telegram - Logging in: Logged in  
18:41:30 @root | telegram - Error: Lost connection to the server...
18:41:30 @root | telegram - Signing off..  
18:41:30 @root | telegram - Reconnecting in 5 seconds..
18:41:35 @root | telegram - Logging in: Logged in  
18:43:06 @root | telegram - Error: Lost connection to the server...
18:43:06 @root | telegram - Signing off..  
18:43:06 @root | telegram - Reconnecting in 5 seconds..
18:43:11 @root | telegram - Logging in: Logged in  
18:44:41 @root | telegram - Error: Lost connection to the server...
18:44:41 @root | telegram - Signing off..  
18:44:41 @root | telegram - Reconnecting in 5 seconds..
18:44:46 @root | telegram - Logging in: Logged in  
18:46:16 @root | telegram - Error: Lost connection to the server...
18:46:16 @root | telegram - Signing off..  
18:46:16 @root | telegram - Reconnecting in 5 seconds..
18:46:21 @root | telegram - Logging in: Logged in  

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

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 telegram-purple depends on:
ii  libc6 2.37-3
ii  libgcrypt20   1.10.2-2
ii  libglib2.0-0  2.74.6-2
ii  libpng16-16   1.6.39-2
ii  libpurple02.14.12-1
ii  libwebp7  1.2.4-0.2
ii  zlib1g1:1.2.13.dfsg-1

telegram-purple recommends no packages.

telegram-purple suggests no packages.

-- no debconf information

Bug#1037270: ITP: node-ftp -- FTP client module for node.js

[Gunnar Wolf]

Israel Galadima dijo [Fri, Jun 09, 2023 at 11:59:35PM +0100]:
> * Package name: node-ftp
>   Version : 0.3.10
>   Upstream Author : Brian White 
> * URL : * https://github.com/mscdex/node-ftp
> *
> * License : Expat
>   Programming Lang: JavaScript
>   Description : FTP client module for node.js
> 
> An FTP client module for node.js that provides an asynchronous interface
> for communicating with an FTP server.
> 
> This package is part of my effort to package corepack for Debian.

It's time to let FTP die! It is a terrible protocol, in so many
levels. The world would be better served if the energy invested in
packaging yet-another-FTP-client is rather used in helping
yet-another-obsolete-service-served-by-FTP migrate by something that
belongs to the current millenium :-\

(Of course, I'm nobody to oppose you working in whatever you wish to,
and your upstreams might be requiring this for $reasons... but still,
had to say it!)

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Gunnar Wolf]

Bastian Blank dijo [Thu, May 18, 2023 at 09:05:44PM +0200]:
> But why does the state of the package (native vs non-native) can have
> any effect on a CTTE decision?  Or do you want to say I can block CTTE
> from reaching any kind of decision just by uploading a package as
> native?  Sorry, but this does not compute.
> (...)
> Sure, but this is a direct violation of a CTTE decision.  How often do
> you think someone could do that?

During my time as a Technical Committe member, /usr-merge was the
point we most came back to. And yes, the way the TC decisions were
dodged or omitted by the dpkg maintainers was... quite depressing.

However, my reply should only be read regarding what I believe should
be done in the following ~month before the release.

Of course, I don't see the situation as ideal, nor as something that
should persist. I hope a _fixed_ dpkg is uploaded and becomes part of
Bookworm's first point release.

But, even if it were on the table (which is not AFAICT), I would (in a
strictly personal capacity) oppose the TC requiring such a patch at
this point.

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Gunnar Wolf]

Ansgar dijo [Thu, May 18, 2023 at 07:55:03PM +0200]:
> Why not?
> 
> Do you think the implications of removing the warning are unclear?
> 
> Do you think we need to explore alternative solutions?

(I am no longer part of the Committee, answering just as another
developer)

dpkg has many bits that make it special. It has been discussed whethe
dpkg should be a native package or it should become non-native; if it
were non-native, having a patch that contradicts the upstream author's
wishes would be easier (and I'm not saying that I'd be up for patching
this warning out as it is).

If we were to force a patch silencing out this warning right now and
for all of the Bookworm cycle, and the dpkg authors disagree with it,
they could remove (even omit to include it) in any updates. Upstream
has repeatedly expressed their opposition to the way usrmerge has been
brought forward, and the warning silenced specifically for Debian is
already the best compromise situation we have been able to reach --
even though we are aware the situation is far from ideal.

Bug#1034428: unblock: vmdb2/0.27+really+0.26-1

[Gunnar Wolf]

Hi,

Following Paul's advice, I have uploaded vmdb2
0.27+really+0.26-1. Debdiff reports no differences (?!)

$ debdiff ../build-area/vmdb2_0.26-2_source.changes 
../build-area/vmdb2_0.27+really.0.26-1_source.changes
File lists identical (after any substitutions)

Although I did check for the (following) patch to be present and
applied. The only difference between version 0.26-2 (currently in
testing) and the just uploaded version follows; once this version is
accepted in testing, I'll apply the rolled-back changes again:

diff --git a/debian/changelog b/debian/changelog
index f8661c6..cfa5dbe 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,33 @@
+vmdb2 (0.27+really.0.26-1) unstable; urgency=medium
+
+  * Rolling back the import of 0.27 due to the request of the Debian
+release managers; applying only the targetted patch
+  * Specify ^large_dir, ^metadata_csum_seed parameters to e2fsprogs to fix
+the creation of unbootable systems when older GRUB versions are used
+(Closes: #1031364)
+
+ -- Gunnar Wolf   Sat, 06 May 2023 19:06:53 -0600
+
+vmdb2 (0.27-1) unstable; urgency=medium
+
+  [ Gunnar Wolf ]
+  * New upstream release
+  * Specify ^large_dir, ^metadata_csum_seed parameters to e2fsprogs to fix
+the creation of unbootable systems when older GRUB versions are used
+(Closes: #1031364)
+
+  [ Debian Janitor ]
+  * Bump debhelper from old 12 to 13.
+  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse.
+  * Update standards version to 4.6.1, no changes needed.
+  * Set upstream metadata fields: Repository.
+
+  [ Gunnar Wolf ]
+  * Drop 001_set_architecture_for_later_stages patch (no longer needed,
+incorporated upstream)
+
+ -- Gunnar Wolf   Mon, 24 Oct 2022 14:48:46 -
+
 vmdb2 (0.26-2) unstable; urgency=medium
 
   * Fix debootstrap plugin: Set architecture for later stages (Closes:
diff --git a/debian/patches/omit_new_ext4_flags 
b/debian/patches/omit_new_ext4_flags
new file mode 100644
index 000..3046e68
--- /dev/null
+++ b/debian/patches/omit_new_ext4_flags
@@ -0,0 +1,27 @@
+Origin: 
https://gitlab.com/larswirzenius/vmdb2/-/merge_requests/106/diffs?commit_id=5b91eb58673d43e27523877816169b14e1ab6dfc
+Forwarded: not-needed
+From: Gunnar Wolf 
+Date: Sat May 6 19:21:30 GMT-6 2023
+Subject: When initializing an ext4 filesystem, omit flags incompatible with 
old GRUBs
+
+Index: vmdb2/vmdb/plugins/mkfs_plugin.py
+===
+--- vmdb2.orig/vmdb/plugins/mkfs_plugin.py
 vmdb2/vmdb/plugins/mkfs_plugin.py
+@@ -51,6 +51,16 @@ class MkfsStepRunner(vmdb.StepRunnerInte
+ cmd.append("-L")
+ cmd.append(label)
+ 
++# Ext4 filesystem features large_dir and metadta_csum_seed
++# are known to make versions of GRUB older than 2.06-8 unable
++# to boot. Keep this round at least until it is no longer
++# likely enough(?) users will try to build older target systems
++if fstype == "ext4":
++cmd.append("-O")
++cmd.append("^large_dir")
++cmd.append("-O")
++cmd.append("^metadata_csum_seed")
++
+ options = values["options"] or None
+ if options:
+ for opt in options.split(" "):
diff --git a/debian/patches/series b/debian/patches/series
index 40b31a7..4f56886 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 001_set_architecture_for_later_stages
+omit_new_ext4_flags


signature.asc
Description: PGP signature

Bug#1034428: unblock: vmdb2/0.27-1

[Gunnar Wolf]

Paul Gevers dijo [Sat, May 06, 2023 at 08:22:26AM +0200]:
> On 06-05-2023 08:01, Gunnar Wolf wrote:
> > What I plan to do (but please, others are welcome to do so ) is to
> > wait for a month, until bookworm is released, and upload to
> > stable-proposed-uploads a 0.26-2+1 or somesuch, including the
> > following, minimal diff thas has been accpted upstream:
> 
> Just for my understanding and avoidance of doubt, why wait for a point
> release? In my opinion it's much better to shape things out now than going
> for a point release. Is time just the issue? E.g. having 0.27+really.0.26-1
> is perfectly fine for the purpose.

Ugh, I quite hate that versioning scheme :-( But I'll do it.

Bug#1034428: unblock: vmdb2/0.27-1

[Gunnar Wolf]

Cyril Brulebois dijo [Sat, May 06, 2023 at 03:19:47AM +0200]:
> OK, so much fail on my part here, my bad.

A fair share of fail in my hands as well: I have been too busy, and
unable to react on this issue.

> That being said, it seems pretty clear to me at this point that the
> proposed update isn't reasonable: it would break autopkgtest (and
> possibly parts of ci.debian.net?), and it contains a bunch of
> irrelevant changes.
> 
> We would need something much more targeted. I'm not commenting on
> whether the changes are even needed given the e2fsprogs package has
> dropped the new options (there are probably some combinations of
> source and destination environments that could benefit from a vmdb2
> update, but I'd like to avoid thinking about that again…).

Right. When I performed the upload, I didn't expect vmdb2 to be used
for autopkgtests. I completely agree with Elbrus: We cannot accept my
upload into bookworm.

What I plan to do (but please, others are welcome to do so ) is to
wait for a month, until bookworm is released, and upload to
stable-proposed-uploads a 0.26-2+1 or somesuch, including the
following, minimal diff thas has been accpted upstream:


https://gitlab.com/larswirzenius/vmdb2/-/merge_requests/106/diffs?commit_id=5b91eb58673d43e27523877816169b14e1ab6dfc

There are some other reliability improvements in 0.27, some of which
could also be hand-picked to be backported to 0.26.

Greetings,


signature.asc
Description: PGP signature

Bug#1034469: unblock: vmdb2/0.27-1

[Gunnar Wolf]

don't enable the plugin.
-  #- virtual-filesystems: /
+  - virtual-filesystems: /
 
   - unpack-rootfs: /
 
-  - qemu-debootstrap: buster
+  - debootstrap: buster
 arch: armhf
 mirror: http://deb.debian.org/debian
 target: /
diff -Nru vmdb2-0.26/check-images vmdb2-0.27/check-images
--- vmdb2-0.26/check-images 2022-03-31 10:38:29.0 -0600
+++ vmdb2-0.27/check-images 2023-04-11 12:01:15.0 -0600
@@ -29,14 +29,11 @@
 src="$(dirname "$0")"
 cd "$src"
 
-# This uses debootstrap, not qemu-debootstrap. Hence, it only works on amd64
-if [ -x /usr/bin/dpkg ] && [ "$(dpkg --print-architecture)" = "amd64" ]; then
-   bash -x ./smoke.sh "$amd64_tarball"
+bash -x ./smoke.sh "$amd64_tarball"
 
-   for x in "$@" pc uefi ansible smoke-pc smoke-uefi; do
-   tryit "$tarballdir/$x.img" "$x.vmdb" "$amd64_tarball"
-   done
-fi
+for x in "$@" pc uefi ansible smoke-pc smoke-uefi; do
+   tryit "$tarballdir/$x.img" "$x.vmdb" "$amd64_tarball"
+done
 
 if [ -e /usr/share/OVMF/OVMF_VARS_4M.fd ]; then
bash -x ./smoke-amd64.sh "$amd64_tarball"
diff -Nru vmdb2-0.26/debian/changelog vmdb2-0.27/debian/changelog
--- vmdb2-0.26/debian/changelog 2022-10-24 09:08:11.0 -0500
+++ vmdb2-0.27/debian/changelog 2022-10-24 09:48:46.0 -0500
@@ -1,3 +1,23 @@
+vmdb2 (0.27-1) unstable; urgency=medium
+
+  [ Gunnar Wolf ]
+  * New upstream release
+  * Specify ^large_dir, ^metadata_csum_seed parameters to e2fsprogs to fix
+the creation of unbootable systems when older GRUB versions are used
+(Closes: #1031364)
+
+  [ Debian Janitor ]
+  * Bump debhelper from old 12 to 13.
+  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse.
+  * Update standards version to 4.6.1, no changes needed.
+  * Set upstream metadata fields: Repository.
+
+  [ Gunnar Wolf ]
+  * Drop 001_set_architecture_for_later_stages patch (no longer needed,
+incorporated upstream)
+
+ -- Gunnar Wolf   Mon, 24 Oct 2022 14:48:46 -
+
 vmdb2 (0.26-2) unstable; urgency=medium
 
   * Fix debootstrap plugin: Set architecture for later stages (Closes:
diff -Nru vmdb2-0.26/debian/control vmdb2-0.27/debian/control
--- vmdb2-0.26/debian/control   2022-10-24 09:08:11.0 -0500
+++ vmdb2-0.27/debian/control   2022-10-24 09:48:46.0 -0500
@@ -4,11 +4,11 @@
 Section: admin
 Priority: optional
 Rules-Requires-Root: no
-Standards-Version: 4.5.1
+Standards-Version: 4.6.1
 Vcs-Browser: https://salsa.debian.org/debian/vmdb2/
 Vcs-Git: https://salsa.debian.org/debian/vmdb2.git
 Build-Depends: cmdtest,
-   debhelper-compat (= 12),
+   debhelper-compat (= 13),
dh-python,
   lmodern,
pandoc (>= 2.1.2~),
diff -Nru vmdb2-0.26/debian/patches/001_set_architecture_for_later_stages 
vmdb2-0.27/debian/patches/001_set_architecture_for_later_stages
--- vmdb2-0.26/debian/patches/001_set_architecture_for_later_stages 
2022-10-24 09:08:11.0 -0500
+++ vmdb2-0.27/debian/patches/001_set_architecture_for_later_stages 
1969-12-31 18:00:00.0 -0600
@@ -1,121 +0,0 @@
-Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021802
-Forwarded: not-needed
-From: Antonio Terceiro 
-Date: Sat Oct 15 02:06:02 UTC 2022
-Subject: fix(debootstrap plugin): set architecture for later stages
- debootstrap takes an architecture argument, but does not propagate that
- to later stages of the image build. This causes, for example, the GRUB
- plugin to fail to install the correct packages when creating an images
- for a foreign archiecture.
- .
- The call to dpkg --print-architecture to discover the native
- architecture is already done when state is first populated, so there is
- no need to do it again in the grub plugin.
- .
- This patch has been accepted in the upstream Git repo (commits 28813c,
- 395bb4). It should be dropped in the next upstream release.
-
-Index: vmdb2/arm64-uefi.vmdb
-===
 vmdb2.orig/arm64-uefi.vmdb
-+++ vmdb2/arm64-uefi.vmdb
-@@ -3,7 +3,7 @@
- 
- steps:
-   - mkimg: "{{ output }}"
--size: 4G
-+size: 1G
- 
-   - mklabel: gpt
- device: "{{ output }}"
-@@ -11,12 +11,12 @@ steps:
-   - mkpart: primary
- device: "{{ output }}"
- start: 0%
--end: 1G
-+end: 20M
- tag: efi
- 
-   - mkpart: primary
- device: "{{ output }}"
--start: 1G
-+start: 20M
- end: 100%
- tag: /
- 
-@@ -30,26 +30,35 @@ steps:
- 
-   - mount: /
- 
--  # Using the virtual-filesystems plugin here upsets qemu-debootstrap,
--  # which ends up unable to create /dev/fd within the chroot, causing
--  # the qemu-debootstrap phase to fail. Until we get to the bottom
--  # that, don't enable the plugin.
--  #- v

Bug#1034428: unblock: vmdb2/0.27-1

[Gunnar Wolf]

1:15.0 -0600
@@ -30,15 +30,11 @@
 
   - mount: /
 
-  # Using the virtual-filesystems plugin here upsets qemu-debootstrap,
-  # which ends up unable to create /dev/fd within the chroot, causing
-  # the qemu-debootstrap phase to fail. Until we get to the bottom
-  # that, don't enable the plugin.
-  #- virtual-filesystems: /
+  - virtual-filesystems: /
 
   - unpack-rootfs: /
 
-  - qemu-debootstrap: buster
+  - debootstrap: buster
 arch: armhf
 mirror: http://deb.debian.org/debian
 target: /
diff -Nru vmdb2-0.26/check-images vmdb2-0.27/check-images
--- vmdb2-0.26/check-images 2022-03-31 10:38:29.0 -0600
+++ vmdb2-0.27/check-images 2023-04-11 12:01:15.0 -0600
@@ -29,14 +29,11 @@
 src="$(dirname "$0")"
 cd "$src"
 
-# This uses debootstrap, not qemu-debootstrap. Hence, it only works on amd64
-if [ -x /usr/bin/dpkg ] && [ "$(dpkg --print-architecture)" = "amd64" ]; then
-   bash -x ./smoke.sh "$amd64_tarball"
+bash -x ./smoke.sh "$amd64_tarball"
 
-   for x in "$@" pc uefi ansible smoke-pc smoke-uefi; do
-   tryit "$tarballdir/$x.img" "$x.vmdb" "$amd64_tarball"
-   done
-fi
+for x in "$@" pc uefi ansible smoke-pc smoke-uefi; do
+   tryit "$tarballdir/$x.img" "$x.vmdb" "$amd64_tarball"
+done
 
 if [ -e /usr/share/OVMF/OVMF_VARS_4M.fd ]; then
bash -x ./smoke-amd64.sh "$amd64_tarball"
diff -Nru vmdb2-0.26/debian/changelog vmdb2-0.27/debian/changelog
--- vmdb2-0.26/debian/changelog 2022-10-24 09:08:11.0 -0500
+++ vmdb2-0.27/debian/changelog 2022-10-24 09:48:46.0 -0500
@@ -1,3 +1,23 @@
+vmdb2 (0.27-1) unstable; urgency=medium
+
+  [ Gunnar Wolf ]
+  * New upstream release
+  * Specify ^large_dir, ^metadata_csum_seed parameters to e2fsprogs to fix
+the creation of unbootable systems when older GRUB versions are used
+(Closes: #1031364)
+
+  [ Debian Janitor ]
+  * Bump debhelper from old 12 to 13.
+  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse.
+  * Update standards version to 4.6.1, no changes needed.
+  * Set upstream metadata fields: Repository.
+
+  [ Gunnar Wolf ]
+  * Drop 001_set_architecture_for_later_stages patch (no longer needed,
+incorporated upstream)
+
+ -- Gunnar Wolf   Mon, 24 Oct 2022 14:48:46 -
+
 vmdb2 (0.26-2) unstable; urgency=medium
 
   * Fix debootstrap plugin: Set architecture for later stages (Closes:
diff -Nru vmdb2-0.26/debian/control vmdb2-0.27/debian/control
--- vmdb2-0.26/debian/control   2022-10-24 09:08:11.0 -0500
+++ vmdb2-0.27/debian/control   2022-10-24 09:48:46.0 -0500
@@ -4,11 +4,11 @@
 Section: admin
 Priority: optional
 Rules-Requires-Root: no
-Standards-Version: 4.5.1
+Standards-Version: 4.6.1
 Vcs-Browser: https://salsa.debian.org/debian/vmdb2/
 Vcs-Git: https://salsa.debian.org/debian/vmdb2.git
 Build-Depends: cmdtest,
-   debhelper-compat (= 12),
+   debhelper-compat (= 13),
dh-python,
   lmodern,
pandoc (>= 2.1.2~),
diff -Nru vmdb2-0.26/debian/patches/001_set_architecture_for_later_stages 
vmdb2-0.27/debian/patches/001_set_architecture_for_later_stages
--- vmdb2-0.26/debian/patches/001_set_architecture_for_later_stages 
2022-10-24 09:08:11.0 -0500
+++ vmdb2-0.27/debian/patches/001_set_architecture_for_later_stages 
1969-12-31 18:00:00.0 -0600
@@ -1,121 +0,0 @@
-Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021802
-Forwarded: not-needed
-From: Antonio Terceiro 
-Date: Sat Oct 15 02:06:02 UTC 2022
-Subject: fix(debootstrap plugin): set architecture for later stages
- debootstrap takes an architecture argument, but does not propagate that
- to later stages of the image build. This causes, for example, the GRUB
- plugin to fail to install the correct packages when creating an images
- for a foreign archiecture.
- .
- The call to dpkg --print-architecture to discover the native
- architecture is already done when state is first populated, so there is
- no need to do it again in the grub plugin.
- .
- This patch has been accepted in the upstream Git repo (commits 28813c,
- 395bb4). It should be dropped in the next upstream release.
-
-Index: vmdb2/arm64-uefi.vmdb
-===
 vmdb2.orig/arm64-uefi.vmdb
-+++ vmdb2/arm64-uefi.vmdb
-@@ -3,7 +3,7 @@
- 
- steps:
-   - mkimg: "{{ output }}"
--size: 4G
-+size: 1G
- 
-   - mklabel: gpt
- device: "{{ output }}"
-@@ -11,12 +11,12 @@ steps:
-   - mkpart: primary
- device: "{{ output }}"
- start: 0%
--end: 1G
-+end: 20M
- tag: efi
- 
-   - mkpart: primary
- device: "{{ output }}"
--start: 1G
-+start: 20M
- end: 100%
- tag: /
- 
-@@ -30,26 +30,35 @@ steps:
- 
-  

Bug#1032663: ITP: eludris -- A simple CLI to help you with setting up and managing your Eludris instance

[Gunnar Wolf]

Oliver Wilkes dijo [Sun, Mar 12, 2023 at 04:12:11PM +]:
> Located at https://github.com/eludris/eludris/tree/main/cli, this is a
> package for creating an Eludris instance with ease. It is officially
> supported and maintained by Eludris and reduces the barrier to entry for new
> instance owners.
> 
> An Eludris instance is your own personally managed node of the Eludris
> server protocol, found at https://github.com/eludris/eludris.
> 
> More info about what Eludris is all about can be found here:
> https://eludris.github.io/docs/index.html.

Still not very useful. Something like the first paragraph of the mage
you quote last:

  Eludris is a FOSS federated, End-To-End-Encrypted Discord x Reddit
  mesh-like social media platform where the priority is for it to be
  truly yours.

I'd even prefer it to be without the hype (starting at "where the
priority..."). Having this explanation makes clear what the package is
about and whether you should be interested or not.

Bug#1032663: ITP: eludris -- A simple CLI to help you with setting up and managing your Eludris instance

[Gunnar Wolf]

Please explain briefly in your package description what is an Eludris
instance and why it might be useful or interesting to a Debian user
who stumbles upon your package!

Oliver Wilkes dijo [Fri, Mar 10, 2023 at 04:43:19PM +]:
> Package: wnpp
> Severity: wishlist
> Owner: Oliver Wilkes 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name : eludris
> Version : 0.3.2
> Upstream Author : Oliver Wilkes 
> * URL : https://github.com/eludris/eludris/tree/main/cli/
> * License : MIT
> Programming Lang: Rust
> Description : A simple CLI to help you with setting up and managing your
> Eludris instance
> 
> Located at https://github.com/eludris/eludris/tree/main/cli, this is a
> package for creating an Eludris instance with ease. It is officially
> supported and maintained by Eludris and reduces the barrier to entry for new
> instance owners.
> 
> ### Why is this package useful/relevant?
> 
> This CLI provides an easy way for users to create their own Eludris instance
> from scratch. There are currently no alternatives as Eludris is relatively
> new and this is an 'official' CLI.
> 
> ### How do you plan to maintain it?
> 
> I am not all too sure how this works as this is my first time packaging for
> Debian. I plan to maintain it solo for now, unless if anyone has any better
> suggestions as to what team to maintain it under.
> 

-- 

Bug#1032589: sq-wot: Please update

[Gunnar Wolf]

Package: sq-wot
Version: 0.2.0-1+b5
Severity: normal

Dear sq-wot maintainers,

The currently packaged version 0.2 of this tool was released in
February 2022. It remained with relatively little changes until last
December, but since then, five new releases were announced (it
currently sits at 0.6.0):

https://crates.io/crates/sequoia-wot/versions

The online published documentation no longer matches sq-wot's
functionality.

Please try to update this tool in order to have a more recent version
in Bookworm!

Thanks,

- Gunnar.

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

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 sq-wot depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libhogweed6  3.8.1-2
ii  libnettle8   3.8.1-2

sq-wot recommends no packages.

sq-wot suggests no packages.

-- no debconf information

-- 



signature.asc
Description: PGP signature

Bug#1031364: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Gunnar Wolf]

tags 1031364 + upstream,forwarded,patch
thanks

I have reported this bug to the upstream author as issue #69:

https://gitlab.com/larswirzenius/vmdb2/-/issues/69

And proposed a simplistic patch as merge request #106:

https://gitlab.com/larswirzenius/vmdb2/-/merge_requests/106

Just for completeness sake, I'm including the patch in this report as
well:

diff --git a/vmdb/plugins/mkfs_plugin.py b/vmdb/plugins/mkfs_plugin.py
index 7bb32b6..f0bef3b 100644
--- a/vmdb/plugins/mkfs_plugin.py
+++ b/vmdb/plugins/mkfs_plugin.py
@@ -51,6 +51,17 @@ class MkfsStepRunner(vmdb.StepRunnerInterface):
 cmd.append("-L")
 cmd.append(label)
 
+# Ext4 filesystem features large_dir and metadata_csum_seed
+# are known to make versions of GRUB older than 2.06-8 unable
+# to boot. Keep this around at least until it is no longer
+# likely enough(?) users will try to build older target
+# systems.
+if fstype == "ext4":
+cmd.append("-O")
+cmd.append("^large_dir")
+cmd.append("-O")
+cmd.append("^metadata_csum_seed")
+
 options = values["options"] or None
 if options:
 for opt in options.split(" "):

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Gunnar Wolf]

Hello Scarlett,

Scarlett Moore dijo [Sun, Feb 19, 2023 at 09:01:56AM -0700]:
> Package: wnpp
> Severity: wishlist
> Owner: Scarlett Moore 
> X-Debbugs-Cc: debian-de...@lists.debian.org, sgmo...@debian.org
> 
> * Package name: gum
>   Version : 0.9.0
>   Upstream Author : Charmbracelet Inc.
> * URL : https://github.com/charmbracelet/gum
> * License : MIT
>   Programming Lang: Golang
>   Description : A tool for glamourous shell scripts
> 
> A tool for glamorous shell scripts. Leverage the power of Bubbles and 
> Lip Gloss in your scripts and aliases without writing any Go code!

I urge you to use a clearer explanation for the Description field --
The short description is fine,but the long description leaves me
scratching my head. Bubbles and Lip Gloss? Never heard of them. Bash
supports aliases, why the need to pull in Go? etc.

Thanks,

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices

[Gunnar Wolf]

Hi!

Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]:
> > Would they fit into a separate source package not associated with
> > raspi-config?
> 
> I do strongly think they do not belong in the raspi-firmware package for the 
> reason I retitled this bug and retitled my response Subject. Another reason 
> is 
> that the raspi-firmware package makes (several) assumptions, namely that they 
> are only used/usable on RPi devices and have a /boot/firmware directory 
> (where 
> a FAT partition is mounted, although that part is not checked for).
> I have previously expressed my concerns/doubts about that, but that's outside 
> the scope of this bug.
> It also looks 'weird' to install the raspi-firmware package while you only 
> care 
> about the wifi firmware and not care about RPi's at all.

Right, I agree this should be a package of its own. I didn't know
raspi-nonfree came from a "coherent" set of firmware sources provided
by a single upstream. It is a distorsion that peopleinterested in
brcmfmac firmware have to install raspi-firmware if they have
different hardware.

> > The other option is that they get included upstream in
> > linux-firmware.git by upstream?
> 
> Gunnar knows I'm not much of a fan of Raspberry Pi Foundation (RPF) and that 
> was confirmed once again by their typical reaction to this exact request. 
> 
> I'm too 'lazy' to look it up, so I'll paraphrase it:
> "It works for us (so fsck off). Can't you just use our files?"

I doubt we will find true RPF fans here 


signature.asc
Description: PGP signature

Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area

[Gunnar Wolf]

Package: debian-policy
Version: 4.6.2.0
Severity: normal
Tags: patch

It has been four months since the General Resolution 2022/vote_003 was
voted¹, but it has not yet been completely adopted. The archive area
was created and at least a package was uploaded to it in October, but
it has not seen further movement. Two days ago, a call to action for
moving packages was sent by Cyril Brulebois², and I just sent a mail
checking for other places where it should be included³.

¹ https://www.debian.org/vote/2022/vote_003
² https://lists.debian.org/debian-boot/2023/01/msg00150.html
³ https://lists.debian.org/debian-project/2023/01/msg00018.html

To my surprise, the non-free-firmware archive area has not yet been
discussed for inclusion in the Policy.

I am (now!) aware there is a clear process to get changes included in
the Policy, but this is the first time I do this, so please excuse me
for jumping all the way to "State D: Wording proposed" (of course, my
words can be checked and improved, particularly given I'm not a native
English speaker).

⁴ https://www.debian.org/doc/debian-policy/ap-process.html

I am suggesting the following patch, which I'm attaching to this bug
report, and also uploaded them to my fork of debian-policy in Salsa:


https://salsa.debian.org/gwolf/policy/-/commit/79c58a40065c01f56850f86e883d8fa482c7cca0

Thank you very much for considering this!

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
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

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  5.3.0-3

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information
diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index ab04261..15b9343 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -24,11 +24,11 @@ The aims of this are:
 
 The *main* archive area forms the *Debian distribution*.
 
-Packages in the other archive areas (``contrib``, ``non-free``) are not
-considered to be part of the Debian distribution, although we support
-their use and provide infrastructure for them (such as our bug-tracking
-system and mailing lists). This Debian Policy Manual applies to these
-packages as well.
+Packages in the other archive areas (``non-free-firmware``,
+``contrib``, ``non-free``) are not considered to be part of the Debian
+distribution, although we support their use and provide infrastructure
+for them (such as our bug-tracking system and mailing lists). This
+Debian Policy Manual applies to these packages as well.
 
 .. _s-dfsg:
 
@@ -130,6 +130,27 @@ In addition, the packages in *main*
 
 - must meet all policy requirements presented in this manual.
 
+.. _s-non-free-firmware:
+
+The non-free-firmware archive area
+~~
+
+The *non-free-firmware* archive area contains packages providing
+firmware needed to initialize, use or keep updated hardware required
+by our users, typically necessary for important functions to be
+available (i.e. wireless network connectivity) or for fixing security
+defects in hardware (i.e. CPU microcode updates). Packages in this
+archive may not comply with all of the policy requirements in this
+manual due to lack of source code availability, restrictions on
+modification or other limitations.
+
+Packages in *non-free-firmware*
+
+- must not be so buggy that we refuse to support them, and
+
+  - must meet all policy requiremens presented in this manual that it
+is possible for them to meet.
+
 .. _s-contrib:
 
 The contrib archive area
@@ -261,8 +282,8 @@ prohibited" and "distribution restricted".
 Sections
 
 
-The packages in the archive areas *main*, *contrib* and *non-free* are
-grouped further into *sections* to simplify handling.
+The packages in the archive areas *main*, *non-free-firmware*, *contrib*
+and *non-free* are grouped further into *sections* to simplify handling.
 
 The archive area and section for each package should be specified in the
 package's ``Section`` control record (see
@@ -272,8 +293,8 @@ the Debian distribution. The ``Section`` field should be of 
the form:
 
 -  *section* if the package is in the *main* archive area,
 
--  *area/section* if the package is in the *contrib* or *non-free*
-   archive areas.
+-  *area/section* if the package is in the *non-free-firmware*, *contrib*
+   or *non-free* archive areas.
 
 The Debian archive maintainers provide the authoritative list of
 sections. At present, they are: admin, cli-mono, comm, database, debug,

Bug#1027287: bookworm: Segfaults when trying to use basic buttons

[Gunnar Wolf]

Package: bookworm
Version: 1.1.2+git20210715-2
Severity: important

I am trying to read my first epub book with bookworm. Whenever I press
either the "Library", "Table of contents" or "Reading preferences"
buttons, bookworm unceremoniously dies with a segmentation fault.

I cannot share the ebook I'm trying to read to the BTS, as it's a
copyrighted book; I can privately share it to the maintainer if it's
for debugging purposes, in case you think it's necessary to pinpoint
the bug.

In case it's relevant, I'm running under the Sway Wayland compositor,
and bookworm does open as a Sway client (no xwayland emulation).

Thanks!

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

Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 bookworm depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  html2text1.3.2a-28
ii  libc62.36-6
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
pn  libgee-0.8-2 
ii  libglib2.0-0 2.74.3-1
pn  libgranite6  
ii  libgtk-3-0   3.24.35-3
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpoppler-glib8 22.08.0-2.1
ii  libsoup2.4-1 2.74.3-1
ii  libsqlite3-0 3.40.0-1
ii  libwebkit2gtk-4.0-37 2.38.2-1+b1
ii  libxml2  2.9.14+dfsg-1.1+b2
ii  poppler-utils22.08.0-2.1
ii  python3  3.10.6-3
ii  unar 1.10.7+ds1+really1.10.1-2+b1
ii  unzip6.0-27

bookworm recommends no packages.

bookworm suggests no packages.

Bug#1027286: bookworm: Please provide a symlink to the binary with a more memorable name (i.e. /usr/bin/bookworm)

[Gunnar Wolf]

Package: bookworm
Version: 1.1.2+git20210715-2
Severity: wishlist
Tags: patch

I understand the reasons why Bookworm's binary must have the
unconventional long name "com.github.babluboy.bookworm" name, given
several language ecosystems insist on encoding the component's Web
locations as part of their names. However, on a Debian system, we have
grown used to just "apt install pkgname" and expect to find a
"pkgname" binary to launch it with.

Could you provide a symlink named /usr/bin/bookworm to
/usr/bin/com.github.babluboy.bookworm for it to be more easy to
launch?

Of course, the patch is trivial, but provided nevertheless:

diff --git a/debian/bookworm.links b/debian/bookworm.links
new file mode 100644
index 000..e1aa0a4
--- /dev/null
+++ b/debian/bookworm.links
@@ -0,0 +1 @@
+/usr/bin/com.github.babluboy.bookworm /usr/bin/bookworm

Thanks!

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

Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 bookworm depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  html2text1.3.2a-28
ii  libc62.36-6
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
pn  libgee-0.8-2 
ii  libglib2.0-0 2.74.3-1
pn  libgranite6  
ii  libgtk-3-0   3.24.35-3
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpoppler-glib8 22.08.0-2.1
ii  libsoup2.4-1 2.74.3-1
ii  libsqlite3-0 3.40.0-1
ii  libwebkit2gtk-4.0-37 2.38.2-1+b1
ii  libxml2  2.9.14+dfsg-1.1+b2
ii  poppler-utils22.08.0-2.1
ii  python3  3.10.6-3
ii  unar 1.10.7+ds1+really1.10.1-2+b1
ii  unzip6.0-27

bookworm recommends no packages.

bookworm suggests no packages.

Bug#1027155: gnumeric: Description talks about Gnumeric specifically for the X Window system, is now obsolete

[Gunnar Wolf]

Package: gnumeric
Version: 1.12.53-1.1
Severity: wishlist

The package description mentions "(...)set of applications and desktop
tools to be used in conjunction with a window manager for the X Window
System". GNOME is now Wayland-native, and it can run with Wayland
compositors, so this particular bit of the description is obsolete
(and misleading).


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

Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 gnumeric depends on:
ii  debconf [debconf-2.0]  1.5.80
ii  gnumeric-common1.12.53-1.1
ii  gsfonts2:20200910-6
ii  libatk1.0-02.46.0-4
ii  libc6  2.36-6
ii  libcairo2  1.16.0-7
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1
ii  libglib2.0-0   2.74.3-1
ii  libgoffice-0.10-10 0.10.53-1
ii  libgsf-1-114   1.14.50-1
ii  libgtk-3-0 3.24.35-3
ii  libpango-1.0-0 1.50.10+ds-1
ii  libpangocairo-1.0-01.50.10+ds-1
ii  libxml22.9.14+dfsg-1.1+b2
ii  procps 2:4.0.2-2
ii  pxlib1 0.6.8-1+b1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages gnumeric recommends:
ii  evince43.1-2
ii  gnumeric-doc  1.12.53-1.1
ii  lp-solve  5.5.2.5-2

Versions of packages gnumeric suggests:
ii  fonts-liberation1:1.07.4-11
pn  gnumeric-plugins-extra  
pn  libgsf-1-dev

-- debconf information excluded

Bug#1024652: ruby3.0: Segmentation fault from irb when performing a simple multiplication

[Gunnar Wolf]

Antonio Terceiro dijo [Wed, Dec 07, 2022 at 03:29:41PM -0300]:
> > > (And just to be on the safe side, maybe you could do a memory test
> > > to exclude a hardware failure.)
> > 
> > OK -- I cannot say I'll do a memtest right now, as this is a
> > productive machine, but will do it soon-ish ☺
> > 
> > I have the following in my .irbrc:
> > (...)
> My guess is that wirble is the culprit. How was it installed? What's the
> probability that it was built for a different Ruby interpreter?
> 
> (irb itself does colors nowadays so you should not need wirble.
> according to rubygems.org the last release was in 2009).

Right, Wirble makes no sense... And I don't have it installed; its
symbols are not installed in irb. It seems that irb silently fails
missing 'require' statements.

Bug#1024652: ruby3.0: Segmentation fault from irb when performing a simple multiplication

[Gunnar Wolf]

Bernhard Übelacker dijo [Wed, Dec 07, 2022 at 03:14:40PM +0100]:
> Dear Gunnar,
> I tried to collect some more information for the Maintainer.

Thanks!

> First I need to create a .irbrc with the USE_SINGLELINE
> set to true, to reach any function in libedit/readline.
> 
> Next I tried to reach the address given in _IO_new_file_overflow,
> but was not able to. This might be related to some EOF handling
> or some customer buffer settings.

OK...?

> Therfore, maybe you could have a look at your .irbrc
> if there is any setting that sounds related.
> 
> (And just to be on the safe side, maybe you could do a memory test
> to exclude a hardware failure.)

OK -- I cannot say I'll do a memtest right now, as this is a
productive machine, but will do it soon-ish ☺

I have the following in my .irbrc:

IRB.conf[:AUTO_INDENT] = true
IRB.conf[:USE_READLINE] = true
IRB.conf[:SAVE_HISTORY] = 5000
IRB.conf[:HISTORY_FILE] = "#{ENV['HOME']}/.irb_history"
IRB.conf[:PROMPT_MODE] = :SIMPLE

require 'irb/completion'
require 'irb/ext/save-history'
require 'pp'

# load rubygems and wirble
require 'rubygems' rescue nil
require 'wirble'

# load wirble
Wirble.init
Wirble.colorize

Thanks a lot for looking into this -- I haven't seen any other
instance of this issue, nor any other strange behavior, from this
computer so far.

Bug#1024823: tech-ctte: Call for votes on TC membership of Matthew Garrett

[Gunnar Wolf]

Sean Whitton dijo [Fri, Nov 25, 2022 at 03:39:12PM -0700]:
> Package: tech-ctte
> X-debbugs-cc: mj...@debian.org, lea...@debian.org
> 
> I call for votes on the following ballot to fill a vacant seat on the
> Debian Technical Committee.  The voting period starts immediately and
> lasts for up to one week, or until the outcome is no longer in doubt.
> 
> ===BEGIN
> The Technical Committee recommends that Matthew Garrett  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> H: Recommend to Appoint Matthew Garrett 
> F: Further Discussion
> ===END

My vote is:

H > F

Thanks Sean!


signature.asc
Description: PGP signature

Bug#1024652: ruby3.0: Segmentation fault from irb when performing a simple multiplication

[Gunnar Wolf]

Package: ruby3.0
Version: 3.0.4-8
Severity: normal

I often use irb for many quick checks in my system. I was quite amazed
to find the segfault I am attaching; I was unable to reproduce it, but
still, I believe it to be worth reporting. It seems to come from
_something_ in the call to the C function for readline.

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

Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 ruby3.1 depends on:
ii  libc6 2.36-5
ii  libcrypt1 1:4.4.30-1
ii  libgmp10  2:6.2.1+dfsg1-1.1
ii  libruby3.13.1.2-3
ii  rubygems-integration  1.18
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages ruby3.1 recommends:
ii  fonts-lato2.0-2.1
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1

ruby3.1 suggests no packages.

-- no debconf information
$ irb
Ignoring nokogiri-1.10.1 because its extensions are not built. Try: gem 
pristine nokogiri --version 1.10.1
>> 2 * 1.03
=> 20600.0
/usr/lib/ruby/3.0.0/irb/input-method.rb:215: [BUG] Segmentation fault at 
0x55ae1400
ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [x86_64-linux-gnu]

-- Control frame information ---
c:0020 p: s:0091 e:90 CFUNC  :readline
c:0019 p:0038 s:0085 e:84 METHOD /usr/lib/ruby/3.0.0/irb/input-method.rb:215
c:0018 p:0008 s:0080 e:79 BLOCK  /usr/lib/ruby/3.0.0/irb.rb:529
c:0017 p:0024 s:0076 e:75 METHOD /usr/lib/ruby/3.0.0/irb.rb:751
c:0016 p:0007 s:0070 e:69 BLOCK  /usr/lib/ruby/3.0.0/irb.rb:528
c:0015 p:0005 s:0067 e:66 METHOD /usr/lib/ruby/3.0.0/irb/ruby-lex.rb:267
c:0014 p:0008 s:0061 e:60 BLOCK  /usr/lib/ruby/3.0.0/irb/ruby-lex.rb:236 
[FINISH]
c:0013 p: s:0057 e:56 CFUNC  :loop
c:0012 p:0005 s:0053 e:52 BLOCK  /usr/lib/ruby/3.0.0/irb/ruby-lex.rb:233 
[FINISH]
c:0011 p: s:0050 e:49 CFUNC  :catch
c:0010 p:0010 s:0045 e:44 METHOD /usr/lib/ruby/3.0.0/irb/ruby-lex.rb:232
c:0009 p:0046 s:0041 E:0020e8 METHOD /usr/lib/ruby/3.0.0/irb.rb:547
c:0008 p:0004 s:0036 e:35 BLOCK  /usr/lib/ruby/3.0.0/irb.rb:481 [FINISH]
c:0007 p: s:0033 e:32 CFUNC  :catch
c:0006 p:0058 s:0028 E:000f40 METHOD /usr/lib/ruby/3.0.0/irb.rb:480
c:0005 p:0104 s:0022 e:21 METHOD /usr/lib/ruby/3.0.0/irb.rb:409
c:0004 p:0019 s:0016 e:15 TOP
/usr/lib/ruby/gems/3.0.0/gems/irb-1.3.5/exe/irb:11 [FINISH]
c:0003 p: s:0013 e:12 CFUNC  :load
c:0002 p:0112 s:0008 E:30 EVAL   /usr/bin/irb:23 [FINISH]
c:0001 p: s:0003 E:001fe0 (none) [FINISH]

-- Ruby level backtrace information 
/usr/bin/irb:23:in `'
/usr/bin/irb:23:in `load'
/usr/lib/ruby/gems/3.0.0/gems/irb-1.3.5/exe/irb:11:in `'
/usr/lib/ruby/3.0.0/irb.rb:409:in `start'
/usr/lib/ruby/3.0.0/irb.rb:480:in `run'
/usr/lib/ruby/3.0.0/irb.rb:480:in `catch'
/usr/lib/ruby/3.0.0/irb.rb:481:in `block in run'
/usr/lib/ruby/3.0.0/irb.rb:547:in `eval_input'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:232:in `each_top_level_statement'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:232:in `catch'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:233:in `block in each_top_level_statement'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:233:in `loop'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:236:in `block (2 levels) in 
each_top_level_statement'
/usr/lib/ruby/3.0.0/irb/ruby-lex.rb:267:in `lex'
/usr/lib/ruby/3.0.0/irb.rb:528:in `block in eval_input'
/usr/lib/ruby/3.0.0/irb.rb:751:in `signal_status'
/usr/lib/ruby/3.0.0/irb.rb:529:in `block (2 levels) in eval_input'
/usr/lib/ruby/3.0.0/irb/input-method.rb:215:in `gets'
/usr/lib/ruby/3.0.0/irb/input-method.rb:215:in `readline'

-- Machine register context 
 RIP: 0x7fbfd7192d25 RBP: 0x RSP: 0x7ffebfb23100
 RAX: 0x55ae1400 RBX: 0xff70 RCX: 0x0c00
 RDX: 0xfc00 RDI: 0x7fbfd72ccc60 RSI: 0x55ae14ed34b3
  R8: 0x  R9: 0x7ffebfb230e0 R10: 0x0004
 R11: 0x0001 R12: 0x R13: 0x7fbfd72c95e0
 R14: 0x0001 R15: 0x55ae15040220 EFL: 0x00010206

-- C level backtrace information ---
/lib/x86_64-linux-gnu/libruby-3.0.so.3.0(0x7fbfd76ec47c) [0x7fbfd76ec47c]
/lib/x86_64-linux-gnu/libruby-3.0.so.3.0(0x7fbfd7543280) [0x7fbfd7543280]
/lib/x86_64-linux-gnu/libruby-3.0.so.3.0(0x7fbfd7662e8b) [0x7fbfd7662e8b]
/lib/x86_64-linux-gnu/libc.so.6(__restore_rt+0x0) [0x7fbfd7135f90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_free+0x65) [0x7fbfd7192d25]
/lib/x86_64-linux-gnu/libc.so.6(_IO_free_backup_area+0x15) [0x7fbfd717cb75]
/lib/x86_64-linux-gnu/libc.so.6(_IO_file_overflow+0x1c7) 

Bug#999578: dmarc-cat: Please make it accept data via STDIN

[Gunnar Wolf]

Hello Antoine,

Antoine Beaupré dijo [Tue, Nov 08, 2022 at 09:13:01AM -0500]:
> > dmarc-cat insists AFAICT to work on existing files. I tried to get it
> > to process the reports I found attached to received mails; for this, I
> > would love to be able to ask my MTA to pipe the attachment to
> > dmarc-cat. However, I could not get it to work, either with the
> > convention of using '-' or even with capturing via <( ... )
> >
> > So, please, could you add an option for dmarc-cat to work on reports
> > from STDIN?
> 
> It *looks* like this is fixed upstream, according to:
> 
> https://github.com/keltia/dmarc-cat/issues/14
> 
> I'm going to upload 0.15 soon-ish, maybe you can confirm it's fixed
> there? In any case, I'll marked this as fixed there because it looks
> like upstream assumes it's fixed, so it must have happened after 0.14...

Thanks for following up on this. I see it does now _say to_ accept
files via STDIN, but...

$ dmarc-cat -h
Usage of dmarc-cat:
  -DDebug mode
  -NDo not resolve IPs
  -S string
Sort results (default "\"Count\" \"dsc\"")
  -j int
Parallel jobs (default 8)
  -t string
File type for stdin mode
  -vVerbose mode
  -version
Display version
$ dmarc-cat
2022/11/09 12:27:08 Error: realmain: You must specify at least one file.
$ dmarc-cat -
2022/11/09 12:27:10 Error: SelectInput: Wrong file type, use -t

It really lacks documentation! :-( I don't know where to get the
filetype from.

Took a quick dive in dmarc-cat's source, and found only two probable
strings as file types: ".zip" and ".xml". It was not a very scientific
test, but:

$ grep -ri ftype .
./file.go:  debug("%d %s", typ, fType)
./main.go:  fType string
./main.go:  flag.StringVar(, "t", "", "File type for stdin mode")
./main.go:  if fType == "" {
./main.go:  var fType = filepath.Ext(file)
./main.go:  if strings.ToLower(fType) == ".zip" {
./main.go:  typ := archive.Ext2Type(fType)
./main_test.go: fType = ".xml"
./main_test.go: fType = ""
$

But handling it as .zip does not seem to work:

$ cat report.zip | dmarc-cat -t .zip -
2022/11/09 12:34:38 Error: file -:: unmarshall: XML syntax error on line 2: 
illegal character code U+0003

However, it does work when I give it the uncompressed XML:

$ unzip -p file.zip  | dmarc-cat -t .zip -
dmarc-cat 0.15.0,parallel/j8 by Ollivier Robert

Reporting by: google.com — noreply-dmarc-supp...@google.com
From 2022-03-28 18:00:00 -0600 CST to 2022-03-29 17:59:59 -0600 CST

Domain: gwolf.org
Policy: p=none; dkim=r; spf=r

Reports(1):
IP Count   From  RFrom RDKIM   RSPF
mail.iiec.unam.mx. 2   gwolf.org gwolf.org passpass

Given that file.go has the needed bits to handle a .zip file, I'd
still consider a bug to be present (albeit a different one).

I was able to find two spots in the code where this was not correctly
handled. First, in main.go, fType is clobbered even if specificed; it
should only be replaced if not specified:

diff --git a/main.go b/main.go
index 736a8e7..e6d4e98 100644
--- a/main.go
+++ b/main.go
@@ -115,7 +115,9 @@ func realmain(args []string) error {
 
verbose("Analyzing %s", file)
 
-   var fType = filepath.Ext(file)
+   if fType == "" {
+   fType = filepath.Ext(file)
+   }
 
if strings.ToLower(fType) == ".zip" {
txt, err = HandleZipFile(ctx, file)

The other point is in file.go. It seems trivial to fix, but I've never
worked with Go before; function HandleZipFile is failing to open a
file named "-"; it should just read it if so speficied. I tried to
copy the differing logic from HandleSingleFile, but failed and decided
to throw the ball back at you ;-)

Anyway, besides getting dmarc-cat to work with piped zip files, it
should at least be minimally documented!

Thanks,

 - Gunnar.

Bug#1021728: tracker.debian.org: Please include the new "non-free-firmware" section

[Gunnar Wolf]

Package: tracker.debian.org
Severity: normal

Hello,

Last week I uploaded raspi-firmware to non-free-firmware (and was
promptly processed through NEW, whee!).

Two days ago, it successfully migrated to Texting.

I am now building the Raspberry Pi images for Bookworm , and
raspi-firmware is correctly downloaded from non-free-firmware.

However, tracker.debian.org misleadingly shows the package as if it
was removed from Debian («package is gone. This package is not in any
development repository. (...)», and no longer lists it for testing and
unstable.

Thank you very much!

Bug#1021337: linux-image-5.19.0-2-amd64: Please enable building of the idxd module for the IntelData Accelerator support

[Gunnar Wolf]

Vincent Blut dijo [Thu, Oct 06, 2022 at 12:48:58PM +0200]:
> > > Specifically, the required configuration options to enable all of its
> > > features are:
> > >CONFIG_INTEL_IDXD=m
> > >CONFIG_INTEL_IDXD_SVM=y
> > 
> > Is this only applicable for the amd64 architecture or is it useful for 
> > others 
> > as well?
> 
> Since these depend on X86_64, only amd64 is concerned.

Right. And as I mentioned in the bug report,

The driver enables the Data Streaming Accelerator or DSA
capability for the 4th generation of the Intel Scalable Xeon
processor family, with code name Sapphire Rapids, and for future
Intel processors.

So, yes, it is relevant only for relatively recent x86_64 chips
produced by Intel (> 2019). For further details,

https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator


signature.asc
Description: PGP signature

Bug#1021337: linux-image-5.19.0-2-amd64: Please enable building of the idxd module for the IntelData Accelerator support

[Gunnar Wolf]

Package: linux-image-5.19.0-2-amd64
Severity: normal
X-Debbugs-Cc: jair.de.jesus.gonzalez.plascen...@intel.com, 
miguel.bernal.ma...@intel.com

Hello,

I was recently approached by Intel engineers Jair de Jesús Gonzalez
Plascencia and Miguel Bernal Marín, both Cc:ed here. They asked me for
help to get the needed components for Intel Data Accelerator in
Debian.

A necessary first step towards achieving this is having the needed
module built as part of our kernels; this driver has been part of
Linux since 5.6. This report is to request you to add the module in
Debian. Quoting from their mail to me:

Specifically, the required configuration options to enable all of its
features are:

   CONFIG_INTEL_IDXD=m
   # Intel Data Accelerators support
   # found in Linux kernels: 5.6–5.19, 6.0-rc+HEAD

   CONFIG_INTEL_IDXD_SVM=y
   # Accelerator Shared Virtual Memory Support
   # found in Linux kernels: 5.11–5.19, 6.0-rc+HEAD

   Other required configuration options that are already present in the
   Debian Bullseye and Debian Bookworm kernels are:

   CONFIG_INTEL_IOMMU=y
   CONFIG_INTEL_IOMMU_SVM=y
   CONFIG_IRQ_REMAP=y
   CONFIG_PCI_ATS=y
   CONFIG_PCI_PRI=y
   CONFIG_PCI_PASID=y
   CONFIG_DMA_ENGINE=y

- What does it enable? / What is the use case?

The driver enables the Data Streaming Accelerator or DSA
capability for the 4th generation of the Intel Scalable Xeon
processor family, with code name Sapphire Rapids, and for future
Intel processors.

As stated in the DSA specification (which can be found at

https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification):

The driver enables the Data Streaming Accelerator or DSA
capability for the 4th generation of the Intel Scalable Xeon
processor family, with code name Sapphire Rapids, and for future
Intel processors.

As stated in the DSA specification (which can be found at

https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification
 ):

Intel DSA is a high-performance data copy and transformation
accelerator that will be integrated in future Intel® processors,
targeted for optimizing streaming data movement and transformation
operations common with applications for high-performance storage,
networking, persistent memory, and various data processing
applications.

Intel DSA replaces Intel® QuickData Technology, which is a part of
Intel® I/O Acceleration Technology.

This request comes as a requisite for the packaging of the userspace
components of this functionality (WNPP bug is to be fixed once I got a
bug number assigned for this report).

This functionality is available starting at Intel's fourth generation
of Scalable Xeon server processors, code-named Sapphire
Rapids. Currently some SPR products are planned to be launched on 2022
calendar week 42 and 2022 calendar week 45. High volume SPR processors
have a planned launch window on 2023 calendar week 6 to 9 (Feb. 6,
2023 to March 3, 2023).

Thank you very much!


   - Gunnar
 (but really, this should be signed by Miguel and Jair ;-) )

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

Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
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

-- 



signature.asc
Description: PGP signature

Bug#1020923: tech-ctte: please clarify if atomic updates are required

[Gunnar Wolf]

Hi Ansgar,

Ansgar dijo [Wed, Sep 28, 2022 at 10:18:26PM +0200]:
> Any package relevant for successful boot. Any upgrade.
> 
> As far as I can tell, the submitter requires some guarantees
> significantly stronger than what Debian requires for essential
> packages.
> 
> In particular, boot-relevant packages are demanded to work in
> unconfigured state, with not fully satisfied dependencies (possibly not
> even unpackaged?), in partly unpackaged states, after maintainer script
> errors, and all of that in combination with system crashes that might
> result in partly written data to filesystems. And possibly in other
> interesting system states too.

Humm, as the maintainer for raspi-firmware, this definitively
addresses an area where I'm responsible. So this is naturally
interesting for me even outside my TC role.

There is a point I somewhat agree with Bug#1020920's submitter:
Packages modifying the packages involved in system boot need to be
extra careful to reduce the window of vulnerability for an unbootable
system as much as possible.

However, no matter how careful we are, I do not think it's expectable
that we can guarantee the atomic interaction mode Zack W. suggests —
There is no syscall matching "rename and create a symlink". And even
if we had one, it would most probably still become two separate
filesystem operations in the end. Of course, the supported
filesystems' code could be modified so that said operation sequence
could be added to the journal beforehand, so they can be effectively
considered as atomic, but...

That's quite an unrealistic expectation. We cannot expect to implement
actions not expressable in the set of primitives Linux exposes to
us. We cannot expect a (quite invasive I'd expect) kernel patch to be
applied just because we want to run usrmerge.

> > (2) The TC is a decision-making body of last resort.  The bug you
> >     mention was filed today.  Might this be premature?
> 
> Well, if we close it or don't act on it, people will complain and/or
> demand to remove us from Debian for not acting on it (the latter might
> be limited to people just sitting on their porch).
> 
> The other tech-ctte bug about usrmerge also suggested it would just end
> up here either way.

There is a high chance we might end up getting this bug in the TC,
given the spirits we have seen around merged-/usr. However, I agree
with Sean: This bug is too early to summon the TC.

I know that if I suggest you to bring the issue to d-devel@l.d.o it
will fuel a flamewar, but I see no other proper way to handle _this
particular mail_. Maybe the request could be phrased differently, in a
way it could encompass this bug report (i.e. "ask the TC whether we
might use sloppy techniques when upgrading, considering the risks we
take as acceptable" (of course, I don't mean your job is sloppy, it's
just an example text that will not be accepted if asked )

So... I'm also inclined to ask you to please close this TC bug, as it
is not acceptable for a TC ruling. (Also, how many rulings does it
make sense for the TC to hold on the same tired topic of merged-/usr?)

Greetings,

- Gunnar.


signature.asc
Description: PGP signature

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Gunnar Wolf]

Christoph Berg dijo [Tue, Sep 27, 2022 at 10:23:32PM +0200]:
> Re: Sean Whitton
> > Therefore, we will likely just close this bug, I'm afraid.
> 
> +1 on closing from me.

I agree this bug should be closed. I won't comment more, as there is
not much more to add without going in circles back to
already-discussed issues.


signature.asc
Description: PGP signature

Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Gunnar Wolf]

Simon McVittie dijo [Thu, Aug 25, 2022 at 11:19:30AM +0100]:
> Obviously that's quite a bit of churn, mostly in packages that, in
> practice, have never been useful to run on the 2009-2010 plug computers
> that seem to be the main use-case for armel.
> 
> Is armel a realistic candidate for being a Debian 12 release
> architecture? It's already lacking other important packages like Firefox,
> and if it ceased to be treated as a release architecture very soon,
> then we wouldn't have to do all this work to coax GNOME into testing
> despite armel.

While I would never attempt to run a heavy desktop under such
machines, I think there are still many users of Debian in armel
machines -- me included!

The Raspberry Pi families for models 0 and 1 are
almost-but-not-quite-armhf (so they must run armel). There are several
million such devices Out There™; while the RPi1 family does not make
too much sense for buying nowadays (being at the same price as RPi3,
which is vastly more powerful), hardware availability for the much
smaller RPi0W (introduced in 2015/2017, according to Wikipedia) is
much more than of the newer RPI0W-2 (oh, the naming for such
machines...)

I cannot provide hard numbers (I suppose mirror operators might?), but
I do not feel armel systems are hard to come by, nor marginal in the
amount of users they have. Yes, running a GNOME desktop on them might
be a Very Bad Idea (if at all possible)...  But they are very good
non-interactive purposes.

Bug#1017804: ITP: pw -- interactively filtered pipe watcher

[Gunnar Wolf]

Antoine Beaupre dijo [Sat, Aug 20, 2022 at 03:17:52PM -0400]:
> Package: wnpp
> Severity: wishlist
> Owner: Antoine Beaupre 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: pw
>   Version : 2
>   Upstream Author : Kaz Kylheku
> * URL : https://www.kylheku.com/cgit/pw/
> * License : BSD-2
>   Programming Lang: C
>   Description : interactively filtered pipe watcher
> (...)

Might I suggest the name "pipewatcher" or "pipewatch"? Two-letter-long
package names abuse the namespace. Maybe the installed binary, yes,
can remain pw (I think I'd use it quite often, less typing is good),
but you should think it calmly :-]

> (...)
> For instance the command "tcpdump -i  -l | pw" turns
> tcpdump into an interactive network monitoring tool in which you can
> use the dynamic filtering in pw to select different kinds of packets,
> and use the trigger feature to capture certain patterns of
> interaction.
> 
> pw is like an oscilloscope for text streams. Digital oscilloscopes
> sample the signal and pass it through a fifo, which is sampled to the
> oscilloscope screen, and can trigger the sampling on certain
> conditions in the signal to make waveforms appear to stand still. pw
> does something like that for text streams.

The whole thing looks _quite_ interesting! I hope you do get to
package it. And, given I know your inclinations.. Once you do, please
blog so we all remember to download it, test it, and add it to our
toolbelt!

Bug#1017424: alsa-ucm-conf: Please add support for the Lenovo C630 laptop (ARM64)

[Gunnar Wolf]

Package: alsa-ucm-conf
Version: 1.2.7.2-1
Severity: wishlist
Tags: patch

Please consider applying the diff I am attaching. The Lenovo C630
laptop (ARM64-based) does not have sound support otherwise. I
understand this patch has been offered upstream, but got no reply
whatsoever.

I am sending this as a diff, but is available at Steev Klimaszewski
Salsa repository, commit 4b2c846, at:

https://salsa.debian.org/steev/alsa-ucm-conf

Thanks in advance,

  - Gunnar.

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

Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: 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 alsa-ucm-conf depends on:
ii  libasound2  1.2.7.2-1

alsa-ucm-conf recommends no packages.

alsa-ucm-conf suggests no packages.

-- no debconf information
diff --git a/debian/changelog b/debian/changelog
index e5c2829..43406d4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+alsa-ucm-conf (1.2.7.2-1linaro1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add C630 support
+
+ -- Steev Klimaszewski   Thu, 04 Aug 2022 22:11:09 -0500
+
 alsa-ucm-conf (1.2.7.2-1) unstable; urgency=medium
 
   * New upstream release.
diff --git 
a/debian/patches/0001-ucm2-DB845c-fixes-HDMI-select-card-and-HiFi-set-Digi.patch
 
b/debian/patches/0001-ucm2-DB845c-fixes-HDMI-select-card-and-HiFi-set-Digi.patch
new file mode 100644
index 000..c12855e
--- /dev/null
+++ 
b/debian/patches/0001-ucm2-DB845c-fixes-HDMI-select-card-and-HiFi-set-Digi.patch
@@ -0,0 +1,36 @@
+From 4bdcd82538daa39aed454f89a21734603d113b63 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?An=C3=ADbal=20Lim=C3=B3n?= 
+Date: Mon, 31 Aug 2020 17:31:08 -0500
+Subject: [PATCH] ucm2: DB845c fixes HDMI select card and HiFi set DigitalVol
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Aníbal Limón 
+---
+ ucm2/Qualcomm/sdm845/HDMI.conf | 10 +-
+ ucm2/Qualcomm/sdm845/HiFi.conf |  3 +++
+ 2 files changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/ucm2/Qualcomm/sdm845/HDMI.conf b/ucm2/Qualcomm/sdm845/HDMI.conf
+index 1844883..61be0da 100644
+--- a/ucm2/Qualcomm/sdm845/HDMI.conf
 b/ucm2/Qualcomm/sdm845/HDMI.conf
+@@ -19,8 +19,16 @@ SectionDevice."HDMI" {
+   #Name "HDMI"
+   Comment "HDMI Digital Stereo Output"
+ 
++  EnableSequence [
++  ]
++
++  DisableSequence [
++  ]
++
++
+   Value {
+-  PlaybackPCM "hw:${CardId}"
++  PlaybackPCM "hw:${CardId},0"
+   PlaybackPriority 200
+   }
++
+ }
diff --git 
a/debian/patches/0003-ucm.conf-support-KernelModule-CardLongName.conf-path.patch
 
b/debian/patches/0003-ucm.conf-support-KernelModule-CardLongName.conf-path.patch
new file mode 100644
index 000..49f02b0
--- /dev/null
+++ 
b/debian/patches/0003-ucm.conf-support-KernelModule-CardLongName.conf-path.patch
@@ -0,0 +1,28 @@
+From: Dmitry Baryshkov 
+Date: Fri, 29 Jan 2021 15:31:35 +0300
+Subject: ucm.conf: support KernelModule/CardLongName.conf paths
+
+Add support for 'ucm2/module/${KernelModule}/${CardLongName}.conf'
+paths.
+
+Signed-off-by: Dmitry Baryshkov 
+Change-Id: Ib006691e4b384543f97897c03fe575f8278e66f5
+---
+ ucm2/ucm.conf | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/ucm2/ucm.conf b/ucm2/ucm.conf
+index 9e78df1..a9613a2 100644
+--- a/ucm2/ucm.conf
 b/ucm2/ucm.conf
+@@ -53,6 +53,10 @@ If.driver {
+   False {
+   Define.KernelModulePath 
"class/sound/card${CardNumber}/device/driver/module"
+   Define.KernelModule "$${sys:$KernelModulePath}"
++  UseCasePath.modulelongname {
++  Directory "module/${var:KernelModule}"
++  File "${CardLongName}.conf"
++  }
+   UseCasePath.module {
+   Directory "module"
+   File "${var:KernelModule}.conf"
diff --git 
a/debian/patches/0004-module-add-new-symlink-for-Qualcomm-sdm845-driver.patch 
b/debian/patches/0004-module-add-new-symlink-for-Qualcomm-sdm845-driver.patch
new file mode 100644
index 000..6d46996
--- /dev/null
+++ 
b/debian/patches/0004-module-add-new-symlink-for-Qualcomm-sdm845-driver.patch
@@ -0,0 +1,21 @@
+From: Dmitry Baryshkov 
+Date: Fri, 29 Jan 2021 15:32:06 +0300
+Subject: module: add new symlink for Qualcomm/sdm845 driver
+
+Add module/snd_soc_sdm845 -> Qualcomm/sdm845 link.
+
+Signed-off-by: Dmitry Baryshkov 
+Change-Id: I5325033f47ee131499ed406ec56284bbf2f58b8d
+---
+ ucm2/module/snd_soc_sdm845 | 1 

Bug#991859: Is a different opinion about a license a case for the ctte?

[Gunnar Wolf]

Sam Hartman dijo [Tue, Aug 02, 2022 at 09:17:57AM -0600]:
>  
>  TL;DR: you don't have any recourse that is appropriate for this
>  situation.
>  All the hammers are bigger than your nail.

Well, hammers usually _are_ bigger than nails, otherwise... ;-)

But anyways...

>  The secretary ruled that the CT cannover overrule a delegate acting in
>  their delegated responsibility,
>  so no the CT cannot overrule ftpmaster.

Thanks for bringing this ruling up, Sam. Usually we do feel required
to answer to any questions brought up to us, although we have often
"decided not to take action" (or decided not to rule, but explicitly)
in the past.

>  The CT could give advice to ftpmaster, especially if ftpmaster requested
>  that advice.
>  I'd expect the CT would be reluctant to give non-technical advice.
>
>  The CT could set *technical policy* and I'd expect delegates would
>  generally be expected to follow reasonable technical policy established
>  by the CT or be accountable to the DPL and membership at large.
>  However, I don't really think that license standards are technical
>  enough to be technical policy.
>
>  ftpmaster could establish an appeals procedure.

Yes, that was more or less my line of thought upon first reading
Andreas' mail. I do not think licensing advice is the kind of advice
the TC is supposed to give. We do have a delegated body whose
authority is acknowledged by the whole project. And although we could
advice them to act differently, they can decide to ignore our
advice. So, if a licensing disagreement came up, the only real
resource IMO would be a GR. And I feel that would be too much for the
simple case you are presenting here.

Greetings,

Bug#1015855: wf-recorder: Stream sent to v4l2loopback device not readable

[Gunnar Wolf]

Subject: wf-recorder: Stream sent to v4l2loopback device not readable
Package: wf-recorder
Version: 0.3-1+b1
Severity: normal

I had been using wf-recorder to stream my Wayland session via ffmpeg
to a different computer¹, but after the update from 0.2.1 to 0.3 (and
even after the prompt described in #1015842), it seems to me the
output is not correctly formatted. If I grab the screen and redirect
to my v4l2loopback device, I get:

$ wf-recorder -g '0,32 960x720' -t --muxer=v4l2 --pixel-format=yuv420p 
--file=/dev/video10
Output file "/dev/video10" exists. Overwrite? Y/n: y
selected region 0,32 960x720
Setting codec option: crf=20
Setting codec option: preset=ultrafast
Setting codec option: tune=zerolatency
Using video filter: null
[libx264 @ 0x74001c30] using SAR=1/1
[libx264 @ 0x74001c30] MB rate (27) > level limit (16711680)
[libx264 @ 0x74001c30] using cpu capabilities: ARMv8 NEON
[libx264 @ 0x74001c30] profile Constrained Baseline, level 6.2, 4:2:0, 
8-bit
Output #0, video4linux2,v4l2, to '/dev/video10':
  Stream #0:0: Video: h264, yuv420p(pc), 960x720 [SAR 1:1 DAR 4:3], q=2-31

However, when I try to open the /dev/video10 device with a client
program, I get no usable data. Using guvcvideo:

$ guvcview -d /dev/video10 
V4L2_CORE: Unable to find parent usb device.V4L2_CORE: Unable to find 
parent usb device.V4L2_CORE: Unable to find parent usb device.GUVCVIEW: version 
2.0.7
V4L2_CORE: (UVCIOC_CTRL_MAP) Error: Inappropriate ioctl for device
V4L2_CORE: (UVCIOC_CTRL_MAP) Error: Inappropriate ioctl for device
V4L2_CORE: (UVCIOC_CTRL_MAP) Error: Inappropriate ioctl for device
V4L2_CORE: (UVCIOC_CTRL_MAP) Error: Inappropriate ioctl for device
V4L2_CORE: (UVCIOC_CTRL_MAP) Error: Inappropriate ioctl for device
V4L2_CORE: (UVCIOC_CTRL_MAP) Error: Inappropriate ioctl for device
V4L2_CORE: (UVCIOC_CTRL_MAP) Error: Inappropriate ioctl for device
V4L2_CORE: (UVCIOC_CTRL_MAP) Error: Inappropriate ioctl for device
V4L2_CORE: (UVCIOC_CTRL_MAP) Error: Inappropriate ioctl for device
{ VIDIOC_TRY_FMT (invalid values): width = 0, height = 0 }
v4L2_CORE: Unable to enumerate frame sizes :Invalid argument
{ VIDIOC_TRY_FMT (invalid values): width = 0, height = 0 }
v4L2_CORE: Unable to enumerate frame sizes :Invalid argument
{ VIDIOC_TRY_FMT (invalid values): width = 0, height = 0 }
v4L2_CORE: Unable to enumerate frame sizes :Invalid argument
{ VIDIOC_TRY_FMT (invalid values): width = 0, height = 0 }
v4L2_CORE: Unable to enumerate frame sizes :Invalid argument
V4L2_CORE: failed to subscribe events for control 0x00980001: Inappropriate 
ioctl for device
V4L2_CORE: failed to subscribe events for control 0x0098f900: Inappropriate 
ioctl for device
V4L2_CORE: failed to subscribe events for control 0x0098f901: Inappropriate 
ioctl for device
V4L2_CORE: failed to subscribe events for control 0x0098f902: Inappropriate 
ioctl for device
V4L2_CORE: failed to subscribe events for control 0x0098f903: Inappropriate 
ioctl for device
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.front
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround21
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround21
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround40
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround41
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround50
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround51
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.surround71
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.iec958
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping 
unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init 

Bug#1015842: wf-recorder: Spuriously requires interactive input when outputting to a socket

[Gunnar Wolf]

Subject: wf-recorder: Spuriously requires interactive input when outputting to 
a device node
Package: wf-recorder
Version: 0.3-1+b1
Severity: normal

After updating from 0.2.1 to 0.3, when I specify the output file to be
an existing device, wf-recorder requires me as a user to confirm the
destination file, disrupting some scripts. I suggest a check be put in
place, as device contents will not be obliterated (in contrast with
files'):

$ wf-recorder -g '0,32 960x720' -t --muxer=v4l2 --codec=rawvideo 
--pixel-format=yuv420p --file=/dev/video10
Output file "/dev/video10" exists. Overwrite? Y/n: 

Thank you very much,

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.16.11-yogurtu (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_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 wf-recorder depends on:
ii  libavcodec-extra59 [libavcodec59]  7:5.0.1-3+b1
ii  libavdevice59  7:5.0.1-3+b1
ii  libavfilter8   7:5.0.1-3+b1
ii  libavformat59  7:5.0.1-3+b1
ii  libavutil577:5.0.1-3+b1
ii  libc6  2.33-7
ii  libgcc-s1  12.1.0-5
ii  libpulse0  15.0+dfsg1-4+b1
ii  libstdc++6 12.1.0-5
ii  libswresample4 7:5.0.1-3+b1
ii  libwayland-client0 1.20.0-1
ii  sgml-base  1.30

wf-recorder recommends no packages.

wf-recorder suggests no packages.

-- no debconf information

Bug#1007717: Ballot and call for votes

[Gunnar Wolf]

Hello,

Sean Whitton dijo [Mon, Jun 20, 2022 at 05:31:16PM -0700]:
> Hello,
> 
> I hereby call for votes on the following resolution:
> 
> BEGIN BALLOT
> 
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.
> 
> END BALLOT

My vote is:

A > C > X > N

Thanks!


signature.asc
Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Gunnar Wolf]

Thank you very much for drafting the ballot, Matthew!

Matthew Vernon dijo [Wed, Apr 20, 2022 at 03:31:13PM +0100]:
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package containing rename.ul must not
> conflict with the rename package nor divert /usr/bin/rename.
> ===End Resolution A
> 
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B
> 
> ===Begin Resolution N
> None of the above
> ===End Resolution N

I vote A > B > N

Thanks!


signature.asc
Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Gunnar Wolf]

Thanks for drafting this, Matthew!

I have a small suggestion here:

Matthew Vernon dijo [Thu, Apr 14, 2022 at 04:47:17PM +0100]:
> Backwards-compatibility (and the lack of a compelling argument that
> util-linux's rename is significantly superior to the perl rename) means that
> /usr/bin/rename in Debian should remain the perl rename.

I'd prefer to read "that neither 'rename' implementation is superior
to the other", maybe even explaining that "they were designed out of
different needs and meet different criteria".

> The Technical Committee resolves that util-linux's rename should be shipped
> in a binary package build from src:util-linux. If this package Conflicts
 ^built

> Matthew
> ps; my first TC resolution, please be gentle if I have the procedure wrong!

Thanks again!

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files for wifi support in Raspberry p400

[Gunnar Wolf]

Please note I'm currenlty shipping the required files in
raspi-firmware -- I believe their right place is in
firmware-brcm80211, so please just ping me (or better, raise a bug on
raspi-firmware) whent they are added to this package.

Thanks!

Bug#1009164: ITP: gydl -- is a GUI wrapper around the already existing youtube-dl

[Gunnar Wolf]

Braulio Henrique Marques Souto dijo [Thu, Apr 07, 2022 at 09:26:27PM -0300]:
> * Package name: gydl
>   Version : 0.1.1
>   Upstream Author : Jannik Hauptvogel 
> * URL : https://github.com/JannikHv/gydl
> * License : (GPL2+)
>   Programming Lang: (Python)
>   Description : is a GUI wrapper around the already existing youtube-dl
> 
> Gydl (Graphical Youtube-dl) it's developed with a dialog driven experience
>  in mind. This provides a quick and easy video or audio downloads
>  without disturbances. Big thank you to the developer(s) of youtube-dl!

I suggest you rethink whether it's worth uploading it. The project
webpage states:

Fellow users,

Gydl is currently in a state where it is not worth enhancing/developing it 
in any way.

I currently don't have the resources to develop Gydl myself - thus
the amount of open issues.

I plan on keeping Gydl stable for how it currently is/works and
rewrite it completely in about half a year at the latest.

And yes, the Git repository has not had any activity for almost three
years. There are other youtube-dl wrappers already in the project, and
the UI does not look too different, for example, from the one provided
by youtubedl-gui.

Greetings,

Bug#1003958: Tries to remove ansible diectoriy several times in a row, leading to: ERROR: [Errno 2] No such file or directory

[Gunnar Wolf]

tags 1003958 + upstream
thanks

Hi,

Sorry for the long delay before looking into your bug report. I have
forwarded it to the upstream issue tracker, at:

   https://gitlab.com/larswirzenius/vmdb2/-/issues/63

The issue seems to be simple, I trust it will be fixed in the next
release.

Greetings,

Bug#1005846: raspi-firmware: after upgrade to raspi-firmware 1.20220120+ds-1 only one monitor works

[Gunnar Wolf]

tags 1005846 + pending
thanks

Upstream has released a new version fixing this issue, we will upload
it shortly.

Bug#1007719: raspi-firmware: Performance regression under RPi4B

[Gunnar Wolf]

Control: tags pending -1
thanks

We have followed this bug in the tracker linked to by Diederik (thanks
a lot to HankB for the abundant information and tests!), and confirmed
it to be fixed in the just released newversion (thanks popcornmix!)

I am busy with outside-of-Debian activities right now, but will try to
do the upload today or tomorrow.

Bug#994388: dpkg currently warning about merged-usr systems

[Gunnar Wolf]

Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]:
> I am part of that group, and that is definitely _not_ why I wouldn't
> touch dpkg with a barge pole as things stand (and have stood for
> years). You are making a gigantic leap with that assumption, not sure
> what you base it on. As a downstream and upstream maintainer in several
> large projects I fix things that don't impact me all the time, all over
> the place.
> 
> But anyway, it turns out it's all moot because - drum roll - there is a
> patch:
> 
> https://0x0.st/oNFG.diff
> 
> This was shared just now on #debian-devel IRC by user 'uau', linked
> here with explicit permission.
> 
> So it looks like you, Russ and others who chimed in this thread should
> now be in a position to test your theory that a missing patch was the
> only issue. Care to take it forward?

Wow, this is a positive turn of events! Do you happen to have more
information as to the identity of the submitter? We should be able of
properly granting attribution...

The patch seems sane from a first, very much 1m-point-of-view. Of
course, it is very situation-specific and not generalized for
following any unexpected symlinks in the directory hierarchy, but I do
not expect that to be an issue (as we are talking about a very
specific migration here). I am absolutely unfamiliar with dpkg
internals and there are some bits that jump to my eye, but I do not
think there is much use in me discussing very-minor things that should
be obvious to people who are actually involved with dpkg.

Has this diff been shared with Guillem, or included in any relevant
bug report?


signature.asc
Description: PGP signature

Bug#994388: dpkg currently warning about merged-usr systems

[Gunnar Wolf]

Russ Allbery dijo [Thu, Mar 24, 2022 at 04:50:44PM -0700]:
> > I think it's appropriate for people to wait on such work until there's
> > guidance from the TC ensuring that such a patch will be accepted.
> > Otherwise, anyone spending time writing it is spending substantial
> > effort that may well be wasted.
> 
> I think this is a totally fair thing to be concerned about.  Should such a
> patch exist -- with the obvious condition that I think it's quite
> reasonable to do several rounds of iteration on making that patch solid,
> ensuring there are tests, and so forth -- I think it's obvious that we
> should merge it given the previous TC decision.  Of course, I'm not a TC
> member.

I have informally talked with some other TC members; I am a TC member,
but am writing just as an individual DD.

You have said the TC has ruled to make an NMU in the past. I doubt an
NMU would fly -- The dpkg maintainer does not want to engage with the
TC, and I believe odds are high we could end up playing NMU
ping-pong. That's not in the best interests of our users nor the
project.

However, TTBOMK, no patches have been proposed. However, even given
his attitude, I trust he would apply a correctly done patch addressing
the issue at hand.

> It's difficult, procedurally, for the TC to do anything about a
> theoretical patch that someone could write but hasn't written.

Precisely. We cannot mandate a patch to be written. We can (and I _do_
think we should) require the maintainer to remove this warning -- not
because it is false, but because torpedoing trust in the project is
not the right course of action.

> If a concrete patch exists, the TC can (and has in the past) authorize an
> NMU to apply it.  Obviously, we should try to avoid reaching that level of
> social and process confrontation if we can avoid it, but this is clearly
> within the TC's constitutional power via a maintainer override, which puts
> the discussion on somewhat firmer ground.  But design of that patch is
> *not* within the TC's constitutional mandate.
> 
> It may be useful to look at how multiarch support in dpkg was handled.
> That was quite painful and I really hope we don't end up following that
> path exactly, but it provides a concrete example of how Debian's processes
> can reach a resolution.
> 
> I personally am still hopeful that we could do much better than the
> multiarch outcome and find a patch that meets the architectural criteria
> of the dpkg maintainer, but I'm fairly certain that we're not going to
> make any progress towards that goal without having working code, or at
> least a very detailed architecture, to start discussing and analyzing.

Completely agree here.

Bug#1006909: impressive: Fails to find any pages in the presentation

[Gunnar Wolf]

Yaroslav Halchenko dijo [Mon, Mar 21, 2022 at 09:08:34AM -0400]:
> > > Hmmm... But please do take note that I _did_ have mupdf-tools
> > > installed when Impressive failed to analyze the PDF
> > > document.
> 
> > Did you though? Impressive detected "Poppler/Xpdf" as the renderer,
> > which is an indicator of the absence of mupdf-tools. If you can confirm
> > that "mutool -v" works on your system (in the sense of: prints a version
> > number instead of a "command not found" message), I'd have some homework
> > to do though ;)
> 
> Dear Gunnar,
> 
> Could you please confirm that mupdf-tools were installed and
> functioning?  I know that sounds implausible given that it is a hard
> dependency but having no pdftk{,-java} installed I was able to use
> impressive just fine.

I am writing finally from the computer I regularly use for my classes
-- I did have mupdf, but *not* mupdf-tools. I can confirm impressive
works with my presentation (although the rendering looks a bit less
polished) after installing mupdf-tools.

Ugh -- and the ugly rendering remains even if I install pdftk-java
(that is, it seems that having both installed in the system,
impressive will default to mupdf-tools?); I got back my "nice"
rendering only after purging mupdf-tools.

So:

- with mupdf-tools 1.19.0+ds1-2 and pdftk-java 3.2.2-1:
  - Rendering is ugly
  - Impressive reports:
 
Welcome to Impressive version 0.13.0-beta2 (SVN r298)
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
PDF renderer: MuPDF 1.4 or newer
OpenGL renderer: FD630

- with mupdf-tools 1.19.0+ds1-2 and pdftk-java 3.2.2-1:
  - Rendering is nicer
  - Impressive reports:
Welcome to Impressive version 0.13.0-beta2 (SVN r298)
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
PDF renderer: Xpdf/Poppler
OpenGL renderer: FD630

- with mupdf-tools 1.19.0+ds1-2 and pdftk-java uninstalled:
  - Rendering is ugly
  - Impressive reports:
Welcome to Impressive version 0.13.0-beta2 (SVN r298)
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
PDF renderer: MuPDF 1.4 or newer
pdftkParse() FAILED
OpenGL renderer: FD630

- with both mupdf-tools and pdftk-java uninstalled:
  - No rendering
  - Impressive reports:
Welcome to Impressive version 0.13.0-beta2 (SVN r298)
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
PDF renderer: Xpdf/Poppler
pdftkParse() FAILED
WARNING: The input file 
`/home/gwolf/vcs/sistemas_operativos/laminas/08_algoritmos_planif_proc.pdf' 
could not be analyzed.
The presentation doesn't have any pages, quitting.

I think the result for having both installed should be to default for
the best renderer. If none are available, of course, impressive should
fail -- but the message it conveys is quite cryptic (it does not say
the renderer is not there; in fact, it points at xpdf/poppler. Why
does it fail?)

But more than impressive's message... if either pdftk-java or
mupdf-tools are required for impressive to be useful, they should be
declared as alternative dependencies (defaulting to... well, that's
your criteria ).

Thanks!

Bug#1006909: impressive: Fails to find any pages in the presentation

[Gunnar Wolf]

Martin Fiedler dijo [Tue, Mar 15, 2022 at 10:28:15PM +0100]:
> It's a little more complicated.
> 
> For *analyzing* the pages, Impressive requires mupdf-tools | pdftk-java.
> pdftk-java is slightly preferred, because it's required for extracting
> page titles. Basic page display and hyperlink navigation works with just
> mupdf-tools though.
> 
> For *rendering* the PDF to bitmaps, Impressive requires. mupdf-tools |
> poppler-utils, with a preference for mupdf-tools.
> 
> In other words, mupdf-tools alone gives you most of the functionality.
> pdftk is, in that sense, only used for a small, not mission-critical
> feature (title extraction) at this point.

Hmmm... But please do take note that I _did_ have mupdf-tools
installed when Impressive failed to analyze the PDF
document. mupdf-tools is already a hard dependency:

$ apt show impressive|egrep '^(Recom|Dep|Sug)'
Depends: python3, python3-pygame, python3-pil, mupdf-tools (>= 1.5) | 
poppler-utils
Recommends: mplayer, ffmpeg, perl, xdg-utils
Suggests: ghostscript, latex-beamer, pdftk

Greetings,

Bug#1007719: raspi-firmware: Performance regression under RPi4B

[Gunnar Wolf]

Package: raspi-firmware
Version: 1.20220120+ds-1
Severity: important
Tags: upstream

Hank Barta reported a performance regression under the Raspberry Pi
4B, after comparing Bullseye and Bookworm (Debian 11 and 12). I am
copying over to this bug report only part of the information; a
full(er) report is available in Hank's GitHub project
Pi-4B-bookworm-performance:

https://github.com/HankB/Pi-4B-bookworm-performance

The problem presented when running sysbench:

   /--- bullseye ↓
   | $ time sysbench --test=cpu --cpu-max-prime=2 run
   | (...)
   | CPU speed:
   | events per second:   584.72
   |
   | General statistics:
   | total time:  10.0006s
   | total number of events:  5850
   | Latency (ms):
   |   min:1.70
   |   avg:1.71
   |   max:2.99
   |   95th percentile:1.73
   |   sum: 9997.34
   |
   | Threads fairness:
   | events (avg/stddev):   5850./0.00
   | execution time (avg/stddev):   9.9973/0.00
   +--- bookworm ↓
   | # time sysbench --test=cpu --cpu-max-prime=2 run
   | (...)
   | CPU speed:
   |  events per second:   233.03
   | 
   | General statistics:
   | total time:  10.0038s
   | total number of events:  2333
   | 
   | Latency (ms):
   |  min:4.28
   |  avg:4.29
   |  max:4.34
   |  95th percentile:4.33
   |  sum:10001.67
   | 
   | Threads fairness:
   | events (avg/stddev):   2333./0.00
   | execution time (avg/stddev):   10.0017/0.00
   \---

Hank did a thorough saerch, and found out this issue happens after the
firmware update (raspi-firmware/testing 1.20220120+ds-1 arm64
[upgradable from: 1.20210805+ds-1]).

Further information is available on the debian-arm mailing list
thread:

https://lists.debian.org/debian-arm/2022/03/threads.html#3

I prompted Hank to report this issue to the Raspberrrypi Firmware
project in GitHub, which he did, but was outright dismissed:

https://github.com/raspberrypi/firmware/issues/1705

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

Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
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

-- 



signature.asc
Description: PGP signature

Bug#1006909: impressive: Fails to find any pages in the presentation

[Gunnar Wolf]

Package: impressive
Version: 0.13.0~beta2-2
Severity: important
Tags: patch

Whenever I try to open a PDF presentation with impressive, I get the
following error message:

Welcome to Impressive version 0.13.0-beta2 (SVN r298)
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
Detected screen size: 1920x1080 pixels
PDF renderer: Xpdf/Poppler
pdftkParse() FAILED
WARNING: The input file `/tmp/testfile.pdf' could not be analyzed.
The presentation doesn't have any pages, quitting.

Do note that I am running this on ARM64, and using Wayland.

And... Oh! This seems to be due to a missing dependency! I was
checking through the list of versions of depends/recommends/suggests
(am not running reportbug from the affected system), and turns out
that installing pdftk (or rather, pdftk-java, as pdftk is now just a
transitional package) fixes the issue. Just for completeness sake, the
PDF renderer is still marked to be Xpdf/Poppler, but now it reports
"OpenGL renderer: FD630" and... works! :-D

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64

Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
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 impressive depends on:
ii  poppler-utils   20.09.0-3.1
ii  python3 3.9.8-1
ii  python3-pil 9.0.1-1
pn  python3-pygame  1.9.6+dfsg-5

Versions of packages impressive recommends:
ii  ffmpeg 7:4.3.1-3+b2
ii  mplayer2:1.4+ds1-1+b1
ii  perl   5.34.0-3
ii  xdg-utils  1.1.3-4.1

Versions of packages impressive suggests:
ii  ghostscript   9.55.0~dfsg-3
pn  latex-beamer  
pn  pdftk 
diff --git a/debian/control b/debian/control
index 12a1a9d..981c495 100644
--- a/debian/control
+++ b/debian/control
@@ -28,13 +28,13 @@ Depends: python3,
  python3-pygame,
  python3-pil,
  mupdf-tools (>= 1.5) | poppler-utils,
+pdftk-java,
 Recommends: mplayer,
 ffmpeg,
 perl,
 xdg-utils
 Suggests: ghostscript,
   latex-beamer,
-  pdftk,
 Conflicts: keyjnote (<< 0.10.2r-0)
 Provides: keyjnote
 Replaces: keyjnote (<< 0.10.2r-0)

Bug#979067: getting pinta updated in Debian

[Gunnar Wolf]

Timotheus Pokorra dijo [Wed, Mar 02, 2022 at 10:35:36PM +0100]:
> Hello Mike,
> 
> I have some experience with Mono packaging in Fedora.
> I know of the dotnet SIG in Fedora. They made a massive effort, involving
> Microsoft employees, to get dotnet core built according to the Fedora rules
> (build from source, not using external files, etc).
> (...)
> It is really difficult to package dotnet packages, because of all the nuget
> dependancies. We have not figured that out for Fedora. Or did not have the
> volunteers yet to do that.
> 
> Alternatives to dotnet: Mono, dotgnu
> https://www.gnu.org/software/dotgnu/
> "As of December 2012, the DotGNU project has been decommissioned."
> 
> Mono: it is the alternative to .NET Framework, which Microsoft will support
> for many years to come. But the new stuff is happening in dotnet, so
> projects like Pinta are moving from Mono to dotnet.

Uff... .NET -- A reimplementation of the "write once, debug
everywhere" fiasco :-(

Bug#1004280: raspi-firmware: Autogenerated-file warning fixes and clarification for config.txt

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

tags 1004280 + confirmed, pending
thanks

Hello,

Thanks for your careful analysis and recommendations! I am applying
them to our working tree right now, and I expect to do a package
upload quite soon closing this bug report.
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQRgswk9lhCOXLlxQu/i9jtDU/RZiQUCYgVmbQAKCRDi9jtDU/RZ
iZlUAQDBUEIjAa/j6noNWEPAUGf7Jc8gxCKCwxOvdFLpNeStFQD/a09qRrC/gRF4
QAEvDuH+5xvDhC6dR67IsIcvG6bWmAs=
=Q1qj
-END PGP SIGNATURE-

Bug#1004611: Resignation & call for votes to elect the Chair

[Gunnar Wolf]

Sean Whitton dijo [Sun, Jan 30, 2022 at 02:10:08PM -0700]:
> ===BEGIN
> 
> A: Christoph Berg 
> B: Helmut Grohne 
> C: Elana Hashman 
> D: Simon McVittie 
> E: Niko Tyni 
> F: Matthew Vernon 
> G: Sean Whitton 
> H: Gunnar Wolf 
> 
> ===END

My vote is:

G > A = C = D = E = H > B = F


signature.asc
Description: PGP signature

Bug#1003738: tech-ctte: Call for votes on TC membership of Matthew Vernon

[Gunnar Wolf]

Sean Whitton dijo [Fri, Jan 14, 2022 at 11:56:20AM -0700]:
> Package: tech-ctte
> X-debbugs-cc: matt...@debian.org, lea...@debian.org
> 
> I call for votes on the following ballot to fill a vacant seat on the
> Debian Technical Committee.  The voting period starts immediately and
> lasts for up to one week, or until the outcome is no longer in doubt.
> 
> ===BEGIN
> The Technical Committee recommends that Matthew Vernon  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> H: Recommend to Appoint Matthew Vernon 
> F: Further Discussion
> ===END

I vote:

H  > F

Thanks,


signature.asc
Description: PGP signature

Bug#1003737: tech-ctte: Call for votes on TC membership of Helmut Grohne

[Gunnar Wolf]

Sean Whitton dijo [Fri, Jan 14, 2022 at 11:55:17AM -0700]:
> Package: tech-ctte
> X-debbugs-cc: hel...@subdivi.de, lea...@debian.org
> 
> I call for votes on the following ballot to fill a vacant seat on the
> Debian Technical Committee.  The voting period starts immediately and
> lasts for up to one week, or until the outcome is no longer in doubt.
> 
> ===BEGIN
> The Technical Committee recommends that Helmut Grohne  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> H: Recommend to Appoint Helmut Grohne 
> F: Further Discussion
> ===END

I vote:

H > F

Thanks!


signature.asc
Description: PGP signature

Bug#1001161: telegram-purple: The Telegram service seems to be about to perform a protocol update, please update package!

[Gunnar Wolf]

Package: telegram-purple
Version: 1.4.3-3
Severity: important
Tags: upstream

A couple of days ago, I started getting problems while trying to
connect from Bitlbee to my Telegram account:

telegram - Logging in: Logged in   
telegram - Error: RPC_CALL_FAIL 420: FLOOD_WAIT_333
telegram - Signing off..   
telegram - Reconnecting in 5 seconds.. 
telegram - Logging in: Logged in   
telegram - Error: RPC_CALL_FAIL 420: FLOOD_WAIT_333
telegram - Signing off..   
telegram - Reconnecting in 5 seconds.. 

Today I opened Telegram via the browser app, and was greeted by a
message saying:

Error

Hello Gunnar,

Please update Telegram to the latest version. The version you are
using is out of date and will stop working soon

Please check with upstream if a new version is available, and if so,
please push the update to Debian!

Thanks a lot,

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

Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads)
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 telegram-purple depends on:
ii  libc6 2.32-4
ii  libgcrypt20   1.9.4-4
ii  libglib2.0-0  2.70.1-1
ii  libpng16-16   1.6.37-3
ii  libpurple02.14.8-1
ii  libwebp6  0.6.1-2.1
ii  zlib1g1:1.2.11.dfsg-2

telegram-purple recommends no packages.

telegram-purple suggests no packages.

-- no debconf information

Bug#998722: cpufetch: Cannot detect CPU model, so it dies with a buffer overflow

[Gunnar Wolf]

Axel Beckert dijo [Sat, Nov 13, 2021 at 04:17:07PM +0100]:
> reform:~$ cpufetch
> *** buffer overflow detected ***: terminated
> Aborted (core dumped)
> 
> > Now, running cpufetch from the upstream repository (v1.00, commit
> > a5b321a) does not die and correctly prints the architecture
> > (screenshot attached),
> 
> Tagging as fixed-upstream then. :-)

Well, just thinking -- I am not sure it is fixed upstream (only that
it no longer happens in my hardware). If the result of being unable to
detect the CPU yields a core dump, I don't think it should be marked
as fixed-upstream.

...I am not removing your tag, though. I don't know how this was
implemented, _maybe_ it is fixed upstream.

Bug#999578: dmarc-cat: Please make it accept data via STDIN

[Gunnar Wolf]

Package: dmarc-cat
Version: 0.14.0-1+b5
Severity: wishlist
Tags: upstream

dmarc-cat insists AFAICT to work on existing files. I tried to get it
to process the reports I found attached to received mails; for this, I
would love to be able to ask my MTA to pipe the attachment to
dmarc-cat. However, I could not get it to work, either with the
convention of using '-' or even with capturing via <( ... )

So, please, could you add an option for dmarc-cat to work on reports
from STDIN?

Thanks!

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
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 dmarc-cat depends on:
ii  libc6   2.32-4
ii  libgpgme11  1.16.0-1.1

dmarc-cat recommends no packages.

dmarc-cat suggests no packages.

-- no debconf information

-- 

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files for wifi support in Raspberry p400

[Gunnar Wolf]

Package: firmware-brcm80211
Version: 20210818-1
Severity: normal
Tags: newcomer

The Raspberry Pi p400 is very similar to the 4 family, but the Wifi
chip is a slightly different model, and is thus not recognized when
running with Debian, not even with firmware-brcm80211.

We need the addition of three files, all three of them available in
RPi-Distro's firmware-nonfree repository in Github
(https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm/):

brcmfmac43456-sdio.bin
brcmfmac43456-sdio.clm_blob
brcmfmac43456-sdio.txt

Thank you very much!

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

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

Bug#998722: cpufetch: Cannot detect CPU model, so it dies with a buffer overflow

[Gunnar Wolf]

Package: cpufetch
Version: 0.98-1
Severity: important

When I run cpufetch from my Snapdragon 850 laptop (Lenovo Yoga C630),
I get:

$ cpufetch
*** buffer overflow detected ***: terminated
Aborted

Of course, I did not expect it to be aware of every detail on strange
architectures, but not being able to guess the architecture should not
lead to such a horrible death! 

Now, running cpufetch from the upstream repository (v1.00, commit
a5b321a) does not die and correctly prints the architecture
(screenshot attached), although the information guessed is wrong. So,
probably it's just a matter of updating upstream version (and
providing the right data for it to recognize the Snapdragon).

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

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

Bug#997893: RM: ruby-wirble -- ROM; No longer compatible with current versions of Ruby (incorporated)

[Gunnar Wolf]

Package: ftp.debian.org
Severity: normal

Last upstream version for Wirble is from 2009¹, and the last upload of
ruby-wirble to Deblan is from 2015. It was removed from Bullseye on
February 2021. The important parts of its functionality (coloring the
interactive Ruby console, irb) has been adopted in irb itself.

¹ https://rubygems.org/gems/wirble

We were originally two maintainers, Ryan Niebur and myself. Ryan is no
longer active in Debian (#856380), and clearly, I'm not active
maintaining this package, so I request its removal.

Thank you very much,

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

[Gunnar Wolf]

Thank you very much for starting this vote, Sean.

I vote A > B > F.

> > === Resolution A ===
> >
> > The Technical Committee resolves:
> >
> > 1. The debianutils package must continue to provide the which(1) program
> >until a compatible utility is available in a package that is at least
> >transitively essential in Debian 12.
> >
> >For the Debian 12 release, we expect which(1) to be in either an
> >Essential package or a transitively Essential package (that is, a
> >package that is depended on by an Essential package).
> >
> > 2. The which(1) program must not print any deprecation warnings.
> >
> > 3. We decline to overrule the maintainer of debianutils regarding the
> >use of alternatives.  If another package takes over responsibility
> >for which(1), then the debianutils maintainers and the other
> >package's maintainers should coordinate to choose a suitable
> >mechanism, which might be either versioned Depends/Breaks/Replaces,
> >dpkg-divert, alternatives or something else.
> >
> > 4. The debianutils package must continue to provide the tempfile(1)
> >program until a compatible utility is available in a package that is
> >at least transitively essential in Debian 12.
> >
> >For the Debian 12 release, we expect tempfile(1) to be in either an
> >Essential package or a transitively Essential package.
> >
> > 5. Programs in debianutils must not be moved to /usr until we have a
> >project-wide consensus on going ahead with such a move, and any
> >programs that have already been moved must be moved back.  In
> >particular, this means debianutils must contain /bin/run-parts and
> >/sbin/installkernel for the time being.
> >
> > === Resolution B ===
> >
> > As Resolution A, except strike point (2) and renumber succeeding items.
> >
> > === End Resolutions ===
> >
> > A: Issue Resolution A
> > B: Issue Resolution B
> > F: Further Discussion
> 
> I vote:
> 
> A > B > F



-- 



signature.asc
Description: PGP signature

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Gunnar Wolf]

Simon McVittie dijo [Wed, Oct 13, 2021 at 08:13:08PM +0100]:
> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

My vote on the text quoted below is:

yes > further discussion

>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between 

Bug#975023: vmdb2: qemu-debootstrap after virtual-filesystems fails,Re: vmdb2: qemu-debootstrap after virtual-filesystems fails

[Gunnar Wolf]

Hello Ryutaroh,

Ryutaroh Matsumoto dijo [Sun, Aug 22, 2021 at 01:02:57PM +0900]:
> Hi, Diederik
> 
> I redid vmdb run and again got errors as attached.
> qemu-user-static are from bullseye and sid.
> Both trial failed.

I uploaded vmdb2 0.24, which incorporates upstream commit bc42e2a,
which merges qemu-debootstrap into debootstrap. Could you check if the
issue persists?

Bug#992734: scripts/add-key: mktemp

[Gunnar Wolf]

tags 992734 + pending
thanks

Thank you very much for the patch, Clint!

I have added it to our working tree. Next time we upload a package,
the changelog will take care of closing this bug.

Bug#990976: unblock: raspi-firmware/1.20210303+ds-2

[Gunnar Wolf]

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

Please allow version 1.20210303+ds-2 of raspi-firmware into
testing. This is a minor version, adding a config option that avoids
setting the GPU_FREQ for a fixed GPU speed, which works around a bug
in the RPi4 family that changes the baud rate for the serial interface
rendering it useless. Some other much minor changes are included as
well.

As you will see when reviewing this bug, I should have filed this
request about two months ago. I completely forgot about it... shame on
me! Thanks to Adrian Bunk for reminding me.

The impact of not having this change accepted in Bullseye is not being
able to use a serial console on the current top of the line Raspberry
lineup.

I don't have automated tests in place for this package; as it's
basically a firmware blob needed to boot the system, the main test is
whether it boots and *seems* to work correctly (it does!) or not.

[ 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

unblock raspi-firmware/1.20210303+ds-2

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index c3c54ff..a2dee16 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+raspi-firmware (1.20210303+ds-2) unstable; urgency=medium
+
+  * Add a header to config.txt warning users it's an autogenerated file
+(Closes: #983896)
+  * Added config option GPU_FREQ to allow specifying a fixed GPU speed,
+needed for using the serial console in the RPi4 family
+  * ignore *.old-dkms when configuring a new kernel/initrd (Closes:
+#983409)
+  * Applied some shellcheck fixes to improve clarity. Thanks Diederik!
+
+ -- Gunnar Wolf   Wed, 21 Apr 2021 00:52:21 -0500
+
 raspi-firmware (1.20210303+ds-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/default/raspi-firmware b/debian/default/raspi-firmware
index e8e83bc..3e9d9cd 100644
--- a/debian/default/raspi-firmware
+++ b/debian/default/raspi-firmware
@@ -67,6 +67,25 @@
 #
 #CONSOLES="auto"
 
+# In the RPi4 and p400 families, the video processor (GPU) has several
+# possible operating frequencies, but is known to corrupt the serial
+# console (switch to an invalid baud rate), as the UART (the component
+# which drives the serial ports) gets its clock from the GPU, as
+# explained here:
+#
+# https://www.raspberrypi.org/documentation/configuration/uart.md
+#
+# The clock speeds the RPi4 GPU uses are 360/500/550 MHz. If you
+# intend to use the serial console, you need to set GPU_FREQ to
+# 360. If you intend to use this computer as a desktop system, set it
+# to "auto". Both 500 and 550 MHz also corrupt the serial console.
+#
+# Do note that earlier models have fixed frequencies, and this setting
+# will be ignored if your board does not identify as a RPi 4 (any
+# model) or p400.
+#
+#GPU_FREQ="auto"
+
 # Force the architecture to install the kernel as. You will most
 # likely want to leave this setting alone; the only use case I have
 # found for this is when you want to run a 32-bit userland on a
diff --git a/debian/kernel/postinst.d/z50-raspi-firmware 
b/debian/kernel/postinst.d/z50-raspi-firmware
index 09b882f..1cb1334 100755
--- a/debian/kernel/postinst.d/z50-raspi-firmware
+++ b/debian/kernel/postinst.d/z50-raspi-firmware
@@ -1,7 +1,7 @@
 #!/bin/sh
 # vim:ts=2:sw=2:et
 # see also:
-# https://kernel-handbook.alioth.debian.org/ch-update-hooks.html#s-kernel-hooks
+# 
https://kernel-team.pages.debian.net/kernel-handbook/ch-update-hooks.html#s-kernel-hooks
 
 set -e
 
@@ -31,13 +31,15 @@ fi
 # Ensure the target directory exists. See https://bugs.debian.org/887062
 mkdir -p /boot/firmware
 
-latest_kernel=$(ls -1 /boot/vmlinuz-* | grep -v '\.dpkg-bak$' | sort -V -r | 
head -1)
+# shellcheck disable=SC2010
+latest_kernel=$(ls -1 /boot/vmlinuz-* | grep -E -v '\.(dpkg-bak|old-dkms)$' | 
sort -V -r | head -1)
 if [ -z "$latest_kernel" ]; then
   echo "raspi-firmware: no kernel found in /boot/vmlinuz-*, cannot populate 
/boot/firmware"
   exit 0
 fi
 
-latest_initrd=$(ls -1 /boot/initrd.img-* | grep -v '\.dpkg-bak$' | sort -V -r 
| head -1)
+# shellcheck disable=SC2010
+latest_initrd=$(ls -1 /boot/initrd.img-* | grep -E -v '\.(dpkg-bak|old-dkms)$' 
| sort -V -r | head -1)
 if [ -z "$latest_initrd" ]; then
   echo "raspi-firmware: no initrd found in /boot/initrd.img-*, cannot populate 
/boot/firmware"
   exit 0
@@ -76,7 +78,7 @@ else
 fi
 
 if [ "$KERNEL" =

Bug#990010: ITP: mymake -- A tool for compiling C/C++ programs

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 
X-Debbugs-Cc: debian-de...@lists.debian.org, Filip Strömbäck 

* Package name: mymake
  Version : 2.2.0
  Upstream Author : Filip Strömbäck 
* URL : https://github.com/fstromback/mymake/
* License : MIT
  Programming Lang: C++
  Description : A tool for compiling C/C++ programs with minimal 
configuration

I am proposing this package as it is a build dependency for Storm /
Progvis.

Bug#990009: ITP: progvis -- Program visualization tool for C/C++ (and others)

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 
X-Debbugs-Cc: debian-de...@lists.debian.org, Filip Strömbäck 

* Package name: progvis
  Version : 0.5.7
  Upstream Author :  Filip Strömbäck 
* URL : 
https://storm-lang.org/index.php?q=06-Programs%2F01-Progvis.md
* License : LGPL-2.1
  Programming Lang: C++
  Description : Program visualization tool for C/C++ (and others)

 A program visualization tool (written in Storm). Supports a subset of
 C/C++, and other languages supported by Storm. Aimed at showing how
 concurrent programs interact with pointers/references and other
 fundamental programming concepts.

<>

Progvis is an educational tool based on the Storm multi-language
toolbox that helps students visualize memory allocation, thread
interaction, synchronization, and several other things.

Progvis is built from the same sources as Storm (so, of course, this
packaging will include several bits of the Storm ecosystem). I will
also upload Filip's build system, called "mymake".

Bug#983409: raspi-firmware: /etc/kernel/postinst.d/z50-raspi-firmware fails to ignore old-dkms initrds

[Gunnar Wolf]

Control: tags -1 - patch
Control: tags -1 + pending

Hi,

While your patch would work for arm64 (RPi 3 and 4 families), it would
not work for armel (RPi 0/1) or armhf (RPi 2). The suffix of the
kernel version denotes the machine type, not just the architecture;
our working armel kernel is -rpi, and our working armhf kernel is
-armmp.

We could set those suffixes based on the output of "dpkg
--print-architecture", but I fear that would also end up in unbootable
systems for some people who built their own kernels or so.

I will go the other route, and -same as I'm doing grep -v \.dpkg-bak$-
will exclude the known suffix you report for DKMS kernels. I hope that
solves the issue!

Bug#987685: closed by Sebastian Ramacher (unblock raspi-firmware)

[Gunnar Wolf]

Debian Bug Tracking System dijo [Tue, Apr 27, 2021 at 06:45:03PM +]:
> #987685: unblock: raspi-firmware/1.20210303+ds-1
> 
> It has been closed by Sebastian Ramacher .

That was fast. Thanks!

Bug#987685: unblock: raspi-firmware/1.20210303+ds-1

[Gunnar Wolf]

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

Please unblock package raspi-firmware

Upstream release for the Raspberry Pi non-free firmware, needed for
booting their systems with Linux

[ Reason ]

We would like to release Bullseye with the latest firmware, as it
often contains bugfixes. The contents of the firmware are opaque to
us.

[ Impact ]

No ill effects would stem from not approving this; we did upload
before the current freeze came into effect, but are applying only now
because I waited for the needed 20 days.

[ Tests ]

I have built and tested images with this firmware for all of the
Raspberry lineup (0W, 1 using armel; 2 using armhf; 3, 4 and p400
using arm64).

[ Risks ]

There is the always latent risk when using non-free software that this
change might break something. That is true, of course, also of the
currently present version. Version 2.20210303 has been used by
thousands of users, and no updates have been posted in close to two
months by the Raspberry foundation.

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

[ Other info ]

Please note that raspi-firmware is in *non-free*.

Not attaching debdiff as it is not relevant (i.e. the only nonbinary
change is in debian/changelog)

I have some pending changes in the Debian packaging side I will upload
(and apply for an unblock request, if we make it in time for Bullseye.

unblock raspi-firmware/1.20210303+ds-1

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

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

Bug#983896: raspi-firmware: please link /boot/firmware/*.txt to /etc/raspi-firmware/*.txt

[Gunnar Wolf]

Control: tags -1 confirmed
Control: tags -1 pending
Control: version -1 1.20210111+ds-2

Hi Holger!

I don't want to link or copy said files over to /etc, as they would
break expectations for conffiles (i.e. they will be overwritten on
upgrade). But I am adding a warning banner to cmdline.txt warning
about this, and advising the user on how to properly modify it:


https://salsa.debian.org/debian/raspi-firmware/-/commit/7e4ce0f8c0038162ccd6474e13ef5bb954851a2d

I will close this bug by the next package upload. I hope this solution
satisfies you!


signature.asc
Description: PGP signature

Bug#986863: linux: Serial terminal for RPi 4 and p400 corrupted during bootup

[Gunnar Wolf]

Control: Severity -1 normal

Ben Hutchings dijo [Fri, Apr 16, 2021 at 03:07:48PM +0200]:
> > During the boot process of the Raspberry Pi models 4 (4 and 8GB) and
> > p400, the console starts working correctly, but as the vc4 video gets
> > initialized, the console gets corrupted.
> [...]
> 
> This is a known problem with the RPi 3/4 hardware:
> 
> "In order to use the mini UART, you need to configure the Raspberry Pi
> to use a fixed VPU core clock frequency. This is because the mini UART
> clock is linked to the VPU core clock, so that when the core clock
> frequency changes, the UART baud rate will also change."
> 
> (from
> ).

Ugh, great... FSVO.

I can confirm both force_turbo=1 and core_freq=250 worked for keeping
the serial port functioning after vc4 is loaded, but am still unsure
which should be enabled by default for our RPi4 users (I'd set it in
the raspi-firmware package).

In any case, I'm downgrading this bug to Normal, as it has a known
workaround, but if you don't disagree, I'd still regard to it as an
existing, open bug.

Thanks!


signature.asc
Description: PGP signature

Bug#986863: linux: Serial terminal for RPi 4 and p400 corrupted during bootup

[Gunnar Wolf]

Control: notfound -1 5.9.15-1
Control: found -1 5.10.4-1

Marking two adjacent kernel versions where the breakage first appeared.

Bug#986863: linux: Serial terminal for RPi 4 and p400 corrupted during bootup

[Gunnar Wolf]

found 986863 5.10.0-6-arm64
notfound 986863 5.8.0-3-arm64
thanks

I blacklisted the vc4 module, and the console works reliably again, so
that's a way to get a working system. I will blacklist in the images I
produce, but this should not be needed for users to know!

I am also trying with a kernel from the 5.8 series, as noted in the
pseudo-headers to the BTS. The bug does not happen under kernel
5.8.0-3. I will try to more precisely pinpoint the place where it
stopped working.

Just to have as much information together -- If I boot without loading
the vc4 module, then load it via modprobe, I get the following
messages:

root@rpi4-20210226:~# modprobe vc4
[   71.824867] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' 
already present!
[   71.835045] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[   71.869840] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' 
already present!
[   71.879230] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[   71.899628] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])
[   71.906197] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[   71.912815] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[   71.920100] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[   71.927301] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[   71.934495] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[   71.941850] fb0: switching to vc4drmfb from simple
[   71.947094] Console: switching to colour dummy device 80x25
[   71.974285] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[   72.035497] Console: switching to colour frame buffer device 160x45
[   72.041942] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
root@rpi4-20210226:~# 

After which, the console becomes unoperative.

I tested this in the p400 as well, the behavior us the same.


signature.asc
Description: PGP signature

Bug#985336: diaspora-installer-mysql: missing dependency on tzdata

[Gunnar Wolf]

tags 985336 + pending
thanks

I have uploaded a fixed package as a NMU to the 7-day-delayed queue,
and submitted MR #4 in Salsa.



signature.asc
Description: PGP signature

Bug#986585: bluez-firmware: Please remove severely outdated README.Debian

[Gunnar Wolf]

Package: bluez-firmware
Version: 1.2-4
Severity: wishlist

File debian/README.Debian is relevant for details of kernel versions
2.4.x and 2.6.x. They are long obsolete! I suggest removing the file
to avoid user frustration interested in finding something relevant.

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

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

Bug#980536: raspi-firmware: CMA=64M too small for 4K display and vc4.ko in 5.10 kernel

[Gunnar Wolf]

tags -1 wontfix
severity -1 wishlist
thanks

Hi,

There are Raspberries in use with memory ranging from 256M (512M
currently for sale) to 8G. I do not want to ship a package that's
unusable in all of the 0 and 1 families.

As you mention in your bug report, it's easy to do this fix in
/etc/default/raspi-firmware -- that's the reason for it to exist!

Please note /etc/default/raspi-firmware discourages setting a CMA in
the RPi4 family. I don't have the needed hardware (i.e. 4K monitor) to
test this, but I do remember having unbootable RPi4 when I had CMA
set.

I'm tagging this bug as "wontfix", at least for the time being. I
think it's best for all users to be able to boot (and then tweak as
you did) than to make it more difficult for some users to get to basic
system functionality.

Bug#985375: vmdb2: add option to 'apt' step for not installing recommends

[Gunnar Wolf]

tags -1 + pending,patch
thanks

I have submitted a merge request to the upstream author. I have _not_
yet tested this -- So, Andres, if you can try my proposed patch,
everybody will be happier ;-)

https://gitlab.com/larswirzenius/vmdb2/-/merge_requests/73/diffs

diff --git a/vmdb/plugins/apt.mdwn b/vmdb/plugins/apt.mdwn
index a05922a..e66454c 100644
--- a/vmdb/plugins/apt.mdwn
+++ b/vmdb/plugins/apt.mdwn
@@ -12,6 +12,10 @@ Step keys:
 
 * `packages`  REQUIRED; value is a list of packages to install.
 
+* `recommends`  OPTIONAL; defaults to true. Setting value to a
+  false (i.e. `0`, `null`, `false`) asks apt-get to run with the
+  `--no-install-recommends` option set.
+
 Example (in the .vmdb file):
 
 - apt: install
diff --git a/vmdb/plugins/apt_plugin.py b/vmdb/plugins/apt_plugin.py
index 09b8902..5f11855 100644
--- a/vmdb/plugins/apt_plugin.py
+++ b/vmdb/plugins/apt_plugin.py
@@ -28,7 +28,7 @@ class AptPlugin(vmdb.Plugin):
 
 class AptStepRunner(vmdb.StepRunnerInterface):
 def get_key_spec(self):
-return {"apt": str, "packages": [], "tag": "", "fs-tag": "", "clean": 
True}
+return {"apt": str, "packages": [], "tag": "", "fs-tag": "", "clean": 
True, "recommends": True}
 
 def run(self, values, settings, state):
 operation = values["apt"]
@@ -36,15 +36,16 @@ class AptStepRunner(vmdb.StepRunnerInterface):
 raise Exception('"apt" must always have value "install"')
 
 packages = values["packages"]
+recommends = values["recommends"]
 tag = values.get("tag") or None
 if tag is None:
 tag = values["fs-tag"]
 mount_point = state.tags.get_builder_mount_point(tag)
 
 if not self.got_eatmydata(state):
-self.install_packages(mount_point, [], ["eatmydata"])
+self.install_packages(mount_point, [], recommends, ["eatmydata"])
 state.got_eatmydata = True
-self.install_packages(mount_point, ["eatmydata"], packages)
+self.install_packages(mount_point, ["eatmydata"], recommends, packages)
 
 if values["clean"]:
 self.clean_cache(mount_point)
@@ -52,15 +53,19 @@ class AptStepRunner(vmdb.StepRunnerInterface):
 def got_eatmydata(self, state):
 return hasattr(state, "got_eatmydata") and getattr(state, 
"got_eatmydata")
 
-def install_packages(self, mount_point, argv_prefix, packages):
+def install_packages(self, mount_point, argv_prefix, recommends, packages):
 env = os.environ.copy()
 env["DEBIAN_FRONTEND"] = "noninteractive"
 
 vmdb.runcmd_chroot(mount_point, argv_prefix + ["apt-get", "update"], 
env=env)
 
+rec = ''
+if recommends:
+rec = '--no-install-recommends'
+
 vmdb.runcmd_chroot(
 mount_point,
-argv_prefix + ["apt-get", "-y", "--no-show-progress", "install"] + 
packages,
+argv_prefix + ["apt-get", "-y", "--no-show-progress", rec, 
"install"] + packages,
 env=env,
 )
 

Bug#985270: Resignation + Call for votes for new Chair

[Gunnar Wolf]

Margarita Manterola dijo [Mon, Mar 15, 2021 at 10:30:59AM +0100]:
> The ballot is the following:
> 
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
>  A : Margarita Manterola
>  B : David Bremner
>  C : Niko Tyni
>  D : Gunnar Wolf
>  E : Simon McVittie
>  F : Sean Whitton
>  G : Elana Hashman
>  H : Christoph Berg
> 
> ===END===

My vote is:

A = B = C = E = F = G > D > H

Thanks!


signature.asc
Description: PGP signature

Bug#983610: zint: CVE-2021-27799

[Gunnar Wolf]

tags -1 + patch,pending
user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-03-latinoamerica
thank you

Hi,

I have prepared this patch and will be performing an upload targetted
at delayed/7-day.

Dmitry, please do take a look at my proposed patch. I backported the
commit I'm quoting in it, which applied quite imperfectly; I am
basically sure the code I applied is correct (but extra eyes will
never hurt!), but I left out the patch for
backend/tests/test_upcean.c, as the version we are shipping is very
much behind (the patched functions don't even exist).

Greetings,
Last-Update: 2021-03-11
Origin: https://sourceforge.net/p/zint/code/ci/7f8c8114f31c09a986597e0ba63a49f96150368a/
Forwarded: not-needed
Author: Gunnar Wolf 
Description: Fix a buffer overflow in ean_laeding_zeroes
 This vulnerability is tracked as CVE-2021-27799. The patch was backported
 from the devel git tree.

Index: zint-2.9.1/backend/composite.c
===
--- zint-2.9.1.orig/backend/composite.c
+++ zint-2.9.1/backend/composite.c
@@ -65,7 +65,7 @@
 
 INTERNAL int eanx(struct zint_symbol *symbol, unsigned char source[], int length);
 INTERNAL int ean_128(struct zint_symbol *symbol, unsigned char source[], const size_t length);
-INTERNAL void ean_leading_zeroes(struct zint_symbol *symbol, unsigned char source[], unsigned char local_source[]);
+INTERNAL int ean_leading_zeroes(struct zint_symbol *symbol, unsigned char source[], unsigned char local_source[]);
 INTERNAL int rss14(struct zint_symbol *symbol, unsigned char source[], int length);
 INTERNAL int rsslimited(struct zint_symbol *symbol, unsigned char source[], int length);
 INTERNAL int rssexpanded(struct zint_symbol *symbol, unsigned char source[], int length);
@@ -1422,7 +1422,10 @@ INTERNAL int composite(struct zint_symbo
 int padded_pri_len;
 char padded_pri[20];
 padded_pri[0] = '\0';
-ean_leading_zeroes(symbol, (unsigned char *) symbol->primary, (unsigned char *) padded_pri);
+if (!ean_leading_zeroes(symbol, (unsigned char *) symbol->primary, (unsigned char *) padded_pri)) {
+		strcpy(symbol->errtxt, "448: Input wrong length in linear component");
+		return ZINT_ERROR_TOO_LONG;
+		}
 padded_pri_len = strlen(padded_pri);
 if (padded_pri_len <= 7) { /* EAN-8 */
 cc_width = 3;
Index: zint-2.9.1/backend/upcean.c
===
--- zint-2.9.1.orig/backend/upcean.c
+++ zint-2.9.1/backend/upcean.c
@@ -125,7 +125,7 @@ static void upca_draw(char source[], cha
 /* Make a UPC A barcode when we haven't been given the check digit */
 static int upca(struct zint_symbol *symbol, unsigned char source[], char dest[]) {
 int length;
-char gtin[15];
+char gtin[13];
 
 strcpy(gtin, (char*) source);
 length = strlen(gtin);
@@ -391,7 +391,7 @@ static char ean_check(char source[]) {
 static int ean13(struct zint_symbol *symbol, unsigned char source[], char dest[]) {
 unsigned int length, i, half_way;
 char parity[6];
-char gtin[15];
+char gtin[14];
 
 strcpy(parity, "");
 strcpy(gtin, (char*) source);
@@ -569,8 +569,9 @@ static int isbn(struct zint_symbol *symb
 }
 
 /* Add leading zeroes to EAN and UPC strings */
-INTERNAL void ean_leading_zeroes(struct zint_symbol *symbol, unsigned char source[], unsigned char local_source[]) {
-unsigned char first_part[20], second_part[20], zfirst_part[20], zsecond_part[20];
+INTERNAL int ean_leading_zeroes(struct zint_symbol *symbol, unsigned char source[],
+	unsigned char local_source[], int *p_with_addon) {
+unsigned char first_part[14], second_part[6], zfirst_part[14], zsecond_part[6];
 int with_addon = 0;
 int first_len = 0, second_len = 0, zfirst_len = 0, zsecond_len = 0, i, h;
 
@@ -592,15 +593,16 @@ INTERNAL void ean_leading_zeroes(struct
 ustrcpy(zfirst_part, (unsigned char *) "");
 ustrcpy(zsecond_part, (unsigned char *) "");
 
+if (first_len > 13 || second_len > 5) {
+return 0;
+}
+
 /* Split input into two strings */
 for (i = 0; i < first_len; i++) {
 first_part[i] = source[i];
 first_part[i + 1] = '\0';
 }
 
-if (second_len >= 6) { /* Allow 6 (actual max 5) so as to trigger too long error */
-second_len = 6;
-}
 for (i = 0; i < second_len; i++) {
 second_part[i] = source[i + first_len + 1];
 second_part[i + 1] = '\0';
@@ -698,12 +700,13 @@ INTERNAL void ean_leading_zeroes(struct
 strcat((char*) local_source, "+");
 strcat((char*) local_source, (char*) zsecond_part);
 }
+
+return 1; /* Success */
 }
 
-/* splits string to parts before and after '+' parts */
 INTERNAL int eanx(struct zint_symbol *symbol, unsigned char source[], int src_len) {
-

Bug#829398: xcfa: Buffer overflow with more than 45 tracks

[Gunnar Wolf]

tags -1 + patch
user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-03-latinoamerica
kthxbye

So, a trivial workaround for this issue would be to increase the
amount of entries in the allocation table:


diff --git a/src/file_lc.c b/src/file_lc.c
index 4d9ce0c..ef774ee 100644
--- a/src/file_lc.c
+++ b/src/file_lc.c
@@ -57,7 +57,7 @@
 // 
 gchar **filelc_AllocTabArgs( void )
 {
-   gchar   **PtrTab = (gchar **)g_malloc0( sizeof(gchar **) * 50 );
+   gchar   **PtrTab = (gchar **)g_malloc0( sizeof(gchar **) * 110 );
 
PtrTab [ 0 ] = g_strdup( "nice" );
PtrTab [ 1 ] = g_strdup( "-n" );


I chose 110 in order to leave space for the relevant logs mentioned by
the bug submitter. While this is not a definitive answer and does not
make the buffer overflow go away, this would allow all
standards-compliant CDDA disks to be produced -- A CD can contain up
to 99 tracks¹, so this would allow for creating all valid CDs.

Of course, this trivial patch does not take away the overflow
potential (and that should definitively be addressed!), and does not
yet properly communicate to users they requested the creation of
something that would break the standards. But it would be a first,
trivial step to fix this (old!) bug allowing for the creation of valid
images.

¹ https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio#Tracks
  The official standard is not freely available.

Bug#969938: debirf: bullseye: switch from /updates to -security

[Gunnar Wolf]

user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-03-latinoamerica
tags -1 + pending,patch
thank you

I have included the following patch and pushed to the Git repository
(but not made an upload):

diff --git a/debian/changelog b/debian/changelog
index 25f22f6..9872f94 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,11 @@
 debirf (0.39) UNRELEASED; urgency=medium
 
+  [ Ondřej Nový ]
   * d/copyright: Use https protocol in Format field
 
+  [ Gunnar Wolf ]
+  * switch from /updates to -security (Closes: #969938)
+
  -- Ondřej Nový   Mon, 01 Oct 2018 10:36:19 +0200
 
 debirf (0.38) unstable; urgency=medium
diff --git a/src/modules/a0_add_security_repos 
b/src/modules/a0_add_security_repos
index a4ab2be..7c0341d 100755
--- a/src/modules/a0_add_security_repos
+++ b/src/modules/a0_add_security_repos
@@ -22,7 +22,7 @@ case "${DEBIRF_DISTRO}" in
 ;;
 *)
 cat < 
"${DEBIRF_ROOT}/etc/apt/sources.list.d/security_repos.list"
-deb http://security.debian.org/ ${DEBIRF_SUITE}/updates main contrib non-free
+deb http://security.debian.org/ ${DEBIRF_SUITE}-security main contrib non-free
 EOF
 ;;
 esac



This package has currently three RC bugs. I'll see if I can make
progress on any other of them, and if so, will upload to a delayed
queue (otherwise, I'm just tagging as patch+pending).


signature.asc
Description: PGP signature

Bug#904627: (no subject)

[Gunnar Wolf]

user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-03-latinoamerica
thank you

Bug#984941: RM: cons -- RoQA; Unusable due to obsolete dependency

[Gunnar Wolf]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 904...@bugs.debian.org, hst...@debian.org

Hello,

Looking for RC bugs to tackle for BSP/2021/03/LatinAmerica, I came
across #904627 filed on package "cons".

After quickly analyzing the situation, I am requesting the removal of
cons from the archive. My reasoning is:

1. cons' last upload was in 2016, and the prior one was in 2006
2. cons has no reverse dependencies in the archive
3. It was not part of buster, and most probably won't make it to
   bullseye
4. RC bug #904627 dates back to 2018, and has had no interaction
5. The package's popcon is very low (12). It had a peak nearing 100
   back in 2008, but has a steady downward tendence since ~2013.

Thank you very much,

Bug#956083: autopostgresqlbackup: Fails to detect when DB dumps fail, and saves useless backups

[Gunnar Wolf]

user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-03-latinoamerica
thank you