Bug#1055279: tox-current-env: potential bugs on armel

[Bo YU]

Hi,
On Tue, Mar 19, 2024 at 01:31:10PM +0200, Faidon Liambotis wrote:

Control: retitle -1 test_allenvs_print_extras tests are flaky

On Fri, Nov 03, 2023 at 08:57:57PM +0800, Bo YU wrote:

I recently uploaded tox/4.14.1-1. tox-current-env autopkgtests fail on
s390x[1] with a similar error, which in turn is currently preventing tox
from migrating into testing[2]


Thanks your detailed analysis for it. I have uploaded -3 to unstable to
hope to unblock tox migrating. But these are some unexpected maybe.


1: https://ci.debian.net/packages/t/tox-current-env/testing/s390x/44050718/
2: https://qa.debian.org/excuses.php?package=tox

This bug was originally for test_allenvs_print_extras_to_file(); for
this I would imagine think the fix is something like:
 - assert prep_tox_output(result.stdout) == expected
 + assert sorted(prep_tox_output(result.stdout)) == sorted(expected)


I have cherry-picked your comment here:
https://salsa.debian.org/python-team/packages/tox-current-env/-/blob/debian/main/debian/patches/sorted-output-on-tests.patch

It seems it works but I was missing another code snipshot which need be
`sorted` also:
https://salsa.debian.org/python-team/packages/tox-current-env/-/blob/debian/main/tests/test_integration_tox4.py#L217
```
@pytest.mark.parametrize("option", ("--print-deps-to", "--print-deps-to-file"))
def test_allenvs_print_deps_to_file(tmp_path, option):
depspath = tmp_path / "deps"
result = tox(option, str(depspath))
assert sorted(depspath.read_text().splitlines()) == sorted(
["tox", "six", "py"] * len(envs_from_tox_ini())
)
expected = ""
for env in envs_from_tox_ini()[:-1]:
expected += f"{env}: OK\n"
expected += tox_footer(spaces=0) + "\n"
assert prep_tox_output(result.stdout) == expected
```

This will lead a autopkgtest on s390x[0] again from its tracker page[1] to
get the link(UTC+8 13:06 2024/03/22).

But another retry on s390x it passed on s390x[2].

[0]: https://ci.debian.net/packages/t/tox-current-env/testing/s390x/44235641/
[1]: https://tracker.debian.org/pkg/tox-current-env
[2]: https://ci.debian.net/packages/t/tox-current-env/

So if many retries on debci page and it passes all autopkgtest, does it
still block your migration? 



The s390x autopkgtest above fails on test_allenvs_print_extras(), which
is very similar. However, that one seems to have a sorted() already:
45s def test_allenvs_print_extras(print_extras_stdout_arg):
45s result = tox(print_extras_stdout_arg)
45s expected = []
45s for env in envs_from_tox_ini():
45s expected.extend(("dev", "full", f"{env}: OK"))
45s expected.pop()  # The last "py310: OK" is not there
45s expected.append(tox_footer(spaces=0))
45s expected = ("\n".join(expected)).splitlines()
45s >   assert sorted(prep_tox_output(result.stdout).splitlines()) == 
sorted(expected)

For safe to unblock anything, I skip this:
https://salsa.debian.org/python-team/packages/tox-current-env/-/blob/debian/main/debian/patches/flaky-test.patch




Do you think I will need to upload it to unstable again with `sorted`
for `test_allenvs_print_deps_to_file` as I analyzed above?

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1067474: gxr-openvr: package Build-Depends on libgxr-0.15-0 whic is no longer built

[Michael Hudson-Doyle]

Package: gxr-openvr
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: michael.hud...@ubuntu.com

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * s/libgxr-0.15-0/libgxr-dev/ in Build-Depends.

Thanks for considering the patch.


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

Kernel: Linux 6.5.0-25-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gxr-openvr-0.15.1/debian/control gxr-openvr-0.15.1/debian/control
--- gxr-openvr-0.15.1/debian/control2024-03-08 18:00:00.0 +1300
+++ gxr-openvr-0.15.1/debian/control2024-03-22 18:20:57.0 +1300
@@ -1,8 +1,7 @@
 Source: gxr-openvr
 Section: contrib/libs
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Andrew Lee (李健秋) 
+Maintainer: Andrew Lee (李健秋) 
 Uploaders: Héctor Orón Martínez 
 Build-Depends:
  debhelper (>= 11),
@@ -12,7 +11,7 @@
  gtk-doc-tools,
  libgtk-3-dev (>= 3.22),
  libgulkan-dev (>= 0.15.0),
- libgxr-0.15-0,
+ libgxr-dev,
  libjson-glib-dev,
  libopenvr-dev,
  mesa-common-dev,

Bug#1066892: inventor: Update to 2.1.6 from GitHub

[Steven Robbins]

On Fri, 15 Mar 2024 01:46:05 +0100 Amr Ibrahim  
wrote:
> Package: inventor
> Severity: normal
> 
> Dear Maintainer,
> 
> The current homepage is dead (Invalid URL), and apparently there is an effort
> to maintain Open Inventor on GitHub:
> https://github.com/aumuell/open-inventor

Thank you for the link!

> 2.1.6:
> * build fixes for modern compilers on Linux and macOS
> * bug fixes, most importantly font rendering on 64 bit Linux
> * CMake as a modern alternative to the existing Makefile build system

Nice improvements.  Out of curiousity: are you using the 2.1.6 sources?  Are 
there important bug fixes for your workflow?

-Steve


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

Bug#1067473: gambas3: ftbfs on time64 arches

[Michael Hudson-Doyle]

Package: gambas3
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: michael.hud...@ubuntu.com

Dear Maintainer,


In Ubuntu, the attached patch was applied to achieve the following:


  * s/libdumb1/libdump1t64/ in Build-Depends.


Thanks for considering the patch.


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

Kernel: Linux 6.5.0-25-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gambas3-3.19.0/debian/control gambas3-3.19.0/debian/control
--- gambas3-3.19.0/debian/control   2024-01-05 12:31:10.0 +1300
+++ gambas3-3.19.0/debian/control   2024-03-22 16:46:35.0 +1300
@@ -17,7 +16,7 @@
libcrypt-dev,
libcurl4-gnutls-dev | libcurl-ssl-dev,
libdbus-1-dev,
-   libdumb1,
+   libdumb1t64,
libffi-dev,
libglew-dev,
libgmime-3.0-dev,

Bug#1067472: firefox-esr: Firefox and Firefox ESR should implement update-alternatives and provide a seperate binary

[Wesley Schwengle]

Package: firefox-esr
Version: 115.9.0esr-2
Severity: wishlist
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I went digging for how firefox works on Debian because I want to make a partial
switch from Google Chrome to firefox. There are some things that could be
improved I think. Mainly by starting to make use of update-alternatives.

I want to start of with by saying this bug is more or less a combination of
bugs #1001724 and #1033594. They both address why I have this wish, for
different reasons.

/usr/bin/firefox is a wrapper script to which looks for $FIREFOX.real, where
$FIREFOX is assuming, firefox. It looks for command firefox, which may be
something else if the user has a wrapper script itself in their PATH and this
than misses its target, #1001724 in short.

The easy way to solve this is IMO a update-alternatives group for firefox like
Google Chrome does (via the Google repo). They have an update-alternatives
group, aptly named `google-chrome', which provides `/usr/bin/google-chrome' and
as a user you can change this to have google-chrome-{unstable,beta,stable} as
your google-chrome. Instead of the wrapper script, firefox-esr should provide
firefox-esr. The firefox package should provide firefox-stable (or similar) and
install itself at a higher level than firefox-esr. This way the firefox binary
"overrides" the ESR. At least, that is my take on it, feel free to swap the
priorities around.

It would be nice if the upstream firefox packages, also adhere to this, eg,
firefox-nightly is already installed as firefox-nightly, but doesn't add an
update-alternatives.

Another reason, besides the wrapper script, is that firefox doesn't really put
profiles in a different path, eg, `~/.config/firefox-nightly',
`~/.config/firefox', etc etc. They however in their compatibility.ini, eg in
`~/.mozilla/firefox/rqowq6li.default-esr/compatibility.ini', you can see a
LastPlatformDIr, which is for the nightly version:

  LastPlatformDir=/usr/lib/firefox-esr

Now, when I run `readlink -m /usr/bin/firefox-nightly' it returns
`/usr/lib/firefox-nightly/firefox'. The LastPlatformDir is the dirname of the
binary. Now, with a propper update-alternative I can also do this on the binary
`/usr/bin/firefox', as this will point to `/etc/alternatives/firefox', which in
turn links to `/usr/bin/firefox-nightly', which is
`/usr/lib/firefox-nightly/firefox'. I can do a little bit of magic with some
shell scripts to startup firefox profiles for different versions.

The wrapper script blocks this from working:

  $ readlink -m /usr/bin/firefox
  /usr/bin/firefox

I hope to see this wish become reality :)


Cheers,
Wesley





-- Package-specific info:

-- Extensions information
Name: Add-ons Search Detection
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox-esr/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: System theme — auto theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled


-- Addons package information
ii  firefox-esr115.9.0esr-2 amd64Mozilla Firefox web browser - 
Extended Support Release (ESR)

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

Kernel: Linux 6.7.7-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, 

Bug#1066292: createrepo-c: FTBFS: xml_file.c:338:36: error: implicit declaration of function ‘rasprintf’; did you mean ‘g_sprintf’? [-Werror=implicit-function-declaration]

[Michael Hudson-Doyle]

Package: createrepo-c
Followup-For: Bug #1066292
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: michael.hud...@ubuntu.com
Control: tags -1 patch

Dear Maintainer,


In Ubuntu, the attached patch was applied to achieve the following:


  * Fix printing time_t and missing prototypes.


Thanks for considering the patch.


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

Kernel: Linux 6.5.0-25-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru createrepo-c-0.17.3/debian/patches/ftbfs.patch 
createrepo-c-0.17.3/debian/patches/ftbfs.patch
--- createrepo-c-0.17.3/debian/patches/ftbfs.patch  1970-01-01 
12:00:00.0 +1200
+++ createrepo-c-0.17.3/debian/patches/ftbfs.patch  2024-03-22 
15:53:53.0 +1300
@@ -0,0 +1,21 @@
+--- a/src/xml_dump_repomd.c
 b/src/xml_dump_repomd.c
+@@ -143,7 +143,7 @@
+BAD_CAST repomd->revision);
+ } else {
+ // Use the current time if no revision was explicitly specified
+-gchar *rev = g_strdup_printf("%ld", time(NULL));
++gchar *rev = g_strdup_printf("%lld", (long long)time(NULL));
+ xmlNewChild(root, NULL, BAD_CAST "revision", BAD_CAST rev);
+ g_free(rev);
+ }
+--- a/src/xml_file.c
 b/src/xml_file.c
+@@ -20,6 +20,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include "xml_file.h"
+ #include 
+ #include "error.h"
diff -Nru createrepo-c-0.17.3/debian/patches/series 
createrepo-c-0.17.3/debian/patches/series
--- createrepo-c-0.17.3/debian/patches/series   2023-01-06 11:16:32.0 
+1300
+++ createrepo-c-0.17.3/debian/patches/series   2024-03-22 15:52:17.0 
+1300
@@ -1,3 +1,4 @@
 python-path.patch
 python-skbuild-path.patch
 python-platlib-debian.patch
+ftbfs.patch

Bug#1066962: wxwidgets3.2: 1 testsuite failed on loong64

[Scott Talbert]

On Sat, 16 Mar 2024 15:21:57 +0800 zhangdandan
 wrote:
> Source: wxwidgets3.2
> Version: 3.2.4+dfsg-3.1
> Severity: serious
> Tags: help
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
> 
> Dear maintainers,
> 
> The following test failed on the loongarch64 architecture, compiled
20 
> hours ago (March 16th).
> ```
> -
--
> URLTestCase
>    GetInputStream
> -
--
> ./uris/url.cpp:37
>
...

> 
> ./uris/url.cpp:89: FAILED:
>    REQUIRE( in_stream )
> with expansion:
>    0
> 
>
===

> test cases: 312 | 311 passed | 1 failed
> assertions: 1230238 | 1230237 passed | 1 failed
> 
> make[1]: *** [debian/rules:89: override_dh_auto_test] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:22: binary-arch] Error 2
> dpkg-buildpackage: error: debian/rules binary-arch subprocess
returned 
> exit status 2
> ```
> The full build log can be found at 
>
https://buildd.debian.org/status/package.php?p=wxwidgets3.2=sid.
> 
> I have reproduced the above testsuite issues on my local loong64
rootfs 
> environment.
> After analyzing, I don't think this error has anything to do with 
> architecture.
> So please focus on this test case failure.
> 
> thanks,
> Dandan Zhang

Hello,

This particular test is supposed to be skipped if the build host
doesn't have network connectivity.  Does the loong64 buildd have
network connectivity (unlike the other buildd's)?

Unfortunately, there doesn't appear to be a loong64 porterbox, so I'm
unable to look into why this is failing.

Regards,
Scott 

Bug#1062963: patch is incomplete

[Matthias Klose]

Control: reopen -1
Control: tags -1 + ftbfs patch

some library names in the symbols file were omitted.
patch attached.
http://launchpadlibrarian.net/720580389/muffin_6.0.1-1build1_6.0.1-1ubuntu1.diff.gz

Bug#1067409: scapy: Tests failures with python3-cryptography >= 42

[Carlos Henrique Lima Melara]

Hey there,

On Thu, 21 Mar 2024 09:45:07 +0100 =?utf-8?b?SsOpcsOpbXkgTGFs?= 
 wrote:
> Hi,
> 
> scapy tests fail against cryptography 42, preventing its migration.
> Fix:
> https://salsa.debian.org/pkg-security-team/scapy/-/merge_requests/3
> 
> Jérémy

I replied in salsa, but I'm also sending here for completeness (and
rastreability).

Even with this patch, autopkgtest is failing (run with sbuild), so I'm
working to get a new snapshot from upstream. That would unblock
python3-cryptography transition.

Cheers,
Charles


signature.asc
Description: PGP signature

Bug#1035321: parsing of 'git log' seems to break when commits are signed

[Anthony Fok]

