Bug#967284: [Pkg-pascal-devel] Bug#967284: castle-game-engine: depends on deprecated GTK 2

[Peter B]

On 27/09/2023 10:45, Bastian Germann wrote:

On Sun, 9 Aug 2020 23:01:12 +0200 Michalis Kamburelis wrote:

Upgrade to GTK3 is planned.


Would it be possible to build with qt5 instead? From a Debian packaging 
perspective,
this should already work as opposed to gtk3.



Hi Bastian,

That would maybe have possible if castle-game-engine was built with Lazarus,
but it is built with Gtk2 via fp-units-gtk2.

Michalis is the expert here, but FWIW, my guess is no.


Regards,
Peter

Bug#1052678: xsane core dumps in Trixie when changing settings

[B Rhodes]

Package: xsane
Version: 0.999-12+b1
Severity: important
X-Debbugs-Cc: borde...@tutanota.com

Dear Maintainer,

* What led up to the situation?
Since updating to Trixie using the interface (most predictably changing the
scanning page size in Standard Options) causes a crash. The best debugging
information I can find is from journald:


xsane: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
xsane: IA__gtk_widget_get_toplevel: assertion 'GTK_IS_WIDGET (widget)' failed
xsane: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
xsane: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
xsane: IA__gtk_widget_get_toplevel: assertion 'GTK_IS_WIDGET (widget)' failed
xsane: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
kernel: xsane: segfault at b1 ip 7f3d33eba70e sp 7fffefe68930 error 4
in libgtk-x11-2.0.so.0.2400.33[7f3d33e64000+275000] likely on CPU 2 (core 1,
socket 0)
kernel: Code: 0f 1f 84 00 00 00 00 00 0f 1f 40 00 41 54 55 48 83 ec 08 48 85 ff
0f 84 90 00 00 00 48 89 fd 49 89 f4 e8 f5 d2 ff ff 48 89 c6 <48> 8b 45 00 48 85
c0 74 05 48 39 30 74 0c 48 89 ef e8 ac dd fa ff
systemd: Started systemd-coredump@9-34505-0.service - Process Core Dump (PID
34505/UID 0).
systemd: Started drkonqi-coredump-processor@9-34505-0.service - Pass systemd-
coredump journal entries to relevant user for potential DrKonqi handling.
systemd-coredump: Process 34468 (xsane) of user 1000 dumped core.

   Module libsystemd.so.0 from
deb systemd-254.1-3.amd64
   Module libudev.so.1 from deb
systemd-254.1-3.amd64
   Module libzstd.so.1 from deb
libzstd-1.5.5+dfsg2-2.amd64
   Stack trace of thread 34468:
   #0  0x7f3d33eba70e
gtk_container_set_focus_child (libgtk-x11-2.0.so.0 + 0xba70e)
   #1  0x7f3d3405af2a n/a
(libgtk-x11-2.0.so.0 + 0x25af2a)
   #2  0x7f3d33ec0cb3 n/a
(libgtk-x11-2.0.so.0 + 0xc0cb3)
   #3  0x7f3d342b2540
g_closure_invoke (libgobject-2.0.so.0 + 0x16540)
   #4  0x7f3d342c6188 n/a
(libgobject-2.0.so.0 + 0x2a188)
   #5  0x7f3d342c7501 n/a
(libgobject-2.0.so.0 + 0x2b501)
   #6  0x7f3d342cd186
g_signal_emit_valist (libgobject-2.0.so.0 + 0x31186)
   #7  0x7f3d342cd243
g_signal_emit (libgobject-2.0.so.0 + 0x31243)
   #8  0x7f3d3405a15a
gtk_widget_grab_focus (libgtk-x11-2.0.so.0 + 0x25a15a)
   #9  0x7f3d3405b09c n/a
(libgtk-x11-2.0.so.0 + 0x25b09c)
   #10 0x7f3d33f3926b n/a
(libgtk-x11-2.0.so.0 + 0x13926b)
   #11 0x7f3d342b24a5
g_closure_invoke (libgobject-2.0.so.0 + 0x164a5)
   #12 0x7f3d342c6188 n/a
(libgobject-2.0.so.0 + 0x2a188)
   #13 0x7f3d342c6d51 n/a
(libgobject-2.0.so.0 + 0x2ad51)
   #14 0x7f3d342cd186
g_signal_emit_valist (libgobject-2.0.so.0 + 0x31186)
   #15 0x7f3d342cd243
g_signal_emit (libgobject-2.0.so.0 + 0x31243)
   #16 0x7f3d3405aa04
gtk_widget_child_focus (libgtk-x11-2.0.so.0 + 0x25aa04)
   #17 0x7f3d33ebb11a n/a
(libgtk-x11-2.0.so.0 + 0xbb11a)
   #18 0x7f3d33f3926b n/a
(libgtk-x11-2.0.so.0 + 0x13926b)
   #19 0x7f3d342b24a5
g_closure_invoke (libgobject-2.0.so.0 + 0x164a5)
   #20 0x7f3d342c6188 n/a
(libgobject-2.0.so.0 + 0x2a188)
   #21 0x7f3d342c6d51 n/a
(libgobject-2.0.so.0 + 0x2ad51)
   #22 0x7f3d342cd186
g_signal_emit_valist (libgobject-2.0.so.0 + 0x31186)
   #23 0x7f3d342cd243
g_signal_emit (libgobject-2.0.so.0 + 0x31243)
   #24 0x7f3d3405aa04
gtk_widget_child_focus (libgtk-x11-2.0.so.0 + 0x25aa04)
   #25 0x7f3d33ebb11a n/a
(libgtk-x11-2.0.so.0 + 0xbb11a)
   #26 0x7f3d33f3926b n/a
(libgtk-x11-2.0.so.0 + 0x13926b)

Bug#1052537: draft patch

[Andreas B. Mundt]

Control: tags -1 patch
thanks!

Hi,

the attached draft (non-java-programmer) patch implements
the feature per user based.

Best regards,

  Andi
>From ed0ec33096a94b183f235e0c3da3426faea9203d Mon Sep 17 00:00:00 2001
From: "Andreas B. Mundt" 
Date: Sun, 24 Sep 2023 18:36:57 +0200
Subject: [PATCH] Add 'ignore and remember' button and skip check eventually.

---
 .../fixes/Enhance-permission-handling.patch   |  2 +-
 debian/permission-checker/arduinopc.java  | 26 ---
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/debian/patches/fixes/Enhance-permission-handling.patch b/debian/patches/fixes/Enhance-permission-handling.patch
index 59aef01..0e57548 100644
--- a/debian/patches/fixes/Enhance-permission-handling.patch
+++ b/debian/patches/fixes/Enhance-permission-handling.patch
@@ -17,7 +17,7 @@ index f70c650..e31ab34 100755
 -APPDIR="$(dirname -- "$(readlink -f -- "${0}")" )"
 +APPDIR=/usr/share/arduino
 +
-+if [[ `id -u` -ne 0 ]]; then
++if [[ `id -u` -ne 0 ]] && [[ ! -e ~/.arduino15/ignore-dialout-group ]] ; then
 +#for group in dialout tty; do
 +for group in dialout; do
 +if ! groups | grep -q "\b$group\b"; then
diff --git a/debian/permission-checker/arduinopc.java b/debian/permission-checker/arduinopc.java
index ad891c3..d50583a 100644
--- a/debian/permission-checker/arduinopc.java
+++ b/debian/permission-checker/arduinopc.java
@@ -29,6 +29,8 @@ import javax.swing.JPanel;
 import javax.swing.JLabel;
 import javax.swing.SwingUtilities;
 
+import java.io.File;
+import java.io.IOException;
 
 public class arduinopc extends JFrame {
 
@@ -43,7 +45,7 @@ public class arduinopc extends JFrame {
 
 //   panel.setLayout(null);
 
-   JButton ignoreButton = new JButton("Ignore");
+   JButton ignoreButton = new JButton("Ignore (for now)");
//ignoreButton.setBounds(50, 60, 80, 30);
ignoreButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent event) {
@@ -51,6 +53,23 @@ public class arduinopc extends JFrame {
   }
});
 
