Bug#1072718: [Pkg-pascal-devel] Bug#1072718: lazarus: Lazarus fails to compile itself

2024-06-14 Thread Peter B

On 07/06/2024 02:26, Bas van Besouw wrote:

Package: lazarus
Version: 3.0+dfsg1-8
Severity: serious
Tags: ftbfs


Hi Bas,

some general points about bug reporting;

1)  The tag ftbfs is used when the package does not build from the 
debian source (using debuild or whatever)


https://buildd.debian.org/status/package.php?p=lazarus
Lazarus is building fine from source.

When a compiler fails to build something locally, that is not ftbfs.
If the package really was ftbfs, there would be nothing for users to 
install.



2)  The severity serious means a "severe violation of Debian policy".

https://www.debian.org/Bugs/Developer#severities

Lazarus failing to rebuild the IDE, but generally working fine apart 
from that, is unfortunate, and definitely

a [Normal] bug, but it is hardly a "severe violation of Debian policy".


Regards,
Peter

P.S.   I can reproduce this problem too, with both 3.0 & 3.4 Debian 
packages,

  but rebuilding the IDE works with the Arch Linux 3.4 package.



Bug#1073207: Subject: RFS: cevomapgen/34-1 -- External Map Generator for C-Evo

2024-06-14 Thread Peter B

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : cevomapgen
   Version  : 34-1
   Upstream contact : Peter Blackman 
 * URL  : https://sourceforge.net/projects/cevomapgen/
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/PeterB/cevomapgen
   Section  : games

The source builds the following binary packages:

  c-evo-map-gen - 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_34-1.dsc


Changes since the last upload:

 cevomapgen (34-1) unstable; urgency=medium
 .
   * New upstream release.
   * Change watch file to use git
   * Standards 4.7.0  (No changes)
   * Use Static-Built-Using in d/control
   * Change build dependency on fpc to fp-compiler
   * Drop d/install & d/docs (now uses upstream Makefile install target)
   * Team maintained

Regards,
--
  Peter Blackman



Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

2024-06-07 Thread Igor B. Poretsky
Hello Tobias,

I've added missed copyright notices.

BTW, my packages were removed from mentors.debian.net since no sponsor
was found for up to 20 weeks. Now I've restored upload and opened new
RFS bugs. Thus, for this particular package it is 1072726.

Great thanks for your attention.

Best regards,
Igor.

> "Tobias" == Tobias Frost  writes:

Tobias> Found another few minutes for the d/copyright review: -
Tobias> doc/Makefile.in is undocumented.  - po Translation authors
Tobias> should also be mentioned - m4/* has undocumentd files.  -
Tobias> */Makefile.in are not documented

Tobias> -- tobi



Bug#1072728: RFS: ru-tts/6.2.2-1 [ITP] -- Software Russian TTS engine

2024-06-07 Thread Igor B. Poretsky
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ru-tts":

 * Package name : ru-tts
   Version  : 6.2.2-1
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/ru_tts
 * License  : MIT
 * Vcs  : https://salsa.debian.org/tts-team/ru-tts
   Section  : sound

The source builds the following binary packages:

  ru-tts - Software Russian TTS engine
  librutts7 - Software Russian TTS engine (shared library)
  librutts-dev - Software Russian TTS engine (development library)

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

  https://mentors.debian.net/package/ru-tts/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/ru-tts/ru-tts_6.2.2-1.dsc

Changes for the initial release:

 ru-tts (6.2.2-1) unstable; urgency=medium
 .
   * Packaged for Debian. (Closes: #1055879)

Regards,
-- 
  Igor B. Poretsky



Bug#1072727: RFS: rulex/3.8.4-1 [ITP] -- Russian pronunciation dictionary support binaries

2024-06-07 Thread Igor B. Poretsky
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : rulex
   Version  : 3.8.4-1
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/rulex
 * License  : LGPL-2.1+
 * Vcs  : https://salsa.debian.org/tts-team/rulex
   Section  : sound

The source builds the following binary packages:

  rulex - Russian pronunciation dictionary support binaries
  rulex-data - Russian pronunciation dictionary
  librulexdb0 - Russian pronunciation dictionary access library (runtime)
  librulexdb-dev - Russian pronunciation dictionary access library (development)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/rulex/rulex_3.8.4-1.dsc

Changes for the initial release:

 rulex (3.8.4-1) unstable; urgency=medium
 .
   * Packaged for Debian. (Closes: #1055898)

Regards,
-- 
  Igor B. Poretsky



Bug#1072726: RFS: multispeech/4.6.2-1 [ITP] -- Multilingual speech server for Emacspeak

2024-06-07 Thread Igor B. Poretsky
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : multispeech
   Version  : 4.6.2-1
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/multispeech
 * License  : FSFAP, FSFUL, GPL-2+, X11, FSFULLR, FSFULLRWD
 * Vcs  : https://salsa.debian.org/tts-team/multispeech
   Section  : sound

The source builds the following binary packages:

  multispeech - Multilingual speech server for Emacspeak
  sd-multispeech - Multilingual Speech Dispatcher backend
  multispeech-common - Multilingual speech server - common files
  libmultispeech5 - Multilingual speech server - core shared library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/multispeech/multispeech_4.6.2-1.dsc

Changes for the initial release:

 multispeech (4.6.2-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1055902)

Regards,
-- 
  Igor B. Poretsky



Bug#1072725: RFS: freespeech/1.0m-1 [ITP] -- English pronunciation dictionary

2024-06-07 Thread Igor B. Poretsky
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : freespeech
   Version  : 1.0m-1
   Upstream contact : Alistair Conkie 
 * URL  : https://github.com/poretsky/freespeech
 * License  : GPL-1
 * Vcs  : https://salsa.debian.org/tts-team/freespeech
   Section  : sound

The source builds the following binary packages:

  freephone - English Text-To-Phoneme converter
  enlex-data - English pronunciation dictionary

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/freespeech/freespeech_1.0m-1.dsc

Changes for the initial release:

 freespeech (1.0m-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1055900)

Regards,
-- 
  Igor B. Poretsky



Bug#1070322: still an issue in trixie

2024-05-30 Thread Andreas B. Mundt
Control: reopen -1
Control: notfixed -1 kio/5.115.0-6


Hi again,

some more tests with trixie.  I mounted a samba share and in
comparision a ksmbd share.  Long story short: ark still fails for the
samba share.  The ksmbd share seems to work as expected:

-- samba mount (note the 'Links: X', file disappears)

ansible@trixie:~$ ls -l $FILE
ls: cannot access '/media/samba/test.tar.gz': No such file or directory

ansible@trixie:~$ ark --add-to $FILE 
/usr/share/images/desktop-base/desktop-grub.png && stat $FILE
  File: /media/samba/test.tar.gz
  Size: 147 Blocks: 1  IO Block: 1048576 regular file
Device: 0,52Inode: 924164  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/ ansible)   Gid: ( 1000/ ansible)
Access: 2024-05-30 09:42:30.891533000 +0200
Modify: 2024-05-30 09:42:30.906949700 +0200
Change: 2024-05-30 09:42:30.906949700 +0200
 Birth: 2024-05-30 09:42:30.891533000 +0200

ansible@trixie:~$ ls -l $FILE
-rwxr-xr-x 1 ansible ansible 147 May 30 09:42 /media/samba/test.tar.gz

ansible@trixie:~$ ark --add-to $FILE 
/usr/share/images/desktop-base/desktop-grub.png && stat $FILE
  File: /media/samba/test.tar.gz
  Size: 147 Blocks: 8  IO Block: 1048576 regular file
Device: 0,52Inode: 924164  Links: 0
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/ ansible)   Gid: ( 1000/ ansible)
Access: 2024-05-30 09:42:39.643743300 +0200
Modify: 2024-05-30 09:42:30.906949700 +0200
Change: 2024-05-30 09:42:30.906949700 +0200
 Birth: 2024-05-30 09:42:30.891533000 +0200

ansible@trixie:~$ ls -l $FILE
ls: cannot access '/media/samba/test.tar.gz': No such file or directory

- ksmbd mount (looks fine)

ansible@trixie:~$ FILE=/media/ksmbd/test.tar.gz
ansible@trixie:~$ ark --add-to $FILE 
/usr/share/images/desktop-base/desktop-grub.png && stat $FILE
  File: /media/ksmbd/test.tar.gz
  Size: 5694Blocks: 16 IO Block: 1048576 regular file
Device: 0,53Inode: 391733  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/ ansible)   Gid: ( 1000/ ansible)
Access: 2024-05-30 09:43:10.516972400 +0200
Modify: 2024-05-30 09:43:10.520972500 +0200
Change: 2024-05-30 09:43:10.520972500 +0200
 Birth: 2024-05-30 09:43:10.516972400 +0200

ansible@trixie:~$ ark --add-to $FILE 
/usr/share/images/desktop-base/desktop-grub.png && stat $FILE
  File: /media/ksmbd/test.tar.gz
  Size: 5694Blocks: 16 IO Block: 1048576 regular file
Device: 0,53Inode: 391734  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/ ansible)   Gid: ( 1000/ ansible)
Access: 2024-05-30 09:43:13.885037800 +0200
Modify: 2024-05-30 09:43:13.885037800 +0200
Change: 2024-05-30 09:43:13.885037800 +0200
 Birth: 2024-05-30 09:43:13.885037800 +0200

ansible@trixie:~$ ls -l $FILE
-rwxr-xr-x 1 ansible ansible 5694 May 30 09:43 /media/ksmbd/test.tar.gz

Any ideas?  Again, find below some more information about the setup.

Best regards,

  Andi

--

ansible@trixie:~$ apt list kio
kio/testing,now 5.115.0-6 amd64 [installed,automatic]

mount:
//192.168.122.184/homes on /media/samba type cifs 
(rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=andi,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.122.184,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,nobrl,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,user=ansible,user=andi)
//192.168.122.157/homedirs on /media/ksmbd type cifs 
(rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=smbuser,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.122.157,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,nobrl,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,user=ansible,user=smbuser)



Bug#1070322: marked as pending in kio

2024-05-29 Thread Andreas B. Mundt
Hi,

I started testing the patched kio. Unfortunatelly, it seems to not fix
all issues.  To ease testing, I export and mount from localhost and
run the following (note the link counter in ls -l):  

andi@kde:/media/samba$ ls -l test.tar.gz
ls: cannot access 'test.tar.gz': No such file or directory
andi@kde:/media/samba$ ark --add-to test.tar.gz 
/usr/share/images/desktop-base/desktop-grub.png && ls -l test.tar.gz
-rwxr-xr-x 1 andi andi 147 May 29 21:59 test.tar.gz
   ^
andi@kde:/media/samba$ ark --add-to test.tar.gz 
/usr/share/images/desktop-base/desktop-grub.png && ls -l test.tar.gz
-rwxr-xr-x 0 andi andi 147 May 29 21:59 test.tar.gz
   ^
andi@kde:/media/samba$ ark --add-to test.tar.gz 
/usr/share/images/desktop-base/desktop-grub.png && ls -l test.tar.gz
-rwxr-xr-x 1 andi andi 147 May 29 22:00 test.tar.gz
   ^
andi@kde:/media/samba$ ark --add-to test.tar.gz 
/usr/share/images/desktop-base/desktop-grub.png && ls -l test.tar.gz
-rwxr-xr-x 0 andi andi 147 May 29 22:00 test.tar.gz
   ^
andi@kde:/media/samba$ ls -l test.tar.gz
ls: cannot access 'test.tar.gz': No such file or directory

So if the archive exists, it is removed, if newly generated, it works.
No idea why the file shows up with link counter 0 if the file is
listed immediately after running ark.  It's gone if listed seperately.

Find below some more information about the setup, perhaps this gives
someone some ideas.  I'll continue tomorrow.

Best regards,

  Andi


andi@kdedaily:/media/samba$ grep -vE "^(#|;|$)" /etc/samba/smb.conf 
[global]
   workgroup = WORKGROUP
   log file = /var/log/samba/log.%m
   max log size = 1000
   logging = file
   panic action = /usr/share/samba/panic-action %d
   server role = standalone server
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* 
%n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes
[homes]
   comment = Home Directories
   browseable = no
   read only = no
   create mask = 0700
   directory mask = 0700
   valid users = %S