On Sun, Apr 30, 2023 at 2:18 PM John Scott  wrote:
>
> Package: dh-make-golang
> Version: 0.6.0-2+b5
> Severity: normal
> Control: block 1035318 by -1
>
> It looks like dh-make-golang fails when the commits are signed, and this
> makes me unable to package the rtltcp library:
>
> $ dh-make-golang make -type "library" github.com/bemasher/rtltcp
> 2023/04/30 15:46:18 Starting "dh-make-golang v0.6.0 linux/amd64"
> 2023/04/30 15:46:18 Downloading "github.com/bemasher/rtltcp/..."
> 2023/04/30 15:46:21 Determining upstream version number
> 2023/04/30 15:46:21 Could not create a tarball of the upstream source: get 
> package version from Git: parse last commit date: strconv.ParseInt: parsing 
> "gpg: Signature made Sun 30 Apr 2023 03:27:39 PM EDT\ngpg:
> using RSA key 4AEE18F83AFDEB23\ngpg: Good signature from \"GitHub (web-flow 
> commit signing) \" [marginal]\ngpg: nore...@github.com: 
> Verified 120 signatures in the past 2 years.  Encrypted\n 0 
> messages.\ngpg: Warning: you have yet to encrypt a message to this key!\ngpg: 
> WARNING: This key is not certified with sufficiently trusted 
> signatures!\ngpg:  It is not certain that the signature belongs to 
> the owner.\n  5DE3E0509C47EA3CF04A42D34AEE18F83AFDEB23\n1682882859": 
> invalid syntax
>
> If this is not a trivial fix, if anyone knows of a workaround so I can
> do my packaging, that would be nice.
>
> -- System Information:
> Debian Release: 12.0
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 
> 'unstable-debug'), (2, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, arm64
>
> Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages dh-make-golang depends on:
> ii  git   1:2.39.2-1.1
> ii  git-buildpackage  0.9.30
> ii  golang-any2:1.19~1
> ii  libc6 2.36-8
> ii  pristine-tar  1.50
>
> Versions of packages dh-make-golang recommends:
> ii  golang-golang-x-tools 1:0.5.0+ds-1
> ii  msmtp-mta [mail-transport-agent]  1.8.23-1
>
> dh-make-golang suggests no packages.
>
> -- no debconf information

Hi John,

Thank you for your report, and I apologize for my late reply.

I did some testing, and was initially unable to reproduce the bug you
are seeing until I added "log.showSignature = true" to my global git
config file.
Please try running the command:

git config --show-origin --show-scope --get-all log.showSignature

and see if it outputs anything; for example:

global  file:/home/foka/.gitconfig  true

Such a setting would forcefully show signatures when running "git log",
which dh-make-golang does in "git log --pretty=format:%ct -n1" to get
a timestamp.

It can be fixed in dh-make-golang by adding the --no-show-signature option
to the git log call, which I'll be uploading in 0.7.0-1 in the
not-too-distant future.

Until a fix is uploaded, you may use the following command to remove
the setting from your global git config, i.e. ~/.gitconfig:

git config --global --unset log.showSignature

and you shouldn't see that error again.

Cheers,
Anthony

Bug#1067398: closed by Debian FTP Masters (reply to Timo Röhling ) (Bug#1067398: fixed in numpy 1:1.26.4+ds-6)

[Dima Kogan]

I just pushed mrbuild 1.9 to use the .pc file. Thank you!

Bug#1067468: these tests also fail with openmpi on amd64 and ppc64el

[Samuel Thibault]

Matthias Klose, le ven. 22 mars 2024 01:11:09 +0100, a ecrit:
> these tests also fail with openmpi on amd64 and ppc64el

? I can't reproduce this.

Samuel

Bug#1067468: these tests also fail with openmpi on amd64 and ppc64el

[Matthias Klose]

Control: retitle -1 eztrace fails openmpi tests on arm64, amd64, ppc64el

these tests also fail with openmpi on amd64 and ppc64el

Bug#1067471: RFS: emacs-language-id/0.20-1 [Team] -- Library to work with programming language identifiers

[Xiyue Deng]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "emacs-language-id":

 * Package name : emacs-language-id
   Version  : 0.20-1
   Upstream contact : Lassi Kortela 
 * URL  : https://github.com/lassik/emacs-language-id
 * License  : ISC
 * Vcs  : https://salsa.debian.org/emacsen-team/emacs-language-id
   Section  : editors

The source builds the following binary packages:

  elpa-language-id - Library to work with programming language identifiers

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

  https://mentors.debian.net/package/emacs-language-id/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/emacs-language-id/emacs-language-id_0.20-1.dsc

Changes since the last upload:

 emacs-language-id (0.20-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream release.
   * Drop 0001-Add-Puppet-mode.patch (applied upstream.)
   * Update Standards-Version to 4.6.2 (no change needed.)
   * Drop obsolete emacs version in Recommends.
   * Fix d/watch with special substitue strings.
   * Add d/upstream/metadata.
   * Add Upstream-Contact and add upstream maintainer's email in
 d/copyright

Regards,
-- 
Xiyue Deng

Bug#1067453: gnat: Ada.Calendar.Clock crashes on time_t64 architectures

[Matthias Klose]

Control: forwarded -1 https://gcc.gnu.org/PR114424

Bug#1037139: gst-plugins-bad1.0: Please switch gstreamer1.0-wpe to the new 2.0 WPE API

[Alberto Garcia]

On Tue, Mar 05, 2024 at 12:58:51PM +0100, Alberto Garcia wrote:
> > > gst-plugins-bad1.0 is buildable now. I am ready to do this mini
> > > transition when you are, except that I see wpewebkit is on the
> > > time_t transition list so we should let that transition complete
> > > first.
> > 
> > Yes, let's do that, thanks.
> 
> libwpewebkit-2.0-dev is now in experimental in case you want to give
> it a try. I'll upload it to unstable as soon as I verify that it
> builds in all architectures and the time_t transition is finished.

wpewebkit 2.44.0 has just been released, I confirmed that both
gstreamer1.0-wpe and cog build and work fine with it.

The armel and armhf builds are still missing for a lot of packages,
and it's been a while already. So I wonder if I should go forward and
upload the 2.0 API packages to unstable.

I'm ready to do it so I'll wait for your confirmation.

Berto

Bug#1067390: ITP: golang-github-radovskyb-watcher -- watch for files or directory changes without using filesystem events

[Arthur Diniz]

Thanks for reporting the conflict.

I will rename the source to golang-github-radovskyb-watcher and the
binary to golang-watcher, also adding python3-watcherclient set as a
Conflicts flag in the control file.

Bug#1067390: retitle 1067390 ITP: golang-github-radovskyb-watcher -- watch for files or directory changes without using filesystem events

[Arthur Diniz]

retitle 1067390 ITP: golang-github-radovskyb-watcher -- watch for
files or directory changes without using filesystem events

Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k

[Thorsten Glaser]

Colin Watson dixit:

>Thanks!  No rush - I won't be at a proper computer until Sunday or so
>anyway.

OK sure… no rush is not the reason, the Atari VM I’m using having
only 98 MHz is the one here ;-)

But I already see:

checking if cc supports compile flag -fzero-call-used-regs=used and linking 
succeeds... no

So I guess it should work, but I’ll see tomorrow.

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut)  23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren   -- Michael Prokop über MirOS bsd4grml

Bug#1067470: urlwatch 2.25-1 navigate fails on Debian stable (12.5)

[Justin Piszcz]

Package: urlwatch
Version: 2.25-1

Logged a case on github for this as well:
https://github.com/thp/urlwatch/issues/809

$ urlwatch --edit

name: "Wyze Service Status & Known Issues"
filter:
  - html2text
  - striplines
navigate: 
"https://support.wyze.com/hc/en-us/articles/360015979872-Service-Status-Known-Issues;

$ urlwatch --test-filter 1
Exception while releasing resources for job: 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urlwatch/command.py", line 139,
in test_filter
raise job_state.exception
  File "/usr/lib/python3/dist-packages/urlwatch/handler.py", line 68,
in __enter__
self.job.main_thread_enter()
  File "/usr/lib/python3/dist-packages/urlwatch/jobs.py", line 406, in
main_thread_enter
from .browser import BrowserContext
  File "/usr/lib/python3/dist-packages/urlwatch/browser.py", line 42,
in 
class BrowserLoop(object):
  File "/usr/lib/python3/dist-packages/urlwatch/browser.py", line 49,
in BrowserLoop
@asyncio.coroutine
 ^
AttributeError: module 'asyncio' has no attribute 'coroutine'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urlwatch/handler.py", line 78,
in __exit__
self.job.main_thread_exit()
  File "/usr/lib/python3/dist-packages/urlwatch/jobs.py", line 410, in
main_thread_exit
self.ctx.close()

AttributeError: 'BrowserJob' object has no attribute 'ctx'
Traceback (most recent call last):
  File "/usr/bin/urlwatch", line 33, in 
sys.exit(load_entry_point('urlwatch==2.25', 'console_scripts',
'urlwatch')())
 ^^^
  File "/usr/lib/python3/dist-packages/urlwatch/cli.py", line 112, in main
urlwatch_command.run()
  File "/usr/lib/python3/dist-packages/urlwatch/command.py", line 431, in run
self.handle_actions()
  File "/usr/lib/python3/dist-packages/urlwatch/command.py", line 231,
in handle_actions
sys.exit(self.test_filter(self.urlwatch_config.test_filter))
 ^^
  File "/usr/lib/python3/dist-packages/urlwatch/command.py", line 139,
in test_filter
raise job_state.exception
  File "/usr/lib/python3/dist-packages/urlwatch/handler.py", line 68,
in __enter__
self.job.main_thread_enter()
  File "/usr/lib/python3/dist-packages/urlwatch/jobs.py", line 406, in
main_thread_enter
from .browser import BrowserContext
  File "/usr/lib/python3/dist-packages/urlwatch/browser.py", line 42,
in 
class BrowserLoop(object):
  File "/usr/lib/python3/dist-packages/urlwatch/browser.py", line 49,
in BrowserLoop
@asyncio.coroutine
 ^
AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you
mean: 'coroutines'?

Bug#1067398: python3-numpy: Missing /usr/include/python3.11/numpy link breaks builds

[Dima Kogan]

> Backporting sounds like a reasonable approach. If that does not work
> as expected, I'll restore the symlink.

Excellent. Let me know when this is done, and I'll then update mrbuild
to use it, and the builds will then work again.

I see you just tagged 1:1.26.4+ds-6 in git with the .pc stuff. I'll make
my mrbuild changes now against that, and will push them when you tell me
that you're done and that you have pushed it.

Thanks!

Bug#1067469: script for generating the UI does not work

[Toni]

Package: prometheus-alertmanager
Version: 0.25.0-1+b4
Severity: normal
Tags: upstream patch


Hi,

the included script 'generate-ui.sh' does not work. The attached patch fixes
this, at least to a degree.

Enjoy,
Toni



-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages prometheus-alertmanager depends on:
ii  adduser  3.134
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u4
ii  tzdata   2024a-0+deb12u1

prometheus-alertmanager recommends no packages.

prometheus-alertmanager suggests no packages.

-- no debconf information
--- ./usr/share/prometheus/alertmanager/generate-ui.sh	2023-02-03 03:10:24.0 +
+++ /tmp/generate-ui.sh	2024-03-21 22:43:52.452041965 +
@@ -2,7 +2,7 @@
 
 set -e
 
-ELMDISTURL=https://github.com/elm/compiler/releases/download/0.19.0/binaries-for-linux.tar.gz
+ELMDISTURL=https://github.com/elm/compiler/releases/download/0.19.1/binary-for-linux-64-bit.gz
 SRCDIR=/usr/share/gocode/src/github.com/prometheus/alertmanager/ui/app
 DSTDIR=/usr/share/prometheus/alertmanager/ui
 
@@ -14,7 +14,8 @@
 TMPDIR=$(mktemp -d)
 
 echo "Downloading Elm tools..." >&2
-curl --location $ELMDISTURL | tar xz -C $TMPDIR
+# curl --location $ELMDISTURL | tar xz -C $TMPDIR
+( cd $TMPDIR && curl -L -o - $ELMDISTURL | gzip -d - > elm && chmod 0755 ./elm )
 
 echo "Compiling source code..." >&2
 ln -s $SRCDIR/src $SRCDIR/elm.json $TMPDIR
@@ -31,7 +32,9 @@
 cp $TMPDIR/script.js $DSTDIR
 cp $SRCDIR/index.html $SRCDIR/favicon.ico $DSTDIR
 ln -s /usr/share/fonts-font-awesome $DSTDIR/lib/font-awesome
+ln -s /usr/share/nodejs/bootstrap/dist $DSTDIR/lib/bootstrap
 ln -s /usr/share/nodejs/bootstrap/dist $DSTDIR/lib/bootstrap4
+cp -a /usr/share/gocode/src/github.com/prometheus/alertmanager/ui/app/lib/elm-datepicker $DSTDIR/lib
 
 rm -rf $TMPDIR
 

Bug#1067468: eztrace fails openmpi tests on arm64

[Matthias Klose]

Package: src:eztrace
Version: 2.1-7
Severity: serious
Tags: sid trixie ftbfs

eztrace fails openmpi tests on arm64:

67% tests passed, 2 tests failed out of 6

Total Test time (real) =  22.42 sec

The following tests FAILED:
  2 - mpi_tests (Failed)
  6 - mpi_tests (Failed)
Errors while running CTest
make[2]: *** [Makefile:74: test] Error 8
make[2]: Leaving directory '/<>/build-openmpi'


maybe you could try to run all test suites before failing, if one of the 
test suites fails?

Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k

[Colin Watson]

On Thu, Mar 21, 2024 at 10:35:17PM +, Thorsten Glaser wrote:
> Colin Watson dixit:
> >Could you try the somewhat further reduced patch in
> 
> I’ve started a build and will let you know probably when I get
> back late tomorrow.

Thanks!  No rush - I won't be at a proper computer until Sunday or so
anyway.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1066490: motif: FTBFS: XpmCrBufFrI.c:155:5: error: implicit declaration of function ‘strcpy’ [-Werror=implicit-function-declaration]

[Samuel Thibault]

Hello,

Lucas Nussbaum, le mer. 13 mars 2024 12:53:39 +0100, a ecrit:
> > XpmCrBufFrI.c:155:5: error: implicit declaration of function ‘strcpy’ 
> > [-Werror=implicit-function-declaration]
> >   155 | strcpy(ptr, buf);
> >   | ^~

Given the severity, the importance of the package, the time_t rebuild
issues, and the simplicity of a fix, I have uploaded the attached
changes to DELAYED/0.

