Bug#1070492: mixxx: Tries to use the network during build

[fabian]

Hi,

Am 04.07.2024 08:01, schrieb Gianfranco Costamagna:
Also this patch is needed to adapt build dependencies with the t64 
renamed ones


diff -Nru mixxx-2.4.0+dfsg/debian/control 
mixxx-2.4.0+dfsg/debian/control

--- mixxx-2.4.0+dfsg/debian/control 2024-03-12 00:14:18.0 +0100
+++ mixxx-2.4.0+dfsg/debian/control 2024-07-04 07:55:35.0 +0200
@@ -55,8 +54,8 @@
  libtag1-dev,
  libupower-glib-dev,
  libusb-1.0-0-dev,
- libvamp-hostsdk3v5,
- libvamp-sdk2v5,
+ libvamp-hostsdk3t64,
+ libvamp-sdk2t64,
  libvorbis-dev,
  libwavpack-dev,
  pkgconf,


why does this package need to Build-Depend on shared library packages 
anyway? Why not the vamp-plugin-sdk package?


 - Fabian

Bug#1073423: url-normalize: diff for NMU version 1.4.3-3.1

[Alexandre Detiste]

Dear maintainer,

I've prepared an NMU for url-normalize (versioned as 1.4.3-3.1) and
uploaded. Here is the nmudiff.

I did broke this package in a very indirrect way by uploading urrlib3 2.x

Before this upload, python3-six was pulled in by this long
and unexpected dependency chain:

-> python3-pytest
  -> python3-request
-> python3-urllib3 (1.x)
  -> python3-six

Greetings