[printers]
   comment = All Printers
   browseable = no
   path = /var/tmp
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700
[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no

mount:
//localhost/homes/ on /media/samba type cifs 
(rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=andi,uid=1000,noforceuid,gid=1000,noforcegid,addr=:::::::0001,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,nobrl,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,user=andi)

fstab:
//localhost/homes/ /media/samba cifs  user,nobrl,user=andi,password=123 0 0

apt list "libkf5kio*" "kio*" | grep install
kio-extras-data/stable,stable,now 4:22.12.3-1 all [installed,automatic]
kio-extras/stable,now 4:22.12.3-1 amd64 [installed,automatic]
kio-ldap/stable,now 22.12.3-1 amd64 [installed,automatic]
kio/now 5.103.0-1+deb12u1 amd64 [installed,local]
libkf5kiocore5/now 5.103.0-1+deb12u1 amd64 [installed,local]
libkf5kiofilewidgets5/now 5.103.0-1+deb12u1 amd64 [installed,local]
libkf5kiogui5/now 5.103.0-1+deb12u1 amd64 [installed,local]
libkf5kiontlm5/now 5.103.0-1+deb12u1 amd64 [installed,local]
libkf5kiowidgets5/now 5.103.0-1+deb12u1 amd64 [installed,local]



Bug#1071741: RFS: winff/1.6.4+dfsg-2 -- graphical video and audio batch converter using ffmpeg or avconv

2024-05-24 Thread Peter B

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : winff
   Version  : 1.6.4+dfsg-2
   Upstream contact : Matthew Weatherford 
 * URL  : https://github.com/WinFF/winff
 * License  : GFDL-1.3+, GPL-2+, GPL-3+
 * Vcs  : https://salsa.debian.org/pascal-team/winff
   Section  : video

The source builds the following binary packages:

  winff - graphical video and audio batch converter using ffmpeg or avconv
  winff-qt - Qt variant of winff
  winff-data - winff data files
  winff-doc - winff documentation

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/winff/winff_1.6.4+dfsg-2.dsc


Changes since the last upload:

 winff (1.6.4+dfsg-2) unstable; urgency=medium
 .
   * Fix reproducibility for locales & timezone

Regards,
--
  Peter Blackman



Bug#1070683: should work with systemd socket activation

2024-05-19 Thread Andreas B. Mundt
Control: severity -1 wishlist

Hi Tomas,

atftpd should work with both IP versions already when using the
default Debian installation with systemd socket activation.  I
hesitate to apply your patch right now, as I am not that familiar with
the code:  For example, AF_INET is used at other places in the code
too.

Best regards,

  Andi



Bug#1070846: ITP: smatch -- a static analysis tool for C

2024-05-10 Thread Ricardo B. Marliere
Package: wnpp
Severity: wishlist
Owner: "Ricardo B. Marliere" 
X-Debbugs-Cc: debian-de...@lists.debian.org, dan.carpen...@linaro.org, 
rica...@marliere.net

* Package name: smatch
  Version : 1.73
  Upstream Contact: sma...@vger.kernel.org
* URL : https://smatch.sourceforge.net/
* License : GPLv2+
  Programming Lang: C
  Description : a static analysis tool for C

Smatch is a code checking framework developed by Dan Carpenter on top of
Sparse [1]. It extends Sparse with useful functionality in the scope of
the Linux Kernel such as data-flow analysis which makes it possible to
detect such things as conditions that will always (or never) be true,
pointers that might be null, and locks that end up in different states
depending on which path is taken through the code [2]. A good
introduction was written by Dan himself [3] and he also had a mentorship
session about it [4], which goes in detail about its usefulness.

[1] https://tracker.debian.org/pkg/sparse
[2] https://lwn.net/Articles/691882/
[3] 
https://blogs.oracle.com/linux/post/smatch-static-analysis-tol-overview-by-dan-carpenter
[4] https://events.linuxfoundation.org/mentorship-session-smatch/



Bug#1063900: gstreamer1.0-plugins-good: missing Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)

2024-05-08 Thread Richard B

Hello.

Upgrading gstreamer1.0-plugins-ugly to 1.24.3-1 on Trixie didn't produce 
the error that was originally reported.  Here's my output:


   Retrieving bug reports... Done
   Parsing Found/Fixed information... Done
   serious bugs of gstreamer1.0-plugins-good (1.22.10-1 → 1.24.3-1)
   
 b1 - #1063900 - gstreamer1.0-plugins-good: missing
   Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)
   Merged with: 1063921
   Summary:
 gstreamer1.0-plugins-good(1 bug)
   Are you sure you want to install/upgrade the above packages?
   [Y/n/?/...] y
   Reading changelogs... Done
   ...
   Preparing to unpack .../gstreamer1.0-plugins-good_1.24.3-1_amd64.deb ...
   Unpacking gstreamer1.0-plugins-good:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   Preparing to unpack .../gstreamer1.0-plugins-bad_1.24.3-1_amd64.deb ...
   Unpacking gstreamer1.0-plugins-bad:amd64 (1.24.3-1) over (1.22.10-1) ...
   ...
   Preparing to unpack
   .../04-libgstreamer-plugins-bad1.0-0_1.24.3-1_amd64.deb ...
   Unpacking libgstreamer-plugins-bad1.0-0:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   Preparing to unpack
   .../05-gir1.2-gst-plugins-bad-1.0_1.24.3-1_amd64.deb ...
   Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   ...
   Setting up libgstreamer-plugins-bad1.0-0:amd64 (1.24.3-1) ...
   Setting up gir1.2-gst-plugins-bad-1.0:amd64 (1.24.3-1) ...
   Setting up gstreamer1.0-plugins-good:amd64 (1.24.3-1) ...
   Setting up gstreamer1.0-plugins-bad:amd64 (1.24.3-1) ...
   Processing triggers for libc-bin (2.38-7) ...

I see that the conflicting files mentioned are on my system, but that 
didn't seem to impact my upgrade:


   -rw-r--r-- 1 root root 27K Apr 30 04:18
   /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so
   -rw-r--r-- 1 root root 19K Apr 30 04:18
   /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrwbdec.so
   -rw-r--r-- 1 root root 208 Apr 29 18:15
   /usr/share/gstreamer-1.0/presets/GstAmrnbEnc.prs

gstreamer1.0-plugins-ugly was upgraded to a matching version before 
this.  Here's what dpkg reports:


   ii  gstreamer1.0-plugins-ugly:amd64
   1.24.3-1 amd64    GStreamer plugins
   from the "ugly" set

Best.

Richard

Bug#1070258: release-notes: Approach to managing other package managers when upgrading needs documentation

2024-05-05 Thread Justin B Rye
Manny wrote:
> One of the ways I got burnt in the Bullseye → Bookworm full-upgrade is
> documented here:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070203
> 
> There was no signal given before, during, or after the upgrade warning
> that the non-debian python app “argostranslate” would be ruined. It
> was just a surprise the next time the app was needed that it no longer
> functioned.

The Debian package-management system can never guarantee that software
it doesn't know about will continue to work through an upgrade (even
to a new backport kernel, never mind a whole new stable release).  If
what happened in this case was that pip3 installed code relying on a
particular version of Python, and then you upgraded the system version
of Python, then there are two approaches to protecting yourself: you
can either stick to Debian packaged Python apps, or set up a whole
separate local Python environment that you take responsibility for.

In theory, non-Debian code ecosystems could help you out here by doing
their own OS-compatibility tests and maintaining their own "release
notes".  But that's a lot of work, and unfortunately the developers
who'd need to be doing it have a tendency to ignore OS distributions -
hence all that upstream pip documentation that didn't warn you about
this.

> I’m not sure if the release notes could give any detailed guidance,
> but users should probably be instructed to minimally become aware of
> packages that are at risk. These existing sections are probably
> relevant:
> 
>   4.2.6. Remove non-Debian packages

When this says "packages", it means in the APT sense of the word; you
aren't necessarily expected to remove the things that "pip3 list"
would tell you about, just to be aware of them as things that you need
to take care of.

>   4.2.13. Check package status
> 
> Perhaps users should probably be instructed to run:
> 
>   $ pip list
>   $ pip3 list
>   $ pipx list
> 
> to at least become aware of non-Debian packages that might be impacted
> so they can be reminded to give some thought to it. IMO it’s sensible
> to save the lists from that output to a file and then refer to it
> post-upgrade to test these fragile apps so the nasty surprise of lost
> functionality does not manifest at the time that they need to use it,
> which is about the worst time to discover the loss.
> 
> Rust also has its own package manager (cargo), as does emacs. I have
> no idea if they have the same special needs that pip does. I don’t
> think cargo gives a listing mechanism so perhaps nothing can be done
> there.

There are myriad different available potential footguns of this
general sort: one or more for every active programming language
ecosystem, plus flatpak, make install, and so on.  Once you're using a
local Python environment, there might also be alternatives too new for
the most recent Debian Release Notes to know about.

One workaround that we occasionally try is to have the Release Notes
point at a Debian Wiki page that goes into all the details at length.
In principle that would be possible here, but who would write it?  As
far as I can see nobody has ever bothered to put any information about
pip/pip3/pipx on the Debian wiki in all the years they've existed.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#1070314: cryptsetup: backward incompatible change for plain mode when relying on defaults

2024-05-05 Thread Justin B Rye
RL wrote (https://lists.debian.org/debian-doc/2024/05/msg3.html):
> Guilhem Moulin  writes:
>> cryptsetup 2:2.7.0~rc0-1 has a backward incompatible change for plain
>> mode when relying on defaults cipher and password hashing algorithm.
>>
>> The change affects users upgrading from bookworm to trixie.  Plain mode
>> is generally advised against but it still makes sense to include the
>> NEWS entry into the release notes.
> 
> The text needs a bit of intro/context to be readable by an end-user. Can
> you give some pointers to explain the basic issue here - what is "plain
> mode"? is it the default now? what is the change, and what is the user
> meant to do about in response to this change? what is the
> "incompatability"?

I imagine it's connected with the Changelog entry saying:

# + plain mode: Set default cipher to aes-xts-plain64 and password hashing
#   to sha256.  This is a backward incompatible change for plain mode when
#   relying on the defaults.  It doesn't affect LUKS volumes.  Defaults for
#   plain mode should not be relied upon anyway; for many releases the
#   Debian wrappers found in the 'cryptsetup' binary package spew a loud
#   warning when 'ciphers' or 'hash=' are not explicitly specified in the
#   crypttab(5) options of plain devices.  The cryptsetup(8) executable now
#   issue such a warning as well.
 
(But I can't answer any of your questions, except that I noticed a
mention elsewhere of plain mode being the default.)

>>   Default cipher and password hashing for plain mode have respectively
>>   been changed to aes-xts-plain64 and sha256 (from aes-cbc-essiv:sha256
>>   resp. ripemd160).
> 
> It would help to start with "The" before "default".
> 
> what does "resp." mean in this context?

This one I know (and there's a clue earlier in the sentence): it's a
common non-native-English-speakerism.  "Resp." is short for "and/or
respectively", but it's used where anglophones would be more likely to
use plain "and" or "or", and it's a warning sign of a tortuously
organised sentence.  I'd suggest:
  The default cipher has been changed to aes-xts-plain64 (from
  aes-cbc-essiv:sha256), and the default hash to sha256 (from ripemd160).

(I see crypttab(5) is absolutely infested with resps.)

> Is there a crucial word missing after "hashing" - should it be "hash
> function"?

That (or "password hashing algorithm") would be more natural English,
but it might be better to stick to "hash" since that's the name of the
crypttab field.
 
>>   The new values matches what is used for LUKS, but the change does NOT
>>   affect LUKS volumes.
> 
> "value" not "values" here

(In fact I think he means "the new values match what is used...")

> (assuming LUKS is a noun) "by LUKS" not "for LUKS"?

(No idea.)
 
> the bit after the comma is pretty confusing to a non-expert like me,
> what are you trying to say here? would i expect a change in cryptsetup
> what *does* the change affect?

(No idea.)
 
>>   This is a backward incompatible change for plain mode when relying on
>>   the defaults, which (for plain mode only) is strongly advised
>>   against.
> 
> i'm afraid I cant make any sense out of this paragraph! what is
> "strongly advised against"?

"Relying on the defaults" - that is, leaving the fields empty in
crypttab.
 
>>   For many releases the Debian wrappers found in the ‘cryptsetup’ binary
>>   package have spewed a loud warning for plain devices from crypttab(5)
>>   where ‘cipher=’ or ‘hash=’ are not explicitly specified.  The
>>   cryptsetup(8) executable now issue such a warning as well.
> 
> Is this an unrelated change or is there some link to the above?

Part of the same deprecation process.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

2024-05-03 Thread Andreas B. Mundt
Control: tags -1 + patch


Hi Sune!

On Fri, May 03, 2024 at 10:18:22AM +0200, Sune Stolborg Vuorela wrote:
> On Friday, May 3, 2024 10:06:27 AM CEST you wrote:
> > On Thu, May 02, 2024 at 04:37:30PM +0200, Sune Stolborg Vuorela wrote:
> > > […]
> > >
> > > If it works for you, I'll ask the debian kde maintainers to fix it.
> > >
> > It looks like it fixes the libreoffice issue (no modifications applied
> > to libreoffice).  With a patched kio package I was not able to
> > reproduce the issue.  Replacing just the kio binary package seems to
> > be sufficient.  We are going to test a bit more on other setups too.

Tested with libreoffice from bookworm-backports:  Fixed.

> The changes needed to libreoffice are already in Debian ( https://
> gerrit.libreoffice.org/c/core/+/162935 ) - also by Kevin Ottens who also
> authored this patch.

Great!

> […]
>
> For the ark issue, you need the two kio patches I referenced in the bug report
> - also patches by Kevin Ottens
> https://invent.kde.org/frameworks/kio/-/commit/3e6800b37
> https://invent.kde.org/frameworks/kio/-/commit/48322f443

Attached is the slightly modified patch (only context, to apply cleanly).

Best regards,

  Andi
>From d1a2dab1da43d613ae5a8459ddcb62c8d78c46ff Mon Sep 17 00:00:00 2001
From: Kevin Ottens 
Date: Fri, 5 Jan 2024 11:51:49 +0100
Subject: [PATCH] Don't leak file descriptors when spawning new workers

By default we inherit file descriptors from the parent in
the worker process. This is a leak of resources since the
worker won't be able to do anything with them. Also, in
the case of CIFS this causes locks which might lead to bad
surprises in the parent process.
---

Index: kio-5.103.0/src/kioslave/kioslave.cpp
===
--- kio-5.103.0.orig/src/kioslave/kioslave.cpp
+++ kio-5.103.0/src/kioslave/kioslave.cpp
@@ -18,6 +18,10 @@
 #include 
 #include 
 
+#ifdef Q_OS_UNIX
+#include 
+#endif
+
 #ifdef Q_OS_WIN
 #include 
 #include 
@@ -40,6 +44,17 @@ extern "C" KIO::AuthInfo *_kioslave_init
 
 int main(int argc, char **argv)
 {
+#ifdef Q_OS_UNIX
+int max_fd = INT_MAX;
+struct rlimit limit;
+if (getrlimit(RLIMIT_NOFILE, ) == 0) {
+max_fd = limit.rlim_cur;
+}
+for (int fd = STDERR_FILENO + 1; fd < max_fd; fd++) {
+::close(fd);
+}
+#endif
+
 if (argc < 5) {
 fprintf(stderr, "Usage: kioslave5\n\nThis program is part of KDE.\n");
 return 1;


Bug#1069855: strace

2024-04-26 Thread Andreas B. Mundt
Hi,

here are parts of the strace, one with a samba share where the archive
is removed, and one with a ksmbd share which works fine:

samba:

[pid 101820] poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, 
events=POLLIN}, {fd=14, events=POLLIN}], 4, 473 
[pid 101840] write(23, 
"\37\213\10\0TS+f\0\3\355Zy] lseek(23, 0, SEEK_SET) = 0
[pid 101840] fdatasync(23) = 0
[pid 101840] close(23) = 0
[pid 101840] rename("/media/samba/test.tar.gz.PywIFJ", 
"/media/samba/test.tar.gz") = -1 EACCES (Permission denied)
[pid 101840] unlink("/media/samba/test.tar.gz.PywIFJ") = 0
[pid 101840] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 101840] write(5, "\1\0\0\0\0\0\0\0", 8 
[pid 101820] <... poll resumed>)   = 1 ([{fd=5, revents=POLLIN}])

The rename fails (samba lock?) and then the temporary archive is
removed.

ksmbd:

[pid 101861] poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, 
events=POLLIN}, {fd=14, events=POLLIN}], 4, 7 
[pid 101881] <... fdatasync resumed>) = 0
[pid 101881] close(23) = 0
[pid 101881] rename("/media/ksmbd/test.tar.gz.DRmBuC", 
"/media/ksmbd/test.tar.gz") = 0
[pid 101881] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 101861] <... poll resumed>)   = 1 ([{fd=5, revents=POLLIN}])