Samuel
diff -Nru motif-2.3.8/debian/changelog motif-2.3.8/debian/changelog
--- motif-2.3.8/debian/changelog2020-07-02 11:30:19.0 +0200
+++ motif-2.3.8/debian/changelog2024-03-21 23:42:09.0 +0100
@@ -1,3 +1,10 @@
+motif (2.3.8-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * patches/implicit: Fix build with qa=+bug-implicit-func (Closes: #1066490)
+
+ -- Samuel Thibault   Thu, 21 Mar 2024 23:42:09 +0100
+
 motif (2.3.8-3) unstable; urgency=medium
 
   [ Graham Inggs ]
diff -Nru motif-2.3.8/debian/patches/implicit 
motif-2.3.8/debian/patches/implicit
--- motif-2.3.8/debian/patches/implicit 1970-01-01 01:00:00.0 +0100
+++ motif-2.3.8/debian/patches/implicit 2024-03-21 23:38:08.0 +0100
@@ -0,0 +1,26 @@
+---
+ demos/unsupported/xmform/xmform.c |1 +
+ lib/Xm/XpmI.h |2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+--- a/lib/Xm/XpmI.h
 b/lib/Xm/XpmI.h
+@@ -129,7 +129,7 @@ extern "C" {
+ extern FILE *popen();
+ #endif
+ 
+-#if defined(SYSV) || defined(SVR4) || defined(VMS) || defined(WIN32) || 
defined (_SVID_SOURCE)
++#if defined(SYSV) || defined(SVR4) || defined(VMS) || defined(WIN32) || 
defined (_SVID_SOURCE) || defined (_POSIX_SOURCE)
+ #include 
+ 
+ #ifndef index
+--- a/demos/unsupported/xmform/xmform.c
 b/demos/unsupported/xmform/xmform.c
+@@ -50,6 +50,7 @@ xmform*topShadowColor:   white
+ xmform*bottomShadowColor:black
+ ***---*/
+ 
++#include 
+ #include 
+ #include 
+ #include 
diff -Nru motif-2.3.8/debian/patches/series motif-2.3.8/debian/patches/series
--- motif-2.3.8/debian/patches/series   2020-07-02 10:59:29.0 +0200
+++ motif-2.3.8/debian/patches/series   2024-03-21 23:37:12.0 +0100
@@ -17,3 +17,4 @@
 pass-hardening-flags.patch
 revert-fix-1617.patch
 cross.patch
+implicit

Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k

[Thorsten Glaser]

Colin Watson dixit:

>Could you try the somewhat further reduced patch in

I’ve started a build and will let you know probably when I get
back late tomorrow.

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy

Bug#1067467: eztrace fails tests during the build on almost all architectures

[Samuel Thibault]

Control: block -1 by 1066735

Ok, it's the third one, I'll just add a block instead of merging again.

Samuel

Matthias Klose, le jeu. 21 mars 2024 23:23:21 +0100, a ecrit:
> Package: src:eztrace
> Version: 2.1-7
> Severity: serious
> Tags: sid trixie ftbfs
> 
> eztrace fails tests during the build on almost all architectures, e.g.
> 
> 
> 90% tests passed, 2 tests failed out of 21
> 
> Total Test time (real) =  42.52 sec
> 
> The following tests FAILED:
> 2 - mpi_tests (Failed)
> 9 - mpi_tests (Failed)
> Errors while running CTest
> make[2]: *** [Makefile:74: test] Error 8
> make[2]: Leaving directory '/<>/build-mpich'

Bug#1067467: eztrace fails tests during the build on almost all architectures

[Matthias Klose]

Package: src:eztrace
Version: 2.1-7
Severity: serious
Tags: sid trixie ftbfs

eztrace fails tests during the build on almost all architectures, e.g.


90% tests passed, 2 tests failed out of 21

Total Test time (real) =  42.52 sec

The following tests FAILED:
  2 - mpi_tests (Failed)
  9 - mpi_tests (Failed)
Errors while running CTest
make[2]: *** [Makefile:74: test] Error 8
make[2]: Leaving directory '/<>/build-mpich'

Bug#1067466: black autopkgtest fails because python3-typed-ast no longer in archive

[Olivier Gayot]

Package: black
Version: 24.2.0-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

Since the removal of python3-typed-ast from the archive [1], black
cannot install its test dependencies anymore and therefore fails autopkg tests.

https://tracker.debian.org/news/1469662/python3-typed-ast-removed-from-testing/

The AST library is provided by the Python standard library since Python
3.8 so the dependency has been unused for some time and can be safely
dropped.

In src:black 22.10.0-2, the dependency on python3-typed-ast was dropped
from d/control but not from d/test/control:

https://metadata.ftp-master.debian.org/changelogs//main/b/black/black_24.2.0-1_changelog

In Ubuntu, the attached patch was applied to achieve the following:

  * d/test/control: drop unused dependency on python3-typed-ast, which was
dropped from the archive. (LP: #2058692)


Thanks for considering the patch.


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

Kernel: Linux 6.8.0-11-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 black-24.2.0/debian/tests/control black-24.2.0/debian/tests/control
--- black-24.2.0/debian/tests/control   2024-02-15 10:47:43.0 +0100
+++ black-24.2.0/debian/tests/control   2024-03-21 23:04:40.0 +0100
@@ -9,7 +9,6 @@
  python3-pytest,
  python3-pathspec,
  python3-regex,
- python3-typed-ast,
  python3-aiohttp,
  python3-tomli,
  python3-mypy-extensions,

Bug#1066957: dependency not satisfiable in bookworm-backports

[TM]

Hi Julian,

Thank you for the reply.

The failure I encountered was an unbootable system; see
`/var/log/apt/history.log` below.  In that configuration, the
system reboots at the grub loading screen, instead of proceeding to the
grub menu.

I was able to use Super Grub Disk to log in, downgrade and restore the
missing packages, but I think this behavior qualifies as "critical."

I would appreciate any assistance you can provide forwarding this report to
the correct team.

```
Start-Date: 2024-03-13  12:21:38
Commandline: /usr/sbin/synaptic --hide-main-window --non-interactive
--parent-window-id 56623118 -o Synaptic::closeZvt=true
--set-selections-file /tmp/tmpabiw_6dz
Requested-By: me (1000)
Upgrade: grub-firmware-qemu:amd64 (2.06-13+deb12u1, 2.12-1~bpo12+1),
grub2-common:amd64 (2.06-13+deb12u1, 2.12-1~bpo12+1), grub-common:amd64
(2.06-13+deb12u1, 2.12-1~bpo12+1)
Remove: grub-efi-amd64:amd64 (2.06-13+deb12u1), grub-efi-amd64-bin:amd64
(2.06-13+deb12u1), shim-signed:amd64 (1.39+15.7-1)
End-Date: 2024-03-13  12:21:45
```


On Wed, 20 Mar 2024 12:39:02 +0100 Julian Andres Klode <
julian.kl...@canonical.com> wrote:
> On Fri, Mar 15, 2024 at 08:56:25PM -0400, TM wrote:
> > Package: grub-efi-amd64-bin
> >
> > Version: 2.12-1~bpo12+1
> >
> > Hello,
> >
> > This package seems to require[1] grub-efi-amd64-signed >= 1+2.12, which
is
> > available in testing[2].
> >
> > Please excuse the report if this is expected behavior.  Apt output
follows.
> >
> > Thank you for your time.
> >
>
> We did not upload that backport, and this is normal and expected
> behavior, and it's out of our hands and up to the ftp team to approve
> the signing binaries - it's not a bug.
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en
>
>

Bug#1067465: yosys-plugin-ghdl builds on x86 only, but built on other architectures before

[Matthias Klose]

Package: src:yosys-plugin-ghdl
Version: 0.0~git20230419.5b64ccf-1
Severity: serious
Tags: sid trixie ftbfs

yosys-plugin-ghdl builds on x86 only, but built on other architectures 
before


Caused by

* Use ghdl-mcode instead of ghdl-gcc as it's more portable

but ghdl-mcode is only available on amd64 and i386.  With this choice 
you're making things worse.

Bug#1064171: reopen, package ftbfs on armhf

[Matthias Klose]

Control: reopen -1
Control: tags -1 + ftbfs patch

patch at
http://launchpadlibrarian.net/720527458/mir_2.14.1-4.1build1_2.14.1-4.1ubuntu1.diff.gz

Bug#1067440: Compression makes searching packages very slow

[Julian Andres Klode]

On Thu, Mar 21, 2024 at 09:25:47PM +0100, Julian Andres Klode wrote:
> On Thu, Mar 21, 2024 at 06:01:12PM +0200, Laurențiu Nicola wrote:
> > Package: apt
> > Version: 2.7.12
> > 
> > I noticed that searching for packages is very slow if the package lists are 
> > compressed. To reproduce, remove `/var/lib/apt/lists`, enable
> > 
> > Acquire::GzipIndexes "true"; Acquire::CompressionTypes::Order:: "gz";
> > 
> > , run `apt update`. This enables LZ4 compression on my systems, but I don't 
> > think the exact method matters. You can then run `apt search librust`, 
> > which takes about 19 seconds in a Debian 12 container (docker.io/debian:12 
> > has compression already set up), compared to 0.4 seconds without 
> > compression.
> > 
> > Also tested on Ubuntu 22.04 and 24.04, so the exact APT version shouldn't 
> > matter too much.
> > 
> > I tried to look into it, and `strace -e trace=openat apt-cache search 
> > librust` shows it reopen and re-read one of the package lists:
> > 
> > openat(AT_FDCWD, 
> > "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
> >  O_RDONLY) = 16
> > librust-addr2line+default-dev - Cross-platform symbolication library - 
> > feature "default"
> > openat(AT_FDCWD, 
> > "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
> >  O_RDONLY) = 16
> > librust-addr2line+object-dev - Cross-platform symbolication library - 
> > feature "object"
> > openat(AT_FDCWD, 
> > "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
> >  O_RDONLY) = 16
> > librust-addr2line+rustc-demangle-dev - Cross-platform symbolication library 
> > - feature "rustc-demangle"
> > openat(AT_FDCWD, 
> > "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
> >  O_RDONLY) = 16
> > librust-addr2line+std-dev - Cross-platform symbolication library - feature 
> > "std"
> > 
> > (you can use -e trace=openat,read to confirm that it's actually reading the 
> > file)
> > 
> > I believe it's quadratic in the number of search results, and this is 
> > related to the pseudo-indexing mechanism used by APT (see 
> > `pkgRecords::Lookup` in apt-pkg). Each lookup call will have to decompress 
> > the file in order to seek to the destination.
> > 
> > Unfortunately, I suspect this isn't exactly an easy fix, given the current 
> > design.
> > 
> 
> Going to respond to this but also including responses to your followup email
> which has a broken Subject:
> 
> 
> Searching works by ordering the packages based on file, offset
> and then iterating over them and looking them up. Seeking forward
> to a higher offset does not involve a reopen, we just skip content
> in betwene.
> 
> Full-text search is inside the description in the section parsed
> for each package.
> 
> It's not clear why this fails on bookworm - I can reproduce that -
> t certainly is fine in git main on my Ubuntu 24.04 system.

This should be fixed in

https://salsa.debian.org/apt-team/apt/-/merge_requests/336

What happened was that we got called for the same offset twice, e.g.
let's say 42.

Now our section size is let's say 7.

So what happened is that we did:

- Jump to 42  =>  offset = 42
- Parse   =>  offset = 49
- Jump to 42  => ugh gotta go back

Luckily we still have the currently used section in the Buffer; i.e.
we only looked at bytes 49... but our buffer still starts
at 42, so we can just look back to find our section again.

Sadly we can't avoid the reparse of the section here, because the
pkgTagSection passed to pkgTagFile::Jump() could be a different one
than the last one.

I have a patch to avoid the reparse by storing offset a level higher
where the pkgTagSection is fixed but I'm in favour of not shipping that
- those would only be marginal gains and we want to exercise this code
path.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Dmitry Shachnev]

Control: tags 1066967 +unreproducible

Hi Holger!

On Sat, Mar 16, 2024 at 09:52:54AM +0100, Holger Wansing wrote:
> Package: sphinx-common
> Severity: serious
> 
> Hi,
> 
> dh_sphinxdoc does not work well with read-the-doc theme, apparently.
> Debian policy document has switched to sphinx_rtd_theme recently (see
> https://salsa.debian.org/dbnpolicy/policy/-/commit/686622814018b5a121252b189d99c1968f332b78
>  )
> 
> However, the built document has a completely broken html layout, because
> many files under _static/ are empty (0B size), most noteably 
> _static/css/theme.css.
> 
> If I replace 
>   dh $@ --with sphinxdoc
> by
>   dh $@
> (so do not use dh_sphinxdoc), I get a valid html file with the theme
> in use.

I cannot reproduce this. I downloaded debian-policy source package and built
it in an up-to-date sid chroot. And the built package has this:

  $ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css
  lrwxrwxrwx root/root 0 2024-02-24 15:39 
./usr/share/doc/debian-policy/policy.html/_static/css/theme.css -> 
../../../../../sphinx_rtd_theme/static/css/theme.css

So, it is a symlink, not an empty file. When resolving the relative path,
I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file
exists in sphinx-rtd-theme-common and is non-empty.

The only issue I see is that sphinx-rtd-theme-common is in Recommends of
debian-policy, not in Depends. But that is because ${sphinxdoc:Depends}
was put there.

Am I doing something wrong?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1067457: jose: CVE-2023-50967

[Christoph Biedl]

Control: forwarded 1067457 https://github.com/latchset/jose/issues/151


signature.asc
Description: PGP signature

Bug#1067464: gnutls28: CVE-2024-28834

[Salvatore Bonaccorso]

Source: gnutls28
Version: 3.8.3-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.com/gnutls/gnutls/-/issues/1516
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gnutls28.

CVE-2024-28834[0]:
| A flaw was found in GnuTLS. The Minerva attack is a cryptographic
| vulnerability that exploits deterministic behavior in systems like
| GnuTLS, leading to side-channel leaks. In specific scenarios, such
| as when using the GNUTLS_PRIVKEY_FLAG_REPRODUCIBLE flag, it can
| result in a noticeable step in nonce size from 513 to 512 bits,
| exposing a potential timing side-channel.


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-28834
https://www.cve.org/CVERecord?id=CVE-2024-28834
[1] https://gitlab.com/gnutls/gnutls/-/issues/1516
[2] https://lists.gnupg.org/pipermail/gnutls-help/2024-March/004845.html
[3] https://www.gnutls.org/security-new.html#GNUTLS-SA-2023-12-04

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1067463: gnutls28: CVE-2024-28835

[Salvatore Bonaccorso]

Source: gnutls28
Version: 3.8.3-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.com/gnutls/gnutls/-/issues/1525
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gnutls28.

CVE-2024-28835[0]:
| A flaw has been discovered in GnuTLS where an application crash can
| be induced when attempting to verify a specially crafted .pem bundle
| using the "certtool --verify-chain" command.


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-28835
https://www.cve.org/CVERecord?id=CVE-2024-28835
[1] https://gitlab.com/gnutls/gnutls/-/issues/1525
[2] https://lists.gnupg.org/pipermail/gnutls-help/2024-March/004845.html
[3] https://www.gnutls.org/security-new.html#GNUTLS-SA-2024-01-23

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1067462: ERROR: Failed to create organization

[Tj]

Package: taskd
Version: 1.1.0+dfsg-4+b2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: deb...@iam.tj

Dear Maintainer,

After installation and following the instructions in README.Debian I
found that adding an organisation fails. It is due to two
things:

1. The package fails to create /var/lib/taskd/orgs/

see https://github.com/GothenburgBitFactory/taskserver/issues/82

2. Permissions on /var/lib/taskd/ are incorrect; since taskd uses
Debian-taskd user that user needs write permissions to everything under
/var/lib/taskd/  . Additionally Others should not have access.

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

Kernel: Linux 6.6.7+debian+tj (SMP w/4 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 taskd depends on:
ii  adduser3.134
ii  gnutls-bin 3.7.9-2+deb12u2
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u4
ii  libgcc-s1  12.2.0-14
ii  libgnutls303.7.9-2+deb12u2
ii  libstdc++6 12.2.0-14
ii  libuuid1   2.38.1-5+b1
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4

taskd recommends no packages.

Versions of packages taskd suggests:
pn  taskwarrior  

-- Configuration Files:
/etc/taskd/config changed [not included]

-- no debconf information

Bug#947858: ITP: wshowkeys -- Displays keypresses on screen on supported Wayland compositors

[Antoine Beaupré]

On 2024-03-21 21:47:28, Birger Schacht wrote:
> Hi Antoine,
>
> ah, I think I've forgotten about this, also because `wev` serves a 
> similar usecase, without SUID.
>
> Feel free to upload, I won't have time for this in the next couple of 
> days. Feel free to put it under the swaywm-team umbrella, I can also 
> give you access to the salsa team, if you want to move it there.

I'm happy to move it wherever.

For me, wev doesn't cut it because it doesn't show keystrokes unless you
type them in the wev window, did I miss anything?

A.

-- 
Some believe it is only great power that can hold evil in check, but
that is not what I have found. It is the small everyday deeds of
ordinary folk that keep the darkness at bay. Small acts of kindness and
love.   - J.R.R. Tolkien

Bug#983870: Picking up webdriver-manager packaging

[Joost van Baal-Ilić]

Hi Ananthu!

On Thu, Mar 21, 2024 at 11:38:36PM +0530, Ananthu C V wrote:
> 
> It seems that you are no longer intending to work on this.
> I, on the other hand, require webdriver manager for packaging 
> lightnovel-crawler.
> So if you don't mind, can I pick this up?

Sure, be my guest.  I hope my comments in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983870#12 help you get
started.

Happy hacking!

Bye,

Joost

Bug#947858: ITP: wshowkeys -- Displays keypresses on screen on supported Wayland compositors

[Birger Schacht]

Hi Antoine,

ah, I think I've forgotten about this, also because `wev` serves a 
similar usecase, without SUID.


Feel free to upload, I won't have time for this in the next couple of 
days. Feel free to put it under the swaywm-team umbrella, I can also 
give you access to the salsa team, if you want to move it there.


cheers,
Birger

Bug#1067461: libvirt: CVE-2024-2494

[Salvatore Bonaccorso]

Source: libvirt
Version: 10.1.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libvirt.

CVE-2024-2494[0]:
| A flaw was found in the RPC library APIs of libvirt. The RPC server
| deserialization code allocates memory for arrays before the non-
| negative length check is performed by the C API entry points.
| Passing a negative length to the g_new0 function results in a crash
| due to the negative length being treated as a huge positive number.
| This flaw allows a local, unprivileged user to perform a denial of
| service attack by causing the libvirt daemon to crash.


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-2494
https://www.cve.org/CVERecord?id=CVE-2024-2494
[1] 
https://gitlab.com/libvirt/libvirt/-/commit/8a3f8d957507c1f8223fdcf25a3ff885b15557f2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1067460: entropybroker: please fix libpng-dev build dependency

[Gianfranco Costamagna]

Package: entropybroker
Version: 2.9-7
Severity: serious
Tags: patch

Dear Maintainer,

  * Update dependency to libpng-dev


Thanks for considering the patch.

diff -Nru entropybroker-2.9/debian/control entropybroker-2.9/debian/control
--- entropybroker-2.9/debian/control2022-07-31 22:25:00.0 +0200
+++ entropybroker-2.9/debian/control2024-03-21 21:41:18.0 +0100
@@ -7,7 +7,7 @@
 , libgd-dev
, libasound2-dev
, libusb-1.0-0-dev
-   , libpng16-16
+   , libpng-dev
, zlib1g-dev
, libpcsclite-dev
, libftdi-dev


G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067459: connectgram: Please update or drop qt6 dependencies

[Gianfranco Costamagna]

Package: connectagram
Version: 1.3.5-1
Severity: serious

Dear Maintainer,


Looks like you are adding some runtime dependencies as build-dependencies

Thanks for considering the patch.

--- connectagram-1.3.5/debian/control   2024-03-12 02:50:36.0 +0100
+++ connectagram-1.3.5/debian/control   2024-03-21 21:36:00.0 +0100
@@ -10,9 +9,6 @@
   qt6-l10n-tools,
   qt6-tools-dev-tools,
   qt6-base-dev-tools,
-  libqt6widgets6,
-  libqt6gui6,
-  libqt6core6,
   mesa-common-dev,
   debhelper-compat (= 13)
 Standards-Version: 4.6.2


G.

Bug#1067458: pulseaudio: FTBFS cpu-volume-test fails

[Jeremy Bícha]

Source: orc
Severity: serious
Version: 1:0.4.38-1
Forwarded: https://gitlab.freedesktop.org/gstreamer/orc/-/issues/66
X-Debbugs-CC: pulseau...@packages.debian.org
User: debian-...@lists.debian.org
Usertags: time-t
Control: affects -1 src:pulseaudio
Control: block 1036884 by -1

pulseaudio fails to build from source on a few architectures but it
built successfully recently. The build log suggests that the new
version of orc might have triggered this regression in pulseaudio's
build tests so I filed an upstream bug and am reporting this Debian
bug against orc.

Here's an excerpt from the build log.

test: cpu-volume-test
start time:   20:02:32
duration: 2.06s
result:   exit status 1
command:  src/tests/cpu-volume-test
--- stdout ---
Running suite(s): CPU
66%: Checks: 3, Failures: 0, Errors: 1
../src/tests/cpu-volume-test.c:188:E:svolume:svolume_orc_test:0:
(after this point) Received signal 11 (Segmentation fault)

https://buildd.debian.org/status/package.php?p=pulseaudio

Thank you,
Jeremy Bícha

Bug#1032670: allegro4.4: CVE-2021-36489

[Andreas Rönnquist]

On Fri, 10 Mar 2023 18:04:23 +0100 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= 
 wrote:
> Source: allegro4.4
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for allegro4.4.
> 
> CVE-2021-36489[0]:
> | Buffer Overflow vulnerability in Allegro through 5.2.6 allows
> | attackers to cause a denial of service via crafted PCX/TGA/BMP files
> | to allegro_image addon.
> 
> https://github.com/liballeg/allegro5/issues/1251
> https://github.com/liballeg/allegro5/pull/1253
> 
> These fixes landed in Allegro 5.2.8.0:
> https://github.com/liballeg/allegro5/commit/3f2dbd494241774d33aaf83910fd05b2a590604a
>  (5.2.8.0)
> https://github.com/liballeg/allegro5/commit/cca179bc16827f358153060cd10ac73d394e758c
>  (5.2.8.0)
> https://github.com/liballeg/allegro5/commit/a2c93939f6997a96ecac1865dbb4fa3f66b5e1b7
>  (5.2.8.0)
> https://github.com/liballeg/allegro5/commit/0294e28e6135292eab4b2916a7d2223b1bb6843e
>  (5.2.8.0)
> 
> In allegro 4.4, code is in src/[pcx|tga].c instead
> 

Hey

I just tried to reproduce this now on the version of Allegro 4.4 in
Debian, and using the crash file as mentioned in
https://github.com/liballeg/allegro5/issues/1251

I cannot reproduce the crash on 4.4.

Can you still reproduce the crash on allegro4.4 from the debian package?

For me when running './ex_bitmap crash' I get a dialog "Error reading
bitmap file 'crash'", but no crash of the program

best
/Andreas
gus...@debian.org

Bug#1064003: Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Helmut Grohne]

Hi Bastian and Matthias,

I was recently working on gcc builds and this disagreement currently
makes stuff unbuildable. Hence I looked into solutions and/or
workarounds.

On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> > You just said that the search path used during the build of the
> > toolchain and the one for everything else are unrelated.  So you are
> > free to create $BUILD/tmp-include with symlinks for asm, asm-generic,
> > linux.
> > 
> > The toolchain as installed already finds all headers.  So I still don't
> > see why we need this in the final system.
> 
> I find this argument fairly convincing and hope Matthias also does.

As a result, I implemented the proposed change and am attaching it for
discussion here. I've implemented it in a way that if there is a sysroot
linux header installation, it'll be preferred. Do you see any downsides
of this approach?

Helmut
linux-libc-dev now provides linux-libc-dev-$arch-cross without actually
providing /usr//include. Thus we symlink it to where we need it.

See also #1064003.

diff --git a/debian/rules2 b/debian/rules2
index 651d14af..6a486ffe 100644
--- a/debian/rules2
+++ b/debian/rules2
@@ -1266,6 +1266,13 @@ endif
 	  ln -sf /usr/include/$(DEB_HOST_MULTIARCH)/crypt.h \
 	$(builddir)/sys-include/crypt.h; \
 	fi
+	: # Import headers from Multi-Arch:foreign linux-libc-dev
+	set -e; for d in asm-generic linux; do \
+	  if [ -d "/usr/include/$$d" ] && ! [ -d "/usr/$(DEB_TARGET_GNU_TYPE)/include/$$d" ]; then \
+	mkdir -p '$(builddir)/sys-include'; \
+	ln -sf "/usr/include/$$d" "$(builddir)/sys-include/$$d"; \
+	  fi; \
+	done
 
 	touch $(configure_stamp)
 

Bug#1067440: Compression makes searching packages very slow

[Julian Andres Klode]

On Thu, Mar 21, 2024 at 06:01:12PM +0200, Laurențiu Nicola wrote:
> Package: apt
> Version: 2.7.12
> 
> I noticed that searching for packages is very slow if the package lists are 
> compressed. To reproduce, remove `/var/lib/apt/lists`, enable
> 
> Acquire::GzipIndexes "true"; Acquire::CompressionTypes::Order:: "gz";
> 
> , run `apt update`. This enables LZ4 compression on my systems, but I don't 
> think the exact method matters. You can then run `apt search librust`, which 
> takes about 19 seconds in a Debian 12 container (docker.io/debian:12 has 
> compression already set up), compared to 0.4 seconds without compression.
> 
> Also tested on Ubuntu 22.04 and 24.04, so the exact APT version shouldn't 
> matter too much.
> 
> I tried to look into it, and `strace -e trace=openat apt-cache search 
> librust` shows it reopen and re-read one of the package lists:
> 
> openat(AT_FDCWD, 
> "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
>  O_RDONLY) = 16
> librust-addr2line+default-dev - Cross-platform symbolication library - 
> feature "default"
> openat(AT_FDCWD, 
> "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
>  O_RDONLY) = 16
> librust-addr2line+object-dev - Cross-platform symbolication library - feature 
> "object"
> openat(AT_FDCWD, 
> "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
>  O_RDONLY) = 16
> librust-addr2line+rustc-demangle-dev - Cross-platform symbolication library - 
> feature "rustc-demangle"
> openat(AT_FDCWD, 
> "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
>  O_RDONLY) = 16
> librust-addr2line+std-dev - Cross-platform symbolication library - feature 
> "std"
> 
> (you can use -e trace=openat,read to confirm that it's actually reading the 
> file)
> 
> I believe it's quadratic in the number of search results, and this is related 
> to the pseudo-indexing mechanism used by APT (see `pkgRecords::Lookup` in 
> apt-pkg). Each lookup call will have to decompress the file in order to seek 
> to the destination.
> 
> Unfortunately, I suspect this isn't exactly an easy fix, given the current 
> design.
> 

Going to respond to this but also including responses to your followup email
which has a broken Subject:


Searching works by ordering the packages based on file, offset
and then iterating over them and looking them up. Seeking forward
to a higher offset does not involve a reopen, we just skip content
in betwene.

Full-text search is inside the description in the section parsed
for each package.

It's not clear why this fails on bookworm - I can reproduce that -
t certainly is fine in git main on my Ubuntu 24.04 system.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1067398: python3-numpy: Missing /usr/include/python3.11/numpy link breaks builds

[Timo Röhling]

Hi Dima,

* Dima Kogan  [2024-03-21 07:23]:
My feeling is that being confused by that symlink is a bug, but I 
didn't read #998084 in great detail, so maybe I'm missing some 
nuance. So let's make this work.
My understanding is that /usr/include/pythonX.Y as Python header 
directory will be made available from inside a venv if you use the 
system interpreter (which venv does by default). Now, the system 
NumPy headers will leak into the venv, regardless of the NumPy 
package that is actually installed there, causing conflicts.


Proposal: if pkg-config files will be added in the near future, can 
we wait until those are available before removing the symlink? Or, 
can you backport them into the current package?
Backporting sounds like a reasonable approach. If that does not work 
as expected, I'll restore the symlink.


But if something was confused by the symlink, would it also be 
confused by the .pc file?
Very good question. I suspect the answer is yes, but there is a pull 
request that would make it work as expected [1].


[1] https://github.com/pypa/virtualenv/issues/2637

Currently the Makefile launches Python and imports sysconfig, which 
is relatively fast. As we can see, importing numpy also, is MUCH 
slower. All I want is the include path; I shouldn't need to 
initialize all of numpy to do that.

I understand and I would not want to do that either.


Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#1051098: suggestion: dh-builtusing may simplify the packaging

[Vagrant Cascadian]

Control: tags 1051098 +patch

On 2024-03-21, Nicolas Boulenguez wrote:
>> Also filed a bug on dh-builtusing about this:
>> 
>>   https://bugs.debian.org/1067242
>> 
>> I look forward to an improved dh-builtusing and patch for u-boot! :)
>
> Thanks for reporting.
>
> Dh-builtusing/0.0.6 adds a regression test reporting this bug, and
> fixes it.
>
> Variables disabled by a restriction now receive a dummy but valid
> value, so that dpkg-gencontrol can parse the expansion (then ignore
> the dummy value).

Tested and seems to work!


> For u-boot, no patch is necessary.  Just revert the reversal :-)

Re-added the patch tag, although strictly speaking it should now have a
versioned dependency... :)

Will probably wait till u-boot migrates to testing to re-apply the
patch... but will do so eventually.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1067147: dcmtk: diff for NMU version 3.6.7-9.2

[Aurelien Jarno]

Hi,

On 2024-03-19 11:54, Emanuele Rocca wrote:
> Package: dcmtk
> Version: 3.6.7-9.1
> Severity: normal
> Tags: patch  pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for dcmtk (versioned as 3.6.7-9.2) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
> 
>   Emanuele

> diff -Nru dcmtk-3.6.7/debian/changelog dcmtk-3.6.7/debian/changelog
> --- dcmtk-3.6.7/debian/changelog  2024-02-28 02:17:02.0 +0100
> +++ dcmtk-3.6.7/debian/changelog  2024-03-19 11:08:29.0 +0100
> @@ -1,3 +1,13 @@
> +dcmtk (3.6.7-9.2) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Build without stack-clash-protection on armel. See #1060104.
> +  * Do not build-depend on graphviz on armhf and armel. The package is
> +currently not installable on those arches due to the ongoing t64
> +transition.
> +
> + -- Emanuele Rocca   Tue, 19 Mar 2024 11:08:29 +0100
> +
>  dcmtk (3.6.7-9.1) unstable; urgency=medium
>  
>* Non-maintainer upload.
> diff -Nru dcmtk-3.6.7/debian/control dcmtk-3.6.7/debian/control
> --- dcmtk-3.6.7/debian/control2024-02-28 02:17:02.0 +0100
> +++ dcmtk-3.6.7/debian/control2024-03-19 11:08:29.0 +0100
> @@ -16,7 +16,7 @@
> libxml2-dev,
> zlib1g-dev
>  Build-Depends-Indep: doxygen,
> - graphviz
> + graphviz [!armhf !armel]

This does not look correct. Build-Depends-Indep are only used to build
the arch:all packages, and currently all the arch:all autobuilder run on
amd64. Therefore it looks to me that this change is not necessary to
help the armel/armhf rebootstrap done as part of the time_t transition.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1067431: brutespray: Update the package to version > 2

[Carlos Henrique Lima Melara]

Hi, Sophie.

On Thu, Mar 21, 2024 at 03:47:36PM +0100, Sophie Brun wrote:
> Upstream has released new versions of brutespray. They have rewritten the
> tool in Golang.

I saw it and started to track which dependencies were necessary to go
through the NEW queue [1], but the upstream was releasing a new version
every day so I was just waiting a bit for things to cool down before
trying to package everything.

> They asked me to update it in Kali [1].
> 
> I have updated the package for Kali [2]. I chose to embed 9 Golang
> dependencies in debian/vendor as the packages don't exist in Debian. But I
> don't think it is acceptable for a Debian package, or at least the
> debian/copyright needs to be fixed.

Yeah, I think we have to package the go dependencies aside from
brutespray :-( Though I was wondering if we should keep them under the
umbrella of the security team or the go team (I tend to keep under the
go team, what do you think?).

> It would be great if you could update the package in Debian.

Now that it seems to have slowed down the releases, I'll check what you
have done in kali and start to package the go dependencies. If you'd
like to help, just let me know :-)

Question: do you know if the v2 has feature/api compatibility with the
python one?

> Thanks.
> 
> Sophie

Cheers,
Charles

[1] https://salsa.debian.org/debian-brasilia-team/docs/-/issues/157


signature.asc
Description: PGP signature

Bug#1066110: tracker-extract: regular crash

[Patrice Duroux]

So did a forcemerge 1066898 1066110 be a better way to proceed?

Le jeu. 21 mars 2024 à 10:40, Alban Browaeys
 a écrit :
>
> On Thu, 14 Mar 2024 22:04:33 +0100 intrigeri 
> wrote:
> > Hi,
> >
> > I see a similar crash every 2-4 seconds on my sid system since some
> recent
> > upgrade.
> >
> > This looks like
> > https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/312.
> >
>
>
> Looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066898
>
> > I lack time to do this myself but it could be interesting to check if
> > the upstream fix resolves this for you:
> >
> https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/516/diffs
> > … which I understand will be included in 3.7 stable.
> >
>
>
> Should be fixed by 3.7.0-1 which is available in unstable since a day.
> Could you upgrade and clos this bug report if fixed?
>
> Regards,
> Alban

Bug#1066754: sentry-python: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Gregor Riepl]

Hi,

I believe this issue can be addressed by my proposed fix for #1063986:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063986#12

Regards,
Gregor

Bug#1066314: regina-rexx: FTBFS: ./rexxext.c:95:7: error: implicit declaration of function ‘getcallstack’; did you mean ‘popcallstack’? [-Werror=implicit-function-declaration]

[Agustin Martin]

Control: tags -1 +pending

El dom, 17 mar 2024 a las 21:41, Agustin Martin
() escribió:
>
> El vie, 15 mar 2024 a las 18:57, Agustin Martin
> () escribió:
> >
> > Hi, Lucas and Alen.
> >
> > While it is easy to fix this particular error (see attached patch,
> > from upstream repo), other similar error happens afterwards in my
> > tests. The problem is that this package is way behind upstream and I
> > think priority is to upgrade to a recent upstream version and then fix
> > whatever is left.
>
> Hi, Alen,
>
> Some time ago I played a bit with upgrading regina-rexx to a recent
> upstream version. I think I can find that stuff and try again with
> last upstream version. In case of success, I would like to push
> changes to regina-rexx salsa repo for further inspection. Let me know
> your POV.

Hi, Lucas and Alen

I have been working on upgrading upstream version from 3.6 to 3.9.5.
There have been a lot of upstream changes between both versions and I
have tried to quickly look at them in case I find something I do not
like. It was a quick look, so something may have gone unnoticed,
better if maintainer can look better at it. I have upgraded all the
Debian stuff to work with that new version, added some other changes I
found interesting, and verified that everything builds in a recent
pbuilder sid box, so I think package as I have it fixes this problem,
thus the "pending" tag.

I have committed everything to
https://salsa.debian.org/debian/regina-rexx.git, including upstream
and pristine-tar branches. I will leave some time for inspection and,
if no one else uploads before and there are no objections, will upload
NMU myself. In the meantime I would like to look at [#1027405:
regina-rexx FTCBFS: builds for the build architecture] and see how to
adjust supplied patch and deal with this problem. Note that
regina-rexx package is marked for autoremoval from testing on 26
April.

Regards,

-- 
Agustin

Bug#1067456: erlang-jose: CVE-2023-50966

[Moritz Mühlenhoff]

Source: erlang-jose
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for erlang-jose.

CVE-2023-50966[0]:
| erlang-jose (aka JOSE for Erlang and Elixir) through 1.11.6 allow
| attackers to cause a denial of service (CPU consumption) via a large
| p2c (aka PBES2 Count) value in a JOSE header.

https://github.com/potatosalad/erlang-jose/issues/156
https://github.com/P3ngu1nW/CVE_Request/blob/main/erlang-jose.md

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-2023-50966
https://www.cve.org/CVERecord?id=CVE-2023-50966

Please adjust the affected versions in the BTS as needed.

Bug#1067457: jose: CVE-2023-50967

[Moritz Mühlenhoff]

Source: jose
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for jose.

CVE-2023-50967[0]:
| latchset jose through version 11 allows attackers to cause a denial
| of service (CPU consumption) via a large p2c (aka PBES2 Count)
| value.

This doesn't appear to have been forwarded upstream yet:
https://github.com/P3ngu1nW/CVE_Request/blob/main/latch-jose.md

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-2023-50967
https://www.cve.org/CVERecord?id=CVE-2023-50967

Please adjust the affected versions in the BTS as needed.

Bug#1063986: sentry-python: autopkgtest regression with pytest 8

[Gregor Riepl]

Hi,

I think this issue can be fixed by pulling in the latest sentry-sdk 
version (1.43 at this point) and applying the following patch:



diff --git a/debian/rules b/debian/rules
index 206ab22..27d6911 100755
--- a/debian/rules
+++ b/debian/rules
@@ -43,6 +43,7 @@ PYBUILD_TEST_ARGS_PYTEST7_IGNORE=\
and not test_circular_references \
and not test_has_tracestate_enabled \
and not test_default_release \
+   and not test_uwsgi_warnings \

 export PYBUILD_NAME=sentry_sdk
 # Disable tests failing mostly because of internet access (httpbin.org)


The test "test_uwsgi_warnings" is flaky and doesn't clean up properly 
after itself, which leads to an error further down the line.


Please release a new version as soon as possible.
Thank you very much.

Regards,
Gregor

Bug#1067455: libgphoto2: please reduce build-dependencies by moving things to Build-Depends-Indep

[Simon McVittie]

Source: libgphoto2
Version: 2.5.31-2.1
Severity: wishlist
Tags: patch

I noticed that libgphoto2 was blocking some of the rebuilds that are needed
for the 64-bit time_t transition, and was itself not buildable because it
was waiting for graphviz. This has now been resolved, but if libgphoto2 had
fewer build-dependencies, then it could have been built sooner.

Please consider applying the attached patches, also available as
.

I have confirmed (using diffoscope) that building with -Pnodoc,nocheck
skips installation of various build-dependencies, and skips production
of the -dev-doc package, but does not otherwise affect the package's
contents.

Thanks,
smcv
>From 21d265c1b839fcfa0933ddb963788b7f5f9662f1 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Mar 2024 17:29:31 +
Subject: [PATCH 1/3] d/control: Only require graphviz for Architecture: all
 builds

This reduces the length of dependency chains for bootstrapping or
re-bootstrapping architectures, for example during the 64-bit time_t
transition.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 5847c3c3e..fe7539ff4 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,6 @@ Maintainer: Debian PhotoTools Maintainers ,
 Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
-   graphviz,
libcurl4-openssl-dev,
libexif-dev,
libgd-dev,
@@ -20,6 +19,7 @@ Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
zlib1g-dev
 Build-Depends-Indep:
  doxygen,
+ graphviz,
 Build-Conflicts: liblockdev1-dev
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
-- 
2.43.0

>From c1605a2af5e0f048fafc6fee788506db4633e6ba Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Mar 2024 17:30:05 +
Subject: [PATCH 2/3] d/control, d/rules: Only run rdfind and symlinks if we
 built documentation

---
 debian/control | 4 ++--
 debian/rules   | 4 
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index fe7539ff4..652ed43a5 100644
--- a/debian/control
+++ b/debian/control
@@ -14,12 +14,12 @@ Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
libusb-1.0-0-dev,
libxml2-dev,
pkg-config,
-   rdfind,
-   symlinks,
zlib1g-dev
 Build-Depends-Indep:
  doxygen,
  graphviz,
+ rdfind,
+ symlinks,
 Build-Conflicts: liblockdev1-dev
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
diff --git a/debian/rules b/debian/rules
index b3fcf7ce8..b3c9ee7f0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,8 @@ DOC_IMG=$(CURDIR)/debian/libgphoto2-dev-doc/usr/share/doc/libgphoto2-6t64/libgph
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+built_binaries := $(shell dh_listpackages)
+
 ### soname version - libgphoto2-major:
 major=6t64
 
@@ -27,9 +29,11 @@ override_dh_install:
 		mkdir -p debian/libgphoto2-port12t64/lib/udev && \
 		mv debian/tmp/usr/lib/udev/check-mtp-device \
 			debian/libgphoto2-port12t64/lib/udev/check-mtp-device
+ifneq ($(filter %-doc,$(built_binaries)),)
 	# Using rdfind and symlinks to transform duplicated files in softlinks
 	rdfind -makesymlinks true -makeresultsfile false $(DOC_IMG)
 	symlinks -cr $(DOC_IMG)
+endif
 
 ifeq ($(DEB_HOST_ARCH_OS),linux)
 override_dh_installudev:
-- 
2.43.0

>From 4e750496fdbfb0fa64bc2d92b52bf6b3a5dad14b Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Mar 2024 17:31:05 +
Subject: [PATCH 3/3] d/control: Don't build -dev-doc package under nodoc
 build-profile

This allows the -l10n package to be built without also needing to build
developer documentation.
---
 debian/control | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index 652ed43a5..268997c39 100644
--- a/debian/control
+++ b/debian/control
@@ -16,10 +16,10 @@ Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
pkg-config,
zlib1g-dev
 Build-Depends-Indep:
- doxygen,
- graphviz,
- rdfind,
- symlinks,
+ doxygen ,
+ graphviz ,
+ rdfind ,
+ symlinks ,
 Build-Conflicts: liblockdev1-dev
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
@@ -45,6 +45,7 @@ Description: gphoto2 digital camera library (development files)
  This package contains the development files.
 
 Package: libgphoto2-dev-doc
+Build-Profiles: 
 Section: doc
 Architecture: all
 Multi-Arch: foreign
-- 
2.43.0

Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

Control: reassign -1 tech-ctte
Control: severity -1 normal

Hi

I don't see any way to solve this issue right now.  Please decide this
matter according to 6.1 nr 2 Debian Constitution.

Background:  linux-libc-dev provides the Linux API for consumption by
all userspace stuff.

This package was arch-any for as long as I remember and provided only
the headers for this single architecture.  Since a short while this
package is now arch-all and provides headers for all known Debian
architectures in one swoop.  This change was done when the Ubuntu
maintainers asked if we wanted to follow.

This now means that new architectures will need to get added to
linux-libc-dev first and it is not longer required to push hand crafted
packages somewhere in the ports archive.

However the package now contains everything that is also contained in
the uncoordinated linux-libc-dev-*-cross packages.  The only difference
is the physical location of the files (/usr/include instead of the
policy violating /usr/*/include).  This API proofed to be compatible
with all tested packages available in the archive.

Because of this (from my side unnecessary) code duplication, I opened
the plan to replace linux-libc-dev-*-cross, see #1059786.  Two months
later the following bug report comes in:

On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't
> do that completely
> 
> Provides: linux-libc-dev-amd64-cross (= 6.7.7-1), ...
> 
> However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.
> 
> Please stop providing the cross-packages, you don't even need a breaks,
> because the current cross packages continue to work.
> 
> Once that is done, I'll reduce the cross packages to some symlinks.

Even after several e-mails, the OP was unable or unwilling to show where
the problem actually lies.

Please decide who is going to provide linux-libc-dev and all the
associated cross stuff and how it should look like.

Regards,
Bastian

-- 
Vulcans never bluff.
-- Spock, "The Doomsday Machine", stardate 4202.1

Bug#983870: Picking up webdriver-manager packaging

[Ananthu C V]

Hi Joost,

It seems that you are no longer intending to work on this.
I, on the other hand, require webdriver manager for packaging 
lightnovel-crawler.
So if you don't mind, can I pick this up?

Best,
Ananthu

Bug#1067454: presentty: bad domain in Homepage and d/copyright

[Jakub Wilk]

Source: presentty
Version: 0.2.1-1.1

The Homepage field in debian/control and the Source field 
debian/copyright point to , but 
there's no such domain. According to README.rst, it should be 
s/org/com/.


--
Jakub Wilk

Bug#1051098: suggestion: dh-builtusing may simplify the packaging

[Nicolas Boulenguez]

Hello.

> About to upload a version reverting this change to fix build failure on
> armhf.
> 
> Removing the patch flag, as the patch does not quite work correctly.
> 
> Also filed a bug on dh-builtusing about this:
> 
>   https://bugs.debian.org/1067242
> 
> I look forward to an improved dh-builtusing and patch for u-boot! :)

Thanks for reporting.

Dh-builtusing/0.0.6 adds a regression test reporting this bug, and
fixes it.

Variables disabled by a restriction now receive a dummy but valid
value, so that dpkg-gencontrol can parse the expansion (then ignore
the dummy value).

For u-boot, no patch is necessary.  Just revert the reversal :-)

Bug#1067453: gnat: Ada.Calendar.Clock crashes on time_t64 architectures

[Nicolas Boulenguez]

Package: gnat-13
Version: 13.2.0-19
Severity: normal
X-Debbugs-Cc: lbre...@debian.org
Control: affects -1 pcscada libalog dbusada anet ahven libgmpada libgtkada 
libgnatcoll-db libncursesada libaunit adacgi liblog4ada libtexttools 
libtemplates-parser libxmlezout libgnatcoll-bindings libgnatcoll gprbuild

Hello.

Most Ada packages randomly FTBFS on 32 bit architectures with
gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed

The problem originates in the gcc-13 switch to time_t64.
gcc/ada/libgnat/s-os_prim__posix.adb is affected by two apparently
distinct issues.

* s-os_prim.adb allocates 3Long_Integer=3void*=3*32 bits for the
  timeval C struct, while 2*64bits = 2Long_Long_Integer are now needed.

  This issue affects other files, but is easy to find and fix.

* The switch breaks the call from Ada to the C gettimeofday function.

  Can anyone explain this, and ideally provide a real fix instead of
  the ugly work-around below?

cat > mycal.c <
int mygettimeofday(struct timeval *restrict tv,
   struct timezone *restrict tz) {
  return gettimeofday(tv, tz);
}
EOF

cat > foo.adb <

Bug#1067410: golang-github-go-jose-go-jose-dev: ftbfs on i386 and mips64el due to timeout of test case

[Nilesh Patra]

> The 4.0.1-2 still has timeout on test issue, see:
> https://buildd.debian.org/status/logs.php?pkg=golang-github-go-jose-go-jose=i386
>
> https://buildd.debian.org/status/logs.php?pkg=golang-github-go-jose-go-jose=mips64el
>
> So open this to trace it again.
> ...
> golang-github-go-jose-go-jose (4.0.1-3) unstable; urgency=medium
> .
>   * Skip one test on some architectures accurately. (Closes: #1067410)

You could instead increase the timeout too with:

override_dh_auto_test:
dh_auto_test -- -timeout=1h

Unless the tests run on those archs forever.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1067444: FileNotFoundError: [Errno 2] ... /usr/lib/python3/dist-packages/bugwarrior/docs/configuration.rst

[Jochen Sprickerhof]

Hi Tj,

* Tj  [2024-03-21 16:08]:

Severity: grave
Justification: renders package unusable


I disagree here. Any reason why you did it?


With a fresh install and manually creating the user's configuration file
I hit this error. The path reported seems to indicate the package is not
shipping the file mentioned. I tried moving the user config directory and
saw the error caused by it being missing, put it back, and hit this package
config file issue agian.

$ bugwarrior-pull
CRITICAL:bugwarrior.command:Could not load configuration. Maybe you have not 
created a configuration file.
FileNotFoundError: [Errno 2] No such file or directory: 
'/home/tj/.config/bugwarrior/bugwarriorrc'

$ mv ~/.config/bugwarrior{.bak,}

$ bugwarrior-pull
CRITICAL:bugwarrior.command:Could not load configuration. Maybe you have not 
created a configuration file.
FileNotFoundError: [Errno 2] No such file or directory: 
'/usr/lib/python3/dist-packages/bugwarrior/docs/configuration.rst'

$ cat ~/.config/bugwarrior/bugwarriorrc
[general]
targets = debianbts my_github


Delete my_github here, as you don't have a section on it.


[debianbts]
service = bts
bts.email = deb...@iam.tj


Add bts.udd = True to get your bugs ;).


$ dpkg -S docs/configuration.rst
dpkg-query: no path found matching pattern *docs/configuration.rst*
$ apt-file search  docs/configuration.rst
$


dpkg -S configuration.rst
bugwarrior: /usr/share/doc/bugwarrior/html/_sources/common_configuration.rst.txt
bugwarrior: /usr/share/doc/bugwarrior/html/_sources/configuration.rst.txt

The second one is the same file. I will push new version with a fixed 
path.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1067447: jackd2: patch to fix ftbfs on m68k; jack{1,2}: unneeded libffado-dev B-D on some arches

[Thorsten Glaser]

Source: jackd2
Version: 1.9.21~dfsg-3
Severity: important
Tags: patch
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org
Control: affects -1 src:jack-audio-connection-kit

Hi,

please apply the attached patch for jackd2 and forward it upstream
that makes the implicit alignment assumptions (not supported by the
C and C++ standards) explicit, which allows building on m68k. The
diff won’t change a bit for other architectures.

Please also apply the patches for jackd2 and jack-audio-connection-kit
both to restrict B-D on libffado-dev to these architectures where the
firewire binary package is actually built. The reverse B-D chain of
ffado is… pure hell, and even more cyclic without this.

Thanks!diff -Nru jack-audio-connection-kit-0.126.0/debian/changelog 
jack-audio-connection-kit-0.126.0/debian/changelog
--- jack-audio-connection-kit-0.126.0/debian/changelog  2023-01-06 
23:02:48.0 +0100
+++ jack-audio-connection-kit-0.126.0/debian/changelog  2024-03-21 
02:03:21.0 +0100
@@ -1,3 +1,9 @@
+jack-audio-connection-kit (1:0.126.0-2+m68k) unreleased; urgency=medium
+
+  * Only B-D: libffado-dev if jackd1-firewire is built
+
+ -- Thorsten Glaser   Thu, 21 Mar 2024 02:03:21 +0100
+
 jack-audio-connection-kit (1:0.126.0-2) unstable; urgency=medium
 
   * Team upload
diff -Nru jack-audio-connection-kit-0.126.0/debian/control 
jack-audio-connection-kit-0.126.0/debian/control
--- jack-audio-connection-kit-0.126.0/debian/control2023-01-06 
23:02:48.0 +0100
+++ jack-audio-connection-kit-0.126.0/debian/control2024-03-21 
01:50:44.0 +0100
@@ -15,7 +15,7 @@
  doxygen,
  libasound2-dev [linux-any],
  libdb-dev,
- libffado-dev [linux-any],
+ libffado-dev [amd64 i386 powerpc],
  libraw1394-dev [linux-any],
  libreadline-dev,
  libsamplerate-dev,
diff -Nru jackd2-1.9.21~dfsg/debian/changelog 
jackd2-1.9.21~dfsg/debian/changelog
--- jackd2-1.9.21~dfsg/debian/changelog 2023-05-04 21:29:39.0 +0200
+++ jackd2-1.9.21~dfsg/debian/changelog 2024-03-21 02:20:11.0 +0100
@@ -1,3 +1,10 @@
+jackd2 (1.9.21~dfsg-3+m68k) unreleased; urgency=medium
+
+  * Only B-D: libffado-dev if jackd2-firewire is built
+  * debian/patches/fix-implicit-alignment-assumptions.diff: add
+
+ -- Thorsten Glaser   Thu, 21 Mar 2024 02:20:11 +0100
+
 jackd2 (1.9.21~dfsg-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru jackd2-1.9.21~dfsg/debian/control jackd2-1.9.21~dfsg/debian/control
--- jackd2-1.9.21~dfsg/debian/control   2023-05-04 21:29:39.0 +0200
+++ jackd2-1.9.21~dfsg/debian/control   2024-03-21 01:54:43.0 +0100
@@ -11,7 +11,7 @@
libdb-dev,
libdbus-1-dev,
libexpat1-dev,
-   libffado-dev [linux-any],
+   libffado-dev [amd64 i386 powerpc],
libncurses-dev,
libopus-dev,
libraw1394-dev [linux-any],
diff -Nru 
jackd2-1.9.21~dfsg/debian/patches/fix-implicit-alignment-assumptions.diff 
jackd2-1.9.21~dfsg/debian/patches/fix-implicit-alignment-assumptions.diff
--- jackd2-1.9.21~dfsg/debian/patches/fix-implicit-alignment-assumptions.diff   
1970-01-01 01:00:00.0 +0100
+++ jackd2-1.9.21~dfsg/debian/patches/fix-implicit-alignment-assumptions.diff   
2024-03-21 02:20:03.0 +0100
@@ -0,0 +1,93 @@
+Description: fix implicit alignment assumptions
+ The language standard does not guarantee “natural” alignment
+ (i.e. alignment to (at least) the size of the integer type),
+ and on some architectures, int normally is only 16-bit-aligned.
+ Make the assumption explicit to allow compilation on these.
+Author: Thorsten Glaser 
+
+--- a/common/JackActivationCount.h
 b/common/JackActivationCount.h
+@@ -39,7 +39,7 @@ class JackActivationCount
+ 
+ private:
+ 
+-alignas(SInt32) SInt32 fValue;
++alignas(SInt32) alignas(sizeof(SInt32)) SInt32 fValue;
+ SInt32 fCount;
+ 
+ public:
+--- a/common/JackAtomicArrayState.h
 b/common/JackAtomicArrayState.h
+@@ -122,7 +122,7 @@ class JackAtomicArrayState
+ // fState[2] ==> request
+ 
+ T fState[3];
+-alignas(UInt32) alignas(AtomicArrayCounter) volatile 
AtomicArrayCounter fCounter;
++alignas(UInt32) alignas(sizeof(UInt32)) alignas(AtomicArrayCounter) 
volatile AtomicArrayCounter fCounter;
+ 
+ UInt32 WriteNextStateStartAux(int state, bool* result)
+ {
+--- a/common/JackAtomicState.h
 b/common/JackAtomicState.h
+@@ -94,7 +94,7 @@ class JackAtomicState
+ protected:
+ 
+ T fState[2];
+-alignas(UInt32) alignas(AtomicCounter) volatile AtomicCounter 
fCounter;
++alignas(UInt32) alignas(sizeof(UInt32)) alignas(AtomicCounter) 
volatile AtomicCounter fCounter;
+ SInt32 fCallWriteCounter;
+ 
+ UInt32 WriteNextStateStartAux()
+--- a/common/JackConnectionManager.h
 b/common/JackConnectionManager.h
+@@ -417,7 +417,7 @@ class SERVER_EXPORT JackConnectionManage
+ JackFixedArray1 

Bug#1067451: libzip: please update to 1.10.1

[Thomas Klausner]

Package: libzip
Version: 1.7.3-1.1

Upstream here.

The libzip package in Debian is quite outdated (a release from 2020),
can you please update it to the latest version (1.10.1 right now, from
August 2023)?

We take care that libzip is backwards-compatible, so the update should
be painless. Let me know if it isn't!

Thanks,
 Thomas

Bug#1067450: ttyd: does not start

[Daniel]

Package: ttyd
Version: 1.7.4-1+b2
Severity: grave
Justification: renders package unusable

Output of systemctl status ttyd

Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E: 
lws_create_context: failed to load evlib_uv
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E: 
libwebsockets context creation failed
Mar 21 17:59:09 zone-s systemd[1]: ttyd.service: Main process exited, 
code=exited, status=1/FAILURE
Mar 21 17:59:09 zone-s systemd[1]: ttyd.service: Failed with result 'exit-code'.



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

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

Versions of packages ttyd depends on:
ii  libc6   2.36-9+deb12u4
ii  libcap2 1:2.66-4
ii  libjson-c5  0.16-2
ii  libssl3t64  3.1.5-1.1
ii  libuv1t64   1.48.0-1.1
ii  libwebsockets-evlib-uv  4.1.6-3
ii  zlib1g  1:1.2.13.dfsg-1

ttyd recommends no packages.

Versions of packages ttyd suggests:
ii  apache2  2.4.57-2

-- no debconf information

Bug#1067449: RFS: cdemu-client/3.2.5-1 [ITP] -- Command-line client to control CDEmu daemon

[Matteo Bini]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "cdemu-client":

 * Package name : cdemu-client
   Version  : 3.2.5-1
   Upstream contact : Rok Mandeljc 
 * URL  : https://cdemu.sourceforge.io/
 * License  : CC0-1.0, GPL-2+
   Section  : utils

The source builds the following binary packages:

  cdemu-client - Command-line client to control CDEmu daemon

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

  https://mentors.debian.net/package/cdemu-client/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cdemu-client/cdemu-client_3.2.5-1.dsc

Changes for the initial release:

 cdemu-client (3.2.5-1) unstable; urgency=low
 .
   * Initial release, closes: #983452.

Regards,

-- 
Matteo Bini

Bug#1067448: RFS: gcdemu/3.2.6-1 [ITP] -- GNOME application to control CDEmu daemon

[Matteo Bini]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : gcdemu
   Version  : 3.2.6-1
   Upstream contact : Rok Mandeljc 
 * URL  : https://cdemu.sourceforge.io/
 * License  : CC0-1.0, GPL-2+
   Section  : utils

The source builds the following binary packages:

  gcdemu - GNOME application to control CDEmu daemon

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gcdemu/gcdemu_3.2.6-1.dsc

Changes for the initial release:

 gcdemu (3.2.6-1) unstable; urgency=low
 .
   * Initial release, closes: #983453

Regards,

-- 
Matteo Bini

Bug#1067446: ghdl fails to build with gnat-13

[Matthias Klose]

Package: src:ghdl
Version: 3.0.0+dfsg2-1
Severity: serious
Tags: sid trixie ftbfs

ghdl still uses gcc-12/gnat-12 for the build, a package that will not be 
shipped with the next Debian release (these will be gcc-13 and gcc-14).


Replacing the -12 b-d's with -13, and fixing the version check in 
Makefile.in let's the package build, but with some tsts failing.


There's also a new upstream release.

Bug#1067445: whitakers-words ftbfs with gnat-13

[Matthias Klose]

Package: src:whitakers-words
Version: 0.2020.10.27-1.3
Severity: serious
Tags: sid trixie ftbfs

[...]
makeinfl.adb:22:06: warning: renamed predefined unit is an obsolescent 
feature (RM J.1) [-gnatwj]
/home/packages/tmp/x/whitakers-words-0.2020.10.27/src/latin_utils/latin_utils-general.adb: 
In function 'latin_utils__general__load_dictionary':
/home/packages/tmp/x/whitakers-words-0.2020.10.27/src/latin_utils/latin_utils-general.adb:49:8: 
warning: 'd_k' may be used uninitialized [-Wmaybe-uninitialized]
/home/packages/tmp/x/whitakers-words-0.2020.10.27/src/latin_utils/latin_utils-general.ads:33:8: 
note: 'd_k' was declared here


   compilation of makeinfl.adb failed

gprbuild: *** compilation phase failed
make[2]: *** [Makefile:40: commands] Error 4
make[2]: Leaving directory 
'/home/packages/tmp/x/whitakers-words-0.2020.10.27'

Bug#1067444: FileNotFoundError: [Errno 2] ... /usr/lib/python3/dist-packages/bugwarrior/docs/configuration.rst

[Tj]

Package: bugwarrior
Version: 1.8.0-7
Severity: grave
Justification: renders package unusable

Dear Maintainer,

With a fresh install and manually creating the user's configuration file
I hit this error. The path reported seems to indicate the package is not
shipping the file mentioned. I tried moving the user config directory and
saw the error caused by it being missing, put it back, and hit this package
config file issue agian.

$ bugwarrior-pull
CRITICAL:bugwarrior.command:Could not load configuration. Maybe you have not 
created a configuration file.
FileNotFoundError: [Errno 2] No such file or directory: 
'/home/tj/.config/bugwarrior/bugwarriorrc'

$ mv ~/.config/bugwarrior{.bak,}

$ bugwarrior-pull
CRITICAL:bugwarrior.command:Could not load configuration. Maybe you have not 
created a configuration file.
FileNotFoundError: [Errno 2] No such file or directory: 
'/usr/lib/python3/dist-packages/bugwarrior/docs/configuration.rst'

$ cat ~/.config/bugwarrior/bugwarriorrc
[general]
targets = debianbts my_github

[debianbts]
service = bts
bts.email = deb...@iam.tj

$ dpkg -S docs/configuration.rst
dpkg-query: no path found matching pattern *docs/configuration.rst*
$ apt-file search  docs/configuration.rst
$

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

Versions of packages bugwarrior depends on:
ii  libjs-sphinxdoc5.3.0-4
ii  python33.11.2-1+b1
ii  python3-click  8.1.3-2
ii  python3-dateutil   2.8.2-2
ii  python3-dogpile.cache  1.1.8-2
ii  python3-future 0.18.2-6
ii  python3-jinja2 3.1.2-1
ii  python3-lockfile   1:0.12.2-2.2
ii  python3-requests   2.28.1+dfsg-1
ii  python3-six1.16.0-4
ii  python3-taskw  2.0.0-1
ii  python3-tz 2022.7.1-4

Versions of packages bugwarrior recommends:
ii  python3-google-auth-oauthlib  0.4.2-1
ii  python3-googleapi 1.7.12-1
ii  python3-jira  3.4.1-1
ii  python3-keyring   23.9.3-2
ii  python3-phabricator   0.7.0-1.1
ii  python3-pypandoc  1.7.4+ds0-2

bugwarrior suggests no packages.

-- no debconf information

Bug#1067443: procps: vmstat [delay] does not update memory information

[helios . solaris]

Apologies for the duplicate. I merged it.
But I agree, it should be fixed in stable.

Bug#1067440:

[Laurențiu Nicola]

Correction: because of full-text search, it might actually be quadratic in the 
number of packages (I didn't check). And it might be possible to fix it, by 
going through the compressed stream just once, instead of restarting (assuming 
the results are returned in the file order, which seems reasonable).

Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k

[Thorsten Glaser]

Colin Watson dixit:

>I don't love overriding snprintf here, since it seems possible that that

Agreed.

>could disturb the check on other architectures.  Could you try the
>somewhat further reduced patch in
>https://salsa.debian.org/ssh-team/openssh/-/tree/zero-call-used-regs-m68k,

Yes, but not sure I manage it tonight, and I’ll be gone all day
tomorrow.

>please?  I wanted to use the mitchy.debian.net porterbox but I got
>ECONNREFUSED.

Adrian, do you have an idea about that?

>This configure check doesn't use the usual autoconf result caching
>arrangements, which makes it a bit more awkward to override from
>debian/rules.  There are options, but an extended configure check that I
>could send upstream would probably be best.

oic, yes, that’s definitely easier.

For now I’ve built the last upload with the flag manually removed,
so this isn’t a transition blocker any more, until the next upload
anyway and perhaps not even then…

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#1067407: graphviz: diff for NMU version 2.42.2-8.1

[GCS]

Control: tags -1 +moreinfo

On Thu, Mar 21, 2024 at 12:39 PM Gianfranco Costamagna
 wrote:
> I've prepared an NMU for graphviz (versioned as 2.42.2-8.1) and
> uploaded it to DELAYED/2. Please feel free to cancel it directly if you want 
> to do a maintainer upload.
 I do not see the point of this. Can you please recheck the current
graphviz package state and report back to me?

Regards,
Laszlo/GCS

Bug#1067443: procps: vmstat [delay] does not update memory information

[Bänziger]

Package: procps
Version: 2:4.0.2-3
Severity: normal
X-Debbugs-Cc: helios.sola...@gmx.ch

Dear Maintainer,

When running for example "vmstat 5", the io, system and cpu information are 
updated every 5 seconds, as expected. But the memory info stays always the 
same, until vmstat is terminated and started again.


-- System Information:
Debian Release: 12.5
  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-18-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages procps depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u4
ii  libncursesw6 6.4-4
ii  libproc2-0   2:4.0.2-3
ii  libtinfo66.4-4

Versions of packages procps recommends:
ii  psmisc  23.6-1

procps suggests no packages.

-- no debconf information

Bug#1067407: graphviz: FTBFS due to -Wimplicit-declaration gcc flag

[GCS]

Hi Gianfranco,

On Thu, Mar 21, 2024 at 9:09 AM Gianfranco Costamagna
 wrote:
> Hello, looks like the package will FTBFS due to newly introduced 
> implicit-declaration flag
> I did cherry-pick two upstream patches and the package now build successfully.
 When that '-Wimplicit-declaration' is going to be set? I'm a bit
confused, you may mix it with '-Werror=implicit-function-declaration'
which was already patched five days ago.
Can you recheck your findings and add more information?

Thanks,
Laszlo/GCS

Bug#1067317: scons: FTBFS: Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: cannot open shared object file: No suc

[Mats Wichmann]

On Wed, 20 Mar 2024 22:04:03 +0100 Lucas Nussbaum  wrote:

Source: scons
Version: 4.5.2+dfsg-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240319 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


This is unfortunate.  The docbook toolchain seems to have always 
generated a lot of spew from fop, which to the SCons project has seemed 
"out of our control". Now it seems something has changed so where the 
java used to throw SEVERE it is now throwing ERROR, thus failing the 
build - which really has nothing to do with the operation of SCons, 
which is just a Python package, after all.  This is a failure to 
generate the pdf versions of the docs, which are unused by the deb 
package, afaict.



Relevant part (hopefully):



> [ERROR] FOUserAgent - Invalid property value encountered in margin-left="": org.apache.fop.fo.expr.PropertyException: 
file:/<>/doc/man/scons-scons-time.fo:3:6: No conversion defined ; property:'margin-left' (See position 147:8) 
>/doc/man/scons-scons-time.fo:3:6: No conversion defined 
; property:'margin-left'>org.apache.fop.fo.expr.PropertyException: 
file:/<>/doc/man/scons-scons-time.fo:3:6: No conversion defined ; property:'margin-left'

...

> [ERROR] FOUserAgent - Invalid property value encountered in margin-right="": org.apache.fop.fo.expr.PropertyException: 
file:/<>/doc/man/scons-scons-time.fo:3:6: No conversion defined ; property:'margin-right' (See position 
147:8) >/doc/man/scons-scons-time.fo:3:6: No conversion 
defined ; property:'margin-right'>org.apache.fop.fo.expr.PropertyException: 
file:/<>/doc/man/scons-scons-time.fo:3:6: No conversion defined ; property:'margin-right'
>at org.apache.fop.fo.properties.PropertyMaker.make(PropertyMaker.java:446)
>at 
org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:499)


The latest upstream release (4.7.0) tried to provide a way to avoid 
doing the pdf and Sphinx builds, but it turns out it doesn't do that in 
a place that the Debian packaging uses anyway.  Will make a note to 
revisit that on our end.


Didn't realize the deb directly used the build files in doc/man and 
doc/user.  The quickest way to patch around this would seem to be to 
comment out or remove the check in


doc/man/SConstruct
doc/user/SConstrcut

which checks for the presence of the 'fop' or 'xep' commands, so that 
'has_pdf' remains false, and the pdf build thus isn't attempted at all. 
I assume you don't need the pdf files, just the scons.1 etc. files? 
that's all I see copied in 
https://salsa.debian.org/debian/scons/-/blob/master/debian/rules?ref_type=heads

Bug#1067442: contains files for different architecture

[Dmitry Baryshkov]

Package: syslinux-efi
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
Severity: grave
X-Debbugs-Cc: dbarysh...@gmail.com

The ARM64 syslinux-efi package binaries for x86 instead instead of ARM
binaries:

$ uname -m
aarch64

$ file /usr/lib/SYSLINUX.EFI/efi*/syslinux.efi
/usr/lib/SYSLINUX.EFI/efi32/syslinux.efi: PE32 executable (EFI application) 
Intel 80386 (stripped to external PDB), for MS Windows
/usr/lib/SYSLINUX.EFI/efi64/syslinux.efi: PE32+ executable (EFI application) 
x86-64 (stripped to external PDB), for MS Windows

As such these binaries are unusable on ARM64 hosts.

-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.9-qcomlt-arm64-00188-g31f49428dc7d (SMP w/4 CPU threads; 
PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

syslinux-efi depends on no packages.

Versions of packages syslinux-efi recommends:
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

Versions of packages syslinux-efi suggests:
ii  dosfstools  4.2-1

-- no debconf information

Bug#1067441: chromium: Unable to sync profile

[Wesley Schwengle]

Package: chromium
Version: 122.0.6261.128-1
Severity: important
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I've started up Chromium and want to sync my Google account.

* Create new profile
* Login to Google (succesfully)
  Within Google.com you are known, myaccount.google.com shows your details
* Click on the profile button of your browser
* Clock on "Turn sync on"
* Follow the login sequence
* Notice error in the console:

[29150:29150:0321/112903.702701:ERROR:turn_sync_on_helper.cc(256)] Cannot turn 
Sync On for invalid account.
[29150:29150:0321/112950.431580:ERROR:turn_sync_on_helper.cc(256)] Cannot turn 
Sync On for invalid account.

Doing the same action with the builds of Google itself everything works fine,
tested this with the browsers listed below.

The bug is also present on bookworm, where I tested it with 
122.0.6261.128-1~deb12u1

Cheers,
Wesley


google-chrome-stable:
  Installed: 123.0.6312.58-1
  Candidate: 123.0.6312.58-1
  Version table:
 *** 123.0.6312.58-1 900
900 https://dl.google.com/linux/chrome/deb stable/main amd64 Packages
100 /var/lib/dpkg/status
google-chrome-beta:
  Installed: 123.0.6312.46-1
  Candidate: 123.0.6312.46-1
  Version table:
 *** 123.0.6312.46-1 900
900 https://dl.google.com/linux/chrome/deb stable/main amd64 Packages
100 /var/lib/dpkg/status
google-chrome-unstable:
  Installed: 124.0.6356.2-1
  Candidate: 124.0.6356.2-1
  Version table:
 *** 124.0.6356.2-1 900
900 https://dl.google.com/linux/chrome/deb stable/main amd64 Packages
100 /var/lib/dpkg/status



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

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

Versions of packages chromium depends on:
ii  chromium-common  122.0.6261.128-1
ii  libasound2t641.2.11-1+b1
ii  libatk-bridge2.0-0t642.51.90-4
ii  libatk1.0-0t64   2.51.90-4
ii  libatomic1   14-20240315-1
ii  libatspi2.0-0t64 2.51.90-4
ii  libc62.37-15.1
ii  libcairo21.18.0-2
ii  libcups2t64  2.4.7-1.2+b1
ii  libdbus-1-3  1.14.10-4+b1
ii  libdouble-conversion33.3.0-1+b1
ii  libdrm2  2.4.120-2
ii  libevent-2.1-7t642.1.12-stable-8.1+b1
ii  libexpat12.6.2-1
ii  libflac12t64 1.4.3+ds-2.1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b2
ii  libgbm1  24.0.3-1
ii  libgcc-s114-20240315-1
ii  libglib2.0-0t64  2.78.4-5
ii  libgtk-3-0t64 [libgtk-3-0]   3.24.41-3
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libjsoncpp25 1.9.5-6+b2
ii  liblcms2-2   2.14-2+b1
ii  libminizip1t64   1:1.3.dfsg-3.1
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libopenh264-72.4.1+dfsg-1
ii  libopenjp2-7 2.5.0-2+b3
ii  libopus0 1.4-1+b1
ii  libpango-1.0-0   1.52.1+ds-1
ii  libpng16-16t64   1.6.43-3
ii  libpulse016.1+dfsg1-3+b1
ii  libsnappy1v5 1.1.10-1+b1
ii  libstdc++6   14-20240315-1
ii  libwebp7 1.3.2-0.4+b1
ii  libwebpdemux21.3.2-0.4+b1
ii  libwebpmux3  1.3.2-0.4+b1
ii  libwoff1 1.0.2-2+b1
ii  libx11-6  

Bug#872807: Bug #872807: dh-make-golang: Please find dependencies based on Homepage, too

[Anthony Fok]

I am sorry, I copied the wrong bug number and inadvertently closed
this bug by mistake.
My apologies!
It has now been reopened.

Thanks,
Anthony

Bug#1066067: cl-plus-ssl: hardcoded libssl3 dependency

[Christoph Berg]

Re: Sebastian Ramacher
> Source: cl-plus-ssl
> Version: 20220328.git8b91648-4
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> cl-plus-ssl hardcodeds a dependency on libssl3. Due to the time_t
> transition, the package name changed and the dependency needs to be
> updated.

It actually doesn't hard-code the dependency but correctly extracts it
from libssl-dev. But since we don't have arch:all binnmus, a new
upload was needed anyway. Just did that.

Once cl-plus-ssl is installed, please binnmu pgloader to have it pick
up the changed dependency.

Christoph

Bug#1066191: libapache2-mod-security2: when building an apache2 docker image with sid packages for armhf the build fails

[Alberto Gonzalez Iniesta]

Hi, as you already mention, the t64 transition is taking place right
now. I'm quite sure this will be solved in some days/weeks.



On Wed, Mar 13, 2024 at 12:39:11PM +0100, logo wrote:
> Package: libapache2-mod-security2
> Version: 2.9.7-1+b1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> time_64 migration
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Fails to build an Dockerfile with the following command:
> 
> #MODSECURITY_VERSIONi=2.9.7-1+b1
> RUN set -x  && apt-get update \
>&& apt-get -t sid install -o APT::Immediate-Configure=false -y 
> libapache2-mod-security2=$MODSECURITY_VERSION
> 
>* What was the outcome of this action?
> #10 0.187 Reading package lists...
> #10 5.903 Building dependency tree...
> #10 6.837 Reading state information...
> #10 7.275 Some packages could not be installed. This may mean that you have
> #10 7.275 requested an impossible situation or if you are using the unstable
> #10 7.275 distribution that some required packages have not yet been created
> #10 7.275 or been moved out of Incoming.
> #10 7.275 The following information may help to resolve the situation:
> #10 7.275 
> #10 7.276 The following packages have unmet dependencies:
> #10 7.690  libdb5.3t64 : Breaks: libdb5.3 (< 5.3.28+dfsg2-5) but 
> 5.3.28+dfsg2-1 is to be installed
> #10 7.690  libgdbm6t64 : Breaks: libgdbm6 (< 1.23-5.1) but 1.23-5+b1 is to be 
> installed
> #10 7.690  libgnutls30t64 : Breaks: libgnutls30 (< 3.8.3-1.1) but 3.8.3-1 is 
> to be installed
> #10 7.690  libhogweed6t64 : Breaks: libhogweed6 (< 3.9.1-2.2) but 3.8.1-2 is 
> to be installed
> #10 7.691  libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2+b1 is 
> to be installed
> #10 7.693  libssl3t64 : Breaks: libssl3 (< 3.1.5-1.1) but 3.1.5-1 is to be 
> installed
> #10 7.699 E: Unable to correct problems, you have held broken packages.
> 
>* What outcome did you expect instead?
> Installed package
> 
> 
> -- System Information:
> 
> is not clear, as it is running in docker buildx v0.13.0 with docker buildx 
> build --platform=linux/arm/v7 on docker 25.0.4 in:
> 
> Debian Release: 12.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable')
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 6.1.0-18-arm64 (SMP w/4 CPU threads)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> 
> Base image is debian:bookworm-slim
> no other sid packages
> 
> image builds fine for arm64 or amd64
> 
> I know that the package is currently the same in bookworm but I build on new 
> releases in sid.
> 
> Please advise.
> 
> Thank You
> 
> Peter

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#1067427: dpkg-dev: Fail to generate a substitution variable ${t64:Provides} (time_t transition)

[Christian Marillat]

On 21 mars 2024 15:41, Simon McVittie  wrote:


[...]

>  4. armel, armhf are the two 32-bit release architectures which are
> not in any of the previous categories, so they are genuinely changing
> their ABIs.
> Non-release architectures in the same category: hppa m68k powerpc sh4.
>
> On these architectures, libopenshot-audio9t64 must not have a Provides
> on libopenshot-audio9, because its ABI has changed, so the new library
> does not provide an interface that is compatible with the old library.
> (This is the reason why we're doing all this renaming!)

I did not know.

> So I think this is not a bug, and certainly not a RC bug. The warnings are
> a bit annoying, but do not indicate a genuine problem.

Yes of course, you can close this bug.

Christian

Bug#1065194: RFS: python-raccoon/3.1.1-1 -- Python DataFrame with fast insert and appends (Python 3)

[Akash Doppalapudi]

Hi Jeroen Ploemen,

Thank you for reviewing my package...

* Yes, I need the salsa repo access for this package. My username is 
"akashdoppalapudi"

* I will rectify the package and reupload it to mentors.

Thanks again for taking time and reviewing my package.

Regards,
Akash

On March 21, 2024 3:00:22 PM GMT+05:30, Jeroen Ploemen  wrote:
>Control: tags -1 moreinfo
>
>On Fri, 1 Mar 2024 23:54:26 +0530
>Akash Doppalapudi  wrote:
>
>> I am looking for a sponsor for my package "python-raccoon":
>
>hi Akash,
>
>thanks for working on this package. Unfortunately, it fails to build,
>so the following remarks and suggestions are based on the source pkg
>alone:
>
>* please push your changes to the package's VCS; if you need access
>  to its current repository on salsa just let me know (do mention your
>  username there).
>* multiple build-deps seem to be only needed for running tests, but
>  those are disabled in d/rules (probably because the tarball on pypi
>  doesn't contain any test files in the first place, only the upstream
>  github repo does). Please remove any unused build-deps.
>* d/rules incorrectly sets PYBUILD_NAME to the source pkg name, this
>  should either be deleted, or set to the name actually used to import
>  the module.
>* the binary pkg has an unused hardcoded dependency on
>  python3-pkg-resources.
>* consider adding a very basic autopkgtest by setting 'Testsuite:
>  autopkgtest-pkg-python' in d/control.
>
>
>Build fails with the following error (full log attached):
>
>dpkg-source: info: building python-raccoon in python-raccoon_3.1.1-1.dsc
> debian/rules binary
>dh binary --with python3 --buildsystem=pybuild
>   dh_update_autotools_config -O--buildsystem=pybuild
>   dh_autoreconf -O--buildsystem=pybuild
>   dh_auto_configure -O--buildsystem=pybuild
>E: pybuild pybuild:389: configure: plugin pyproject failed with: PEP517 plugin 
>dependencies are not available. Please Build-Depend on 
>pybuild-plugin-pyproject.
>dh_auto_configure: error: pybuild --configure -i python{version} -p "3.12 
>3.11" returned exit code 13
>make: *** [debian/rules:6: binary] Error 25
>
>
>Please remove the moreinfo tag (and CC me directly) once you have an
>updated package ready.


signature.asc
Description: PGP signature

Bug#1067440: Compression makes searching packages very slow

[Laurențiu Nicola]

Package: apt
Version: 2.7.12

I noticed that searching for packages is very slow if the package lists are 
compressed. To reproduce, remove `/var/lib/apt/lists`, enable

Acquire::GzipIndexes "true"; Acquire::CompressionTypes::Order:: "gz";

, run `apt update`. This enables LZ4 compression on my systems, but I don't 
think the exact method matters. You can then run `apt search librust`, which 
takes about 19 seconds in a Debian 12 container (docker.io/debian:12 has 
compression already set up), compared to 0.4 seconds without compression.

Also tested on Ubuntu 22.04 and 24.04, so the exact APT version shouldn't 
matter too much.

I tried to look into it, and `strace -e trace=openat apt-cache search librust` 
shows it reopen and re-read one of the package lists:

openat(AT_FDCWD, 
"/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
 O_RDONLY) = 16
librust-addr2line+default-dev - Cross-platform symbolication library - feature 
"default"
openat(AT_FDCWD, 
"/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
 O_RDONLY) = 16
librust-addr2line+object-dev - Cross-platform symbolication library - feature 
"object"
openat(AT_FDCWD, 
"/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
 O_RDONLY) = 16
librust-addr2line+rustc-demangle-dev - Cross-platform symbolication library - 
feature "rustc-demangle"
openat(AT_FDCWD, 
"/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
 O_RDONLY) = 16
librust-addr2line+std-dev - Cross-platform symbolication library - feature "std"

(you can use -e trace=openat,read to confirm that it's actually reading the 
file)

I believe it's quadratic in the number of search results, and this is related 
to the pseudo-indexing mechanism used by APT (see `pkgRecords::Lookup` in 
apt-pkg). Each lookup call will have to decompress the file in order to seek to 
the destination.

Unfortunately, I suspect this isn't exactly an easy fix, given the current 
design.

Bug#822605: bash: SIGPIPE not handled, terminates shell

[Gioele Barabucci]

Control: retitle -1 bash: SIGPIPE not handled, terminates shell
Control: found -1 5.2.21-2

Bash 5.2.21 still exhibits this issue, the subshell terminates once a 
SIGPIPE is received:


(shell1)$ rm -f /tmp/f && mkfifo /tmp/f && (i=0; while true; do echo 
$((i=i+1)) > /tmp/f; done); echo "terminated with exit status $?"


(shell2)$ while true; do echo $(< /tmp/f); done

The command in shell1 will output "terminated with exit status 141".

For the record, dash 0.5.12 has the same behavior.

Regards,

--
Gioele Barabucci

Bug#1067427: dpkg-dev: Fail to generate a substitution variable ${t64:Provides} (time_t transition)

[Simon McVittie]

Control: tags -1 + moreinfo

On Thu, 21 Mar 2024 at 15:00:52 +0100, Christian Marillat wrote:
> I noticed this bug with the libopenshot-audio source and with
> armel, armh and powerpc architectures from buildd logs and my rebuild.
> 
> I didn't pay attention for others sources, but I noticed that only
> after a second rebuild...
> 
> ,
> | pkg-gencontrol: warning: Provides field of package libopenshot-audio9t64: 
> substitution variable ${t64:Provides} used, but is not defined
> | dpkg-gencontrol: warning: Provides field of package libopenshot-audio9t64: 
> substitution variable ${t64:Provides} used, but is not defined
> `

This appears to be working as designed (cc'ing the instigator of this
transition for confirmation). It is correct that no ${t64:Provides}
is generated on armel, armhf and powerpc (and other 32-bit non-i386
architectures, like hppa).

There are four categories of architectures for this transition (text
adapted from https://wiki.debian.org/ReleaseGoals/64bit-time, which was
itself adapted from a recent message from me to -devel):

 1. amd64, arm64, mips64el, ppc64el, riscv64, s390x are all 64-bit, so they
already had 64-bit time_t.
Non-release architectures in the same category: alpha hurd-amd64 ia64
loong64 ppc64 sparc64.

On these architectures, libopenshot-audio9t64 can safely have
Provides: libopenshot-audio9, because the ABI has not actually changed.

 2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
because its major purpose this decade is running legacy 32-bit
binaries, a purpose that would no longer be possible if it broke ABI.
Non-release architectures in the same category: hurd-i386.

On i386, libopenshot-audio9t64 can have the Provides, as above.

 3. There is currently no release architecture that is 32-bit but already
had a 64-bit time_t prior to 2024.
Non-release architectures in this category: x32.

On x32, libopenshot-audio9t64 should ideally have the Provides, as above
(I'm not sure whether it actually does, but given the status of x32,
I don't think this is actually harming anyone.)

 4. armel, armhf are the two 32-bit release architectures which are
not in any of the previous categories, so they are genuinely changing
their ABIs.
Non-release architectures in the same category: hppa m68k powerpc sh4.

On these architectures, libopenshot-audio9t64 must not have a Provides
on libopenshot-audio9, because its ABI has changed, so the new library
does not provide an interface that is compatible with the old library.
(This is the reason why we're doing all this renaming!)

So I think this is not a bug, and certainly not a RC bug. The warnings are
a bit annoying, but do not indicate a genuine problem.

smcv

Bug#1067439: cpu: undefined symbol globalLdap in libcpu_ldap.so on Debian 12

[Simone Piccardi]

Package: cpu
Version: 1.4.3-13+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

It was working on Debian 11, but after upgrading to Debian 12 just calling the 
program make it crash:

root@davis:~# cpu
CPU_loadLibrary: dlopen(libcpu_ldap.so, RTLD_NOW) failed.
CPU_loadLibrary: /lib/x86_64-linux-gnu/libcpu_ldap.so: undefined symbol: 
globalLdap
There was an error loading the ldap library. Exiting.

Regards
Simone

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 cpu depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u4
ii  libcrack2  2.9.6-5+b1
ii  libcrypt1  1:4.4.33-2
ii  libldap-2.5-0  2.5.13+dfsg-5
ii  ucf3.0043+nmu1

cpu recommends no packages.

cpu suggests no packages.

-- debconf information:
  cpu/ldap/BIND_PASS: (password omitted)
  cpu/ldap/USER_BASE: ou=People,dc=truelite,dc=it
  cpu/ldap/BIND_DN: cn=admin,dc=truelite,dc=it
  cpu/ldap/GROUP_BASE: ou=Group,dc=truelite,dc=it
  cpu/ldap/LDAP_URI: ldap://localhost
  cpu/do_debconf: true

Bug#1067413: RFP: keydb -- persistent key-value database with network interface

[Sascha Steinbiss]

Hi Guillem,

[RFP]
I'll try to do this during this week or next one, but if someone 
would like to package this right ahead, I can speed this up.


Cool. If my old packaging helps in any way, feel free to steal anything
from it! [0]

[...]
I'm also CCing Sascha who might be interested (given the keydb 
packaging repo in salsa).


That was a one-off that never made it from a testing prototype into
anything upload-worthy, let alone into production. We used it to
evaluate KeyDB internally within my organization as a potentially faster
Redis replacement, but we found out that it didn't help in our
particular use case. I just packaged it for Debian to allow for easier
installation/removal, so really simply for our convenience. I didn't
polish the packaging, did not do time-consuming things like checking
licenses, looking for the presence of code copies, etc. like I would for
something to be uploaded to the official archive. You can also see that
I just copied the debian directory from a different project (e.g. in
d/upstream/metadata).

I also wouldn't want to support KeyDB in Debian long-term, given that I
already have >100 packages on my list and, as I said, I don't use KeyDB
myself anymore.

So please feel free to salvage the (unfortunately quite old) repo. Just
fork, remove me from the maintainer list and upload at will 

Best regards
Sascha

[0] https://salsa.debian.org/satta/keydb


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067438: gnome-shell-extension-hard-disk-led: needs update for GNOME Shell 46

[Simon McVittie]

Package: gnome-shell-extension-hard-disk-led
Version: 34-1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-46

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 46, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-46.html

If not updated, this extension will have to be removed from testing for
the GNOME Shell 46 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 46 but not
compatible with the version in unstable, please upload to experimental
for now.

Thanks,
smcv

Bug#1067437: gnome-shell-extension-espresso: needs update for GNOME Shell 46

[Simon McVittie]

Package: gnome-shell-extension-espresso
Version: 8-2
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-46

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 46, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-46.html

If not updated, this extension will have to be removed from testing for
the GNOME Shell 46 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

There does not seem to have been any work upstream yet on GNOME 46 support.

This particular extension is redundant with g-s-e-caffeine. I originally
uploaded it because g-s-e-caffeine seemed to be unmaintained, but actually
g-s-e-caffeine seems to be updating to new GNOME releases faster than
g-s-e-espresso, so it might make more sense to remove -espresso and only
keep -caffeine.

smcv

Bug#1067436: gnome-shell-extension-caffeine: needs update for GNOME Shell 46

[Simon McVittie]

Package: gnome-shell-extension-caffeine
Version: 48-1
Severity: important
Tags: trixie sid upstream patch
Forwarded: https://github.com/eonpatapon/gnome-shell-extension-caffeine/pull/317
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-46

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 46, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-46.html

There is a PR available upstream. I haven't tested it.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 46 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

smcv

Bug#1067435: psmisc: missing prstat binary

[Marek Straka]

Package: psmisc
Version: 23.4-2
Severity: minor
X-Debbugs-Cc: ma...@straka.info

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.10.0-27-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages psmisc depends on:
ii  libc6  2.31-13+deb11u7
ii  libtinfo6  6.2+20201114-2+deb11u2

psmisc recommends no packages.

psmisc suggests no packages.

Bug#1067434: gnome-shell-extension-shortcuts: needs update for GNOME Shell 46

[Jeremy Bícha]

Package: gnome-shell-extension-shortcuts
Version: 1.5.0-1~exp1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-46

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 46, which is currently being prepared in
Experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-46.html

Because GNOME Shell in Unstable is still at version 44 and because it
is generally not possible for extensions to be compatible with both
GNOME Shell version < 45 and >= 45, extension updates will need to go
to Experimental instead of Unstable until we upload GNOME Shell 46 to
Unstable.

If not updated, this extension will have to be removed from Testing
for the GNOME Shell 46 transition. This bug will be raised to serious
severity when the transition is ready to go ahead.

We expect to get approval from the Debian Release Team to begin the
GNOME Shell 46 transition soon after the 32-bit time_t transition
completes, but we do not know how long the time_t transition will
take.

On behalf of the Debian GNOME team,
Jeremy Bícha

Bug#1067433: gnome-shell-extensions-extra: needs update for GNOME Shell 46

[Jeremy Bícha]

Package: gnome-shell-extensions-extra
Version: 20231210-2
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-46

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 46, which is currently being prepared in
Experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-46.html

Because GNOME Shell in Unstable is still at version 44 and because it
is generally not possible for extensions to be compatible with both
GNOME Shell version < 45 and >= 45, extension updates will need to go
to Experimental instead of Unstable until we upload GNOME Shell 46 to
Unstable.

If not updated, this extension will have to be removed from Testing
for the GNOME Shell 46 transition. This bug will be raised to serious
severity when the transition is ready to go ahead.

We expect to get approval from the Debian Release Team to begin the
GNOME Shell 46 transition soon after the 32-bit time_t transition
completes, but we do not know how long the time_t transition will
take.

On behalf of the Debian GNOME team,
Jeremy Bícha

Bug#1067398: python3-numpy: Missing /usr/include/python3.11/numpy link breaks builds

[Dima Kogan]

Hi Timo. Thanks for replying.

My feeling is that being confused by that symlink is a bug, but I didn't
read #998084 in great detail, so maybe I'm missing some nuance. So let's
make this work.

** Short version **

Proposal: if pkg-config files will be added in the near future, can we
wait until those are available before removing the symlink? Or, can you
backport them into the current package? Essentially, moving the
information that was previously in the symlink into the .pc file? If I
can assume the symlink exists, I will use it in mrbuild and/or the
builds of projects that use it.

But if something was confused by the symlink, would it also be confused
by the .pc file?

** Long version **

The breakage is in packages where I'm upstream. These use my build
system: mrbuild. This asks Python for its header directory:
sysconfig.get_config_var('INCLUDEPY'), and asks the compiler to look
there. Today this ends up passing

  -I/usr/include/python3.11

which would previously succesfully resolve (via the now-missing symlink)

  #include 

mrbuild very explicitly does not use setup.py or anything of that
nature. It's used for mixed-language projects, and I don't want multiple
build systems for each language that wanted to rewrite the world. Some
discussion and rationale in a blog post:

  
https://notes.secretsauce.net/notes/2017/11/14_python-extension-modules-without-setuptools-or-distutils.html

I just tried to patch mrbuild to use np.get_includes(). This works, but
it's slow. After warming up the caches, I see this:

  $ time python3 -c 'import sysconfig'
  python3 -c 'import sysconfig'  0.02s user 0.01s system 97% cpu 0.025 total

  $ time python3 -c 'import numpy'
  python3 -c 'import numpy'  0.51s user 0.67s system 634% cpu 0.185 total

Currently the Makefile launches Python and imports sysconfig, which is
relatively fast. As we can see, importing numpy also, is MUCH slower.
All I want is the include path; I shouldn't need to initialize all of
numpy to do that.


Thanks much. Hopefully we can find a nice way to satisfy everybody