diff -Nru url-normalize-1.4.3/debian/changelog 
url-normalize-1.4.3/debian/changelog
--- url-normalize-1.4.3/debian/changelog2024-03-02 08:28:29.0 
+0100
+++ url-normalize-1.4.3/debian/changelog2024-07-03 21:56:22.0 
+0200
@@ -1,3 +1,10 @@
+url-normalize (1.4.3-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing python3-six build dependency (Closes: #1073423)
+
+ -- Alexandre Detiste   Wed, 03 Jul 2024 21:56:22 +0200
+
 url-normalize (1.4.3-3) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru url-normalize-1.4.3/debian/control url-normalize-1.4.3/debian/control
--- url-normalize-1.4.3/debian/control  2024-03-02 08:28:29.0 +0100
+++ url-normalize-1.4.3/debian/control  2024-07-03 21:55:40.0 +0200
@@ -8,6 +8,7 @@
python3-poetry,
python3-pytest ,
python3-pytest-cov ,
+   python3-six,
 Standards-Version: 4.6.0.1
 Testsuite: autopkgtest-pkg-python
 Homepage: https://github.com/niksite/url-normalize

Bug#1074780: Acknowledgement (pdns-backend-mysql: autopkgtests use of mysql* commands don't work directly with new MariaDB 11.4 with mariadb-* commands)

[Otto Kekäläinen]

Hi Marc and Christian!

Just checking if you can help with debugging the pdns autopkgtest issues?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074780

Bug#1074498: RFS: baby/1.0.29-1 [ITP] -- Abbreviate long commands in terminal

[Phil Wyett]

Control: tags -1 + moreinfo

Hi Manuel,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Fail

dpkg-buildpackage
-

Command: dpkg-buildpackage --sanitize-env -us -uc -mPhil Wyett 
 -ePhil
Wyett  -rfakeroot
dpkg-buildpackage: info: source package baby
dpkg-buildpackage: info: source version 1.0.29-1
dpkg-buildpackage: info: source distribution unstable
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/<>'
dh_auto_clean
rm -f baby
make[1]: Leaving directory '/<>'
   dh_clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: verifying ./baby_1.0.29.orig.tar.gz.asc
dpkg-source: info: building baby using existing ./baby_1.0.29.orig.tar.gz
dpkg-source: info: building baby using existing ./baby_1.0.29.orig.tar.gz.asc
dpkg-source: info: building baby in baby_1.0.29-1.debian.tar.xz
dpkg-source: info: building baby in baby_1.0.29-1.dsc
 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
go mod init baby
go: creating new go.mod: module baby
go: to add module requirements and sums:
go mod tidy
go build -o baby
failed to initialize build cache at /sbuild-nonexistent/.cache/go-build: mkdir 
/sbuild-nonexistent:
permission denied
make[1]: *** [debian/rules:8: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Build finished at 2024-07-04T05:51:06Z

Finished


2. Lintian: Not performed due to (1. Build).

3. Licenses: Issue

It is best practice to have a separate section for Debian files. The majority 
of Debian Developers
will not sponsor a package without it.

Example:

Files: debian/*
Copyright: Copyright (C) 2024 Manuel Guerra 
License: GPL-3+

4. Build Twice (sudo pbuilder build --twice .dsc): Not performed due 
to (1. Build).

5. Reproducible builds (reporotest)[1]: Not performed due to (1. Build).

6. Install (No previous installs): Not performed due to (1. Build).

7. Upgrade (Over previous installs if any): Not performed due to (1. Build).

Additional...

A. Need for a language specific 'debian/ppostinst'?

B. 'debian/patches' folder is not needed if no patches in use.

C. 'debian/misc:Built-Using' and empty?

D. 'debian/baby.lintian-overrides', I would remove for now. Seeing lintian 
warnings while developing
a new package for Debian is not a bad thing.

E. 'debian/watch' - Broken.

philwyett@ks-windu:~/Development/builder/debian/mentoring/baby-1.0.29$ uscan 
--force-download 
uscan warn: In directory ., downloading
  https://github.com/manuwarfare/baby/archive/refs/tags/v1.0.tar.gz.asc failed: 
404 Not Found
uscan die: FAIL Checking OpenPGP signature (no signature file downloaded).

F. 'debian/source/include-binaries' and empty?

G. 'baby.conf' empty?

H. 'debian/missing-sources/main.go'?

One thing at a time Manuel. If you need to, please ask, we are here to help.

I believe baby is not yet ready for sponsorship/upload. Could the contributor 
rectify one of more of
the rasied issues. Once updated to your satisfaction and a new upload done, 
please remove the
'moreinfo' on the Request For Sponsorship (RFS) bug report.

[1] https://wiki.debian.org/ReproducibleBuilds/Howto#Newer_method

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1070492: mixxx: Tries to use the network during build

[Gianfranco Costamagna]

Hello, looks like we need an additional build dependency currently in new queue
https://ftp-master.debian.org/new/libdjinterop_0.21.0+ds-1.html

when that library is not found, the system tries to build from source by 
downloading it.

Also this patch is needed to adapt build dependencies with the t64 renamed ones

diff -Nru mixxx-2.4.0+dfsg/debian/control mixxx-2.4.0+dfsg/debian/control
--- mixxx-2.4.0+dfsg/debian/control 2024-03-12 00:14:18.0 +0100
+++ mixxx-2.4.0+dfsg/debian/control 2024-07-04 07:55:35.0 +0200
@@ -55,8 +54,8 @@
  libtag1-dev,
  libupower-glib-dev,
  libusb-1.0-0-dev,
- libvamp-hostsdk3v5,
- libvamp-sdk2v5,
+ libvamp-hostsdk3t64,
+ libvamp-sdk2t64,
  libvorbis-dev,
  libwavpack-dev,
  pkgconf,

On Mon, 6 May 2024 13:23:47 +0200 Santiago Vila  wrote:

Package: src:mixxx
Version: 2.4.0+dfsg-2
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
   --- LOG END ---
   error: downloading 
'https://github.com/xsco/libdjinterop/archive/refs/tags/0.20.1.tar.gz' failed
   status_code: 6
   status_string: "Couldn't resolve host name"
   log:
   --- LOG BEGIN ---
   Could not resolve host: github.com

   Closing connection



   --- LOG END ---
   error: downloading 
'https://launchpad.net/~xsco/+archive/ubuntu/djinterop/+sourcefiles/libdjinterop/0.20.1-0ubuntu1/libdjinterop_0.20.1.orig.tar.gz'
 failed
   status_code: 6
   status_string: "Couldn't resolve host name"
   log:
   --- LOG BEGIN ---
   Could not resolve host: launchpad.net

   Closing connection



   --- LOG END ---
   
 



make[4]: *** [CMakeFiles/libdjinterop.dir/build.make:102: 
libdjinterop-prefix/src/libdjinterop-stamp/libdjinterop-download] Error 1
make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[3]: *** [CMakeFiles/Makefile2:317: CMakeFiles/libdjinterop.dir/all] Error 2
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [Makefile:169: all] Error 2
make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j2 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
make[1]: *** [debian/rules:21: override_dh_auto_build] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:15: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


The build was made using the unshare backend of sbuild, which
does not allow network access.

If you need a full build log, it also fails here for the same reason:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mixxx.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1075740: RM: r-cran-rgeos -- ROM; Removed from CRAN (not maintained upstream)

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: r-cran-rg...@packages.debian.org, debia...@lists.debian.org, 
1071...@bugs.debian.org
Control: affects -1 + src:r-cran-rgeos
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

this package was removed from testing due to a dependency from
r-cran-maptools which will be asked for removal as well soon.  These
packages are not maintained upstream at CRAN any more and we have no
capacity to maintain these in Debian any more.

Kind regards
Andreas.

Bug#1071355: In how far are several packages affected by bug #1071355 of maptools

[Andreas Tille]

Hi,

there was a series of testing removals due to bug #1071355 of
r-cran-maptools.  Since maptools was removed from CRAN[1] we intend to
remove this package.  However, before doing so I would like to
understand why packages like r-cran-factominer, r-cran-ggpubr,
r-cran-vim, r-cran-systemfit, r-cran-survminer and others where I can't
see any connection to r-cran-maptools were removed from testing.

Kind regards
Andreas.


[1] https://cran.r-project.org/web/packages/maptools/index.html

-- 
https://fam-tille.de

Bug#1075739: RM: r-cran-zeligei -- ROM; Removed from CRAN (not maintained upstream)

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: r-cran-zeli...@packages.debian.org, debia...@lists.debian.org
Control: affects -1 + src:r-cran-zeligei
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

this package was removed from testing due to a dependency from
r-cran-maptools which will be asked for removal as well soon.  These
packages are not maintained upstream at CRAN any more and we have no
capacity to maintain these in Debian any more.

Kind regards
Andreas.

Bug#1075738: RM: r-cran-zeligverse -- ROM; Removed from CRAN (not maintained upstream)

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: r-cran-zeligve...@packages.debian.org, debia...@lists.debian.org
Control: affects -1 + src:r-cran-zeligverse
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

this package was removed from testing due to a dependency from
r-cran-maptools which will be asked for removal as well soon.  These
packages are not maintained upstream at CRAN any more and we have no
capacity to maintain these in Debian any more.

Kind regards
Andreas.

Bug#1075737: riemann-c-client: Please update to latest, current debian: 1.10.4, current upstream: 2.2.2

[Phil Wyett]

Package: riemann-c-client
Version: 1.10.4-4
Severity: normal

Dear Maintainer,

Please update to latest version, currently 2.2.2.

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1075736: RM: r-cran-zeligchoice -- ROM; Removed from CRAN (not maintained upstream)

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: r-cran-zeligcho...@packages.debian.org, debia...@lists.debian.org
Control: affects -1 + src:r-cran-zeligchoice
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

r-cran-zeligchoice was removed from testing due to a dependency from
r-cran-maptools which will be asked for removal as well soon.  These
packages are not maintained upstream at CRAN any more and we have no
capacity to maintain these in Debian any more.

Kind regards
Andreas.

Bug#1075713: linux: ISO missing qxl.ko.xz kernel module

[Salvatore Bonaccorso]

Control: reassign -1 src:debian-installer

Hi Cyril,

On Wed, Jul 03, 2024 at 11:34:30PM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Tj  (2024-07-03):
> > Source: linux
> > Followup-For: Bug #1075713
> > X-Debbugs-Cc: tj.iam...@proton.me debian-b...@lists.debian.org
> > 
> > I've inspected the arch-latest amd64 ISO from:
> > 
> > https://get.debian.org/images/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
> > 
> > It is missing drivers/gpu/drm/qxl/qxl.ko.xz kernel module.
> > 
> > We need to review the ISO build log(s) and the Debian Image scripts but
> > I've been unable to track them down.
> > 
> > I also noticed that in
> > 
> > /usr/lib/modules/6.9.7-amd64/kernel/drivers/gpu/drm/
> > 
> > all 6 modules there are named *.ko
> > 
> > but the other 818 modules in the installer image are *.ko.xz
> > 
> > This may be a clue!
> 
> Right, it looks like a fumble on my part in the following commit:
>   
> https://salsa.debian.org/installer-team/debian-installer/-/commit/bd0f1106f90756e6f4514108492d71e1f2e695ea
> 
> I'm picking up compressed modules but shipping them without the suffix…
> and that's not an issue with src:linux.
>   
> https://salsa.debian.org/installer-team/debian-installer/-/commit/042be38d65ae906574d03ef07be20cbd865fddc6
> 
> Still need to find time to actually debug the original issue, but that's
> another story entirely.

So AFAIU, we can re-eassign this bug to src:debian-installer installer
for now. Doing so now.

Regards,
Salvatore

Bug#1074529: Bug#1074529: r-cran-dimred: autopkgtest regression with r-base 4.4.1 (i386)

[Andreas Tille]

Hi Charles,

Am Tue, Jul 02, 2024 at 08:29:13AM +0900 schrieb Charles Plessy:
> > For what it is worth version 0.2.6 is in good standing at CRAN with tests
> > using "r-release" (ie now 4.4.1) as well as "r-devel" and "r-oldrel", see
> > https://cran.r-project.org/web/checks/check_results_dimRed.html
> 
> Hello everybody,
> 
> among the tested release architectures, only i386 is failing.
> 
> I can update r-cran-dimred so that it excludes i386.

My non-user packaging view says:  If upstream is not testing /
supporting i386 any more we will have a hard time to support it.  Thanks
to our autopkgtests we know that there is an issue on this architecture.
If we can't fix it, removing the failing architecture makes probably
sense.
 
> But would that mean I have to do that for its reverse-dependencies too ?

I think so.

Kind regards
Andreas. 

-- 
https://fam-tille.de

Bug#1074059: bookworm-pu: package nodejs/18.19.0+dfsg-6~deb12u2

[Salvatore Bonaccorso]

Hi,

On Wed, Jul 03, 2024 at 11:36:46PM +0200, Jérémy Lal wrote:
> Le mer. 3 juil. 2024 à 23:04, Andres Salomon  a écrit :
> 
> >
> >
> > On 6/25/24 16:34, Jérémy Lal wrote:
> > >
> > >
> > > Le mar. 25 juin 2024 à 22:22, Salvatore Bonaccorso  > > > a écrit :
> > [...]
> > >
> > > Thanks a lot for your work Adrian. Please note that there is
> > currently
> > > a nodejs upload pending for releasing via a DSA, which will rebase
> > > nodejs to 18.20.3+dfsg-1~deb12u1 so this might invalidate those
> > > changes.
> > >
> > > Jérémy, Aron is that something you want to have included in your
> > > prepared update?
> > >
> > >
> > > Indeed, it's applied to 18.20.3+dfsg-1~deb12u1, along with other skipped
> > > tests.
> > > I'll resume work on this by the end of the week.
> > >
> >
> > While we wait for this, is there any reason to keep the existing
> > 18.20.3+dfsg-1~deb12u1 upload in the embargoed security queue? Security
> > packages are actively building against it, which is a bit of a problem
> > for reproducibility. Someone actually asked me about oddities in the
> > chromium package that was originally built for bookworm-security, and
> > now sits in the 12.6 point release. It turns out that it built against
> > the embargoed nodejs, but since that nodejs package was never released,
> > they can't use it to reproduce the chromium in 12.6.
> >
> > If there's a new nodejs bookworm-security package being uploaded at some
> > point and the currently embargoed nodejs package will never be released,
> > perhaps we should REJECT it now?
> >
> 
> Sorry, probably me being overbooked here.
> I was supposed to check the regressions against it, and been on another job
> since then.

Aron is taking care of the DSA, so I do not want to interfer here with
his planning, but sharing an idea: There will be an upcoming release
for nodejs on Monday, 8th (actually was planned for today):
https://nodejs.org/en/blog/vulnerability/july-2024-security-releases

Do you think you will be less overbooked, can review the regression
report and with Aron's help work on fixing the new CVEs for mondays
release and we base the update upon that?

Again, I do not mean to interfer here with Aron was thinking about
releasing the packages.

Regards,
Salvatore

Bug#1043686: Please provide a proper download location for beads

[Andreas Tille]

Ping again,

Am Thu, May 23, 2024 at 07:15:40AM +0200 schrieb Andreas Tille:
> Hi Filippo,
> 
> Am Wed, May 22, 2024 at 09:29:30PM +0200 schrieb Filippo Rusconi:
> > On Wednesday, 22 May 2024 07:22:32 CEST you wrote:
> > > Hi Filippo,
> > > 
> > > ping again.  The currently packaged beads is not at the location
> > > you wrote.  Please fix the watch file to report latest version.
> > > 
> > > Thanks a lot
> > >Andreas.
> > 
> > The git commit that seems to fix the bug is located at 
> > 
> > https://salsa.debian.org/med-team/beads/-/tree/1.1.22-1?ref_type=tags
> > 
> > To me it looks like it is the HEAD of the master branch.
> > 
> > Could you confirm this is correct ?
> 
> If I run
> 
>   uscan --verbose --report
> 
> I get
> 
> ...
> $newversion  = 1.1.20
> $lastversion = 1.1.22
> uscan info: Matching target for downloadurlmangle: 
> https://forgemia.inra.fr/pappso/beads/-/archive/1.1.20/beads-1.1.20.tar.gz
> uscan info: Upstream URL(+tag) to download is identified as
> https://forgemia.inra.fr/pappso/beads/-/archive/1.1.20/beads-1.1.20.tar.gz
> uscan info: Filename (filenamemangled) for downloaded file: 
> beads-1.1.20.tar.gz
> uscan info: Newest version of beads on remote site is 1.1.20, local version 
> is 1.1.22
> uscan info:  => Only older package available from:
>  => 
> https://forgemia.inra.fr/pappso/beads/-/archive/1.1.20/beads-1.1.20.tar.gz
> uscan info: Scan finished
> Exit code:   1 
> 
> This was the reason for my mail.
> 
> Kind regards
>Andreas.
> 
> -- 
> https://fam-tille.de
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
https://fam-tille.de

Bug#1074350: nvidia-kernel-dkms: Trying to modprobe nvidia-peermem to use NCCL/RDMA/Infiniband with GPUs

[Jeffrey Mark Siskind]

   So I don't know why the module doesn't load.

   Any ideas?

I figured it out. doca-ofed aka MLNX_OFED needs to have
openibd.service running. It failed because opensmd.service was
running. For some reason, it hung when I tried to stop opensmd.service.
I rebooted and then nvidia-peermem loaded.

Jeff (http: //engineering.purdue.edu/~qobi)

Bug#1075726: RFS: xtrkcad/1:5.3.0GA-1 [RC] -- CAD program for designing model railroad layouts

[Phil Wyett]

Control: tags -1 + moreinfo

Hi Jorg,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Issue

I: xtrkcad-common: image-file-has-conflicting-name (is JPEG) 
[usr/share/doc/xtrkcad-
common/html/png.d/mzoomscale.png]
N: 
N:   An image file in this package has a name that is usually associated with
N:   another image format.
N: 
N:   Please refer to Bug#717818 for details.
N: 
N:   Visibility: info
N:   Show-Always: no
N:   Check: images/filenames

Needs to be rectified immediately in my opinion.

I: xtrkcad: spelling-error-in-binary Perferences Preferences [usr/bin/xtrkcad]
N: 
N:   Lintian found a spelling error in the given binary. Lintian has a list of
N:   common misspellings that it looks for. It does not have a dictionary like
N:   a spelling checker does.
N:   
N:   If the string containing the spelling error is translated with the help of
N:   gettext or a similar tool, please fix the error in the translations as
N:   well as the English text to avoid making the translations fuzzy. With
N:   gettext, for example, this means you should also fix the spelling mistake
N:   in the corresponding msgids in the *.po files.
N:   
N:   You can often find the word in the source code by running:
N:   
N:grep -rw  
N:   
N:   This tag may produce false positives for words that contain non-ASCII
N:   characters due to limitations in strings.
N: 
N:   Visibility: info
N:   Show-Always: no
N:   Check: binaries/spelling
N: 
N:
I: xtrkcad: spelling-error-in-binary guage gauge [usr/bin/xtrkcad]
N:
I: xtrkcad: spelling-error-in-binary hilighted highlighted [usr/bin/xtrkcad]
N:
I: xtrkcad: spelling-error-in-binary seperation separation [usr/bin/xtrkcad]
N:
I: xtrkcad: spelling-error-in-binary wTH with [usr/bin/xtrkcad

For upstream to rectify if possible. Patched if not.

I: xtrkcad-common: unused-override source-is-missing 
[app/doc/xtrkcad-manual-5.3.0.html]
[usr/share/lintian/overrides/xtrkcad-common:2]
N: 
N:   Your package specifies the named override but there were no tags that
N:   could have been silenced by it.
N:   
N:   Maybe you fixed an underlying condition but forgot to remove the override.
N:   It is also possible that the Lintian maintainers fixed a false positive.
N:   
N:   If the override is now unused, please remove it.
N:   
N:   This tag is similar to mismatched-override except there a tag could have
N:   been silenced if the context had matched.
N:   
N:   Sometimes, overrides end up not being used because a tag appears only on
N:   some architectures. In that case, overrides can be equipped with an
N:   architecture qualifier.
N: 
N:   Please refer to Architecture specific overrides (Section 2.4.3) in the
N:   Lintian User's Manual for details.
N: 
N:   Visibility: info
N:   Show-Always: yes
N:   Check: lintian

3. Licenses: Good

4. Build Twice (sudo pbuilder build --twice .dsc): Good

5. Reproducible builds (reporotest)[1]: Good

6. Install (No previous installs): Not performed due to (2. Lintian).

7. Upgrade (Over previous installs if any): Not performed due to (2. Lintian).

Summary...

I believe xtrkcad is not yet ready for sponsorship/upload. Could the 
contributor rectify one of more of the rasied issues. Once updated to your 
satisfaction and a new upload done, please remove the 'moreinfo' on the Request 
For Sponsorship (RFS) bug report.

[1] https://wiki.debian.org/ReproducibleBuilds/Howto#Newer_method

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1055047: ceph: Please add loongarch64 macro definition

[zhangdandan]

Dear maintainers,

On Mon, 30 Oct 2023 15:06:26 +0800 zhangdandan wrote:

> Source: ceph
> Version: 16.2.11+ds-5
> Severity: wishlist
> Tags: ftbfs patch
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
>
> Dear maintainers,
>
> The package ceph failed to compile on loong64 in the Debian Package
> Auto-Building environment. The error messages are as follows,
> ```
> /usr/bin/ld: /usr/include/c++/13/bits/atomic_base.h:1015:(.text+0x9dc):
> undefined reference to `__atomic_compare_exchange_16'
> /usr/bin/ld: /usr/include/c++/13/bits/atomic_base.h:1015:(.text+0xa00):
> undefined reference to `__atomic_compare_exchange_16'
> [ 95%] Linking CXX shared library ../../lib/librbd.so
> cd /<>/obj-loongarch64-linux-gnu/src/librbd &&
> /usr/bin/cmake -E cmake_link_script CMakeFiles/librbd.dir/link.txt
> --verbose=1
> ```
>
> The full compilation log can be found at
> 
https://buildd.debian.org/status/logs.php?pkg=ceph&ver=16.2.11%2Bds-5&arch=loong64

>
> BTW, ceph upstream uses the "__SIZEOF_INT128__" macro definitions
> starting with version v18.0.0, please see details at
> 
https://github.com/ceph/ceph/blob/v18.0.0/cmake/modules/CheckCxxAtomic.cmake.

> Environment information for loong64 rootfs:
> root@localhost:/home/ceph# dpkg-architecture  |grep DEB_HOST_ARCH_CPU
> DEB_HOST_ARCH_CPU=loong64
> root@localhost:/home/ceph# gcc -dM -E - > #define __SIZEOF_INT128__ 16
>
> For the ceph version in the debian sid, please consider the patch I have
> attached.
> If you have any questions, you can contact me at any time.

- enable loongarch64 support in d/control.
Please consider the below patch.
```
diff -Nru ceph-16.2.11+ds/debian/control ceph-16.2.11+ds/debian/control
--- ceph-16.2.11+ds/debian/control    2023-10-09 06:53:31.0 +
+++ ceph-16.2.11+ds/debian/control    2023-10-09 06:53:31.0 +
@@ -50,7 +50,7 @@
  libfuse-dev,
  libgf-complete-dev,
  libgnutls28-dev,
- libgoogle-perftools-dev [amd64 arm64 armel armhf i386 mips64el mipsel 
ppc64 ppc64el riscv64 powerpc s390x],
+ libgoogle-perftools-dev [amd64 arm64 armel armhf i386 loong64 mips64el 
mipsel ppc64 ppc64el riscv64 powerpc s390x],

  libhwloc-dev,
```

- add loongarch64 support in src/rocksdb.
In addition, please consider the attached patch (For src/rocksdb).
loongarch64 was supported in rocksdb's upstream, you can also refer to 
https://github.com/facebook/rocksdb/pull/10036/files.


I have built ceph successfully on my local loong64 rootfs, and I have 
uploaded the ceph packages to unreleased repo.
For loong64, the unreleased source package of ceph can be found at 
http://ftp.ports.debian.org/debian-ports/pool-loong64/main/c/ceph/.


Could you add loongarch64 support in the next upload?
Any questions, you can contact me at any time.

Sincerely
Dandan

Description: FTBFS: add loongarch64 support
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 ceph (18.2.3+ds-3+loong64) unreleased; urgency=medium
 .
   * Add build support for loong64. (Open: #1055047)
   * FTBFS: add support for loong64. (Open: #1069022)
Author: Dandan Zhang 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Applied-Upstream: https://github.com/facebook/rocksdb/pull/10036
Reviewed-By: 
Last-Update: 2024-07-03

--- ceph-18.2.3+ds.orig/src/rocksdb/CMakeLists.txt
+++ ceph-18.2.3+ds/src/rocksdb/CMakeLists.txt
@@ -245,6 +245,14 @@ if(CMAKE_SYSTEM_PROCESSOR MATCHES "s390x
   endif(HAS_S390X_MARCH_NATIVE)
 endif(CMAKE_SYSTEM_PROCESSOR MATCHES "s390x")
 
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "loongarch64")
+  CHECK_C_COMPILER_FLAG("-march=loongarch64" HAS_LOONGARCH64)
+  if(HAS_LOONGARCH64)
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mtune=loongarch64")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mtune=loongarch64")
+  endif(HAS_LOONGARCH64)
+endif(CMAKE_SYSTEM_PROCESSOR MATCHES "loongarch64")
+
 option(PORTABLE "build a portable binary" OFF)
 option(FORCE_SSE42 "force building with SSE4.2, even when PORTABLE=ON" OFF)
 option(FORCE_AVX "force building with AVX, even when PORTABLE=ON" OFF)
--- ceph-18.2.3+ds.orig/src/rocksdb/Makefile
+++ ceph-18.2.3+ds/src/rocksdb/Makefile
@@ -2058,7 +2058,7 @@ JAVA_INCLUDE = -I$(JAVA_HOME)/include/ -
 ifeq ($(PLATFORM), OS_SOLARIS)
 	ARCH := $(shell isainfo -b)
 else ifeq ($(PLATFORM), OS_OPENBSD)
-	ifneq (,$(filter amd64 ppc64 ppc64le s390x arm64 aarch64 sparc64, $(MACHINE)))
+	ifneq (,$(filter amd64 ppc64 ppc64le s390x arm64 aarch64 sparc64 loongarch64, $(MACHINE)))
 		ARCH := 64
 	else
 		ARCH := 32
--- ceph-18.2.3+ds.orig/src/rocksdb/port/port_posix.h
+++ ceph-18.2.3+ds/src/rocksdb/port/port_posix.h
@@ -169,6 +16

Bug#1069210: dh-elpa: Support nested directory in elpa installation

[Nicholas D Steeves]

Replying from my phone:

On Wed, 3 Jul 2024, 22:40 Sean Whitton,  wrote:

> Hello,
>
> Sorry to keep asking for these minor changes, but it does help me
> understand the change better.
>
> Why can't you just use debian/install to install the .nosearch?  Are you
> trying to avoid creating an empty .nosearch in the source package, or is
> there some other reason?
>

While we're discussing interface, I'm curious about a "debian:rules:dh
--with dh-elpa --nosearch, norecurse, flat, or similar".

For the fine-grained approach, I'm curious about special handling for
debian/foo.elpa: subdir/.nosearch.  Like an autoload cookie, but a " do not
recourse and do not load" cookie.

Ie can't this problem be resolved such that it enables declarative style
and doesn't require a debian/[foo.]install file?

>

Bug#1069210: dh-elpa: Support nested directory in elpa installation

[Sean Whitton]

Hello,

Sorry to keep asking for these minor changes, but it does help me
understand the change better.

Why can't you just use debian/install to install the .nosearch?  Are you
trying to avoid creating an empty .nosearch in the source package, or is
there some other reason?

-- 
Sean Whitton

Bug#1075734: RFS: mangl/1.1.5-1 [ITP] -- Graphical man page viewer

[Phil Wyett]

Control: tags -1 + moreinfo

Hi James,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Fail

dpkg-buildpackage: info: source package mangl
dpkg-buildpackage: info: source version 1.1.5-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by James Montgomery 

dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
dpkg-source: info: using options from mangl-1.1.5/debian/source/options: 
--extend-diff-
ignore=mandoc/Makefile.local --extend-diff-ignore=mandoc/config.h --extend-diff-
ignore=mandoc/config.log
 debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/build/mangl-1.1.5'
dh_auto_clean
make -j4 distclean
make[2]: Entering directory '/build/mangl-1.1.5'
Makefile:1: mandoc/Makefile.local: No such file or directory
make[2]: *** No rule to make target 'mandoc/Makefile.local'.  Stop.
make[2]: Leaving directory '/build/mangl-1.1.5'
dh_auto_clean: error: make -j4 distclean returned exit code 2
make[1]: *** [debian/rules:39: override_dh_auto_clean] Error 2
make[1]: Leaving directory '/build/mangl-1.1.5'
make: *** [debian/rules:14: clean] Error 2
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package
I: unmounting dev/ptmx filesystem
I: unmounting dev/pts filesystem
I: unmounting dev/shm filesystem
I: unmounting proc filesystem
I: unmounting sys filesystem
I: cleaning the build env 
I: removing directory /var/cache/pbuilder/build/471707 and its subdirectories

2. Lintian: Not performed due to (1. Build).

3. Licenses: Issue

philwyett@ks-windu:~/Development/builder/debian/mentoring/mangl-1.1.5$ lrc
en: Versions: recon 1.11  check 3.3.9-1

Parsing Source Tree  
Reading copyright
Running licensecheck 

d/copyright | licensecheck

BSD-3-Clause| ISC  mandoc/apropos.1
BSD-3-Clause| ISC  mandoc/arch.c
BSD-3-Clause| ISC  mandoc/att.c
BSD-3-Clause| ISC  mandoc/catman.8
BSD-3-Clause| ISC  mandoc/chars.c
BSD-3-Clause| ISC  mandoc/compat_getline.c
BSD-3-Clause| ISC  mandoc/compat_isblank.c
BSD-3-Clause| ISC  mandoc/compat_mkdtemp.c
BSD-3-Clause| ISC  mandoc/compat_mkstemps.c
BSD-3-Clause| ISC  mandoc/compat_ohash.c
BSD-3-Clause| ISC  mandoc/compat_ohash.h
BSD-3-Clause| ISC  mandoc/compat_progname.c
BSD-3-Clause| ISC  mandoc/compat_reallocarray.c
BSD-3-Clause| ISC  mandoc/compat_recallocarray.c
BSD-3-Clause| BSD-2-Clause-NetBSD and/or BSD-2-clause 
mandoc/compat_stringlist.c
BSD-3-Clause| BSD-2-Clause-NetBSD and/or BSD-2-clause 
mandoc/compat_stringlist.h
BSD-3-Clause| ISC  mandoc/compat_strlcat.c
BSD-3-Clause| ISC  mandoc/compat_strlcpy.c
BSD-3-Clause| ISC  mandoc/compat_strndup.c
BSD-3-Clause| ISC  mandoc/compat_strtonum.c
BSD-3-Clause| ISC  mandoc/compat_vasprintf.c
BSD-3-Clause| ISC  mandoc/dba_array.c
BSD-3-Clause| ISC  mandoc/dba_array.h
BSD-3-Clause| ISC  mandoc/dba.c
BSD-3-Clause| ISC  mandoc/dba.h
BSD-3-Clause| ISC  mandoc/dba_read.c
BSD-3-Clause| ISC  mandoc/dba_write.c
BSD-3-Clause| ISC  mandoc/dba_write.h
BSD-3-Clause| ISC  mandoc/dbm.c
BSD-3-Clause| ISC  mandoc/dbm.h
BSD-3-Clause| ISC  mandoc/dbm_map.c
BSD-3-Clause| ISC  mandoc/dbm_map.h
BSD-3-Clause| ISC  mandoc/demandoc.1
BSD-3-Clause| ISC  mandoc/demandoc.c
BSD-3-Clause| ISC  mandoc/eqn.7
BSD-3-Clause| ISC  mandoc/eqn.c
BSD-3-Clause| ISC  mandoc/eqn_html.c
BSD-3-Clause| ISC  mandoc/eqn_term.c
BSD-3-Clause| ISC  mandoc/gmdiff
BSD-3-Clause| ISC  mandoc/html.h
BSD-3-Clause| ISC  mandoc/lib.c
BSD-3-Clause| ISC  mandoc/lib.in
BSD-3-Clause| ISC  mandoc/Makefile
BSD-3-Clause| ISC  mandoc/Makefile2
BSD-3-Clause| ISC  mandoc/makewhatis.8
BSD-3-Clause| ISC  mandoc/man.7
BSD-3-Clause| ISC  mandoc/man.cgi.3
BSD-3-Clause| ISC  mandoc/man.cgi.8
BSD-3-Clause| ISC  mandoc/man.conf.5
BSD-3-Clause| ISC  mandoc/mandoc.1
BSD-3-Clause| ISC

Bug#1075735: (no subject)

[wuruilong]

Package: golang-github-coreos-discovery-etcd-io

Version: 2.0.0+git2019.04.19.git.78fb45d3c9-4

Severity: wishlist

Tags: patch

User: debian-loonga...@lists.debian.org

Usertags: loong64


Dear maintainers,


golang-github-coreos-discovery-etcd-io software third-party dependencies 
do not support loongarch, please refer to the attached content to update 
the code.



wuruilong

Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 golang-github-coreos-discovery-etcd-io (2.0.0+git2019.04.19.git.78fb45d3c9-4) unstable; urgency=medium
 .
   * Rebuilt.
Author: Thomas Goirand 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-07-03

--- /dev/null
+++ golang-github-coreos-discovery-etcd-io-2.0.0+git2019.04.19.git.78fb45d3c9/vendor/github.com/coreos/bbolt/bolt_loong64.go
@@ -0,0 +1,9 @@
+// +build loong64
+
+package bbolt
+
+// maxMapSize represents the largest mmap size supported by Bolt.
+const maxMapSize = 0x // 256TB
+
+// maxAllocSize is the size used when creating array pointers.

Bug#1070171: ITP: mangl -- An enhanced man page viewer

[James Montgomery]

> Please file a Request For Sponsorship (RFS) bug.
>
> https://mentors.debian.net/sponsors/rfs-howto/
>
> I will review here for now, but you must do the above.

Thanks, Phil! I've opened RFS bug #1075734 as advised.
>

[SNIP]

>
> Regards
>
> Phil
>
> --
>
> Internet Relay Chat (IRC): kathenas
>
> Website: https://kathenas.org
>
> Instagram: https://instagram.com/kathenasorg/
>
> Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Bug#1075734: RFS: mangl/1.1.5-1 [ITP] -- Graphical man page viewer

[James Montgomery]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: mangl
   Version : 1.1.5-1
   Upstream Author : Ziga Lenarcic
 * URL : https://github.com/zigalenarcic/mangl
 * License : BSD-2-Clause
 * Vcs : https://salsa.debian.org/monty/mangl
   Section : utils

The source builds the following binary packages:

  mangl - Graphical man page viewer based on the mandoc library

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/m/mangl/mangl_1.1.5-1.dsc

Changes for the initial release:

 mangl (1.1.5-1) unstable; urgency=medium
 .
   * Initial packaging (Closes: #1070171
)
   * Change distribution to unstable for upload.

Regards,
-- 
  James Montgomery

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2024-06-18 22:58:59)
> It seems these packages still need to be updated as well:

Here is the current status:

DONE in unstable:

* async-fs
  * v2.1.2 accepts async-lock v2+3 in unstable
  * v2.1.2 succeeds build-time testsuite and autopkgtests in unstable
* blocking
  * v1.6.1 accepts async-channel v1+2 in unstable
  * v1.6.1 succeeds build-time testsuite and autopkgtests in unstable
* criterion
  * v0.5.1 accepts smol v1+2 in unstable
  * v0.5.1 succeeds build-time testsuite and autopkgtests in unstable
* criterion-0.3
  * v0.3.6 accepts smol v1+2 in unstable
  * v0.3.6 succeeds build-time testsuite and autopkgtests in unstable

DONE in experimental, just need re-release for unstable:

* async-channel
  * involves branch transition: v1 -> v2
  * v2.3.1 accepts event-listener v5 in experimental
(via event-listener-strategy)
  * v2.3.1 succeeds build-time testsuite in experimental
* async-executor
  * v1.12.0 stops needing async-lock v2 in experimental
  * v1.12.0 succeeds build-time testsuite in experimental
* async-lock
  * involves branch transition: v2 -> v3
  * v3.4.0 accepts event-listener v5 in experimental
  * v3.4.0 succeeds build-time testsuite in experimental
* async-process
  * involves branch transition: v1 -> v2
  * v2.2.3 accepts async-channel v2 in experimental
  * v2.2.3 accepts async-lock v2+3 in experimental
  * v2.2.3 accepts event-listener v5 in experimental
  * v2.2.3 succeeds build-time testsuite in experimental
* event-listener
  * involves branch transition: v2 -> v5
  * v5.3.1 succeeds build-time testsuite in experimental
* if-watch
  * v3.2.0 accepts smol v1+2 in unstable
  * v3.2.0 succeeds build-time testsuite and autopkgtests in unstable
* smol
  * involves branch transition: v1 -> v2
  * v2.0.0 accepts async-channel v1+2 in experimental
  * v2.0.0 accepts async-fs v1+2 in experimental
  * v2.0.0 accepts async-lock v3 in experimental
  * v2.0.0 succeeds build-time testsuite in experimental

DONE but awaits testing:

* async-std
  * v1.12.0 accepts async-channel v1+2 in unstable
  * v1.12.0 accepts async-lock v2+3 in unstable
  * v1.12.0 accepts async-process v1+2 in unstable
  * needs to succeed build-time testsuite and autopkgtests in unstable

TODO:

* async-broadcast
  * involves branch transition: v0.5 -> v0.7
  * v0.7.0 accepts event-listener v5 in experimental
  * needs custom testing: package lacks build-time testing
* async-global-executor
  * needs to accept async-channel v2 at least in experimental


  * needs to accept async-lock v3 at least in experimental
  * needs custom testing: package lacks build-time testing
* async-io
  * v2.3.3 accepts async-lock v3 in experimental
  * needs custom testing: package lacks build-time testing
* async-mutex
  * v1.4.0 accepts event-listener v5 in experimental
  * needs custom testing: package lacks build-time testing
* crosstermion
  * v0.14.0 accepts async-channel v2 in experimental, sloppily
  * needs custom testing: package lacks build-time testing
* event-listener-strategy
  * v0.5.2 accepts event-listener v5 in experimental
  * needs custom testing: package lacks build-time testing
* fs4
  * needs to accept smol v2 at least in experimental
  * needs custom testing: package lacks build-time testing
* gst-plugin-gtk4
  * needs to accept async-channel v2 at least in experimental
  * needs custom testing: package lacks build-time testing
* sluice
  * needs to accept async-channel v2 at least in experimental
  * needs custom testing: package lacks build-time testing
* sqlx-core
  * v0.7.3 accepts event-listener v5 in experimental
  * needs custom testing: package lacks build-time testing
* zbus
  * needs to accept event-listener v5 at least in experimental
  * needs custom testing: package lacks build-time testing

BROKEN for different reasons

* isahc
  * needs to accept async-channel v2 at least in experimental
  * needs to accept event-listener v5 at least in experimental
  * broken

If, as expected, testing of async-std turns succesfull, I am ready to
re-release to unstable all of the packages listed above that is
currently lingering in experimental.

Please tell when you are ready as well, for the packages above listed as
needing custom testing.  Only say so when they are *all* ready.

Kind regards, and thanks for all your help and patience,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1070171: ITP: mangl -- An enhanced man page viewer

[Phil Wyett]

Please file a Request For Sponsorship (RFS) bug.

https://mentors.debian.net/sponsors/rfs-howto/

I will review here for now, but you must do the above.

Hi Ziga,

Package fails to build.

dpkg-buildpackage
-

Command: dpkg-buildpackage --sanitize-env -us -uc -mPhil Wyett 
 -ePhil
Wyett  -rfakeroot
dpkg-buildpackage: info: source package mangl
dpkg-buildpackage: info: source version 1.1.5-1
dpkg-buildpackage: info: source distribution unstable
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
dpkg-source: info: using options from mangl-1.1.5/debian/source/options: 
--extend-diff-
ignore=mandoc/Makefile.local --extend-diff-ignore=mandoc/config.h --extend-diff-
ignore=mandoc/config.log
 debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/<>'
dh_auto_clean
make -j4 distclean
make[2]: Entering directory '/<>'
Makefile:1: mandoc/Makefile.local: No such file or directory
make[2]: *** No rule to make target 'mandoc/Makefile.local'.  Stop.
make[2]: Leaving directory '/<>'
dh_auto_clean: error: make -j4 distclean returned exit code 2
make[1]: *** [debian/rules:39: override_dh_auto_clean] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:14: clean] Error 2
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2

Build finished at 2024-07-04T00:38:51Z

Finished



+--+
| Cleanup  |
+--+

Not cleaning session: cloned chroot in use
Keeping session: unstable-amd64-sbuild-08ff5098-25e3-493c-8ba6-224bda893062
E: Build failure (dpkg-buildpackage died)

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 16592
Build-Time: 0
Distribution: unstable
Fail-Stage: build
Host Architecture: amd64
Install-Time: 50
Job: /home/philwyett/Development/builder/debian/mentoring/mangl_1.1.5-1.dsc
Machine Architecture: amd64
Package: mangl
Package-Time: 65
Source-Version: 1.1.5-1
Space: 16592
Status: attempted
Version: 1.1.5-1

Finished at 2024-07-04T00:38:51Z
Build needed 00:01:05, 16592k disk space
E: Build failure (dpkg-buildpackage died)

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1075717: mawk: rand() incorrect results on i386 - returns negative numbers and ignores srand()

[Thomas Dickey]

On Wed, Jul 03, 2024 at 05:07:10PM -0400, Thomas Dickey wrote:
> On Wed, Jul 03, 2024 at 11:03:09AM -0400, Boyuan Yang wrote:
> > X-Debbugs-CC: t...@invisible-island.net
> > 
> > 在 2024-07-03星期三的 16:28 +0200，Kristian Nielsen写道：
> > > Package: mawk
> > > Version: 1.3.4.20240622-1
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > Running mawk produces wrong output from rand() on i386:
> > > 
> > >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > >   0.158578
> > >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > >   -0.276944
> > >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > >   -0.387807
> > >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > >   0.470306
> > > 
> > > The result of rand() should never be negative; and it should be
> > > deterministic after calling srand().
> > > 
> > > This occurs on i386 (tested in sbuild --arch=i386 as part of debugging a
> > > reproducible build problem of package openscad).
> > > 
> > > The expected output is the same value between 0 and 1, for example:
> > > 
> > >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > >   0.559536
> > >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > >   0.559536
> > >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> > >   0.559536
> > > 
> > > The longer story, for completeness: I am the maintainer for openscad, and 
> > > I
> > > see openscad sometimes failing to build reproducibly on (only) i386 during
> > > the past year. The root cause seems to be a test script that calls awk and
> > > behaves unexpectedly due to getting a negative number out of rand().
> > > 
> > > The problem does not seem to occur on amd64 or arm64. Openscad doesn't 
> > > build
> > > on armhf, so not sure if the problem in mawk is specific to i386 or may be
> > > specific to 32-bit for example.
> > 
> > Ack. Reproducible on Debian Sid (mawk/1.3.4.20240622), not reproducible on 
> > Debian 12
> > Bookworm (mawk/1.3.4.20200120). Likely a regression since 2020.
> 
> odd - I can reproduce the problem, but what I'm seeing is older.
> I'll investigate further.

what I see is a problem with the configurable feature to use the system
srand/rand functions.  Apparently the relatively new configure check 
(and availability) for arc4random_stir/arc4random is not being scaled
properly.

The other bug that I see is that if the system rand/srand is used,
then srand has no effect in the script.  That is a drawback to the
new/improved(?) arc4random functions: their developers chose to not support an
equivalent to srand.

This bug can be resolved by adding --enable-builtin-srand to the configure
options.  The issue with repeatability has come up before - see

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=63843

but the scaling is actually a bug.  The configure script's choice of
random functions is a little awkward to work around other than by
setting the configure option (actually a small patch to the configure script
would work, by changing this line:

for cf_func in arc4random_stir/arc4random srandom/random 
srand48/lrand48 srand/rand
to
for cf_func in srandom/random srand48/lrand48 srand/rand

but I seem to recall that doesn't mesh with dpkg-buildpackage (ymmv).

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1074785: RFS: freefilesync/13.7-1 [RC] -- Cross-platform file sync utility with GUI (GPL release)

[Phil Wyett]

Hi Fab,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Good

The spelling error 'Unknow' has been reported by myself upstream.

https://freefilesync.org/forum/viewtopic.php?t=11423

3. Licenses: Good

4. Build Twice (sudo pbuilder build --twice .dsc): Good

5. Reproducible builds (reporotest)[1]: Good

6. Install (No previous installs): Good

7. Upgrade (Over previous installs if any): Good

Summary...

I believe freefilesync is ready for sponsorship/upload. Could a Debian 
Developer (DD) with available
free time, please review this package and upload if you feel it is ready.

[1] https://wiki.debian.org/ReproducibleBuilds/Howto#Newer_method

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1001551: xpdf: Argument parsing: -exec with spaces

[Adam Sampson]

On Thu, Jul 04, 2024 at 12:58:10AM +0200, Celelibi wrote:
> I took a look at that xpdf script and I concur. It wouldn't be easy to
> keep the script posix-compliant and do the parsing correctly.

It would probably be simpler to do the job in xpopple itself and get rid
of the wrapper script -- I'd be happy to take a patch if someone wants
to have a first attempt at it.

In PDFCore::loadFile, you'd need to check for a known extension to the
filename, create a temporary file with mkstemp, and decompress to it
before creating the PDFDoc. It wouldn't be very hard to add a
"decompress .gz zcat" config command to set up a list of known
extensions with decompression commands, in much the same way that key
bindings work already.

Thanks,

-- 
Adam Sampson  

Bug#1075733: login: broadcasted wall message no longer shown

[Luca Boccassi]

Package: login
Version: 1:4.15.2-3

Dear Maintainer(s),

since the new login version 1:4.15.2-3 has migrated to testing, an
upstream systemd test has started failing.
The issue is that the "broadcast" wall message on shutdown is no longer
detected by the test script running pexpect, a reboot is scheduled, and
the test sees "Reboot scheduled for Wed 2024-07-03 11:14:42 UTC, ..."
coming through. Before the change, it also could see "Broadcast message
from ..." but now it doesn't. Downgrading login to the previous version
fixes the issue.

This is the test case:
https://github.com/systemd/systemd/blob/main/test/units/TEST-69-SHUTDOWN.py

It opens a new tty with "login -f root" and then issues "shutdown -r"
on it. The same thing can be verified manually.

-- 
Kind regards,
Luca Boccassi


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

Bug#1042913: freecad: TechDraw workbench: part corner vertices and circle centers not showing up, unable to attach for draw dimensions

[Scott MacKenzie]

Package: freecad
Version: 0.20.2+dfsg1-4
Followup-For: Bug #1042913
X-Debbugs-Cc: larri...@inbox.lv

Dear Maintainer,

I see this problem exactly as described.
I downloaded/ran FreeCAD_0.20.2-2022-12-27-conda-Linux-x86_64-py310.AppImage 
and the problem does not appear to exist in upstream.
I am eagerly awaiting the efforts of the smarter people.

Regards,
Scott.

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

Kernel: Linux 6.1.0-22-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 freecad depends on:
ii  freecad-python3  0.20.2+dfsg1-4

Versions of packages freecad recommends:
ii  calculix-ccx  2.20-1
ii  graphviz  2.42.2-7+b3

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#1075717: mawk: rand() incorrect results on i386 - returns negative numbers and ignores srand()

[Thomas Dickey]

On Wed, Jul 03, 2024 at 11:03:09AM -0400, Boyuan Yang wrote:
> X-Debbugs-CC: t...@invisible-island.net
> 
> 在 2024-07-03星期三的 16:28 +0200，Kristian Nielsen写道：
> > Package: mawk
> > Version: 1.3.4.20240622-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > Running mawk produces wrong output from rand() on i386:
> > 
> >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> >   0.158578
> >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> >   -0.276944
> >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> >   -0.387807
> >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> >   0.470306
> > 
> > The result of rand() should never be negative; and it should be
> > deterministic after calling srand().
> > 
> > This occurs on i386 (tested in sbuild --arch=i386 as part of debugging a
> > reproducible build problem of package openscad).
> > 
> > The expected output is the same value between 0 and 1, for example:
> > 
> >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> >   0.559536
> >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> >   0.559536
> >   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
> >   0.559536
> > 
> > The longer story, for completeness: I am the maintainer for openscad, and I
> > see openscad sometimes failing to build reproducibly on (only) i386 during
> > the past year. The root cause seems to be a test script that calls awk and
> > behaves unexpectedly due to getting a negative number out of rand().
> > 
> > The problem does not seem to occur on amd64 or arm64. Openscad doesn't build
> > on armhf, so not sure if the problem in mawk is specific to i386 or may be
> > specific to 32-bit for example.
> 
> Ack. Reproducible on Debian Sid (mawk/1.3.4.20240622), not reproducible on 
> Debian 12
> Bookworm (mawk/1.3.4.20200120). Likely a regression since 2020.

odd - I can reproduce the problem, but what I'm seeing is older.
I'll investigate further.

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1074350: nvidia-kernel-dkms: Trying to modprobe nvidia-peermem to use NCCL/RDMA/Infiniband with GPUs

[Jeffrey Mark Siskind]

   > How can we/I compile the nvidia-peermem driver with Mellanox
 ib_peer_mem symbols?

   Probably not a problem of the nvidia-peermem module but of the kernel 
   (or a third-party module) that needs to provide these symbols.

First, I upgraded to Debian 12.6. So I am running nvidia-driver 535.183.01.

I then installed doca-ofed.

   
https://developer.nvidia.com/doca-downloads?deployment_platform=Host-Server&deployment_package=DOCA-Host&target_os=Linux&Architecture=x86_64&Profile=doca-ofed&Distribution=Debian&version=12.1&installer_type=deb_online

(I'll spare you the details. It did not install out of the box. If you
wish, I can tell you exactly what I did to install it.)

doca-ofed (aka MLNX_OFED) provides the necessary symbols.

Then I did this:

   dkms --force build -m nvidia-current -v 535.183.01
   dkms --force install -m nvidia-current -v 535.183.01

I did this to attempt to get nvidia-peermem to work. Indeed, now I get
a different error message:

   root@vuku:~# modprobe nvidia-peermem
   modprobe: ERROR: could not insert 'nvidia_current_peermem': Unknown symbol 
in module, or unknown parameter (see dmesg)
   modprobe: ERROR: ../libkmod/libkmod-module.c:1047 command_do() Error running 
install command 'modprobe nvidia ; modprobe -i nvidia-current-peermem ' for 
module nvidia_peermem: retcode 1
   modprobe: ERROR: could not insert 'nvidia_peermem': Invalid argument
   root@vuku:~# dmesg|tail
   [161810.093263] Compat-mlnx-ofed backport release: 91fb8cd
   [161810.093272] Backport based on 
https://:@git-nbu.nvidia.com/r/a/mlnx_ofed/mlnx-ofa_kernel-4.0.git 91fb8cd
   [161810.093274] compat.git: 
https://:@git-nbu.nvidia.com/r/a/mlnx_ofed/mlnx-ofa_kernel-4.0.git
   [161810.342539] nvidia_peermem: Unknown symbol 
ib_register_peer_memory_client (err -2)
   [161810.342554] nvidia_peermem: Unknown symbol 
ib_unregister_peer_memory_client (err -2)
   root@vuku:~# 

I think I am getting close to getting nvidia-peermem to work.

   /usr/src/nvidia-current-535.183.01/nvidia-peermem/nvidia-peermem.Kbuild

has

   OFA_DIR := /usr/src/ofa_kernel
   OFA_CANDIDATES = $(OFA_DIR)/$(OFA_ARCH)/$(KERNELRELEASE) 
$(OFA_DIR)/$(KERNELRELEASE) $(OFA_DIR)/default /var/lib/dkms/mlnx-ofed-kernel

And three of the four candidate directories exist:

   qobi@vuku>ls /usr/src/ofa_kernel/x86_64/6.1.0-22-amd64/
   compat/   compat_base_tree_version  configure@   
Module.symvers
   compat_base   compat.config configure.mk.kernel  
ofed_scripts/
   compat_base_tree  compat_versioninclude/
   qobi@vuku>ls /usr/src/ofa_kernel/6.1.0-22-amd64/
   ls: cannot access '/usr/src/ofa_kernel/6.1.0-22-amd64/': No such file or 
directory
   qobi@vuku>ls /usr/src/ofa_kernel/default
   /usr/src/ofa_kernel/default@
   qobi@vuku>ls /usr/src/ofa_kernel/default/
   compat/   compat_base_tree_version  configure@   
Module.symvers
   compat_base   compat.config configure.mk.kernel  
ofed_scripts/
   compat_base_tree  compat_versioninclude/
   qobi@vuku>ls /var/lib/dkms/mlnx-ofed-kernel
   24.04.OFED.24.04.0.7.0.1/  kernel-6.1.0-22-amd64-x86_64@
   qobi@vuku>

There appear to be two different Module.symvers, but they apear to be identical:

   qobi@vuku>ls -l /usr/src/ofa_kernel/x86_64/6.1.0-22-amd64/Module.symvers
   -rw-r--r-- 1 root root 92655 Jul  3 15:49 
/usr/src/ofa_kernel/x86_64/6.1.0-22-amd64/Module.symvers
   qobi@vuku>ls -l /usr/src/ofa_kernel/default/Module.symvers
   -rw-r--r-- 1 root root 92655 Jul  3 15:49 
/usr/src/ofa_kernel/default/Module.symvers
   qobi@vuku>diff /usr/src/ofa_kernel/x86_64/6.1.0-22-amd64/Module.symvers 
/usr/src/ofa_kernel/default/Module.symvers
   qobi@vuku>

And they appear to have the requiste symbols:

   qobi@vuku>fgrep ib_register_peer_memory_client 
/usr/src/ofa_kernel/x86_64/6.1.0-22-amd64/Module.symvers
   0xaba78e45ib_register_peer_memory_client  
/var/lib/dkms/mlnx-ofed-kernel/24.04.OFED.24.04.0.7.0.1/build/drivers/infiniband/core/ib_core
   EXPORT_SYMBOL   
   qobi@vuku>fgrep ib_unregister_peer_memory_client 
/usr/src/ofa_kernel/x86_64/6.1.0-22-amd64/Module.symvers
   0xbde5c050ib_unregister_peer_memory_client
/var/lib/dkms/mlnx-ofed-kernel/24.04.OFED.24.04.0.7.0.1/build/drivers/infiniband/core/ib_core
   EXPORT_SYMBOL   
   qobi@vuku>

And the module appears to contain those symbols:

   qobi@vuku>fgrep ib_register_peer_memory_client 
/usr/lib/modules/6.1.0-22-amd64/updates/dkms/nvidia-current-peermem.ko
   grep: 
/usr/lib/modules/6.1.0-22-amd64/updates/dkms/nvidia-current-peermem.ko: binary 
file matches
   qobi@vuku>strings 
/usr/lib/modules/6.1.0-22-amd64/updates/dkms/nvidia-current-peermem.ko|fgrep 
ib_register_peer_memory_client
   ib_register_peer_memory_client
   ib_register_peer_memory_client
   qobi@vuku>

So I don't know why the module doesn't load.

Any ideas?

Thanks,
Jeff (http: //engineering.purdue.edu/~qobi)

Bug#1072708: openafs: src/rx[gen] contains SUN RPC code under the original license

[Bastian Germann]

Am 04.07.24 um 00:28 schrieb Benjamin Kaduk:

Sounds like we might want to add this bug to the 'blocks' list for that
one, then?


Then you should change its title, too.

Bug#1072708: openafs: src/rx[gen] contains SUN RPC code under the original license

[Benjamin Kaduk]

On Thu, Jul 04, 2024 at 12:23:11AM +0200, Bastian Germann wrote:
> Am 03.07.24 um 23:56 schrieb Benjamin Kaduk:
> > On Wed, Jul 03, 2024 at 11:27:50PM +0200, Bastian Germann wrote:
> > > Am 03.07.24 um 05:23 schrieb Benjamin Kaduk:
> > > > I do not see how it would be possible to replace this code in Debian 
> > > > before
> > > > upstream can do so; this code is a core part of the functionality of the
> > > > software and the files cannot be relicensed without the permission of 
> > > > all
> > > > copyright holders.
> > > 
> > > Upstream supports more OS than only Linux and most of the changes are
> > > portability changes. Trying a compile with the files replaced won't hurt.
> > 
> > I think it would hurt; some of the chnages relate to security fixes, among
> > other things.
> 
> Can you point to a specific security fix that is not included in glibc or 
> FreeBSD?
> I would like to report it to them in that case.

https://github.com/openafs/openafs/commit/a4c1d5c48deca2ebf78b1c90310b6d56b3d48af6
is the one I found first that is of clear security relevance to openafs (I
did not attempt an exhaustive search).  That said, I have to say "of
security relevance to openafs" because it relates to how the overall
application handles large/unexpected RPC input arguments, and the right way
to address that class of issue is likely to depend on the particular
application in question.  This particular fix is suitable for openafs but
is not necessarily suitable for all consumers of a generic rpcgen.

> > > > I am also a bit confused at why you chose to file this as severity: 
> > > > serious
> > > > -- could you please clarify what part of policy is being violated or 
> > > > how it
> > > > makes the package unsuitable for release?
> > > 
> > > Assuming the license is non-free (which some people may doubt but this 
> > > seems
> > > to be established in Debian) the package violates Policy §2.2.1 "Every 
> > > package
> > > in main must comply with the DFSG"
> > 
> > Do you have any links handy for "this seems to be established in Debian"?
> > Maybe a statement from ftpmaster?
> 
> There is a bug waiting for a statement from ftpmaster: #1072165.

Sounds like we might want to add this bug to the 'blocks' list for that
one, then?

> > Starting from scratch I'm only finding
> > https://lists.debian.org/debian-legal/2003/08/msg00667.html from 2003 (and
> > the corresponding bug,
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181493), neither of which
> > really ends with a resounding conclusion, and which are quite old.
> 
> The conclusion of bug #181493 was upstream's relicensing of the code.

Right, which is not much of a conclusion on whether or not the license is
non-free; it is just side-stepping the question.

-Ben

Bug#1074795: python3-distributed: module version reported as "0+unknown"

[Julian Gilbey]

On Wed, Jul 03, 2024 at 09:51:03PM +0200, Étienne Mollier wrote:
> Control: tags -1 + confirmed
> 
> Hi Martin,
> 
> Thanks for your report!
> [...]
> 
> Now to make sense how to reroute the package version number to
> the version module, instead of having to rely on a git tag.  The
> problem during the official package build is that it occurs
> completely outside any git context, so no tags have any chance
> to be available.  It may be possible to capture the package
> version instead, but the version.py code to do that is non
> existent for now.

Is there any chance that setting SETUPTOOLS_SCM_PRETEND_VERSION would
help?

   Julian

Bug#1072708: openafs: src/rx[gen] contains SUN RPC code under the original license

[Bastian Germann]

Am 03.07.24 um 23:56 schrieb Benjamin Kaduk:

On Wed, Jul 03, 2024 at 11:27:50PM +0200, Bastian Germann wrote:

Am 03.07.24 um 05:23 schrieb Benjamin Kaduk:

I do not see how it would be possible to replace this code in Debian before
upstream can do so; this code is a core part of the functionality of the
software and the files cannot be relicensed without the permission of all
copyright holders.


Upstream supports more OS than only Linux and most of the changes are
portability changes. Trying a compile with the files replaced won't hurt.


I think it would hurt; some of the chnages relate to security fixes, among
other things.


Can you point to a specific security fix that is not included in glibc or 
FreeBSD?
I would like to report it to them in that case.


I am also a bit confused at why you chose to file this as severity: serious
-- could you please clarify what part of policy is being violated or how it
makes the package unsuitable for release?


Assuming the license is non-free (which some people may doubt but this seems
to be established in Debian) the package violates Policy §2.2.1 "Every package
in main must comply with the DFSG"


Do you have any links handy for "this seems to be established in Debian"?
Maybe a statement from ftpmaster?


There is a bug waiting for a statement from ftpmaster: #1072165.


Starting from scratch I'm only finding
https://lists.debian.org/debian-legal/2003/08/msg00667.html from 2003 (and
the corresponding bug,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181493), neither of which
really ends with a resounding conclusion, and which are quite old.


The conclusion of bug #181493 was upstream's relicensing of the code.

Bug#1033839: docker.io -- please update to v26.0.0 or above

[Prusty, Badrikesh]

Hi Reinhard,

Regarding dh_override_dh_auto_test, I fixed the issues daemon and cli 
unit-tests.

Added the required patches skip and fix the tests to my fork:
https://salsa.debian.org/badrikesh/docker/-/commits/bp%2Fdocker26

7505958 engine: add patches to skip tests that fails with permission denied
573d29d remove microsoft hcsshim tests for engine archive test
71fcbc2 add patches to fix minor string issues in cli unit-test
803e6ef add patch to disable GO111MODULE from cli Makefile
82cd833 debian/control: update Standards-Version to 4.7.0 (no changes)


Currently, with libnetwork tests, we have around 150+ failures, will try fixing 
those as well.

Please review the changes.


Thanks & Regards,
Badrikesh

Bug#1074789: [Pkg-utopia-maintainers] Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Luca Boccassi]

On Wed, 03 Jul 2024 22:58:33 +0100 Luca Boccassi 
wrote:
> On Wed, 3 Jul 2024 21:26:36 +0200 Michael Biebl 
> wrote:
> > Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:
> > > On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:
> > > 
> > > connect(5, {sa_family=AF_UNIX,
> sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1
> ECONNREFUSED (Connection refused)
> > > 
> > >> systemd should be listening on this socket
> > > 
> > > Well, on no less than four different Debian machines, it does
not.
> > > 
> > >> $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> > >> COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE
NAME
> > >> systemd   1 root   28u  unix 0x73ac41e2  0t0 8696
> > >> /run/systemd/userdb/io.systemd.DynamicUser type=STREAM (LISTEN)
> > > 
> > > Isn't that on a machine where systemd-userdb is installed maybe?
> The
> > > installation of that package triggers the systemd binary to
listen?
> > 
> > No, systemd-userdb is not installed and as you can see from the
above
> > output it's actually systemd which listens on that socket.
> 
> I can reproduce it by mounting a tmpfs on /run/systemd/userdb/ _and_
> creating an empty io.systemd.DynamicUser file on it. Maybe it should
> not abort like that, however, if you have the directory in /run/
_and_
> the socket file exists _but_ nothing is listening on it, then your
> machine is broken in some way. If the directory/socket are missing
they
> are just skipped gracefully.

I'm not sure what's the alternative here - if consulting NSS fails for
some local reasons because the machine is broken/misconfigured, I am
not sure if it should just ignore it and continue it. If NSS is
configured and is supposed to work, but doesn't for some
temporary/local reason, you might end up creating a duplicated
user/group, and I am not really sure that's better than bailing out
without touching anything.

-- 
Kind regards,
Luca Boccassi


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

Bug#1074238: vmxnet.hook can be deleted

[Bryce Harrington]

On Wed, Jul 03, 2024 at 10:37:16PM +0200, Bernd Zeimetz wrote:
> Hi Bryce,
> 
> that hook is not being installed anymore since
> 
> commit 5bf93011c0b4c02cd7e6169e8bbba56b87ea14c4
> Author: Bernd Zeimetz 
> Date:   Fri Jan 19 00:25:09 2018 +0100
> 
> Drop -dkms package.
> 
> Closes: #884656
> Thanks: Christian Ehrhardt

Yes, as mentioned I traced it down to this commit as well.

> 
> Or did I miss something? Did you find the hook on a recently installed
> system?

No, it was discovered due to an archive-wide code review for hooks that
rely on manual_add_modules().

AFAICT it is not possible that this code would be triggered by anything,
and thus no recent systems should have this installed.

> I've removed the file from the repository.

Perfect, thanks!

> Bernd
> 
> On Wed, 2024-07-03 at 13:28 -0700, Bryce Harrington wrote:
> > Hi Maintainers,
> > 
> > In doing further investigation, I suspect this hook is entirely
> > vestigal
> > and should be dropped from packaging.
> > 
> > Neither pcnet32.* nor vmxnet appear to be referenced anywhere else in
> > debian/*, and I could not find an obvious way to install things that
> > would exercise the conditional.
> > 
> > In doing some git archaeology[1], I discovered that vmxnet used to be
> > installed by a deprecated binary module that was finally dropped from
> > the packaging with the changeset to remove the -dkms package[2].
> > 
> > So I think the file debian/local/vmxnet.hook should have been deleted
> > with that, and thus can simply be dropped now.
> > 
> > 1:
> > https://code.launchpad.net/~bryce/ubuntu/+source/open-vm-tools/+git/open-vm-tools/+merge/468120
> > 2:
> > https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/commit/5bf93011c0b4c02cd7e6169e8bbba56b87ea14c4
> 
> -- 
>  Bernd ZeimetzDebian GNU/Linux Developer
>  http://bzed.dehttp://www.debian.org
>  GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1074789: [Pkg-utopia-maintainers] Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Luca Boccassi]

On Wed, 3 Jul 2024 21:26:36 +0200 Michael Biebl 
wrote:
> Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:
> > On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:
> > 
> > connect(5, {sa_family=AF_UNIX,
sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1
ECONNREFUSED (Connection refused)
> > 
> >> systemd should be listening on this socket
> > 
> > Well, on no less than four different Debian machines, it does not.
> > 
> >> $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> >> COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> >> systemd   1 root   28u  unix 0x73ac41e2  0t0 8696
> >> /run/systemd/userdb/io.systemd.DynamicUser type=STREAM (LISTEN)
> > 
> > Isn't that on a machine where systemd-userdb is installed maybe?
The
> > installation of that package triggers the systemd binary to listen?
> 
> No, systemd-userdb is not installed and as you can see from the above
> output it's actually systemd which listens on that socket.

I can reproduce it by mounting a tmpfs on /run/systemd/userdb/ _and_
creating an empty io.systemd.DynamicUser file on it. Maybe it should
not abort like that, however, if you have the directory in /run/ _and_
the socket file exists _but_ nothing is listening on it, then your
machine is broken in some way. If the directory/socket are missing they
are just skipped gracefully.

-- 
Kind regards,
Luca Boccassi


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

Bug#1072708: openafs: src/rx[gen] contains SUN RPC code under the original license

[Benjamin Kaduk]

On Wed, Jul 03, 2024 at 11:27:50PM +0200, Bastian Germann wrote:
> Am 03.07.24 um 05:23 schrieb Benjamin Kaduk:
> > I do not see how it would be possible to replace this code in Debian before
> > upstream can do so; this code is a core part of the functionality of the
> > software and the files cannot be relicensed without the permission of all
> > copyright holders.
> 
> Upstream supports more OS than only Linux and most of the changes are
> portability changes. Trying a compile with the files replaced won't hurt.

I think it would hurt; some of the chnages relate to security fixes, among
other things.

> > I am also a bit confused at why you chose to file this as severity: serious
> > -- could you please clarify what part of policy is being violated or how it
> > makes the package unsuitable for release?
> 
> Assuming the license is non-free (which some people may doubt but this seems
> to be established in Debian) the package violates Policy §2.2.1 "Every package
> in main must comply with the DFSG"

Do you have any links handy for "this seems to be established in Debian"?
Maybe a statement from ftpmaster?

Starting from scratch I'm only finding
https://lists.debian.org/debian-legal/2003/08/msg00667.html from 2003 (and
the corresponding bug,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181493), neither of which
really ends with a resounding conclusion, and which are quite old.

Given that openafs appears to have already been in Debian at that time
(looking at its changelog), it's a bit surprising that this bug is only
being filed now in 2024.

-Ben

Bug#1075732: dracut-config-generic: Package dracut-config-generic seems to be obsolete at least in trixie+

[farblos]

Package: dracut-config-generic
Version: 102-3
Severity: minor
X-Debbugs-Cc: in.cognit...@arcor.de

Dear Maintainer,

it seems that all what package dracut-config-generic does is to install
a file /etc/dracut.conf.d/20-generic-image.conf with contents

  hostonly="no"

But according to dracut.conf(5) that should be the default anyway:

  hostonly="{yes|no}"
Host-only mode: Install only what is needed for booting the
local host instead of a generic host and generate
host-specific configuration (default=no).

So package dracut-config-generic would have an effect only if a user has
explicitly set hostonly=yes, and probably in that case we should expect
the user not to install the package.

So probably that package should be phased out or whatever you do with
obsolete packages in Debian?

Thanks!

Bug#1074059: bookworm-pu: package nodejs/18.19.0+dfsg-6~deb12u2

[Jérémy Lal]

Le mer. 3 juil. 2024 à 23:04, Andres Salomon  a écrit :

>
>
> On 6/25/24 16:34, Jérémy Lal wrote:
> >
> >
> > Le mar. 25 juin 2024 à 22:22, Salvatore Bonaccorso  > > a écrit :
> [...]
> >
> > Thanks a lot for your work Adrian. Please note that there is
> currently
> > a nodejs upload pending for releasing via a DSA, which will rebase
> > nodejs to 18.20.3+dfsg-1~deb12u1 so this might invalidate those
> > changes.
> >
> > Jérémy, Aron is that something you want to have included in your
> > prepared update?
> >
> >
> > Indeed, it's applied to 18.20.3+dfsg-1~deb12u1, along with other skipped
> > tests.
> > I'll resume work on this by the end of the week.
> >
>
> While we wait for this, is there any reason to keep the existing
> 18.20.3+dfsg-1~deb12u1 upload in the embargoed security queue? Security
> packages are actively building against it, which is a bit of a problem
> for reproducibility. Someone actually asked me about oddities in the
> chromium package that was originally built for bookworm-security, and
> now sits in the 12.6 point release. It turns out that it built against
> the embargoed nodejs, but since that nodejs package was never released,
> they can't use it to reproduce the chromium in 12.6.
>
> If there's a new nodejs bookworm-security package being uploaded at some
> point and the currently embargoed nodejs package will never be released,
> perhaps we should REJECT it now?
>

Sorry, probably me being overbooked here.
I was supposed to check the regressions against it, and been on another job
since then.

Bug#1075713: linux: ISO missing qxl.ko.xz kernel module

[Cyril Brulebois]

Hi,

Tj  (2024-07-03):
> Source: linux
> Followup-For: Bug #1075713
> X-Debbugs-Cc: tj.iam...@proton.me debian-b...@lists.debian.org
> 
> I've inspected the arch-latest amd64 ISO from:
> 
> https://get.debian.org/images/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
> 
> It is missing drivers/gpu/drm/qxl/qxl.ko.xz kernel module.
> 
> We need to review the ISO build log(s) and the Debian Image scripts but
> I've been unable to track them down.
> 
> I also noticed that in
> 
> /usr/lib/modules/6.9.7-amd64/kernel/drivers/gpu/drm/
> 
> all 6 modules there are named *.ko
> 
> but the other 818 modules in the installer image are *.ko.xz
> 
> This may be a clue!

Right, it looks like a fumble on my part in the following commit:
  
https://salsa.debian.org/installer-team/debian-installer/-/commit/bd0f1106f90756e6f4514108492d71e1f2e695ea

I'm picking up compressed modules but shipping them without the suffix…
and that's not an issue with src:linux.
  
https://salsa.debian.org/installer-team/debian-installer/-/commit/042be38d65ae906574d03ef07be20cbd865fddc6

Still need to find time to actually debug the original issue, but that's
another story entirely.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1072708: openafs: src/rx[gen] contains SUN RPC code under the original license

[Bastian Germann]

Am 03.07.24 um 05:23 schrieb Benjamin Kaduk:

I do not see how it would be possible to replace this code in Debian before
upstream can do so; this code is a core part of the functionality of the
software and the files cannot be relicensed without the permission of all
copyright holders.


Upstream supports more OS than only Linux and most of the changes are
portability changes. Trying a compile with the files replaced won't hurt.


I am also a bit confused at why you chose to file this as severity: serious
-- could you please clarify what part of policy is being violated or how it
makes the package unsuitable for release?


Assuming the license is non-free (which some people may doubt but this seems
to be established in Debian) the package violates Policy §2.2.1 "Every package
in main must comply with the DFSG"

Bug#1075713: linux: ISO missing qxl.ko.xz kernel module

[Tj]

Source: linux
Followup-For: Bug #1075713
X-Debbugs-Cc: tj.iam...@proton.me debian-b...@lists.debian.org

I've inspected the arch-latest amd64 ISO from:

https://get.debian.org/images/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso

It is missing drivers/gpu/drm/qxl/qxl.ko.xz kernel module.

We need to review the ISO build log(s) and the Debian Image scripts but
I've been unable to track them down.

I also noticed that in

/usr/lib/modules/6.9.7-amd64/kernel/drivers/gpu/drm/

all 6 modules there are named *.ko

but the other 818 modules in the installer image are *.ko.xz

This may be a clue!

Bug#1074059: bookworm-pu: package nodejs/18.19.0+dfsg-6~deb12u2

[Andres Salomon]

On 6/25/24 16:34, Jérémy Lal wrote:



Le mar. 25 juin 2024 à 22:22, Salvatore Bonaccorso > a écrit :

[...]


Thanks a lot for your work Adrian. Please note that there is currently
a nodejs upload pending for releasing via a DSA, which will rebase
nodejs to 18.20.3+dfsg-1~deb12u1 so this might invalidate those
changes.

Jérémy, Aron is that something you want to have included in your
prepared update?


Indeed, it's applied to 18.20.3+dfsg-1~deb12u1, along with other skipped 
tests.

I'll resume work on this by the end of the week.



While we wait for this, is there any reason to keep the existing 
18.20.3+dfsg-1~deb12u1 upload in the embargoed security queue? Security 
packages are actively building against it, which is a bit of a problem 
for reproducibility. Someone actually asked me about oddities in the 
chromium package that was originally built for bookworm-security, and 
now sits in the 12.6 point release. It turns out that it built against 
the embargoed nodejs, but since that nodejs package was never released, 
they can't use it to reproduce the chromium in 12.6.


If there's a new nodejs bookworm-security package being uploaded at some 
point and the currently embargoed nodejs package will never be released, 
perhaps we should REJECT it now?


--
I'm available for contract & employment work, see:
https://spindle.queued.net/~dilinger/resume-tech.pdf


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1075731: qa.debian.org: Popularity Contest Statistics: statistics table not populated any more

[Sven Geuer]

Package: qa.debian.org
Severity: normal

Shortly after bug #1073562 [1] had been fixed the statistics table
stopped being populated, see the Popularity Contest Statistics for
argon2 [2] as an example.

This happened in coincidence with popcon numbers missing from DDPO as
already reported with bug #1074794 [3].

Maybe there are more scripts to adapt, similar to what Mattia Rizzolo
did with "popcon: fix python3 script after bookworm upgrade." [4].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073562
[2] https://qa.debian.org/popcon.php?package=argon2
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074794
[4] 
https://salsa.debian.org/qa/qa/-/commit/2560ed22b04c4678d162b445ce1680d639b835cf

Best,
Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#1074238: vmxnet.hook can be deleted

[Bernd Zeimetz]

Hi Bryce,

that hook is not being installed anymore since

commit 5bf93011c0b4c02cd7e6169e8bbba56b87ea14c4
Author: Bernd Zeimetz 
Date:   Fri Jan 19 00:25:09 2018 +0100

Drop -dkms package.

Closes: #884656
Thanks: Christian Ehrhardt


Or did I miss something? Did you find the hook on a recently installed
system?

I've removed the file from the repository.


Bernd

On Wed, 2024-07-03 at 13:28 -0700, Bryce Harrington wrote:
> Hi Maintainers,
> 
> In doing further investigation, I suspect this hook is entirely
> vestigal
> and should be dropped from packaging.
> 
> Neither pcnet32.* nor vmxnet appear to be referenced anywhere else in
> debian/*, and I could not find an obvious way to install things that
> would exercise the conditional.
> 
> In doing some git archaeology[1], I discovered that vmxnet used to be
> installed by a deprecated binary module that was finally dropped from
> the packaging with the changeset to remove the -dkms package[2].
> 
> So I think the file debian/local/vmxnet.hook should have been deleted
> with that, and thus can simply be dropped now.
> 
> 1:
> https://code.launchpad.net/~bryce/ubuntu/+source/open-vm-tools/+git/open-vm-tools/+merge/468120
> 2:
> https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/commit/5bf93011c0b4c02cd7e6169e8bbba56b87ea14c4

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1074238: vmxnet.hook can be deleted

[Bryce Harrington]

Hi Maintainers,

In doing further investigation, I suspect this hook is entirely vestigal
and should be dropped from packaging.

Neither pcnet32.* nor vmxnet appear to be referenced anywhere else in
debian/*, and I could not find an obvious way to install things that
would exercise the conditional.

In doing some git archaeology[1], I discovered that vmxnet used to be
installed by a deprecated binary module that was finally dropped from
the packaging with the changeset to remove the -dkms package[2].

So I think the file debian/local/vmxnet.hook should have been deleted
with that, and thus can simply be dropped now.

1: 
https://code.launchpad.net/~bryce/ubuntu/+source/open-vm-tools/+git/open-vm-tools/+merge/468120
2: 
https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/commit/5bf93011c0b4c02cd7e6169e8bbba56b87ea14c4

Bug#1075730: goldencheetah: FTPFS on hppa - ‘class ANTLogger’ has no member named ‘open64’

[John David Anglin]

Source: goldencheetah
Version: 1:3.5-6
Severity: normal
Tags: ftbfs

Dear Maintainer,

Build fails here:

g++ -c -pipe -Wno-unused-variable -Wno-sign-compare -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Wextra -D_REENTRANT -fPIC -DGC_VIDEO_VLC 
-DGC_VERSION=\"3.5-DEV1810\" -DQXT_STATIC -DGC_HAVE_KML -DGC_HAVE_ICAL 
-DGC_HAVE_LIBUSB -DGC_HAVE_VLC -DGC_HAVE_OVERVIEW -DQT_NO_DEBUG -DQT_SVG_LIB 
-DQT_MULTIMEDIAWIDGETS_LIB -DQT_WEBKITWIDGETS_LIB -DQT_CHARTS_LIB 
-DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_WEBKIT_LIB 
-DQT_GUI_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CONCURRENT_LIB 
-DQT_SERIALPORT_LIB -DQT_BLUETOOTH_LIB -DQT_CORE_LIB -I. -IANT -ITrain -IFileIO 
-ICloud -ICharts -IMetrics -IGui -ICore -IPlanning -I../qwt/src -I../qxt/src 
-I../qtsolutions/json -I../qtsolutions/qwtcurve -I../lmfit -I../levmar 
-I/usr/include -I/usr/include/libical -I/usr/include -I/usr/include/vlc 
-I/usr/include/hppa-linux-gnu/qt5 -I/usr/include/hppa-linux-gnu/qt5/QtSvg 
-I/usr/include/hppa-linux-gnu/qt5/QtMultimediaWidgets 
-I/usr/include/hppa-linux-gnu/qt5/QtWebKitWidgets 
-I/usr/include/hppa-linux-gnu/qt5/QtCharts 
-I/usr/include/hppa-linux-gnu/qt5/QtOpenGL 
-I/usr/include/hppa-linux-gnu/qt5/QtWidgets 
-I/usr/include/hppa-linux-gnu/qt5/QtMultimedia 
-I/usr/include/hppa-linux-gnu/qt5/QtWebKit 
-I/usr/include/hppa-linux-gnu/qt5/QtGui -I/usr/include/hppa-linux-gnu/qt5/QtXml 
-I/usr/include/hppa-linux-gnu/qt5/QtSql 
-I/usr/include/hppa-linux-gnu/qt5/QtNetwork 
-I/usr/include/hppa-linux-gnu/qt5/QtConcurrent 
-I/usr/include/hppa-linux-gnu/qt5/QtSerialPort 
-I/usr/include/hppa-linux-gnu/qt5/QtBluetooth 
-I/usr/include/hppa-linux-gnu/qt5/QtCore -I. 
-I/usr/lib/hppa-linux-gnu/qt5/mkspecs/linux-g++ -o moc_Aerolab.o moc_Aerolab.cpp
moc_ANTLogger.cpp: In static member function ‘static void 
ANTLogger::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’:
moc_ANTLogger.cpp:86:21: error: ‘class ANTLogger’ has no member named ‘open64’; 
did you mean ‘open’?
   86 | case 1: _t->open64(); break;
  | ^~
  | open
make[2]: *** [Makefile:271657: moc_ANTLogger.o] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=goldencheetah&arch=hppa&ver=1%3A3.5-6&stamp=1719870870&raw=0

sh fails in the same way:
https://buildd.debian.org/status/fetch.php?pkg=goldencheetah&arch=sh4&ver=1%3A3.5-6&stamp=1719731500&raw=0

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.10.0-rc6+ (SMP w/4 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1075729: znc: CVE-2024-39844

[Salvatore Bonaccorso]

Source: znc
Version: 1.9.0-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.8.2-2
Control: found -1 1.8.2-3.1
Control: fixed -1 1.8.2-2+deb11u1
Control: fixed -1 1.8.2-3.1+deb12u1

Hi,

The following vulnerability was published for znc.

CVE-2024-39844[0]:
| In ZNC before 1.9.1, remote code execution can occur in modtcl via a
| KICK.

The version with above fixed versions were uploaded to security-master
and will be released in the upcoming DSA for znc.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-39844
https://www.cve.org/CVERecord?id=CVE-2024-39844
[1] https://wiki.znc.in/ChangeLog/1.9.1
[2] https://github.com/znc/znc/commit/8cbf8d628174ddf23da680f3f117dc54da0eb06e

Regards,
Salvatore

Bug#1074764: [Pkg-openssl-devel] Bug#1074764: signing with osslsigncode fails with a segmentation fault since latest stable update

[Sebastian Andrzej Siewior]

On 2024-07-02 16:23:58 [+0200], Sébastien Villemot wrote:
> Dear Maintainers,
> 
> Since the last upgrade of openssl on bookworm (version 3.0.13-1~deb12u1), code
> signing using osslsigncode (and my Yubikey) now fails with a segmentation
> fault. It was working properly with version 3.0.11-1~deb12u2 (and note that
> downgrading solves the problem).
> 
> Here is the command:
> 
> $ osslsigncode sign -pkcs11module
> /usr/lib/x86_64-linux-gnu/libykcs11.so.2 -key
> "pkcs11:id=%01;type=private;pin-value=" -certs
> ~/code-signing-certificate.pem -n Foo -i https://www.foo.org -t
> http://timestamp.comodoca.com -in installer.exe -out
> installer-signed.exe
…
> 
> Note that the segfault occurs in /usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so
> (from libengine-pkcs11-openssl), which is itself called by libcrypto.so.3 
> (from
> libssl3).

Can you check if

https://github.com/openssl/openssl/commit/39ea78379826fa98e8dc8c0d2b07e2c17cd68380

fixes it?   

> Cheers,

Sebastian

Bug#1075728: lincity: Multi-lingual support is disfunctional

[debian]

Package: lincity
Severity: normal
Tags: l10n
X-Debbugs-Cc: deb...@gpa.lu

Hello.

The game barely has multi-lingual support apparently:
- Only minor UI elements are translated, most notably the in-game time;
- Changing $LANG to other languages does not fix the problem, the game remains 
largely untranslated;
- The French and Czech translations, available at the web site of the project 
hosted by Source Forge, are missing from the package.

As a result, the game is only available in English.
Many people expect to play the game in various languages that are described as 
supported, however they do not seem to be.

Have a good day.

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

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

Versions of packages lincity depends on:
ii  libc6   2.38-13
ii  libpng16-16t64  1.6.43-5
ii  libx11-62:1.8.7-1+b1

lincity recommends no packages.

lincity suggests no packages.

Bug#1075727: lincity: Multi-lingual support is disfunctional

[debian]

Package: lincity
Severity: normal
Tags: l10n
X-Debbugs-Cc: a...@abc.abc

Hello.

The game barely has multi-lingual support apparently:
- Only minor UI elements are translated, most notably the in-game time;
- Changing $LANG to other languages does not fix the problem, the game remains 
largely untranslated;
- The French and Czech translations, available at the web site of the project 
hosted by Source Forge, are missing from the package.

As a result, the game is only available in English.
Many people expect to play the game in various languages that are described as 
supported, however they do not seem to be.

Have a good day.

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

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

Versions of packages lincity depends on:
ii  libc6   2.38-13
ii  libpng16-16t64  1.6.43-5
ii  libx11-62:1.8.7-1+b1

lincity recommends no packages.

lincity suggests no packages.

Bug#1074795: python3-distributed: module version reported as "0+unknown"

[Étienne Mollier]

Control: tags -1 + confirmed

Hi Martin,

Thanks for your report!

Martin Knopp, on 2024-07-03:
> the module version reported by pip list (and contained within
> /usr/lib/python3/dist-packages/distributed/_version.py) is "0+unknown" while
> the package itself is "2024.5.2+ds.1-2". This causes unnecessary
> installations
> when other python code declares a minimum version of distributed (e. g.
> distributed = ">=2022.5.2" in my case).

The faulty version number also leaks through version invocation:

$ python3 -c 'import 
distributed;print(distributed._version.get_versions()["version"])'
0+unknown

It is also reflected in a number of other places, like egg file
names, and as you point out, interferes with pip's dependencies
resolver.  The minor severity may be slightly underrated.

> I tried to run "python3 setup.py version" on a clone of Salsa's
> "debian/2024.5.2+ds.1-2" tag, that yielded a completely different version
> (2.10.0+ds.1-3.219.g57b69fd) instead of the desired one or "0+unknown", so I
> don't know what's going wrong during build time.

Now to make sense how to reroute the package version number to
the version module, instead of having to rely on a git tag.  The
problem during the official package build is that it occurs
completely outside any git context, so no tags have any chance
to be available.  It may be possible to capture the package
version instead, but the version.py code to do that is non
existent for now.

The package has still a couple of other issues I'm trying to
diagnose at the moment.  With some luck I, or someone else
faster than I am, may come up with something before next upload.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-on air: Utopianisti - Universe For Dummies


signature.asc
Description: PGP signature

Bug#1075726: RFS: xtrkcad/1:5.3.0GA-1 [RC] -- CAD program for designing model railroad layouts

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

   Package name : xtrkcad
   Version  : 1:5.3.0GA-1
   Upstream contact : XTrkCAD Developers 

   URL  : http://xtrkcad.org/
   License  : BSD-2-Clause, permissive, GPL-2, LGPL-2+, public-domain,
  Expat, APAFML, BSD-1-Clause, GPL-2+
   Vcs  : https://git.jff.email/cgit/xtrkcad.git
   Section  : editors

The source builds the following binary packages:

  xtrkcad - CAD program for designing model railroad layouts
  xtrkcad-common - CAD program for designing model railroad layouts (common
files)

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/x/xtrkcad/xtrkcad_5.3.0GA-1.dsc

or from

 git https://git.jff.email/cgit/xtrkcad.git/?h=release%2Fdebian%2F1_5.3.0GA-1


Changes since the last upload:

 xtrkcad (1:5.3.0GA-1) unstable; urgency=medium
 .
   * New upstream release (Closes: #1057286, #1074722):
   * debian/control:
 - Add Build-Depends:
   + inkscape
   + libfreeimage-dev
   + pandoc
 - Change to new repository URL.
 - Change Standards-Version to 4.7.0.0 (No changes needed).
 - Add myself as Maintainer and Daniel E. Markle as Uploader.
   (Closes: #1057287)
   * debian/xtrkcad.install:
 - Add CHANGELOG.txt, Readme.txt
   * debian/copyright:
 - Add year 2024 to myself.
 - Rebase for the new release.
   * debian/changlog:
 - Remove trailing whitespace.
   * debian/rules:
 - Remove trailing whitespace.

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://git.jff.email/cgit/

Skype:jff-skype@jff.email
Jami: joergfringsfuerst
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.






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

Bug#1075725: UDD/dmd: Make the header row of tables sticky/fixed

[James McCoy]

Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: udd

The todolist and dmddetails tables can be quite long, which makes it
difficult to keep track of what data each column is displaying. It would
be useful if the header row could be made sticky so it stays visible
when scrolling through the table.

The tables are using datatables[0] to format the data. It has an
extension called FixedHeader[1] which supports adding this
functionality.

[0]: https://datatables.net/
[1]: https://datatables.net/extensions/fixedheader/

I tested locally by downloading a new bundled datatables.css /
datatables.jss with fixedheader included and adjusting the dmd template
and javascript with the attached patch.

It does work nicely with the todolist table, but I think the colspan /
rowspan in the dmddetails table throws off the sizing of the header when
it becomes sticky. The header cells become larger and then don't align
with the actual columns of the table.

It would be nice if someone who understands web stuff better could turn
this a functional patch.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
diff --git i/web/js/dmd.js w/web/js/dmd.js
index 4925098..2fb12bf 100644
--- i/web/js/dmd.js
+++ w/web/js/dmd.js
@@ -32,7 +32,8 @@ $(document).ready(function() {
 
 $('#todolist').DataTable( {
"paging": false,
-"info": false
+"info": false,
+   fixedHeader: true,
 });
 
 var dmddetails = $('#dmddetails').DataTable( {
@@ -40,6 +41,7 @@ var dmddetails = $('#dmddetails').DataTable( {
"paging": false,
"info": false,
"autoWidth": false,
+   fixedHeader: true,
stateSave: true,
buttons: [ {
  extend: 'colvis',
diff --git i/web/templates/dmd.erb w/web/templates/dmd.erb
index 44997c0..45519b3 100644
--- i/web/templates/dmd.erb
+++ w/web/templates/dmd.erb
@@ -2,9 +2,7 @@
 
 
 
-
-
-
+
 
 
 Debian Maintainer Dashboard
@@ -382,14 +380,10 @@
 
 
 
-
-
-
+
 
 
 
 
-
-
 
 

Bug#1074789: [Pkg-utopia-maintainers] Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Michael Biebl]

Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:

On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:


connect(5, {sa_family=AF_UNIX, 
sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1 ECONNREFUSED 
(Connection refused)



systemd should be listening on this socket


Well, on no less than four different Debian machines, it does not.


$ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd   1 root   28u  unix 0x73ac41e2  0t0 8696
/run/systemd/userdb/io.systemd.DynamicUser type=STREAM (LISTEN)


Isn't that on a machine where systemd-userdb is installed maybe? The
installation of that package triggers the systemd binary to listen?


No, systemd-userdb is not installed and as you can see from the above 
output it's actually systemd which listens on that socket.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074789: systemd-sysusers and userdb/io.systemd.DynamicUser socket [was: Bug#1074789: polkitd: postinst configure first install fails due to systemd-sysusers not working]

[Lionel Élie Mamane]

Dear systemd maintainers,

The polkitd postinst script invokes systemd-sysusers, and relies on it
being functional, under the sole condition that this binary is
present; in Debian this is equivalent to the systemd package being
installed since /bin/systemd-sysusers is in that package.

Is this a correct assumption or is there an additional condition for
systemd-sysusers to be functional that the polkitd postinst script
should be checking before invocation?

I hit a scenario where it doesn't work, and makes the installation
(configure phase) of polkitd fail, due to the necessary user not being
created. I traced that back to systemd-sysusers trying to connect to
/run/systemd/userdb/io.systemd.DynamicUser

On all my Debian machines, that socket exists but nobody is listening
on it. A polkitd maintainer argues that systemd should be listening on
it, and on his machine it does.

The stdout/stderr of the invocation looks like:

$ sudo systemd-sysusers polkitd.conf
Failed to check if group polkitd already exists: Connection refused

but the return value is 0, which would indicate success. But the user
that should be created is not created. At least this seems to be a bug
in systemd-sysusers; according to usual interface, and as documented
in its man page, if it failed to perform its job, it should return
non-zero.

What is your take on this?

You can see the history of the discussion in bug #1074789
https://bugs.debian.org/1074789

systemd version 252.26-1~deb12u2 on amd64, and systemd-userdbd is not
installed.

Thanks in advance,

-- 
Lionel Mamane

Bug#1074789: systemd-sysusers: Failed to check if group polkitd already exists: Connection refused (on /run/systemd/userdb/io.systemd.DynamicUser)

[Simon McVittie]

Control: reassign -1 systemd
Control: retitle -1 systemd-sysusers: Failed to check if group polkitd already 
exists: Connection refused (on /run/systemd/userdb/io.systemd.DynamicUser)
Control: affects -1 + polkitd

On Wed, 03 Jul 2024 at 19:25:15 +0200, Michael Biebl wrote:
> Am 03.07.24 um 17:15 schrieb Lionel Élie Mamane:
> > $ ls -al /run/systemd/userdb/io.systemd.DynamicUser
> > srw-rw-rw- 1 root root 0 24 mai 17:36 
> > /run/systemd/userdb/io.systemd.DynamicUser
> > 
> > $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> > lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
> >Output information may be incomplete.
> 
> systemd should be listening on this socket
> 
> At this point, I think it's a systemd issue.

I think it's fairly clear, at least, that this *isn't* a polkitd issue:
its postinst is just using systemd-sysusers in an obvious way, so this
(whatever the underlying issue is here) is going to affect increasingly
many packages as they adopt systemd-sysusers as their way to create their
required system users.

smcv

Bug#1075720: authbind does not honor CFLAGS/LDFLAGS set by the maintainer

[Ian Jackson]

Olivier Gayot writes ("Bug#1075720: authbind does not honor CFLAGS/LDFLAGS set 
by the maintainer"):
> I just noticed that my quilt patch does not automatically apply because 
> authbind does not declare d/source/format.
> As a consequence, the patch is ignored and the build still runs without the 
> expected CFLAGS / LDFLAGS.

Oh!  (I hadn't looked at it yet.)

> I will rework the patch and update.

Thanks.  Please don't change the package source format.  Just checking
that the patch works if it is actually applied will be fine.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Lionel Élie Mamane]

On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:

 connect(5, {sa_family=AF_UNIX, 
 sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1 
 ECONNREFUSED (Connection refused)

> systemd should be listening on this socket

Well, on no less than four different Debian machines, it does not.

> $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> systemd   1 root   28u  unix 0x73ac41e2  0t0 8696
> /run/systemd/userdb/io.systemd.DynamicUser type=STREAM (LISTEN)

Isn't that on a machine where systemd-userdb is installed maybe? The
installation of that package triggers the systemd binary to listen?

> At this point, I think it's a systemd issue.

That's possible. Let's loop in the systemd maintainers.

Bug#1075724: rocblas: Give SIGILL on CPUS without the f16c extention

[Cordell Bloor]

Control: tags 1075724 + pending fixed-upstream

Hi Petter,

On 2024-07-03 12:04, Petter Reinholdtsen wrote:

When compiling llama.cpp with ROCm support and running it, I get a
illegal instruction crash in the binary.  The cause seem to be that
rocblas is built with -mf16c.


I'm preparing an upload with a fix for this and a couple other minor 
issues. It just takes a long time to verify, as the build is so long.


Sincerely,
Cory Bloor

Bug#1075720: authbind does not honor CFLAGS/LDFLAGS set by the maintainer

[Olivier Gayot]

Package: authbind
Version: 2.1.3
Followup-For: Bug #1075720
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

To avoid modifying the upstream makefile, I decided to pass the CFLAGS &
LDFLAGS variables on the CLI at the make invocation level.

Attaching the new debdiff.

Thanks,
Olivier
diff -Nru authbind-2.1.3build2/debian/control 
authbind-2.1.3ubuntu1~ppa4/debian/control
--- authbind-2.1.3build2/debian/control 2024-04-08 17:54:08.0 +0200
+++ authbind-2.1.3ubuntu1~ppa4/debian/control   2024-07-03 17:42:33.0 
+0200
@@ -1,8 +1,7 @@
 Source: authbind
 Section: utils
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Ian Jackson 
+Maintainer: Ian Jackson 
 Standards-Version: 3.9.1
 
 Package: authbind
diff -Nru authbind-2.1.3build2/debian/rules 
authbind-2.1.3ubuntu1~ppa4/debian/rules
--- authbind-2.1.3build2/debian/rules   2021-12-17 19:34:02.0 +0100
+++ authbind-2.1.3ubuntu1~ppa4/debian/rules 2024-07-03 17:42:33.0 
+0200
@@ -41,12 +41,8 @@
 INSTALL_SCRIPT  = $(INSTALL) -p-o root -g root  -m  755
 INSTALL_DIR = $(INSTALL) -p -d -o root -g root  -m  755
 
-CFLAGS = -O2 -Wall
-LDFLAGS = 
 
-
-CFLAGS += -g
-LDFLAGS += -g 
+include /usr/share/dpkg/buildflags.mk
 
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
 STRIP=$(TOOL_PREFIX)strip
@@ -55,8 +51,6 @@
 STRIP=:
 endif
 
-export CFLAGS
-export LDFLAGS
 export INSTALL
 export INSTALL_FILE
 export INSTALL_PROGRAM
@@ -68,7 +62,7 @@
 udp=debian/tmp/usr/share/doc/$(package)
 
 build-arch: 
-   $(MAKE) prefix=/usr CC='$(CC)' LD='$(TOOL_PREFIX)ld'
+   $(MAKE) prefix=/usr CC='$(CC)' LD='$(TOOL_PREFIX)ld' CFLAGS='$(CFLAGS)' 
LDFLAGS='$(LDFLAGS)'
 
 binary-arch:   checkroot build
rm -rf debian/tmp

Bug#1075129: lastpass-cli: ftbfs with GCC-14

[Chris Lamb]

forwarded 1075129 https://github.com/lastpass/lastpass-cli/issues/693
thanks

I've forwarded this upstream here:

  https://github.com/lastpass/lastpass-cli/issues/693


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1075721: octave-dicom: use-after-free with dicomdict

[Rafael Laboissière]

* Dan Bungert  [2024-07-03 11:23]:


Source: octave-dicom
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

I wanted to forward along a fix I have done for Ubuntu for octave-dicom. 
Ubuntu builds of octave-dicom were FTBFS on the built-in testsuite with 
use-after-free / segfault type issues.  I have not reproduced this build 
failure on Sid, but memory corruption issues are treacherous and might show up 
later.


If desired, more details can be found at 
https://bugs.launchpad.net/ubuntu/+source/octave-dicom/+bug/2069660 , 
but the summary is that I have moved the std::maps used by dicomdict to static 
storage to address this.  I believe that the destructors are getting confused 
with the multiple copies of dicomdict, due to the functionality being built 
into several plugins and plugins being loaded by octave with RTLD_GLOBAL.


The patch passes the built-in testsuite, along with my attempts to confuse the 
dict information loaded with specific plugin ordering.


Please see attached.  Also, the upstream bug tracker at 
https://octave.space/savannah/?Action=get&Format=HTMLCSS&Title=[octave%20forge]%20(dicom) 
seems to be down, so if you have information about how best to reach upstream, 
I'd appreciate it.


Thank you for the bug report.

Indeed, the website octave.space is down. You might try the following 
URL for searching the bugs filed against the dicom package: 
https://savannah.gnu.org/search/?search=Search&words0=dicom&type_of_search=bugs&only_group_id=1925&exact=1&max_rows=#options


You might file a bug report using this URL: 
https://savannah.gnu.org/bugs/?group=octave&func=additem


Best,

Rafael Laboissière

Bug#1005961: nq,fq: trying to overwrite '/usr/bin/fq', which is also in package nq 0.3.1-4

[Leah Neukirchen]

Stephen Gelman  writes:

>  Great, that would be perfect if you’re willing to do so! Just let me know
> when that’s done and I can work with the nq debian maintainer to get that
> uploaded.

nq 1.0 has been release without conflicting names.

-- 
Leah Neukirchenhttps://leahneukirchen.org

Bug#1075603: debugpy: incompatible with new pydevd

[Julian Gilbey]

On Wed, Jul 03, 2024 at 02:52:00PM +0200, Gianfranco Costamagna wrote:
> Source: debugpy
> Version: 1.8.0+ds-4
> Severity: serious
> 
> Hello, the debugpy can't build anymore from source
>  sbuild-build-depends-main-dummy : Depends: python3-pydevd (< 2.11) but 
> 3.1.0+ds-2 is to be installed
> 
> 
> Looks like 1.8.2 is out, but I'm unsure about the compatibility with pydevd 
> 3.1.0

Yes, indeed.  pydevd had a FTBFS bug, which the upgrade fixed.
Unfortunately, debugpy has diverged from pydevd, and 1.8.2 has
multiple test failures when built in a Debian context, even when using
the vendored pydevd shipped with it, but not when run within a venv.
I have not yet got to the bottom of it, but will release 1.8.2 when I
have managed to do so.

Any help to track this down would be much appreciated - email me
privately if you (or anyone else reading this bug report) wants to
offer!

Best wishes,

   Julian

Bug#1075724: rocblas: Give SIGILL on CPUS without the f16c extention

[Petter Reinholdtsen]

Package: rocblas
Version: 5.5.1+dfsg-5
Tags: patch

When compiling llama.cpp with ROCm support and running it, I get a
illegal instruction crash in the binary.  The cause seem to be that
rocblas is built with -mf16c.

I built llama.cpp using this command line:

  HIPCXX=clang-17 cmake -H. -Bbuild -DGGML_HIPBLAS=ON 
-DCMAKE_HIP_ARCHITECTURES="gfx803;gfx900;gfx906;gfx908;gfx90a;gfx942;gfx1010;gfx1030;gfx1100;gfx1101;gfx1102"
 -DCMAKE_BUILD_TYPE=Release -DGGML_NATIVE=ON

I see the crash after downloading a model from huggingface and starting
bin/llama-cli using this model.  Using valgrind, I get this report from
the crash:

   ==27243== Warning: set address range perms: large range [0x221c55000,
   0x231e56000) (noaccess)
   llama_kv_cache_init:  ROCm0 KV buffer size =   256,00 MiB
   llama_new_context_with_model: KV self size  =  256,00 MiB, K (f16):  128,00
   MiB, V (f16):  128,00 MiB
   llama_new_context_with_model:  ROCm_Host  output buffer size = 0,12 MiB
   llama_new_context_with_model:  ROCm0 compute buffer size =   164,00 MiB
   llama_new_context_with_model:  ROCm_Host compute buffer size =12,01 MiB
   llama_new_context_with_model: graph nodes  = 1030
   llama_new_context_with_model: graph splits = 2
   vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x79 0x13 0xC0 0xC5
   0xF0 0x57 0xC9 0xC5
   vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
   vex amd64->IR:   VEX=1 VEX.L=0 VEX.n=0x0 ESC=0F38
   vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
   ==27243== valgrind: Unrecognised instruction at address 0x1331a8a8.
   ==27243==at 0x1331A8A8: ??? (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x13326E28: ??? (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x13157CBA: ??? (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x13155D51: ??? (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x1314DB31: ??? (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x1314B477: rocblas_gemm_batched_ex (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x1305CD09: hipblasGemmBatchedEx (in
   /usr/lib/x86_64-linux-gnu/libhipblas.so.0.1)
   ==27243==by 0x4AA55CD:
   ggml_cuda_mul_mat_batched_cublas(ggml_backend_cuda_context&, ggml_tensor
   const*, ggml_tensor const*, ggml_tensor*) (in
   /home/pere/src/ki/llama.cpp/build/ggml/src/libggml.so)
   ==27243==by 0x4A94C71: ggml_backend_cuda_graph_compute(ggml_backend*,
   ggml_cgraph*) (in /home/pere/src/ki/llama.cpp/build/ggml/src/libggml.so)
   ==27243==by 0x4A1E61C: ggml_backend_sched_graph_compute_async (in
   /home/pere/src/ki/llama.cpp/build/ggml/src/libggml.so)
   ==27243==by 0x48D1A32: llama_decode (in
   /home/pere/src/ki/llama.cpp/build/src/libllama.so)
   ==27243==by 0x13C4EC: llama_init_from_gpt_params(gpt_params&) (in
   /home/pere/src/ki/llama.cpp/build/bin/llama-cli)
   ==27243== Your program just tried to execute an instruction that Valgrind
   ==27243== did not recognise.  There are two possible reasons for this.
   ==27243== 1. Your program has a bug and erroneously jumped to a non-code
   ==27243==location.  If you are running Memcheck and you just saw a
   ==27243==warning about a bad jump, it's probably your program's fault.
   ==27243== 2. The instruction is legitimate but Valgrind doesn't handle it,
   ==27243==i.e. it's Valgrind's fault.  If you think this is the case or
   ==27243==you are not sure, please let us know and we'll try to fix it.
   ==27243== Either way, Valgrind will now raise a SIGILL signal which will
   ==27243== probably kill your program.
   ==27243== 
   ==27243== Process terminating with default action of signal 4 (SIGILL)
   ==27243==  Illegal opcode at address 0x1331A8A8
   ==27243==at 0x1331A8A8: ??? (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x13326E28: ??? (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x13157CBA: ??? (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x13155D51: ??? (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x1314DB31: ??? (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x1314B477: rocblas_gemm_batched_ex (in
   /usr/lib/x86_64-linux-gnu/librocblas.so.0.1)
   ==27243==by 0x1305CD09: hipblasGemmBatchedEx (in
   /usr/lib/x86_64-linux-gnu/libhipblas.so.0.1)
   ==27243==by 0x4AA55CD:
   ggml_cuda_mul_mat_batched_cublas(ggml_backend_cuda_context&, ggml_tensor
   const*, ggml_tensor const*, ggml_tensor*) (in
   /home/pere/src/ki/llama.cpp/build/ggml/src/libggml.so)
   ==27243==by 0x4A94C71: ggml_backend_cuda_graph_compute(ggml_backend*,
   ggml_cgraph*) (in /home/pere/src/ki/llama.cpp/build/ggml/src/libggml.so)
   ==27243==by 0x4A1E61C: ggml_backend_sched_graph_compute_async (in
   /home/pere/src/ki/llama.cpp/build/ggml/src/libggml.so)
   ==27243==by 0x48D1A32: llama_decod

Bug#1075723: krb5: Enable the LMDB backend for KDB

[Gauravsingh Sisodia]

Source: krb5
Severity: wishlist
X-Debbugs-Cc: xae...@gmail.com

Dear Maintainer,
Could you please enable the LMDB backend for KDB.

opensuse patch for reference: https://build.opensuse.org/request/show/1173687

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

Kernel: Linux 6.7.7 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1074633: qt6-base: upgrading libqt6core6t64 removes qpdfview and wireshark instead of upgrading them

[Vincent Lefevre]

Control: reassign -1 apt
Control: retitle -1 When installing a package, apt should always upgrade rather 
than remove packages to satisfy dependencies
Control: severity -1 normal
Control: found -1 2.6.1
Control: found -1 2.9.5
Control: found -1 2.9.6

Note: In the initial test, I had done "apt install libpoppler-dev".
"apt install libqt6core6t64" was just an attempt to simplify it,
but the result is exactly the same.

On 2024-07-03 19:13:37 +0200, Patrick Franz wrote:
> So in both cases, apt proposes a solution that does exactly what you 
> asked it for. In the first example, there are multiple solutions and apt 
> happened to pick one that you don't want. Why it picked that one and not 
> another one, I do not know. Maybe it found this solution quicker.

In any case, this is not satisfactory. Upgrades should always be
favored instead of removals.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

debian-bugs-dist@lists.debian.org

[Marco Mattiolo]

Hi Patrick,

I do not want to put too much burden on the Qt/KDE team. I've seen in 
the past weeks Qt6, then KF6 and now Plasma6 steadily being packaged and 
uploaded into experimental, making it easier and easier for me to test 
the plasma-mobile_6.x packaging. I know it's a big effort, so big thank 
you for that!


When you estimate it being matter of one month or less, I definitely 
prefer to have Mobian plasma-mobile weekly images' building to fail for 
a few weeks more (users still have the pre-time64-migration images 
available, then they can upgrade from there) and let you continue with 
Plasma6 packaging, in order to get plasma-mobile_6.x available sooner 
for Mobian users.


Kind regards

Marco

Il 02/07/24 22:48, Patrick Franz ha scritto:

Hi,

On Tue, 2 Jul 2024 19:39:27 +0200 Marco Mattiolo
 wrote:

Hi Santiago,

I'm the maintainer of plasma-mobile package in Debian, plus some of
the related apps. At the moment, the present bug keeps meta-plasma-
mobile metapackage out of trixie, thus letting the building of Mobian
plasma-mobile images to fail [1]. As I wrote in the previous message,
looking into buildd and reproducible-builds, I thought this to be
solved, but from your attachment I see I shouldn't have assumed.

I'm not the maintainer of wacomtablet, so I'm not sure what to touch
if tests are still failing. I see in your attachment that the error
message is always the same as in the original report, then I'd try
e.g. [2] that I see is not implemented in d/rules for wacomtablet,
but maybe it's just better to wait for the new version of wacomtablet
(6.1.0-1 now in experimental) to be uploaded to sid and check how that
new version behaves.

I don't have the resources to dig into why the tests are failing, but I
could disable them for the time being if wacomtablet is a blocker for
something right now.

We will definitely revisit this once the new version in exp (now part of
Plasma 6) can be compiled there.

Bug#1075722: google-android-platform-tools-installer: fail to install

[Paride Desimone]

Package: google-android-platform-tools-installer
Version: 33.0.3+1675172738
Severity: important
X-Debbugs-Cc: nos...@inventati.org

Dear Maintainer,

I try to install google-android-platform-tools-installer. But the installation
fail.

paride@arda:~$ sudo apt install   google-android-platform-tools-installer
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto
I seguenti pacchetti aggiuntivi saranno inoltre installati:
  google-android-licenses
I seguenti pacchetti NUOVI saranno installati:
  google-android-licenses google-android-platform-tools-installer
0 aggiornati, 2 installati, 0 da rimuovere e 0 non aggiornati.
È necessario scaricare 4.060 B/25,9 kB di archivi.
Dopo quest'operazione, verranno occupati 18,9 MB di spazio su disco.
Continuare? [S/n]
Scaricamento di:1 http://deb.debian.org/debian bookworm/non-free amd64 google-
android-licenses all 1675172738 [4.060 B]
Recuperati 4.060 B in 0s (25,5 kB/s)
Preconfigurazione dei pacchetti in corso
Selezionato il pacchetto google-android-licenses non precedentemente
selezionato.
(Lettura del database... 570561 file e directory attualmente installati.)
Preparativi per estrarre .../google-android-licenses_1675172738_all.deb...
Estrazione di google-android-licenses (1675172738)...
Selezionato il pacchetto google-android-platform-tools-installer non
precedentemente selezionato.
Preparativi per estrarre .../google-android-platform-tools-
installer_33.0.3+1675172738_amd64.deb...
Estrazione di google-android-platform-tools-installer (33.0.3+1675172738)...
Configurazione di google-android-licenses (1675172738)...
Configurazione di google-android-platform-tools-installer
(33.0.3+1675172738)...
make: ingresso nella directory «/var/cache/google-android-platform-tools-
installer»
cd /var/cache/google-android-platform-tools-installer && \
su nobody -s /bin/sh -c "wget --continue
https://dl.google.com/android/repository/platform-tools_r33.0.3-linux.zip -O
platform-tools_r33.0.3-linux.zip.tmp && mv platform-tools_r33.0.
3-linux.zip.tmp platform-tools_r33.0.3-linux.zip"
--2024-07-03 19:28:42--  https://dl.google.com/android/repository/platform-
tools_r33.0.3-linux.zip
Risoluzione di dl.google.com (dl.google.com)... 216.58.206.46,
2a00:1450:4001:831::200e
Connessione a dl.google.com (dl.google.com)|216.58.206.46|:443... connesso.
Richiesta HTTP inviata, in attesa di risposta... 200 OK
Lunghezza: 7505569 (7,2M) [application/zip]
Salvataggio in: «platform-tools_r33.0.3-linux.zip.tmp»

platform-tools_r33.0.3-linux.zip.tmp
100%[=>]
7,16M  7,68MB/sin 0,9s

2024-07-03 19:28:43 (7,68 MB/s) - «platform-tools_r33.0.3-linux.zip.tmp»
salvato [7505569/7505569]

sha1sum -c platform-tools_r33.0.3-linux.zip.sha1
platform-tools_r33.0.3-linux.zip: OK

  Unzipping platform-tools_r33.0.3-linux.zip. Please be patient, this may take
some time.
install -d -m0755 /usr/share/doc/google-android-platform-tools
find /usr/share/doc/google-android-platform-tools | sort >>
/var/lib/dpkg/info/google-android-platform-tools-installer.list
chmod -R a+rX /var/cache/google-android-platform-tools-installer/platform-
tools/
chmod -R go-w /var/cache/google-android-platform-tools-installer/platform-
tools/
install -d -m0755 /usr/lib/android-sdk/
tac: failed to create temporary file in 'android-sdk/platform-tools': File o
directory non esistente
make: uscita dalla directory «/var/cache/google-android-platform-tools-
installer»

If I try to make the platform-tools directory, bookworm tell me, that this
directory already exist.


-- Package-specific info:
Installed google-android-* family packages:
  google-android-licenses   1675172738
  google-android-platform-tools-installer   33.0.3+1675172738
Content of /usr/lib/android-sdk (maxdepth 2):
  /usr/lib/android-sdk/
  /usr/lib/android-sdk/licenses
  /usr/lib/android-sdk/licenses/android-sdk-license
  /usr/lib/android-sdk/platform-tools
  /usr/lib/android-sdk/platform-tools/NOTICE.txt
  /usr/lib/android-sdk/platform-tools/adb
  /usr/lib/android-sdk/platform-tools/dmtracedump
  /usr/lib/android-sdk/platform-tools/e2fsdroid
  /usr/lib/android-sdk/platform-tools/etc1tool
  /usr/lib/android-sdk/platform-tools/fastboot
  /usr/lib/android-sdk/platform-tools/hprof-conv
  /usr/lib/android-sdk/platform-tools/lib64
  /usr/lib/android-sdk/platform-tools/make_f2fs
  /usr/lib/android-sdk/platform-tools/make_f2fs_casefold
  /usr/lib/android-sdk/platform-tools/mke2fs
  /usr/lib/android-sdk/platform-tools/mke2fs.conf
  /usr/lib/android-sdk/platform-tools/package.xml
  /usr/lib/android-sdk/platform-tools/sload_f2fs
  /usr/lib/android-sdk/platform-tools/source.properties
  /usr/lib/android-sdk/platform-tools/sqlite3

-- System Information:
Debian Release: 12.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')

Bug#1075721: octave-dicom: use-after-free with dicomdict

[Dan Bungert]

Source: octave-dicom
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

I wanted to forward along a fix I have done for Ubuntu for octave-dicom.
Ubuntu builds of octave-dicom were FTBFS on the built-in testsuite with
use-after-free / segfault type issues.  I have not reproduced this build
failure on Sid, but memory corruption issues are treacherous and might show up
later.

If desired, more details can be found at
https://bugs.launchpad.net/ubuntu/+source/octave-dicom/+bug/2069660 ,
but the summary is that I have moved the std::maps used by dicomdict to static
storage to address this.  I believe that the destructors are getting confused
with the multiple copies of dicomdict, due to the functionality being built
into several plugins and plugins being loaded by octave with RTLD_GLOBAL.

The patch passes the built-in testsuite, along with my attempts to confuse the
dict information loaded with specific plugin ordering.

Please see attached.  Also, the upstream bug tracker at
https://octave.space/savannah/?Action=get&Format=HTMLCSS&Title=[octave%20forge]%20(dicom)
seems to be down, so if you have information about how best to reach upstream,
I'd appreciate it.

-Dan

P.S. - this is my second attempt at forwarding this, so if you see a duplicate
assume mailserver weirdness and just close it.
Description: fix use-after-free due to symbol collisions across plugins
Bug-Ubuntu:  https://bugs.launchpad.net/bugs/2069660
Forwarded:   no
Last-Update: 2024-06-28

Move these symbols to static, which helps shield them from strange cleanup
ordering of the maps that can result in use-after-free due to the map
destructors performing an overwriting clear and that the symbols are referenced
from multiple plugins.
--- a/src/dicomdict.cpp
+++ b/src/dicomdict.cpp
@@ -51,9 +51,9 @@
 const char * factory_dicom_dict_filename="octavedicom.dic";
 static std::string dic_filename(factory_dicom_dict_filename);
 
-std::map tagmap ;
-std::map keymap ;
-std::map dict ;
+static std::map tagmap ;
+static std::map keymap ;
+static std::map dict ;
 
 void insert(const char *k, const gdcm::Tag t, const gdcm::DictEntry e)
 {

Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Michael Biebl]

Am 03.07.24 um 17:15 schrieb Lionel Élie Mamane:

On Wed, Jul 03, 2024 at 01:14:35PM +0200, Michael Biebl wrote:

Am 03.07.24 um 11:57 schrieb Lionel Élie Mamane:



connect(5, {sa_family=AF_UNIX, 
sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1 ECONNREFUSED 
(Connection refused)



This socket is provided by systemd itself. Please post the output of



ls -al /run/systemd/userdb/io.systemd.DynamicUser


$ ls -al /run/systemd/userdb/io.systemd.DynamicUser
srw-rw-rw- 1 root root 0 24 mai 17:36 /run/systemd/userdb/io.systemd.DynamicUser


lsof /run/systemd/userdb/io.systemd.DynamicUser


$ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
   Output information may be incomplete.



systemd should be listening on this socket


$ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
  Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
  Output information may be incomplete.
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd   1 root   28u  unix 0x73ac41e2  0t0 8696 
/run/systemd/userdb/io.systemd.DynamicUser type=STREAM (LISTEN)



At this point, I think it's a systemd issue.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1075720: authbind does not honor CFLAGS/LDFLAGS set by the maintainer

[Olivier Gayot]

Hello,

I just noticed that my quilt patch does not automatically apply because 
authbind does not declare d/source/format.
As a consequence, the patch is ignored and the build still runs without the 
expected CFLAGS / LDFLAGS.

I will rework the patch and update.

Thanks,
Olivier

Bug#1074633: qt6-base: upgrading libqt6core6t64 removes qpdfview and wireshark instead of upgrading them

[Patrick Franz]

Hej Vincent,

Am Mittwoch, 3. Juli 2024, 01:02:28 CEST schrieb Vincent Lefevre:
[...]
> In particular, "apt install libqt6core6t64" wants to remove
> qt6-wayland, but if I try "apt install libqt6core6t64 qt6-wayland",
> then the upgrade is fine. So there seems to be really something
> wrong with the Qt package relationships.

The dependencies of Qt are fine, you just ended up in an unfortunate 
situation that makes it look as if the dependencies in Qt are wrong.

The upgrade from Qt 6.4 to 6.6 involves a number of Break+Replaces, but 
that doesn't mean anything is wrong.

In your first example, you only wanted to upgrade libqt6core6t64. The 
thing here is that there are multiple solutions about what to do with 
the reverse dependencies. Some solutions remove a lot of them and 
install as little as possible, others replace a bunch of libs and remove 
fewer packages.
You asked apt to upgrade libqt6core6t64 and that is exactly what apt 
did. The issue is that the proposed solution is correct, but it's just 
not your preferred one.
In your second example, removing all those libraries without replacing 
them is not a viable option, because that would make wireshark 
uninstallable. Therefore, apt installs a number of libs to satisfy the 
dependencies of wireshark.

So in both cases, apt proposes a solution that does exactly what you 
asked it for. In the first example, there are multiple solutions and apt 
happened to pick one that you don't want. Why it picked that one and not 
another one, I do not know. Maybe it found this solution quicker.
But all that doesn't mean that the dependencies in Qt are wrong. In 
fact, all the libs that apt wants to remove are not compatible with 
libqt6core6t64 6.6.2 and therefore removing them is correct.

I absolutely do not see that this is a problem with Qt's dependencies. 
It's just that apt gives you a correct solution that you don't like and 
hence have to adjust the upgrade command slightly. But nothing is wrong 
with Qt's dependencies.

You can either close this bug or you can re-assign the bug to apt and 
turn it into a wishlist item suggesting that apt give you more than 1 
solution in such cases.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1075720: authbind does not honor CFLAGS/LDFLAGS set by the maintainer

[Olivier Gayot]

Package: authbind
Version: 2.1.3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch

Dear Maintainer,

When building authbind, CFLAGS and LDFLAGS are overwritten by the
upstream makefile (and are also hardcoded in debian/rules). Therefore,
flags specified via dpkg-buildflags are ignored.

In Ubuntu, the attached patch was applied to enable frame-pointers and
enable LTO.

Thanks for considering the patch.


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

Kernel: Linux 6.8.0-36-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru authbind-2.1.3build2/debian/control 
authbind-2.1.3ubuntu1~ppa2/debian/control
--- authbind-2.1.3build2/debian/control 2024-04-08 17:54:08.0 +0200
+++ authbind-2.1.3ubuntu1~ppa2/debian/control   2024-07-03 17:42:33.0 
+0200
@@ -1,8 +1,7 @@
 Source: authbind
 Section: utils
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Ian Jackson 
+Maintainer: Ian Jackson 
 Standards-Version: 3.9.1
 
 Package: authbind
diff -Nru 
authbind-2.1.3build2/debian/patches/makefile-honor-cflags-ldflags.patch 
authbind-2.1.3ubuntu1~ppa2/debian/patches/makefile-honor-cflags-ldflags.patch
--- authbind-2.1.3build2/debian/patches/makefile-honor-cflags-ldflags.patch 
1970-01-01 01:00:00.0 +0100
+++ 
authbind-2.1.3ubuntu1~ppa2/debian/patches/makefile-honor-cflags-ldflags.patch   
2024-07-03 17:42:33.0 +0200
@@ -0,0 +1,28 @@
+Description: Honor CFLAGS and LDFLAGS set by the maintainer
+ The upstream makefile used to override any CFLAGS / LDFLAGS set by the
+ maintainer when building authbind. This prevents us from controlling the
+ presence of frame pointers when building. It also prevents us from enabling
+ LTO.
+ Fixed by dropping directives that overwrite CFLAGS & LDFLAGS ; and only adding
+ to those variables when relevant.
+Author: Olivier Gayot 
+Bug-Ubuntu: https://launchpad.net/bugs/2071841
+Forwarded: no
+Last-Update: 2024-07-03
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/Makefile
 b/Makefile
+@@ -34,11 +34,8 @@
+ INSTALL_DIR   ?= install -o root -g root -m 755 -d
+ STRIP ?= strip
+ 
+-OPTIMISE= -O2
+-LDFLAGS=  -g
+ LIBS= -ldl -lc
+-CFLAGS=   -g $(OPTIMISE) \
+-  -Wall -Wwrite-strings -Wpointer-arith -Wimplicit \
++CFLAGS+=  -Wall -Wwrite-strings -Wpointer-arith -Wimplicit \
+   -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes
+ CPPFLAGS= -DMAJOR_VER='"$(MAJOR)"' -DMINOR_VER='"$(MINOR)"' \
+   -DLIBAUTHBIND='"$(lib_dir)/$(LIBCANON)"' \
diff -Nru authbind-2.1.3build2/debian/patches/series 
authbind-2.1.3ubuntu1~ppa2/debian/patches/series
--- authbind-2.1.3build2/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ authbind-2.1.3ubuntu1~ppa2/debian/patches/series2024-07-03 
17:42:33.0 +0200
@@ -0,0 +1 @@
+makefile-honor-cflags-ldflags.patch
diff -Nru authbind-2.1.3build2/debian/rules 
authbind-2.1.3ubuntu1~ppa2/debian/rules
--- authbind-2.1.3build2/debian/rules   2021-12-17 19:34:02.0 +0100
+++ authbind-2.1.3ubuntu1~ppa2/debian/rules 2024-07-03 17:42:33.0 
+0200
@@ -41,12 +41,10 @@
 INSTALL_SCRIPT  = $(INSTALL) -p-o root -g root  -m  755
 INSTALL_DIR = $(INSTALL) -p -d -o root -g root  -m  755
 
-CFLAGS = -O2 -Wall
-LDFLAGS = 
 
+DPKG_EXPORT_BUILDFLAGS := 1
 
-CFLAGS += -g
-LDFLAGS += -g 
+include /usr/share/dpkg/buildflags.mk
 
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
 STRIP=$(TOOL_PREFIX)strip
@@ -55,8 +53,6 @@
 STRIP=:
 endif
 
-export CFLAGS
-export LDFLAGS
 export INSTALL
 export INSTALL_FILE
 export INSTALL_PROGRAM

Bug#1075395: Fwd: Bug#1075395: postfix-gld: ftbfs with GCC-14

[Santiago Vila]

Hello.

I've received the following report from the Debian bug system.

Summary: GLD does not build ok when using gcc-14 due to incorrect declarations
of some arguments.

The attached diff, which I will apply in my next upload, seems to be enough
to fix the problem.

Thanks.

 Mensaje reenviado 
Asunto: Bug#1075395: postfix-gld: ftbfs with GCC-14
De: Matthias Klose 

Package: src:postfix-gld
Version: 1.7-9
Severity: important
Tags: sid trixie
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-14

[This bug is targeted to the upcoming trixie release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
severity of this report will be raised before the trixie release.

The full build log can be found at:
http://qa-logs.debian.net/2024/07/01/postfix-gld_1.7-9_unstable_gccexp.log
The last lines of the build log are at the end of this report.

To build with GCC 14, either set CC=gcc-14 CXX=g++-14 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-14/porting_to.html

[...]
  141 | if(s<0) return(S_SOCK_ERR);
  | ^~
sockets.c:143:9: note: ...this statement, but the latter is misleadingly 
indented as if it were guarded by the ‘if’
  143 | timeout.tv_sec=tout;
  | ^~~
sockets.c: In function ‘ReadUdpData’:
sockets.c:494:68: warning: pointer targets in passing argument 6 of ‘recvfrom’ 
differ in signedness [-Wpointer-sign]
  494 |nbytes=recvfrom(s,buffer,maxsize,0,(struct sockaddr *)0,(int 
*)0);
  |
^~~~
  ||
  |int *
In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:343,
 from sockets.h:17,
 from sockets.c:31:
/usr/include/x86_64-linux-gnu/bits/socket2.h:62:56: note: expected ‘socklen_t * 
restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int *’
   62 |   __SOCKADDR_ARG __addr, socklen_t *__restrict __addr_len)
  |  ~~^~
sockets.c: In function ‘CloseSocket’:
sockets.c:518:30: warning: comparison of constant ‘0’ with boolean expression 
is always false [-Wbool-compare]
  518 | if ( (s && close(s)) < 0 ) return(S_CLOS_ERR);
  |  ^
sockets.c: In function ‘GetPeerIp’:
sockets.c:643:48: error: passing argument 3 of ‘getpeername’ from incompatible 
pointer type [-Wincompatible-pointer-types]
  643 | if (getpeername(sock,(struct sockaddr *)&from, &foo) == 0)
  |^~~~
  ||
  |size_t * {aka long 
unsigned int *}
/usr/include/x86_64-linux-gnu/sys/socket.h:131:47: note: expected ‘socklen_t * 
restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘size_t *’ 
{aka ‘long unsigned int *’}
  131 | socklen_t *__restrict __len) __THROW;
  | ~~^
sockets.c: In function ‘WaitTcpServer’:
sockets.c:726:54: error: passing argument 3 of ‘accept’ from incompatible 
pointer type [-Wincompatible-pointer-types]
  726 | return(accept(serv.sd,(struct sockaddr *)&(serv.sin),&foo));
  |  ^~~~
  |  |
  |  size_t * {aka long 
unsigned int *}
/usr/include/x86_64-linux-gnu/sys/socket.h:307:42: note: expected ‘socklen_t * 
restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘size_t *’ 
{aka ‘long unsigned int *’}
  307 |socklen_t *__restrict __addr_len);
  |~~^~
make[1]: *** [Makefile:9: sockets.o] Error 1
make[1]: *** Waiting for unfinished jobs
greylist.c: In function ‘GreyList’:
greylist.c:99:9: warning: ‘__builtin_strncpy’ output may be truncated copying 
31 bytes from a string of length 31 [-Wstringop-truncation]
   99 | strncpy(netw,oip,sizeof(netw)-1);
  | ^
server.c: In function ‘HandleChild’:
server.c:226:84: warning: ‘%s’ directi

Bug#1075718: libvirt-clients: virsh domif-setlink fails to update state

[Cyril Brulebois]

Control: tag -1 patch upstream

Cyril Brulebois  (2024-07-03):
> The same happens with both 'up' and 'down', with or without --interface
> and --state, and really looks like some basic logic bug somewhere in the
> XML update code? (I haven't looked at the implementation just yet.)

There's an upstream fix published between 9.0.0 and 9.1.0:
  
https://gitlab.com/libvirt/libvirt/-/commit/6f3f6c0f763b9ffd8ef93eb124c88dd0b79138fc

I've verified it does the trick when added on top of the debian/bookworm
branch, and built for bookworm.

I've just created an MR for that:
  https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/224

and I'm also attaching the source debdiff.

It'd be nice to include this bugfix alongside the next set of
security/stability fixes, should such an upload be needed.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
--- libvirt-9.0.0/debian/patches/backport/virsh-Make-domif-setlink-work-more-than-once.patch	1970-01-01 01:00:00.0 +0100
+++ libvirt-9.0.0/debian/patches/backport/virsh-Make-domif-setlink-work-more-than-once.patch	2024-07-03 18:21:49.0 +0200
@@ -0,0 +1,43 @@
+From: Michal Privoznik 
+Date: Mon, 30 Jan 2023 10:55:22 +0100
+Subject: virsh: Make domif-setlink work more than once
+
+In virsh, we have this convenient domif-setlink command, which is
+just a wrapper over virDomainUpdateDeviceFlags() and which allows
+setting link state of given guest NIC. It does so by fetching
+corresponding  XML snippet and either putting  into it, OR if the element already exists setting the
+attribute to desired value. The XML is then fed into the update
+API.
+
+There's, however, a small bug in detecting the pre-existence of
+the element and its attribute. The code looks at "link"
+attribute, while in fact, the attribute is called "state".
+
+Resolves: https://gitlab.com/libvirt/libvirt/-/issues/426
+Fixes: e575bf082ed4889280be07c986375f1ca15bb7ee
+Signed-off-by: Michal Privoznik 
+Reviewed-by: Ján Tomko 
+
+Forwarded: non-needed
+Origin: https://gitlab.com/libvirt/libvirt/-/commit/6f3f6c0f763b9ffd8ef93eb124c88dd0b79138fc
+---
+ tools/virsh-domain.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
+index 6b431bd1e5..59b2b3ce60 100644
+--- a/tools/virsh-domain.c
 b/tools/virsh-domain.c
+@@ -3209,7 +3209,7 @@ cmdDomIfSetLink(vshControl *ctl, const vshCmd *cmd)
+ }
+ }
+ 
+-if (xmlHasProp(linkNode, BAD_CAST "link"))
++if (xmlHasProp(linkNode, BAD_CAST "state"))
+ stateAttr = xmlSetProp(linkNode, BAD_CAST "state", BAD_CAST state);
+ else
+ stateAttr = xmlNewProp(linkNode, BAD_CAST "state", BAD_CAST state);
+-- 
+2.39.2
+
--- libvirt-9.0.0/debian/patches/series	2023-05-21 11:31:31.0 +0200
+++ libvirt-9.0.0/debian/patches/series	2024-07-03 18:22:22.0 +0200
@@ -10,6 +10,7 @@
 backport/rpc-Don-t-warn-about-max_client_requests-in-single-thread.patch
 backport/conf-Fix-migration-in-some-firmware-autoselection-scenari.patch
 backport/virpci-Resolve-leak-in-virPCIVirtualFunctionList-cleanup.patch
+backport/virsh-Make-domif-setlink-work-more-than-once.patch
 forward/Skip-vircgrouptest.patch
 forward/Reduce-udevadm-settle-timeout-to-10-seconds.patch
 forward/Pass-GPG_TTY-env-var-to-the-ssh-binary.patch


signature.asc
Description: PGP signature

Bug#1075714: (no subject)

[Steven Maddox]

Small omission...

"This reallypromoting the adoption of IPv6!"
 ^isn't

:)

Unless of course I've got this completely wrong and there is a way to do 
both a static IPv4 and a static IPv6 completely through d-i before the 
system even reboots into Debian for the first time.


But if you can, it's certainly not obvious and that's an issue in itself.

Bug#1071523: r-cran-spatstat.geom: autopkgtest regression in testing

[Graham Inggs]

Hi Andreas

On Wed, 3 Jul 2024 at 05:18, Andreas Tille  wrote:
> Well, sure.  But our tooling will add this for the next upstream version
> again and if the problem is not solved otherwise it will re-appear.  I
> will upload this change but I would prefer understanding the issue and
> provide a real fix.

Looking at the riscv64 results for r-cran-spatstat.geom [1], which
were passing because r-cran-spatstat.core was not available there, it
seems that the autopkgtest-pkg-r test consists only of an attempt to
load the library:

# Try to load package
echo "Test: Try to load the R library ${pkgname}"
R --no-save -e "library('${pkgname}')"

Being a superficial test, I think this causes far more problems than
it is actually worth, and I suggest to disable it until a fix for
#961138 is found.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-spatstat.geom/testing/riscv64/

Bug#1074495: Greetd init.d file

[Juliusz Chroboczek]

> Greetd does not include an init script, forcing the use of SystemD.  The
> attached script seems to work for me, please consider including it with
> the Debian package for greetd.

That only appeared to work, since the greetd deamon doesn't fork itself.
The attached works better.

#!/bin/sh

### BEGIN INIT INFO
# Provides:  greetd
# Required-Start:$local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: The greetd login manager
### END INIT INFO

set -e

DEFAULT_DISPLAY_MANAGER_FILE=/etc/X11/default-display-manager

PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON=/usr/sbin/greetd

test -x $DAEMON || exit 0

. /lib/lsb/init-functions

SSD_START_ARGS="--background --exec $DAEMON --name $(basename $DAEMON) 
--startas $DAEMON"
SSD_STOP_ARGS="--exec $DAEMON --name $(basename $DAEMON) --retry TERM/5/TERM/5"

case "$1" in
  start)
if [ -e $DEFAULT_DISPLAY_MANAGER_FILE ] &&
   [ "$(cat $DEFAULT_DISPLAY_MANAGER_FILE)" != "$DAEMON" ]; then
  echo "Not starting greetd; it is not the default" \
"display manager."
else
  log_daemon_msg "Starting greetd" "greetd"
  start-stop-daemon --start --quiet $SSD_START_ARGS \
|| log_progress_msg "already running"
  log_end_msg 0
fi
  ;;

  restart)
/etc/init.d/greetd stop
/etc/init.d/greetd start
  ;;

  force-reload)
/etc/init.d/greetd restart
  ;;

  stop)
log_daemon_msg "Stopping greetd" "greetd"
start-stop-daemon --stop --quiet $SSD_STOP_ARGS
SSD_RES=$?
if [ $SSD_RES -eq 1 ]; then
  log_progress_msg "not running"
fi
if [ $SSD_RES -eq 2 ]; then
  log_progress_msg "not responding to TERM signals"
fi
log_end_msg 0
  ;;

  *)
echo "Usage: /etc/init.d/greetd {start|stop|restart|force-reload}"
exit 1
;;
esac

exit 0

Bug#1073203: Vendoring an unmaintained library?

[Andreas Metzler]

On 2024-07-03 Alexandre Rossi  wrote:
[...]
> #1073005 asks for the vendoring back of an unvendored library, arguing
> that this particular library is unmaintained upstream, implying that the
> vendored fork is better maintained.

> My view on this is that if the vendored fork is better maintained, the
> vendored fork should become the upstream of the Debian package.
[...]

FWIW both FreeBSD and Gentoo have switched to the suggested fork (last
commit 2020), while the original source on sf is quite dead (last change
2013).

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1074592: RFS: selint/1.5.0-2 -- Static code analysis of refpolicy style SELinux policies

[Phil Wyett]

Hi Christian,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Good

3. Licenses: Issue

philwyett@ks-windu:~/Development/builder/debian/mentoring/selint-1.5.0$ lrc
en: Versions: recon 1.11  check 3.3.9-1

Parsing Source Tree  
Reading copyright
Running licensecheck 

d/copyright | licensecheck

Apache-2.0  | FSFAPINSTALL

It would be nice if this minor issue could be fixed in this upload.

4. Build Twice (sudo pbuilder build --twice .dsc): Good

5. Reproducible builds (reporotest)[1]: Good

6. Install (No previous installs): Good

7. Upgrade (Over previous installs if any): Good

[1] https://wiki.debian.org/ReproducibleBuilds/Howto#Newer_method

Summary...

Excluding the one minor issue, I believe selint is ready for 
sponsorship/upload. Could a Debian
Developer (DD) with available free time, please review this package and upload 
if you feel it is
ready.

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1075593: u-boot: ftbfs with GCC-14

[Vagrant Cascadian]

Control: tag 1075593 moreinfo

On 2024-07-03, Matthias Klose wrote:
> The full build log can be found at:
> http://qa-logs.debian.net/2024/07/01/u-boot_2024.01+dfsg-5_unstable_gccexp.log
> The last lines of the build log are at the end of this report.

Seems like the build dependencies failed to install; The more
interesting part of the build log is:

  The following packages have unmet dependencies:
   gcc-14-aarch64-linux-gnu : Depends: libgcc-14-dev-arm64-cross (>= 
14-20240207-1cross1) but 14-20240127-1cross1 is to be installed
   gcc-14-arm-linux-gnueabihf : Depends: libgcc-14-dev-armhf-cross (>= 
14-20240207-1cross1) but 14-20240127-1cross1 is to be installed
   gcc-14-i686-linux-gnu : Depends: libgcc-14-dev-i386-cross (>= 
14-20240207-1cross1) but 14-20240127-1cross1 is to be installed
   gcc-14-riscv64-linux-gnu : Depends: libgcc-14-dev-riscv64-cross (>= 
14-20240207-1cross1) but 14-20240127-1cross1 is to be installed
  E: Unable to correct problems, you have held broken packages.
  apt-get failed.
  E: Package installation failed
  Not removing build depends: cloned chroot in use

I do not think the problem is u-boot here, but solely the fact that
u-boot depends on cross-toolchains which were not yet available?

Please re-run the tests when the cross-toolchains become available.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1075719: awscli: ecr get-login-password fails with "No module named 'botocore.vendored.six.moves'"

[Tatsuki Sugiura]

Package: awscli
Version: 2.15.22-1
Severity: normal

Dear Maintainer,

I get following error when use `aws ecr get-login-password`

-
sugi@tempest:~% aws ecr get-login-password --region ap-northeast-1
Traceback (most recent call last):
  File "/usr/bin/aws", line 19, in 
import awscli.clidriver
  File "/usr/lib/python3/dist-packages/awscli/clidriver.py", line 21, in 

import botocore.session
  File "/usr/lib/python3/dist-packages/awscli/botocore/session.py", line 27, in 

import botocore.client
  File "/usr/lib/python3/dist-packages/awscli/botocore/client.py", line 16, in 

from botocore import UNSIGNED, waiter, xform_name
  File "/usr/lib/python3/dist-packages/awscli/botocore/waiter.py", line 17, in 

from botocore.docs.docstring import WaiterDocstring
  File "/usr/lib/python3/dist-packages/awscli/botocore/docs/__init__.py", line 
15, in 
from botocore.docs.service import ServiceDocumenter
  File "/usr/lib/python3/dist-packages/awscli/botocore/docs/service.py", line 
13, in 
from botocore.docs.bcdoc.restdoc import DocumentStructure
  File "/usr/lib/python3/dist-packages/awscli/botocore/docs/bcdoc/restdoc.py", 
line 15, in 
from botocore.compat import OrderedDict
  File "/usr/lib/python3/dist-packages/awscli/botocore/compat.py", line 36, in 

from botocore.vendored.six.moves import http_client
ModuleNotFoundError: No module named 'botocore.vendored.six.moves'
-

I tried to install python3-botocore, but nothing has been changed.


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

Kernel: Linux 6.8.12-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=ja_JP.utf8 (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 awscli depends on:
ii  groff-base1.23.0-4
ii  python3   3.12.2-1
ii  python3-awscrt0.20.4+dfsg-1+b1
ii  python3-colorama  0.4.6-4
ii  python3-cryptography  42.0.5-2
ii  python3-dateutil  2.9.0-2
ii  python3-distro1.9.0-1
ii  python3-docutils  0.20.1+dfsg-3
ii  python3-jmespath  1.0.1-1
ii  python3-prompt-toolkit3.0.47-1
ii  python3-pyasn10.5.1-1
ii  python3-ruamel.yaml   0.18.6+ds-3
ii  python3-ruamel.yaml.clib  0.2.8+ds-1
ii  python3-urllib3   2.0.7-2

awscli recommends no packages.

awscli suggests no packages.

-- no debconf information

Bug#1074540: anacron: Anacron hangs on removal

[Lin Qigang]

On 6/30/24 9:20 PM, Balbir Thomas wrote:

Package: anacron
Version: 2.3-36
Severity: normal

Dear Maintainer,

I was experiencing long delays on shutdown of my laptop because
anacron was running a long running task with no time limit.
I found anacron was only installed because it was a dependency
of task-laptop. I removed task-laptop then I tried to remove
anacron using "apt remove --purge anacron" . However this
lead to a hang and the removal process never terminates, requiring
killall.



Other than task-laptop, logrotate also depends on anacron, so I would 
not recommend removal. If you know which task is long running, you could 
disable the task in "/etc/cron.*", "/etc/anacrontab", or "/etc/crontab". 
I am not familiar with "apt remove --purge", so I have added the apt 
team mailing list to help with debugging this issue. Any logs or other 
information you could provide would also be be good to have.



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

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

Versions of packages anacron depends on:
ii  libc6  2.36-9+deb12u7
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages anacron recommends:
ii  cron [cron-daemon]  3.0pl1-162

Versions of packages anacron suggests:
ii  msmtp-mta [mail-transport-agent]  1.8.23-1
ii  powermgmt-base1.37
ii  rsyslog [system-log-daemon]   8.2302.0-1

-- no debconf information


--
Lance Lin
GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7



OpenPGP_0x903649294C33F9B7.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071755: RFS: open62541/1.4.2-1 [ITP] -- open62541 () is an open source implementation

[Phil Wyett]

Control: tags -1 + moreinfo

Hi Julius,

There seems to be a number of license issues that need to e looked at and 
rectified as required
within 'debian/copyright'.

philwyett@ks-windu:~/Development/builder/debian/mentoring/open62541-1.4.2$ lrc
en: Versions: recon 1.11  check 3.3.9-1

Parsing Source Tree  
Reading copyright
Running licensecheck 

d/copyright | licensecheck

MPL-2.0 | Expatdeps/cj5.c
MPL-2.0 | Expatdeps/cj5.h
MIT | Expatdeps/itoa.c
MPL-2.0 | Expatdeps/itoa.h
MIT | Expatdeps/mp_printf.c
MIT | Expatdeps/mp_printf.h
MIT | Expatdeps/parse_num.c
MPL-2.0 | Expatexamples/nodeset/testtypes.bsd
MIT | Expatnodeset/Schema/Opc.Ua.NodeSet2.xml
MIT | Expatnodeset/Schema/Opc.Ua.Types.bsd
MPL-2.0 | Expattests/nodeset-compiler/testtypes.bsd
MPL-2.0 | BSD-3-clause tools/cmake/FindCheck.cmake
MPL-2.0 | ISC  tools/cmake/FindLibreSSL.cmake
MPL-2.0 | Expat
tools/schema/Opc.Ua.NodeSet2.DiagnosticsMinimal.xml
MPL-2.0 | Expat
tools/schema/Opc.Ua.NodeSet2.EventsMinimal.xml
MPL-2.0 | Expat
tools/schema/Opc.Ua.NodeSet2.HistorizingMinimal.xml
MPL-2.0 | Expat
tools/schema/Opc.Ua.NodeSet2.PubSubMinimal.xml
MPL-2.0 | Expattools/schema/Opc.Ua.NodeSet2.Reduced.xml
MPL-2.0 | Expattools/schema/Opc.Ua.Types.bsd

'debian/watch' is broken when you use 'uscan'.

philwyett@ks-windu:~/Development/builder/debian/mentoring/open62541-1.4.2$ 
uscan --force-download 
Newest version of open62541 on remote site is 2, local version is 1.4.2
 => Newer package available from:
=> https://api.github.com/repos/open62541/open62541/tarball/v1.4.2
uscan error: Parameter ../v1.4.2 does not look like a tar archive or a zip file.

Ref: https://wiki.debian.org/debian/watch#GitHub

Once updated to your satisfaction and a new upload done, please remove the 
'moreinfo' on the Request
For Sponsorship (RFS) bug report.

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Lionel Élie Mamane]

On Wed, Jul 03, 2024 at 01:14:35PM +0200, Michael Biebl wrote:
> Am 03.07.24 um 11:57 schrieb Lionel Élie Mamane:

>> connect(5, {sa_family=AF_UNIX, 
>> sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1 
>> ECONNREFUSED (Connection refused)

> This socket is provided by systemd itself. Please post the output of

> ls -al /run/systemd/userdb/io.systemd.DynamicUser

$ ls -al /run/systemd/userdb/io.systemd.DynamicUser
srw-rw-rw- 1 root root 0 24 mai 17:36 /run/systemd/userdb/io.systemd.DynamicUser

> lsof /run/systemd/userdb/io.systemd.DynamicUser

$ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
  Output information may be incomplete.

Bug#1036820: libsdl2-dev include headers not found by cmake since usr merge

[Simon McVittie]

On Wed, 03 Jul 2024 at 16:34:35 +0200, Nicolas Otton wrote:
> I was able to reproduce this bug on a debian bookworm installed recently.
> I have the same issue, cmake, libsdl2-dev and the other dependencies were
> installed through apt, not compiled from source, and CMAKE_CURRENT_LIST_DIR is
> set to /lib/x86_64-linux-gnu/cmake/SDL2 so the cmake of the projects fails.

How were you able to reproduce this? Please explain in more detail.

If you download and unpack the libsdl2 source package, you'll find several
simple test projects in debian/tests/cmake-*/ which are all run by the
test script debian/tests/cmake - it's intended to be run via autopkgtest,
but you can just run it as ./debian/tests/cmake from an unpacked libsdl2
source package. Do those tests pass or fail on your system?

If those tests pass, perhaps you could modify one of them into a
simplified version of whatever project is failing for you?

Or if you are invoking cmake with special options, please try to edit
./debian/tests/cmake so that it uses similar options and reproduces
this error.

smcv

Bug#1075717: mawk: rand() incorrect results on i386 - returns negative numbers and ignores srand()

[Boyuan Yang]

X-Debbugs-CC: t...@invisible-island.net

在 2024-07-03星期三的 16:28 +0200，Kristian Nielsen写道：
> Package: mawk
> Version: 1.3.4.20240622-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Running mawk produces wrong output from rand() on i386:
> 
>   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
>   0.158578
>   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
>   -0.276944
>   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
>   -0.387807
>   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
>   0.470306
> 
> The result of rand() should never be negative; and it should be
> deterministic after calling srand().
> 
> This occurs on i386 (tested in sbuild --arch=i386 as part of debugging a
> reproducible build problem of package openscad).
> 
> The expected output is the same value between 0 and 1, for example:
> 
>   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
>   0.559536
>   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
>   0.559536
>   $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
>   0.559536
> 
> The longer story, for completeness: I am the maintainer for openscad, and I
> see openscad sometimes failing to build reproducibly on (only) i386 during
> the past year. The root cause seems to be a test script that calls awk and
> behaves unexpectedly due to getting a negative number out of rand().
> 
> The problem does not seem to occur on amd64 or arm64. Openscad doesn't build
> on armhf, so not sure if the problem in mawk is specific to i386 or may be
> specific to 32-bit for example.

Ack. Reproducible on Debian Sid (mawk/1.3.4.20240622), not reproducible on 
Debian 12
Bookworm (mawk/1.3.4.20200120). Likely a regression since 2020.

CC the mawk upstream developer to make them aware of this issue.

Thomas: if you need help in setting up a proper Debian Sid i386 environment to
reproduce the issue and do debugging, feel free to let me know.

Thanks,
Boyuan Yang


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

Bug#1074952: fflas-ffpack: ftbfs with GCC-14

[Torrance, Douglas]

Control: block -1 by 1075001

On Wed 03 Jul 2024 12:26:26 PM GMT, Matthias Klose  wrote:

Package: src:fflas-ffpack
Version: 2.5.0-3
Severity: important
Tags: sid trixie
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-14

[This bug is targeted to the upcoming trixie release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
severity of this report will be raised before the trixie release.

The full build log can be found at:
http://qa-logs.debian.net/2024/07/01/fflas-ffpack_2.5.0-3_unstable_gccexp.log


Here are the relevant lines from the build log:

configure:19320: checking for GIVARO usability
configure:19333: g++ -o conftest  -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
 -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.cpp  -lgivaro -lgmpxx -lgmp  >&5
In file included from /usr/include/givaro/givinteger.h:24,
from conftest.cpp:40:
/usr/include/givaro/random-integer.h: In member function 'Givaro::RandomIntegerIterator<_Unsigned, 
_Exact_Size>& Givaro::RandomIntegerIterator<_Unsigned, _Exact_Size>::operator=(const 
Givaro::RandomIntegerIterator<_Unsigned, _Exact_Size>&)':
/usr/include/givaro/random-integer.h:94:54: error: no match for 'operator=' (operand types are 
'Givaro::RandomIntegerIterator<_Unsigned, _Exact_Size>::Integer_Domain' {aka 
'Givaro::ZRing'} and 'const Givaro::RandomIntegerIterator<_Unsigned, 
_Exact_Size>::Integer_Domain' {aka 'const Givaro::ZRing'})
  94 | const_cast(_ring)=R._ring;
 |  ^


This is givaro bug #1075001, which was just fixed in the recently uploaded 
givaro 4.2.0-5.


signature.asc
Description: PGP signature

Bug#1075718: libvirt-clients: virsh domif-setlink fails to update state

[Cyril Brulebois]

Package: libvirt-clients
Version: 9.0.0-4
Severity: normal

Hi,

Working on some network-oriented tools (https://pts-project.org/), I
ended up wanting to down/up some network links from the virtualization
host (running libvirt, with the QEMU backend). The first step worked
just fine, the second step will surprise you:

virsh # domif-setlink ViRogue --interface 52:54:00:03:73:13 --state down
Device updated successfully

virsh # domif-setlink ViRogue --interface 52:54:00:03:73:13 --state up
error: Failed to update interface link state
error: (device_definition):6: Attribute state redefined
  
---^

The same happens with both 'up' and 'down', with or without --interface
and --state, and really looks like some basic logic bug somewhere in the
XML update code? (I haven't looked at the implementation just yet.)

That used to work fine but I couldn't say for sure which version(s) (as
I've run Debian 9 and Debian 11 previously, but with some backports); at
the time, I used that quite heavily to test bonding on virtualized
images with a lot of interfaces, without any such obvious issues.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


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

Kernel: Linux 6.1.0-22-amd64 (SMP w/20 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

Versions of packages libvirt-clients depends on:
ii  libc6   2.36-9+deb12u7
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2+deb12u3
ii  libgnutls30 3.7.9-2+deb12u3
ii  libreadline88.2-1.3
ii  libvirt09.0.0-4
ii  libxml2 2.9.14+dfsg-1.3~deb12u1
ii  sensible-utils  0.0.17+nmu1

libvirt-clients recommends no packages.

Versions of packages libvirt-clients suggests:
pn  libvirt-clients-qemu  
ii  libvirt-daemon9.0.0-4
pn  libvirt-login-shell   

-- no debconf information

Bug#1075717: mawk: rand() incorrect results on i386 - returns negative numbers and ignores srand()

[Kristian Nielsen]

Package: mawk
Version: 1.3.4.20240622-1
Severity: normal

Dear Maintainer,

Running mawk produces wrong output from rand() on i386:

  $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
  0.158578
  $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
  -0.276944
  $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
  -0.387807
  $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
  0.470306

The result of rand() should never be negative; and it should be
deterministic after calling srand().

This occurs on i386 (tested in sbuild --arch=i386 as part of debugging a
reproducible build problem of package openscad).

The expected output is the same value between 0 and 1, for example:

  $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
  0.559536
  $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
  0.559536
  $ echo | mawk 'BEGIN {srand(10);} {print rand()};'
  0.559536

The longer story, for completeness: I am the maintainer for openscad, and I
see openscad sometimes failing to build reproducibly on (only) i386 during
the past year. The root cause seems to be a test script that calls awk and
behaves unexpectedly due to getting a negative number out of rand().

The problem does not seem to occur on amd64 or arm64. Openscad doesn't build
on armhf, so not sure if the problem in mawk is specific to i386 or may be
specific to 32-bit for example.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages mawk depends on:
ii  libc6  2.38-13

mawk recommends no packages.

mawk suggests no packages.

-- no debconf information

Bug#1075716: ktouch: Unable to type characters under native wayland client

[Bob Wong]

Package: ktouch
Version: 4:22.12.3-1+b1
Severity: important
X-Debbugs-Cc: ybx...@gmail.com

Dear Maintainer,

Upstream fixed the bug in version 23.08 and beyond, so please update the
package so the problem can be solved. Thanks for your help.


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

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.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 ktouch depends on:
ii  ktouch-data  4:22.12.3-1
ii  libc62.38-13
ii  libkf5completion55.115.0-2
ii  libkf5configcore55.115.0-2
ii  libkf5configgui5 5.115.0-2
ii  libkf5configwidgets5 5.115.0-2
ii  libkf5coreaddons55.115.0-2
ii  libkf5i18n5  5.115.1-2+b1
ii  libkf5itemviews5 5.115.0-2
ii  libkf5kcmutils5  5.115.0-3
ii  libkf5textwidgets5   5.115.0-2
ii  libkf5widgetsaddons5 5.115.0-2
ii  libkf5xmlgui55.115.0-2+b1
ii  libqt5core5t64   5.15.13+dfsg-2
ii  libqt5gui5t645.15.13+dfsg-2
ii  libqt5qml5   5.15.13+dfsg-2
ii  libqt5quick5 5.15.13+dfsg-2
ii  libqt5quickcontrols2-5   5.15.13+dfsg-2
ii  libqt5quickwidgets5  5.15.13+dfsg-2
ii  libqt5sql5-sqlite5.15.13+dfsg-2
ii  libqt5sql5t645.15.13+dfsg-2
ii  libqt5widgets5t645.15.13+dfsg-2
ii  libqt5x11extras5 5.15.13-2
ii  libqt5xml5t645.15.13+dfsg-2
ii  libqt5xmlpatterns5   5.15.13-2
ii  libstdc++6   14-20240330-1
ii  libx11-6 2:1.8.7-1+b1
ii  libxcb-xkb1  1.17.0-2
ii  libxcb1  1.17.0-2
ii  qml-module-org-kde-charts4:22.12.3-1+b2
ii  qml-module-org-kde-kcoreaddons   5.115.0-3
ii  qml-module-org-kde-kquickcontrolsaddons  5.115.0-3
ii  qml-module-qtgraphicaleffects5.15.13-2
ii  qml-module-qtquick-controls2 5.15.13+dfsg-2
ii  qml-module-qtquick-layouts   5.15.13+dfsg-2
ii  qml-module-qtquick-window2   5.15.13+dfsg-2
ii  qml-module-qtquick2  5.15.13+dfsg-2

ktouch recommends no packages.

ktouch suggests no packages.

-- no debconf information

Bug#1075601: unar: ftbfs with GCC-14

[Yavor Doganov]

Control: tags -1 + patch

Hi Alex,

Here's a patch fixing this bug.
Description: Fix FTBFS with GCC 14.
Bug-Debian: https://bugs.debian.org/1075601
Author: Yavor Doganov 
Forwarded: no
Last-Update: 2024-07-03
---

--- unar-1.10.8+ds1.orig/XADRAR5Parser.m
+++ unar-1.10.8+ds1/XADRAR5Parser.m
@@ -74,12 +74,6 @@
return 8;
 }
 
-+(BOOL)recognizeFileWithHandle:(CSHandle *)handle firstBytes:(NSData *)data 
name:(NSString *)name
-{
-off_t signatureLocation = [self signatureLocationInData:data];
-return signatureLocation != RAR5SignatureNotFound;
-}
-
 + (off_t)signatureLocationInData:(NSData *)data {
 const uint8_t *bytes=[data bytes];
 int length=[data length];
@@ -98,6 +92,12 @@
 return RAR5SignatureNotFound;
 }
 
++(BOOL)recognizeFileWithHandle:(CSHandle *)handle firstBytes:(NSData *)data 
name:(NSString *)name
+{
+off_t signatureLocation = [self signatureLocationInData:data];
+return signatureLocation != RAR5SignatureNotFound;
+}
+
 +(NSArray *)volumesForHandle:(CSHandle *)handle firstBytes:(NSData *)data 
name:(NSString *)name
 {
 // Check if multipart

Bug#1036820: libsdl2-dev include headers not found by cmake since usr merge

[Nicolas Otton]

Hello,

I was able to reproduce this bug on a debian bookworm installed recently.
I have the same issue, cmake, libsdl2-dev and the other dependencies were
installed through apt, not compiled from source, and CMAKE_CURRENT_LIST_DIR
is set to /lib/x86_64-linux-gnu/cmake/SDL2 so the cmake of the projects
fails.

-- 
Nicolas OTTON

DevOps

Unissey
[image: emailAddress] nicolas.ot...@unissey.com
[image: website] unissey.com
[image: address] 4 rue du Caire, 75002 Paris


-- 
The content of this email is confidential and intended for the recipient 
specified in message only. It is strictly forbidden to share any part of 
this message with any third party, without a written consent of the sender. 
If you received this message by mistake, please reply to this message and 
follow with its deletion, so that we can ensure such a mistake does not 
occur in the future. Thank you for your cooperation and understanding.