Here the rename succeeds and things work as expected.
Looks like the same problem as discussed in [1].

Best regards,

  Andi

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=55004#c56



Bug#1069855: ark may remove archive on SMB share

2024-04-25 Thread Andreas B. Mundt
Source: ark
Version: 4:23.08.1-2
Severity: normal

Dear Maintainer,

when adding a file to an archive on a (samba) SMB share, the archive 
disappears completely:

In '/etc/fstab':
  //192.168.122.184/share/ /media/sambashare cifs 
user,nobrl,user=andi,password=123 0 0

Mount the share, then:

  cd /media/sambashare/
  tar zcf test.tar.gz /usr/share/doc/cifs-utils
  ls test.tar.gz
  …
  ark --add-to test.tar.gz /usr/share/images/desktop-base/desktop-grub.png
  ls test.tar.gz
  ls: cannot access 'test.tar.gz': No such file or directory

A share provided by ksmbd does not show show the issue.
This has been found when trying to understand the issue reported in [1]. 

Thanks and best regards,

  Andi


[1] https://bugs.debian.org/1069835

mount: 
//192.168.122.157/homedirs on /media/ksmbdshare type cifs 
(rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=smbuser,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.122.157,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,nobrl,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,user=ansible,user=smbuser)

//192.168.122.184/homes on /media/sambashare type cifs 
(rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=andi,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.122.184,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,nobrl,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,user=ansible,user=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#1069835: libreoffice-kf5: documents may get lost on SMB shares

2024-04-25 Thread Andreas B. Mundt
Control: found -1 libreoffice/4:24.2.3~rc1-3
Control: notfixed -1 libreoffice/4:24.2.2-1
Control: reopen -1
Control: tags -1 - moreinfo

Hi again,

On Thu, Apr 25, 2024 at 06:43:17PM +0200, Rene Engelhard wrote:
> Am 25.04.24 um 18:37 schrieb Andreas B. Mundt:
> > On Thu, Apr 25, 2024 at 05:43:29PM +0200, Rene Engelhard wrote:
> > > Am 25.04.24 um 17:03 schrieb Andreas B. Mundt:
> > > > For now, we traced the issue back to libreoffice-kf5.  If this package
> > > > is removed, neither the document disappears on closing libreoffice nor
> > > > the popup is shown when 'nobrl' is removed from the mount options.
> > > Which doesn't do IO itself though? But maybe the KDE file picker (over 
> > > kio)
> > > does something weird? But saving (ttbomk) isn't done by the file picker
> > > itself?
> > I just tried a trixie XFCE desktop and cannot reproduce the issue
> > there.  Then I installed KDE and switched the DE. In KDE again the
> > issue is reproducable, removing libreoffice-kf5 makes the problem go
> > away.  Installing libreoffice-kf5 again: Issue is back.
> Shrugs.
> > However, back in XFCE, even with libreoffice-kf5 installed, the issue
> > does not show up.
> 
> Because in XFCE you don't get the KDE File Picker but the Gtk one.
> 
> Unless you force kf5, which I don't think you do.

Right.

> >   The different file chooser GUIs seem to trigger the
> > issue.
> Interesting.
> > Removing libreoffice-kf5 or switching to XFCE results in a
> > different file chooser, which somehow causes the problem.  So the bug
> > is probably not in libreoffice-kf5 …
> 
> -kf5 does contain the KDE file picker used in LibreOffice.
> 
> 
> In any case, try with >= 24.2.2 (so sid). If that commit was it (which I
> somehow doubt, see my previous reply) sid should work.

I upgraded libreoffice to the version in sid now -- it seems not to
happen as often as before, but I could reproduce it still a few more
times.

Not sure which package to reassign the bug to.

Best regards,

  Andi



Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

2024-04-25 Thread Andreas B. Mundt
Control: found -1 libreoffice/4:24.2.0-1 

Hi Rene,

thanks for your quick reply and sorry for not providing detailed
version information!

On Thu, Apr 25, 2024 at 05:43:29PM +0200, Rene Engelhard wrote:
> 
> Am 25.04.24 um 17:03 schrieb Andreas B. Mundt:
> > For now, we traced the issue back to libreoffice-kf5.  If this package
> > is removed, neither the document disappears on closing libreoffice nor
> > the popup is shown when 'nobrl' is removed from the mount options.
> 
> Which doesn't do IO itself though? But maybe the KDE file picker (over kio)
> does something weird? But saving (ttbomk) isn't done by the file picker
> itself?

I just tried a trixie XFCE desktop and cannot reproduce the issue
there.  Then I installed KDE and switched the DE. In KDE again the
issue is reproducable, removing libreoffice-kf5 makes the problem go
away.  Installing libreoffice-kf5 again: Issue is back.

However, back in XFCE, even with libreoffice-kf5 installed, the issue
does not show up.  The different file chooser GUIs seem to trigger the
issue. Removing libreoffice-kf5 or switching to XFCE results in a
different file chooser, which somehow causes the problem.  So the bug
is probably not in libreoffice-kf5 …

Best regards,

  Andi



Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

2024-04-25 Thread Andreas B. Mundt
Package: libreoffice-kf5
Severity: grave

Dear Rene, everybody,

we run Debian bookworm KDE plasma clients with home directories
mounted from an SMB share.  From time to time, users reported that
libreoffice documents have disappeared completely when closing
libreoffice.  We were now able to reproduce the issue on both,
the current bookworm and bookworm-backports version of libreoffice.

Mount an SMB share. I use the following in fstab:
  //SHARE/DIR /media/share cifs user,nobrl,user=USER,password=PASS 0 0

Open/create an ODT document, write some text, save the file and check
it's appearance on the share.  Then click Insert → Image and (perhaps
with the image still selected in the document) close libreoffice.
The file disappears on the share.  This is almost always reproducible
(we tested multiple SMB servers) if not, just open the file again,
insert another image, Ctrl-S, Ctrl-Q, the file is gone!

If 'nobrl' is removed from the mount options (but we need it for other
programs to work properly), instead of the file disappearing, a popup
shows:

  Error saving the document Untitled 1:
  Error creating object.
  Could not create backup copy.

This looks like already reported upstream [1].

For now, we traced the issue back to libreoffice-kf5.  If this package
is removed, neither the document disappears on closing libreoffice nor
the popup is shown when 'nobrl' is removed from the mount options.

It looks a bit like the issue found in [2].

Thanks for maintaining libreoffice,
best regards,

  Andi


[1] https://bugs.documentfoundation.org/show_bug.cgi?id=160315 
[2] https://bugs.documentfoundation.org/show_bug.cgi?id=55004#c56



Bug#1069554: [Pkg-pascal-devel] Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?

2024-04-24 Thread Peter B

On 24/04/2024 20:02, Rene Engelhard wrote:



This bugreport now caused the following "fix" in winff:

Build-Depends-Indep:
 faketime,
 libreoffice-draw-nogui   | libreoffice-draw,
 libreoffice-writer-nogui | libreoffice-writer,

which I consider bad...



Hi Rene,

Why is it bad?  The nogui's are lighter dependencies than the gui packages.
One or the other is needed. Surely better to use the nogui if its available?


Regards,
Peter

P.S.  Relates to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065447



Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

2024-04-24 Thread Peter B

Regarding ;-

"(for example linking against static libraries, builds for
 source-centered languages such as Go or Rust, usage of header-only
 C/C++ libraries, injecting data blobs into code, etc.)"

Perhaps Pascal & Lazarus could be added to that list for clarity? [1]


Regards,
Peter

