Bug#1049325: Updated patch with CVE-2023-42464 fix

[Daniel Markstedt]

A new 0-day vulnerability CVE-2023-42464 has been published and patched with 
upstream Netatalk 3.1.17

The large CVE patch batch for oldstable has been updated and a new version 
attached here.

Thank you!

Daniel

netatalk-3.1.12~ds-8+deb11u1-2.patch
Description: Binary data

Bug#1052301: ITP: node-stdlib -- Standard library for JavaScript and Node.js

[Yadd]

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

* Package name: node-stdlib
  Version : 0.0.96
  Upstream Contact: The Stdlib Authors
  
* URL : https://github.com/stdlib-js/stdlib
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Standard library for JavaScript and Node.js

node-stdlib is a standard library for JavaScript and Node.js, with an
emphasis on numerical and scientific computing applications. The library
provides a collection of robust, high performance libraries for mathematics,
statistics, data processing, streams, and more and includes many utilities
expected from a standard library.

node-stdlib is a build dependency of node-jupyterlab. Will be maintained
under JS Team umbrella.

Bug#1052300: O: xdaliclock -- Melting digital clock

[Kartik Mistry]

Package: wnpp
Severity: normal
X-Debbugs-Cc: xdalicl...@packages.debian.org, kar...@debian.org
Control: affects -1 + src:xdaliclock

I intend to orphan the xdaliclock package. I've tried my best to maintain this
package. Be careful as upstream is not helpful or rather hostile.

Package Vcs is available in Salsa. Feel free to take over from there.

The package description is:
 The xdaliclock program displays a digital clock; when a digit changes, it
 "melts" into its new shape.
 .
 It can display in 12 or 24 hour modes, and displays the date when a mouse
 button is held down. It has two large fonts built into it, but it can animate
 most other fonts that contain all of the digits. It can also do some funky
 psychedelic colormap cycling, and can use the "shape" extension so that the
 window is shaped like the digits.

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[NIIBE Yutaka]

Hello,

NIIBE Yutaka  wrote:
> I backported and pushed my changes to tmp-gniibe-v2.4.
>
> https://salsa.debian.org/gniibe/gnupg2
>
> This is Debian compatible version of GnuPG 2.4.1.

Today, I merged 2.4.3 from Andreas Metzler's tmp-ametzler-v2.4 branch.

This is Debian compatible version of GnuPG 2.4.3.  I just started to use
this GnuPG on my system.
-- 

Bug#1052299: gnome-boxes: Cannot install "GNOME OS Nightly" - secure-boot set by ovmf while gnome os efi seems not signed

[Alban Browaeys]

Package: gnome-boxes
Version: 45.0-1
Severity: normal

Dear Maintainer,
If I attempt to create a GNOME OS guest I end up on the edkII console.
If inhte console I try to boot the EFI (in FS0: be it bootx64.efi in
\EFI\BOOT or systemd-bootx64.efi in EFI\systemd) I get a "Command Error
Status: Access Denied" error.

I got he clue it might be secure boot related by 
https://forum.proxmox.com/threads/vm-always-going-into-uefi-interactive-shell.119215/

I also learned that the install was fine with the flatpak, so I compared
the VM configurations for GNOME OS:

Debian gome-boxes 45:
  
hvm

  
  

/usr/share/OVMF/OVMF_CODE_4M.ms.fd
/home/prahal/.config/libvirt/qemu/nvram/gnomenightly_VARS.fd



  
  
 

 
   >

Flatpak gnome-boxes 44:
  
hvm



  
  


  


Grepping where this secure-boot feature comes from, I ended up on:
/usr/share/qemu/firmware/40-edk2-x86_64-secure-enrolled.json

Scrambling the target (for example, replacing in "machines", "pc-q35-*"
by "pc-q35xxx-*") in this file to avoid its settings being added to
(all?) the  guest VM I now can install "GNOME OS Nightly x86_64" (ie
edk2 boots into the installer and the installer proceeds).

This might well be an ovmf bug.
Still, as I don' know if gnome-boxes or qemu have flags to avoid ovmf
bringing in this secure-boot for all guest setups, I start up the stack.


Cheers,
Alban

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

Kernel: Linux 6.5.0+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  genisoimage  9:1.1.11-3.4
ii  libarchive13 3.6.2-1
ii  libc62.37-8
ii  libcairo21.17.8-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.78.0-1
ii  libgtk-3-0   3.24.38-5
ii  libgudev-1.0-0   238-2
ii  libhandy-1-0 1.8.2-2
ii  libosinfo-1.0-0  1.10.0-2
ii  libosinfo-bin1.10.0-2
ii  libsoup-3.0-03.4.3-1
ii  libspice-client-glib-2.0-8   0.42-2
ii  libspice-client-gtk-3.0-50.42-2
ii  libusb-1.0-0 2:1.0.26-1
ii  libvirt-clients  9.7.0-1
ii  libvirt-daemon   9.7.0-1
ii  libvirt-glib-1.0-0   4.0.0-3
ii  libwebkit2gtk-4.1-0  2.40.5-1
ii  libxml2  2.9.14+dfsg-1.3
ii  tracker  3.6.0-1
ii  user-session-migration   0.4.1

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:8.0.4+dfsg-3+b1

Versions of packages gnome-boxes suggests:
ii  gnome-connections  45~rc-1

-- no debconf information

Bug#1052298: metafun.mp refers to inexistent metafun.mpii

[Stéphane Glondu]

Package: context
Version: 2023.05.05.20230730+dfsg-2
Severity: important
Control: block 1052232 by -1

Dear Maintainer,