+   JButton ignoreRememberButton = new JButton("Ignore (remember)");
+   ignoreRememberButton.addActionListener(new ActionListener() {
+   public void actionPerformed(ActionEvent event) {
+   String stampFilePath = System.getProperty("user.home") +
+   "/.arduino15/ignore-dialout-group";
+   try {
+   File stamp = new File(stampFilePath);
+   stamp.createNewFile();
+   System.out.printf("Created '%s'.\n", stampFilePath);
+   } catch(IOException e) {
+   System.out.printf("Creating '%s' failed.\n", stampFilePath);
+   e.printStackTrace();
+   }
+   System.exit(0);
+   }
+   });
+
JButton addButton = new JButton("Add");
//addButton.setBounds(150, 60, 80, 30);
addButton.addActionListener(new ActionListener() {
@@ -61,7 +80,7 @@ public class arduinopc extends JFrame {
 
 //JLabel label = new JLabel("You need to be a member of the \"dailout\"group to upload code to an Arduinomicrocontroller over the USB orserial ports.");
 	//label.setBounds(10,10,300,100);
-panel.add(new JLabel("You need to be added to the \"dialout\"group to upload code to an Arduinomicrocontroller over the USB orserial ports.Click \"Add\" below to be added.You must log out and log in againbefore any group changeswill take effect.", JLabel.CENTER));
+panel.add(new JLabel("You need to be added to the \"dialout\" group to upload codeto an Arduino microcontroller over the USB or serial ports.Click \"Add\" below to be added. You must log out and log inagain before any group changes will take effect.If access is provided by other means, click \"Ignore\".", JLabel.CENTER));
 //label.setFont(new Font("Georgia", Font.PLAIN, 14));
//label.setForeground(new Color(50, 50, 25));
 //label.setOpaque(true);
@@ -69,12 +88,13 @@ public class arduinopc extends JFrame {
 
//panel.add(label);//, BorderLayout.CENTER);
panel.add(ignoreButton);
+   panel.add(ignoreRememberButton);
panel.add(addButton);
 
 
 
setTitle("Arduino Permission Checker");
-   setSize(300, 250);
+   setSize(380, 220);
setLocationRelativeTo(null);
setDefaultCloseOperation(EXIT_ON_CLOSE);
 }
-- 
2.30.2

Bug#587553: Any progress packaging?

[Andreas B. Mundt]

Hi Tassia,

thanks for your reply!

On Tue, Sep 19, 2023 at 06:00:09PM +, Tassia Camoes Araujo wrote:
> On 2023-09-13 15:04, Andreas B. Mundt wrote:
> > 
[…]
> 
> I can try to reboot my effort, but I would probably be starting from
> zero again, so if you are willing to package it, that's totally fine
> with me!

As I am rather limited in time for the next weeks if not months, and I
can't estimate the effort to learn the gradle/java packaging stuff,
I suggest the following:  If you find time to work on it, just send a
short notice here or directly to me.  I'll do the same, so we won't
double work, and then we can figure out the details, if needed.

Best regards,

  Andi

Bug#1052537: arduino: please make dialog/check for dialout group optional or allow for remembering 'ignore'

[Andreas B. Mundt]

Package: arduino
Severity: wishlist
X-Debbugs-Cc: a...@debian.org

Hi,

we use arduino in schools where the users are centrally provided and
the dialout group exists only on the local machine.  To access the
serial interface, additional configurations are in place to give
everybody access.  Now, every time arduino is started, students have
to choose 'ignore' on the popup dialog.

It would be great if either:

  • this dialog can be disabled somehow (preseed a debconf question)
or
  • it remembers the answer of the user, like another button:
[Ignore and remember decision]   
or
  • detects if access to the serial interfaces is really not granted

Probably there are even better solutions, but you get the idea.
Thanks for packaging arduino!

Best regards,

  Andi

Bug#967306: ddrescueview: depends on deprecated GTK 2

[Peter B]

On 20/09/2023 12:36, Bastian Germann wrote:

Control: tags -1 patch
Control: unblock -1 by 967564

Please find a patch attached that builds the package with Qt5.



Fix uploaded to Mentors.

Would like to update the VCS, (and setup CI) but need 'maintainer' access to be 
able to do that.

Bug#1052356: RFS: ddrescueview/0.4.5-2 -- graphical viewer for GNU ddrescue map files

[Peter B]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ddrescueview":

 * Package name : ddrescueview
   Version  : 0.4.5-2
   Upstream contact : Martin Bittermann 
 * URL  : https://sourceforge.net/projects/ddrescueview/
 * License  : GPL-3.0+
 * Vcs  : https://salsa.debian.org/pascal-team/ddrescueview
   Section  : utils

The source builds the following binary packages:

  ddrescueview - graphical viewer for GNU ddrescue map files

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/ddrescueview/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/d/ddrescueview/ddrescueview_0.4.5-2.dsc

Changes since the last upload:

 ddrescueview (0.4.5-2) unstable; urgency=medium
 .
   * Build for Qt5 instead of Gtk2 (Closes: #967306)

Regards,
--
  Peter Blackman

Bug#1052322: RFS: c-evo-dh/1.9-1 -- Empire Building Game (data files), C-evo: Distant Horizon

[Peter B]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "c-evo-dh":

 * Package name : c-evo-dh
   Version  : 1.9-1
   Upstream contact : Peter 
 * URL  : https://sourceforge.net/projects/c-evo-eh/
 * License  : CC-BY-3.0, CC-BY-SA-3.0-US, GPL-2+, CC0-1.0
 * Vcs  : https://salsa.debian.org/PeterB/c-evo-dh
   Section  : games

The source builds the following binary packages:

  c-evo-dh-gtk2 - Empire Building Game (GTK2), C-evo: Distant Horizon
  c-evo-dh-stdai - Empire Building Game (AI module), C-evo: Distant Horizon
  c-evo-dh-data - Empire Building Game (data files), C-evo: Distant Horizon

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/c-evo-dh/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/c-evo-dh/c-evo-dh_1.9-1.dsc

Changes since the last upload:

 c-evo-dh (1.9-1) unstable; urgency=medium
 .
   * New Upstream Release

Regards,
--
  Peter Blackman

Bug#1052321: RFS: view3dscene/4.2.0-2 [RC] -- VRML / X3D browser, and a viewer for other 3D model formats

[Peter B]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "view3dscene":

 * Package name : view3dscene
   Version  : 4.2.0-2
   Upstream contact : Michalis Kamburelis 
 * URL  : https://castle-engine.io/view3dscene.php
 * License  : public-domain, GPL-2+, GFDL-1.2+
 * Vcs  : https://salsa.debian.org/pascal-team/view3dscene
   Section  : graphics

The source builds the following binary packages:

  view3dscene - VRML / X3D browser, and a viewer for other 3D model formats

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/view3dscene/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/v/view3dscene/view3dscene_4.2.0-2.dsc

Changes since the last upload:

 view3dscene (4.2.0-2) unstable; urgency=medium
 .
   * Depend on libgl1 (Closes: #1051598)
   * Build-Depends on libgdk-pixbuf-2.0-dev (Closes: #1037406)
   * Disable lto (Closes: #1015702)
   * Fix links in debian/copyright
   * Fix folder name in debian/clean
   * Drop build dependency on whitedune-docs
   * Add lintian overrides
   * Add myself to Uploaders
   * Update standards version to 4.6.2, no changes needed.

Regards,
--
  Peter Blackman

Bug#1052259: licensecheck: GPL-3+ licences shown as GPL-3

[Peter B]

Package: licensecheck
Version: 3.3.9-1
Severity: normal
X-Debbugs-Cc: pe...@pblackman.plus.com

Dear Maintainer,

Files containing short license names such as GPL-3.0+ are reported
as GPL-3 instead of GPL-3+

Example is dist/unix/strawberry.spec.in in package strawberry
https://salsa.debian.org/debian/strawberry/-/blob/master/dist/unix/strawberry.spec.in

This is the only example file I have now, but I have tried editing the file to
use various other short names such as;

GPL-3+
GPLv3+

The results are the same. The + suffix is not recognised as allowing a later
version of the license. All are reported as GPL-3


Regards,
Peter B


-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages licensecheck depends on:
ii  libfeature-compat-class-perl    0.06-1
ii  libfeature-compat-try-perl  0.05-1
ii  libio-interactive-perl  1.023-2
ii  liblog-any-adapter-screen-perl  0.140-2
ii  liblog-any-perl 1.717-1
ii  libnamespace-clean-perl 0.27-2
ii  libpath-iterator-rule-perl  1.015-2
ii  libpath-tiny-perl   0.144-1
ii  libpod-constants-perl   0.19-2
ii  libstring-copyright-perl    0.003014-1
ii  libstring-escape-perl   2010.002-3
ii  libstring-license-perl  0.0.9-2
ii  perl    5.36.0-9

Versions of packages licensecheck recommends:
ii  libregexp-pattern-license-perl  3.11.0-1

Versions of packages licensecheck suggests:
ii  bash-completion  1:2.11-7

-- no debconf information

Bug#1021339: Offer to help with some neovim packaging

[Ricardo B. Marliere]

On 23/09/18 08:39PM, James McCoy wrote:
> I have initial versions of the new dependencies packaged locally.  I
> need to clean a few things up, get them through NEW, and then either
> skip or figure out what the test failures are that I'm hitting.
> 
> This will all likely go to experimental first, since there are also a
> few library transitions that are involved.
> 
> Cheers,
> --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Greetings!

I can also help with testing and sorting things out.

Thanks,
-   Ricardo

Bug#1052122: RFS: asunder/3.0.1+ds-1 -- Graphical audio CD ripper and encoder

[Peter B]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "asunder":
(Andreas R who kindly sponsored my adoption of this package,
is sadly locked out from his gpg key.)


 * Package name : asunder
   Version  : 3.0.1+ds-1
   Upstream contact : Andrew Smith 

 * URL  : http://www.littlesvr.ca/asunder
 * License  : GPL-2
 * Vcs  : https://salsa.debian.org/debian/asunder
   Section  : sound

The source builds the following binary packages:

  asunder - Graphical audio CD ripper and encoder

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/asunder/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/asunder/asunder_3.0.1+ds-1.dsc

Changes since the last upload:

 asunder (3.0.1+ds-1) unstable; urgency=medium
 .
   * New upstream release 3.0.1 (Fixes CDDB upload)
   * Add missing docs to binary package

Regards,
--
  Peter Blackman

Bug#967259: asunder depends on gtk2

[Peter B]

Hi Matthias, Bastian,

I'd prefer to retain asunder for the time being.
If bugs are reported in grimripper that I can't reproduce,
it would be very helpful to ask the reporter if the same problem happens with 
asunder.
That will be problematic if its been removed from the archive.


I'd also like to see a much wider take-up, freedom from bugs, and more upstream 
support,
before burning the boats with respect to asunder.

Currently, there are no other official grimripper packages in the 'nix world.
https://repology.org/project/grimripper/versions

This CTD bug reported in May, is still not fixed upstream.
https://gitlab.gnome.org/Salamandar/GrimRipper/-/issues/8
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040980


Asunder is seeing some upstream activity now,
so there is still a possibility of a switch to gtk3, before gtk2 is removed 
from Debian


Cheers,
Peter

Bug#1052029: c-evo-dh: depends on deprecated GTK 2

[Peter B]

On 16/09/2023 11:31, Bastian Germann wrote:

Please consider switching to lcl=qt5 to build with qt5 interface.
Please rename c-evo-dh-gtk2 to c-evo-dh when implementing this. We really
do not need to know the toolkit that it uses by looking at the pkg name.


Hi Bastian,

Lazarus can build packages against various toolkits, and if more than one is 
viable,
building those gives users some choice, as they all have various quirks.
The toolkit in the package name allows that differentiation.

C-evo-dh will build against all supported Lazarus toolkits, however,
gtk3 & fpgui builds crash on startup, and qt5 & qt6 have corrupted graphics.
gtk2 is the only Linux toolkit version that currently runs OK.

C-evo-dh has been intentionally packaged to allow co-installation of multiple 
front-ends.
I will certainly include others when they become viable.
I tested the Qt6 build today with Lazarus 3.0RC1, but have the same display 
issues as with Qt5.
gtk3 is being worked on upstream. That may become a possibility.

Cheers,
Peter

Bug#587553: Any progress packaging?

[Andreas B. Mundt]

Hi Tassia,

I would like to ask if there is any progress with this ITP.  A friend 
of mine is using bluej teaching java in his school, that's how I found
this report and got interested in the current status.  It would be
nice to have this packaged in Debian.

Thanks and best regards,

  Andi

Bug#1051840: licensecheck: file parsing: extract metadata from appstream

[Peter B]

Hi Jonas,

Apart from the appstream metadata issue, I'm seeing license shortnames such as

GPL-3.0+
GPLv3+
GPL-3+

in file headers are all shown as GPL-3  instead of GPL-3+

Example
https://salsa.debian.org/debian/strawberry/-/blob/master/dist/unix/strawberry.spec.in


Should I raise this as a separate bug report?



Cheers,
Peter

Bug#1040494: RFS: cevomapgen/27-1 [ITP] -- External Map Generator for C-Evo

[Peter B]

Package: sponsorship-requests

Dear mentors,

I am looking for a sponsor for my package "cevomapgen":

 * Package name : cevomapgen
   Version  : 27-1
   Upstream contact : Peter Blackman 
 * URL  : https://sourceforge.net/projects/cevomapgen/
 * License  : CC-BY-3.0, GPL-3+
   Programming Lang : FPC/Lazarus
 * Vcs  : https://salsa.debian.org/PeterB/cevomapgen
   Section  : games

The source builds the following binary packages:

  cevomapgen - External Map Generator for c-evo-dh

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/cevomapgen/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cevomapgen/cevomapgen_27-1.dsc

Changes for the initial release:

 cevomapgen (27-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1035747)

Regards,
--
  Peter Blackman

Bug#1051840: licensecheck: Incorrect license reported for appstream metadata

[Peter B]

Package: licensecheck
Version: 3.3.9-1
Severity: minor
X-Debbugs-Cc: pe...@pblackman.plus.com

Dear Maintainer,

Appstream metadata files have two license fields;
1) 
2) 

The license for the file itself is the metadata license,
but licensecheck reports using the project license.

Example here
https://salsa.debian.org/debian/strawberry/-/blob/master/dist/unix/org.strawberrymusicplayer.strawberry.appdata.xml

File license is CC0-1.0, but licensecheck reports GPL.


Note, also the project license is GPL-3+, not just GPL.



Regards,
Peter B

Bug#1051314: fonts-recommended: recognise noto-core as alternative to dejavu-core

[Justin B Rye]

Package: fonts-recommended
Version: 1
Severity: wishlist
Tags: patch

Various major desktops now default to fonts-noto-core instead of
fonts-dejavu-core.   During a conversation with a fontconfig-config
maintainer on debian-l10n-english about the knock-on effects
("https://lists.debian.org/debian-l10n-english/2023/09/msg1.html;)
I noticed that the dependency chains ensuring that fonts-noto-core is
actually installed at all are surprisingly weak.

This font package used to be very nearly the only one I needed to have
manually installed to ensure I got everything I was likely to want (as
a linguist I add fonts-unifont just to be on the safe side).  Changing
the "Depends: fonts-dejavu-core" to "fonts-dejavu-core |
fonts-noto-core" (or even the reverse) would help the package stay
just as useful on trixie.  Possibly more useful, if noto's coverage is
good enough to let me stop installing unifont!

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fonts-recommended depends on:
ii  fonts-cantarell  0.303.1-1
ii  fonts-comic-neue 2.51-4
ii  fonts-courier-prime  0+git20190115-3
ii  fonts-croscore   20201225-2
ii  fonts-crosextra-caladea  20200211-2
ii  fonts-crosextra-carlito  20230309-2
ii  fonts-dejavu-core2.37-8
ii  fonts-firacode   6.2-2
ii  fonts-freefont-otf   20211204+svn4273-2
ii  fonts-league-spartan 2.210-1
ii  fonts-noto-color-emoji   2.038-1
ii  fonts-symbola2.60-1.1
ii  fonts-urw-base35 20200910-7

fonts-recommended recommends no packages.

fonts-recommended suggests no packages.

-- no debconf information
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- control.orig	2020-02-20 19:31:27.0 +
+++ control	2023-09-06 07:09:55.513613487 +0100
@@ -13,8 +13,8 @@
 Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends},
-# long-time default of most DEs, mostly in the past
-	fonts-dejavu-core,
+# older and newer widespread DE defaults
+	fonts-dejavu-core | fonts-noto-core,
 # GNOME's default
 	fonts-cantarell,
 # Windows compat: Arial, Courier New, Times New Roman

Bug#1050550: [Pkg-pascal-devel] RFA: winff -- graphical video and audio batch converter using ffmpeg or avconv

[Peter B]

On Thu, 31 Aug 2023 16:37:30 +0200 Bastian Germann  wrote:
> Hi Peter,
>
> It would be helpful to maintain the git repo, so if you are not already
> part of the Pascal Team, please consider joining. Otherwise, Paul might be
> so kind to add you as a member only to that single repo.
>
> Thanks,
> Bastian


Agreed. It would be very helpful if I could update the VCS.
I was about to mention this anyway.

I'd be happy to join the team.


Cheers,
Peter

Bug#1047457: winff: Fails to build source after successful build

[Peter B]

FPC have changed .rst files to .rsj

debian/clean needs updating. (pending)

Bug#1050833: release-notes: Bookworm renames network interfaces

[Justin B Rye]

Rainer Dorsch wrote:
>> Are you saying that armhf machines still used one of the old interface
>> naming schemes (https://wiki.debian.org/NetworkInterfaceNames) on
>> bullseye, and hadn't yet switched over to "predictable" names?  
> 
> That is at least what I observed. I don't have insights, why armhf behaves 
> differently here.

Maybe I should go and ask on the armhf mailinglist - oh, except that
you've done that for me, thanks!  Let's see if anyone follows up.

The name "end0" doesn't match anything that the systemd documentation
told us the Predictable Names scheme would generate, so I should also
try to find out what's going on there... ah, looks as if it's "d for
devicetree":

https://github.com/systemd/systemd/commit/65c2ad985a8debdf6d7d11fee5b466f280260f4b#diff-74ecd06b7b5ba73ee97dbca326e44e3dddf6e8841bda2e073b06bdc4d8bd158dR682

You'd think they'd have learned by now that when you change this
stuff, you need to mention to sysadmins that you're planning to lock
them out of their servers next time they do a remote reboot, but no,
it isn't mentioned anywhere in

https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html

Except, wait, if this was caused by a change in systemd v254, doesn't
that make it a bookworm-to-trixie tripwire?  Perhaps I'm looking at
the wrong arbitrary unsignposted fluctuation in naming policy...

>> For
>> the architectures I know anything about, interface names like eth0
>> disappeared quite a while ago, with particular warnings in the stretch
>> and buster release notes:
>> 
>> https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.
>> html#new-interface-names
>> 
>> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en
>> .html#migrate-interface-names
> 
> If I understand the sentence
> 
> "This change does not apply to upgrades of jessie systems; the naming will 
> continue to be enforced by /etc/udev/rules.d/70-persistent-net.rules."
> 
> correctly, this means old systems stay with the old naming scheme by default, 
> newly installed systems use the new naming scheme.

It was true for jessie-to-stretch upgrades, but then buster lost the
machinery keeping /etc/udev/rules.d/70-persistent-net.rules updated
for changed network hardware, and the support has crumbled further
since then - it's not exactly clear how much is left.  Upstream
insists it isn't supported at all, but then again udev still seems to
allow those rules files...
 
> That is an excellent solution, since it does not break existing systems 
> during 
> the upgrade. 
>
> But what I observed in the armhf install is exactly the opposite. A running 
> bullseye system did not work anymore after the upgrade to bookworm due to the 
> network interface naming change. Since these are often headless systems, you 
> then rely on a serial interface for debugging.
> 
> As a side note:
> I have two amd64 kvm cloud hosted machines at different providers. I upgraded 
> one of them to bookworm, both use still uses eth0 as interface name. I see 
> the 
> they have both
> 
> net.ifnames=0
> 
> configured as kernel parameter in /etc/default/grub in the variable 
> GRUB_CMDLINE_LINUX.
> 
> Since I did not actively configure that, I assume that there are quite a few 
> machines out there with disabled Predictable Network Interface renaming 
> behavior.

I'm told (so it went into the bookworm release notes) that Xen only
recently switched from "eth0" to "enX0"; no idea what the situation is
like on KVM.

>> If the sequence of events has been different on armhf, that might need
>> a new entry in the "Complications and corner cases" section of the
>> wiki page.  The question is, how exactly did you come to be still
>> using "eth0" in a bullseye /etc/network/interfaces file?
> 
> I just run the installer for bullseye on a cubox-i/armhf machine. I do not 
> recall that I did anything special. I could repeat it, but maybe it is better 
> if somebody else does a test (just in case I missed something, it is likely 
> that I miss it again, though I don't know what that could be).

Did the installer give you a 70-persistent-net.rules file?  It seems a
bit of a pointless mechanism for hardware like yours...
 
>> Sure, *if* the change was in bookworm.  But if people didn't read
>> the stretch and buster release notes, why would we expect a warning in
>> the bookworm release notes to do any good? 
> 
> I am also somewhat concerned that users don't read the release notes 
> carefully, break their systems. This information should probably be in a more 
> prominent place and clearly visible during the upgrade. I liked the previous 
> solution better that systems by default continue to use the old naming scheme.

Well, systems still do continue to use the old naming scheme, unless
you change your apt sources to point at a new release!  And it's
really much easier to change your configuration once to use the new
names than to change your grub configuration and carry that around

Bug#1050833: release-notes: Bookworm renames network interfaces

[Justin B Rye]

Rainer Dorsch wrote:
> I did a test installation with a bullseye installer on a cubox-i
> (armhf architecture) and then upgraded to bookworm. After the upgrade
> the network was gone. Even booting with the previous kernel
> 5.10.0-23-armmp does not bring the network back.
> 
> After some more investigation, I found that the network interfaces got
> renamed from eth0 to end0, which required manual modifications in my
> /etc/network/interfaces file. Fortunately, I did this test before
> upgrading production systems.

Are you saying that armhf machines still used one of the old interface
naming schemes (https://wiki.debian.org/NetworkInterfaceNames) on
bullseye, and hadn't yet switched over to "predictable" names?  For
the architectures I know anything about, interface names like eth0
disappeared quite a while ago, with particular warnings in the stretch
and buster release notes:

https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#new-interface-names

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names

If the sequence of events has been different on armhf, that might need
a new entry in the "Complications and corner cases" section of the
wiki page.  The question is, how exactly did you come to be still
using "eth0" in a bullseye /etc/network/interfaces file?

> On one of my production systems the renaming also broke the packages
> shorewall, dnsmasq, and some custom scripts.
> 
> On the debian-arm mailing list the topic was discussed in this threat:
> 
> https://lists.debian.org/debian-arm/2023/08/msg3.html
> 
> Suggestions in the thread:
> - Try adding "net.ifnames=0" to kernel's commandline.
> - Adding a statement to the release notes like "did you know your
> interface name will change after the reboot thus possibly breaking
> your network configuration?"
> - Add a warning to debconf which the user has to confirm during the
> upgrade
> - ifupdown can do interface name wildcards and mac matching. The
> other solutions for this problem (systemd-networkd, NetworkManager,
> ifupdown-ng, probably ifupdown2) -> but this solves only part of the
> problem, e.g. neither dnsmasq and shorewall are not covered nor custom
> scripts  

If you're worried about "predictable" names making things
unpredictable, the canonical solution is to set up a .link file
specifying how you want the crucial interface(s) to be named.  See the
section "CUSTOM SCHEMES USING .LINK FILES".
 
> Adding a prominent warning to the release notes should a low hanging
> fruit and would have helped me. Likely I would not have run in the
> issue in the first place or at least the debugging would have been
> easier :-)

Sure, *if* the change was in bookworm.  But if people didn't read
the stretch and buster release notes, why would we expect a warning in
the bookworm release notes to do any good? 
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1050751: qosmic: Move to a lua version != 5.2

[Peter B]

Last upstream release was in 2017. Seems Unlikely that they can help with a lua 
port.

Many compile errors with lua 5.3, however Qosmic builds OK with lua 5.1 with
a one line change.

src/lua/frame.cpp  // 98
    lua_tointegerx(L, 1, ) - 1; --> lua_tointeger(L, isnum) - 1;

Bug#1050550: RFA: winff -- graphical video and audio batch converter using ffmpeg or avconv

[Peter B]

I'd be happy to adopt winff


Cheers,
Peter

Bug#1049986: ITP: filtermail -- Filtermail filters incoming e-mail as accepted, spam, or ignored

[Frank B. Brokken]

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

* Package name: filtermail
  Version : 1.02.00
  Upstream Contact: Frank B. Brokken 
* URL : https://fbb-git.gitlab.io/filtermail
* License : GPL
  Programming Lang: C++
  Description : Filtermail filters incoming e-mail as accepted, spam, or 
ignored

Filtermail filters incoming e-mail as either accepted, spam, or ignored
e-mail. It uses rule files, which are inspected in sequence until the incoming
e-mail matches a rule. Once that happens the rule's associated action (accept,
spam, or ignore) is executed. If the e-mail is not matched by any rule then
the e-mail is accepted.

Accepted e-mail normally is appended to the mail file which is used by the
incoming mail server when receiving mail for the current user. E.g., if the
user's username is frank then incoming mail is appended to the file
/var/mail/frank. Users may also define directories to contain saved e-mails
(e.g., ~/Mail), and filtermail can be configured to append e-mail considered as
spam to, e.g., ~/Mail/spam. Likewise, e-mail matching the 'ignore'
criteria could be appended to ~/Mail/ignore. 

Instead of appending the complete e-mail to its destination file the received
e-mail's From: and Subject: headers can be appended to its destination
file. Alternatively, such e-mail can also be ignored, losing it completely.

Filtermail uses three types of files:
* The configuration file contains values of options with are generally
used (covered in the man-page's sections CONFIGURATION and OPTIONS);
* Mail filtering rules are hierarchically ordered in the rules
file: incoming mail is sequentially matched against the patterns
defined in files specified in the rules file until a match is
found. Once a match has been found the rule's action (accept, ignore
or spam) is executed, ending the filtering process;
* Each file specified in the rules file defines matching patterns, which
are tested sequentially. Testing those patterns ends once the incoming
mail matches a pattern.

In addition to the filtermail program itself a small support program 'inspect'
is part of filtermail: inspect expects a received e-mail file at its standard
input. Mail handling programs (e.g., mutt(1)) allow its users to pipe an
e-mail file to a program, inspecting the received e-mail.  Depending on the
content of the Received: headers inspect's output shows the domain name of the
sender, its IP address, its country of origin and the cidr-range containing
the received IP address. If the received e-mail is considered conspicuous
(e.g., spam or mail to ignore) then the mail's details, e.g. its cidr
range. could be added to the file recognizing spam-rated e-mail.

 - why is this package useful/relevant? 
The main reason for developing filtermail was the fact that I frequently
receive mail which is either spam or which is completely irrelevant and
annoying. Previously I used a bash-script to filter such mail, but that
script eventually was hard to maintain. A compilable program offers, IMHO,
better facilities for maintenance and modifications so I wrote
filtermail. Over the past three months it performed its job as
expected. E.g., of the about 300 e-mails I received in the category
'igored' were all correctly categorized.

  - it a dependency for another package? 
 No, it's a stand-alone program

  - do you use it? 
 Yes, I do

  - if there are other packages providing similar functionality, how does it
compare?  
 There exists a program 'mailfilter' focusing on handling pop-accounts and
 also offering ways to recognize e-mail as spam. Filtermail, on the other
 hand, uses the 'ignore' category in addition to the 'spam' category and
 primarily aims at categorizing (in various forms) incoming e-mail.

 - how do you plan to maintain it? 
 I have a long history of building and maintaining programs, many of them
 are also registered as Debian packages. I handle the maintenance of the
 programs myself, and almost all my direct contact with Debian is via Tony
 Mancill (tmanc...@debian.org) who is a Debian developer. When there's a
 new version of one of my Debian provided programs I prepare the required
 update, upload it to salsa, and send Tony an e-mail asking him to verify
 the latest update.

 Filtermail's website is at https://fbb-git.gitlab.io/filtermail/ where
 you also find links to the man-pages, to its repository, and to a list of
 programs I developed, most of them are available as Debian packages.

   - do you need a sponsor?
  If I'm correct then the 'sponsor' is a Debian maintainer who's willing to
  adopt a program for Debian. If so, then yes, I do.
  
I hope you like filtermail!

Bug#1043180: s3ql: missing dependency "fuse3"

[Raveeroj B.]

Package: s3ql
Version: 3.7.3+dfsg-2+b1
Severity: normal

Dear Maintainer,

In compact Debian images, the package fuse3 is not installed by default.
This leads to this error when using the "mount.s3ql" command:

fuse: failed to exec fusermount3: No such file or directory
ERROR: Uncaught top-level exception:
Traceback (most recent call last):
  File "/usr/lib/s3ql/s3ql/mount.py", line 218, in main_async
pyfuse3.init(operations, options.mountpoint, get_fuse_opts(options))
  File "src/pyfuse3.pyx", line 765, in pyfuse3.init
RuntimeError: fuse_session_mount failed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/s3ql/s3ql/mount.py", line 220, in main_async
raise QuietError(str(exc), exitcode=39)
s3ql.logging.QuietError: fuse_session_mount failed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/mount.s3ql", line 33, in 
sys.exit(load_entry_point('s3ql==3.7.3', 'console_scripts', 'mount.s3ql')())
 ^^
  File "/usr/lib/s3ql/s3ql/mount.py", line 131, in main
trio.run(main_async, options, stdout_log_handler)
  File "/usr/lib/python3/dist-packages/trio/_core/_run.py", line 2093, in run
raise runner.main_task_outcome.error
  File "/usr/lib/s3ql/s3ql/mount.py", line 204, in main_async
async with AsyncExitStack() as cm:
  File "/usr/lib/python3.11/contextlib.py", line 733, in __aexit__
raise exc_details[1]
  File "/usr/lib/python3.11/contextlib.py", line 716, in __aexit__
cb_suppress = await cb(*exc_details)
  ^^
  File "/usr/lib/python3.11/contextlib.py", line 621, in _exit_wrapper
await callback(*args, **kwds)
  File "/usr/lib/s3ql/s3ql/block_cache.py", line 284, in destroy
while self.to_remove.get_nowait() is QuitSentinel:
  ^
AttributeError: 'NoneType' object has no attribute 'get_nowait'

This can easily be fixed by installing the fuse3 package.



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

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

Versions of packages s3ql depends on:
ii  fuse3 [fuse]  3.14.0-4
ii  libc6 2.37-7
ii  libjs-sphinxdoc   5.3.0-6
ii  libsqlite3-0  3.42.0-1
ii  procps2:4.0.3-1
ii  psmisc23.6-1
ii  python3   3.11.4-5+b1
ii  python3-apsw  3.42.0.1-1
ii  python3-cryptography  38.0.4-3
ii  python3-defusedxml0.7.1-2
ii  python3-dugong3.8.1+dfsg-1
ii  python3-google-auth   1.5.1-3
ii  python3-google-auth-oauthlib  0.4.2-1
ii  python3-pkg-resources 68.0.0-1
ii  python3-pyfuse3   3.2.1-2+b2
ii  python3-requests  2.31.0+dfsg-1
ii  python3-systemd   235-1+b2
ii  python3-trio  0.22.2-1

s3ql recommends no packages.

s3ql suggests no packages.

-- no debconf information

Bug#1043035: systemd has invalid dependency in sid for riscv64

[Michał B .]

Package: systemd

The systemd has invalid dependency in comparison to other packages. I am
unable to debootstrap for riscv64 platform.

Host machine: Linux 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2
(2023-07-27) x86_64 GNU/Linux
Host debian version: 12.1

Command executed: sudo debootstrap --arch=riscv64 --keyring
/usr/share/keyrings/debian-ports-archive-keyring.gpg
 --include=debian-ports-archive-keyring unstable chroot/
https://deb.debian.org/debian-ports/

Error log:
Setting up libkmod2:riscv64 (30+20230519-1) ...
Setting up libseccomp2:riscv64 (2.5.4-1+b3) ...
Setting up libsystemd-shared:riscv64 (254~rc3-3) ...
dpkg: dependency problems prevent configuration of systemd:
 systemd depends on systemd-dev (>= 254~rc3-3); however:
  Version of systemd-dev on system is 254~rc3-1.

dpkg: error processing package systemd (--install):
 dependency problems - leaving unconfigured
Setting up systemd-dev (254~rc3-1) ...
Setting up libdevmapper1.02.1:riscv64 (2:1.02.185-2) ...
Setting up dmsetup (2:1.02.185-2) ...
Setting up libcryptsetup12:riscv64 (2:2.6.1-4) ...
Processing triggers for libc-bin (2.37-6) ...
Errors were encountered while processing:
 systemd

Bug#1039472: Fix for bookworm available as well?

[Andreas B. Mundt]

Hi Andreas, all,

we suffer from this issue on bookworm desktops (KDE plasma desktop)
where installing arduino causes the troubles described above (… error
processing package ca-certificates-java …).  For the time being, we
decided to skip arduino, but this is no solution in the long run.

Are there any plans to fix this in bookworm too?  Or is there a
workaround available to get rid of the problem?

Many thanks and best regards,

  Andi

Bug#684128: src:debian-installer: allow use of binary units in disk partitioner

[Justin B Rye]

Holger Wansing wrote:
> Thorsten Glaser :
>> Could this information (valid unit sufficēs) be added to the dialogue
>> where the size is entered? Screen space should suffice.
[...]
> CC'ing debian-l10n-english for template review (three identical additions
> in two packages).
[...]
>   Hint: "max" can be used as a shortcut to specify the maximum size, or
>   enter a percentage (e.g. "20%") to use that percentage of the maximum size.
> + You can specify partition sizes in decimal units (like MB or GB) as well as
> + in binary units (like GiB or TiB).

Looks good to me.  Mind you, this makes the passive voice in the first
line a bit more of a stylistic and syntactic mismatch, so I might
suggest changing it to

Hint: you can use "max" as a shortcut to specify the maximum size, or

throughout...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1019862: invisible mouse pointer: still an issue in bookworm 12.1

[Andreas B. Mundt]

Hi Rene,

thanks for your quick answer!

On Sat, Jul 22, 2023 at 04:44:32PM +0200, Rene Engelhard wrote:
> Am 22.07.23 um 16:17 schrieb Andreas B. Mundt:
> > […]
> 
> Sure? The description in the original bug doesn't talk about mouse cursors?
> 
> Theer's that wayland message, indeed, but..

You are right, I am also not completely sure … 

> > […]

> So fixed in 7.5.2 then... I could upload a backport if 7.5 even migrated to
> testing

That's also a very good solution for us, as we will probably use
backports from libreoffice sooner or later anyway.

> > The related qt6 report is here:
> > 
> >https://bugreports.qt.io/browse/QTBUG-95434
> >
> > https://codereview.qt-project.org/c/qt/qtwayland/+/461361/3/src/client/qwaylandcursor.cpp
> 
> But that is Qt6, but Qt5. The kf5 plugin uses Qt5 "of course".
> 
> 
> You say "or to qt6-wayland".
> 
> If at all - for KDE -, this needs to be fixed in Qt5 (in whatever package is
> equivalent to said qt6-wayland) additonally tp qt6-wayland.

Of course, sorry, confused …

Best regards,

  Andi

Bug#1019862: invisible mouse pointer: still an issue in bookworm 12.1

[Andreas B. Mundt]

Hi Rene, all,

first, many thanks for maintaining libreoffice!  We are running the
KDE plasma desktop environment in our school and observe probably the
same issue here:  Especially in libreoffice draw, when selecting for
example the 'lines and arrows'-tool, the mouse pointer usually becomes
a cross and a line on the drawing area.  However, it becomes invisible
in KDE/Plasma on wayland.  I found the following related upstream bug
reports with patches already, but unfortunatelly they are not applied
to the libreoffice 7.4 series or to qt6-wayland (cc Debian Qt/KDE
Maintainers):

  https://bugs.documentfoundation.org/show_bug.cgi?id=15
  
https://git.libreoffice.org/core/+/091f56e50748e3fd807b9bae88652b68834aac3a%5E%21

The related qt6 report is here:

  https://bugreports.qt.io/browse/QTBUG-95434
  
https://codereview.qt-project.org/c/qt/qtwayland/+/461361/3/src/client/qwaylandcursor.cpp

Best regards,

  Andi



-- 

GPG key: 4096R/617B586D 2010-03-22 Andreas B. Mundt--
   Andreas B. Mundt--
   Andreas B. Mundt--
   Andreas B. Mundt--

 938A 5CEE 1E29 0DE2 55D9  AC98 B01F EA84 617B 586D

 https://keys.openpgp.org/

Bug#1033847: closed by Debian FTP Masters (reply to gabr...@debian.org (Gabriel F. T. Gomes)) (Bug#1033847: fixed in bash-completion 1:2.11-7)

[Richard B. Kreckel]

Gabriel,

On 7/17/23 08:39, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the bash-completion package:

#1033847: Please update to upstream sources

It has been closed by Debian FTP Masters  
(reply to gabr...@debian.org (Gabriel F. T. Gomes)).


You seem to have fixed the NIS issue by removing the specific Debian 
patch. That's great. Thank you!


Would it be possible to update the package to the current upstream 
version? The Debian package is lagging three years behind, after all.


  -richy.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034812: Bug#1041168: Installation of GRUB failed

[Christof B.]

Am 17.07.23 um 20:13 schrieb Pascal Hambourg:

Thanks for testing. Should #1034812 and #1041168 be merged ?


Yes, I think so.

Bug#1041168: Installation of GRUB failed

[Christof B.]

Am 15.07.23 um 22:57 schrieb Pascal Hambourg:
> Replacing /lib/partman/init.d/50efi with either attached 50efi.1 or
> 50efi.2 as 50efi should fix the issue in guided partitioning with
> encrypted LVM.
>
>cp /50efi.1 /lib/partman/init.d/50efi
> or
>cp /50efi.2 /lib/partman/init.d/50efi
>

I tried each of them and they both solved my problem. /boot and /boot/efi 
were on the same (and correct) disk. The installed system was bootable :-)


> Fixing the issue in guided partitioning with unencrypted LVM also
> requires replacing /bin/autopartition-lvm with the attached
> autopartition-lvm.
>
>cp /autopartition-lvm /bin/autopartition-lvm
>
> The files can be replaced after "Load installer components" and before
> "Partition disks".

I could reproduce the same issue with unencrypted LVM (#1034812) on my 
machine with my stock installer image.


Like above, replacing 50efi by 50efi.1 plus the other file in /bin made 
the installation work alright. The system was bootable afterwards.


Thanks a lot for the quick fixes!

Cheers
Christof

Bug#1041168: Installation of GRUB failed

[Christof B.]

Am 15.07.23 um 21:07 schrieb Pascal Hambourg:
If you are willing to test, I can provide patched files which replace the 
original ones in a running d-i.


Yes, I am willing to test this. If it can be patched by replacing some 
files at runtime (and not compiling some binaries or images), please 
provide me the files with a hint at where (path) and when (at which step 
of the installation process) to put them into place.


If technically feasible (if all files can be replaced at once) a tarball 
would be best.


Thanks and cheers
Christof

Bug#1041168: Installation of GRUB failed

[Christof B.]

Hi!

Am 15.07.23 um 18:35 schrieb Pascal Hambourg:

Hello,

On 15/07/2023 at 15:28, Christof B. wrote:


Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/mapper/debian--vg-root
  120469224   1379448 112924068   1% /target
/dev/sdb2   466026 88234    352807  20% /target/boot
/dev/sda2 5062  5062 0 100% /target/boot/efi

(...)
Although I chose sdb as installation target, somehow d-i uses /dev/sda2 
instead of /dev/sdb2 as EFI partition.


You mean /dev/sdb1. /dev/sdb2 is the /boot partition.


Yes.



It looks like bug #1034812 (patches available).
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034812>


Probably this is a duplicate.
Are there any (nightly) d-i images available to test these patches, 
because otherwise (i. e. building d-i myself) this is over my head.


Cheers,
Christof

Bug#1041168: Installation of GRUB failed

[Christof B.]

Salut Cyril,

thanks for your quick reply!

Am 15.07.23 um 14:09 schrieb Cyril Brulebois:


Thanks for sharing all those logs in advance. syslog has:

 Jul 15 11:00:47 grub-installer: grub-install: error: cannot copy 
`/usr/lib/shim/shimx64.efi.signed' to `/boot/efi/EFI/debian/shimx64.efi': No 
space left on device.

And the ESP is close to 500M, so ENOSPC is very surprising. Any chance
you could check what's inside/what filled it?


I hat a look at the disk, but the ESP partition was completely empty. I 
redid the whole installation (with the same error) to get runtime 
information about what is going on.


Et voilà - df:

Filesystem   1K-blocks  Used Available Use% Mounted on
tmpfs   391488   136391352   0% /run
devtmpfs   1933492 0   1933492   0% /dev
/dev/mapper/debian--vg-root
 120469224   1379448 112924068   1% /target
/dev/sdb2   466026 88234352807  20% /target/boot
/dev/sda2 5062  5062 0 100% /target/boot/efi
/dev/mapper/debian--vg-root
 120469224   1379448 112924068   1% /dev/.static/dev
devtmpfs   1933492 0   1933492   0% /target/dev
tmpfs   391488   136391352   0% /target/run
/dev/sdc1  3906068  1200   3904868   0% /mnt/s

Although I chose sdb as installation target, somehow d-i uses /dev/sda2 
instead of /dev/sdb2 as EFI partition. I have no clue why.

For further investigation I added the lastest syslog as well.

Thanks in advance for your efforts!

Cheers,
Christof[1:0:0:0]   diskATA SAMSUNG SSD PM872D0Q
[2:0:0:0]   (5) PLDSDVD+-RW DS-8ABSHLD11
[7:0:0:0]   disktakeMS  Mem-drive EasyII1100
[0:0:0:0]   diskUSB Flash Disk  2.00


syslog.gz
Description: application/gzip
lrwxrwxrwx1 root root 9 Jul 15 12:49 
ata-PLDS_DVD+_-RW_DS-8ABSH_23HW6736395B764G9A03 -> ../../sr0
lrwxrwxrwx1 root root 9 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418 -> ../../sdb
lrwxrwxrwx1 root root10 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418-part1 -> ../../sdb1
lrwxrwxrwx1 root root10 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418-part2 -> ../../sdb2
lrwxrwxrwx1 root root10 Jul 15 13:05 
ata-SAMSUNG_SSD_PM871_2.5_7mm_128GB_S1ZUNXAG629418-part3 -> ../../sdb3
lrwxrwxrwx1 root root 9 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0 -> ../../sda
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0-part1 -> ../../sda1
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0-part2 -> ../../sda2
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-USB_Flash_Disk_080D7F461819660-0:0-part3 -> ../../sda3
lrwxrwxrwx1 root root 9 Jul 15 13:05 
usb-takeMS_Mem-drive_EasyII_AA04012700049230-0:0 -> ../../sdc
lrwxrwxrwx1 root root10 Jul 15 13:05 
usb-takeMS_Mem-drive_EasyII_AA04012700049230-0:0-part1 -> ../../sdc1
lrwxrwxrwx1 root root 9 Jul 15 13:05 wwn-0x5002538d401cb207 
-> ../../sdb
lrwxrwxrwx1 root root10 Jul 15 13:05 
wwn-0x5002538d401cb207-part1 -> ../../sdb1
lrwxrwxrwx1 root root10 Jul 15 13:05 
wwn-0x5002538d401cb207-part2 -> ../../sdb2
lrwxrwxrwx1 root root10 Jul 15 13:05 
wwn-0x5002538d401cb207-part3 -> ../../sdb3

Bug#1041072: trixie: Explicitly flag that /usr-merge changes will break skip-upgrades

[Justin B Rye]

Matthew Vernon wrote:
> We don't support skip-upgrades, but in practice they can often be made
> to work by an experienced administrator.
> 
> For trixie, though, packages are going to be allowed to assume
> merged-/usr, and the ongoing work to resolve the outstanding problems
> around merged-/usr and dpkg is going to concentrate on making sure all
> bookworm-trixie upgrades will work. But changes that could result in
> file loss on a bullseye-trixie skip-upgrade will not be considered
> bugs, so it would be good to particularly emphasise in the trixie
> release notes that skip-upgrades to it are not supported, and that in
> all circumstances administrators must upgrade to bookworm first.

This issue shouldn't be a major risk as long as admins know to
install usrmerge as step one.  (If they're upgrading direct from
stretch then I suppose step zero is "find a copy of usrmerge".)

Maybe a new warning-note thing at the top of section 4.2?  Of course
if they're doing skip-upgrades because they don't have time to read
all those separate Release Notes then they're probably doomed...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1041168: Installation of GRUB failed

[Christof B.]

Package: installation-reports

Boot method: USB stick (written with usbimager), UEFI
Image version: 
https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/mini.iso

Date: 2023-07-15

Machine: Dell Optiplex 9020 SFF
Partitions: see attached files hardware-summary and partman

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

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

Comments/Problems:

I did a pretty minimal installation with the base system but no graphical 
environmend. I used the "Guided - use entire disk and set up encrypted 
LVM" partitioning scheme. Then I chose the harddisk sdb instead of USB 
stick sda.

Installing GRUB (more precisely: configuring shim-signed:amd64) failed
with a message complaining that GRUB could not be installed on dummy 
(execution of "grub install dummy" failed).


Conclusion: I was unable to install GRUB using the Debian installer. That 
left me with a non bootable installation.


Thanks for looking into this,
Christof

hardware-summary.gz
Description: application/gzip
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230607"
X_INSTALLATION_MEDIUM=netboot


partman.gz
Description: application/gzip


status.gz
Description: application/gzip


syslog.gz
Description: application/gzip

Bug#982648: RFP: filius -- Filius is a tool for enhancing computer science lessons on networks.

[Andreas B. Mundt]

Package: wnpp
Followup-For: Bug #982648
X-Debbugs-Cc: a...@debian.org, debian-j...@lists.debian.org

Control: retitle -1 ITP: filius -- educational network simulator
Control: block -1 by 1040528

Hi,

I started to package filius for Debian, a draft package is already
available[1].  First, some maven data needs to be added to the
libhtmlparser-java package [2] and libsemantic-version-java [3] needs
to be included in Debian too.  I'll do some more polishing and then
coordinate the uploads with the Debian Java team. Any tests are of
course welcome.

Best regards,

  Andi


[1] https://salsa.debian.org/andi/filius
[2] https://salsa.debian.org/java-team/libhtmlparser-java/-/merge_requests/1
[3] https://salsa.debian.org/andi/libsemantic-version-java

Bug#1040528: ITP: libsemantic-version-java -- single-class semantic version implementation for java

[Andreas B. Mundt]

Package: wnpp
Severity: wishlist
Owner: "Andreas B. Mundt" 
X-Debbugs-Cc: debian-de...@lists.debian.org, a...@debian.org

* Package name: libsemantic-version-java
  Version : 2.1.1
  Upstream Contact: Simon Taddiken
* URL : https://github.com/skuzzle
* License : MIT
  Programming Lang: Java
  Description : single-class semantic version implementation for java

Semantic-Version requires no further dependencies and is thereby easy
to use within projects. Key features are:

 - Lightweight: Consists of only a single file, no dependencies.
 - Immutable: Strict immutability ensures easy handling and thread safety.
 - Serializable: Objects can be serialized using Java's ObjectOutputStream.
 - Fast: Many performance improvements make this the fastest semver
   implementation in java around (according to parsing and sorting performance.


The package is needed as a dependency for filius (RFP: #982648).
I plan to maintain it within the debian java team.

Bug#1040494: RFS: cevomapgen/26-1 [ITP] -- External Map Generator for C-Evo

[Peter B]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "cevomapgen":

 * Package name : cevomapgen
   Version  : 26-1
   Upstream contact : Peter Blackman 
 * URL  : https://sourceforge.net/projects/cevomapgen/
 * License  : CC-BY-3.0, GPL-2+
 * Vcs  : https://salsa.debian.org/PeterB/cevomapgen
   Section  : games

The source builds the following binary packages:
  cevomapgen - External Map Generator for C-Evo

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/cevomapgen/

Alternatively, you can download the package with 'dget' using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/c/cevomapgen/cevomapgen_26-1.dsc

Changes for the initial release:

 cevomapgen (26-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1035747)


Regards,
--
  Peter Blackman

Bug#614070: asunder: segfault on cddb resolver failure

[Peter B]

On Tue, 28 Feb 2017 11:06:22 + Alan Sermons 
 wrote:
> Package: asunder
> Version: 2.8-5
> Followup-For: Bug #614070
>
> Apologies for the late reply (and more if this appears twice).
>
> I've just tried this a couple of times, on a laptop that has only recently 
been
> installed. If the computer is aware that it has no connection to the Internet,
> then clicking "CDDB lookup" fails silently, but asunder keeps running. As soon
> as the connection comes back up (I'd turned the RF kill switch on the laptop
> off), it works as expected.
>
> If there is no Internet connection, but the computer does not know this (I
> rebooted the router while attempting this, but the Wifi stayed up) then the
> software aborts, as shown in the attached file. I have attached the output 
from
> gdb and the backtrace, as shown in the attached file.
>
> Please let me know what other information would be required.
>

Thanks for providing a backtrace.

The backtrace shows that lookup_disc called a library routine usleep which 
segfaulted.

Lookup_dsic has been rewritten and no longer calls usleep,
so its possible this bug is now fixed.

Can it still be reproduced?
If not, I'm inclined to close this bug now.



Cheers,
Peter

P.S. Googling "usleep segfault" gives over 13,000 results!!

Bug#1038438: graphite-web: please package latest upstream

[Andreas B. Mundt]

Package: graphite-web
Severity: wishlist
X-Debbugs-Cc: a...@debian.org

Dear Maintainer,

Thank you for maintaining the graphite-web package, which I am using
in combination with icinga2.  It seems to be the recommended way to
generate graphs within icinga.  (Because of #995461, it does not work
out-of-the-box.) 

It would be great to have the latest upstream release available in
Debian.

Best regards,

  Andi

Bug#1037249: adb: android-debug-bridge daemon hangs at start (no daemon start)

[Will B.]

Package: adb
Version: 1:29.0.6-28
Severity: important
X-Debbugs-Cc: ksu...@gmail.com

Dear Maintainer,

Ever since a few weeks ago, plugging an android device and starting the adb
daemon hangs for some time before being usable i.e. the daemon does not seem to
fire up straight away once a device is plugged in and will take some time
before starting.

I do not know what may have caused this issue and I believe it did not come
from an upgrade on the android device (as the device is pinned to a specific
version) and, beyond app updates, does not receive "mods" that could have
tampered with adb or its daemon.

The issue is found in testing as well as stable.

Once the daemon has started, it remains functioning for the remainder of its
use, even if device is plugged-off and plugged back in a few minutes later.

I have not tried the "experimental" version of adb which seems to be the latest
version available for this package nor did I see the issue mentioned when
reporting this bug. Please disregard if already fixed.

Regards


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (500, 
'testing-proposed-updates'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 adb depends on:
ii  android-libbase   1:29.0.6-28
ii  android-libboringssl  13.0.0+r24-2
ii  android-libcutils 1:29.0.6-28
ii  android-liblog1:29.0.6-28
ii  libc6 2.36-9
ii  libgcc-s1 12.2.0-14
ii  libstdc++612.2.0-14
ii  libusb-1.0-0  2:1.0.26-1

Versions of packages adb recommends:
pn  android-sdk-platform-tools-common  

adb suggests no packages.

-- no debconf information

Bug#1037203: aide release notes to work around #1037171

[Justin B Rye]

Marc Haber wrote:
> I am really sorry for this. #1037171 is an embarrassing one, sadly too
> late for the release, but I'll try to do a fix via spu.

I gather from the version data that when the bug submitter says buster
that's a typo for bookworm?

> Suggested wording for something along chapter 5.4:

It'll also need a section title and a summary of what the bug actually
is, which isn't completely clear to me.  Does the bug mean that
bullseye systems where aide was already working will break on
dist-upgrade to bookworm, or is it only a bug for systems where aide
is installed subsequently?  I'm guessing:

   
 Bug in aide user creation
 
   The version of aide in the
   initial 12.0 release of bookworm has a bug
   (https://bugs.debian.org/1037171;>#1037171) in
   its package scripts which results in the _aide
   user not being created, preventing aideinit
   from creating a new database.
 

> Before upgrading your aide packages, create

So this needs to be done before the dist-upgrade?

> /usr/lib/sysusers.d/aide-common.conf with the following contents:

Isn't this the sort of thing that's usually overridable via files with
names like /etc/sysusers.d/aide-common.conf?  I'll assume for now that
this needs to live in /usr/lib (because we *want* it trampled when the
point release version installs its own copy).

> #Type   NameID  GECOS   Home 
> directoryShell↲
> u   _aide   -   "Advanced Intrusion Detection Environment"  
> /var/lib/aide /usr/sbin/nologin↲

(I'm assuming "↲" just means "newline"...)
 
> and call systemd-sysusers to work around Bug #1037171.

(...and that this is a plain root-privileged invocation of bullseye
"systemd-sysusers".  So:)

 
   The bug can be avoided by creating the user before the dist-upgrade.
   Create a file /usr/lib/sysusers.d/aide-common.conf
   containing:
   
#Type  Name   ID  GECOS   Home directory 
Shell
u  _aide  -   "Advanced Intrusion Detection Environment"  /var/lib/aide  
/usr/sbin/nologin
   
   and then run systemd-sysusers.
 
   
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#990298: conserver-server - ipmi support

[Paul B. Henson]

Please add ipmi support to this package.

Bug#1037121: release-notes: Salt has been dropped

[Justin B Rye]

Elimar Riesebieter wrote:
> Please mention that in Bookworm the salt-stack has been removed.

Does this mean we need something in issues.dbk like this?

  

  salt stack dropped


  Due to several release-critical bugs and a short upstream support
  lifecycle, the salt remote execution manager stack
  has been dropped from Debian stable starting with bookworm. Users
  who cannot track unstable should switch to an alternative.
  

Bug#1036907: release-notes: dash in bookworm drops debconf selector for /bin/sh

[Justin B Rye]

Andrej Shadura wrote:
> I think the release notes should probably mention that dash
> 0.5.11+git20210903+057cd650a4ed-4 has dropped all debconf code to allow
> using a different shell as /bin/sh.

It's not clear from the above (or the changelog) what the change is,
exactly.  Okay, there's now no debconf code to set up a new /bin/sh ->
/bin/bash symlink, but does that mean existing ones will be reverted
on dist-upgrade, or what?  Is this configuration no longer supported,
or is it just that in future admins should set it up with some
mechanism more reliable than debconf?

Either way, we'll need to amend that release-notes entry for
^-handling, and presumably we'll want a new entry about this to go
along with that one.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1036776: release-notes: Release notes paragraph from Debian Med team

[Justin B Rye]

Andreas Tille wroteL
> Please add the following patch from the Debian Med team to the release notes:

Some English-usage suggestions:

> 
> News from Debian Med Blend
> 
> 
> As in every release new packages in the field of life sciences and 
> medicine
> were added.

"Have been" added, and I think it works better as

  As in every release new packages have been added in the fields of medicine
  and life sciences.

>  The new package shiny-server might be worth extra mentioning

 The new package shiny-server
   might be worth a particular mention,

(Or "might be particularly worth mentioning", among other options.)

> since it simplifies scientific web applications using R.

(Is it worth reorganising that into something like "since it makes it
simpler for scientific web applications to use R" or am I only
noticing it because I'm reading in pedant mode?)

>   We kept on to 
> get
> Continuous Integration support for the packages maintained by the Debian 
> Med
> team.

It's not clear whether this means that you maintained the effort and
as a result got CI support or whether CI support is something you
already had that you kept going.  Maybe:
   We also kept up 
the
  effort to provide Continuous Integration support for the packages 
maintained
  by the Debian Med team.

> 
> The Debian Med team is continuously interested in feedback from users
> specifically in the form of requesting the packaging of not yet packaged
> free software or backports from new packages or higher versions in 
> unstable.
> 

This needs at least one extra comma; maybe even:

  The Debian Med team is always interested in feedback from users,
  especially in the form of requests for packaging of not-yet-packaged
  free software, or for backports from new packages or higher versions
  in unstable.

(Are you *allowed* to put things in stable-backports if there's no
version in stable?)

> To install packages maintained by the Debian Med team, install the
> metapackages named med-*, which are at version 3.8.x for Debian bookworm.
> Feel free to visit the
> https://blends.debian.org/med/tasks;>Debian Med tasks 
> pages
> to see the full range of biological and medical software available in 
> Debian.
> 

This all looks good; I suppose med-* gets a
* but no  tags.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1034168: RFS: profile-cleaner/2.44-1 [ITP] -- Reduces browser profile size by cleaning their sqlite databases

[Peter B]

On 24/05/2023 22:04, Tobias Frost wrote:



It seems that the source is missing (the input file for txt2man)?
It would be nice to have this and create the manpage at build time.
(Can you ask upstream to include the source file of the manpage?)


Now building the man page from source text.

Bug#1034168: RFS: profile-cleaner/2.44-1 [ITP] -- Reduces browser profile size by cleaning their sqlite databases

[Peter B]

On 24/05/2023 22:04, Tobias Frost wrote:

Package: sponsorship-requests
Followup-For: Bug #1034168
Control: tags -1 moreinfo

Hi Peter,

some review:
- d/postinst is not a place to post messages to users;

What do you suggest then?  I could ditch the postinst and put the text
into the man page, but users are probably less like to see it.
Note, this is upstream's postinst, not something I added myself.



  also is does
not have the #DEBHELPER# token. dh_installdeb(1)
(For that, the lintian override is wrong too)

Oops. Fixed, and removed the override



doc/pc.1 says:
".\" Text automatically generated by txt2man"

It seems that the source is missing (the input file for txt2man)?
It would be nice to have this and create the manpage at build time.
(Can you ask upstream to include the source file of the manpage?)


Raised upstream
https://github.com/graysky2/profile-cleaner/issues/39


Thanks for your review.
Uploaded the latest upstream version 2.45 to Mentors
https://mentors.debian.net/package/profile-cleaner/

Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386

[Justin B Rye]

Paul Gevers wrote:
> On 20-05-2023 16:21, Justin B Rye wrote:
> > When do we stop producing official Release Notes?
> 
> You mean when do we stop accepting changes to the Release Notes and stop
> building them? Once the release is EOL. However, I don't expect a lot of
> people to look for new versions after a while. You can still find the old
> release notes on-line.

I was just wondering if it was standard procedure for the last set of
Release Notes for a given arch to announce that that's what they are.
Given how arch qualification works, this could be tricky; but of
course we might still consider i386 a special case.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#995397: Dropped support for 32-bit Xen PV guests should be mentioned in i386 release notes

[Justin B Rye]

Richard Lewis wrote:
> But the user could be reading the release notes form perspective of
> the host, which could be running any arch, so i think safer to include
> in every arch's release-notes
> 
> 
>  32-bit Xen PV guests are not supported
>  
>The Linux kernel (from version 5.9) not longer support 32-bit
 ~~~  ~~
That should be "no longer supports".  In fact we might prefer to avoid
a parenthetical by saying

 From version 5.9, the Linux kernel no longer supports 32-bit

(5.9?  Is this a belated item for the bullseye Release Notes?)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386

[Justin B Rye]

RL wrote:
> Ansgar  writes:
>> On Fri, 2023-05-19 at 15:03 +0100, Steve McIntyre wrote:
>>> My plan is therefore to ship i386 installer images
>>> for bookworm as normal (including bookworm point releases going
>>> forwards), but to disable those builds for testing/trixie
>>> ~immediately after the release.
>>
>> I suggest to already document this in the release notes for bookworm,
>> possibly in Section 2.1 (Supported architectures) or a subsection in
>> Section 5 (Issues to be aware of for bookworm).
> 
> I suspect few would re-read 2.1 on upgrade... but is release-notes is
> the best place to document what new installs can use? (maybe doesnt
> matter as there wont be any new installs!)

I would expect a debian-announce message when it happens.

>> Maybe something along these lines:
>>
>> +---
>> | Debian 12 is expected to be the last Debian release providing
>> | full support for i386.  Debian 13 will only partially support
>> | i386 and no longer provide installation media for i386.
>> |
>> | We recommend hosts still running the i386 port to be upgraded
>> | to amd64.  Legacy i386 software can be run using multi-arch,
>> | chroot environments or containers.
>> +---
> 
> We already have a bit about i386 now meaning i686, but i think OK to
> keep separate as that one is bookworm, and this is for the future
> 
> Adding links to explain jargon and adding markup: im hope ive got the right
> arch-related entities right here...
> 
>   
>
> Bookworm is the last Debian release with full support for 
> 
>

Title lines don't need to be full sentences; this could be just
" support to be reduced from trixie".

>
> The next release, trixie, will not have full support for the
>  architecture, for example there will be no official
> installer. 
>

Do we need a mention of the reason (i.e. that an increasing number of
upstreams are no longer supporting it)?

Perhaps the angle the Release Notes should be taking on this is to
announce what's going to happen for dist-upgrades to trixie/forkie.
When do we stop producing official Release Notes?

>
> Debian recommends converting systems using the 
> architecture to the 64-bit
> PC architecture (known as amd64) before bookworm
> becomes unsupported: 

How about "https://wiki.debian.org/CrossGrading;? I was worried that it
might be a pre-systemd relic, but apparently not.

> most computers manufactured since 2000 can use
> amd64.

I'd have guessed later, given that the i386 arch held the lead in
popcon until 2012 ("https://www.debian.org/News/weekly/2012/17/;), but
this may just be because I use junk hardware.

>
>
> You can still run legacy 32-bit software on 64-bit systems using  url="SystemVirtualization">containers
> 
> or in  url="Multiarch/HOWTO">multi-arch
> chroots.
>
>  
> 
> (but shld use the  entity for wiki links)
> 
> Perhaps https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995397 (Xen no
> longer supports 32-bit Xen PV guests) also relevent to the last para.

It would make a relevant link for the "increasing number of upstreams"
I was mentioning.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1036293: [Pkg-pascal-devel] Bug#1036293: Bug#1036293: lazarus: LHelp needs CHM files to display online help

[Peter B]

On 18/05/2023 22:24, Mike Swanson wrote:

On Thu, 2023-05-18 at 22:28 +0200, Abou Al Montacir wrote:

Yes these files were removed from the source package. This was
intentional not only to remove lintian warning but also to force
using doct build during the lazarus build process.


You can find them in lazarus-doc-2.2 package. If any is missing,
please report it here.


Interesting, I do see the lcl.chm in /usr/share/doc/lazarus/... but
LHelp doesn't open it by default.  I recall that working on Debian 11's
version of the package.  I may have placed blame in the wrong place
then, but there is still a bug (it is annoying to navigate to that
file, even when I do know what's going on).

___
Pkg-pascal-devel mailing list
pkg-pascal-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel


Regarding the html help, looks to me that lazarus is looking in
/usr/share/doc/lazarus/2.2.0/index.html
a 2.2.0 folder, but the index is now in 2.2.6

Bug#1035106: grimripper

[Peter B]

I'm happy to have co-maintainers, but with less than a dozen packages in my list
I would hope to be able to keep it in good shape.

Bug#1035106: grimripper

[Peter B]

Hi Matthias,

I'd rather not remove asunder just yet. If I receive a bug report on grimripper,
the first thing I would want to do is run asunder alongside it to compare.

Also, until grimripper is uploaded we won't know for sure if it will build on 
all architectures,
and until I get access to a Salsa repository, how the CI will go.

I actually prefer the look of asunder and am therefore more likely to continue 
to use it over grimripper.
(I realise this is subjective)

Regards,
Peter

Bug#1035106: RFS: grimripper/3.0.0-1 [ITP 1035103] -- Graphical audio CD ripper and encoder

[Peter B]

Package renamed;


 * Package name : grimripper
   Version  : 3.0.0-1
   Upstream contact : Salamandar 
 * URL  : https://gitlab.gnome.org/Salamandar/GrimRipper
 * License  : GPL-2, CC0-1.0
 * Vcs  : TBD
   Section  : sound


The source builds the following binary packages:
  grimripper - Graphical audio CD ripper and encoder

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/grimripper/

Alternatively, you can download the package with 'dget' using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/g/grimripper/grimripper_3.0.0-1.dsc

Changes for the initial release:
 grimripper (3.0.0-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1035103)

Bug#1035106: RFS: grimripper/3.0.0-1 [ITP 1035103] -- Graphical audio CD ripper and encoder

[Peter B]

On Fri, 5 May 2023 17:59:01 +0200 Bastian Germann  wrote:
> On Sat, 29 Apr 2023 20:10:02 +0100 Peter Blackman wrote:
> > cdreaper is the Gtk3 fork of asunder
> > https://tracker.debian.org/pkg/asunder
> >
> > I would like to set up a packaging VCS on Salsa under the debian group,
> > but don't have the privilege to create an empty repository there myself.
>
> Why not put this under the Multimedia Team's umbrella?
>
>

I don't have any particular view where it should go, its just that I noticed 
asunder is in the debian group.

Bug#1035103: re : ITP: grimripper -- Graphical audio CD ripper and encoder

[Peter B]

Upstream have now renamed the project to GrimRipper

https://gitlab.gnome.org/Salamandar/GrimRipper

Bug#1035089: bookworm: gpgv must be installed for successful upgrades

[Justin B Rye]

Jonathan Wiltshire wrote:
> Attached patch adds a section in the upgrade guide to ensure gpgv is
> installed. Most users will have this if they have followed previous
> upgrade guidance not to skip releases. However, without it they will not
> be able to upgrade at all because the release signing key is not
> validated correctly.

A bit more explanation in the text would be helpful.  Mind you, users
who have been disregarding standard procedure to the extent of doing
leapfrog dist-upgrades seem unlikely to be paying close attention to
the procedure recommended in the bullseye-to-bookworm release notes!

I gather this is an extra precautionary step *before* the upgrade, but
is this "in case you've somehow accidentally ended up with only gpgv1
by accident" or are we expecting there to be users who have insisted
on sticking with the familiar v1 UI or something?  If there aren't,
it's hard to see why gpgv1 still exists, let alone still satisfying
apt's gpgv dependency even on bookworm... surely that has to be a bug?
If it isn't, it is at least confusing enough to need some explanation.

> +  
> +Check gpgv is installed
> +
> +  APT needs gpgv version 2 or greater to verify the 
> keys used
> +  to sign releases of . Ensure it is installed with:

Maybe something like:
APT needs gpgv version 2 or greater to verify the 
keys used
to sign releases of . Since gpgv1 technically satisfies 
the
dependency but is useful only in specialized circumstances, users may 
wish to
ensure the correct version is installed with:

> +
> +
> +$ apt install gpgv
> +
> +  

Requires root, so make it:
   # apt install gpgv
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1033847: Please update to upstream sources

[Richard B. Kreckel]

On 4/10/23 19:55, Sergio Durigan Junior wrote:

 fix_quote_readline_by_ref.patch, thanks to JuanJo Ciarlante (Closes: 
#739835)
 
 + avoid escaping 1st '~' (LP: #1288314)

 + avoid quoting if empty, else expansion without args only shows
   dirs (LP: #1288031)
 + replace double escaping to single (eg for completing file/paths
   with spaces)


Bingo! What I observe is reported in #825317.

I can confirm that adding a backslash before ~* in 
_quote_readline_by_ref() stops bash doing the very expensive NSS lookup.


Using the upstream version of the function has the same effect, of course.

In my humble opinion, this is a prime example that Debian (and Ubuntu) 
maintainers should be careful with their patches, especially in 
well-maintained packages.


Best wishes,
  -richard.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1034168: RFS: profile-cleaner/2.44-1 [ITP] -- Reduces browser profile size by cleaning their sqlite databases

[Peter B]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "profile-cleaner":

 * Package name : profile-cleaner
   Version  : 2.44-1
   Upstream contact : graysky 
 * URL  : https://github.com/graysky2/profile-cleaner
 * License  : Expat
 * Vcs  : N/A
   Section  : utils

I came across this package when searching for ideas to speed up Firefox.
Its by the same author as profile-sync-daemon.

The source builds the following binary packages:
  profile-cleaner - Reduces browser profile size by cleaning their sqlite 
databases

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/profile-cleaner/

Alternatively, you can download the package with 'dget' using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/p/profile-cleaner/profile-cleaner_2.44-1.dsc

Changes for the initial release:
 profile-cleaner (2.44-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1033413)

Regards,
  Peter Blackman

Bug#1033847: Please update to upstream sources

[Richard B. Kreckel]

Gabriel,

Times are changing. Many upstream maintainers don't do releases any more 
and instead rely on CI to maintain a good quality level. Unfortunately, 
this change often goes without announcement and unnoticed by package 
maintainers, leading to the situation you describe.


In cases like this, it might be best to check with upstream and ask them 
about their intentions. It may be that you'll never see a release tag 
again. Then, it would be best to just take the most up-to-date git version.


Regarding my hangs: It is because something's broken in my NIS 
(yellow-pages) setup (haven't fully analyzed yet). It turns out that, 
when doing tab completion, your patch 00-fix_quote_readline_by_ref.patch 
tries to match against ~*, which incurs a NIS look-up and that blocks.
The upstream version doesn't do that and it seems like the patch has 
never been applied.

Are you sure it is necessary?
If no: can it be removed?
If yes: has it been reported upstream and what was the response?

Best wishes,
   -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1031643: some tests …

[Andreas B. Mundt]

Hi,

after trying some installs with the provided initrd from
pu/bug-1031643, I observed the following:

 • The patch seems to work fine with 'hostname=somename' or
   'hostname?=somename' added to the boot parameters: The question is
   not asked respectively by default set to 'somename'.
 • However, I also ran an installation with the original, unpatched
   initrd and the boot parameters:
   'auto=true priority=critical hostname=somename url=tftp://192.168.122.1 
playbook=minimal.yml ---'
   That works fine too.  The pressed file is [1] with minor, unrelated
   changes.  So that's kind of confusing to me right now.   

Best regards,

  Andi


[1] 
https://salsa.debian.org/installer-team/netboot-assistant/-/blob/master/examples/preseed.cfg

Bug#1031643: bring hostname variable back

[Andreas B. Mundt]

Hi,

perhaps something like the following in [1] could be a fix:

diff --git a/env2debconf b/env2debconf
index 3032235..80394a4 100755
--- a/env2debconf
+++ b/env2debconf
@@ -3,6 +3,12 @@
 set -e
 export DEBIAN_FRONTEND=none
 . /usr/share/debconf/confmodule
+
+if [ "$(hostname)" != '(none)' ]; then
+   # the hostname has been set as boot param, bring it back here
+   hostname="$(hostname)"
+fi
+

I am not familiar with the code, but from checking the installer
console right at the beginning of the installation, this could
work.

Best regards,

  Andi


[1] https://salsa.debian.org/installer-team/preseed/-/blob/master/env2debconf

Bug#1033632: qa.debian.org: sourceforge redirector for debian/watch files fails with a 500 error

[Peter B]

I think this problem is now resolved.
The big red ERROR texts in the Watch column on my DDPO page are slowly going 
away.


Cheers,
Peter


On Wed, 29 Mar 2023 08:05:01 +0200 Christian Marillat  
wrote:
> Package: qa.debian.org
> Severity: normal
>
> Dear Maintainer,
>
> For several days sf.php no longer works:
>
> ,
> | uscan warn: In watchfile debian/watch, reading webpage
> | https://qa.debian.org/watch/sf.php/synfig/ failed: 500 Error
> `
>
> Christian
>
>

Bug#1033847: Please update to upstream sources

[Richard B. Kreckel]

The reproducible hang on my system turns out to be caused by Debian's 
00-fix_quote_readline_by_ref.patch. Without it, tab completion returns 
immediately. This patch is not there upstreams. Is it really needed?


It hangs at the line comparing $1 to ~*. Not sure what it does.

Bug#1033847: Please update to upstream sources

[Richard B. Kreckel]

Package: bash-completion
Version: 1:2.11-6
Severity: important

The current package version was taken from upstream somewhen in 2020. 
Since then, a lot has happened upstream.


Please update this package to the current upstream version. That version 
is reasonably maintained.


I got here (and classify this as 'important') because there seem to be 
really annoyhing bugs in the old version. I have a problem where file 
completion of ls reproducibly hangs for many seconds in the _filedir 
function. This does not happen when I swap 
/usr/share/bash-completion/bash_completion for the upstream version. I 
am not sure it's worth debugging this further, given the outdated state 
of this package in Debian.


  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1033666: icinga2-common: wrong executable in /usr/share/icinga2/include/plugins-contrib.d/systemd.conf

[Andreas B. Mundt]

Package: icinga2-common
Version: 2.13.6-2
Severity: normal
Tags: patch
X-Debbugs-Cc: a...@debian.org

Hi,

the configuration in '/usr/share/icinga2/include/plugins-contrib.d/systemd.conf'
contains a wrong executable in line 4:

command = [ PluginContribDir + "/check_systemd.py" ]

The plugin's path is '/usr/lib/nagios/plugins/check_systemd' (no .py) [1].

Thanks and best regards,

  Andi


[1] https://packages.debian.org/sid/all/monitoring-plugins-systemd/filelist
>From a807766be0459b0ac69afcb9584485bc43594d55 Mon Sep 17 00:00:00 2001
From: "Andreas B. Mundt" 
Date: Wed, 29 Mar 2023 19:59:15 +0200
Subject: [PATCH] Fix wrong executable name.

---
 itl/plugins-contrib.d/systemd.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/itl/plugins-contrib.d/systemd.conf 
b/itl/plugins-contrib.d/systemd.conf
index 4c0bbca1..236499bc 100644
--- a/itl/plugins-contrib.d/systemd.conf
+++ b/itl/plugins-contrib.d/systemd.conf
@@ -1,7 +1,7 @@
 /* Icinga 2 | (c) 2012 Icinga GmbH | GPLv2+ */
 
 object CheckCommand "systemd" {
-   command = [ PluginContribDir + "/check_systemd.py" ]
+   command = [ PluginContribDir + "/check_systemd" ]
 
arguments = {
"--unit" = {
-- 
2.39.2

Bug#1033624: obs-studio: Pipewire capture source not listed

[Richard B. Kreckel]

On 3/28/23 22:12, Kevin Otte wrote:

When I attempt to add a source to the current scene, I do not see the "Screen 
Capture (Pipewire)" option listed as demonstrated in the screenshot at 
https://www.linuxuprising.com/2021/06/obs-studio-27-released-with-wayland-and.html

As such, I am unable to capture the screen under Wayland (specifically, sway).


Do you have xdg-desktop-portal-gnome installed? (See bug #1031645.)

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033583: icingaweb2-module-graphite: /etc/icingaweb2/enabledModules has wrong owner/permissions

[Andreas B. Mundt]

Package: icingaweb2-module-graphite
Version: 1.2.2-1
Severity: normal
X-Debbugs-Cc: a...@debian.org

Dear Maintainer,

when installing an icinga monitoring host, I run into the problem that
/etc/icingaweb2/enabledModules is not writable by the web application.
Finishing the web based setup complained about missing permissions.

After modifying ownership and permissions like (comparable to the other 
files/directories there):

   drwxrws--- 2 www-data icingaweb2 4096 Mar 26 15:23 enabledModules 

it worked fine.

Thanks for maintaining icingaweb2-module-graphite,
best regards,

  Andi


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

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

Versions of packages icingaweb2-module-graphite depends on:
ii  icinga-php-library 0.10.1-1
ii  icinga-php-thirdparty  0.11.0-2
ii  icingaweb2 2.11.4-2

icingaweb2-module-graphite recommends no packages.

icingaweb2-module-graphite suggests no packages.

-- no debconf information

Bug#1033261: strawberry: Tag editing can corrupt media files

[Peter B]

Package: strawberry
Version: 1.0.14-1
Severity: important
Tags: upstream
X-Debbugs-Cc: pe...@pblackman.plus.com

A bug affecting the tag editor can cause possible corruption of media files.
Versions affected are all versions from 0.9.1 to the current latest 1.0.15.

The issue occurs whenever you edit and save both the tags and the album cover
with the embedded cover option in one operation. The embedded cover option is
off by default, and it only occurs if you also edit any tags in the same save
operation.
It is also possible that the issue only affects certain audio formats on
specific file-systems.

As a precaution, suggest to not use the tag editor at all until a new release
[16] is available.


https://github.com/strawberrymusicplayer/strawberry/issues/1158

Bug#1033108: unblock: di-netboot-assistant/0.76

[Andreas B. Mundt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: di-netboot-assist...@packages.debian.org, a...@debian.org
Control: affects -1 + src:di-netboot-assistant

Hi Release Team!

Please unblock package di-netboot-assistant

[ Reason ]
This upload fixes a few issues in examples and the documentation
provided by the package as well as the Salsa CI autopkgtest. 

[ Impact ]
Users will end up with examples that do not work with bookworm.

[ Tests ]
All changes have been tested by me in two unrelated environments.

[ Risks ]
Almost none.

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

[ Other info ]
Especially the changes in the example preseed file are due to the
bookworm release and surfaced recently.  Many thanks for all your work!

unblock di-netboot-assistant/0.76
diff -Nru di-netboot-assistant-0.75/config/ipxemenu.HEAD 
di-netboot-assistant-0.76/config/ipxemenu.HEAD
--- di-netboot-assistant-0.75/config/ipxemenu.HEAD  2022-12-21 
20:49:44.0 +0100
+++ di-netboot-assistant-0.76/config/ipxemenu.HEAD  2023-03-16 
17:05:12.0 +0100
@@ -30,7 +30,7 @@
 :customized
 kernel ${210:string}d-i/n-a/stable/amd64/linux initrd=initrd.gz \
   locale?=de_DE mirror/http/proxy?=http://192.168.122.1:3142/ \
-  pkgsel/include=etckeeper preseed/late_command="rm -fv /target/etc/ 
apt/apt.conf" ---
+  pkgsel/include=etckeeper preseed/late_command="rm -fv 
/target/etc/apt/apt.conf" ---
 initrd ${210:string}d-i/n-a/stable/amd64/initrd.gz
 boot
 
diff -Nru di-netboot-assistant-0.75/debian/changelog 
di-netboot-assistant-0.76/debian/changelog
--- di-netboot-assistant-0.75/debian/changelog  2022-12-21 20:49:44.0 
+0100
+++ di-netboot-assistant-0.76/debian/changelog  2023-03-16 17:05:12.0 
+0100
@@ -1,3 +1,11 @@
+di-netboot-assistant (0.76) unstable; urgency=medium
+
+  * Fix typo in preseeding example.
+  * Fix salsa CI package version check.
+  * Update preseeding example for bookworm.
+
+ -- Andreas B. Mundt   Thu, 16 Mar 2023 17:05:12 +0100
+
 di-netboot-assistant (0.75) unstable; urgency=medium
 
   * Bump Standards-Version to 4.6.2 (no changes needed).
diff -Nru di-netboot-assistant-0.75/debian/tests/std-run 
di-netboot-assistant-0.76/debian/tests/std-run
--- di-netboot-assistant-0.75/debian/tests/std-run  2022-12-21 
20:49:44.0 +0100
+++ di-netboot-assistant-0.76/debian/tests/std-run  2023-03-16 
17:05:12.0 +0100
@@ -1,9 +1,9 @@
-#!/bin/sh
+#!/usr/bin/bash
 
 ## Make sure package and script version are identical:
 PV="$(dpkg-query -f='${Version}\n' -W di-netboot-assistant)"
 SV="$(di-netboot-assistant -V | cut -d' ' -f2)"
-if [ "${PV%%~*}" != "$SV" ] ; then
+if [ "${PV%%[^.0-9]*}" != "$SV" ] ; then
 echo "E: Version of package ($PV) and script ($SV) do not match!"
 exit 1
 else
diff -Nru di-netboot-assistant-0.75/di-netboot-assistant 
di-netboot-assistant-0.76/di-netboot-assistant
--- di-netboot-assistant-0.75/di-netboot-assistant  2022-12-21 
20:49:44.0 +0100
+++ di-netboot-assistant-0.76/di-netboot-assistant  2023-03-16 
17:05:12.0 +0100
@@ -26,7 +26,7 @@
 
 # -- Declare the constants --- #
 PACKAGE_NAME=di-netboot-assistant
-PACKAGE_VERSION=0.75
+PACKAGE_VERSION=0.76
 
 # -- Initialize the global variables - #
 OFFLINE=false
diff -Nru di-netboot-assistant-0.75/examples/preseed.cfg 
di-netboot-assistant-0.76/examples/preseed.cfg
--- di-netboot-assistant-0.75/examples/preseed.cfg  2022-12-21 
20:49:44.0 +0100
+++ di-netboot-assistant-0.76/examples/preseed.cfg  2023-03-16 
17:05:12.0 +0100
@@ -30,6 +30,10 @@
 d-i debian-installer/locale string en_US
 d-i keyboard-configuration/xkb-keymap select us
 
+## netcfg will choose an interface that has link if possible. This makes it
+## skip displaying a list if there is more than one interface:
+#d-i netcfg/choose_interface select auto
+
 ## Use hostname assigned by DHCP:
 d-i netcfg/get_hostname string unassigned-hostname
 d-i netcfg/get_domain string unassigned-domain
@@ -37,7 +41,13 @@
 ## Skip root account:
 d-i passwd/root-login boolean false
 
+## If non-free firmware is needed for the network or other hardware, you can
+## configure the installer to always try to load it, without prompting. Or
+## change to false to disable asking.
+d-i hw-detect/load_firmware boolean true
+
 ### Apt setup
+d-i apt-setup/non-free-firmware boolean true
 d-i apt-setup/non-free boolean true
 d-i apt-setup/contrib boolean true
 
@@ -111,6 +121,8 @@
   echo "ssh-rsa 
B3NzaC1yc2EDAQABAAABAQC6tlRPOPBdxAJKLCNH+7S3fHhxzu64HViJQDFZbbI+Mbd+wwx6fe7ba1XZ8TXcFGmipHBYiOVaGMXIeJvGsEK3P1ULXNcNygrXl6HzjKDyL+iX3e7pls

Bug#825222: lintian: please allow debian/source/timestamps in unknown-file-in-debian-source

[Peter B]

On Sat, 18 Feb 2023 11:45:05 +0100 Abou Al Montacir  
wrote:

> >
> > Just affecting two packages is IMHO a valid case for lintian
> > overrides.
>
> I may agree, but I failed to find the right syntax to override this error.


Hi Abou,

the syntax is just to have the error string, and nothing else on the line, ie.

# In 3.0.0+dfsg-5 elbrus added fp-fix-timestamps that expects 
d/source/timestamps
# lintian bug: http://bugs.debian.org/825222
unknown-file-in-debian-source


Cheers,
Peter

Bug#1025350: qt6ct: Font changes are not saved in configuration file

[Peter B]

It seems the problem only occurs if a style sheet is selected.

Sadly, not fixed in release 0.8

Bug#1025350: qt6ct: Font changes are not saved in configuration file

[Peter B]

Raised upstream
https://github.com/trialuser02/qt6ct/issues/25

I've noticed that the font settings are saved if one just hits [OK],
but lost if one hits [Apply] first.

Bug#1032020: [pkg-apparmor] Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.

[Guillaume B.]

Hi,

Thanks for clearing it up.

I might just take time and find that faulty profile if it ever existed.

Thanks for clearing everything up.

Cheers

On Wed, Mar 1, 2023, 09:48 intrigeri  wrote:

> Control: tag -1 + unreproducible
> Control: severity -1 minor
>
> Hi,
>
> Guillaume B. (2023-02-28):
> > Installing fresh sid profiles with both previously stated packages
> (version
> > 3.0.8-3 and 1.35 respectively), I have not seen that specific mistake
> made.
> >
> > It may have come from a loose AppArmor profile but, just to be sure, no
> > such open "/** r," found in latest sid-provided
> > apparmor-profiles/apparmor-profiles-extra Chromium AppArmor profile.
>
> I've looked at the Git history of the relevant apparmor* packages and
> found no trace of them having ever distributed a Chromium profile
> with a "/** r," rule.
>
> > dpkg-query: no path found matching pattern
> /etc/apparmor.d/usr.bin.chromium
>
> This shows that no Debian package is currently maintaining that file.
>
> Frankly, I have no idea how this rule landed on your filesystem, but
> I really don't see how this problem could have been directly caused by
> a Debian package or upgrade.
>
> Cheers,
> --
> intrigeri
>

Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.

[Guillaume B.]

Start quote -> "
You mean Debian maintenance team, right? If you pulled in an Ubuntu
apparmor package, that's a different story (and we should close this
bug). If you're using Debian's apparmor-profiles package, then the bug
and fix should go there. Although, if you're pulling in an Ubuntu
package to get some kind of apparmor protection that Debian doesn't
have, you also might want to open a wishlist bug on the Debian package
asking for the feature so you don't have to mix-and-match packages
across different distributions."

   ///

I am, honestly, as confused as you. I've had profiles from the
apparmor-profiles and apparmor-profiles-extra packages for a long time.

This time around, though, I did not have either packages installed all the
while having active apparmor.d profiles.

Installing fresh sid profiles with both previously stated packages (version
3.0.8-3 and 1.35 respectively), I have not seen that specific mistake made.

It may have come from a loose AppArmor profile but, just to be sure, no
such open "/** r," found in latest sid-provided
apparmor-profiles/apparmor-profiles-extra Chromium AppArmor profile.

Cheers

On Mon, Feb 27, 2023, 20:45 Andres Salomon  wrote:

> Control: reassign -1 apparmor-profiles
>
>
>
> On Mon, Feb 27 2023 at 08:15:37 PM +0100, Guillaume B.
>  wrote:
> > Hi,
> >
> > It seems that the previous emails in our exchange got nuked out my
> > account so apologies for not being able to reply using the usual
> > channels.
> >
> > The command 'find /etc/apparmor* -name "*hromium*" | xargs dpkg -S'
> > returns the following -> "dpkg-query: no path found matching pattern
> > /etc/apparmor.d/usr.bin.chromium
> > lightdm: /etc/apparmor.d/abstractions/lightdm_chromium-browser"
> >
> >   ///
> >
> > I'm using AppArmor profiles found in the "apparmor-profiles" package.
> > Having recently updated from stable, I was able to keep the profiles
> > without the package being installed; i.e., the update couldn't have
> > come from an apparmor-profile package update.
>
>
> Ah, okay, that makes more sense. Reassigning to the apparmor-profiles
> package, then.
>
>
> >
> > Dealing with the issue, I have not made a backup of the updated
> > Chromium AppArmor profile but simply did some file comparison and
> > reverted to a previous profile, nuking the updated profile in the
> > copying process.
> >
> > The "updated" AppArmor profile was dated either january or february
> > of this year and had been modified by an Ubuntu email.
> >
> > TLDR; There was an update to the Chromium AppArmor profile, not sure
> > how, but it happened.
> >
> > I might just take it up with the Ubuntu Chromium AppArmor profile
> > maintenance team, in which case, sorry to have wasted your time.
> >
> > Regards
>
>
>
> You mean Debian maintenance team, right? If you pulled in an Ubuntu
> apparmor package, that's a different story (and we should close this
> bug). If you're using Debian's apparmor-profiles package, then the bug
> and fix should go there. Although, if you're pulling in an Ubuntu
> package to get some kind of apparmor protection that Debian doesn't
> have, you also might want to open a wishlist bug on the Debian package
> asking for the feature so you don't have to mix-and-match packages
> across different distributions.
>
>
>
>

Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.

[Guillaume B.]

Hi Andres,

Will take care of it tonight.

Regards

On Sun, Feb 26, 2023, 22:58 Andres Salomon  wrote:

> Hi,
>
> I'm a bit confused by this bug report, as chromium doesn't include any
> apparmor profiles.
>
> Please run the following commands to hopefully figure out what package
> is actually providing the profile:
>
> find /etc/apparmor* -name "*hromium*" | xargs dpkg -S
>
> Thanks,
> Andres
>
> On Sun, Feb 26 2023 at 05:48:38 PM +0100, Will B. 
> wrote:
> > Package: chromium
> > Version: 110.0.5481.177-1
> > Severity: important
> > Tags: upstream
> > X-Debbugs-Cc: ksu...@gmail.com
> >
> > Dear Maintainer,
> >
> > Before I begin, the Chromium AppArmor profile in Sid was updated
> > after apt-get
> > update && apt-get upgrade.
> > Please redirect to relevant authority if Chromium reportbug is not
> > the right
> > source.
> >
> >///
> >
> > * What led up to the situation? -> Chromium AppArmor profile update
> > after apt-
> > get update && apt-get upgrade.
> > * What exactly did you do (or not do) that was effective (or
> > ineffective)? ->
> > fixed the issue by adding a missing "/" to the profile.
> > * What was the outcome of this action? -> The Chromium AppArmor
> > profile
> > restricted access as it should have done.
> > * What outcome did you expect instead? -> None, fix fixed it.
> >
> >   ///
> >
> > Hi,
> >
> > After a Chromium Sid update in which the AppArmor profile was updated
> > (last
> > date -> 02/07/2023),
> > a missing "/" opened up browsing to the whole system i.e. -> "/** r,"
> > instead
> > of "/**/ r,".
> > Switching to the "enclosed" stars symbol fixes the issue.
> >
> > Regards
> >
> >
> > -- System Information:
> > Debian Release: bookworm/sid
> >   APT prefers testing
> >   APT policy: (990, 'testing'), (50, 'unstable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 6.1.0-3-amd64 (SMP w/12 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 chromium depends on:
> > ii  chromium-common
> > 110.0.5481.177-1
> > ii  libasound2   1.2.8-1+b1
> > ii  libatk-bridge2.0-0   2.46.0-5
> > ii  libatk1.0-0  2.46.0-5
> > ii  libatomic1   12.2.0-14
> > ii  libatspi2.0-02.46.0-5
> > ii  libbrotli1   1.0.9-2+b6
> > ii  libc62.36-8
> > ii  libcairo21.16.0-7
> > ii  libcups2 2.4.2-1+b2
> > ii  libdbus-1-3  1.14.6-1
> > ii  libdouble-conversion33.2.1-1
> > ii  libdrm2  2.4.114-1
> > ii  libevent-2.1-7
> > 2.1.12-stable-5+b1
> > ii  libexpat12.5.0-1
> > ii  libflac121.4.2+ds-2
> > ii  libfontconfig1   2.14.1-4
> > ii  libfreetype6 2.12.1+dfsg-4
> > ii  libgbm1  22.3.3-1
> > ii  libgcc-s112.2.0-14
> > ii  libglib2.0-0 2.74.5-1
> > ii  libgtk-3-0   3.24.36-4
> > ii  libjpeg62-turbo  1:2.1.5-2
> > ii  libjsoncpp25 1.9.5-4
> > ii  liblcms2-2   2.14-1+b1
> > ii  libminizip1  1.1-8+b1
> > ii  libnspr4 2:4.35-1
> > ii  libnss3  2:3.87.1-1
> > ii  libopenjp2-7 2.5.0-1+b1
> > ii  libopus0 1.3.1-3
> > ii  libpango-1.0-0   

Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.

[Will B.]

Package: chromium
Version: 110.0.5481.177-1
Severity: important
Tags: upstream
X-Debbugs-Cc: ksu...@gmail.com

Dear Maintainer,

Before I begin, the Chromium AppArmor profile in Sid was updated after apt-get
update && apt-get upgrade.
Please redirect to relevant authority if Chromium reportbug is not the right
source.

   ///

* What led up to the situation? -> Chromium AppArmor profile update after apt-
get update && apt-get upgrade.
* What exactly did you do (or not do) that was effective (or ineffective)? ->
fixed the issue by adding a missing "/" to the profile.
* What was the outcome of this action? -> The Chromium AppArmor profile
restricted access as it should have done.
* What outcome did you expect instead? -> None, fix fixed it.

  ///

Hi,

After a Chromium Sid update in which the AppArmor profile was updated (last
date -> 02/07/2023),
a missing "/" opened up browsing to the whole system i.e. -> "/** r," instead
of "/**/ r,".
Switching to the "enclosed" stars symbol fixes the issue.

Regards


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-3-amd64 (SMP w/12 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 chromium depends on:
ii  chromium-common  110.0.5481.177-1
ii  libasound2   1.2.8-1+b1
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libatomic1   12.2.0-14
ii  libatspi2.0-02.46.0-5
ii  libbrotli1   1.0.9-2+b6
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libcups2 2.4.2-1+b2
ii  libdbus-1-3  1.14.6-1
ii  libdouble-conversion33.2.1-1
ii  libdrm2  2.4.114-1
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libexpat12.5.0-1
ii  libflac121.4.2+ds-2
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libgbm1  22.3.3-1
ii  libgcc-s112.2.0-14
ii  libglib2.0-0 2.74.5-1
ii  libgtk-3-0   3.24.36-4
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjsoncpp25 1.9.5-4
ii  liblcms2-2   2.14-1+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libopenjp2-7 2.5.0-1+b1
ii  libopus0 1.3.1-3
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpng16-16  1.6.39-2
ii  libpulse016.1+dfsg1-2+b1
ii  libre2-9 20220601+dfsg-1+b1
ii  libsnappy1v5 1.1.9-2
ii  libstdc++6   12.2.0-14
ii  libwebp7 1.2.4-0.1
ii  libwebpdemux21.2.4-0.1
ii  libwebpmux3  1.2.4-0.1
ii  libwoff1 1.0.2-2
ii  libx11-6 2:1.8.3-3
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxkbcommon01.5.0-1
ii  libxml2  2.9.14+dfsg-1.1+b3
ii  libxnvctrl0  525.85.05-1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxslt1.1   1.1.35-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  

Bug#1031645: gnome-shell should depend on xdg-desktop-portal-gnome

[Richard B. Kreckel]

On 2/19/23 20:31, Simon McVittie wrote:

[...]
* gnome-core, a GNOME system with essential utilities like a login prompt,
   preferences, a file manager and a text editor, which Depends on
   gnome-session, and also on xdg-desktop-portal-gnome specifically;


Okay, you managed to convince me that gnome-core should pull it in, not 
gnome-shell.


(For some weird reason gnome-core was not installed on my machines 
although I've been using them with GNOME for ages.)


I'm gonna close this bug then.

  -richy.

Bug#1031645: gnome-shell should depend on xdg-desktop-portal-gnome

[Richard B. Kreckel]

Package: gnome-shell
Version: 43.2-2

The package should pull in xdg-desktop-portal-gnome.

After all, "GNOME Shell is the defining technology of the GNOME 3 user 
experience." A system without xdg-desktop-portal-gnome installed will 
not provide some of this experience, like the ability to do screen 
captures (PipeWire) in OBS studio, etc.


Related: https://bugzilla.redhat.com/show_bug.cgi?id=2074189

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1031502: python3-matplotlib: Missing documentation package

[B Thomas]

Package: python3-matplotlib
Version: 3.6.3-1+b1
Severity: normal
X-Debbugs-Cc: balbirtho...@hotmail.com

Dear Maintainer,

The Matplotlib documentation package seems to have been removed from
testing distribution. Could you please bring it back.

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

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

Versions of packages python3-matplotlib depends on:
ii  libc6   2.36-8
ii  libfreetype62.12.1+dfsg-4
ii  libgcc-s1   12.2.0-14
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  libqhull-r8.0   2020.2-5
ii  libstdc++6  12.2.0-14
ii  python-matplotlib-data  3.6.3-1
ii  python3 3.11.1-3
ii  python3-contourpy   1.0.7-1+b1
ii  python3-cycler  0.11.0-1
ii  python3-dateutil2.8.2-1
ii  python3-fonttools   4.38.0-1+b1
ii  python3-kiwisolver  1.4.4-1+b1
ii  python3-numpy [python3-numpy-abi9]  1:1.24.1-2+b1
ii  python3-packaging   23.0-1
ii  python3-pil 9.4.0-1.1+b1
ii  python3-pil.imagetk 9.4.0-1.1+b1
ii  python3-pyparsing   3.0.9-1
ii  python3-six 1.16.0-4

Versions of packages python3-matplotlib recommends:
ii  python3-tk  3.10.8-1

Versions of packages python3-matplotlib suggests:
pn  cm-super-minimal 
ii  dvipng   1.15-1.1+b1
ii  ffmpeg   7:5.1.2-2
pn  fonts-staypuft   
ii  ghostscript  10.0.0~dfsg-9+b1
ii  gir1.2-gtk-3.0   3.24.36-3
pn  inkscape 
ii  ipython3 8.5.0-4
ii  librsvg2-common  2.54.5+dfsg-1
pn  python3-cairocffi
ii  python3-gi   3.42.2-3+b1
ii  python3-gi-cairo 3.42.2-3+b1
pn  python3-gobject  
ii  python3-pyqt55.15.9+dfsg-1
ii  python3-scipy1.10.0-4
pn  python3-sip  
ii  python3-tornado  6.2.0-3
ii  texlive-extra-utils  2022.20230122-1
ii  texlive-latex-extra  2022.20230122-1

-- no debconf information

Bug#1025350: qt6ct: Font changes are not saved in configuration file

[Peter B]

Hi,

I can reproduce the problem now.
Font changes are not stored in the configuration file when qt6ct exits.

A workaround would be to edit this file manually.
config/qt6ct/qt6ct.conf

I don't think this is anything to do with the Debian packaging, as the problem 
occurs
in Arch Linux too. I'll raise it upstream.

==


On 15/02/2023 00:22, Christopher Cramer wrote:


qt5ct does not work either.



Working fine here, I suggest you raise that as a separate bug.


Cheers,
Peter

Bug#1025350: qt6ct: changing font has no effect on GNOME

[Peter B]

Hi Christopher,

It has occurred to me that you might not have seen my follow up messages if you 
are not subscribed to the bug.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025350

Please comment on the bug report if you have any more useful information on the 
problem.

I had said on Dec 3rd 

    "Just tested font changing for qt6ct itself and qtcreator, and fonts are 
changing just fine,
    so I can't reproduce this problem.

    However, I'm using Xfce, so maybe this is a Gnome issue?
    Fonts do take a little while to change though.

    Is qt5ct working for you?"

and

    "One further thought.

    I assume you are using TrueType fonts.
    Which specific font(s) are you having the issue with?

    I'm using liberation fonts here.  {fonts-liberation2}"


Regards,
Peter B

Bug#968495: ITP: c-evo-dh -- C-evo: Distant Horizon, Empire building game

[Peter B]

New Upstream version

   Package name : c-evo-dh
   Version  : 1.7-1
   Upstream contact : Peter 
   URL  : https://sourceforge.net/projects/c-evo-eh/
   License  : CC-BY-3.0, CC-BY-SA-3.0-US, CC0-1.0, GPL-2+
   Vcs  : https://salsa.debian.org/PeterB/c-evo-dh
   Section  : games



Changes since 1.6

  Update Tutorial doc
  Enlarge Buy button on City Screen
  Improve Spanish and Portuguese translations
  Fix regression in multi-buttons on Free Player Setup form.
  Remove writelns not in debug blocks


Also, changes to packaging.
  Add .gitignore
  Update gbp.conf

Removed conflicts/breaks & QT5 binary packages following FTP Master's reject.

Bug#1030042: opentracker: Misleading README.Debian, compile flags only allow use with whitelist profile

[Andreas B. Mundt]

Package: opentracker
Version: 0.0~git20210823.110868e-2+b1
Severity: normal
X-Debbugs-Cc: a...@debian.org

Dear Agathe,

from the /usr/share/doc/opentracker/README.Debian, I thougth that it is possible
to switch from white- to blacklist or use no list at all (public tracker):  

| By default, the tracker is run in "private" mode using a whitelist access.
| You need to explicitly list all of the torrent hashes that you want to 
announce
| into the /etc/opentracker/whitelist.txt file.
|
| If you want to switch to "public" mode, allowing to announce any torrent hash,
| you can comment the "access.whitelist" option in
| /etc/opentracker/opentracker.conf.

However, especially the last paragraph seems to be wrong, running without 
"access.whitelist" does not allow any trackers (like an empty whitelist).  

>From upstream's documentation [1]:

| Some variables in opentracker's Makefile control features and behaviour of 
opentracker. Here they are:
| [...]
| You can change that behaviour by enabling ONE of -DWANT_ACCESSLIST_BLACK or 
-DWANT_ACCESSLIST_WHITE.
   ^
So, it looks like the use cases whitelist tracker, blacklist tracker and open 
tacker
are defined by compile time options and can't be modified later when invoking 
the 
program.  Comments in the config file state:

#  It is pointless and hence not possible to compile black AND white
#  listing, so choose one of those options at compile time.
   ^^^
Several tests and package rebuilds with different compile flags in 
debian/rules have confirmed this. 

Hm. It would of course be great to be able to modify the mode with options / 
config file. 

Best regards,

  Andi


[1] http://erdgeist.org/arts/software/opentracker/

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

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

Versions of packages opentracker depends on:
ii  libc6  2.36-8
ii  libowfat0  0.32-4
ii  zlib1g 1:1.2.13.dfsg-1

opentracker recommends no packages.

opentracker suggests no packages.

-- Configuration Files:
/etc/opentracker/whitelist.txt changed:
a2a3a73e80da24ab2a4ac2a0624bdefb9b1fa20a


-- no debconf information

Bug#1030041: release-notes: offer deb22 format for apt sources

[Justin B Rye]

Package: release-notes
Severity: minor

The familiar "single-line" format for apt sources in .list files is,
in theory, gradually being deprecated in favour of the deb822 format
in .sources files[1].  We can expect the old format to be supported
for a few releases yet - for a start as I understand it we're still
generating new installs with /etc/apt/sources.list - but we ought to
at least take the first step of offering examples of the preferred
format.

Places that use the old format:

 old-stuff.dbk
  #old-sources "Checking your APT source-list files"

 upgrading.dbk throughout but especially
  #upgrade-process "Preparing APT source-list files"

 ...anywhere else?

[1] https://lists.debian.org/debian-devel/2021/11/msg00026.html
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1030040: release-notes: usrmerge and dist-upgrade

[Justin B Rye]

Package: release-notes
Severity: normal

We've already given users notice in previous release-notes that the
unmerged format won't be supported on bookworm; now, any users who
haven't yet installed usrmerge will get it automatically pulled in
during the dist-upgrade.  The release-notes ought to mention the
recommended way of handling this.

Normally I'd say this was the kind of thing you're better off doing as
a separate sysadmin task *before* the day you do the dist-upgrade.  On
the other hand, bookworm's usrmerge has a few cornercase fixes[1] that
release-notes readers who are using obscure btrfs features or the like
might want to take advantage of.  So which approach should we be
recommending to unmerged upgraders?

 a) Doing a combined dist-upgrade and usrmerge is so reliable that
everybody should simply do it this way (thus using the latest
usrmerge).

 b) Users should check the list of bugfixes and if none of them apply
they should do the merge on bullseye before the dist-upgrade;
on the other hand if they want to use the bookworm usrmerge
they should let the dist-upgrade pull it in.

 c) Combined dist-upgrade and usrmerge is not certified safe, so if
you need bookworm usrmerge it's better to upgrade your
sources, pull in just usrmerge and its dependencies (plus
perhaps the new apt, linux-image, etc), reboot, and *then*
carry on with the rest of the dist-upgrade.

 d) Something else.

Whatever advice we end up giving, the same section could also mention
the detail that if you don't want all of usrmerge's dependencies
installed - not that there are many - you can replace it with the
special dummy package usr-is-merged on bookworm.

(I have done a couple of plain-sailing trial dist-upgrades, but my
testbed systems are already merged so I haven't had a chance to check
the various options.)

[1] 
"https://metadata.ftp-master.debian.org/changelogs//main/u/usrmerge/usrmerge_35_changelog;
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On Wed, 11 Jan 2023 09:43:31 +0100 Sylvestre Ledru 
 wrote:
go: could not create module cache: mkdir /sbuild-nonexistent: permission 
denied

To make this go away, the package must Build-Depend on dh-golang.

However, that does not seem to be enough. The way subpackages are 
fetched or not during build is not very clear to me. How did you put 
together the 2.9.0 source package?


  -richard.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028561: /usr/bin/update-alternatives: Counting mistake in terminal returns

[Daniel B]

Package: dpkg
Version: 1.21.9kali1
Severity: minor
File: /usr/bin/update-alternatives
X-Debbugs-Cc: p2...@icloud.com

Hey there,

when doing "sudo update-alternatives --config x-session-manager" the ruturn is 
(on German, sorry...):

> Es gibt 3 Auswahlmöglichkeiten für die Alternative x-session-manager (welche 
> /usr/bin/x-session-manager bereitstellen).
> 
>   Auswahl  Pfad  Priorität Status
> 
> * 0/usr/bin/startxfce450automatischer Modus
>   1/usr/bin/startplasma-x11   40manueller Modus
>   2/usr/bin/startxfce450manueller Modus
>   3/usr/bin/xfce4-session 40manueller Modus
> 
> Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
> oder geben Sie die Auswahlnummer ein: 

It tells me there's 3 choices. But it's 4. It would be 3 *alternatives* to my 
current *choice*.
It should be something like "Es gibt 3 alternative Auswahlmöglichkeiten", 
adding "alternative",
which would translate to "There are 3 alternative choices [...]".

(Freshly installed Kali Linux, was going to switch from xfce to plasma)

Thx for ur work :)


-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See .

-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2022.4
Codename:   kali-rolling
Architecture: x86_64

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-4
ii  liblzma5 5.2.7-0.1
ii  libselinux1  3.4-1+b3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-4.1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.5.4
pn  debsig-verify  

-- no debconf information

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On 1/9/23 23:26, Sylvestre Ledru wrote:

Le 08/01/2023 à 00:46, Richard B. Kreckel a écrit :


2) Based on mozillavpn_2.9.0-1.debian.tar.xz, apply some changes to 
debian/ directory:
   a) -DBUILD_TESTING=OFF to dh_auto_configure argument in 
debian/rules (without it it FTBFS trying to run some tests and that is 
also in upstream's rules file)
   d) change rm -rf debian/mozillavpn/etc/opt/chrome to rm -rf 
debian/mozillavpn/etc/opt in debian/rules so purge won't remove 
/etc/opt/ since there's nothing in there anyway
   c) Add packages python3-click and python3-jinja2 to Build-Depnds in 
debian/control (without these, it FTBFS)
   d) remove libqt6* and qt6-qpa-plugins dependencies in 
debian/control (see #1026957).



I tried with these changes but I am getting:


/<>/src/connectionbenchmark/benchmarktaskdownload.cpp:50:4: 
error: #error Check if QT added support for QDnsLookup::lookup() on Android
    50 | #  error Check if QT added support for QDnsLookup::lookup() on 
Android

   |    ^
[ 56%] Building CXX object 
src/CMakeFiles/mozillavpn.dir/connectionbenchmark/benchmarktaskping.cpp.o


rings a bell?


Sure.

Mozillavpn 2.9.0 #errors out there if QT_VERSION >= 0x060400.

The current qt6-base-dev in the archive is 6.4.2+dfsg~rc1-3 and that 
#defines QT_VERSION 060402. Hence, #error...


You must have been compiling Mozillavpn version 2.9.0, and not 2.12.0, 
as I recommended! (It was Andrea Marchesini who changed this upstream 
2022-10-06.)


All my best,
  -richard.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On 1/9/23 10:38, Sylvestre Ledru wrote:

Or just push a fork on github. I can take it for there :)


For work-related reasons this isn't going to happen the next few weeks.

Can you, please, update to 1.12.0 and include the minor described fixes 
to debian/*? It should work, afaict.


  -richard.

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On 1/8/23 12:36, Richard B. Kreckel wrote:

I am unfamiliar with GitLab. Sorry.


Well, then I thought that could give it a try...

Is there a simple walk-through what to do to create salsa MRs in a case 
like this package?


(I've spent the whole Sunday now and I'm giving up frustrated by the 
existing documentation now.)


  -richard.

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

Szlvestre,

On 1/8/23 00:54, Sylvestre Ledru wrote:
Could you please submit a MR here ? 
https://salsa.debian.org/sylvestre/mozillavpn


I will be happy to upload it then


Is that really necessary?
I am unfamiliar with GitLab. Sorry.

  -richard.

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

Could we just upgrade to version 1.12.0 for sid/bookworm, please?

Right now, the mozillavpn package is slated for removal from bookworm. I 
would be very happy if we could avoid this.


After some tinkering, I got v1.12.0 to work on sid/bookworm. Here's what 
it takes:


1) Create mozillavpn_2.12.0.orig.tar.gz
   a) download 
https://github.com/mozilla-mobile/mozilla-vpn-client/archive/refs/tags/v2.12.0.tar.gz
   b) unpack it (and discover that directories under 3rdparty/ subdir 
are empty)
   c) drop the contents of 
https://github.com/mozilla/glean/archive/refs/tags/v52.0.0.tar.gz into 
3rdparty/glean/
   d) drop the contents of 
https://github.com/WireGuard/wireguard-tools/archive/refs/heads/master.zip 
into 3rdparty/wireguard-tools/


2) Based on mozillavpn_2.9.0-1.debian.tar.xz, apply some changes to 
debian/ directory:
   a) -DBUILD_TESTING=OFF to dh_auto_configure argument in debian/rules 
(without it it FTBFS trying to run some tests and that is also in 
upstream's rules file)
   d) change rm -rf debian/mozillavpn/etc/opt/chrome to rm -rf 
debian/mozillavpn/etc/opt in debian/rules so purge won't remove 
/etc/opt/ since there's nothing in there anyway
   c) Add packages python3-click and python3-jinja2 to Build-Depnds in 
debian/control (without these, it FTBFS)
   d) remove libqt6* and qt6-qpa-plugins dependencies in debian/control 
(see #1026957).


This builds for me on amd64.

An alternative to step 1) above is of course to clone from 
https://github.com/mozilla-mobile/mozilla-vpn-client.git and then git 
submodule update --init. That only adds some stuff not needed for Debian 
into the orig.tar.gz.


For the record, I've placed copies of the files at 
https://in.terlu.de/~kreckel/mozillavpn/.


Also, debian-release should be contacted because of the build failure on 
mipsel and mpis64el. It makes little sense to insist on these 
architectures if upstream doesn't care.


Please decide how to proceed and let me know if I can help in any way.

  -richard.
--
   .''`.  Richard B. Kreckel
  : :' :  
  `. `'   
`-<http://in.terlu.de/~kreckel/>

Bug#1028061: apertium-hbs-eng: Errors shown against many translated words

[Peter B]

On 06/01/2023 13:57, Tino Didriksen wrote:

Agreed, direction eng-hbs doesn't look good. Direction hbs-eng looks much 
better.

It is clear from https://github.com/apertium/apertium-hbs-eng/tree/master/texts that this pair was developed with 
hbs-eng in mind, and eng-hbs probably shouldn't have been published. And 
https://github.com/apertium/apertium-hbs-eng/blob/master/modes.xml corroborates this with the comment that eng-hbs was 
only installed for debugging.


 As for this bug, I think best I can do in the short term is remove the 
eng-hbs direction.



Thanks for your prompt response. I was wondering myself if the eng-hbs 
direction was problematic.

Would it be possible to leave it in for devs debugging, but hide it from the 
'apertium -l' output?
If not, dropping it seems the best option to me too.

Either would be less confusing to new users.

Thanks again,
Peter