[1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997948



Bug#1069554: [Pkg-pascal-devel] Bug#1069554: winff: FTBFS on armel: build-dependency not installable: libreoffice-draw-nogui

2024-04-21 Thread Peter B

On 20/04/2024 21:28, Paul Gevers wrote:

Hi,

On 20-04-2024 3:22 p.m., Lucas Nussbaum wrote:

The following packages have unmet dependencies:
  sbuild-build-depends-main-dummy : Depends: libreoffice-draw-nogui 
but it is not installable

E: Unable to correct problems, you have held broken packages.
apt-get failed.


I recall rene mentioning that parts of lo are expected to not work on 
armel due to java being broken. Probably the best way forward is to 
request binary removal on armel.


Paul


Hi Paul,

Thanks for commenting.  Despite spitting out
   "Warning: failed to launch javaldx - java may not function correctly"

I gather soffice does not actually use Java, for pdf creation.
I hope to fix this by changing the build dependencies.

Cheers,
Peter



Bug#1068181: asunder: Additional Information following maintainer response.

2024-04-03 Thread Peter B

On 03/04/2024 22:51, Joshua Aspinall wrote:

E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?


Hi Josh,

I suggest trying that suggestion  "maybe run apt-get update or try with 
--fix-missing?"


Also try installing cdparanoia and wavpack separately.

You can download wavpack from here, and install with 'sudo dpkg -i'
https://packages.debian.org/trixie/amd64/wavpack/download



IMHO there is something wrong with your system, rather than with asunder.

Maybe ask for help on the user mailing list of the forum.
https://lists.debian.org/debian-user/
https://forums.debian.net/viewforum.php?f=40


Regards,
Peter



Bug#1068068: bobcat, time_t transition lead to apparent ABI break (was: Need rebootstrapping on armel and armhf).

2024-04-03 Thread Frank B. Brokken
Dear Peter Green, you wrote:
> > Also, the bootstrapping procedure is only required when icmake isn't
> > available ...

Thanks for your bugreport: I'm about to update icmake so that the circular
dependency between bobcat and icmake is removed. Shortly after icmake's
update bobcat will also be updated.

-- 
Frank B. Brokken
(+31) 6 5353 2509
PGP Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature


Bug#1068181: asunder: Asunder package calls wavpack version not present (5.6.0-1+b1). 5.7.0-1 in repo. Cannot install.

2024-04-01 Thread Peter B

On 01/04/2024 13:07, Joshua Aspinall wrote:

Package: asunder
Version: 3.0.1+ds-1
Severity: normal
X-Debbugs-Cc: joshaspin...@member.fsf.org

Dear Maintainer,

Cannot install Asunder on testing under normal conditions due to wavpack 
version not present (reports file not found)

Looking through the packages browser can see a newer version (5.7.0-1) than 
that one it tries to grab.  Hopefully a simple fix!

Please contact me if I can help further.

Kind Regards,
Josh.


..snip


Versions of packages asunder depends on:
pn  cdparanoia   
ii  libatk1.0-0  2.50.0-1+b1
ii  libc62.37-15
ii  libcddb2 1.3.2-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libgtk2.0-0  2.24.33-3

Versions of packages asunder recommends:
pn  flac  
pn  lame  
pn  opus-tools
pn  vorbis-tools  
pn  wavpack   

Versions of packages asunder suggests:
pn  musepack-tools  

Hi Josh,

I can see that you do not have cdparanoia installed.
Its a dependency, and you will not be able to install asunder without it.
Also none of the recommends is installed.
You need at least one for Asunder to do anything useful.

wavpack is only a recommends, not a dependency, and the recommends is 
unversioned.

I have no idea where '5.6.0-1+b1' is coming from.
Have removed wavpack here and reinstalled asunder several times without 
any problems.



What exactly is the response to
  sudo dpkg -i asunder_3.0.1+ds-1_amd64.deb
?


Also, what happens if you try to install grimripper?
(grimripper is the gtk3 version of asunder)


Regards,
Peter



Bug#1067905: mpg321: Does not work on modern system (pipewire)

2024-03-30 Thread Peter B

Hi Andreas,

"mpg321 simply produces no sound output here on a system running pipewire."


How strange!

Just wondering; have you got pipewire-alsa installed?


Regards,
Peter



Bug#1068068: Need rebootstrapping on armel and armhf

2024-03-30 Thread Frank B. Brokken
Dear Andrey Rakhmatullin, you wrote:
> 
> Package: icmake,libbobcat6
> Severity: serious
> Tags: ftbfs
> 
> As src:icmake B-D:libbobcat-dev, src:bobcat B-D:icmake, there seems to be zero
> packaging-level support for bootstrapping, the packages are not 
> cross-buildable
> and the upstream bootstrapping instructions are too tedious, I'm filing this
> for visibility (as there are ~14 packages B-D:libbobcat-dev).

Thanks for your bug report. You write: 

> there seems to be zero packaging-level support for bootstrapping, the
> packages are not cross-buildable and the upstream bootstrapping instructions
> are too tedious,

So far no issues were encountered when the bootstrapping procedure as
described in the README.bobatbootstrap file in icmake's src distribution is
followed. 

If you could be a bit more specific about what you mean by 'bootstrapping
instructions are too tedious' then I'm sure those instructions can be changed
so that they're less tedious. 

Wrt the package not being cross-buildable:

The https://packages.debian.org/sid/libbobcat-dev shows the following lines
for armel and armhf:

armel   6.04.00-1   1,604.2 kB  8,598.0 kB  [list of files]
armhf   6.04.00-1   1,608.4 kB  8,126.0 kB  [list of files] 

although I also see packages for which version 6.04.00-1+b2 or 6.04.00-1+b4 is
listed. So maybe for unstable some issues recently appeared?

Also, the bootstrapping procedure is only required when icmake isn't avaialble
yet. For the construction of the bobcat library icmake 11.01.02-1 is required,
and icmake.01.02-1 needs libbobcat-dev >= 5.07.00, which is available since
bullseye (oldstable).

So maybe you can also provide some info about why the bootstrapping procedure
is needed/used?

In any case: the dependence on icmake when constructing the full bobcat
library could be avoided, but I'd rather not do that once icmake *is*
available. So please advise.


-- 
Frank B. Brokken
(+31) 6 5353 2509
PGP Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA


signature.asc
Description: PGP signature


Bug#1067844: c-evo-dh: Depends on dead-upstream mpg321 instead of mpg123

2024-03-28 Thread Peter B

Hi Andreas,

On 27/03/2024 14:57, Andreas Metzler wrote:

mpg321 is dead upstream

I don't see that as a show stopper.



Please consider moving to another player, e.g. mpg123.

I moved away from ffmpeg after c-evo-dh showed a puiparts fail
stemming from libnettle8. c-evo-dh does not use any crypto stuff,
that library was brought in by ffmpeg.


I picked mpg321 over mpg123 because it it has fewer dependencies.

Also, mpg123 is broken
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067562

mpg321 uses fixed point arithmetic, and is likely to be a better
choice on low spec architectures with no floating point (armel).


I would prefer to keep mpg321 as the sound option for c-evo-dh

Noting the user-tag mpg321-removal on your bug report,
I could instead maintain mpg321 myself if it were orphaned...


Regards,
Peter



Bug#1067426: Package sponsorship request Qucs-S

2024-03-22 Thread Peter B

On 21/03/2024 13:56, Vadim Kuznetsov wrote:

Package: sponsorship-requests
Severity: normal

I am looking for a sponsor for my package "qucs-s":

* Package name : qucs-s
   Version : 24.1.0-1
   Upstream contact : Vadim Kuznetsov 
* URL : https://github.com/ra3xdh/qucs_s
* License : GPL-2.0
* Vcs : https://github.com/ra3xdh/qucs_s.git
   Section : electronics|



Hi Vadim,

I'm wondering if you should file an RFP here?
https://wiki.debian.org/RFP

But please note there are over 3,000 outstanding already!

(For a sponsorship request, you need to package yourself, and upload to 
mentors

https://mentors.debian.net/

and use the RFS template to file a sponsorship request.

(The VCS field there is for the packaging VCS, not your upstream VCS)


Regards,
Peter



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

2024-03-20 Thread Peter B

Changes since the last upload:

 c-evo-dh (1.11-1) unstable; urgency=medium
 .
   * Team maintained (Debian Games team)  (1.10-1)
   * Add -B (build all dependencies) to d/rules   (1.10-1)
   * Add shared library linker options to d/rules (1.10-1)
   * New Upstream Release
   * Update d/copyright date
   * Drop lintian override on missing man page for libexec binary
   * Strip trailing whitespace from d/c-evo-dh-gtk2.install
   * For sound, depend on mpg321 instead of ffmpeg
   * Update long description for c-evo-dh-data



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

2024-03-18 Thread Peter B

On 17/03/2024 10:27, Tobias Frost wrote:

The source builds the following binary packages:

     cevomapgen - External Map Generator for C-Evo



cevomapgen is a tool for use with c-evo-dh
https://tracker.debian.org/pkg/c-evo-dh

Would it make sense to call it also c-evo-mapgen, to use the same scheme
as the game package?


Hi Tobias,

Good idea. A couple of issues though;

I don't want to change the overall project name now.
Its been released elsewhere and promoted in various forums for nearly a 
year.

The name originated from
  https://www.cix.co.uk/~spot/civmapgen/CivMapGen.htm
from which the program was adapted.

c-evo-mapgen is already in use here
https://github.com/samboy/c-evo-mapgen

What I have done, is to change the name of the Debian binary package to 
c-evo-map-gen,

and updated the doc-base indices accordingly

So putting c-evo into synaptic or doc-base now brings up both the game 
and the map tool.

This is better, so thanks for the suggestion.


Cheers,
Peter



Bug#1022043: apt-cacher-ng sometimes fails with several concurrent

2024-03-15 Thread Andreas B. Mundt
Hi Tim,

On Mon, Feb 26, 2024 at 07:12:31PM +, Tim Woodall wrote:
> On Fri, 23 Feb 2024, Andreas B. Mundt wrote:
> 
> […]
> > 
> > thanks for the provided patch!  We see the same issue here, so I
> > included it in a locally built package to give it a try on our
> > infrastructure.
> > 
> > So far it looks quite promising, no errors up to now .
> > 
> 
> That's great! I've been running it for a few weeks now and also seen no
> errors since I started using it.
> 

Same here, still no errors!  I guess this really should be addressed
in the package, perhaps even in a point release.  Unfortunatelly it
looks like apt-cacher-ng is unmaintained for the time being, that's a
pitty . :-(

Best Regards,

  Andi



Bug#1064617: Passwords should not be changed frequently

2024-03-09 Thread Justin B Rye
Philip Hands wrote:
> IMO Having the 'password/passphrase' throughout makes it awkward to
> read, and actually we've got one place where it still just says
> password, and fixing that would make it slightly worse IMO.
> 
> How about dropping the passphrase stuff?
> 
>   
> https://salsa.debian.org/philh/user-setup/-/commit/7c8dd1bd9d5c8596e7b8f82a19a075e0a5572ed7
> &
>   https://openqa.debian.net/tests/240582#step/passwords/1
> 
> which I think is more readable (and is probably fine now that we've
> dropped the stuff about password selection which could be read as
> suggesting that a password is expected to be a single word).

It all looks fine to me; as the screenshot shows, we use "password" as
a general cover-term all over the user interface anyway.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



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

2024-03-08 Thread 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.11-1
   Upstream contact : Peter 
 * URL  : https://sourceforge.net/projects/c-evo-eh/
 * License  : CC0-1.0, GPL-2+, CC-BY-SA-3.0-US, CC-BY-3.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.11-1.dsc



Changes since the last upload:

 c-evo-dh (1.11-1) unstable; urgency=medium
 .
   * New Upstream Release
   * Missing change in changlog for (1.10-1)
   * Update d/copyright date
   * Drop lintian override on missing man page for libexec binary
   * Add source package description in d/control
   * Strip trailing whitespace from d/c-evo-dh-gtk2.install

Regards,
--
  Peter Blackman



Bug#1061731: fwupd: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish”

2024-03-07 Thread Richard B

Hello.

I can confirm that upgrading fwupd and libfwupd2 on Trixie to 1.9.14-1 
and installing the package maintainer's version of /etc/fwupd/fwupd.conf 
allowed the fwupd status to start:


   sudo apt upgrade
   Reading package lists... Done
   Building dependency tree... Done
   Reading state information... Done
   Calculating upgrade... Done
   The following packages will be upgraded:
  fwupd libfwupd2
   2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
   Need to get 0 B/3,833 kB of archives.
   After this operation, 54.3 kB of additional disk space will be used.
   Do you want to continue? [Y/n] y
   Retrieving bug reports... Done
   Parsing Found/Fixed information... Done
   serious bugs of fwupd (1.9.11-1 → 1.9.14-1) 
 b1 - #1061731 - fwupd: Failed to load daemon: failed to load
   engine: Failed to load config: Key file does not have group “redfish”
   Summary:
 fwupd(1 bug)
   Are you sure you want to install/upgrade the above packages?
   [Y/n/?/...] y
   Reading changelogs... Done
   ...
   Configuration file '/etc/fwupd/fwupd.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
   *** fwupd.conf (Y/I/N/O/D/Z) [default=N] ? y
   Installing new version of config file /etc/fwupd/fwupd.conf ...
   fwupd-offline-update.service is a disabled or a static unit not
   running, not starting it.
   fwupd-refresh.service is a disabled or a static unit not running,
   not starting it.
   fwupd.service is a disabled or a static unit not running, not
   starting it.
   Processing triggers for libc-bin (2.37-15) ...
   Processing triggers for man-db (2.12.0-3) ...
   Processing triggers for dbus (1.14.10-4) ...
   Processing triggers for hicolor-icon-theme (0.17-2) ...

   systemctl status fwupd
   ○ fwupd.service - Firmware update daemon
 Loaded: loaded (/usr/lib/systemd/system/fwupd.service; static)
 Active: inactive (dead)
   Docs: https://fwupd.org/

   sudo systemctl start fwupd

   systemctl status fwupd
   ● fwupd.service - Firmware update daemon
 Loaded: loaded (/usr/lib/systemd/system/fwupd.service; static)
 Active: active (running) since Thu 2024-03-07 16:37:27 CST; 3s ago
   Docs: https://fwupd.org/
   Main PID: 22184 (fwupd)
  Tasks: 7 (limit: 18110)
 Memory: 23.7M (peak: 108.7M)
    CPU: 988ms
 CGroup: /system.slice/fwupd.service
 └─22184 /usr/libexec/fwupd/fwupd

I kept fwupd at 1.9.11-1 since this bug was reported, but the new 
version seems to be in the clear.


Best.

Richard

Bug#1064617: Passwords should not be changed frequently

2024-03-06 Thread Justin B Rye
Philip Hands wrote:
>> Maybe instead of saying "use the system's initial user account to
>> become root" it should say "allow the system's initial user account
>> to gain administrative privileges"?  I'm not sure.  Oh, and we might
>> even want to mention the word "superuser", or then again we might not.
> 
> I think Diederik's suggestion of using 'root' for the account and
> 'super-user' for the privileges might be the way to go.

Looking at what I end up with after another couple of rounds of
fiddling with it I'm not sure if it's doing quite what you asked for,
but you still might want it so here it is:

-   Some account needs to have system administrative privileges. The
-   password/passphrase for that account should be something that
-   cannot be guessed.
+   Some account needs to be available with administrative super-user
+   privileges. The password/passphrase for that account should be
+   something that cannot be guessed.
.
To allow direct password-based access via the 'root' account, you
can set the password/passphrase for that account here.
.
-   Alternatively, you can lock root's password
+   Alternatively, you can lock the root account's password
by leaving this setting empty, and
instead use the system's initial user account
(which will be set up in the next step)
-   to become root. This will be enabled for you
-   by adding that user to the 'sudo' group.
+   to gain administrative privileges. This will be enabled for you by
+   adding that initial user to the 'sudo' group.
.
Note: what you type here will be hidden (unless you select to show it).

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



Bug#1064617: Passwords should not be changed frequently

2024-03-06 Thread Justin B Rye
Philip Hands wrote:
>> https://salsa.debian.org/installer-team/user-setup/-/commit/77c1517fade367bc465da2a5908c5ac47dd8bba7
>>
>>   Template: passwd/root-password
>>   Type: password
>>   # :sl1:
>>   _Description: Root password/passphrase:
>>One needs a password/passphrase that grants
>>access to the 'root' (system administrative) account.
>>Be aware that a malicious or unqualified user
>>that obtains root access can have disastrous results,
>>so you should choose a password/passphrase that cannot be guessed.
>>It should not be a word found in dictionaries,
>>or something that could be easily associated with you.
>>
>> (Summary: You DO need a root password.)
> 
> No, as I said, what that's trying to say is that there needs to exist a
> password that one way or the other will let one get access to the root
> account (since otherwise one is not going to be able to admin the
> machine), but that is not neccesarily the same thing as a "root
> password", 
> 
> If it comes across as meaning that there needs to be a "root password",
> then it's not succeeding in expressing the nuance of the situation
> correctly, and we probably need to fix that (assuming that we can come
> up with a better wording that still fits in the space available).

Yes; even reading it suspecting that that might be what it was meant
to be saying I found it hard to read that interpretation into it.  The
line starting "One needs a password..." implies that this dialogue
deals with the need for the particular *password* that gives access to
the root *account* - the obvious interpretation is that it's talking
about the "Root password/passphrase" in the Description.  It takes some
mental contortions to see that my own login password might also be
thought of as doing that, and further, that this dialogue can be seen
as creating (or no, I mean causing the existence of) such a password.

But I notice now that the way I've phrased it means users aren't
implicitly warned that a sudo-privileged user account needs a good
password, so maybe I need another coffee and a think...

>>.
>>To allow direct password-based access to root,
>>you should set the 'root' password/passphrase here.
>>.
>>Alternatively, you can lock root's password
>>by leaving this setting empty, and
>>instead use the system's initial user account
>>(which will be set up in the next step)
>>to become root. This will be enabled for you
>>by adding that user to the 'sudo' group.
>>.
>>Note: what you type here will be hidden (unless you select to show it).
>>
>> (Summary: You DON'T need a root password.)
>>
>> Suggested rewrite (short version):
>>
>>  _Description: Root password/passphrase:
>>   To allow direct password/passphrase-based access to the 'root'
>>   (system administrative) account you can set it up here.
>>   To protect your system you should not use one that can be guessed.
>>   .
>>   Alternatively, you can lock root's password
>>by leaving this setting empty, and
>>instead use the system's initial user account
>>(which will be set up in the next step)
>>to become root. This will be enabled for you
>>by adding that user to the 'sudo' group.
>>.
>>Note: what you type here will be hidden (unless you select to show it).
> 
> This is certainly better than good enough, so I'd be fine with this too.

Post-coffee (also fixing that wobbly indent):

   Some account needs to have system administrative privileges. The
   password/passphrase for that account should be something that
   cannot be guessed.
   .
   To allow direct password-based access via the 'root' account, you
   can set the password/passphrase for that account here.
   .
   Alternatively, you can lock root's password
   by leaving this setting empty, and
   instead use the system's initial user account
   (which will be set up in the next step)
   to become root. This will be enabled for you
   by adding that user to the 'sudo' group.
   .
   Note: what you type here will be hidden (unless you select to show it).

Maybe instead of saying "use the system's initial user account to
become root" it should say "allow the system's initial user account
to gain administrative privileges"?  I'm not sure.  Oh, and we might
even want to mention the word "superuser", or then again we might not.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#1064617: Passwords should not be changed frequently

2024-03-06 Thread Justin B Rye
Philip Hands wrote:
> Justin B Rye  writes:
>> Philip Hands wrote:
>>> Justin B Rye  writes:> ...
>>> The reason behind that structure was supposed to be that one definitely
>>> needs _a_ password, but not necessarily a root password, so the password
>>> advice applies to whichever password you'll decide to grant root access
>>> to, which might not be set here.
>>
>> This template is specifically about the "Root password/passphrase";
> 
> Well, sort-of, except that the user's response (whether to leave this
> blank or not) modifies what happens with the user account's permissions,
> so it's also about explaining the way that logic works in the installer
> and what that will do to the target system.
>
>> probably I should have quoted the patch I was looking at, which starts
>> with "One needs a password/passphrase that grants access to the 'root'
>> (system administrative) account" but goes on to say "Alternatively,
>> you can lock root's password by leaving this setting empty".
> 
> I'm intimately familiar with the patches you're reading, so I feel like
> this comment suggests that we may be talking past one another somehow.

Yes, this is a common problem: you're so familiar with what we need
it to say that you aren't noticing what the text currently does say.

https://salsa.debian.org/installer-team/user-setup/-/commit/77c1517fade367bc465da2a5908c5ac47dd8bba7

  Template: passwd/root-password
  Type: password
  # :sl1:
  _Description: Root password/passphrase:
   One needs a password/passphrase that grants
   access to the 'root' (system administrative) account.
   Be aware that a malicious or unqualified user
   that obtains root access can have disastrous results,
   so you should choose a password/passphrase that cannot be guessed.
   It should not be a word found in dictionaries,
   or something that could be easily associated with you.

(Summary: You DO need a root password.)
   .
   To allow direct password-based access to root,
   you should set the 'root' password/passphrase here.
   .
   Alternatively, you can lock root's password
   by leaving this setting empty, and
   instead use the system's initial user account
   (which will be set up in the next step)
   to become root. This will be enabled for you
   by adding that user to the 'sudo' group.
   .
   Note: what you type here will be hidden (unless you select to show it).

(Summary: You DON'T need a root password.)

Suggested rewrite (short version):

 _Description: Root password/passphrase:
  To allow direct password/passphrase-based access to the 'root'
  (system administrative) account you can set it up here.
  To protect your system you should not use one that can be guessed.
  .
  Alternatively, you can lock root's password
   by leaving this setting empty, and
   instead use the system's initial user account
   (which will be set up in the next step)
   to become root. This will be enabled for you
   by adding that user to the 'sudo' group.
   .
   Note: what you type here will be hidden (unless you select to show it).

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



Bug#1064617: Passwords should not be changed frequently

2024-03-05 Thread Justin B Rye
Philip Hands wrote:
> Justin B Rye  writes:
>> It needs a small amount of rephrasing, but the most important problem
>> is that it starts by saying you need to set a password and then goes
>> on to suggest that you might not need to set a password.  Maybe that
>> can be fixed by rearranging things slightly...
>>
>>  Template: passwd/root-password
>>  Type: password
>>  # :sl1:
>>  _Description: Root password/passphrase:
>>   To allow direct password/passphrase-based access to the 'root'
>>   (system administrative) account you can set it up here.
>>   The results can be disastrous if a malicious or incompetent user
>>   obtains root access, so you should not set one that can be guessed,
>>   found in dictionaries, or easily associated with you.
>>   .
>>   Alternatively, you can lock root's password
>>   by leaving this setting empty, and
>>   instead use the system's initial user account
>>   (which will be set up in the next step)
>>   to become root. This will be enabled for you
>>   by adding that user to the 'sudo' group.
>>   .
>>   Note: what you type here will be hidden (unless you select to show it).
>>
>> Does this still feel like the same advice?
> 
> The reason behind that structure was supposed to be that one definitely
> needs _a_ password, but not necessarily a root password, so the password
> advice applies to whichever password you'll decide to grant root access
> to, which might not be set here.

This template is specifically about the "Root password/passphrase";
probably I should have quoted the patch I was looking at, which starts
with "One needs a password/passphrase that grants access to the 'root'
(system administrative) account" but goes on to say "Alternatively,
you can lock root's password by leaving this setting empty".

> I'm OK with the way you've phrased it, although my personal preference
> would be to simply drop the "disastrous" sentence if we use this
> version, because I think it breaks the straightforward flow of the text
> laying out the choice we're trying to get the user to make between the
> two available options. (I also rather doubt that anything we say at this
> point in the install will have the slightest influence on people's
> choice of password).

I can imagine people might be more likely to heed something shorter;
maybe it could be boiled down to

To allow direct password/passphrase-based access to the 'root'
(system administrative) account you can set it up here.
To protect your system you should not use one that can be guessed.

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



Bug#1064617: Passwords should not be changed frequently

2024-03-05 Thread Justin B Rye
Holger Wansing wrote:
> @d-l10n-english: hey guys, we would like to get a proposal reviewed, 
> which aims to improve the root/user password screens in the installer.
> 
> Please find the related merge request at
> 

It needs a small amount of rephrasing, but the most important problem
is that it starts by saying you need to set a password and then goes
on to suggest that you might not need to set a password.  Maybe that
can be fixed by rearranging things slightly...

 Template: passwd/root-password
 Type: password
 # :sl1:
 _Description: Root password/passphrase:
  To allow direct password/passphrase-based access to the 'root'
  (system administrative) account you can set it up here.
  The results can be disastrous if a malicious or incompetent user
  obtains root access, so you should not set one that can be guessed,
  found in dictionaries, or easily associated with you.
  .
  Alternatively, you can lock root's password
  by leaving this setting empty, and
  instead use the system's initial user account
  (which will be set up in the next step)
  to become root. This will be enabled for you
  by adding that user to the 'sudo' group.
  .
  Note: what you type here will be hidden (unless you select to show it).

Does this still feel like the same advice?

Otherwise the only thing I see is:

 Template: passwd/user-password
 Type: password
 # :sl1:
 _Description: Choose a password/passphrase for the new user:
  Make sure to select a strong password/passphrase, that cannot be guessed.
  ^
No comma needed there.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#1065447: [Pkg-pascal-devel] Bug#1065447: unneeded libreoffice Build-Depends (libreoffice, ure-java, default-jre), -writer and -draw are enough

2024-03-05 Thread Peter B

Hi Rene,

Thanks for clarifying. Seems I can use libreoffice-draw-nogui, but need 
libreoffice-writer for now as you said.



Cheers,
Peter



Bug#1065432: lazarus: cannot build with qt6

2024-03-04 Thread Peter B

Source: lazarus
Version: 3.0+dfsg1-8
Severity: normal
X-Debbugs-Cc: pe...@pblackman.plus.com

Dear Maintainer,

Cannot build packages with
  'lazbuild --ws=qt6'
Builds fail with
  '/usr/bin/ld.bfd: cannot find -lQt6Pas: No such file or directory'

Probably needs a libqt6pas package.

See
https://gitlab.archlinux.org/archlinux/packaging/packages/qt6pas/-/blob/main/PKGBUILD?ref_type=heads


Regards,
Peter


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

Kernel: Linux 6.6.15-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



Bug#1035747: ITP: cevomapgen -- External Map Generator for C-Evo

2024-03-01 Thread Peter B

Now at upstream version 31
Changes since 26,

cevomapgen (31)

  Warn when map size is over 9,600
  Workaround for Qt5 SpinEdits broken in Lazarus 3.0

 --  Wed, 28 Feb 2024

cevomapgen (30)

  Use Smart linking
  Use Makefile in Linux builds
 --  Tue, 27 Feb 2024

cevomapgen (29)

  Rework starting positions algorithm
 --  Sun,  8 Oct 2023

cevomapgen (28)

  fix bug in selection of starting positions
 --  Wed, 20 Sep 2023

cevomapgen (27)

  fix crash on repeating map load
  Show City estimate on loaded maps
 --  Sun, 18 Jun 2023



Bug#1064597: apparmor denies libvirt access to /etc/ssl/openssl.cnf

2024-02-24 Thread Paul B. Henson
Package: libvirt0
Version: 9.0.0-4

When I start vm's, I see this error message in the system logs:

kernel: [578906.082105] audit: type=1400 audit(1708728091.927:140):
apparmor="DENIED" operation="open"
profile="libvirt-f1f75261-a8b3-4987-b3b4-66577cc691b3"
name="/etc/ssl/openssl.cnf" pid=266042 comm="qemu-system-x86" requested_mask="r"
denied_mask="r" fsuid=64055 ouid=0

It appears the libvirt apparmor template does not provide access? I didn't
see this issue under Debian 11, but it started popping up after updating
to Debian 12, specifically. I'm currently running 12.5.



Bug#1022043: apt-cacher-ng sometimes fails with several concurrent

2024-02-23 Thread Andreas B. Mundt
Control: tags -1 patch
Control: found -1 apt-cacher-ng/3.7.4-1

Hi Tim,

thanks for the provided patch!  We see the same issue here, so I
included it in a locally built package to give it a try on our
infrastructure.

So far it looks quite promising, no errors up to now .

Best regards,

  Andi



Bug#1064394: release-notes: English language output for the commands into script session

2024-02-23 Thread Justin B Rye
Franco Martelli wrote:
>> The question is, will users realise that they're putting the files in
>> *root's* home directory, and will they even know where that is?
> 
> A minimal assumption of knowledge base of the FHS ¹  and tilde-expansion
> should be take by Release Notes writers. I think we shouldn't worry about
> this.

It's possible to be a heavy commandline user for a long time without
discovering that ~/ can expand to /root/.  But we've got onto a
sidetrack from the main issue of this bugreport, and I probably
shouldn't have brought it up in the first place, since files are
dropped into ~/ in quite a few of the recipes in the Release Notes,
and changing them all would be more trouble than it's worth.

(So this email really ought to stop here.)
 
>> If we really can't suggest using /var/tmp for this, that seems a pity;
>> that location *shouldn't* be wiped on reboot, and it's usable whether
>> you're running "sudo; screen" or "sudo screen" or "screen; sudo".
> 
> It's more popular to use a non-privileged home directory.

I don't follow: /var/tmp is a non-privileged location that anybody can
write to, and continue accessing before and after switching to a
different user account.  On the other hand, files created in /root/
aren't accessible to normal users, even if they know where to look.

> Few people strictly adhere to the FHS ¹  specifications.

People who diverge from the standards (e.g. by setting up an
overenthusiastic tmpreaper, if that's what you're thinking of) need to
remember their automated footguns and make allowances for them.

> This is why I am in favor of
> using tilde-expansion. No matters if the reader becomes root or runs
> "script" as non-privileged user: the files will always go in the home
> directory, where they will be used by "scriptreplay" command. By doing so we
> won't have to take care of where the files reside.

This is backwards.  If I use ~/, it expands to whatever home directory
is listed in /etc/password for my current user, and that can vary
non-obviously depending on what user I am.  The alternative is to give
an explicit path like /root/, in which case it's obvious what location
it's talking about - though it'll fail if they haven't run sudo yet.

Then again there's the option of using ./, which is another can of
worms.  Part of the problem is that we don't have a section saying
"start by getting a root commandline in a sane shell with a sane PWD";
if we did, that would also be a good place to go into the question of
appropriate locales.  Or maybe it would just encourage users to skip
that whole boring section to get to the "apt full-upgrade" part.

> ¹ https://refspecs.linuxfoundation.org/fhs.shtml

Most users haven't read that.  I know *I* hadn't looked at it since
before they updated it for /run and usrmerge and so on.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#1064394: release-notes: English language output for the commands into script session

2024-02-21 Thread Justin B Rye
I've just noticed that we're discussing this on debian-doc without
always Ccing the bug - see
https://lists.debian.org/debian-doc/2024/02/threads.html

Franco Martelli wrote:
>> immediately preceding line invoking screen with a 2>~/foo redirection*
>> won't work on csh (tested with bookworm's tcsh).
> 
> Yes, the redirection of only stderr is not allowed in csh but with the new
> "script" command syntax this will be solved:
> 
> # script -T ~/upgrade-trixie-step.time -a ~/upgrade-trixie-step.script

(We're imagining italic "variable" markup on "-step")
 
>> So I'm not sure there's any point using anything longer than:
>> 
>> # export LC_ALL=C.UTF-8 LANGUAGE=
> 
> Yes, but what's wrong if we have a syntax portable to all shells? If
> available.

What's wrong is that people might use csh!  Nobody's been checking the
Release Notes for csh-compatibility, so recipes assume you can say
things like "cd $(mktemp -d)".  Who are these people using csh, and
how do we stop them?

(In fact that use of $() is the only other incompatibility I can see
at the moment, but who's going to remember to check each new incoming
recipe next year?)
 
>> (But doing it separately from starting "script" does make sense, if
>> only to give us room for an explanation.)
> 
> Sorry I missed the sense, what explanation?

If we said "LC_ALL=C.UTF-8 LANGUAGE= script -T ..." it would have all
sorts of disadvantages, including the fact that we'd have to explain
all of it together.  Much easier to explain about script, then suggest
a "script -T..." commandline, *then* deal with locales separately.
 
>> I don't think the Release Notes ever mention the fact that we assume
>> a Bourne shell, but if you boot into an initrd rescue shell expecting
>> it to be csh then your day hasn't finished getting worse.
> 
> Again, only if available, why don't we use a portable syntax to all shells?

"Portable" in the sense of "POSIX-ish" (including things like ksh or
zsh) makes sense.  But the thing we should be recommending to anyone
doing a dist-upgrade under csh or fish or intercal is "please stop".

>> Ah, yes, avoiding the tricky redirection syntax (worthwhile even if
>> we don't care about csh).  But if we're assuming this is already a
>> root session, "~/foo" will  put that log in /root/; maybe we should
>> say that instead of using tilde-expansion?
> 
> I'm for tilde-expansion I find it more elegant and more widespread use for
> referring to the home directory.

The question is, will users realise that they're putting the files in
*root's* home directory, and will they even know where that is?

If we really can't suggest using /var/tmp for this, that seems a pity;
that location *shouldn't* be wiped on reboot, and it's usable whether
you're running "sudo; screen" or "sudo screen" or "screen; sudo".
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#1064394: release-notes: English language output for the commands into script session

2024-02-21 Thread Justin B Rye
Franco wrote:
> Dear Debian Documentation Project staff,
> 
> I want to suggest to add a sentence like the following to the §4.4.1
> "Recording the session" paragraph. ¹  Below the "script" command:
> 
> --- BEGIN of the statement ---

I like this idea; but it might work better if we turn things around
and start with the possible problem before offering the solution.

> " If you are comfortable with English language it's strongly
> recommended that you run the following command as soon as you start
> the 'script' session:
>   # LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE
> 
>   This will allow you to get command output messages in English into
>   the script session. By doing so, it will help you for searching the
>   web, during discussions or to submit a bug report."
> --- END of the statement ---

A rephrased version:

If you use a non-English locale during the upgrade, any progress
or error messages are likely to be translated, so in the event of
problems it may be difficult to get assistance from the Internet,
or to submit a bug report. If you are comfortable using English
then it is strongly recommended that you run the following command
at the start of your 'script' session:

# LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE

This will give you command output in English.

(Or do we also need to warn users to say "yes" and not "si"?)

> This change it has been discussed on debian-user mailing-list here. ²
> The syntax of the command was designed to be portable to all shells,
> csh included.

I'm sorry, but if you're doing vital root-privileged sysadmin tasks
under csh, things have already gone badly wrong; the instructions in
the Release Notes all assume a Bourne-family shell.  For instance, the
immediately preceding line invoking screen with a 2>~/foo redirection*
won't work on csh (tested with bookworm's tcsh).

So I'm not sure there's any point using anything longer than:

   # export LC_ALL=C.UTF-8 LANGUAGE=

(But doing it separately from starting "script" does make sense, if
only to give us room for an explanation.)
 
> ¹ 
> https://www.debian.org/releases/testing/release-notes/upgrading.en.html#recording-the-session
> ² https://lists.debian.org/debian-user/2024/02/msg00562.html

I don't think the Release Notes ever mention the fact that we assume
a Bourne shell, but if you boot into an initrd rescue shell expecting
it to be csh then your day hasn't finished getting worse.

[--just as I was about to hit SEND:--]

> Could I suggest that the syntax of "script" command in the "4.4.1.
> Recording the session" section it should be:
>
> # script -T ~/upgrade-trixie-step.time -a ~/upgrade-trixie-step.script

Ah, yes, avoiding the tricky redirection syntax (worthwhile even if
we don't care about csh).  But if we're assuming this is already a
root session, "~/foo" will  put that log in /root/; maybe we should
say that instead of using tilde-expansion?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#1063678: libmrss0: Memory leak while parsing an RSS2 feed

2024-02-21 Thread b

Thanks for reporting this! I fixed the memory leak and make a new release.
Best

On 10/02/24 23:36, Mikhail Kot wrote:

Package: libmrss0
Version: 0.19.2-7
Severity: important
X-Debbugs-Cc: to-debian-...@myrrc.dev

Dear Maintainer,

I have found a bug in libmrss0 leading to memory leak on parsing some of
files. Please find the details attached.

For the following program:

```c
int main(int argc, char **argv) {
   (void)argc, (void)argv;
   mrss_t *doc = NULL;

   FILE *rss = fopen("rss.xml", "r");
   fseek(rss, 0, SEEK_END);
   long len = ftell(rss);
   rewind(rss);

   char *str = malloc(len + 1);
   fread(str, len, 1, rss);
   fclose(rss);
   str[len] = 0;

   mrss_parse_buffer(str, len, );
   mrss_free(doc);
   free(str);
   return 0;
}
```

built with

```
gcc -o out -fsanitize=address nxml_err.c -lmrss
```

Given rss.xml is `wget https://blog.demofox.org/rss.xml`,

ASan reports the following error:

```
=
==967975==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 3 byte(s) in 1 object(s) allocated from:
 #0 0x7f87515749a7 in __interceptor_strdup 
../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
 #1 0x7f87511cec70 in nxmle_find_attribute 
(/lib/x86_64-linux-gnu/libnxml.so.0+0x5c70)

SUMMARY: AddressSanitizer: 3 byte(s) leaked in 1 allocation(s).
```

The issue also reproduces on different files. On some other files,
a bigger leak is reported.

```
=
==966721==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 376010 byte(s) in 18 object(s) allocated from:
 #0 0x7ff5db6989a7 in __interceptor_strdup 
../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
 #1 0x7ff5dad73029 in nxml_get_string 
(/lib/x86_64-linux-gnu/libnxml.so.0+0x5029)

Direct leak of 3 byte(s) in 1 object(s) allocated from:
 #0 0x7ff5db6989a7 in __interceptor_strdup 
../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
 #1 0x7ff5dad73c70 in nxmle_find_attribute 
(/lib/x86_64-linux-gnu/libnxml.so.0+0x5c70)

SUMMARY: AddressSanitizer: 376013 byte(s) leaked in 19 allocation(s).
```

Libmrss0 uses nxml0 internally. For the following program,

```c
int main(int argc, char **argv) {
   (void)argc, (void)argv;
   nxml_t *doc = NULL;

   FILE *rss = fopen("rss.xml", "r");
   fseek(rss, 0, SEEK_END);
   long len = ftell(rss);
   rewind(rss);

   char *str = malloc(len + 1);
   fread(str, len, 1, rss);
   fclose(rss);
   str[len] = 0;

   if (nxml_new() != NXML_OK)
 return 1;
   nxml_parse_buffer(doc, str, len);
   nxml_free(doc);

   free(str);
   return 0;
}
```

built with

```
gcc -o out -fsanitize=address nxml_err.c -lnxml
```

the leak does not reproduce which makes me think the issue not related to
libnxml0.
If we modify the first program to parse an url instead,

```
mrss_parse_url("https://blog.demofox.org/rss.xml;, );
```

the error remains the same which makes me think the issue is not related
to libcurl.

According to libmrss0 sources
(https://github.com/bakulf/libmrss/blob/cc2f489ba698a2227065731b714905ab56b1de1a/test/parser.c#L27),
no invocation except `mrss_free` is required, so I believe
this is a bug indeed.


-- System Information:
Debian Release: bookworm/sid
   APT prefers jammy-updates
   APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-25-generic (SMP w/12 CPU threads)
Kernel taint flags: 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 libmrss0 depends on:
ii  libc62.35-0ubuntu3.6
ii  libcurl3-gnutls  7.81.0-1ubuntu1.15
ii  libnxml0 0.18.4-1

libmrss0 recommends no packages.

libmrss0 suggests no packages.

-- no debconf information





Bug#1064287: RFS: winff/1.6.3+dfsg-1 -- graphical video and audio batch converter using ffmpeg or avconv

2024-02-19 Thread Peter B

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : winff
   Version  : 1.6.3+dfsg-1
   Upstream contact : Matthew Weatherford 
 * URL  : https://github.com/WinFF/winff
 * License  : GFDL-1.3+, GPL-2+, GPL-3+
 * Vcs  : https://salsa.debian.org/pascal-team/winff
   Section  : video

The source builds the following binary packages:

  winff - graphical video and audio batch converter using ffmpeg or avconv
  winff-qt - Qt variant of winff
  winff-data - winff data files
  winff-doc - winff documentation

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/winff/winff_1.6.3+dfsg-1.dsc


Changes since the last upload:

 winff (1.6.3+dfsg-1) unstable; urgency=medium
 .
   * New Upstream release (Closes: #1053373) (Closes: #1061586)
   * Drop patch adopted upstream
   * Update copyright date

Regards,
--
  Peter Blackman



Bug#1053373: winff: shell injection

2024-02-19 Thread Peter B

On Fri, 26 Jan 2024 22:45:28 +0100 Jakub Wilk  wrote:
> Control: found -1 1.6.2+dfsg-2
>
> The fix is insufficient. To reproduce, try converting the file created
> by this command:
>
> touch '`cowsay pwned >&2; sleep inf`.mp3'
>
I'm now escaping backticks. This fixes the issue with above file.


> Single-quoted strings are better suited for shell-escaping, because the
> only character to care of is the single quote itself. That is, the whole
> escaping procedure could look like this:
>
> 1) Replace every ' character with: '\''
>
> 2) Add single quotes around the whole thing.
>

Noted. Thanks for the suggestion.

However, I'm wary of a more invasive change, and more divergence between
Linux & Windows codepaths, so have stuck with the simpler solution for now.


Regards,
Peter



Bug#1061586: ~/.winff/*.sh are world-writable

2024-02-19 Thread Peter B

Thanks for the patch.
Applied upstream.



Bug#1061306:

2024-02-11 Thread Peter B

licenserecon's reporting GPL-3 vs GPL-3+ as a difference
is not a misleading false positive. They are different licenses.
The latter confers the right to use a later license, the former does not.

kitty's d/copyright file should have a separate file stanza for the 
GPL-3 (only) files.

See https://ftp-master.debian.org/licenses/good/gpl3/
In the box to the right it says;
  [Be careful to reflect the right restriction, ie. "version 3 only" or 
"version 3 or any later".]


Anyway, as you prefer not to see these GPL version differences,
I'm changing the bug to wishlist and retitling accordingly.
It would be a real bug if lrc ignored these differences.

I've updated the man page to make it explicit that
license version differences are intentionally reported.

Please note, you can suppress these differences by using
lrc | grep -v 'GPL-3+  | GPL-3'
This leaves just four lines of file differences for kitty.


FYI
I'm considering adding some options to lrc,
including a brief or terse option which would limit output of blocks
of files with identical license differences to the first file only.
In the case of kitty, the result would be very similar to that above,
so should meet your requirement. There would just be one line
of GPL-3+ | GPL-3' which would not down out the rest of the output.

I was originally intending to tag this a 'wontfix', but my current thinking
is to leave it for now, and to close it when a terse option is added.



Bug#1061034: Re Bug#1061034

2024-02-10 Thread Peter B

While Lazarus release (3.0+dfsg1-6) fixed the immediate problem
of ideconfig.lpk missing, lazbuilds still all fail, now with

"Note: (lazarus) Invalid Package Link: file 
"/usr/lib/lazarus/3.0/ide/packages/idedebugger/idedebugger.lpk" does not 
exist."


Builds fail on the firts missing (lazarus) package. Providing 
idedebugger.lpk alone may not be sufficient to fix builds


lazarus packages fail to build unless lazarus_src is included in build 
depends.

Affects c-evo-dh, ddrescueview, view3dscene, winff, doublecmd



Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed

2024-02-04 Thread Richard B. Kreckel

On 2/5/24 00:08, Jeremy Bícha wrote:

I do not believe your issue is the same since you are still able to
log in to your NextCloud, but the original bug poster is not.


Okay.


Yes, I believe it is expected that updating GNOME Online Accounts to
3.49 will require reauthenticating. Authentication is now handled in
the user's regular web browser instead of a webkitgtk dialog which
makes login more reliable and should be more resilient to
authentication changes from upstream providers.


I was looking for information like this pointing out the 
incompatibility. (The changelog does mention that authentication for 
Google & Microsoft now uses the web browser, but nothing about nextCloud 
etc.)



It is not expected that everything will work if you try to share
configuration between different operating system versions. Sorry.


:(   Ouch! This is so frustrating.

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



Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed

2024-02-04 Thread Richard B. Kreckel

Confirmed: Same problem here for nextCloud and for google accounts.

Gnome files says "Unable to access usern...@googlemail.com Invalid 
credentials for usern...@googlemail.com".
Same for nextCloud accounts. goa-daemon says 
"/org/gnome/OnlineAccounts/Accounts/account_1706819076_1: Setting 
AttentionNeeded to TRUE
 because EnsureCredentials() failed with: Invalid password with 
username “username” (goa-error-quark, 4): Authentication failed (goa-e

rror-quark, 4)

I can remove the accounts and re-add them. But then they don't work with 
gnome-online-accounts 3.46.0-1 (Debian stable machine where same home 
dir is mounted). There, I can remove them and re-add them. But changing 
to 3.49.0-1 from testing all starts over again.


Seems like compatibility broke badly.



Bug#1061678: passt: apparmor denies access to /run/user/$UID/libvirt/qemu/run/passt/

2024-01-28 Thread Andreas B. Mundt
Package: passt
Version: 0.0~git20231230.f091893-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: a...@debian.org

Hi,

I tried to run a VM using libvirt with user mode networking and
'passt':
…

  
  
  

…
Starting the machine fails and the log shows:
   kernel: audit: type=1400 audit(1706457189.881:713): apparmor="DENIED" 
operation="mknod" …
   libvirtd[752859]: internal error: Child process (passt --one-off
   --socket 
/run/user/1000/libvirt/qemu/run/passt/47-debiantesting-6-net0.socket
   --pid 
/run/user/1000/libvirt/qemu/run/passt/47-debiantesting-6-net0-passt.pid
   […]
   PID file open: Permission denied

I guess the path to socket and pid file is not allowed from
'/etc/apparmor.d/usr.bin.passt'. After 'aa-teardown' it works as
expected.   

To Reproduce the issu:
 passt --debug --one-off \
  --socket /run/user/1000/libvirt/qemu/run/passt/38-debiantesting-net0.socket \
  --pid /run/user/1000/libvirt/qemu/run/passt/38-debiantesting-net0-passt.pid

Thanks and best regards,

  Andi

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/4 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 passt depends on:
ii  libc6  2.37-13

passt recommends no packages.

Versions of packages passt suggests:
ii  apparmor  3.0.12-1+b2

-- no debconf information


Bug#1041786: codeblocks: randomly crashes when writing c++ code

2024-01-18 Thread Andreas B. Mundt
Package: codeblocks
Followup-For: Bug #1041786
X-Debbugs-Cc: a...@debian.org
Control: tags -1 upstream

Hi,

we have the same problem, CB crashing much too often …

I found an upstream bug report with a recipe provoking crashes, and
indeed I was able to crash the program in gdb.  I prepared Debian packages
with latest upstream source applied and recompiled on bookworm to make
sure the bug is not already fixed.

You can find coredump and some more detail at the upstream report at:
 https://sourceforge.net/p/codeblocks/tickets/1152/#d644

Best regards,

  Andi


Bug#1060052: looks good: patched kernel doesn't Oops

2024-01-13 Thread Andreas B. Mundt
Hi,

On Sat, Jan 13, 2024 at 10:38:43AM +0100, Salvatore Bonaccorso wrote:
>
> […]
> 
> If someone additionally might or want to test testbuilds please have a
> look at:
> 
> https://people.debian.org/~carnil/tmp/linux/1060005/
> 
> The builds are signed with my key in the Debian keyring.

I can confirm that the provided kernel does not show the Oops in our
setup.

Many thanks and best regards,

   Andi



Bug#1060052: confirmed :-(

2024-01-09 Thread Andreas B. Mundt
Hi,

with our home directories mounted as cifs shares, we are hit by this
issue quite hard:  People can't login (because sddm is missing the
home directory) or it takes ages (or ~20 min if you are patient) until
the KDE plasma desktop gets usable.  It doesn't seem to be always
triggered, but in cases it does, it's rather fatal.  I remember
'cifs_flush_folio' from a quick look at the logs …

After booting with the 6.1.0-16 kernel, systems are back to normal.
If any more details are needed to fix the issue, just let me know.

Best regards,

  Andi



Bug#1059907: licensecheck: Please use correct case for BSD-2-Clause & BSD-3-Clause

2024-01-03 Thread Peter B

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

Dear Maintainer,

licensecheck outputs BSD licenses as BSD-2-clause & BSD-3-clause,
but the SPDX short-names use title case with upper case C
as in BSD-2-Clause & BSD-3-Clause.
https://spdx.org/licenses/

While the detected license is still clear,
this causes case sensitive comparisons by license-reconcile & 
licenserecon to fail.


Please use the official SPDX short-names for these licences.

It may be possible to fix this by changing the relevant strings in this 
source file

https://sources.debian.org/src/libstring-license-perl/0.0.9-2/t/license.t/


Regards,
Peter


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

Kernel: Linux 6.6.8-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.025-1
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-10

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-8

-- no debconf information



Bug#1052259: licensecheck: license shortname GPL-3 misdetected as GPL

2024-01-02 Thread Peter B

I have found another example of misdetection of GPL-3

In most of the files in https://sources.debian.org/src/xbrzscale/1.8-2/xbrz/
the license is given in the line

// * GNU General Public License: 
https://www.gnu.org/licenses/gpl-3.0 *


but licensecheck detects as just GPL.
Changing the case to GPL-3.0 does not improve things.



Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

2023-12-29 Thread Igor B. Poretsky
Hello Tobias,

> "Tobias" == Tobias Frost  writes:

Tobias> - m4/* has undocumentd files.

Why should these files be mentioned especially? Isn't the "Files: *"
stanza sufficient?

Tobias> - */Makefile.in are not documented

The Makefile.in files are autogenerated. How should be they documented
apart from others? And, maybe, some other autogenerated files as well?

Apparently there is something I don't understand clearly here.

Best regards,
Igor.



Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

2023-12-19 Thread Igor B. Poretsky
Hello Tobias,

> "Tobias" == Tobias Frost  writes:

Tobias> Until the first upload is sponsored, you just keep a single
Tobias> changelog entry.  In the case of a new upstream version, you
Tobias> just change the version accordingly.

Very much thanks for your clarification. So, I've updated my uploads on
mentors.debian.net.

Best regards,
Igor.



Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

2023-12-09 Thread Igor B. Poretsky
Hello Tobias,

> "Tobias" == Tobias Frost  writes:

Tobias> The "-1" is the Debian revision; it is orthogonal to the
Tobias> upstream version, (except the rules where it resets to
Tobias> usually -1, of course)

So, what should I do if my package has not been yet sponsored, but a new
upstream release actually has some sensible fixes? As I understand, I
may update my upload on mentors.debian.net. But what should I do in
debian/changelog? Should I add a new entry with a new upstream version
or amend the one that closes the ITP bug? I think that the latter option
is better. Am I right?

Best regards,
Igor.



Bug#1057801: kio-extras: afc module not enabled

2023-12-08 Thread Ricardo B. Marliere
Package: kio-extras
Version: 4:22.12.3-1
Severity: normal
X-Debbugs-Cc: rica...@marliere.net

Greetings,

there is upstream support for afc [1] but it is currently unavailable in
Debian.

[1] https://invent.kde.org/network/kio-extras/-/merge_requests/7


Thanks!
-   Ricardo


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

Kernel: Linux 6.6.5-rc1+ (SMP w/16 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 kio-extras depends on:
ii  kio5.107.0-1
ii  kio-extras-data4:22.12.3-1
ii  libappimage1.0abi1 1.0.4-5-2
ii  libc6  2.37-13
ii  libgcc-s1  13.2.0-8
ii  libkdsoap1 1.9.1+dfsg-5
ii  libkf5activities5  5.107.0-1
ii  libkf5activitiesstats1 5.107.0-1
ii  libkf5archive5 5.107.0-1
ii  libkf5bookmarks5   5.107.0-1
ii  libkf5configcore5  5.107.0-1
ii  libkf5configgui5   5.107.0-1
ii  libkf5configwidgets5   5.107.0-2
ii  libkf5coreaddons5  5.107.0-1
ii  libkf5dbusaddons5  5.107.0-1
ii  libkf5dnssd5   5.107.0-1
ii  libkf5guiaddons5   5.107.0-1
ii  libkf5i18n55.107.0-1+b1
ii  libkf5kexiv2-15.0.023.04.2-2
ii  libkf5kiocore5 5.107.0-1
ii  libkf5kiofilewidgets5  5.107.0-1
ii  libkf5kiogui5  5.107.0-1
ii  libkf5kiowidgets5  5.107.0-1
ii  libkf5service-bin  5.107.0-1
ii  libkf5service5 5.107.0-1
ii  libkf5solid5   5.107.0-1
ii  libkf5syntaxhighlighting5  5.107.0-1
ii  libmtp91.1.21-1
ii  libopenexr-3-1-30  3.1.5-5.1
ii  libphonon4qt5-44:4.12.0-3
ii  libqt5core5a   5.15.10+dfsg-5
ii  libqt5dbus55.15.10+dfsg-5
ii  libqt5gui5 5.15.10+dfsg-5
ii  libqt5network5 5.15.10+dfsg-5
ii  libqt5sql5 5.15.10+dfsg-5
ii  libqt5svg5 5.15.10-2
ii  libqt5widgets5 5.15.10+dfsg-5
ii  libqt5xml5 5.15.10+dfsg-5
ii  libsmbclient   2:4.19.3+dfsg-1
ii  libssh-4   0.10.5-3
ii  libstdc++6 13.2.0-8
ii  libtag1v5  1.13.1-1
ii  libtirpc3  1.3.4+ds-1
ii  libxcursor11:1.2.1-1
ii  phonon4qt5 4:4.12.0-3

kio-extras recommends no packages.

kio-extras suggests no packages.

-- no debconf information



Bug#1056605: format output of man page

2023-12-05 Thread Peter B



lrc parses a valid DEP-5 copyright file and notes the licenses of all
files in the source tree. Licensecheck is then run, and the results
compared. Differences between licenses in debian/copyright and the output
of licensecheck are reported.

It should be run in the top level of a cleaned Debian source tree,
with a valid DEP-5 copyright file. The source tree should be clean,
otherwise results may be contaminated by spurious reports on the
build's generated files. It is advisable to run lintian first to ensure
correct syntax of debian/copyright.

The results are indicative only, and not a substitute for manual
checking. It is intended to report obvious errors. The design intends to
minimise false positives as much as is practical. However, false positives
will occur if the spelling of the license short-string is not identical
between the file and debian/copyright. This is quite likely with complex
licensing such as 'and'/'or' constructs and specific exceptions.

Only files with a copyright header are checked. False negatives may occur
if licensecheck cannot determine a file's license. Files named copyright,
copying, readme etc. are not checked as they often specify the licenses of
other files rather than their own.


(Reformating man page output for email)



Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

2023-11-30 Thread Igor B. Poretsky
Hello Tobias,

> "Tobias" == Tobias Frost  writes:

Tobias> You should be able to just re-upload to mentors. If it does
Tobias> not allow that, remove the package manually from mentors,
Tobias> then re-upload. In the case a bot auto-close this RFS bug,
Tobias> just manually re-open it (do not file a new one)

Indeed, I've done it without a problem. Thus, I've re-uploaded all my
packages, not only Multispeech. And, since the issues listed are actual
for other my packages as well, I tried to address them their as well.

Tobias> On further iterations, you keep at -1 until this is
Tobias> sponsored.

But some things should be fixed on the upstream level. Of course, I can
do it with Debian patches, but is it a point when I am an upstream
developer myself? How should I act in this situation?

Best regards,
Igor.



Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

2023-11-26 Thread Igor B. Poretsky
Hello Tobias,

Great thanks for your review. I'll try to address all the issues listed,
but several questions by the way below:

> "Tobias" == Tobias Frost  writes:

Tobias> d/changelog: - An initial upload to Debian only have one
Tobias> single entry, like "Initial Upload (Closes:
Tobias> #)" (There are by definition no changes to the
Tobias> packaging on initial upload.)  - As an consequence, the
Tobias> debian revision must stay at -1 until sponsored.

Ok, but how can I return to the -1 debian revision now in my upload on
mentors.debian.net? And what should I do further if it will not be the
last iteration?

Tobias> - A library package needs a development package too.

But this library is not intended for a third-party development. It just
implements core functionality that is common for two different
frontends.

Tobias> - the library package must only contain the library, not
Tobias> configuration files nor manpages. (makes them breaking when
Tobias> an SONAME bump is required - see above about your Conflicts)

But this configuration is common as well and it is parsed by the library
functions. Can you give me some hint what should I do in this situation?

Tobias> d/libmultispeech.shlibs - Why do you need this file?

For the version restriction in dependencies.

Tobias> d/libmultispeech.links - why do you need the link? Is
Tobias> multispeech to be invoked by the user directly or is it only
Tobias> to be invoked by emacs? (as the usr/share/emacs seems to
Tobias> indicate) (Disclaimer: I do not know anything about emacs
Tobias> extension.)

Generally, it is used just by Emacspeak. This symlink is inherited
historically from the old versions. Now I see no valuable reason for it.

Tobias> postinst - speech-dispatcher is using a systemd service
Tobias> file, if you really need to reload its configuration, you
Tobias> should use service speech-dispatcher reload and not kill it
Tobias> via kill. (you might overkill)

Actually, it is not mandatory. Speech Dispatcher can as well be
automatically spawned by a client. The kill command in this case just
sends the SIGHUP signal, that does not kill or restart Speech
Dispatcher, but only notifies it about a configuration change. It is
documented behaviour of Speech Dispatcher. And I should notify every
running instance regardless of the way it was launched by.

Best regards,
Igor.



Bug#1056605: Vcs moved

2023-11-25 Thread Peter B

The Vcs has now moved to

https://salsa.debian.org/debian/licenserecon



Bug#1056578: RFS: profile-cleaner/2.45-3 -- Reduces browser profile size by cleaning their sqlite

2023-11-23 Thread Peter B

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : profile-cleaner
   Version  : 2.45-3
   Upstream contact : graysky 
 * URL  : https://github.com/graysky2/profile-cleaner
 * License  : Expat
 * Vcs  : https://salsa.debian.org/debian/profile-cleaner
   Section  : utils

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.45-3.dsc

Changes since the last upload:

 profile-cleaner (2.45-3) unstable; urgency=medium
 .
   * Add VCS fields to control file

Regards,
--
  Peter Blackman



Bug#1056320: RFS: mp3guessenc/0.27.6~beta+dfsg-1 -- Utility for analysis of audio mpeg files

2023-11-20 Thread Peter B

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : mp3guessenc
   Version  : 0.27.6~beta+dfsg-1
   Upstream contact : eblanc...@users.sourceforge.net
 * URL  : https://mp3guessenc.sourceforge.io/
 * License  : LGPL-2.1+, CC0-1.0
 * Vcs  : https://salsa.debian.org/debian/mp3guessenc
   Section  : sound

The source builds the following binary packages:

  mp3guessenc - Utility for analysis of audio mpeg files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mp3guessenc/mp3guessenc_0.27.6~beta+dfsg-1.dsc

Changes since the last upload:

 mp3guessenc (0.27.6~beta+dfsg-1) unstable; urgency=medium
 .
   * New upstream version
  (updated ID3v1 detection routine)
   * Standards now 4.6.2

Regards,
--
  Peter Blackman



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

2023-11-19 Thread 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.10-1
   Upstream contact : Peter 
 * URL  : https://sourceforge.net/projects/c-evo-eh/
 * License  : GPL-2+, CC-BY-SA-3.0-US, CC0-1.0, CC-BY-3.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.10-1.dsc

Changes since the last upload:

 c-evo-dh (1.10-1) unstable; urgency=medium
 .
   * New Upstream Release, (Closes: #1055837)
   * Add NEWS file

Regards,
--
  Peter Blackman



Bug#1056169: bookworm-pu: package di-netboot-assistant/0.78~deb12u1

2023-11-18 Thread Andreas B. Mundt
Hi Kibi,

thank you for your comment and explanation!

On Sat, Nov 18, 2023 at 10:11:33AM +0100, Cyril Brulebois wrote:
>
> […] 
> 
> The versioning seems a little weird.
> 
> Usually:
>  - either one cherry-picks stuff on top of the stable package, and uses
>0.76+deb12u1;
>  - or one ships a rebuild of the testing/unstable into stable, and uses
>0.78~deb12u1 (adding a changelog entry on top of unstable's,
>similarly to what would be done for backports).
> 
> Glancing very briefly at the patch and the git tree, it seems like
> you're doing the latter but versioning it like the former. I'll let
> others comment as to whether that's some nitpicking that should be
> ignored, or something they'd like to see adjusted.

Ah, you are absolutely right, makes sense.  I started with a
0.76+deb12u1 package, realized that cherry-picking ended up at 0.78,
adjusted the version number … but I wasn't aware that the changelog
should also be 'reset' to the one from 0.78 (which, I agree, makes
perfectly sense).  If needed, I can provide another upload.

Thanks and best regards,

  Andi



Bug#1056169: bookworm-pu: package di-netboot-assistant/0.78~deb12u1

2023-11-17 Thread Andreas B. Mundt
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: di-netboot-assist...@packages.debian.org, a...@debian.org
Control: affects -1 + src:di-netboot-assistant

[ Reason ]
With Bookworm, a few modifications have happened to the Debian Live ISO
images' meta data [1].  These changes make di-netboot-assistant
partially fail when bookworm ISO images are in use (the menus for the
network boot loaders like grub and iPXE are not generated properly).

The Live ISO images side has improved and stabilized [2], and also
di-netboot-assistant has been made more robust to account for these
modifications.  In addition a few minor fixes to documentation and
examples (bookworm, preseed file) have been applied.

[1] https://lists.debian.org/debian-live/2023/06/msg00023.html
[2] https://lists.debian.org/debian-live/2023/07/msg00030.html

[ Impact ]
The inclusion of bookworm live ISO images fails.

[ Tests ]
I tested the changes with the 12.2.0 gnome, kde and standard ISOs.
Grub and iPXE menu.

[ Risks ]
There are almost no risks involved.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Mostly parsing latest meta data from the live images and more robust
handling of kernel/initrd (with/without version number).

[ Other info ]
I'll already upload the updated package.
The release team is doing a great job, thank you!
diff -Nru di-netboot-assistant-0.76/config/grub.cfg.HEAD 
di-netboot-assistant-0.78~deb12u1/config/grub.cfg.HEAD
--- di-netboot-assistant-0.76/config/grub.cfg.HEAD  2023-03-16 
17:05:12.0 +0100
+++ di-netboot-assistant-0.78~deb12u1/config/grub.cfg.HEAD  2023-06-18 
09:11:47.0 +0200
@@ -18,7 +18,7 @@
 set default='Boot from local disk..'
 #set timeout=10
 
-if background_image 
/d-i/n-pkg/images/11/amd64/text/debian-installer/amd64/boot-screens/splash.png; 
then
+if background_image 
/d-i/n-pkg/images/12/amd64/text/debian-installer/amd64/boot-screens/splash.png; 
then
   set color_normal=light-gray/black
   set color_highlight=white/black
 elif background_image /d-i/n-a/stable/amd64/boot-screens/splash.png; then
diff -Nru di-netboot-assistant-0.76/debian/changelog 
di-netboot-assistant-0.78~deb12u1/debian/changelog
--- di-netboot-assistant-0.76/debian/changelog  2023-03-16 17:05:12.0 
+0100
+++ di-netboot-assistant-0.78~deb12u1/debian/changelog  2023-06-18 
09:11:47.0 +0200
@@ -1,3 +1,10 @@
+di-netboot-assistant (0.78~deb12u1) bookworm; urgency=medium
+
+  * Fixes for bookworm live iso image inclusion.
+  * Update/add/fix preseed examples.  Thanks to Holger Wansing.
+
+ -- Andreas B. Mundt   Sun, 18 Jun 2023 09:11:47 +0200
+
 di-netboot-assistant (0.76) unstable; urgency=medium
 
   * Fix typo in preseeding example.
diff -Nru di-netboot-assistant-0.76/di-netboot-assistant 
di-netboot-assistant-0.78~deb12u1/di-netboot-assistant
--- di-netboot-assistant-0.76/di-netboot-assistant  2023-03-16 
17:05:12.0 +0100
+++ di-netboot-assistant-0.78~deb12u1/di-netboot-assistant  2023-06-18 
09:11:47.0 +0200
@@ -26,7 +26,7 @@
 
 # -- Declare the constants --- #
 PACKAGE_NAME=di-netboot-assistant
-PACKAGE_VERSION=0.76
+PACKAGE_VERSION=0.78
 
 # -- Initialize the global variables - #
 OFFLINE=false
@@ -253,8 +253,8 @@
 # Returns: (EXIT STATUS) 0=Success, 1=Error
 #  #
 prepare_grub() {
-local v="" opt=$1 VERS V GRUB AR DIR 
-
+local v="" opt=$1 VERS V GRUB AR DIR
+
 $VERBOSE && v="-v"
 [ -z "$opt"  ] && [ -d $TFTP_ROOT/$N_A_DIR/grub ] && return 0
 
@@ -263,7 +263,7 @@
 [ ! -e "$TFTP_ROOT/debian-installer" ] && \
 ln -srv $TFTP_ROOT/$N_A_DIR/ $TFTP_ROOT/debian-installer
 
-for AR in x64 aa64 ; do 
+for AR in x64 aa64 ; do
 ## We link bootnet*.efi and grub*.efi from the latest available image:
 echo "I: Preparing EFI executables for '${AR}'."
 GRUB=""
@@ -533,7 +533,7 @@
 
 EOF
 sed -i "s%\(\# END_PKG_LIVE_MENU.*\)%item $tag $title\n\1%" menu.ipxe
-
+
 for AR in amd64 arm64 ; do
 gcfg="${TFTP_ROOT}/${relpath}/debian-installer/${AR}/grub/grub.cfg"
 if [ -f "$gcfg" ] ; then
@@ -560,7 +560,7 @@
 relpath=$(dirname "$x" | sed -e "s#${TFTP_ROOT}##" -e "s#^/*##" -e 
"s#\/.disk##")
 # shellcheck disable=SC2034
 ISO_NAME=$(basename "$relpath")
-title=$(sed -e "s#Official ##" -e "s#T.*\$##" "$x")
+title="$(sed -e "s#Official ##" -e 

Bug#1055837: c-evo-dh-gtk2: game unusable because directory ~/.config/c-evo-dh/Saved is not created

2023-11-17 Thread Peter B

Hi Davide,

Thanks for reporting this problem.

The game only created the Saved folder if there was something to install in it.
The removal of the original example game (for incompatibility) caused this 
regression.

Fix in 1.10


Regards,
Peter



Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

2023-11-14 Thread Igor B. Poretsky
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : multispeech
   Version  : 4.6.0-1
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/multispeech
 * License  : GPL-2.0
 * Vcs  : https://github.com/poretsky/multispeech
   Section  : sound

The source builds the following binary packages:

  multispeech - Multilingual speech server for Emacspeak
  sd-multispeech - Multilingual Speech Dispatcher backend
  libmultispeech5 - Multilingual speech server

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/multispeech/multispeech_4.6.0-1.dsc

Changes for the initial release:

 multispeech (4.6.0-1) unstable; urgency=medium
 .
   * Debian package has been separated from the upstream sources.
   * Switch to dpkg-source 3.0 format.
   * Debian package release. (Closes: #1055902)

Regards,
-- 
  Igor



Bug#1055949: RFS: ru-tts/6.2.0-1 [ITP] -- software Russian TTS engine

2023-11-14 Thread Igor B. Poretsky
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ru-tts":

 * Package name : ru-tts
   Version  : 6.2.0-1
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/ru_tts
 * License  : MIT
 * Vcs  : https://github.com/poretsky/ru_tts
   Section  : sound

The source builds the following binary packages:

  ru-tts - software Russian TTS engine
  librutts7 - software Russian TTS engine
  librutts-dev - software Russian TTS engine

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

  https://mentors.debian.net/package/ru-tts/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/ru-tts/ru-tts_6.2.0-1.dsc

Changes for the initial release:

 ru-tts (6.2.0-1) unstable; urgency=medium
 .
   * Upstream sources have been separated from the debian package.
   * Dropped rulex package dependency.
   * Updated ru_speak script.
   * Don't treat koi8 locale absence as a critical error.
   * Don't touch unknown words sink when dictionary is not in use by
 whatever reason.
   * Packaged for Debian. (Closes: #1055879)

Regards,
-- 
  Igor



Bug#1055948: RFS: rulex/3.8.0-1 [ITP] -- Russian pronunciation dictionary support binaries

2023-11-14 Thread Igor B. Poretsky
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : rulex
   Version  : 3.8.0-1
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/rulex
 * License  : LGPL-2.1
 * Vcs  : https://github.com/poretsky/rulex
   Section  : sound

The source builds the following binary packages:

  rulex - Russian pronunciation dictionary support binaries
  rulex-data - Russian pronunciation dictionary
  librulexdb0 - Russian pronunciation dictionary access library
  librulexdb-dev - Russian pronunciation dictionary access library

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/rulex/rulex_3.8.0-1.dsc

Changes for the initial release:

 rulex (3.8.0-1) unstable; urgency=medium
 .
   * Packaged for Debian. (Closes: #1055898)

Regards,
-- 
  Igor



Bug#1055947: RFS: freespeech/1.0m-21 [ITP] -- English pronunciation dictionary

2023-11-14 Thread Igor B. Poretsky
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : freespeech
   Version  : 1.0m-21
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/freespeech
 * License  : GPL
 * Vcs  : https://github.com/poretsky/freespeech
   Section  : sound

The source builds the following binary packages:

  freephone - English Text-To-Phoneme converter
  enlex-data - English pronunciation dictionary

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/freespeech/freespeech_1.0m-21.dsc

Changes for the initial release:

 freespeech (1.0m-21) unstable; urgency=medium
 .
   * Debian package update. (Closes: #1055900)

Regards,
-- 
  Igor



Bug#1055902: ITP: multispeech -- Multilingual speech server for Emacspeak

2023-11-13 Thread Igor B. Poretsky
Package: wnpp
Severity: wishlist
Owner: "Igor B. Poretsky" 

* Package name: multispeech
  Version : 4.6.0
  Upstream Author : Igor B. Poretsky 
* URL : https://github.com/poretsky/multispeech
* License : GPL-2.0
  Programming Lang: C++
  Description : Multilingual speech server for Emacspeak

Multispeech was primarily designed as a multilingual speech server
for Emacspeak, but it can be useful in some other circumstances
as well, when multilingual speech feedback is needed.
For instance, it can serve as a backend module for Speech Dispatcher.
Multispeech produces audible speech, sounds and tone signals
according to the commands passed by client. It utilizes third party
speech synthesis software to perform actual TTS transformation.

The main feature of Multispeech is its facility to recognize language by
context and automatically choose proper voice for it. Multispeech
in its very early stage was included in Knoppix distribution about 20
years ago.

Need sponsorship for upload.



Bug#1055900: ITP: freespeech -- English text preprocessor for MBROLA speech synthesizer

2023-11-13 Thread Igor B. Poretsky
Package: wnpp
Severity: wishlist
Owner: "Igor B. Poretsky" 

* Package name: freespeech
  Version : 1.0m
  Upstream Author : Steve Isard, Alistair Conkie
* URL : https://github.com/poretsky/freespeech
* License : GPL
  Programming Lang: C
  Description : English text preprocessor for MBROLA speech synthesizer

This software originates from the old archive found at
http://tcts.fpms.ac.be/synthesis/mbrola/tts/English/fs.a10m.tar.gz.
It contains English text to phoneme converter and pronunciation dictionary
that being used along with mbrola speech synthesizer
can provide full TTS functionality for English language.

The mbrola package description in fact mentions freephone as a
preprocessor along with cicero and espeak, but freephone itself is a
part of this package. Thus, I think, it would be reasonable to have it
in Debian as well.

Looking for a sponsor to upload.



Bug#1055898: ITP: rulex -- Pronunciation dictionary for Russian TTS engine

2023-11-13 Thread Igor B. Poretsky
Package: wnpp
Severity: wishlist
Owner: "Igor B. Poretsky" 

* Package name: rulex
  Version : 3.8.0
  Upstream Author : Igor B. Poretsky 
* URL : https://github.com/poretsky/rulex
* License : LGPL-2.1
  Programming Lang: C
  Description : Pronunciation dictionary for Russian TTS engine

RuLex database is primarily intended for use along with the
Ru_tts (https://github.com/poretsky/ru_tts) speech synthesizer in order
to improve its pronunciation.

This package provides  lexical database itself, its data access library
and some additional utilities to deal with it. These include text
preprocessor rulex  and lexholder-ru utility that allows one
 to browse and alter the database content.

Being developed for some years as an open source project RuLex database
was eventually used by RHVoice TTS engine
(https://github.com/RHVoice/RHVoice).

Need a sponsor for upload.



Bug#1055879: ITP: ru-tts -- Compact and portable Russian speech synthesizer

2023-11-13 Thread Igor B. Poretsky
Package: wnpp
Severity: wishlist
Owner: "Igor B. Poretsky" 

* Package name: ru-tts
  Version : 6.2.0
  Upstream Author : Igor B. Poretsky 
* URL : https://github.com/poretsky/ru_tts
* License : MIT
  Programming Lang: C
  Description : Compact and portable Russian speech synthesizer

An alternative implementation of the Phonemophone-5 Russian speech
synthesizer by the international laboratory of intelligent systems
BelSInt (the Speech Recognition and Synthesis Lab of the Institute of
Technical Cybernetics of the Academy of Sciences of the Byelorussian
SSR). The source code of the original implementation has been lost.
This implementation is the result of a reverse engineering of
the SDRV resident speech driver for MS-DOS, and it is officially
approved for publication under a free license by Boris Lobanov, who is
the head of the laboratory and the author of the design solutions that
formed the basis of the speech synthesizer, and Alexander Ivanov,
who is an engineer of the laboratory and the developer of
the speech synthesizer's the original software implementation.

It is extremely fast, compact and portable indeed. Meanwhile, it
provides quite decent speech quality. Being implemented as a library,
it can easily be used in other applications.

Currently need a sponsor for upload.



Bug#1055005: [Pkg-pascal-devel] Bug#1055005: lazarus-ide-2.2: gdb 13 dynamic array crash (regression: gdb 10 working)

2023-11-02 Thread Peter B

On 29/10/2023 08:27, Jonas Bechtel wrote:

Following conditions have to be met to reproduce the problem:

* The line must be in an extra unit (not application form class unit)
* gdb 13 must be installed (gdb 10 does not crash)


Given that the crash only occurs with gdb 13 and not with gdb 10,
surely this is a bug in gdb, not with the Lazarus IDE?

gdb is pretty flakey...
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=gdb;dist=unstable


Regards,
Peter



Bug#1054565: RFP: golang-github-zeebo-xxh3 -- XXH3 algorithm in Go

2023-11-01 Thread Ricardo B. Marliere
On 23/11/01 10:46PM, Nilesh Patra wrote:
> You need to convert RFP into ITP whenever you want to package something
> that is an RFP. Please keep that in mind for future.

I thought inserting a new ITP would be unnecessary duplication. Would
that make the system automatically convert the RFP into ITP? I had this
doubt because they would come from different users.

In any case, noted. Thank you and sorry for the rework!
-   Ricardo



Bug#967795: [Pkg-pascal-devel] Bug#967795: view3dscene: depends on deprecated GTK 2

2023-10-31 Thread Peter B

On 22/10/2023 22:15, Bastian Germann wrote:

Meanwhile, you can drop libgtkglext1-dev, which is not used, and unblock 
#967491.


Pushed to Salsa, 4.2.0-3
https://salsa.debian.org/pascal-team/view3dscene



Bug#1054565: RFP: golang-github-zeebo-xxh3 -- XXH3 algorithm in Go

2023-10-30 Thread Ricardo B. Marliere
On 23/10/25 09:19PM, James McCoy wrote:
> Package: wnpp
> Severity: wishlist
> Control: block 1037440 by -1
> 
> * Package name: golang-github-zeebo-xxh3
>   Version : 1.0.2-1
>   Upstream Author : Jeff Wendling
> * URL : https://github.com/zeebo/xxh3
> * License : BSD-2-clause
>   Programming Lang: Go
>   Description : XXH3 algorithm in Go
> 
>  XXH3
>  .
>  GoDoc (https://godoc.org/github.com/zeebo/xxh3) Sourcegraph
>  (https://sourcegraph.com/github.com/zeebo/xxh3?badge) Go Report Card
>  (https://goreportcard.com/report/github.com/zeebo/xxh3)
>  .
>  This package is a port of the xxh3 (https://github.com/Cyan4973/xxHash)
>  library to Go.
>  .
>  Upstream has fixed the output as of v0.8.0, and this package matches
>  that.
> 
> This is needed to package a new upstream version of kitty.
> 
> Cheers,
> -- 
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
> 

Hello James,

please consider reviewing for uploading the following:

https://salsa.debian.org/go-team/packages/golang-github-zeebo-assert
https://salsa.debian.org/go-team/packages/golang-github-zeebo-xxh3

Thank you!
-   Ricardo



Bug#1055074: ITP: golang-github-zeebo-assert -- Helpers for tests. You don't have to like it.

2023-10-30 Thread Ricardo B. Marliere
Package: wnpp
Severity: wishlist
Owner: Ricardo B. Marliere 

* Package name: golang-github-zeebo-assert
  Version : 1.3.1-1
  Upstream Author : Jeff Wendling
* URL : https://github.com/zeebo/assert
* License : CC0-1.0
  Programming Lang: Go
  Description : Helpers for tests. You don't have to like it.

 package assert
 .
 import "github.com/zeebo/assert"
 .
 .
 Usage
 .
 See the api docs. There's not a lot of surface area, and that's the
 goal.


This package is a dependency for golang-github-zeebo-xxh3-dev, requested
in #1054565.



Bug#941352: normal user's password is sufficient

2023-10-12 Thread Andreas B. Mundt
Control: severity -1 wishlist
Control: title -1 make clear the password query asks for the user's password 

Hi,

on bookworm, KDE/plasma, things work fine here with the user's
password entered.  It is not clear from the query text that the user's
password is sufficient, perhaps this could be improved.

Best regards,

  Andi



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

2023-09-27 Thread 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

2023-09-25 Thread 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

2023-09-25 Thread 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?

2023-09-24 Thread 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'

2023-09-24 Thread 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

2023-09-20 Thread 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

2023-09-20 Thread 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

2023-09-20 Thread 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



  1   2   3   4   5   6   7   8   9   10   >