While investigating why mlpost now FTBFS (#1052232), I realized that
file /usr/share/texmf/metapost/context/base/mpiv/metafun.mpiv refers
to a "metafun.mpii" which doesn't exist.


Cheers,

-- 
Stéphane

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

Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 context depends on:
ii  lmodern   2.005-1
ii  luametatex2.10.08+ds-1+b1
ii  ruby  1:3.1
ii  tex-common6.18
ii  tex-gyre  20180621-6
ii  texlive-base  2023.20230613-3
ii  texlive-binaries  2023.20230311.66589-6
ii  texlive-metapost  2023.20230613-3

Versions of packages context recommends:
pn  context-modules   
ii  fonts-freefont-otf20211204+svn4273-2
ii  fonts-gfs-artemisia   1.1-6
ii  fonts-gfs-baskerville 1.1-6
pn  fonts-gfs-bodoni-classic  
ii  fonts-gfs-didot   1.1-7
pn  fonts-gfs-didot-classic   
pn  fonts-gfs-gazis   
ii  fonts-gfs-neohellenic 1.1-7
ii  fonts-gfs-olga1.1-6
ii  fonts-gfs-porson  1.1-7
ii  fonts-gfs-solomos 1.1-6
pn  fonts-gfs-theokritos  
ii  fonts-sil-gentium 20081126:1.03-4

Versions of packages context suggests:
pn  context-nonfree 
pn  fontforge   
ii  libxml-parser-perl  2.46-4
ii  perl-tk 1:804.036-1+b2

-- no debconf information

Bug#1052232: FTBFS with OCaml 4.14.1

[Stéphane Glondu]

Control: severity -1 serious

Le 19/09/2023 à 12:53, Stéphane Glondu a écrit :

Your package FTBFS with OCaml 4.14.1 with the following error:

[...]


The package currently FTBFS in unstable (with OCaml 4.13.1) as well, I 
suspect because of an update in Metapost. Raising severity.



Cheers,

--
Stéphane

Bug#1052297: ITP: node-heya-globalize -- Convert JavaScript files using UMD or AMD global

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: node-heya-globalize
  Version : 1.2.1
  Upstream Contact: Eugene Lazutkin 
* URL : https://github.com/heya/globalize
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Convert JavaScript files using UMD or AMD global

 The "heya-globalize" package is a tool that transforms JavaScript modules
 written in UMD Heya style or plain AMD style into different formats. It can
 generate JavaScript modules that utilize global browser dependencies and
 exports. These modules can be directly included in HTML pages using the
 

Bug#1052296: RM: php-psr-log-test -- ROM; Already packaged under another name

[David Prévot]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: php-psr-log-t...@packages.debian.org, Debian PHP PEAR Maintainers 

Control: affects -1 + src:php-psr-log-test

Hi,

Seems like I missed that Athos already packaged php-fig-log-test when I
introduced this package… Please, remove php-psr-log-test from the
archive, it’s already available (under another slightly, but probably
better, name).

Regards,

David


signature.asc
Description: PGP signature

Bug#1052295: RM: xmlrpc-light -- RoQA; dead upstream; low popcon; FTBFS with OCaml 4.14.1

[Stéphane Glondu]

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

Dear FTP Team,

The last upstream release of xmlrpc-light dates back to 2009 and it
seems that upstream did not bother to move elsewhere since the demise
of code.google.com. Patches accumulate in Debian packaging to keep it
compilable as Debian evolves. It now fails to build from source with
OCaml 4.14.1. It does not make sense to me to fix it now.

I think it's time to remove it from Debian.


Cheers,

-- 
Stéphane

Bug#1052294: RM: otags -- RoQA; based on ancient OCaml version; dead upstream; low popcon

[Stéphane Glondu]

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

Dear FTP Team,

The last upstream release of otags dates back to 2017 and OCaml 4.05.0
(which is the version from oldoldstable). Even though I "ported" it to
more recent OCaml versions thanks to ocaml-migrate-parsetree, new
syntax introduced since then is not supported to the point that I
wonder if it makes sense to port it to 4.14.1, whose transition is
being prepared.

Besides, ocaml-merlin is a better replacement (although not drop-in).

I think it's time to remove otags from Debian.


Cheers,

-- 
Stéphane

Bug#1052293: RM: gmetadom -- RoQA; unmaintained; low popcon; FTBFS with OCaml 4.14.1

[Stéphane Glondu]

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

Dear FTP Team,

The gmetadom package has had no human maintainers since 2011. Its last
upstream release dates back to 2006. It has low popcom, no reverse
dependencies, and seems absent from OPAM, and now fails to build from
source with OCaml 4.14.1.

I think it's time to remove it from Debian.


Cheers,

-- 
Stéphane

Bug#1052116: initscripts: /etc/rcX.d symlinks not created

[Kevin Ruml]

   >On Tuesday, September 19, 2023 at 02:17:55 AM CDT, Mark Hindley 
 wrote:  >
 >
 >On Tue, Sep 19, 2023 at 07:29:45AM +0100, Mark Hindley wrote:>> > Setting up 
 >initscripts (3.08-1) ...>> > Setting up udev (254.3-1) ...>> >> The udev 
 >postinst, which removes the update-rc.d symlinks is  run after the>> 
 >initscripts postinst which has created them.>>Just so I can be sure that 
 >there isn't a bug in the initscripts postinst, having>upgraded to initscripts 
 >3.08-1, can you run> >dpkg-reconfigure initscripts>>and verify that the 
 >symlinks are recreated?>>Thanks>>>Mark
I know you sent subsequent messages about a fix, but since you asked me to test 
this and it was easy enough for me to do it, I did.  Downgrading then upgrading 
again left the system without the symlinks.  Running "dpkg-reconfigure 
initscripts" did generate the symlinks.

Thanks,Kevin
  

Bug#1052292: inkscape: missing Breaks+Replaces: inkscape-open-symbols (<< 1.3)

[Andreas Beckmann]

Package: inkscape
Version: 1.3+ds-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../8-inkscape_1.3+ds-1_amd64.deb ...
  Unpacking inkscape (1.3+ds-1) over (1.2.2-2+b1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-Hgag5N/8-inkscape_1.3+ds-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/inkscape/symbols/sjjb-amenity.svg', which is 
also in package inkscape-open-symbols 1.2.1-1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-Hgag5N/8-inkscape_1.3+ds-1_amd64.deb


cheers,

Andreas


inkscape-open-symbols=1.2.1-1_inkscape=1.3+ds-1.log.gz
Description: application/gzip

Bug#1049380: RM: gliv -- RoQA; unmaintained; depends on gtk2

[Bastian Germann]

Control: severity -1 normal
Control: reassign -1 ftp.debian.org

Please remove gliv. It is unmaintained both upstream and in Debian.
Also, it depends on the deprecated gtk2.

Bug#1044138: RM: pcmanx-gtk2 -- RoQA; dead upstream; depends on gtk2

[Bastian Germann]

Control: severity -1 normal
Control: reassign -1 ftp.debian.org

Please remove pcmanx-gtk2. It is dead upstream, unmaintained in Debian,
and depends on the deprectated gtk2.

Bug#1052291: ITP: r-cran-writexl -- GNU R package for export Excel xlsx format

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-writexl
  Version : 1.4.2
  Upstream Author : Jeroen Ooms 
* URL or Web page : https://cran.r-project.org/package=writexl
* License : BSD-2
  Description : GNU R package to write xlsx file

This zero-dependency export helper package is now a dependency of package rio
(aka r-cran-rio) which has been in Debian since May 2018.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Sun, 17 Sept 2023 at 18:53, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > Let me clarify, here I meant something much simpler - the image
> > installed is a 'normal' one, with r/w root and managed by apt as usual
> > (ie: not immutable image-based) but with a repart.d snippet that causes
> > a new /var to be created on-the-fly on first boot if missing, with
> > tpm-bound encryption (and similar treatment for /home, although
> > unrelated here). This is a very low-hanging fruit of a pattern that
> > would allow to achieve decent local data protection on an otherwise
> > pretty much vanilla setup. But if you need to ship /var from packages,
> > then it goes out of the window.
>
> I don't see how shipping empty directories in a deb package affects this
> in any way.  You're going to have to be considerably more specific about
> what invariant is being violated or what error you're expecting.

How could it _not_ affect it? You'd have two separate components
stepping on each other's toes and claiming ownership of the same
resources, with no hope of having any real synchronization apart from
manually crafting it and hoping for the best, assuming it's even
possible - how can one even express things like aging, acls, xattrs,
and all the other things that tmpfiles.d can do, via dpkg? On top of
that, the point is to be able to keep a consistent system at all times
- but the package tree is going to be immediately inconsistent. If I
wanted to work against the system, I would just do that. The purpose
was to keep things coherent instead.

> > I don't think it is particularly useful, and mixing package content
> > with variable data smells like trouble to me.
>
> I understand that you don't like the idea.  You've made that very clear.
> However, we are *currently* doing this, so obviously nothing that we
> currently support is going to break from continuing to do this.

It doesn't seem to me that we really are though: on my bookworm laptop
I have 5357 packages installed, which ship in total 196 unique
directories under /var, so 1 pkg out of 27 actually does it. I have
4487 unique directories under /var, 20 times as many as they are
shipped by packages.

> > We are working on that. This means that tmpfiles.d would be able to both
> > create the files/dirs when needed, and remove them when unneeded, ie on
> > purge - as far as I can tell, that would be the only useful thing that a
> > dpkg integration would provide.
>
> dpkg -S is the most useful feature this supports for me personally (and
> some related things, such as cruft-finding).

We could add a systemd-tmpfiles --inventory or so, that outputs the
same, with a json mode too, if it could be useful. Give it paths, it
gives out a list of tmpfiles.d that touch them, which then you can
trace back to their packages.

> > On the contrary I suspect it would break things or at the very least get
> > in the way, as explained above. Of course I haven't tested this as we
> > aren't there yet, so can't be 100% sure. But from what I've seen from
> > some experiments, expectations around /var being fixed and
> > package-managed is already creating some headaches, and requiring
> > workarounds.
>
> Specifics!  Specifics!  My kingdom for specifics!  :)  Bug numbers for
> these headaches would be helpful, or detailed descriptions, or
> *something*.  You're giving me nothing to work with here, which means that
> I'm likely to go forward with requiring some of these empty directories be
> registered with dpkg because that's the less invasive change and avoids a
> regression.

I'm afraid that would require significantly more time that I have
available, so I just can't give you a working prototype anytime soon.

Bug#920111: Updating the cscope Uploaders list

[tony mancill]

On Wed, Sep 20, 2023 at 12:16:10AM +0200, Bastian Germann wrote:
> Control: tags -1 pending
> X-Debbugs-Cc: tmanc...@debian.org
> 
> Tony, would you please upload a new version of the package including the 
> following commit?
> https://salsa.debian.org/debian/cscope/-/commit/86d078bee598db0d87634cd53d82f2d868bee68c

Hello Bastian, 

Yes, gladly!  Thank you for the reminder.

Cheers,
tony

Bug#1050547:

[Hor Jiun Shyong]

Hi,  on 17 Sep, I have reinstall gnome-shell. An additional new package
package was installed too:  policykit-1-gnome:amd64 (0.105-8, automatic)

The issue was resolved and GNOME gdm3 is able to start successfully.  Below
are the packages involved. Thanks.

Start-Date: 2023-09-17  12:17:15
Commandline: apt-get remove gnome-shell -V
Install: policykit-1-gnome:amd64 (0.105-8, automatic)
Remove: gnome-shell-extensions:amd64 (44.0-2), gnome-shell:amd64 (44.4-1),
gdm3:amd64 (45~beta-1), chrome-gnome-shell:amd64 (42.1-4),
gnome-session:amd64 (44.0-4), gnome-browser-connector:amd64 (42.1-4),
gnome-shell-extension-prefs:amd64 (44.4-1)
End-Date: 2023-09-17  12:17:21

Start-Date: 2023-09-17  12:17:44
Commandline: apt-get install gnome-shell -V
Install: gnome-shell:amd64 (44.4-1), gdm3:amd64 (45~beta-1, automatic),
chrome-gnome-shell:amd64 (42.1-4, automatic), gnome-session:amd64 (44.0-4,
automatic), gnome-browser-connector:amd64 (42.1-4, automatic),
gnome-shell-extension-prefs:amd64 (44.4-1, automatic)
End-Date: 2023-09-17  12:17:53


Regards,
Hor Jiun Shyong 何俊雄
+60-16-2089567

Bug#848571: Updating the wondershaper Uploaders list

[Bastian Germann]

Control: retitle -1 O: wondershaper -- Easy to use traffic shaping script
Control: reassign -1 wnpp

As Vince was the only Maintainer/uploader of the package, oprhan the package 
now.

Description: Easy to use traffic shaping script
 An easy to use traffic shaping script that provides these improvements:
  * Low latency for interactive traffic (and pings) at all times
  * Allow websurfing at reasonable speeds while uploading / downloading
  * Make sure uploads don't hurt downloads
  * Make sure downloads don't hurt uploads

 It does this by:
  * Limiting upload speed slightly, to eliminate queues
  * Limiting download speed, while allowing bursts, to eliminate queues
  * Interactive traffic skips the queue
  * ACKs and tiny packets skip the queue

Bug#1042034: nwchem: FTBFS: ld: cannot find -ldangchang: No such file or directory

[Drew Parsons]

Package: nwchem
Version: 7.0.2-4
Followup-For: Bug #1042034

The problem seems to be specific to mpich, which is a bit peculiar.
The openmpi build remains successful.

Bug#1051735: closed by Bastian Germann (Re: RFP: pysolfc -- A large collection of solitaire card, MaJong, and other games written in Python)

[Arthur Torrey]

Hi, Thanks for looking at this.  Sorry if I didn't follow correct procedures... 
 This side of dealing w/ Debian (or any distro) is new to me.  

Can you give me any pointers on how to find the bugs that are hindering the 
migration to Trixie / Bookworm?  I tried to see if there were any existing 
issues, and couldn't find any, but it is likely that I wasn't looking in the 
right place.

Thanks,
ART

--
Arthur Torrey - 
---

> On 09/19/2023 18:21 GMT Debian Bug Tracking System  
> wrote:
> 
>  
> This is an automatic notification regarding your Bug report
> which was filed against the wnpp package:
> 
> #1051735: RFP: pysolfc -- A large collection of solitaire card, MaJong, and 
> other games written in Python
> 
> It has been closed by Bastian Germann .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Bastian Germann 
>  by
> replying to this email.
> 
> 
> -- 
> 1051735: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051735
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> On Mon, 11 Sep 2023 16:49:33 -0400 Arthur Torrey wrote:
> > This game (or Pysol, which it forks) was in Buster and earlier Debian 
> > versions, and appears to be in Sid, but is NOT in Trixie, or Bookworm.
> Please do not file RFPs for packages that are in sid.
> Instead, please ask on the bugs that hinder the package migration to work on 
> them.Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: arthur_tor...@comcast.net
> 
> * Package name: pysolfc
>   Version : PySolFC v2.21.0.
>   Upstream Contact: Name  I don't know and can't find it
> * URL : https://pysolfc.sourceforge.io
> * License : GPLv3
>   Programming Lang: Python
>   Description : A large collection of solitaire card, MaJong, and other 
> games written in Python
> 
> (copied from website)
> PySol Fan Club Edition (PySolFC) is a collection of more than 1000 solitaire 
> card games. It is a fork of PySol Solitaire.
> 
> There are games that use the 52 card International Pattern deck, games for 
> the 78 card Tarock deck, eight and ten suit Ganjifa games, Hanafuda games, 
> Matrix games, Mahjongg games, and games for an original hexadecimal-based 
> deck.
> 
> Its features include a modern look and feel (uses the TTk widget set), 
> multiple card sets and tableau backgrounds, sound, unlimited undo, player 
> statistics, a hint system, demo games, a solitaire wizard, support for user 
> written plug-ins, an integrated HTML help browser, and lots of documentation.
> 
> This game (or Pysol, which it forks) was in Buster and earlier Debian 
> versions, and appears to be in Sid, but is NOT in Trixie, or Bookworm.  There 
> are some old bugs filed against it that I found, but I'm not sure if they 
> were ever solved.  (I am not a dev!)  I have been addicted to playing 
> FreeCell on many systems for years, and this version has IMHO the best 
> interface I've ever encountered.  I have looked at the available packages 
> that say they offer FreeCell, and IMHO they are horrible to play.  I have 
> attempted to follow the instructions on making a local package and have 
> gotten errors I don't understand.  I don't want to make a FrankenDeb, please 
> make this game available

Bug#920111: Updating the cscope Uploaders list

[Bastian Germann]

Control: tags -1 pending
X-Debbugs-Cc: tmanc...@debian.org

Tony, would you please upload a new version of the package including the 
following commit?
https://salsa.debian.org/debian/cscope/-/commit/86d078bee598db0d87634cd53d82f2d868bee68c

Bug#1052058: apt: refuses to downgrade itself to a version that works on the system

[Philippe Grégoire]

Apologies. It seems that usrmerge had not successfully performed the merge 
(another issue). It was installed, as can be seen in my first message, but 
running /usr/lib/usrmerge/convert-usrmerge manually did the trick. It also 
merges /lib*.

Thank you and with my best regards,

On Tue, Sep 19, 2023, at 17:18, David Kalnischkies wrote:
> On Mon, Sep 18, 2023 at 07:56:09PM -0400, Philippe Grégoire wrote:
>> As such, I can no longer install or remove packages since my system is 
>> partitioned. I'd like to point out that the above link does not specifically 
>> mention disk partitioning, but only how files are placed on disk.
>> 
>> Obviously, re-partitioning the system is something I'd like to avoid at the 
>> moment.
>> 
>> Thinking about it, in the long term, due to the merge and how packagers are 
>> expected to be able to address files (e.g. /bin/sh vs /usr/bin/sh), I don't 
>> see any other way than re-partitioning. Re-partitioning will be done by a 
>> future me.
>
> It is sort-of the point of /usr-merge that /usr can be another partition
> instead of having packaged content split over multiple subdirectories
> of / which could all be individual partitions, but only really work if
> you mount them all anyhow… (yes, /etc, /var and all that jazz. People
> have opinions on that, too. Lets focus on the problem we already have
> now instead of pilling additional ones on top).
>
>
> What should be the case is that /usr is a directory and e.g. /bin is
> a symlink to /usr/bin. That is what the apt code is trying to check in
> a somewhat roundabout way with inode as both /usr and /usr/bin should
> point to the same real directory occupying the same inode.
>
>
> That should be the case even if you have /usr on a different partition.
> Are you sure your system is properly merged – as in you haven't unmerged
> it with e.g. dpkg-fsys-usrunmess or prevent the merge to be executed
> automatically by the installation of usrmerge?
>
> In either case, it is probably better to contact a user support list
> to resolve your issue.
>
>
>> P.S. I'm uncertain why /lib isn't also merged with /usr/lib
>
> It is? The code even checks for /sbin, /bin und /lib – but that isn't
> all that /usr-merge entails and APT doesn't really want to be checking
> for everything. Just for some easy to verify truths to ensure nothing
> went south… like it seems to have happened on your system.
>
>
> Best regards
>
> David Kalnischkies
>
> Attachments:
> * signature.asc

Bug#922907: Updating the openmx Uploaders list

[Bastian Germann]

Control: retitle -1 O: openmx -- nano-scale material simulations
Control: reassign -1 wnpp

Nobody of the Science Team cared to fix openmx's RC bug so the package was 
removed from testing 3 years ago.
I am orphaning it now. Please only consider adopting if you can afford the time 
to maintain the package.

Description: package for nano-scale material simulations
 OpenMX (Open source package for Material eXplorer) is a program package for
 nano-scale material simulations based on density functional theories (DFT),
 norm-conserving pseudopotentials and pseudo-atomic localized
 basis functions. Since the code is designed for the realization of
 large-scale ab initio calculations on parallel computers, it is anticipated
 that OpenMX can be a useful and powerful tool for nano-scale material sciences
 in a wide variety of systems such as biomaterials, carbon nanotubes, magnetic
 materials, and nanoscale conductors.

Bug#787963: wdiff: please don't use the same node name two times

[Karl Berry]

Thanks for bringing this to our attention.  The primary wdiff
maintainer (Martin von Gagern) has not been active on the project in
some time so I'm not sure how soon the project will get to it.  

Denver, Martin (Martin, are you there?) - in principle, all GNU packages
should be actively maintained. If you (pl.) no longer have
time/inclination to do so, that's perfectly understandable, but please
write maintain...@gnu.org to tell them you are stepping down. Then they
can at least put up a note that the project is looking for a new
maintainer.
https://www.gnu.org/prep/maintain/html_node/Stepping-Down.html

Since the last wdiff release was in 2014, it seems evident that this is
needed. (maintain...@gnu.org should have been contacting you about the
long time since the last release, but I guess that hasn't happened.)

Thanks,
Karl

Bug#1051374: breaks existing setups using /etc/default/mini-httpd

[Johannes Schauer Marin Rodrigues]

Quoting Alexandru Mihail (2023-09-19 23:41:05)
> > do you have an estimate when you think you can upload this?  This bug has
> > now blocked part of my work in Debian for two weeks and I'm unable to do
> > another release for my package until this bug gets fixed.
> I'm planning to release no later than Friday.

okay, I'll wait. Thank you for your quick reply!

signature.asc
Description: signature

Bug#1051374: breaks existing setups using /etc/default/mini-httpd

[Alexandru Mihail]

Hello,

> do you have an estimate when you think you can upload this?
> 
> This bug has now blocked part of my work in Debian for two weeks and
> I'm unable
> to do another release for my package until this bug gets fixed.
> 
I'm planning to release no later than Friday. I'm also tackling #491078
now, and would prefer to bundle both fixes into 1.30-5 for efficiency
reasons and a cleaner update path.
> If you are short on time I can also NMU mini-httpd with the changes
> to the
> service file I proposed in my last mail.
> 
Is that all right with you ?
> Thanks!
> 
> cheers, josch
Cheers,
Alexandru



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

Bug#1052290: cryptsetup-initramfs: askpass is not executed; cryptroot-unlock fails

[Tj]

Package: cryptsetup-initramfs
Version: 2:2.6.1-4~deb12u1
Severity: important

Discovered this whilst working on a relatively simple test of multiple
LUKS block devices for LUKS.0 + LUKS.1 > btrfs RAID1 @/ - that is a
BTRFS RAID1 using 2 LUKS block devices.

Two files represent SSD1 and SSD2, which each have GPT with:

1: EFI-SP (ef00)
2: LUKS  (8309) for BTRFS
3: LUKS (8309) for swap

added as loop devices and configured. SSD2's EFI-SP partition is not
formatted.
# fallocate -l 12G ssd${x}.raw
# sgdisk --new=... --typecode=... ssd${x}.raw
# losetup --show --partscan --find ssd${x}.raw
mkfs.vfat -F 16 ${SSD1}p1
# next 2 also applied to SSD2
cryptsetup luksFormat --pbkdf pbkdf2 ${SSD1}p2
cryptsetup open ${SSD1}p2 luks-$(UUID_SSD1p2}
mkfs.btrfs -d raid1 -m raid1 /dev/mapper/luks-${UUID_SSD1p2}
/dev/mapper/luks-${UUID_SSD2p2}
mount /dev/mapper/luks-${UUID_SSD1p2} /target
btrfs subvol create /target/@
btrfs subvol create /target/@home
umount /target
mount -o subvol=@ /dev/mapperluks-${UUID_SSD1p2}
debootstrap bookworm /target
# add and configure packages for bootable EFI image

After unmounting and closing devices create a libvirt VM guest using the
two files as virtio storage and configure for UEFI boot.

On startup GRUB correctly opens the LUKS block devices to access vmlinuz
and initrd.img, and its own configuration and modules.

On reaching initialramfs it fails to unlock either of the LUKS devices;
eventually dropping to the shell after reporting:

Error: Timeout reached while waiting for askpass.

After using `break=mount` and investigating with `sh -x
/bin/cryptsetup-unlock` it seems it fails because it is not finding
`askpass` in the process list.

On closer examination and searching I am unable to locate where
/usr/lib/cryptsetup/askpass is actually executed.  `cryptsetup-unlock`
correctly locates the file with [ -f ] and ensures it is executable with
[-x ] but I do not see any attempt to actually execute it.

If needed I can either share the 2 SSD files or a script to build them.

-- System Information:
Debian Release: 12.1
Architecture: amd64 (x86_64)

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 cryptsetup-initramfs depends on:
ii  busybox-static [busybox]1:1.36.0-1~exp1
ii  cryptsetup  2:2.6.1-4~deb12u1
ii  debconf [debconf-2.0]   1.5.82
ii  initramfs-tools [linux-initramfs-tool]  0.143~tj01

Versions of packages cryptsetup-initramfs recommends:
ii  console-setup  1.221
ii  kbd2.5.1-1+b1

Bug#1052058: apt: refuses to downgrade itself to a version that works on the system

[David Kalnischkies]

On Mon, Sep 18, 2023 at 07:56:09PM -0400, Philippe Grégoire wrote:
> As such, I can no longer install or remove packages since my system is 
> partitioned. I'd like to point out that the above link does not specifically 
> mention disk partitioning, but only how files are placed on disk.
> 
> Obviously, re-partitioning the system is something I'd like to avoid at the 
> moment.
> 
> Thinking about it, in the long term, due to the merge and how packagers are 
> expected to be able to address files (e.g. /bin/sh vs /usr/bin/sh), I don't 
> see any other way than re-partitioning. Re-partitioning will be done by a 
> future me.

It is sort-of the point of /usr-merge that /usr can be another partition
instead of having packaged content split over multiple subdirectories
of / which could all be individual partitions, but only really work if
you mount them all anyhow… (yes, /etc, /var and all that jazz. People
have opinions on that, too. Lets focus on the problem we already have
now instead of pilling additional ones on top).


What should be the case is that /usr is a directory and e.g. /bin is
a symlink to /usr/bin. That is what the apt code is trying to check in
a somewhat roundabout way with inode as both /usr and /usr/bin should
point to the same real directory occupying the same inode.


That should be the case even if you have /usr on a different partition.
Are you sure your system is properly merged – as in you haven't unmerged
it with e.g. dpkg-fsys-usrunmess or prevent the merge to be executed
automatically by the installation of usrmerge?

In either case, it is probably better to contact a user support list
to resolve your issue.


> P.S. I'm uncertain why /lib isn't also merged with /usr/lib

It is? The code even checks for /sbin, /bin und /lib – but that isn't
all that /usr-merge entails and APT doesn't really want to be checking
for everything. Just for some easy to verify truths to ensure nothing
went south… like it seems to have happened on your system.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1052289: Mark consul as EOLed for bullseye

[Moritz Muehlenhoff]

Source: debian-security-support
Severity: normal

Hashicorp changed the license for Consul to the BSL and they will only
provide security fixes for the MPLed version until end of the year, as
such Consul should be marked as EOLed for Bullseye in Debian.

Ideally we'd just remove it in the Bullseye point release, but there's
a handful of reverse deps (e.g. Prometheus which has support for Consul)
which would need updates to make that happen, so instead let's simply
mark it as EOLed.

For unstable it can simply be removed once consulfs has been removed
(#1052124), which is the last remaining rdep.

Cheers,
Moritz

Bug#1051146: rust-laurel, upcoming rust-bindgen update.

[Peter Green]

Severity 1051146 serious
Thanks


The new version of rust-bindgen has been uploaded to experimental so people
can test against it. 


The new version of rust-bindgen has now been uploaded to unstable.

Bug#1052288: bullseye-pu: package qemu/1:5.2+dfsg-11+deb11u3

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: q...@packages.debian.org, m...@tls.msk.ru
Control: affects -1 + src:qemu

Various low severity security issues in qemu, debdiff below.
I've tested this on a Bullseye ganeti cluster using the
updated qemu.

Cheers,
Moritz

diff -Nru qemu-5.2+dfsg/debian/changelog qemu-5.2+dfsg/debian/changelog
--- qemu-5.2+dfsg/debian/changelog  2022-05-04 21:50:01.0 +0200
+++ qemu-5.2+dfsg/debian/changelog  2023-09-04 16:11:35.0 +0200
@@ -1,3 +1,19 @@
+qemu (1:5.2+dfsg-11+deb11u3) bullseye; urgency=medium
+
+  * CVE-2021-20196 (Closes: #984453)
+  * CVE-2023-0330 (Closes: #1029155)
+  * CVE-2023-1544 (Closes: #1034179)
+  * CVE-2023-3354
+  * CVE-2021-3930
+  * CVE-2023-3180
+  * CVE-2021-20203 (Closes: #984452)
+  * CVE-2021-3507 (Closes: #987410)
+  * CVE-2020-14394 (Closes: #979677)
+  * CVE-2023-3301
+  * CVE-2022-0216 (Closes: #1014590)
+
+ -- Moritz Mühlenhoff   Mon, 04 Sep 2023 16:11:35 +0200
+
 qemu (1:5.2+dfsg-11+deb11u2) bullseye-security; urgency=medium
 
   * virtio-net-fix-map-leaking-on-error-during-receive-CVE-2022-26353.patch
diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2020-14394.patch 
qemu-5.2+dfsg/debian/patches/CVE-2020-14394.patch
--- qemu-5.2+dfsg/debian/patches/CVE-2020-14394.patch   1970-01-01 
01:00:00.0 +0100
+++ qemu-5.2+dfsg/debian/patches/CVE-2020-14394.patch   2023-08-22 
12:42:56.0 +0200
@@ -0,0 +1,67 @@
+From effaf5a240e03020f4ae953e10b764622c3e87cc Mon Sep 17 00:00:00 2001
+From: Thomas Huth 
+Date: Thu, 4 Aug 2022 15:13:00 +0200
+Subject: [PATCH] hw/usb/hcd-xhci: Fix unbounded loop in
+ xhci_ring_chain_length() (CVE-2020-14394)
+
+The loop condition in xhci_ring_chain_length() is under control of
+the guest, and additionally the code does not check for failed DMA
+transfers (e.g. if reaching the end of the RAM), so the loop there
+could run for a very long time or even forever. Fix it by checking
+the return value of dma_memory_read() and by introducing a maximum
+loop length.
+
+Resolves: https://gitlab.com/qemu-project/qemu/-/issues/646
+Message-Id: <20220804131300.96368-1-th...@redhat.com>
+Reviewed-by: Mauro Matteo Cascella 
+Acked-by: Gerd Hoffmann 
+Signed-off-by: Thomas Huth 
+---
+ hw/usb/hcd-xhci.c | 23 +++
+ 1 file changed, 19 insertions(+), 4 deletions(-)
+
+--- qemu-5.2+dfsg.orig/hw/usb/hcd-xhci.c
 qemu-5.2+dfsg/hw/usb/hcd-xhci.c
+@@ -21,6 +21,7 @@
+ 
+ #include "qemu/osdep.h"
+ #include "qemu/timer.h"
++#include "qemu/log.h"
+ #include "qemu/module.h"
+ #include "qemu/queue.h"
+ #include "migration/vmstate.h"
+@@ -720,9 +721,13 @@ static int xhci_ring_chain_length(XHCISt
+ bool control_td_set = 0;
+ uint32_t link_cnt = 0;
+ 
+-while (1) {
++do {
+ TRBType type;
+-dma_memory_read(xhci->as, dequeue, , TRB_SIZE);
++if (dma_memory_read(xhci->as, dequeue, , TRB_SIZE) != MEMTX_OK) {
++qemu_log_mask(LOG_GUEST_ERROR, "%s: DMA memory access failed!\n",
++  __func__);
++return -1;
++}
+ le64_to_cpus();
+ le32_to_cpus();
+ le32_to_cpus();
+@@ -756,7 +761,17 @@ static int xhci_ring_chain_length(XHCISt
+ if (!control_td_set && !(trb.control & TRB_TR_CH)) {
+ return length;
+ }
+-}
++
++/*
++ * According to the xHCI spec, Transfer Ring segments should have
++ * a maximum size of 64 kB (see chapter "6 Data Structures")
++ */
++} while (length < TRB_LINK_LIMIT * 65536 / TRB_SIZE);
++
++qemu_log_mask(LOG_GUEST_ERROR, "%s: exceeded maximum tranfer ring 
size!\n",
++  __func__);
++
++return -1;
+ }
+ 
+ static void xhci_er_reset(XHCIState *xhci, int v)
diff -Nru qemu-5.2+dfsg/debian/patches/CVE-2021-20196.patch 
qemu-5.2+dfsg/debian/patches/CVE-2021-20196.patch
--- qemu-5.2+dfsg/debian/patches/CVE-2021-20196.patch   1970-01-01 
01:00:00.0 +0100
+++ qemu-5.2+dfsg/debian/patches/CVE-2021-20196.patch   2023-09-04 
16:11:35.0 +0200
@@ -0,0 +1,61 @@
+Combined backport of
+
+From 1ab95af033a419e7a64e2d58e67dd96b20af5233 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
+Date: Wed, 24 Nov 2021 17:15:35 +0100
+Subject: [PATCH] hw/block/fdc: Kludge missing floppy drive to fix
+ CVE-2021-20196
+
+and
+
+From b154791e7b6d4ca5cdcd54443484d97360bd7ad2 Mon Sep 17 00:00:00 2001
+From: =?utf8?q?Philippe=20Mathieu-Daud=C3=A9?= 
+Date: Wed, 24 Nov 2021 17:15:34 +0100
+Subject: [PATCH] hw/block/fdc: Extract blk_create_empty_drive()
+
+--- qemu-5.2+dfsg.orig/hw/block/fdc.c
 qemu-5.2+dfsg/hw/block/fdc.c
+@@ -61,6 +61,12 @@
+ } while (0)
+ 
+ 
++/* Anonymous BlockBackend for empty drive */
++static BlockBackend *blk_create_empty_drive(void)
++{
++return blk_new(qemu_get_aio_context(), 0, BLK_PERM_ALL);
++}
++
+ 

Bug#1052255: libmagic1:amd64: magic.5: warnings and errors from "mandoc -T lint"

[Christoph Biedl]

Control: reopen 1052255

Closed that one by accident, sorry for the mess.



signature.asc
Description: PGP signature

Bug#1051967: closed by David Prévot (Re: [pkg-php-pear] Bug#1051967: php-fig-log-test: ships /usr/share/php/Psr/Log/Test/*.php, already in php-psr-log-test)

[Andreas Beckmann]

Control: reopen -1

On 15/09/2023 01.18, Debian Bug Tracking System wrote:
   dpkg: error processing archive […]/php-psr-log-test_1.1.0-1_all.deb 
(--unpack):
    trying to overwrite […] which is also in package php-fig-log-test 
1.1.0-1


Seems like a false positive: a package trying to overwrite files from 
the same package (and same version…).


These are two distinct packages:

vvv
php-fig-log-test | 1.1.0-1   | experimental | source, all
php-psr-log-test | 1.1.0-1   | unstable | source, all
^^^

Andreas

Bug#1002948: Updating the should.js Uploaders list

[Bastian Germann]

Version: 13.2.3~dfsg-6

Bug#1052287: python-unicodedata2: Fails to build with unicode-data 15.1.0

[Jeremy Bícha]

Source: python-unicodedata2
Version: 14.0.0+ds2-1
Severity: serious
Tags: ftbfs sid trixie upstream
Forwarded: https://github.com/fonttools/unicodedata2/issues/60

python-unicodedata2 fails to build with unicode-data 15.1.0, now in Unstable.

A brief outline of needed changes is provided in the upstream bug report.

Thank you,
Jeremy Bícha

Bug#1052255: libmagic1:amd64: magic.5: warnings and errors from "mandoc -T lint"

[Christoph Biedl]

Control: reopen 1052255D 

Closed that one by accident, sorry for the mess.


signature.asc
Description: PGP signature

Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in

[Markus Koschany]

Hello,

the new Bullseye version of xrdp is identical to the version in Bookworm. Thus
the underlying problem is probably more complex and I don't suspect that
something is wrong with xrdp itself but more likely with a configuration option
or related software packages which do something different than in Bookworm.

I have tried to reproduce the problem on Bullseye with Gnome 3 installed. The
problem here is that gnome-remote-desktop appears to interfere with xrdp, so
I'm not totally sure what is caused by Gnome and what might be a bug in xrdp.
Then I restarted the session with Gnome in Xorg mode and a remote connection to
the xrdp server succeeded. However I got a black background instead of the
normal wallpaper I have. Applications were shown correctly though. 

I definitely need more information about your setup or xrdp in general to debug
this issue. Possible reasons for the behavior may be:

1. TLS / connection problem ? Did you do "adduser xrdp ssl-cert" ? Maybe a new
TLS configuration option in 0.9.21.1?

2. graphic drivers ? I read that hardware accelerated drivers may cause such
problems. Maybe try to disable them and use software rendering only?
LIBGL_ALWAYS_SOFTWARE = true

Please also upload the following log files: 

/var/log/xrdp-sesman.log
/var/log/xrdp.log
~/.xsession-errors

and 

journalctl -S -2m 

or something similar may provide more information about error messages, etc.

~/.xorgxrdp.10.log seems to belong to xorgxrdp. The package is only recommended
but I wonder if the problem is potentially caused by it. xrdp is a build-
dependency which suggests it might need a rebuild? But on the other hand then
recommending the package would be wrong and it should be added to Depends.
Someone else would have stumbled upon this sooner I guess.

Regards,

Markus





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

Bug#1052286: please re-enable building against pkcs5 crate

[Jelmer Vernooij]

Source: rust-pkcs8
Version: 0.10.2+ds-7
Severity: wishlist

Hello,

The pkcs5 crate has entered unstable. Please consider dropping the
2002_pkcs5.patch patch. I've verified that the package still builds without it.

This will enable building of the rsa crate.

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Niels Thykier]

Russ Allbery:

Niels Thykier  writes:


I had a look at the introduction section of Policy to check who the
target audience is.  I cannot find an explicit mention of the target
audience. I suspect there is a conflict here on the content because we
have different audiences in mind for the Policy and the Policy does not
seem to be explicit here.



[...]


Ooo, this is a great framing of the problem.  I have a lot of thoughts
about this.  Unfortunately, I'm not sure if they're actionable thoughts
since my grand vision requires someone to sit down and do some serious
Policy restructuring and produce a radically different document.  But
maybe if I write them all down and enough people feel similarly, it would
be worth doing.  I would love to work on this, I am just afraid that it is
the sort of project that I would start and never finish and thus never
accomplish anything of use.



Indeed, it is definitely the thing I would personally prefer to 
pre-align on before adventuring on something of this scale myself (were 
I in your shoes), so I totally feel your concern about actionability.



I think that ideally Policy targets all three of your audiences, but not
at the same time, and not with the same priority.

I have a lot of problems with the current structure of Policy, to the
extent that it sometimes interferes with my motivation for working on it,
and one of the big ones is that it doesn't follow any structured design
pattern for documentation, such as Divio [1].


I had Divio in an earlier draft of my email - should have kept it! :D


[...]

I think my ideal structure of Policy would have three major parts.

First, there would be Policy for Debian packagers.  This would focus on
the things someone packaging for Debian needs to know, and would be
organized roughly around task.  Example sections here would be:

* Choosing an archive area
* Files on the file system (FHS, ownership, permissions, etc.)
* Writing a debian/control file
* Writing a changelog
* Writing a copyright file
* Packaging a shared library
* Packaging a system service
* Using maintainer scripts

In other words, this section would consist primarily of Divio how-to
guides, with some intermixed Divio explanations.  (Tutorials I think are
outside the scope of Policy and are better handled elsewhere, such as in
debhelper documentation.)

[...]


Interesting choice with the mixing. I was of the understanding that the 
idea was one should try to avoid mixing documentation styles according 
to Divio. Admittedly, I find it hard to fully stick to exactly one type 
of style, so I would be happy if I had just overlooked the "advice on 
mixing".


As for the content: The "How-to" style would make sense for the target 
audience.  I am less clear if all of these headlines makes up a "Policy" 
as they sounds like something you could find in a "Debian Packaging 101" 
guide.  That is a "risk" (or maybe exactly what you are going for), 
which would be fine with me and I would support the idea.


Nevertheless, I feel it has quite some potential to make Policy more 
accessible to new contributors and that alone is worth supporting in my 
book. Though I am hardly the target audience nor "paying the upkeep 
cost", so supporting it is basically gratis for me.





[...]

Second section would be Policy the reference manual for interfaces in the
distribution.  Sections here would be:

* Complete list of control fields and their meanings.
* Specifications for the .dsc and .changes files (which packagers mostly
   never need to care about, but tool maintainers do).
* The detailed reference documentation on all the ways maintainer scripts
   can be called.
* Specification for the symbols and shlibs files.

This is all Divio reference stuff.  Whenever we have a comprehensive
explanation of the details of something, it goes here, and then we
liberally link to the reference section from the packaging-focused how-to
section for more details.



Makes sense to me as well. I would indeed also need documentation somewhere.

Side question: Does Policy add anything on the specification for 
`symbols` and `shlibs` files as a reference document that is not covered 
by dpkg's documentation for these formats? I assume the "symbols guide" 
(on /when/ to use symbols and when not too) would go in the previous 
section.



Finally, there is the reference manual for toolchain maintainers.  My
position on this is that it's best-effort documentation and should
probably be a non-normative appendix where toolchain maintainers are
relatively free to just make changes without going through a very formal
process as long as those changes reflect reality.  This is, by nature,
going to be incomplete and possibly out of date, but I do think the
project should have *somewhere* outside of any specific package where
people can write down the details of, oh, the other options to
Rules-Requires-Root that we aren't currently using.  But we would stick a
lot of disclaimers on it and make it clear 

Bug#973411: spectre-meltdown-checker: Inconsistent output compared to Debian's security tracker

[Matt Taggart]

Hi Patrick,

spectre-meltdown-checker has had some updates in this detection code 
since you filed this bug. If you still have access to the hardware you 
generated that report on, could you run a newer version and see if it 
fixes your issue?
(also it might be interesting to test with the old microcode if that is 
still installed, and then newer)


Please report back what you find and also lscpu output so we know what 
CPU this is in particular.


Thanks,

--
Matt Taggart
m...@lackof.org

Bug#904044: OpenVPN3

[Bernhard Schmidt]

Hi Marc,

Because our company decided "there will be no impact" to use multifactor 
authentication, I was forced to package openvpn3.


I don't know if you were planning anything in that direction, but my 
current work can be found here:


https://salsa.debian.org/televic-team/openvpn3 



It's rough, I need to go through the finer details.

If you are nog planning anything, I can open an ITP.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044 



Thanks for letting us know. I haven't taken a deep look at it, but it 
looks pretty sane and I'm not aware of any work other than the upstream 
repository. You are certainly welcome to package it.


I can review and sponsor the first uploads if noone beats me to it 
(anyone: feel free to do so, there is no need of the OpenVPN2 
maintainers to specifically review anything in OpenVPN3, and they will 
continue to be used in parallel for years to come).


I've seen you have applied for DM, so I would be happy to give you 
uploader rights when things have settled.


Bernhard

Bug#1052197: sync with xorgxrdp

[Blindauer Emmanuel]

Hello,

The bug is also reported upstream:

https://github.com/neutrinolabs/xrdp/issues/2796

the xorgxrdp package must be updated in sync for the xrdp version

Emmanuel Blindauer

Bug#1052278: clevis-systemd: move systemd units from / to /usr

[Christoph Biedl]

Control: tags 1052278 pending

Helmut Grohne wrote...

> we're trying to finalize the /usr-merge transition. In the process, I
> ask you to move the remaining files from / to /usr. In your source
> package, only two files are affected and both are systemd units. Such a
> move violates the file move moratorium. If you restructure this package
> after applying this patch, please upload to experimental first. dumat[1]
> will look for problems and file an RC bug. For further information,
> please refer to https://wiki.debian.org/UsrMerge and
> https://subdivi.de/~helmut/dep17.html or consider asking.

After some clarification behind the curtain, I'll upload an according
version to experimental in the next hours.

Thanks for work on unmessing the usrmerge story.

Christoph


signature.asc
Description: PGP signature

Bug#1043503: Accepted python-git 3.1.36-1 (source) into unstable

[Salvatore Bonaccorso]

Source: python-git
Source-Version: 3.1.36-1

This upload fixes as well CVE-2023-40267 / #1043503.

On Mon, Sep 18, 2023 at 08:39:50PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Mon, 18 Sep 2023 22:09:04 +0200
> Source: python-git
> Architecture: source
> Version: 3.1.36-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Python Team 
> Changed-By: Hans-Christoph Steiner 
> Changes:
>  python-git (3.1.36-1) unstable; urgency=medium
>  .
>* Team upload.
>* New upstream version 3.1.36
> Checksums-Sha1:
>  160c3306a75acdd0fa514114abd18a77f864f096 2397 python-git_3.1.36-1.dsc
>  ed816f20cf47cf25778bb45c543288df58e15326 486095 python-git_3.1.36.orig.tar.gz
>  2af815d362edd01f1a01c862d5cf0fa5636aaaee 6908 
> python-git_3.1.36-1.debian.tar.xz
>  74ec8194c0076df30d91675728a6240b05097437 8678 
> python-git_3.1.36-1_source.buildinfo
> Checksums-Sha256:
>  3ed1350f5c6923148de5f1a6706f6132c55b5b1d49105a28f42286677076d3d7 2397 
> python-git_3.1.36-1.dsc
>  17655e095db95f6d25affada911b706483075532719ad6df7bbc879e2b8c1838 486095 
> python-git_3.1.36.orig.tar.gz
>  7356abc0d18d823826e7bdab53fcd936baa71d4d0983118edd96ca1331b3db1c 6908 
> python-git_3.1.36-1.debian.tar.xz
>  d20f33a39afb3746e79461083a3229019cefee992148b1ad94e354071987f58f 8678 
> python-git_3.1.36-1_source.buildinfo
> Files:
>  2ff6c912c00fa4b2e84cb9b2b4538301 2397 python optional python-git_3.1.36-1.dsc
>  a8be797f09ac62557c8835fd537eec3b 486095 python optional 
> python-git_3.1.36.orig.tar.gz
>  8d055bc9906e2c35ea9882dad279 6908 python optional 
> python-git_3.1.36-1.debian.tar.xz
>  f2022f547c1f750efa290bc749bcb4d7 8678 python optional 
> python-git_3.1.36-1_source.buildinfo
> 
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEElyI52+aGmfUmwGoFPhd4F7obm/oFAmUIrtwACgkQPhd4F7ob
> m/r/Wwf+PcUuu12rqQsE2u6XzDdj1UstwxnaUc1CLcQsBS5H7OI3aBe63G6p8E/L
> r3AE+Tn2Zpowim9DatGU+Cbfc9yHWtdHlp6oiqqII7RMVMFQf+dObnVGNiOC8aPu
> TMXXMXwrV8AvLg3KTeWj027VPwkbtDDABWujrYyotuwfx8F/CruksvviHWsvG2Z3
> MDj1zPY8yE4XwRCnl6H5IPGWa+h3Fv88kEf4c4HM3+tT4cn4uZ/klBt7t34eIjgB
> 2YT+0L4NLLrmSYCOUv7K/Bk1Y0X1mUpxh7sj3DXxWxf0GgpKCrKGaZNJ+0lUAHqv
> AhSd8jtDJ+SMXLMyPQOTa5CDPLs6kg==
> =7Ffu
> -END PGP SIGNATURE-
> 

Bug#1052282: mythtv-status FTBFS with nocheck profile

[Helmut Grohne]

Source: mythtv-status
Version: 1.1.0-1
Severity: serious
Tags: ftbfs

mythtv-status fails to build from source when built with the nocheck
build profile and option. Since trixie such a failure is considered
release critical, because the autoremover relies on correct nocheck
annotations. A build log looks like it actually runs tests despite the
nocheck option and fails doing so as relevant test dependencies have
been annotated . A very simple workaround for this bug is
dropping all  annotations from debian/control, but actually
skipping tests and thus supporting nocheck would be a better solution.

Helmut

Bug#1051560: jpeg-xl: FTBFS: failing test conformance_tooling_test

[Boyuan Yang]

X-Debbugs-CC: ma...@debian.org

On Sat, 09 Sep 2023 16:04:38 -0400 Boyuan Yang  wrote:
> Source: jpeg-xl
> X-Debbugs-Cc: by...@debian.org
> Version: 0.7.0-10
> Severity: serious
> Tags: ftbfs sid trixie
> 
> Dear Maintainer,
> 
> For jpeg-xl/0.7.0-10, it currently fails to build from source in Debian Sid.
> One of the post-build tests will fail:
> 
> 
>   Start 2874: conformance_tooling_test
> 2874/2874 Test #2874: conformance_tooling_test
> ..***Failed
>     0.15 sec
> + CLEANUP_FILES=()
> + trap 'retcode=$?; { set +x; } 2>/dev/null; cleanup' INT TERM EXIT
> + main /<>/obj-x86_64-linux-gnu /usr/share/libjxl-testdata
> ++ mktemp -d
> + local tmpdir=/tmp/tmp.qnjN0F3yQR
> + CLEANUP_FILES+=("${tmpdir}")
> + python3 -c 'import numpy'
> + local build_dir=/<>/obj-x86_64-linux-gnu
> + [[ -z /<>/obj-x86_64-linux-gnu ]]
> + local decoder=/<>/obj-x86_64-linux-gnu/tools/djxl
> + /<>/tools/conformance/generator.py 
> --decoder=/<>/obj-x86_64-linux-gnu/tools/djxl 
> --output=/tmp/tmp.qnjN0F3yQR --peak_error=0.001 --rmse=0.001
> /usr/share/libjxl-testdata/jxl/blending/cropped_traffic_light.jxl
> /<>/obj-x86_64-linux-gnu/tools/djxl: error while loading shared 
> libraries: libjxl_threads.so.0.7: cannot open shared object file: No such 
> file or directory
> Generating cropped_traffic_light
> Traceback (most recent call last):
>   File "/<>/tools/conformance/generator.py", line 128, in 
>
> main()
>   File "/<>/tools/conformance/generator.py", line 124, in main
> GenerateConformanceCorpus(args)
>   File "/<>/tools/conformance/generator.py", line 70, in 
>GenerateConformanceCorpus
> subprocess.check_call(cmd)
>   File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
> raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command 
> '['/<>/obj-x86_64-linux-gnu/tools/djxl', 
> '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/input.jxl',
> '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/reference_image.npy', 
> '--metadata_out', '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/test.json', 
> '--icc_out',
> '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/reference.icc']' returned non-zero 
> exit status 127.
> + retcode=1
> 
> 
> 99% tests passed, 1 tests failed out of 2872
> 

Just made a little bit investigation.

* Previously the test conformance_tooling_test was skipped since python3-numpy 
was not installed
during build.

* With recent builds, python3-numpy was introduced as build-dependency 
(implicitly) due to
build toolchain changes, thus unskipping the test.

* It looks like upstream has some special handling around such test; please 
check
.github/workflows/conformance.yml .

That being said, I am not sure how should we make a proper fix on this issue. I 
wish the issue
is no longer present in v0.8.x series to be packaged. Hope that those findings 
are useful
to you.

Thanks,
Boyuan Yang


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

Bug#1041451: [Sender Not Verified] Re: Bug#1041451: gmap: FTBFS on all !amd64 archs

[Thomas Wu]

Hi Andreas,

I have decided to restore the non-SIMD binaries.  I have just written code
to do that, and will release a new version once some large-scale test runs
complete successfully.

Thanks,

Thomas Wu



On Tue, Sep 19, 2023 at 8:48 AM Thomas Wu  wrote:

>
> Hi Andreas,
>
> The GMAP package should compile on both Intel and Apple architectures.  I
> think we are now requiring SIMD or its equivalent Neon, though, which is
> why we are no longer building the *.nosimd binaries.  I don't think that's
> a problem since every modern computer supports SIMD or Neon.  Does Debian
> require a non-SIMD target machine?  I will try to look at your bug report
> to understand what is going on.
>
> Thanks,
>
> Thomas Wu
>
>
> On Tue, Sep 19, 2023 at 7:44 AM Andreas Tille  wrote:
>
>> **Warning** The sender address (Andreas Tille ) can not be verified,
>> sender email address could be spoofed. Please take care to proceed.
>> Control: tags -1 upstream
>> Control: forwarded -1 Thomas Wu , Colin K. Watanabe <
>> c...@gene.com>
>>
>>
>> Hi Thomas and Colin,
>>
>> the Debian packaged gmap fails to build since version 2023-06-01 for all
>> release architectures besides amd64.  You can read about this bug on our
>> bug tracker[1].  I think the analysis from Étienne below is a sensible
>> explanation for the issue.
>>
>> It would be really helpful if you could clarify why you disabled SIMD?
>> Does this mean you suggest we should provide gmap for amd64 only?
>>
>> Kind regards
>> Andreas.
>>
>>
>> [1] https://bugs.debian.org/1041451
>>
>> Am Tue, Aug 15, 2023 at 12:42:09PM +0200 schrieb Étienne Mollier:
>> > Hi,
>> >
>> > The relevant part of the error message shows that the generic
>> > fully scalar gmap.nosimd executable is never built for any cpu
>> > architecture:
>> >
>> >   Note: /<>/build/src/gmap.avx2 does not exist.  For
>> faster speed, may want to compile package on an AVX2 machine
>> >   Note: /<>/build/src/gmap.sse42 does not exist.  For
>> faster speed, may want to compile package on an SSE4.2 machine
>> >   Note: /<>/build/src/gmap.sse41 does not exist.  For
>> faster speed, may want to compile package on an SSE4.1 machine
>> >   Note: /<>/build/src/gmap.ssse3 does not exist.  For
>> faster speed, may want to compile package on an SSSE3 machine
>> >   Note: /<>/build/src/gmap.sse2 does not exist.  For
>> faster speed, may want to compile package on an SSE2 machine
>> >   Note: /<>/build/src/gmap.nosimd does not exist.  For
>> faster speed, may want to compile package on an non-SIMD machine
>> >   Error: appropriate GMAP version not found
>> >
>> > Looking into src/Makefile.am, indeed they seem disabled upstream
>> > for the current gmap versions:
>> >
>> >   # intersect-uint2.c requires SIMD
>> >   #bin_PROGRAMS += gmap.nosimd
>> >   #bin_PROGRAMS += gmapl.nosimd
>> >   #bin_PROGRAMS += gsnap.nosimd
>> >   #bin_PROGRAMS += gsnapl.nosimd
>> >
>> > My quick attempts to bring the necessary support in the
>> > aforementioned intersect-uint2.c file were not very fruitful so
>> > far.  Something in there looks to prevent use of simde.
>> >
>> > Anyways, in hope this helps further investigations,
>> > --
>> >   .''`.  Étienne Mollier 
>> >  : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
>> >  `. `'   sent from /dev/pts/4, please excuse my verbosity
>> >`-
>>
>>
>>
>> > ___
>> > Debian-med-packaging mailing list
>> > debian-med-packag...@alioth-lists.debian.net
>> >
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>>
>>
>> --
>> http://fam-tille.de
>>
>>

Bug#1052281: apt: Configuration::checkUsrMerged does not check st_dev

[Jean Privat]

Package: apt
Version: 2.6.1
Severity: normal
X-Debbugs-Cc: jean.pri...@gmail.com

Dear Maintainer,

https://salsa.debian.org/apt-team/apt/-/blob/main/apt-
pkg/aptconfiguration.cc#L559 shows that `st_ino` is used to check that `/foo`
and `/usr/foo` entries resolve to the same inode.
However it does not check that the inode are on the same file system.

While usually unlikely, it's possible that both entries give a same inode
number but on two different devices, then possibly break the whole Debian
installation.

A simple fix could be to also check the `st_dev` field.

- if (root.st_ino != usr.st_ino)
+ if (root.st_ino != usr.st_ino || root.st_dev != usr.st_dev)


-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/docker.list present, but not submitted) --


-- (/etc/apt/sources.list.d/google-chrome.list present, but not submitted) --


-- (/etc/apt/sources.list.d/lutris.list present, but not submitted) --


-- (/etc/apt/sources.list.d/nordvpn.list present, but not submitted) --


-- (/etc/apt/sources.list.d/steam-beta.list present, but not submitted) --


-- (/etc/apt/sources.list.d/steam-stable.list present, but not submitted) --


-- (/etc/apt/sources.list.d/teams.list present, but not submitted) --


-- (/etc/apt/sources.list.d/winehq-bullseye.sources present, but not submitted) 
--


-- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (110, 'testing'), (10, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, riscv64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 apt depends on:
ii  adduser 3.134
ii  debian-archive-keyring  2023.3
ii  gpgv2.2.40-1.1
ii  libapt-pkg6.0   2.6.1
ii  libc6   2.36-9+deb12u1
ii  libgcc-s1   12.2.0-14
ii  libgnutls30 3.7.9-2
ii  libseccomp2 2.5.4-1+b3
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.12-1~deb12u1

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.13-5
ii  dpkg-dev1.21.22
ii  gnupg   2.2.40-1.1
ii  gnupg2  2.2.40-1.1
ii  powermgmt-base  1.37
ii  synaptic0.91.3

-- no debconf information

Bug#1052280: ITP: erlang-hex -- Package manager for the Erlang ecosystem

[John Lines]

Package: wnpp
Severity: wishlist
Owner: John Lines 
X-Debbugs-Cc: debian-de...@lists.debian.org, j...@paladyn.org

* Package name: erlang-hex
  Version : 2.0.5
* URL : https://github.com/hexpm/hex
* License : Apache-2.0
  Programming Lang: Elixir
  Description : Package manager for the Erlang ecosystem

Hex is package manager required to build Pleroma (a Federated
Social Media application).

It is primarily intended as a stepping stone towards a pleroma
package

Bug#1019033: Updating the closure-compiler Uploaders list

[Bastian Germann]

Version: 20130227+dfsg1-11

Bug#1052279: biometryd-bin: move files from / to /usr

[Helmut Grohne]

Package: biometryd-bin
Version: 0.3.0-3
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

we're trying to finalize the /usr-merge transition. In the process, I
ask you to move the remaining files from / to /usr. In your source
package, only one systemd unit is affected. Such a move violates the
file move moratorium. If you restructure this package after applying
this patch, please upload to experimental first. dumat[1] will look for
problems and file an RC bug. For further information, please refer to
https://wiki.debian.org/UsrMerge and
https://subdivi.de/~helmut/dep17.html or consider asking.

Helmut

[1] https://salsa.debian.org/helmutg/dumat

diff -Nru biometryd-0.3.0/debian/biometryd-bin.install 
biometryd-0.3.0/debian/biometryd-bin.install
--- biometryd-0.3.0/debian/biometryd-bin.install2023-01-10 
19:54:23.0 +0100
+++ biometryd-0.3.0/debian/biometryd-bin.install2023-09-19 
16:38:18.0 +0200
@@ -1,3 +1,3 @@
 usr/bin/biometryd
 etc/dbus-1/system.d/
-lib/systemd/system/
+lib/systemd/system/ usr/lib/systemd
diff -Nru biometryd-0.3.0/debian/changelog biometryd-0.3.0/debian/changelog
--- biometryd-0.3.0/debian/changelog2023-07-27 03:27:09.0 +0200
+++ biometryd-0.3.0/debian/changelog2023-09-19 16:38:20.0 +0200
@@ -1,3 +1,10 @@
+biometryd (0.3.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move files from / to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 19 Sep 2023 16:38:20 +0200
+
 biometryd (0.3.0-3) unstable; urgency=medium
 
   [ Mike Gabriel ]

Bug#1052278: clevis-systemd: move systemd units from / to /usr

[Helmut Grohne]

Package: clevis-systemd
Version: 19-3
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Hi,

we're trying to finalize the /usr-merge transition. In the process, I
ask you to move the remaining files from / to /usr. In your source
package, only two files are affected and both are systemd units. Such a
move violates the file move moratorium. If you restructure this package
after applying this patch, please upload to experimental first. dumat[1]
will look for problems and file an RC bug. For further information,
please refer to https://wiki.debian.org/UsrMerge and
https://subdivi.de/~helmut/dep17.html or consider asking.

Helmut

[1] https://salsa.debian.org/helmutg/dumat
diff -Nru clevis-19/debian/changelog clevis-19/debian/changelog
--- clevis-19/debian/changelog  2023-07-23 12:04:17.0 +0200
+++ clevis-19/debian/changelog  2023-09-19 16:14:51.0 +0200
@@ -1,3 +1,10 @@
+clevis (19-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move remaining files from / to /usr (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 19 Sep 2023 16:14:51 +0200
+
 clevis (19-3) unstable; urgency=medium
 
   * Retire versioned dependencies met even in oldstable
diff -Nru clevis-19/debian/clevis-systemd.install 
clevis-19/debian/clevis-systemd.install
--- clevis-19/debian/clevis-systemd.install 2023-01-28 11:43:54.0 
+0100
+++ clevis-19/debian/clevis-systemd.install 2023-09-19 16:14:32.0 
+0200
@@ -1,5 +1,5 @@
 
-lib/systemd/system/clevis-luks-askpass.path
-lib/systemd/system/clevis-luks-askpass.service
+lib/systemd/system/clevis-luks-askpass.path usr/lib/systemd/system
+lib/systemd/system/clevis-luks-askpass.service usr/lib/systemd/system
 
 usr/libexec/clevis-luks-askpass

Bug#1052277: heartbeat FTBFS when systemd_system_unit_dir changes

[Helmut Grohne]

Source: heartbeat
Version: 1:3.0.6-13
Tags: ftbfs patch
User: helm...@debian.org
Usertags: dep17m2

We want to change the value of systemd_system_unit_dir in systemd.pc to
reside below /usr as part of the changes proposed in DEP17. When doing
so, heartbeat will FTBFS, because debian/rules hard codes its location
to /lib. I'm proposing a patch that makes it not FTBFS and currently is
a noop (it reproduces the same packages as without). Would you mind
applying it to avert that future FTBFS?

Helmut
diff -Nru heartbeat-3.0.6/debian/changelog heartbeat-3.0.6/debian/changelog
--- heartbeat-3.0.6/debian/changelog2022-04-02 00:34:24.0 +0200
+++ heartbeat-3.0.6/debian/changelog2023-09-19 17:04:22.0 +0200
@@ -1,3 +1,10 @@
+heartbeat (1:3.0.6-13.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with changed systemd_system_unit_dir. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 19 Sep 2023 17:04:22 +0200
+
 heartbeat (1:3.0.6-13) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru heartbeat-3.0.6/debian/control heartbeat-3.0.6/debian/control
--- heartbeat-3.0.6/debian/control  2022-04-02 00:19:57.0 +0200
+++ heartbeat-3.0.6/debian/control  2023-09-19 17:04:22.0 +0200
@@ -35,6 +35,7 @@
  net-tools,
  openssh-client,
  perl,
+ pkgconf,
  psmisc,
  python3-dev,
  resource-agents,
diff -Nru heartbeat-3.0.6/debian/heartbeat.install 
heartbeat-3.0.6/debian/heartbeat.install
--- heartbeat-3.0.6/debian/heartbeat.install2022-04-02 00:28:01.0 
+0200
+++ heartbeat-3.0.6/debian/heartbeat.install2023-09-19 17:04:22.0 
+0200
@@ -1,3 +1,4 @@
+etc/init.d/heartbeat
 etc/ha.d/README.config
 etc/ha.d/harc
 etc/ha.d/rc.d/ask_resources
@@ -30,8 +31,10 @@
 etc/ha.d/resource.d/portblock
 etc/heartbeat
 etc/logrotate.d/heartbeat
+${env:systemd_system_unit_dir}/heartbeat.service
 usr/bin/cl_respawn
 usr/bin/cl_status
+usr/lib/tmpfiles.d/heartbeat.conf
 usr/libexec/heartbeat/api_test
 usr/libexec/heartbeat/apphbd
 usr/libexec/heartbeat/apphbtest
diff -Nru heartbeat-3.0.6/debian/rules heartbeat-3.0.6/debian/rules
--- heartbeat-3.0.6/debian/rules2022-04-02 00:28:53.0 +0200
+++ heartbeat-3.0.6/debian/rules2023-09-19 17:04:22.0 +0200
@@ -24,6 +24,8 @@
 DH_INSTALL_EXCLUDE=-Xdopd -Xdrbd
 endif
 
+export systemd_system_unit_dir=$(shell pkgconf 
--variable=systemd_system_unit_dir systemd | sed 's,^/,,' )
+
 build: build-arch build-indep
 build-arch: build-stamp
 build-indep: build-stamp
@@ -101,14 +103,6 @@
rm -rf ./debian/libheartbeat2-dev/usr/include/heartbeat/ha_msg.h
rm -rf ./debian/libheartbeat2-dev/usr/include/heartbeat/compress.h
 
-   # move sysv init script and systemd service file to expected locations 
for dh_install
-   ! test -e ./debian/tmp/usr/lib/tmpfiles.d/heartbeat.conf || \
-   mv ./debian/tmp/usr/lib/tmpfiles.d/heartbeat.conf 
./debian/heartbeat.tmpfiles
-   ! test -e ./debian/tmp/lib/systemd/system/heartbeat.service || \
-   mv ./debian/tmp/lib/systemd/system/heartbeat.service 
./debian/heartbeat.service
-   ! test -e ./debian/tmp/etc/init.d/heartbeat || \
-   mv ./debian/tmp/etc/init.d/heartbeat ./debian/heartbeat.init
-
# python modules will be compiled in postinst
rm -f ./debian/tmp/usr/share/heartbeat/cts/*.py[co]
rm -rf ./debian/tmp/usr/share/heartbeat/cts/__pycache__

Bug#1043075: python3-openstackdocstheme: Incompatible with Sphinx 7

[Dmitry Shachnev]

Hi,

On Sat, Aug 05, 2023 at 09:48:50PM +0300, Dmitry Shachnev wrote:
> Package: python3-openstackdocstheme
> Version: 1.20.0-5
> Severity: important
> Tags: upstream
>
> Dear Maintainer,
>
> When doing a rebuild of all reverse-dependencies against Sphinx 7.1 (which is
> currently available in experimental), we noticed that 104 packages FTBFS with
> "dh_sphinxdoc: error: .../_static/underscore.js is missing" error [1].
>
> All of these packages build-depend on python3-openstackdocstheme (except for
> masakari, which build-depends implicitly via python3-os-api-ref).
>
> The problem is that openstackdocstheme lists Sphinx' own JS files explicitly,
> which may change from release to release. To fix this, please:
>
> 1. Upgrade to the latest upstream release (at least >= 2.3.0), that inherits
>from basic/layout.html instead of doing an own HTML template from scratch.
>
> 2. Cherry-pick the change [2] that I have just submitted upstream, to stop
>listing Sphinx JS files explicitly.

There is a new release, 3.2.0, which includes my changes and another upstream
change for Sphinx 7.2.

Please upgrade to that release, it is the biggest remaining blocker for having
Sphinx 7.x in unstable.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1037878: ultracopier: diff for NMU version 2.2.6.0-1.1

[alpha_one_x86]

Hi,

Please update to version 2.2.6.8, have critical bug fix for Unix/Linux 
system (enable able to manipulate non latin char like japan char)


alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server 
management
IT, OS, technologies, research & development, security and business department

On 9/10/23 04:47, Thomas Preud'homme wrote:

Thanks, much appreciated. Feel free to upload it right away.

Best regards,
Thomas


On 10 September 2023 09:12:35 WEST, Marcos Talau  wrote:

Control: tags 1037878 + patch Control: tags 1037878 + pending Dear
maintainer, I've prepared an NMU for ultracopier (versioned as
2.2.6.0-1.1) and uploaded it to DELAYED/2. Please feel free to
tell me if I should delay it longer. Regards.

Bug#1052276: ITP: jbig2enc -- encoder for JBIG2

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: jbig2enc
  Version : 0.29
  Upstream Contact: https://github.com/agl/jbig2enc/issues
* URL : https://github.com/agl/jbig2enc
* License : Apache-2.0
  Programming Lang: C++
  Description : encoder for JBIG2

 jbig2enc is an encoder for JBIG2.
 .
 JBIG2 encodes bi-level (1 bpp) images
 using a number of clever tricks to get better compression than G4.
 This encoder can:
  * Generate JBIG2 files, or fragments for embedding in PDFs
  * Generic region encoding
  * Perform symbol extraction, classification and text region coding
  * Perform refinement coding and,
  * Compress multipage documents

This package is optionally used by ocrmypdf.
It will be maintained in the collaborative debian section of Salsa, at
.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUJ6jkACgkQLHwxRsGg
ASGyLw/9GCokfYiMAMMLLRZLA+auOpPNSPOWOATunsucWm1S9Z3Bbai0ELzaTyUM
E0lIf4KT+TjTMEk0aFgKMpQ6EbcGUPpjn3Rq/Zv/UuC+WZCPcWH7S9THuJ6K8HjJ
JamsKksLQ9F0atN48d/9iI57cOt96DL3je0Gcy5gj9ZaV3FpNRR3SahcL3w9Vy+M
W52R/JuWrHf8jRXwIXXltPvSQ5UmO22pVLvvN6RpB3n+k4SU4IhUHq8yj7DFlJ27
GIKBLJluWq0ZWJlBQVzwptQNMTSurdy4NuM3mzTOXjPNPw3LCMg5WzX3WDZCotTD
en4+qYj3oTiKrDL8ZBKAQzTtVxQupXlr0d0JYMGkzFCAAvCtBZDWR5lXYRcUWYKh
rlXtzReC7cecgeUh6YI/B0e+D4uW0mKzuwNMxu1E3Ol9vXYIQRS+4MEohRN602RF
qf6ertUoweMBKVf/8dQjCU+wsFjS1YU2X3JtDqU6b2mFTwdSSvylABLJyIAyvtYT
hUOEoXad1tfZtJM8LNasVYRHZpg675BKkdypS+asfj03xLT+HbJNCmxnzLTIkJZ+
avWqWHD8+nxwlv9pXKq9HEQx19/uD+FM+sEeyWuLX3oGDUO9RDIelVk6eQpxNSBm
ZRdAHgHaMK3/obUplNXzt9ohw5T5slv5SKUKZir68O3a6yecX5M=
=lc09
-END PGP SIGNATURE-

Bug#1052134: description of the problem

[Carsten Schoenert]

Hello Nikolay,

Am 18.09.23 um 01:22 schrieb Nikolay Sabelnikov:

how the problem can be reproduced. try to log in to Yandex mail if
2-factor protection is configured, through the application on the Yandex
key phone. So first the application password is created, which by the
way will be enough, but for some reason the mail program is trying to
log in through 2-factor protection. In the window that opens, after
trying to log in, a 400 error pops up and that's it. I turned to yandex,
but they sent me to contact Mozilla's contributors. But I'll notify you
first. Maybe they fixed it in the new versions.


this is to me clear a upstream issue and not a Debian packaging related 
issue.


Please open a bug report on

https://bugzilla.mozilla.org/

and give back afterwards the bug number within the Bugzilla instance so 
we can track the progress of the upstream report.


--
Regards
Carsten

Bug#1052275: icingaweb2-module-generictts: Please get debconf templates reviewed on debian-l10n-english

[Helge Kreutzmann]

Source: icingaweb2-module-generictts
Version: 2.1.0-1
Severity: normal
Tags: l10n
X-Debbugs-Cc: Christoph Brinkhaus , hermann-Josef 
Beckers 

The debconf template contains invalid english. Please request review
on debian-l10n-english@l.d.o.

See also:
https://lists.debian.org/debian-l10n-english/2023/09/msg00010.html

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1052274: icingaweb2-module-eventdb: Please get debconf templates reviewed on debian-l10n-english

[Helge Kreutzmann]

Source: icingaweb2-module-eventdb
Version: 1.3.0-3
Severity: normal
Tags: l10n
X-Debbugs-Cc: Christoph Brinkhaus , hermann-Josef 
Beckers 

The debconf template contains invalid english. Please request review
on debian-l10n-english@l.d.o.

See also:
https://lists.debian.org/debian-l10n-english/2023/09/msg00010.html

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1052268: icingaweb2-module-pdfexport: Please get debconf templates reviewed on debian-l10n-english

[Helge Kreutzmann]

Source: icingaweb2-module-pdfexport
Version: 0.10.2+dfsg1-2
Severity: normal
Tags: l10n
X-Debbugs-Cc: Christoph Brinkhaus , hermann-Josef 
Beckers 

The debconf template contains invalid english. Please request review
on debian-l10n-english@l.d.o.

See also:
https://lists.debian.org/debian-l10n-english/2023/09/msg00010.html

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1052273: icingaweb2-module-audit: Please get debconf templates reviewed on debian-l10n-english

[Helge Kreutzmann]

Source: icingaweb2-module-audit
Version: 1.0.2-1
Severity: normal
Tags: l10n
X-Debbugs-Cc: Christoph Brinkhaus , hermann-Josef 
Beckers 

The debconf template contains invalid english. Please request review
on debian-l10n-english@l.d.o.

See also:
https://lists.debian.org/debian-l10n-english/2023/09/msg00010.html

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1052272: icingaweb2-module-x509: Please get debconf templates reviewed on debian-l10n-english

[Helge Kreutzmann]

Source: icingaweb2-module-x509
Version: 1:1.1.2-1
Severity: normal
Tags: l10n
X-Debbugs-Cc: Christoph Brinkhaus , hermann-Josef 
Beckers 

The debconf template contains invalid english. Please request review
on debian-l10n-english@l.d.o.

See also:
https://lists.debian.org/debian-l10n-english/2023/09/msg00010.html

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1052271: icingaweb2-module-reporting: Please get debconf templates reviewed on debian-l10n-english

[Helge Kreutzmann]

Source: icingaweb2-module-reporting
Version: 0.10.0-1
Severity: normal
Tags: l10n
X-Debbugs-Cc: Christoph Brinkhaus , hermann-Josef 
Beckers 

The debconf template contains invalid english. Please request review
on debian-l10n-english@l.d.o.

See also:
https://lists.debian.org/debian-l10n-english/2023/09/msg00010.html

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1052270: icingaweb2-module-idoreports: Please get debconf templates reviewed on debian-l10n-english

[Helge Kreutzmann]

Source: icingaweb2-module-idoreports
Version: 0.10.0-1
Severity: normal
Tags: l10n
X-Debbugs-Cc: Christoph Brinkhaus , hermann-Josef 
Beckers 

The debconf template contains invalid english. Please request review
on debian-l10n-english@l.d.o.

See also:
https://lists.debian.org/debian-l10n-english/2023/09/msg00010.html

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1052269: icingaweb2-module-boxydash: Please get debconf templates reviewed on debian-l10n-english

[Helge Kreutzmann]

Source: icingaweb2-module-boxydash
Version: 0.0.1+20160321-4
Severity: normal
Tags: l10n
X-Debbugs-Cc: Christoph Brinkhaus , hermann-Josef 
Beckers 

The debconf template contains invalid english. Please request review
on debian-l10n-english@l.d.o.

See also:
https://lists.debian.org/debian-l10n-english/2023/09/msg00010.html

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1052267: getconf.1: "mandoc -T lint" shows some warnings

[Bjarni Ingi Gislason]

Package: libc-bin
Version: 2.37-8
Severity: minor

Dear Maintainer,

"mandoc -T lint" shows these messages:

mandoc: getconf.1:43:15: WARNING: undefined string, using "": Tr
mandoc: getconf.1:85:14: STYLE: whitespace at end of input line
mandoc: getconf.1:87:19: STYLE: whitespace at end of input line

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

Kernel: Linux 6.4.13-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc-bin depends on:
ii  libc6  2.37-8

Versions of packages libc-bin recommends:
ii  manpages  6.03-2

libc-bin suggests no packages.

-- no debconf information

Bug#1008708: Regarding pysolfc embedding a python module

[Bastian Germann]

On Tue, 6 Sep 2022 10:10:30 -0300 Athos Ribeiro wrote:

As I commented in a similar bug in Ubuntu [1], while the fix for this
issue is available upstream and seems technically straightforward, it
injects a deprecated python module in its code base and re-licenses it
as CC0.

Only the changes to the file are licensed under CC0, which is clarified by
https://github.com/shlomif/PySolFC/commit/f0fb0500ddc35bd34ec6f0ee136342e32f0a3403

Bug#1052266: kdiskmark: please change short description

[Ben Tris]

Package: kdiskmark
Severity: minor
X-Debbugs-Cc: benatt...@gezapig.nl

Dear Maintainer,
Please do not use "open source" and "for Linux distros"
Please change the short description to the following:

simple disk benchmark tool


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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

Bug#1052265: ldap.conf.5: some remarks and editorial changes for this man page

[Bjarni Ingi Gislason]

Package: libldap-common
Version: 2.5.13+dfsg-5
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and editorial fixes for the manual.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man -t  > 
  nroff -man -t  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z -t - "

instead of "nroff -man"

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint ldap.conf.5":

mandoc: ldap.conf.5:1:2: ERROR: skipping insecure request: lf
mandoc: ldap.conf.5:30:2: WARNING: skipping paragraph macro: PP empty
mandoc: ldap.conf.5:69:61: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:71:58: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:72:58: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:75:61: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:104:9: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:107:10: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:118:9: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:121:65: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:122:65: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:125:1: WARNING: tab in filled text
mandoc: ldap.conf.5:129:1: WARNING: tab in filled text
mandoc: ldap.conf.5:162:2: WARNING: line scope broken: TP breaks TP
mandoc: ldap.conf.5:166:9: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:214:75: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:255:46: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:283:20: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:291:20: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:299:24: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:305:87: STYLE: input text line longer than 80 bytes: Do not 
perform rever...
mandoc: ldap.conf.5:308:88: STYLE: input text line longer than 80 bytes: The 
channel-binding ...
mandoc: ldap.conf.5:310:94: STYLE: input text line longer than 80 bytes: If 
OpenLDAP is built...
mandoc: ldap.conf.5:363:57: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:382:67: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:384:28: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:411:83: STYLE: input text line longer than 80 bytes: This 
parameter is ig...
mandoc: ldap.conf.5:417:83: STYLE: input text line longer than 80 bytes: This 
parameter is ig...
mandoc: ldap.conf.5:475:71: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:479:104: STYLE: input text line longer than 80 bytes: 
parameter to be set
mandoc: ldap.conf.5:530:2: ERROR: skipping insecure request: lf
mandoc: ldap.conf.5:535:62: STYLE: whitespace at end of input line
mandoc: ldap.conf.5:536:2: ERROR: skipping insecure request: lf

-.-.

Input file is ldap.conf.5.

Remove space characters at the end of lines.

69:conventionally written in uppercase, although not required), 
71:The value starts with the first non-blank character after 
72:the option's name, and terminates at the end of the line, 
75:for that option, if any.  Quoting values that contain blanks 
104:.I LDAP 
107:.B ldaps 
118:.B name 
121:is required, nor allowed; note that directory separators must be 
122:URL-encoded, like any other characters that are special to URLs; 
166:.I LDAP 
214:may still apply any server-side limit on the amount of entries that can be 
255:Specifies Cyrus SASL security properties. The 
283:.B minssf= 
291:.B maxssf= 
299:.B maxbufsize= 
363: should be a cipher specification for 
382:With GnuTLS the available specs can be found in the manual page of 
384:(see the description of the 
475:Specifies if the Certificate Revocation List (CRL) of the CA should be 
535:is derived from the University of Michigan LDAP 3.3 Release.  

-.-.

Use "\e" to print the escape character instead of "\\" (which gets
interpreted in copy mode).

89: BASEou=IT staff,o=Example\\2C Inc,c=US

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The 

Bug#1050646: Updating the ekeyd Uploaders list

[Bastian Germann]

And while you are at it: Vincent Sanders has two Uploader entries.
Please reduce it to one.

Bug#587553: Any progress packaging?

[Tassia Camoes Araujo]

Hi Andreas,

Thanks for reaching out!

On 2023-09-13 15:04, Andreas B. Mundt wrote:
> 
> I would like to ask if there is any progress with this ITP.  A friend 
> of mine is using bluej teaching java in his school, that's how I found
> this report and got interested in the current status.  It would be
> nice to have this packaged in Debian.
> 
I had made some progress but got blocked by something I can't remember
now. Sorry for not updating the bug report at the time.

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!

Cheers,

Tassia.

Bug#1051044: Updating the opentk Uploaders list

[Bastian Germann]

Control: retitle -1 O: opentk -- Open Toolkit wrapper for OpenGL, OpenAL and 
OpenCL
Control: reassign -1 wnpp
X-Debbugs-Cc: paul...@debian.org

Without Jo, the package is obviously not maintained anymore.
I am orphaning it now.

Paul, you maintain the only reverse dependency, so you might
want to step up as a new maintainer.

Description: Open Toolkit wrapper for OpenGL, OpenAL and OpenCL
 The Open Toolkit is an advanced, low-level C# library that wraps OpenGL,
 OpenCL and OpenAL. It is suitable for games, scientific applications and
 any other project that requires 3d graphics, audio or compute functionality.

Bug#1042911: (Still?) breaks Emacs 29.1 unattended-upgrade

[Nicholas D Steeves]

On Fri, 15 Sep 2023 14:35:08 +0200 "Farblos"  
wrote:
> Not sure whether this is still relevant or just bad luck or whatever ... my
> unattended-upgrade failed today because of this issue.  Logs available
> on request.  Work-around was to remove version 3.20+dfsg-7, retrigger
> the unattended upgrade, install version 3.20+dfsg-8.

So 3.20+dfsg-7 is broken by emacs29 such that it can only be
uninstalled, and not upgraded.  I'm confident that your logs will show
that the -7 is unpacked but no longer configured.  If you're curious
about what the generated configuration scripts actually do, then check
out this article on how to inspect debs:

https://blog.packagecloud.io/inspect-extract-contents-debian-packages/

To be honest I'm not totally sure why this unconfigured (or not totally
configured) package can't be upgraded, but it can be argued that an
upgrade from an undefined state is an unsafe upgrade.  I mean the "why",
where your logs will show the "what" and the "how" ;)  Also, as
maintainers our responsibility is reliable oldstable -> stable upgrades,
so this kind of transient breakage will sometimes occur in unstable/sid
as well as testing.

> Thanks for taking care of this package, BTW!

Yes, thank you Manphiz!  And Farblos, thank you for reaching out :)
While it's unfortunate that it was for a bug, it's always nice to hear
from real users of mature software.

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1051043: Updating the nuget Uploaders list

[Bastian Germann]

Control: retitle -1 O: nuget -- Package manager for NuGet repos
Control: reassign -1 wnpp

Without Jo, the package is obviously not maintained anymore.
I am orphaning it now.

Description: Package manager for NuGet repos
 NuGet is the package manager for the Microsoft
 development platform including .NET. The NuGet client
 tools provide the ability to produce and consume
 packages. The NuGet Gallery is the central package
 repository used by all package authors and consumers.

Bug#1052264: dash: Fix manpage dashes (ASCII '-' / hyphen / en dash / em dash)

[Peter Samuelson]

Package: dash
Version: 0.5.12-6
Severity: minor
Tags: patch upstream

tl;dr: This patch restores the ability to search manpages for text
containing ASCII hyphens, like "-V" or ">&-", using pagers like "less".

nroff can render 4 distinct dash characters, if non-ASCII output is
supported (as in modern Debian, unless suppressed with, e.g.,
"export MANOPT=-Eascii"):

\-  ASCII hyphen.
Use: Any place one would type a literal ASCII hyphen:
"ls \-F", "$((OPTIND \- 1))", "chdir \-"

-   non-ASCII hyphen
Use: Phrases like "POSIX-compliant", "human-readable", "built-in".
Also used by nroff to break a word of text across 2 lines.

\(enen dash (the width of "n").
Use: Very rare. I think it's a mathematical minus sign, but of
course it's not used in $(( )) shell expressions.

\(emem dash (traditionally, the width of lowercase "m").
Use: To break up grammatical phrases: "the shell executes the
command asynchronously \(em that is, the shell does not wait for
the command to finish"

The - vs. \- distinction especially matters, because if you search for
"<<-" by typing "/<<-" into "less", but nroff has used a non-ASCII
hyphen there, it will not find it.

(Also, some older X11 fonts don't have the non-ASCII dash chars. Though
that has an easy workaround, "MANOPT=-Eascii".)

Thanks,
Peter
From: Peter Samuelson 
Date: Tue, 19 Sep 2023 11:53:05 -0500
Subject: Fix manpage dashes (ASCII '-' / hyphen / en dash / em dash)

Directs nroff to use ASCII "-" to document the shell's uses of "-".
This ensures that expressions like "-V" and ">&-" are searchable using
pagers like "less".

(Also changes some \(en to \(em for correctness, but that is purely
cosmetic.)

--- a/src/dash.1
+++ b/src/dash.1
@@ -124,7 +124,7 @@ An interactive shell generally prompts b
 programming and command errors differently (as described below).
 When first starting,
 the shell inspects argument 0, and if it begins with a dash
-.Sq - ,
+.Sq \- ,
 the shell is also considered
 a login shell.
 This is normally done automatically by the system
@@ -176,7 +176,7 @@ The set
 name is provided next to the single letter option in
 the description below.
 Specifying a dash
-.Dq -
+.Dq \-
 turns the option on, while using a plus
 .Dq +
 disables the option.
@@ -270,7 +270,7 @@ Following is a list of operators:
 .It "Control operators:"
 .Dl &  &&  \&(  \&)  \&;  ;; | || \*[Lt]newline\*[Gt]
 .It "Redirection operators:"
-.Dl \*[Lt]  \*[Gt]  \*[Gt]|  \*[Lt]\*[Lt]  \*[Gt]\*[Gt]  \*[Lt]&  \*[Gt]&  
\*[Lt]\*[Lt]-  \*[Lt]\*[Gt]
+.Dl \*[Lt]  \*[Gt]  \*[Gt]|  \*[Lt]\*[Lt]  \*[Gt]\*[Gt]  \*[Lt]&  \*[Gt]&  
\*[Lt]\*[Lt]\-  \*[Lt]\*[Gt]
 .El
 .Ss Quoting
 Quoting is used to remove the special meaning of certain characters or
@@ -323,14 +323,14 @@ If it does, it replaces it in the input
 For example, if there is an alias called
 .Dq lf
 with the value
-.Dq "ls -F" ,
+.Dq "ls \-F" ,
 then the input:
 .Pp
 .Dl lf foobar Aq return
 .Pp
 would become
 .Pp
-.Dl ls -F foobar Aq return
+.Dl ls \-F foobar Aq return
 .Pp
 Aliases provide a convenient way for naive users to create shorthands for
 commands without having to learn how to create functions with arguments.
@@ -404,12 +404,12 @@ Redirect standard input (or n) from file
 .It [n1] Ns \*[Lt]& Ns n2
 Copy file descriptor n2 as stdout (or fd n1).
 fd n2.
-.It [n] Ns \*[Lt]&-
+.It [n] Ns \*[Lt]&\-
 Close standard input (or n).
 .It [n1] Ns \*[Gt]& Ns n2
 Copy file descriptor n2 as stdin (or fd n1).
 fd n2.
-.It [n] Ns \*[Gt]&-
+.It [n] Ns \*[Gt]&\-
 Close standard output (or n).
 .It [n] Ns \*[Lt]\*[Gt] file
 Open file for reading and writing on standard input (or n).
@@ -433,13 +433,13 @@ subjected to parameter expansion, comman
 expansion (as described in the section on
 .Dq Expansions ) .
 If the operator is
-.Dq \*[Lt]\*[Lt]-
+.Dq \*[Lt]\*[Lt]\-
 instead of
 .Dq \*[Lt]\*[Lt] ,
 then leading tabs in the here-doc-text are stripped.
 .Ss Search and Execution
 There are three types of commands: shell functions, builtin commands, and
-normal programs \(en and the command is searched for (by name) in that order.
+normal programs \(em and the command is searched for (by name) in that order.
 They each are executed in a different way.
 .Pp
 When a shell function is executed, all of the shell positional parameters
@@ -578,11 +578,11 @@ the preceding AND-OR-list.
 .Pp
 Note that unlike some other shells, each process in the pipeline is a
 child of the invoking shell (unless it is a shell builtin, in which case
-it executes in the current shell \(en but any effect it has on the
+it executes in the current shell \(em but any effect it has on the
 environment is wiped).
-.Ss Background Commands \(en &
+.Ss Background Commands \(em &
 If a command is terminated by the control operator ampersand (&), the
-shell executes the command asynchronously \(en that is, the shell does not
+shell executes the command asynchronously \(em that is, the shell does not
 wait 

Bug#1052263: fig2dev: sometimes fig2dev does not insert prolog for UTF-8 fonts into EPS file

[Ilya Ovchinnikov]

Here are attached files

fig_8_1.fig
Description: application/xfig


fig_8_1.fig.bak
Description: application/trash

Bug#1052263: fig2dev: sometimes fig2dev does not insert prolog for UTF-8 fonts into EPS file

[Ilya Ovchinnikov]

Package: fig2dev
Version: 1:3.2.9-1
Severity: normal

Dear Maintainer,

Sometimes fig2dev does not include the prolog for UTF-8 fonts into EPS
file and non-ascii characters display uncorrectly. 
The attached FIG files look equally (the only difference is compount
object) but for one fig2dev gives correct EPS and for another it does
not.

With best regards,
Ilya Ovchinnikov


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

Kernel: Linux 6.4.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 fig2dev depends on:
ii  gawk 1:5.2.1-2
ii  ghostscript  10.01.2~dfsg-1
ii  libc62.37-8
ii  libpng16-16  1.6.40-1
ii  netpbm   2:11.01.00-2
ii  x11-common   1:7.7+23
ii  zlib1g   1:1.2.13.dfsg-3

fig2dev recommends no packages.

Versions of packages fig2dev suggests:
ii  xfig  1:3.2.9-1

-- no debconf information

Bug#1052262: ITP: obs-time-source -- Plugin for OBS Studio that displays current date and time

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, Krystian Chachuła 


* Package name: obs-time-source
  Version : 0.1
  Upstream Contact: Krystian Chachuła <~krystianch/public-in...@lists.sr.ht>
* URL : 
https://obsproject.com/forum/resources/time-and-date-source.1781/
* License : GPL-3
  Programming Lang: C
  Description : Plugin for OBS Studio that displays current date and time

 This plugin provides a source that displays current date and time. It is
 possible to configure the time format, text font, background and text colors
 and outline in source properties.

Bug#1052238: php-net-smtp: fails to send MIME multipart email properly

[Guilhem Moulin]

Control: tag -1 moreinfo

Hi,

On Tue, 19 Sep 2023 at 12:42:34 +0200, J.L. Fernandez Jambrina wrote:
> As php-mail didn't change in the upgrade and I verified the arguments
> to the MAIL::send method are the same in both cases I suspect from the
> underlying php-net-smtp package, but I can be wrong.

php-net-smtp treats the SMTP DATA as an opaque string, please use
setDebug() to see what's being passed to send().

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1052261: librust-pkcs5-dev: impossible to install: depends on missing package librust-scrypt-0.11-dev

[Jonas Smedegaard]

Package: librust-pkcs5-dev
Version: 0.7.1-1+b1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

librust-pkcs5-dev depends on missing package librust-scrypt-0.11-dev
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUJ1HsACgkQLHwxRsGg
ASGCyQ/+KIHJJDQnT6vwGP0i13f7Xo/lF/2ZOw0MBASlV+8a5/520+1YN4QqXAll
u+BCXHCrRyz6Q4OnMsJdCKOBXWWnGOHHW10En6JENWRFRn2xdsp93Vc+2n4mGMx3
6JhI2kobfH5Vlr0wr1bYI1ydnOefyAA5SaHMiAJLHvznisvpbUJaD9U8yVk30ncG
yFBKEBY05u83rzGh27GHDb/+//nBob2i/tOIplWR5ynz8+4T7CKbrGEiV1obVfZu
dNUdixJ4pqsKFS3iyBp4NrPzJXSD+Ne5s02mO+Xy3arOUb2jDw/08B1xMA6ZkbLL
UALEeauPxdUQuKQiJAKxNFfJk7Z0Bab4cNRtim/Uy8t9jrWSLJ49cKwd+J9jfhPa
xMvqyQl68nO1W1P6RXQDOm2WZDNIUOLuMaUULyMjLWXRqOwgwUSs4NLqNpbPh8LI
rPYze43mnvKCG3y/yk28H2LOK6n+4FhEXWsykn5Lf0xL5uec4DKtK/FRh84MB9D1
dmWtdYjgacrHaPzBnBesBwsm0oWl+mup7/4vIXrK1aee+zyMb4Pfkm8e1FYpCqKG
o1T1CeSOfy1u5a7a5eyMHrPHov1oIeFkoumQtZVXGUp+2fkxeq22mg2lSytFFyBk
QbuMKJPc3THsAg4Q6P8AqttFxL5hmxdGc+ZQUnVNvw1nQdMYOe8=
=ewt/
-END PGP SIGNATURE-

Bug#1051797: libtk-img-doc: dpkg extraction error during upgrading

[Andreas Beckmann]

Followup-For: Bug #1051797
Control: found -1 1:1.4.15+dfsg-2

Removing the readme from the -doc package is not sufficient, you also
need to add

   Breaks+Replaces: libtk-img-doc (<< 1:1.4.15+dfsg-2)

to libtk-img in order to properly take over the file on upgrades from
1:1.4.15+dfsg-1 or before.


Andreas

Bug#1052116: initscripts: /etc/rcX.d symlinks not created

[Mark Hindley]

On Tue, Sep 19, 2023 at 08:36:05AM +0100, Mark Hindley wrote:
> Yes. I think the real issue is the udev.postinst using update-rc.d -f remove
> udev. Without the -f option, I think the symlinks would be left intact.

The fix for this has been queued in src:systemd[1].

Mark

[1]  
https://salsa.debian.org/systemd-team/systemd/-/commit/12e2c67612f958148f0a4ca165cfb9ca1ed9d3c3

Bug#1052260: libcpuinfo-dev,libtorch-cuda-dev,libtorch-dev: all ship /usr/include/clog.h

[Andreas Beckmann]

Package: libcpuinfo-dev,libtorch-cuda-dev,libtorch-dev
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict
Control: found -1 0.0~git20220819.8ec7bd9-3
Control: found -1 2.0.1+dfsg-4

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

libcpuinfo and libtorch seem to ship different versions of the same
clog.h header. If this originates from a different project, perhaps it
should be packaged separately.


cheers,

Andreas

Bug#1040906: patch for linuxinfo and hope it proves to be useful.

[Helge Kreutzmann]

Hello JiaLing,
Am Tue, Sep 19, 2023 at 06:03:27PM +0800 schrieb zhangjialing:
>     I've created a patch for this bug, but I'm uncertain about how
> hw->hw_cpuinfo should be handled. I've utilized the CPU Family and Model
> Name. Hope this patch might provide some assistance in addressing this bug.

Thank you very much.

Right now, I'm challenged with real live, so I'm a little slow
respoding to bugs.

I'll inform you once I'm getting around working on this.

And thanks for the patch!

Greetings

Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1052247: Blocks (ana)cron daily jobs and system shutdown for too long

[Holger Levsen]

On Tue, Sep 19, 2023 at 02:33:05PM +0200, Guido Berhoerster wrote:
> There are two possible solutions:
> - a shorter maximum delay
> - stop using anacron and rely on systemd timers which support random delays

I'd prefer the 2nd solution.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Bottled water companies don't produce water, they produce plastic bottles.


signature.asc
Description: PGP signature

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

[Peter B]

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

Dear Maintainer,

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

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

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

GPL-3+
GPLv3+

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


Regards,
Peter B


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

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

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

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

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

-- no debconf information

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Tue, Sep 19, 2023 at 06:13:09PM +0200, gregor herrmann wrote:

On Tue, 19 Sep 2023 17:48:41 +0200, Francesco P. Lovergine wrote:


> Sorry to be a pain again :) but: Do we really need this?

Unfortunately yes for me, it is in the dep chain for Geo::GDAL::FFI, as for
https://wiki.debian.org/BookwormGdalPerl
which is my main goal to avoid to mantain an unofficial repo for the rest
of time.


You mean because of Alien::gdal?

I can't really test now, because Geo::GDAL::FFI also needs the
unpackaged FFI::Platypus::Declare, but from reading
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/Makefile.PL
and
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/README.md
a simple

override_dh_auto_configure:
   dh_auto_configure -- GDAL=/usr

plus build dependencies on gdal-bin (for /usr/bin/gdalinfo) and libgdal-dev
might be enough without any Alien::gdal. Maybe :)

(Not sure about
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/lib/Geo/GDAL/FFI.pm#L1567
but this is also guarded by an if())



Mmmm, let me see. The chain I used was to impact minimally on changes for the 
module
taken from CPAN. I would be happy to minimize the use of all that stuff, I was 
not exactly
enthusiastic about the new course at the time.


--
Francesco P. Lovergine

Bug#1051874: closed by Michael Biebl (Re: Bug#1051874: systemd: XDG_RUNTIME_DIR is not set in X11 login session (MATE/slim))

[Michael Biebl]

Am 15.09.23 um 03:57 schrieb Linas Vepstas:

Hi,

On Thu, Sep 14, 2023 at 12:51 PM Debian Bug Tracking System 
mailto:ow...@bugs.debian.org>> wrote:


I installed a test VM with bookworm and task-mate-desktop and slim.

Everything is working fine.
So I must conclude this is a local (mis)configuration.


The problem manifested after an upgrade from bullseye, and not in a 
fresh bookworm install. I did not perform any local configuration. No 
change from `apt reinstall slim`.


The test VM had a basic bullseye installation (only task "standard")
I upgraded it to bookworm via
apt full-upgrade
then installed MATE via
apt install task-mate-desktop slim
and selected slim as login manager.

You need to provide more specific instructions how this issue can be 
reproduced. Ideally by starting from a fresh, minimal installation.


Michael





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052258: RM: paulstretch -- ROM; RC-buggy; depends on fltk1.1

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:paulstretch

paulstretch is RC-buggy and was working on buster for the last time. Please 
remove it.
It has a low popcon and nobody in the Multimedia Team feels responsible for it. It also depends on 
fltk1.1, which should be removed.

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[gregor herrmann]

On Tue, 19 Sep 2023 17:48:41 +0200, Francesco P. Lovergine wrote:

> > Sorry to be a pain again :) but: Do we really need this?
> 
> Unfortunately yes for me, it is in the dep chain for Geo::GDAL::FFI, as for
> https://wiki.debian.org/BookwormGdalPerl
> which is my main goal to avoid to mantain an unofficial repo for the rest
> of time.

You mean because of Alien::gdal?

I can't really test now, because Geo::GDAL::FFI also needs the
unpackaged FFI::Platypus::Declare, but from reading
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/Makefile.PL
and
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/README.md
a simple

override_dh_auto_configure:
dh_auto_configure -- GDAL=/usr

plus build dependencies on gdal-bin (for /usr/bin/gdalinfo) and libgdal-dev
might be enough without any Alien::gdal. Maybe :)

(Not sure about
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/lib/Geo/GDAL/FFI.pm#L1567
but this is also guarded by an if())

Cheers,
gregor
 

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1052257: diffoscope crashes(?) comparing some i386 debs (and others)

[Holger Levsen]

package: diffoscope
version: 240
severity: important
x-debbugs-cc: reproducible-bui...@lists.alioth.debian.org

hi,

On Tue, Sep 05, 2023 at 10:05:58PM +0200, FC Stegerman wrote:
> It worked (and was probably needed) before as the "--" was interpreted
> by schroot, not diffoscope.  So the solution should be to remove the
> "--" and just use:
>   diffoscope --version

thanks, Mattia implemented this in the meantime.

and then I did some commit so we can see on which packages diffoscope
cause the machine go into absurd loads (and sometimes make diffoscope
crash) crashes and the results have been interesting, out of 87
cases where diffoscope didnt finish this happened on:

47 trixie_i386
21 unstable_i386
5 unstable_armhf
4 trixie_arm64
4 trixie_amd64
3 unstable_arm64
2 trixie_armhf
1 experimental_amd64

so I guess my short-term measure will be to disable i386 testing...
(which I consider just wildly poking around.)

Also, this is caused mostly when running diffoscope on 3-4 distinct packages
(so far):

21 ocaml-obuild_trixie_i386
8 pgocaml_trixie_i386
8 omake_unstable_i386
8 ocaml-dune_unstable_i386
8 ocaml-dune_trixie_i386
6 ben_trixie_i386
2 wpewebkit_trixie_arm64
2 hevea_trixie_i386
2 astropy_unstable_armhf

Please not that this is diffoscope running on amd64, testing those packages
build for any arch. (using diffoscope from bookworm currently but I dont see
any major changes between diffoscope from bookworm and sid currently.)

Looking at https://tests.reproducible-builds.org/debian/history/ocaml-dune.html
it shows usual build times of very few minutes, however the last test for 
trixie/i386 took
over 2h. (?!?)

ocaml-obuild is the package which was tried most in the last days, what this
clearly shows is that the package is build twice, then diffoscope appearantly
crashes and the packages is tested again and again and again:

root@jenkins:/var/log/reproducible-builds# ls *ocaml-obuild* -lart
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 09:29 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695029345
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 09:39 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695029961
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 09:47 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695030452
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 09:55 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695030952
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 10:07 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695031674
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 11:20 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695036023
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 11:31 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695036663
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 11:41 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695037307
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 11:50 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695037840
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 12:04 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695038698
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 14:40 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695048004
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 15:05 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695049528
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 15:19 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695050391
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 15:35 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695051344
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 15:51 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695052268
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 16:01 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695052915
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 16:11 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695053485
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 16:28 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695054506
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 16:45 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695055539
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 17:04 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695056683
-rw-r--r-- 1 jenkins jenkins 0 Sep 18 17:32 
diffoscope_stamp_ocaml-obuild_trixie_i386_1695058357

I'm filing this as a bug in the Debian BTS now to benefit from x-debbugs-cc :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Reporter: You're the first person ever to win two Olympic tennis gold medals.
That's an extraordinary feat, isn't it?
Andy Murray: I think Venus and Serena have won about four each.


signature.asc
Description: PGP signature

Bug#1041451: [Sender Not Verified] Re: Bug#1041451: gmap: FTBFS on all !amd64 archs

[Thomas Wu]

Hi Andreas,

The GMAP package should compile on both Intel and Apple architectures.  I
think we are now requiring SIMD or its equivalent Neon, though, which is
why we are no longer building the *.nosimd binaries.  I don't think that's
a problem since every modern computer supports SIMD or Neon.  Does Debian
require a non-SIMD target machine?  I will try to look at your bug report
to understand what is going on.

Thanks,

Thomas Wu


On Tue, Sep 19, 2023 at 7:44 AM Andreas Tille  wrote:

> **Warning** The sender address (Andreas Tille ) can not be verified,
> sender email address could be spoofed. Please take care to proceed.
> Control: tags -1 upstream
> Control: forwarded -1 Thomas Wu , Colin K. Watanabe <
> c...@gene.com>
>
>
> Hi Thomas and Colin,
>
> the Debian packaged gmap fails to build since version 2023-06-01 for all
> release architectures besides amd64.  You can read about this bug on our
> bug tracker[1].  I think the analysis from Étienne below is a sensible
> explanation for the issue.
>
> It would be really helpful if you could clarify why you disabled SIMD?
> Does this mean you suggest we should provide gmap for amd64 only?
>
> Kind regards
> Andreas.
>
>
> [1] https://bugs.debian.org/1041451
>
> Am Tue, Aug 15, 2023 at 12:42:09PM +0200 schrieb Étienne Mollier:
> > Hi,
> >
> > The relevant part of the error message shows that the generic
> > fully scalar gmap.nosimd executable is never built for any cpu
> > architecture:
> >
> >   Note: /<>/build/src/gmap.avx2 does not exist.  For
> faster speed, may want to compile package on an AVX2 machine
> >   Note: /<>/build/src/gmap.sse42 does not exist.  For
> faster speed, may want to compile package on an SSE4.2 machine
> >   Note: /<>/build/src/gmap.sse41 does not exist.  For
> faster speed, may want to compile package on an SSE4.1 machine
> >   Note: /<>/build/src/gmap.ssse3 does not exist.  For
> faster speed, may want to compile package on an SSSE3 machine
> >   Note: /<>/build/src/gmap.sse2 does not exist.  For
> faster speed, may want to compile package on an SSE2 machine
> >   Note: /<>/build/src/gmap.nosimd does not exist.  For
> faster speed, may want to compile package on an non-SIMD machine
> >   Error: appropriate GMAP version not found
> >
> > Looking into src/Makefile.am, indeed they seem disabled upstream
> > for the current gmap versions:
> >
> >   # intersect-uint2.c requires SIMD
> >   #bin_PROGRAMS += gmap.nosimd
> >   #bin_PROGRAMS += gmapl.nosimd
> >   #bin_PROGRAMS += gsnap.nosimd
> >   #bin_PROGRAMS += gsnapl.nosimd
> >
> > My quick attempts to bring the necessary support in the
> > aforementioned intersect-uint2.c file were not very fruitful so
> > far.  Something in there looks to prevent use of simde.
> >
> > Anyways, in hope this helps further investigations,
> > --
> >   .''`.  Étienne Mollier 
> >  : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> >  `. `'   sent from /dev/pts/4, please excuse my verbosity
> >`-
>
>
>
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>
>
> --
> http://fam-tille.de
>
>

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Tue, Sep 19, 2023 at 05:39:12PM +0200, gregor herrmann wrote:

On Tue, 19 Sep 2023 11:37:29 +0200, Francesco P. Lovergine wrote:


Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libalien-base-modulebuild-perl

…

 .
 This module is in maintenance mode, use Alien::Build for new stuff.


Sorry to be a pain again :) but: Do we really need this?

Alien::Build is already questionable¹, although I admit that patching
the requirement out can be a bit cumbersome -- but a subclass that
says "This module is in maintenance mode, use Alien::Build for new
stuff." looks a bit like a candidate for not-packaging to me …



Unfortunately yes for me, it is in the dep chain for Geo::GDAL::FFI, as for
https://wiki.debian.org/BookwormGdalPerl
which is my main goal to avoid to mantain an unofficial repo for the rest
of time. 


--
Francesco P. Lovergine

Bug#1052256: No uploader

[Ben Tris]

Source: jansi1
Version: 1.18-3
Severity: important
X-Debbugs-Cc: benatt...@gezapig.nl

Dear Maintainer,

There is no uploader at this moment, it is required in this case I think.

Debian Policy Manual, Release 4.6.2.0
3.3 The maintainer of a package

If the maintainer of the package is a team of people with a shared email
address, the Uploaders control field must be
present and must contain at least one human with their personal email address.


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[gregor herrmann]

On Tue, 19 Sep 2023 11:37:29 +0200, Francesco P. Lovergine wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Francesco Paolo Lovergine 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-p...@lists.debian.org
> 
> * Package name: libalien-base-modulebuild-perl
…
>  .
>  This module is in maintenance mode, use Alien::Build for new stuff.

Sorry to be a pain again :) but: Do we really need this?

Alien::Build is already questionable¹, although I admit that patching
the requirement out can be a bit cumbersome -- but a subclass that
says "This module is in maintenance mode, use Alien::Build for new
stuff." looks a bit like a candidate for not-packaging to me …

Cheers,
gregor


¹ it's great for e.g. Windows where building C libraries is a pain
but on Debian it's problematic as downloading stuff from the internet
is not something we can or want to do

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1052201: fftw3: baseline violation: Unconditionally enabled NEON for armhf

[Julian Taylor]

On 19.09.23 02:17, Boyuan Yang wrote:



According to https://wiki.debian.org/ArchitectureSpecificsMemo#armhf , NEON 
instructions
are not guaranteed on armhf platform. However, your debian/rules explicitly 
enabled NEON
support in armhf build. This should be a violation to architecture baseline.

Please consider fixing this issue. Ubuntu is providing an example patch for it, 
and it
can be used as a reference (patch attached).



fftw3 uses runtime feature detection, neon instructions are only used 
when the hardware supports it.

Bug#1051435: upstream fix committed

[Timo Röhling]

Control: tags -1 + patch fixed-upstream

Hi again,

On Wed, 13 Sep 2023 16:17:59 +0200 Timo Röhling wrote:

Unfortunately, this bug is *not* resolved; it looks like this is
not a false positive but the subclass case which is explicitly
mentioned in the documentation:


Upstream has fixed this by removing the offending test, as the 
tested behavior (inheriting Hypothesis tests) is considered 
unsupported:


https://github.com/pytest-dev/pytest-asyncio/commit/fd57e55db1170c029324a7a9c56f86f14468217e


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature