Bug#1035064: software-proper: Re: software-properties-qt: First tab labeled 'Ubuntu Software'

[Neal]

Package: software-properties-qt
Version: 0.99.30-4
Followup-For: Bug #1035064
X-Debbugs-Cc: nealheine...@gmail.com

Dear Maintainer,

This bug still exists in new install of Trixie Plasma.


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

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

Versions of packages software-properties-qt depends on:
ii  debconf-kde-helper   1.1.0-1+b1
ii  python3  3.11.6-1
ii  python3-pyqt55.15.10+dfsg-1
ii  python3-software-properties  0.99.30-4
ii  software-properties-common   0.99.30-4

software-properties-qt recommends no packages.

Versions of packages software-properties-qt suggests:
ii  plasma-discover  5.27.10.1-1

-- no debconf information

Bug#1063491: python3-jedi: unvendoring python3-typeshed breaks other packages

[Daniel Vacek]

Package: python3-jedi
Followup-For: Bug #1063491
X-Debbugs-Cc: neel...@gmail.com

The 0.19.1+ds1-1 still depends on python3-typeshed. Is that correct?

--nX


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

Kernel: Linux 6.6.8-rt-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FORCED_MODULE, 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)
LSM: AppArmor: enabled

Versions of packages python3-jedi depends on:
ii  python33.11.6-1
ii  python3-parso  0.8.3-1

python3-jedi recommends no packages.

python3-jedi suggests no packages.

-- no debconf information

Bug#1063185: readpe: NMU diff for 64-bit time_t transition

[Steve Langasek]

Hi David,

On Sun, Feb 11, 2024 at 01:37:53AM -0300, David da Silva Polverari wrote:
> First of all, thanks for your report and for the work on the transition!

> After having a look at [1] and [2], I found the only reported problem
> was due to the usage of a pointer to the pe_ctx structure (typedef'ed as
> pe_ctx_t) [3] as the first parameter of the exported functions from
> libpe, as its map_size field is of type off_t ("Base type has been
> changed from long to long long. Recompilation of a client program may be
> broken.").

> The output of `apt rdepends libpe1` shows that only the binaries built
> by readpe depend on it. Besides, within readpe itself, there is only one
> mention to accessing the map_size field directly outside of libpe, and
> it is commented out [4].

> That said, I am not sure that including readpe in the transition will be
> necessary, but maybe I have overlooked something. But I thought I should
> add this information here.

Note that the libpe1 reverse-dependency, readpe, does not have a strict
versioned dependency on libpe1 but instead gets its dependency from shlibs. 
So a partial upgrade, for whatever reason, of readpe without libpe1 or
libpe1 without readpe could still cause ABI skew and possible crashes.

However, readpe is also a new package to the Debian archive, having only
been around since September; so upgrades from stable releases are not an
issue and third-party packages are likely an ignorable concern.

If you are maintainer are happy to take responsibility for the (unlikely)
crashes that may occur in the partial upgrade case, then it's fine for you
to close this bug, in which case we will not NMU to unstable.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1037914: cloud-initramfs-growroot: missing dependencies in initramfs

[Tiago Ilieve]

Control: tags -1 patch

Hi,

I've managed to reproduce the original report after adding 'debug' to the
kernel command line and checking "/run/initramfs/initramfs.debug"[1].

A patch was sent to the "cloud-team/cloud-initramfs-tools" Salsa repository[2].

Regards,
Tiago.

[1]: https://wiki.debian.org/InitramfsDebug#Saving_debug_information
[2]: 
https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/8

--
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://www.linkedin.com/in/myhro/
Montes Claros, Brazil

Bug#1014625: xterm: screen corruption of scrollback buffer

[Tim Connors]

On Sat, 9 Jul 2022, Thomas Dickey wrote:

> On Sat, Jul 09, 2022 at 02:39:41PM +1000, Tim Connors wrote:
> > This has happened ever since I changed my hardware -- mostly updating
> > my video card to a radeon RX570 -- necessitating new versions of some
> > drivers and kernel.  While I would happily accept that the video card
> > might have some dodgy memory (note to self: find a GPU memory stress
> > tester), this corruption has not affected any other program other than
> > xterm's scrollback buffer, so I wonder if it's a bug instead.
> >
> > Screengrabs of the symptom:
> >
> > https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption.png
> > https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption2.png
> >
> > radeon amdgpu drivers and firmware are the latest version allowed by
> > otherwise being on debian stable - ie,
>
> It looks like the problem is in the drivers (not xterm).
>
> That could be defective implementation of XCopyArea, for instance.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=110214

For those following along at home, for debian bullseye, the solution was
simply to downgrade back to (old)stable's kernels, but alas that is no
longer a solution for debian bookworm - the framebuffer bug is still there
in 6.1 and 6.5 kernels.

However, one of those bugs somewhere hinted about using xcompmgr.  Running
that in fvwm has solved my problem (as well as solving excessive CPU
usage in mozilla related to it wanting to continually update windows that
aren't actually in view).  No apparent sideeffects at all, which seems
rather strange for something coming out of the shiny new world.

I have no idea how xcompmgr fixes this, but it fixes the screen artefacts
in xterm nevertheless!

-- 
Tim Connors

Bug#1064036: dpkg: wrong dpkg-query exit status on syntax error?

[Christoph Anton Mitterer]

Hey Guillem.

On Fri, 2024-02-16 at 05:26 +0100, Guillem Jover wrote:
> 
> Thanks!

Well rather: thank you, for your constant efforts to DPKG and the whole
ecosystem.


> > At least it seems to make it impossible to definitely find out
> > whether a package
> > is not installed (respectively not existant).
> 
> Exactly.

Maybe it would also be worth to elaborate on:
   1   The  requested  query  failed  either fully or partially, due to no
   file  or  package   being   found   (except   for   --control-path,
   --control-list and --control-show were such errors are fatal).

My understanding would have been, that e.g. when searching for a
package, 1 would in practise mean that it doesn't exist at all (when
looking from APT’s PoV) respectively is in the state 'not-installed'.

So I guess for end-users it might be helpful to be told that, i.e. that
these two things (non-existing from APT) and non-installed are the same
from DPKG’s PoV, and would trigger 1.

Also perhaps notifying somewhere that 'not-installed' will never really
show up anywhere as a printed query result.



> This is used for field names, be them real or virtual, so erroring
> out
> on fields that do not exist would seem bad. But there's the
> distinction between the real fields and virtual ones, where the
> latter
> always contain a colon. So I guess I could make the latter, at least
> warn if they do not exist. My main concern with making them errors,
> is
> that this would break backwards and/or forwards compatibility, where
> you could not use a new or renamed field with old or new releases.

Warnings are at last difficult to use when scripting.

And btw: it also succeeds if there's no colon, e.g.:
$ dpkg-query --showformat='${foobar}' --show  2>/dev/null ; echo $?
0


Thanks,
Chris.

PS: In the dpkg-query manpage, there's:
   Desired action:

   u = Unknown
   i = Install
   h = Hold
   r = Remove
   p = Purge

   Package status:

   n = Not-installed
   c = Config-files
   H = Half-installed
   U = Unpacked
   F = Half-configured
   W = Triggers-awaiting
   t = Triggers-pending
   i = Installed

   Error flags:

= (none)
   R = Reinst-required

I think, when these are actually printed, the full names are all
lowercase, i.e. installed not Installed ... might perhaps make sense to
align that?

Bug#1064036: dpkg: wrong dpkg-query exit status on syntax error?

[Guillem Jover]

Hi!

On Fri, 2024-02-16 at 04:37:47 +0100, Christoph Anton Mitterer wrote:
> Package: dpkg
> Version: 1.22.4
> Severity: normal

> dpkg-query manpage says:
> EXIT STATUS
>0   The requested query was successfully performed.
> 
>1   The  requested  query  failed  either fully or partially, due to no
>file  or  package   being   found   (except   for   --control-path,
>--control-list and --control-show were such errors are fatal).
> 
>2   Fatal  or unrecoverable error due to invalid command-line usage, or
>interactions with the system, such as  accesses  to  the  database,
>memory allocations, etc.

> E.g.:
>  $ dpkg-query --showformat='${db:Status-Status}' --show --list 2>/dev/null ; 
> echo $?
>  2
> looks good, as does
>  $ dpkg-query --showformat='${db:Status-Status}' --show not-existing-package 
> 2>/dev/null ; echo $?
>  1
> 
> But e.g.
>  $ dpkg-query --showformat='${db:Status-Statu' --show  2>/dev/null ; echo $?
>  1
> causes also 1, though it fails because of the syntax error in the format 
> string.
> 
> Shouldn't that be a 2?

Yeah, I think so. I've looked into this now, and there are several
problems in the dpkg-query code, one is that several of the action
functions only ever return 1 for any direct failure they handle, the
other is that even if they returned something else, the main()
function coerces that return code into a boolean, so it always ends
up being 0 or 1. I'll have a pass over the entire code, and correct
all instances and queue this for the next upload. Thanks!

> At least it seems to make it impossible to definitely find out whether a 
> package
> is not installed (respectively not existant).

Exactly.

> btw. it will also not fail at all in cases like:
>  $ dpkg-query --showformat='${db:Status-Statu}' --show  2>/dev/null ; echo $?
>  0
> where the field doesn't exist. Not sure whether that’s desired or not

This is used for field names, be them real or virtual, so erroring out
on fields that do not exist would seem bad. But there's the
distinction between the real fields and virtual ones, where the latter
always contain a colon. So I guess I could make the latter, at least
warn if they do not exist. My main concern with making them errors, is
that this would break backwards and/or forwards compatibility, where
you could not use a new or renamed field with old or new releases.

Thanks,
Guillem

Bug#1064036: dpkg: wrong dpkg-query exit status on syntax error?

[Christoph Anton Mitterer]

Package: dpkg
Version: 1.22.4
Severity: normal

Hey.

dpkg-query manpage says:
EXIT STATUS
   0   The requested query was successfully performed.

   1   The  requested  query  failed  either fully or partially, due to no
   file  or  package   being   found   (except   for   --control-path,
   --control-list and --control-show were such errors are fatal).

   2   Fatal  or unrecoverable error due to invalid command-line usage, or
   interactions with the system, such as  accesses  to  the  database,
   memory allocations, etc.

E.g.:
 $ dpkg-query --showformat='${db:Status-Status}' --show --list 2>/dev/null ; 
echo $?
 2
looks good, as does
 $ dpkg-query --showformat='${db:Status-Status}' --show not-existing-package 
2>/dev/null ; echo $?
 1

But e.g.
 $ dpkg-query --showformat='${db:Status-Statu' --show  2>/dev/null ; echo $?
 1
causes also 1, though it fails because of the syntax error in the format string.

Shouldn't that be a 2?


At least it seems to make it impossible to definitely find out whether a package
is not installed (respectively not existant).


btw. it will also not fail at all in cases like:
 $ dpkg-query --showformat='${db:Status-Statu}' --show  2>/dev/null ; echo $?
 0
where the field doesn't exist. Not sure whether that’s desired or not


Cheers,
Chris.


-- Package-specific info:

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

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.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 dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b2
ii  libc62.37-15
ii  liblzma5 5.4.5-0.3
ii  libmd0   1.1.0-2
ii  libselinux1  3.5-2
ii  libzstd1 1.5.5+dfsg2-2
ii  tar  1.35+dfsg-3
ii  zlib1g   1:1.3.dfsg-3+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.7.11
ii  debsig-verify  0.29

-- no debconf information

Bug#1057536: tiles-autotag: FTBFS with default Java 21

[Vladimir Petko]

Hi,

The issue is caused by the outdated version of the byte-buddy. Upgrading it
to 1.14 should solve the issue.
The issue can be worked around by adding -Dnet.bytebuddy.experimental=true
to the argLine in maven-surefire-plugin.
This is the same issue as[1].

 Best Regards,
  Vladimir.

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

Bug#1057533: qpid-proton-j-extensions: FTBFS with default Java 21

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this issue?

Best Regards,
 Vladimir.

 [1] 
https://salsa.debian.org/java-team/qpid-proton-j-extensions/-/merge_requests/1

Bug#1062442: python3-trezor: electrum wants to use python3-trezor version 0.13.0 <= x < 0.14

[Soren Stoutner]

Control: affects -1 + python3-electrum

-- 
Soren Stoutner
so...@debian.org

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

Bug#1063925: victoriametrics: Occasional FTBFS: VictoriaMetrics/lib/storage/inmemory_part.go:37 BUG: Inmemory.InitFromRows must accept at least one row

[Mathias Gibbens]

Hi Denys,

On Thu, 2024-02-15 at 08:22 +0200, Denys Holius wrote:
> This version is an old and not supported version deprecated six month ago.
> I belive this bug has been fixed in the newest versions of VictoriaMetrics.
> Please see https://victoriametrics.com/blog/lts-status-h2-2023/  to find
> the actual list of supported versions.

  Yes, the version in Debian unstable is currently out of date.
Typically it's up to the interested party(ies) to update packages -- in
this case, it looks like Guillem Jover. Eventually a newer version will
be uploaded.

Mathias


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

Bug#1064035: Missing documentation due to error in kernel-doc script

[Ben Hutchings]

Package: linux-doc-5.10
Version: 5.10.209-1
Severity: important

The backport of commit 3080ea5553cc "stddef: Introduce
DECLARE_FLEX_ARRAY() helper" modified scripts/kernel-doc and
introduced a syntax error:

Global symbol "$args" requires explicit package name (did you forget to declare 
"my $args"?) at ./scripts/kernel-doc line 1236.
Global symbol "$args" requires explicit package name (did you forget to declare 
"my $args"?) at ./scripts/kernel-doc line 1236.
Execution of ./scripts/kernel-doc aborted due to compilation errors.

This doesn't stop the documentation build process, but causes the
documentation that should be extracted by kernel-doc to be missing
from linux-doc-5.10.

We should be able to fix this by eithering backport commit
e86bdb24375a "scripts: kernel-doc: reduce repeated regex expressions
into variables" or replacing /$args/ with /([^,)]+)/.

Ben.

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

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

Bug#1057529: Additional Information

[Vladimir Petko]

Dear Maintainers,

 Would it be possible to consider Pushkar's MP [1] that resolves the issue?

Best Regards,
 Vladimir.

[1] https://salsa.debian.org/java-team/opencensus-java/-/merge_requests/2

Bug#848865: vinagre: Writes to syslog every second with message: Drawing a gadget with negative dimensions

[Patrick Plenefisch]

This is still an issue in debian 12 and still filling up my logs,
making journalctl somewhat hard to use.

Note that a workaround is to run it manually and redirect stderr to /dev/null:

edit /usr/share/applications/vinagre.desktop

and change this line:

Exec=vinagre %U 2>/dev/null

Bug#1064034: FTBFS: Expired test certificate

[Ángel]

Package: ruby3.1
Version: 3.1.2-8
Severity: serious
Tags: ftbfs

A build of ruby3.1 fails on the test stage, since multiple
test/net/http/test_https.rb tests return 

> "ERROR OpenSSL::SSL::SSLError: SSL_accept returned=1 errno=0
peeraddr=(null) state=error: sslv3 alert certificate expired\n"

where no error was expected.


Failing tests:
TestNetHTTPS#test_get, TestNetHTTPS#test_skip_hostname_verification,
TestNetHTTPS#test_skip_hostname_verification, TestNetHTTPS#test_post,
TestNetHTTPS#test_min_version, TestNetHTTPS#test_get_SNI,
TestNetHTTPS#test_get, TestNetHTTPS#test_post,
TestNetHTTPS#test_min_version, TestNetHTTPS#test_get_SNI


The actual reason is that the certificate it uses (file
test/net/fixtures/server.crt) *IS* expired:

$ openssl x509 -in test/net/fixtures/server.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = JP, ST = Shimane, L = Matz-e city, O = Ruby Core Team, CN = 
Ruby Test CA, emailAddress = secur...@ruby-lang.org
Validity
Not Before: Jan  2 03:27:13 2019 GMT
Not After : Jan  1 03:27:13 2024 GMT
Subject: C = JP, ST = Shimane, O = Ruby Core Team, OU = Ruby Test, CN = 
localhost


This was fixed upstream on 
https://github.com/ruby/ruby/commit/d3933fc753187a055a4904af82f5f3794c88c416

Bug#1055092: hashbrown/indexmap status update

[Peter Green]

I've finally finished working through the rdeps of rust-hashbrown and 
rust-indexmap,
damn that took a while. Hopefully we are not far off being ready to upload, 
mostly
waiting for a response from jonas on the wasmtime bug at this point.


btm:
jonas package, no changes needed for this update, though currently FTBFS for 
unrelated reasons.

loupe
gnome team package, patch needs dropping, bug filed, Matthias has said he will 
deal with it.

precious
jonas package, package in unstable is ready for the hashbrown/indexmap update

python-maturin
python team package, bug filed with patch

rust-ahash:
joanas package, package in unstable is ready for the hashbrown/indexmap update

rust-carapace-spec-clap:
package in unstable is ready for the hashbrown/indexmap update

rust-cargo
fix prepared but not uploaded.

rust-cbindgen
package in unstable is ready for the hashbrown/indexmap update

rust-chumsky
update uploaded to experimental, autopkgtests currently skipped.

rust-clap-3:
package in unstable is ready for the hashbrown/indexmap update

rust-configparser:
package in unstable is ready for the hashbrown/indexmap update

rust-cookie-store:
package in unstable is ready for the hashbrown/indexmap update

rust-dashmap
update uploaded to experimental

rust-elsa
fix prepared but not uploaded.

rust-gimli
package in unstable is ready for the hashbrown/indexmap update

rust-h2
fix uploaded to unstable

rust-hashlink
fix prepared in debcargo-conf but not uploaded.

rust-imara-diff
fix prepared in debcargo-conf but not uploaded.

rust-laurel:
package in unstable is ready for the hashbrown/indexmap update

rust-lru:
package in unstable is ready for the hashbrown/indexmap update

rust-minijinja
broken and not in testing.

rust-no-std-compat
fix prepared but not uploaded

rust-object
package in unstable is ready for the hashbrown/indexmap update

rust-ordered-multimap:
fix prepared in debcargo-conf but not uploaded.

rust-petgraph
package in unstable is ready for the hashbrown/indexmap update

rust-publicsuffix
package in unstable is ready for the hashbrown/indexmap update

rust-plist
fix prepared in debcargo-conf but not uploaded.

rust-pyo3
package in unstable is ready for the hashbrown/indexmap update

rust-pyproject-toml
package in unstable is ready for the hashbrown/indexmap update

rust-quick-junit
fix prepared in debcargo-conf but not uploaded.

rust-regalloc2
jonas package, package in unstable is ready for the hashbrown/indexmap update

rust-rkyv
package in unstable is ready for the hashbrown/indexmap update

rust-ron
fix prepared in debcargo-conf but not uploaded.

rust-rowan
fix prepared in debcargo-conf but not uploaded.

rust-ruma-common
fix prepared in debcargo-conf but not uploaded.

rust-schemars
fix uploaded to experimental

rust-scraper
broken and not in testing

rust-sequoia-chameleon-gnupg
fix prepared in debcargo-conf but not uploaded.

rust-serde-json
package in unstable is ready for the hashbrown/indexmap update

rust-serde-with
fix prepared in debcargo-conf but not uploaded.
note: rust-serde-with-macros needs uploading at the same time.

rust-serde-yaml
package in unstable is ready for the hashbrown/indexmap update

rust-sqlx-core
package in unstable is ready for the hashbrown/indexmap update

rust-tokio-util
package in unstable is ready for the hashbrown/indexmap update

rust-toml
package in unstable is ready for the hashbrown/indexmap update

rust-toml-0.5
package in unstable is ready for the hashbrown/indexmap update

rust-toml-edit
package in unstable is ready for the hashbrown/indexmap update

rust-tre-command
fix prepared in debcargo-conf but not uploaded.

rust-tower
fix prepared in debcargo-conf but not uploaded.

rust-tree-sitter-cli
package in unstable is ready for the hashbrown/indexmap update

rust-unicode-linebreak
package in unstable is ready for the hashbrown/indexmap update

rust-wasmtime
jonas package, bug filed.

Bug#1064033: ITP: asn -- network OSINT CLI ASN, RPKI, BGP, Geo, Recon, Trace

[Marcos Rodrigues de Carvalho (aka oday)]

Package: wnpp
Severity: wishlist
Owner: "Marcos Rodrigues de Carvalho (aka oday)" 
X-Debbugs-Cc: debian-de...@lists.debian.org, marcosrcarvalh...@gmail.com

* Package name: asn
  Version : 0.75.3
  Upstream Contact: Adriano nitefood
* URL : https://github.com/nitefood/asn/
* License : Expat
  Programming Lang: shell script
  Description : network OSINT CLI ASN, RPKI, BGP, Geo, Recon, Trace

 provides in-depth network analysis, including ASN, RPKI, BGP, IP geolocation,
 and network reconnaissance. It supports incident investigation and offers IP
 tracing and lookup capabilities. It enables quick and efficient queries for
 understanding and decision-making in cybersecurity environments.
 .
 this tool in summary does:
  - ASN: Identifies Autonomous System Numbers
  - RPKI validity: Validates route announcements
  - BGP stats: Provides statistics on Border Gateway Protocol
  - IPv4v6 Prefix: Deals with IP address prefixes
  - ASPath: Tracks the path of Autonomous Systems
  - Organization: Identifies the organization owning an IP address
  - IP reputation: Assesses the reputation of an IP address
  - IP geolocation: Determines the geographical location of an IP address
  - IP fingerprinting: Identifies unique characteristics of an IP address
  - Network recon: Conducts reconnaissance on a network
  - Lookup tool: Searches for information about IP addresses
  - Web traceroute server: Traces the path of data packets over the Internet

Bug#1064032: pulseaudio: Audio not playing over HDMI

[Neal]

Package: pulseaudio
Version: 16.1+dfsg1-3
Severity: important
X-Debbugs-Cc: nealheine...@gmail.com

Dear Maintainer,

When connecting my TV to my laptop via HDMI sound still plays from laptop.
HDMI is not an option in plasma nor pavucontrol.

I moved to testing to try to fix this and did a fresh install of testing 
neither worked.
The same setup works fine in win 10 (laptop, HDMI, TV)
I've also tested the experimental version of pulse audio with no luck.

Thank you for your help on this!


$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: PCH [HDA Intel PCH], device 0: ALC3254 Analog [ALC3254 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser 3.137
ii  init-system-helpers 1.66
ii  libasound2  1.2.10-3
ii  libasound2-plugins  1.2.7.1-1+b1
ii  libc6   2.37-15
ii  libcap2 1:2.66-5
ii  libdbus-1-3 1.14.10-4
ii  libfftw3-single33.3.10-1+b1
ii  libgcc-s1   14-20240201-3
ii  libglib2.0-02.78.3-2
ii  libgstreamer-plugins-base1.0-0  1.22.9-1
ii  libgstreamer1.0-0   1.22.9-1+b1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-7
ii  liborc-0.4-01:0.4.34-3
ii  libpulse0   16.1+dfsg1-3
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.2.2-1
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.1-1+b1
ii  libstdc++6  14-20240201-3
ii  libsystemd0 255.3-2
ii  libtdb1 1.4.10-1
ii  libudev1255.3-2
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libwrap07.6.q-32+b1
ii  libx11-62:1.8.7-1
ii  libx11-xcb1 2:1.8.7-1
ii  libxcb1 1.15-1
ii  libxtst62:1.2.3-1.1
ii  pulseaudio-utils16.1+dfsg1-3
ii  sysvinit-utils [lsb-base]   3.08-6

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.10-4
ii  libpam-systemd [logind]  255.3-2
ii  rtkit0.13-5

Versions of packages pulseaudio suggests:
pn  paprefs  
pn  pavucontrol  
pn  pavumeter
ii  udev 255.3-2

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have 

Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

[Steve Langasek]

Control: forwarded -1 seli...@vger.kernel.org

Patch now forwarded upstream for review.

https://lore.kernel.org/selinux/zc6tzkpsyzric...@homer.dodds.net/T/#t



On Wed, Feb 14, 2024 at 11:25:26PM -0800, Steve Langasek wrote:
> On Wed, Feb 07, 2024 at 09:06:58AM +0100, Helmut Grohne wrote:
> > On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> > > Yes, I'm not sure I understand either. This is what symbol versioning
> > > makes possible, even providing different variants for the same symbol,
> > > see for example glibc or libbsd.
> 
> > I think symbol versioning is subtly different and glibc does not use
> > symbol versioning for e.g. gettimeofday selection. With symbol
> > versioning, you select a default version at release time and stick to
> > it. In other words, building against the updated libselinux does not
> > allow you to use the older 32bit variant of the symbol even if you opt
> > out of lfs and time64 and you always get the 64bit symbol. What glibc
> > does is a little more fancy than my simplistic #define in that it uses
> > asm("name") instead. Still this approach allows for selecting which
> > symbol is being used via macros (e.g. _FILE_OFFSET_BITS). Please correct
> > me if I am misrepresenting this as my experience with symbol versioning
> > is fairly limited.
> 
> Agreed.  libselinux as it happens does use a symbol version map so there is
> symbol versioning involved in some sense? but not the sense you really mean.
> 
> (We could make the symbol map expose the two different function variants
> under the same name but different symbols; that's fine but I'll leave that
> for upstream to decide.)
> 
> > > In any case, if going the bi-ABI path, I think upstream should get
> > > involved, and the shape of this decided with them. In addition
> > > the library should also be built with LFS by the upstream build
> > > system, which it does not currently, to control its ABI.
> 
> > I agree that involving upstream is a good idea and my understanding is
> > that someone from Canonical is doing that already, which is why the
> > schedule was delayed.
> 
> Well, "already" is not exactly correct, but the need to resolve this
> critical showstopper bug in libselinux before making changes to the
> toolchain behavior in unstable and breaking the world has affected the
> timeline, yes.
> 
> I now have a tested patch that I've raised as an MP in salsa:
> 
>   https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/9
> 
> I welcome review from the Debian libselinux maintainers prior to opening a
> discussion with upstream.  (Which I will plan to do sometime Thursday
> US/Pacific)
> 
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1029701: scikit-learn: tests fail with scipy 1.10

[Drew Parsons]

Source: scikit-learn
Version: 1.2.1+dfsg-1
Followup-For: Bug #1029701
Control: severity 1029701 serious

scipy 1.11 is now uploaded to unstable,
so bumping this bug severity to serious.

Bug#1063527: einsteinpy: test_plotting fails to converge with scipy 1.11

[Drew Parsons]

Control: severity 1063527 serious

scipy 1.11 is now uploaded to unstable, so bumping this bug severity to 
serious

Bug#1064031: chromium and rustc in bookworm

[Andres Salomon]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

Chromium now requires a Rust compiler to build, and it specifically 
needs a rustc with profiler support built into it. This package can 
hopefully be shared with firefox and other browser/web engines that end 
up needing a newer rustc.


[ Reason ]
Chromium 121 started removing C++ code in favor of Rust. For 121 in 
bookworm we reverted that patch, but that's not a long-term solution as 
more C++ code gets replaced with Rust code.


Chromium requires a Rust compiler with profiler support built into it, 
which was only added in rustc 1.70.0+dfsg1-3 (see #1043311). Since 
bookworm's rustc lacks this, we need a backport. We don't want to risk 
breaking existing Rust packages in bookworm by backporting the profiler 
patches to 1.63, so instead we'll do something similar to what firefox 
did in the past with rustc-mozilla and backport a newer rustc. Note the 
name "rustc-web" breaks with the traditional rustc-mozilla naming, since 
it's not really mozilla-specific any more.


As mentioned below in the mailing list thread, the firefox maintainer 
isn't certain if 1.70 will be new enough for firefox-esr 128; however, 
if a newer rustc is needed, they can update this package and I will make 
sure the newer version continues to work with chromium.


[ Impact ]
There's no impact for bookworm users, as packages in stable must 
explicitly choose to build against rustc-web. The rustc-web and 
libstd-rust-web-dev packages have appropriate conflicts/replaces to 
ensure there's no accidental installation with bookworm's existing rustc 
packages.


[ Tests ]
Chromium 121.0.6167.160-1~deb12u1 succeeds in building and running on 
bookworm with this rustc-web package.


[ Risks ]
Low/no risk.

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

[ Changes ]
Many of the changes were modeled after the older rustc-mozilla package 
from bullseye, but with some updates for the state of things in 
bookworm. As with rustc-mozilla, the bootstrap compilers are included in 
orig-stage0.tar.xz. Because I'd already backported llvm-toolchain-16 to 
bookworm, there was no need to modify rustc's llvm 16 dependencies.


The changelog entry:

rustc-web (1.70.0+dfsg1-7~deb12u1) bookworm; urgency=medium

  * Non-maintainer upload.
  * Rename rustc backport to rustc-web, intended to be used for browsers.
  * Generate & include bootstrap compilers via an orig-stage0.tar.xz.
  * Add mipsel bootstrap compiler back, as mipsel is still in bookworm.
  * Disable profiler on mipsel, as it likely doesn't work either.
  * Disable wasm.
  * Drop -all virtual package, which doesn't make sense for us.



I've included a diff against unstable's rustc (1.70.0+dfsg-7).

[ Other info ]
See d-release thread below.



On 2/13/24 19:32, Andres Salomon wrote:
Okay, so I've gotten rustc 1.70.0+dfsg-6 (the prior version needed some 
bootstrap fixes) built on bookworm, and managed to use it to build 
chromium as well. Unfortunately -6 isn't building on mips64el, but I 
strongly suspect that this is something that won't happen in bookworm.


I'm going to name the package rustc-web, and I'll send a patch for 
review hopefully tomorrow. Chromium 122's planned for release on Feb 
20th, and I haven't yet checked if they've removed more C++ code in 
favor of Rust.



On 1/22/24 21:22, Timothy Pearson wrote:



- Original Message -

From: "Andres Salomon" 
To: "Adrian Bunk" , debian-rele...@lists.debian.org, 
pkg-rust-maintain...@alioth-lists.debian.net,
debian@fabian.gruenbichler.email, infini...@debian.org, 
sylves...@debian.org

Cc: "Timothy Pearson" 
Sent: Monday, January 22, 2024 8:17:15 PM
Subject: Re: chromium and rustc in bookworm



On 1/22/24 15:34, Mike Hommey wrote:

On Mon, Jan 22, 2024 at 03:39:08AM +0200, Adrian Bunk wrote:

On Sun, Jan 21, 2024 at 06:55:31PM -0500, Andres Salomon wrote:

...

c) Much like the Firefox maintainer(s) created rustc-mozilla for
(old)oldstable, we create a 'rustc-chromium' package for bookworm. 
It could
even be used for Firefox if their ESR updates start needing newer 
Rust
language features (in which case, maybe 'rustc-newer' or 
'rustc-browsers' is
a better name for it? Or like Clang, include the major version and 
call it

'rustc-1.70').


As I'm still messing around with bookworm's rustc(+profiler) as 
well as
trying to get Chromium 121.x to build in Sid, I don't have a 
strong opinion
on this yet. However, I wanted to bring it to everyone's 
attention, and see
if anyone else did have strong opinions either way. If one of the 
teams
feels strongly against option (b) for example, I won't bother 
continuing to

work on that option.


IMHO c) would be best, with one rustc-* package shared for both 
browsers.


AFAIK rustc 1.78 (to be 

Bug#1051551: thunderbird: When deleting a message, the list scrolls up a few messages.

[Alejandro Colomar]

Hi James!

On Thu, Feb 15, 2024 at 11:09:48PM +, James Addison wrote:
> Package: thunderbird
> Followup-For: Bug #1051551
> X-Debbugs-Cc: alx.manpa...@gmail.com, c.schoen...@t-online.de
> 
> On Sat, 09 Sep 2023 19:16:32 +0200, Alex wrote:
> > Since some recent version, every time I delete a mail, the list scrolls
> > up a few messages, and I need to manually scroll down again, every time.
> 
> I'm not 100% certain, so not setting a forwarded-to on this bug yet, but this
> sounds a lot like this upstream bug: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1857766
> 
> Does the description on that bugreport match the behaviour you found, Alex?

Hmmm, it could be; I'm not 100% sure either.  I moved to using mutt(1)
soon after reporting that bug, so I have forgotten some details.  Sorry.

> (someone also mentioned a vaguely-similar-sounding issue on debian-user
> yesterday, which is why I'm taking a brief look)

Thanks!

Have a lovely night,
Alex

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1064030: lcov: Please re-enable tests

[Sudip Mukherjee]

Source: lcov
Version: 2.0-3
Severity: wishlist
Tags: patch
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Dear Maintainer,

The tests during the build time have been disabled. But the tests are
failing due to parallel builds. I have raised a MR in salsa [1] with the
changes to disable parallel builds and to enable the tests.
A build can also be seen at [2].

[1] https://salsa.debian.org/mckinstry/lcov/-/merge_requests/2
[2] https://salsa.debian.org/sudip/lcov/-/jobs/5195976


-- 
Regards
Sudip

Bug#1063771: Please update to version 42, needed for new dnspython

[Scott Kitterman]

On Tue, 13 Feb 2024 18:30:42 -0500 Scott Kitterman  
wrote:
> On Tue, 13 Feb 2024 10:16:23 +0100 Jérémy Lal  wrote:
> > Will do, but right now there are a bunch of rust dependencies that need to
> > be upgraded.
> 
> Thanks,

I got a one release reprieve from the dnspython upstream, so I'm good with 
version 41, for now, but will definitely need 42 for the next release, which is 
nominally in a few months.

Appreciate your work on the package.

Scott K

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

Bug#1064029: bookworm-pu: package mailman3/3.3.8-2~deb12u2

[Pierre-Elliott Bécue]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: mailm...@packages.debian.org
Control: affects -1 + src:mailman3

Hi,

Some bugs affecting mailman3 are found in bookworm. I fixed these in
unstable but forgot to do a stable-pu.

[ Reason ]
Bug #1040708 is about a change in the way sqlalchemy reads postgresql
URIs. Historically the prefix in this URI was postgres. Now it's
postgresql. Therefore the default config for mailman3 is broken under
bookworm.
Bug #1038953 is about tracking cron-daemon instead of cron to allow more
flexibility should one wish to use something else than cron. It was
supposed to be done for some time.

[ Impact ]
The first one will force users to fix the config if they wish to work
with postgresql.

[ Tests ]
Installed fixed version works fine.

[ Risks ]
Changes are trivial.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable
diff -Nru mailman3-3.3.8/debian/changelog mailman3-3.3.8/debian/changelog
--- mailman3-3.3.8/debian/changelog 2023-06-23 01:03:08.0 +0200
+++ mailman3-3.3.8/debian/changelog 2024-02-15 23:59:26.0 +0100
@@ -1,3 +1,11 @@
+mailman3 (3.3.8-2~deb12u2) bookworm; urgency=medium
+
+  * bookworm-pu of two fixes
+- s/postgres/postgresql/ in config files
+- Add replacement dependency on cron to cron-daemon
+
+ -- Pierre-Elliott Bécue   Thu, 15 Feb 2024 23:59:26 +0100
+
 mailman3 (3.3.8-2~deb12u1) bookworm; urgency=medium
 
   * Bookworm-pu of 4 bug fixes
diff -Nru mailman3-3.3.8/debian/contrib/mailman.cfg.sample 
mailman3-3.3.8/debian/contrib/mailman.cfg.sample
--- mailman3-3.3.8/debian/contrib/mailman.cfg.sample2023-06-23 
01:03:08.0 +0200
+++ mailman3-3.3.8/debian/contrib/mailman.cfg.sample2024-02-15 
23:59:26.0 +0100
@@ -170,7 +170,7 @@
 # 'configuration' substitutions.
 url: sqlite:///$DATA_DIR/mailman.db
 #url: 
mysql+pymysql://mailman3:mmpass@localhost/mailman3?charset=utf8_unicode=1
-#url: postgres://mailman3:mmpass@localhost/mailman3
+#url: postgresql://mailman3:mmpass@localhost/mailman3
 
 debug: no
 
diff -Nru mailman3-3.3.8/debian/control mailman3-3.3.8/debian/control
--- mailman3-3.3.8/debian/control   2023-06-23 01:03:08.0 +0200
+++ mailman3-3.3.8/debian/control   2024-02-15 23:59:26.0 +0100
@@ -44,7 +44,7 @@
 Architecture: all
 Depends: dbconfig-sqlite3 | dbconfig-pgsql | dbconfig-mysql | 
dbconfig-no-thanks,
  logrotate,
- cron,
+ cron | cron-daemon,
  python3-falcon (>> 1.0.0),
  python3-psycopg2 | python3-pymysql,
  ucf,
diff -Nru mailman3-3.3.8/debian/mailman3.postinst 
mailman3-3.3.8/debian/mailman3.postinst
--- mailman3-3.3.8/debian/mailman3.postinst 2023-06-23 01:03:08.0 
+0200
+++ mailman3-3.3.8/debian/mailman3.postinst 2024-02-15 23:59:26.0 
+0100
@@ -52,7 +52,7 @@
 pgsql)
 sed -i -e 's|^#\?\s*\(class: 
mailman\.database\.postgresql\.PostgreSQLDatabase\)$|\1|' \
 $mailmancfg_new
-sed -i -e "s|^#\?\s*url: postgres://.*$|url: 
postgres://$dbc_dbuser:$dbc_dbpass@$dbc_dbserver/$dbc_dbname|" \
+sed -i -e "s|^#\?\s*url: postgresql://.*$|url: 
postgresql://$dbc_dbuser:$dbc_dbpass@$dbc_dbserver/$dbc_dbname|" \
 $mailmancfg_new
 ;;
 mysql)

Bug#1051551: thunderbird: When deleting a message, the list scrolls up a few messages.

[James Addison]

Package: thunderbird
Followup-For: Bug #1051551
X-Debbugs-Cc: alx.manpa...@gmail.com, c.schoen...@t-online.de

On Sat, 09 Sep 2023 19:16:32 +0200, Alex wrote:
> Since some recent version, every time I delete a mail, the list scrolls
> up a few messages, and I need to manually scroll down again, every time.

I'm not 100% certain, so not setting a forwarded-to on this bug yet, but this
sounds a lot like this upstream bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1857766

Does the description on that bugreport match the behaviour you found, Alex?

(someone also mentioned a vaguely-similar-sounding issue on debian-user
yesterday, which is why I'm taking a brief look)

Bug#915583: about html_static_path

[Holger Wansing]

Sean Whitton  wrote:
> On Fri 29 Dec 2023 at 07:08am +01, Stéphane Blondon wrote:
> 
> > Yes, html_static_path must be set but it's already the case in conf.py.in:
> > https://sources.debian.org/src/debian-policy/4.6.2.0/policy/conf.py.in/#L105
> >
> > I guess conf.py is generated from conf.py.in so we only need to keep
> > the current setup.
> 
> That line is commented out, though.  Are you saying it takes on its
> default value in that case?

I think it would be good to un-comment such lines which are needed, so it's 
clear without doubt, what is used and active.
Works fine here BTW.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064028: libpython3.12-dev: non-C90 headerfile code breaks -Werror=declaration-after-statement

[James Addison]

Package: libpython3.12-dev
Version: 3.12.1-2
Severity: minor
Tags: upstream newcomer

Dear Maintainer,

Some of the C code contained within the headerfiles from libpython3.12-dev
appears not to be compliant with C90 standards (examples: [1][2]).

This contributed to a build failure[3] for the onboard/1.4.1-5 package that is
currently part of the python3.12-add[4] transition.

Upstream has continued to accept pull requests / patches to update their code
to remain C90 compliant over the past few years (example: [5]).

Although I'm not initially attaching a patch here, I hope to do so within the
next week, unless someone else writes one before I do.

Regards,
James

[1] - https://sources.debian.org/src/python3.12/3.12.2-1/Include/Python.h/

[2] - 
https://sources.debian.org/src/python3.12/3.12.2-1/Include/cpython/longintrepr.h/

[3] - 
https://buildd.debian.org/status/fetch.php?pkg=onboard=amd64=1.4.1-5%2Bb8=1706626636=0

[4] - https://release.debian.org/transitions/html/python3.12-add.html

[5] - https://github.com/python/cpython/pull/92783

Bug#1063916: RFP: freenginx -- a fork of nginx maintained by Maxim Dounin and the development community

[Henrique de Moraes Holschuh]

Is there *any* point on packaging this nginx fork this early?

We don't yet know the bus factor (i.e. uptake of the fork, size of core team, 
etc) of this fork yet.  We don't know how the dynamics with the F5-controlled 
ngnix project will play out re. cross-merges, security issues (which are very 
likely to be the same for both projects for quite a while given the shared 
code), etc.

If nginx and freenginx diverge too much on functionality, it might make sense 
to have both in Debian.  If they do not, we more likely should stick with 
either one, but not both (and it is way too early to even guess which one would 
make sense to stick to)...

There are other potential issues as well, it is best to wait a couple months at 
the very least.

-- 
  Henrique de Moraes Holschuh 

Bug#1064027: RFS: mercurial-evolve/11.1.1-1

[Georges Racinet]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: andrew.shad...@collabora.co.uk, jcris...@debian.org

Dear uploaders,

I have pushed a new version 11.1.1-1 of the mercurial-evolve package to
https://salsa.debian.org/python-team/packages/mercurial-evolve

Note that the previous version, 10.5.3, does not work with
the current Mercurial version (6.6) in unstable.

Is anyone available to upload it to the archive?

Thank you so much,

Cc Andrew, who did the previous uploads, and Julien, who is the Mercurial
package maintainer.

G. Racinet.

Bug#1064026: minetest-data: Strings in french language are replaced by ""

[Mathieu Godlewski]

Package: minetest-data
Version: 5.6.1+dfsg+~1.9.0mt8+dfsg-2
Severity: important
Tags: l10n
X-Debbugs-Cc: mathieu.godlew...@gmail.com

Dear Maintainer,

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 6.1.0-rpi8-rpi-v8 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=ISO-8859-1) (ignored: 
LC_ALL set to fr_FR), LANGUAGE=fr_FR
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages minetest-data depends on:
ii  fonts-croscore20201225-1
ii  fonts-droid-fallback  1:6.0.1r16-1.1

minetest-data recommends no packages.

minetest-data suggests no packages.

-- no debconf information

Bug#1064025: ntpsec does not sync to server if "iburst" is missing

[Attila Kinali]

Package: ntpsec
Version: 1.2.2+dfsg1-4
Severity: important

I recently upgraded my machine and the old ntpd got replaced by ntpsec.
I have a fairly old (read decades old) ntp.conf that I carried over.
Because I ntpsec had a lot of changes in the config file, i opted to
use to overwrite my config with the package maintainer's config and
just replaced the sever line as I used to have: 

server myserver.localnet maxpoll 6

I also removed all other server lines as my local ntp server does all
the heavy lifting and all machines should sync to that. (also removing 
the "tos minsane 3" line)

Unfortunately, ntpsec refuses to sync to any server that does not have
"iburst" set in its options. It outright refuses to consider it. Just adding
iburst to the config, fixes this.

Considering that iburst should only affect ntpd's behaviour of sending
out packets when a server (re)appears, it is quite odd that it affects
the selection algorithm. Hence I consider this a bug.

Attila Kinali

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

Kernel: Linux 6.7.4 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ntpsec depends on:
ii  adduser  3.137
ii  init-system-helpers  1.66
ii  libbsd0  0.11.7-4
ii  libc62.37-12
ii  libcap2  1:2.66-4
ii  libssl3  3.1.4-2
ii  netbase  6.4
ii  python3  3.11.4-5+b1
ii  python3-ntp  1.2.2+dfsg1-4
ii  tzdata   2023c-11

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-181

Versions of packages ntpsec suggests:
ii  apparmor   3.0.12-1+b1
pn  certbot
pn  ntpsec-doc 
pn  ntpsec-ntpviz  

-- Configuration Files:
/etc/NetworkManager/dispatcher.d/ntpsec [Errno 2] No such file or directory: 
'/etc/NetworkManager/dispatcher.d/ntpsec'
/etc/ntpsec/ntp.conf changed [not included]

-- no debconf information

Bug#1064018: [PATCH] #1064018: Enable testsuite

[Plasma (David Paul)]

Control: tags 1064018 + patch

Dear Maintainer,

Attached is a debdiff patch which fixes #1064018.

Questions/comments welcome.

Thanks,

-- 
Plasma
diff -Nru libcbor-0.10.2/debian/changelog libcbor-0.10.2/debian/changelog
--- libcbor-0.10.2/debian/changelog	2023-10-05 01:47:27.0 -0500
+++ libcbor-0.10.2/debian/changelog	2024-02-12 23:12:22.0 -0600
@@ -1,3 +1,16 @@
+libcbor (0.10.2-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/Fix-non-standard-testing.patch:
+Enable testing by default and toggle testing based on
+BUILD_TESTING CMake variable. (Closes: 1064018)
+  * d/control: Build-Depend-Arch on debhelper (>= 13.12~) when 
+build profile is active because the BUILD_TESTING CMake variable is
+automatically set to OFF for nocheck builds starting with
+debhelper 13.12.
+
+ -- Plasma (David Paul)   Thu, 15 Feb 2024 20:46:41 -0600
+
 libcbor (0.10.2-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libcbor-0.10.2/debian/control libcbor-0.10.2/debian/control
--- libcbor-0.10.2/debian/control	2023-10-05 01:47:27.0 -0500
+++ libcbor-0.10.2/debian/control	2024-02-12 23:11:57.0 -0600
@@ -3,6 +3,7 @@
 Maintainer: Vincent Bernat 
 Build-Depends: debhelper-compat (= 13),
 Build-Depends-Arch: cmake,
+debhelper (>= 13.12~) ,
 libcmocka-dev ,
 Build-Depends-Indep: dh-sequence-sphinxdoc,
  doxygen,
--- libcbor-0.10.2/debian/patches/Fix-non-standard-testing.patch	1969-12-31 18:00:00.0 -0600
+++ libcbor-0.10.2/debian/patches/Fix-non-standard-testing.patch	2024-02-12 23:12:22.0 -0600
@@ -0,0 +1,52 @@
+Description: Use idiomatic CMake to control testsuite execution.
+ Rather than creating and relying upon a WITH_TESTS variable in the top-level
+ CMakeLists.txt file, instead make use of the BUILD_TESTING variable defined
+ by the included CTest module. Also remove the enable_testing() command
+ invocation in CMakeLists.txt and instead rely on the one in the CTest module
+ which gets run whenever the BUILD_TESTING variable is not set to OFF.
+Author: Plasma (David Paul) 
+Bug-Debian: https://bugs.debian.org/1064018
+Forwarded: no
+Last-Update: 2024-02-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: libcbor-0.10.2/CMakeLists.txt
+===
+--- libcbor-0.10.2.orig/CMakeLists.txt
 libcbor-0.10.2/CMakeLists.txt
+@@ -29,11 +29,6 @@ option(CBOR_PRETTY_PRINTER "Include a pr
+ set(CBOR_BUFFER_GROWTH "2" CACHE STRING "Factor for buffer growth & shrinking")
+ set(CBOR_MAX_STACK_SIZE "2048" CACHE STRING "maximum size for decoding context stack")
+ 
+-option(WITH_TESTS "[TEST] Build unit tests (requires CMocka)" OFF)
+-if(WITH_TESTS)
+-add_definitions(-DWITH_TESTS)
+-endif(WITH_TESTS)
+-
+ option(WITH_EXAMPLES "Build examples" ON)
+ 
+ option(HUGE_FUZZ "[TEST] Fuzz through 8GB of data in the test. Do not use with memory instrumentation!" OFF)
+@@ -97,8 +92,6 @@ else()
+ add_definitions(-DEIGHT_BYTE_SIZE_T)
+ endif()
+ 
+-enable_testing()
+-
+ set(CTEST_MEMORYCHECK_COMMAND "/usr/bin/valgrind")
+ set(MEMORYCHECK_COMMAND_OPTIONS "--tool=memcheck --track-origins=yes --leak-check=full --error-exitcode=1")
+ 
+@@ -168,12 +161,12 @@ if(use_lto)
+ set_property(DIRECTORY src PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
+ endif(use_lto)
+ 
+-if (WITH_TESTS)
++if (BUILD_TESTING)
+ add_subdirectory(test)
+ if(use_lto)
+ set_property(DIRECTORY test PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
+ endif(use_lto)
+-endif (WITH_TESTS)
++endif (BUILD_TESTING)
+ 
+ if (WITH_EXAMPLES)
+ add_subdirectory(examples)
--- libcbor-0.10.2/debian/patches/series	1969-12-31 18:00:00.0 -0600
+++ libcbor-0.10.2/debian/patches/series	2024-02-11 16:49:18.0 -0600
@@ -0,0 +1 @@
+Fix-non-standard-testing.patch

Bug#1064024: juce: FTBFS on mips64el: Failed to build juceaide

[Sebastian Ramacher]

Source: juce
Version: 7.0.5+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=juce=mips64el=7.0.5%2Bds-1%2Bb1=1707563052=0

CMake Error at extras/Build/juceaide/CMakeLists.txt:142 (message):
  Failed to build juceaide

  gmake[2]: Entering directory
  '/<>/obj-mips64el-linux-gnuabi64/tools'

  gmake[3]: Entering directory
  '/<>/obj-mips64el-linux-gnuabi64/tools'

  gmake[4]: Entering directory
  '/<>/obj-mips64el-linux-gnuabi64/tools'

  gmake[4]: Leaving directory
  '/<>/obj-mips64el-linux-gnuabi64/tools'

  gmake[4]: Entering directory
  '/<>/obj-mips64el-linux-gnuabi64/tools'

  [ 10%] Building CXX object
  
CMakeFiles/juce_lv2_helper.dir/modules/juce_audio_plugin_client/LV2/juce_LV2TurtleDumpProgram.cpp.o


  [ 20%] Linking CXX executable juce_lv2_helper

  gmake[4]: Leaving directory
  '/<>/obj-mips64el-linux-gnuabi64/tools'

  [ 20%] Built target juce_lv2_helper

  gmake[4]: Entering directory
  '/<>/obj-mips64el-linux-gnuabi64/tools'

  gmake[4]: Leaving directory
  '/<>/obj-mips64el-linux-gnuabi64/tools'

  gmake[4]: Entering directory
  '/<>/obj-mips64el-linux-gnuabi64/tools'

  [ 30%] Building CXX object
  extras/Build/juceaide/CMakeFiles/juceaide.dir/Main.cpp.o

  [ 40%] Building CXX object
  
extras/Build/juceaide/CMakeFiles/juceaide.dir/__/juce_build_tools/juce_build_tools.cpp.o


  [ 50%] Building CXX object
  
extras/Build/juceaide/CMakeFiles/juceaide.dir/__/__/__/modules/juce_gui_basics/juce_gui_basics.cpp.o


  [ 60%] Building CXX object
  
extras/Build/juceaide/CMakeFiles/juceaide.dir/__/__/__/modules/juce_graphics/juce_graphics.cpp.o


  [ 70%] Building CXX object
  
extras/Build/juceaide/CMakeFiles/juceaide.dir/__/__/__/modules/juce_events/juce_events.cpp.o


  [ 80%] Building CXX object
  
extras/Build/juceaide/CMakeFiles/juceaide.dir/__/__/__/modules/juce_core/juce_core.cpp.o


  In file included from
  /<>/modules/juce_core/juce_core.cpp:176:



  /<>/modules/juce_core/time/juce_Time.cpp:596:27:
  warning: macro "__DATE__" might prevent reproducible builds [-Wdate-time]

596 | dateTokens.addTokens (__DATE__, true);
|   ^~~~

  
  /<>/modules/juce_core/time/juce_Time.cpp:599:27:
  warning: macro "__TIME__" might prevent reproducible builds [-Wdate-time]

599 | timeTokens.addTokens (__TIME__, ":", StringRef());
|   ^~~~

  [ 90%] Building CXX object
  
extras/Build/juceaide/CMakeFiles/juceaide.dir/__/__/__/modules/juce_data_structures/juce_data_structures.cpp.o


  [100%] Linking CXX executable juceaide_artefacts/Debug/juceaide


  
CMakeFiles/juceaide.dir/__/__/__/modules/juce_gui_basics/juce_gui_basics.cpp.o:
  in function `non-virtual thunk to
  juce::TreeView::TreeViewport::~TreeViewport()':


  
./obj-mips64el-linux-gnuabi64/tools/extras/Build/juceaide/./modules/juce_gui_basics/widgets/juce_TreeView.cpp:717:(.text._ZN4juce8TreeView12TreeViewportD2Ev[_ZN4juce8TreeView12TreeViewportD5Ev]+0x11c):
  relocation truncated to fit: R_MIPS_GOT_PAGE against
  `.text._ZN4juce8TreeView12TreeViewportD2Ev'


  
CMakeFiles/juceaide.dir/__/__/__/modules/juce_gui_basics/juce_gui_basics.cpp.o:
  in function `non-virtual thunk to
  juce::TreeView::TreeViewport::~TreeViewport()':


  
./obj-mips64el-linux-gnuabi64/tools/extras/Build/juceaide/./modules/juce_gui_basics/widgets/juce_TreeView.cpp:717:(.text._ZN4juce8TreeView12TreeViewportD2Ev[_ZN4juce8TreeView12TreeViewportD5Ev]+0x13c):
  relocation truncated to fit: R_MIPS_GOT_PAGE against
  `.text._ZN4juce8TreeView12TreeViewportD2Ev'


  
CMakeFiles/juceaide.dir/__/__/__/modules/juce_gui_basics/juce_gui_basics.cpp.o:
  in function `non-virtual thunk to
  juce::TreeView::TreeViewport::~TreeViewport()':


  
./obj-mips64el-linux-gnuabi64/tools/extras/Build/juceaide/./modules/juce_gui_basics/widgets/juce_TreeView.cpp:717:(.text._ZN4juce8TreeView12TreeViewportD2Ev[_ZN4juce8TreeView12TreeViewportD5Ev]+0x15c):
  relocation truncated to fit: R_MIPS_GOT_PAGE against
  `.text._ZN4juce8TreeView12TreeViewportD2Ev'


  
CMakeFiles/juceaide.dir/__/__/__/modules/juce_gui_basics/juce_gui_basics.cpp.o:
  in function `non-virtual thunk to
  juce::TreeView::TreeViewport::~TreeViewport()':


  
./obj-mips64el-linux-gnuabi64/tools/extras/Build/juceaide/./modules/juce_gui_basics/widgets/juce_TreeView.cpp:717:(.text._ZN4juce8TreeView12TreeViewportD0Ev[_ZN4juce8TreeView12TreeViewportD5Ev]+0x8c):
  relocation truncated to fit: R_MIPS_GOT_PAGE against
  `.text._ZN4juce8TreeView12TreeViewportD0Ev'


  
CMakeFiles/juceaide.dir/__/__/__/modules/juce_gui_basics/juce_gui_basics.cpp.o:
  in function `non-virtual thunk to
  juce::TreeView::TreeViewport::~TreeViewport()':


  

Bug#1064014: dgit - unable to import dscs due to server issues.

[Peter Green]

On 15/02/2024 20:48, Ian Jackson wrote:

Hrm.  Can you point me to an example dsc (eg dgit.dsc?) and semd me
the output with -D ?


dget -d https://deb.debian.org/debian/pool/main/g/giada/giada_0.22.0-4.dsc
mkdir dgittest
cd dgittest/
git init
dgit -D import-dsc ../giada_0.22.0-4.dsc +workingbranch

| git rev-parse --show-toplevel
=> `/home/plugwash/dgittest'
| git config -z --get-regexp --local '.*'
| git config -z --get-regexp --local '.*'
| git config -z --get-regexp --global '.*'
| git config -z --get-regexp --system '.*'
| git check-ref-format --normalize refs/heads/workingbranch
=> `refs/heads/workingbranch'
| git symbolic-ref -q HEAD
=> `refs/heads/master'
| git for-each-ref '--format=%(objectname)' '[r]efs/heads/workingbranch'
=> `'
Dgit metadata in .dsc: specified git info (debian)
dgit: import-dsc of .dsc with Dgit field, using git hash
.dsc names distro debian: fetching rewrite map
git_lrfetch_sane suppl=1 specs dgit-rewrite/map
git_lrfetch_sane specre=(?:refs/dgit\-rewrite\/map)
git_lrfetch_sane iteration 0
| git ls-remote -q --refs https://git.dgit.debian.org/giada 
refs/dgit-rewrite/map
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
dgit: failed command: git ls-remote -q --refs https://git.dgit.debian.org/giada 
refs/dgit-rewrite/map

dgit: error: subprocess failed with error exit status 128

Bug#1064023: cddlib: FTBFS on armhf: ! Text line contains an invalid character.

[Sebastian Ramacher]

Source: cddlib
Version: 094m-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=cddlib=armhf=094m-1%2Bb1=1704482099=0

[13] [14]) [15] [16]
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def

Package amsfonts Warning: Obsolete command \Bbb; \mathbb should be used instead
 on input line 1139.

(./cddlibman.bbl
Overfull \hbox (2.6514pt too wide) in paragraph at lines 4--9
[]\OT1/cmr/m/n/10.95 N. Amenta.  Di-rec-tory of com-pu-ta-tional ge-om-e-try.  
http://www.geom.uiuc.edu/software/cglist/. 
[17])
(./cddlibman.aux)
Underfull \hbox (badness 2302) in paragraph at lines 68--73
[]\OT1/cmr/m/n/10.95 J. Er-ick-son.  Com-pu-ta-tional ge-om-e-try pages, list o
f soft-ware li-braries and codes.
[18]) [19] (./cddlibman.aux
! Text line contains an invalid character.
l.1 ^^@
   ^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@^^@...

? 
! Emergency stop.
l.1 

Output written on cddlibman.dvi (19 pages, 73740 bytes).
Transcript written on cddlibman.log.
 (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsa.fd)make[2]: *** 
[Makefile:526: cddlibman.dvi] Error 1
make[2]: *** Waiting for unfinished jobs

Cheers
-- 
Sebastian Ramacher

Bug#1064014: dgit - unable to import dscs due to server issues.

[Ian Jackson]

Peter Green writes ("Bug#1064014: dgit - unable to import dscs due to server 
issues."):
> Package: dgit
> 
> Something seems to be wrong with the dgit infrastructure, I've been unable to
> import any dscs from Debian that include a dgit: header for a week or two now.
> I get messages like

Hrm.  Can you point me to an example dsc (eg dgit.dsc?) and semd me
the output with -D ?

-- 
Ian JacksonThese opinions are my own.  

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

Bug#1064022: editorconfig-core: FTBFS on i386: error: Could not create output directory /<>/obj-i686-linux-gnu/doc/man

[Sebastian Ramacher]

Source: editorconfig-core
Version: 0.12.6-0.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=editorconfig-core=i386=0.12.6-0.1%2Bb1=1704501538=0

[ 35%] Generating man/man1/editorconfig.1
cd /<>/obj-i686-linux-gnu/src/lib && /usr/bin/cc  
-I/<>/include -I/<>/obj-i686-linux-gnu/src/auto -g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2   -funsigned-char -MD 
-MT src/lib/CMakeFiles/editorconfig_static.dir/ec_glob.c.o -MF 
CMakeFiles/editorconfig_static.dir/ec_glob.c.o.d -o 
CMakeFiles/editorconfig_static.dir/ec_glob.c.o -c 
/<>/src/lib/ec_glob.c
cd /<>/doc && /usr/bin/doxygen 
/<>/obj-i686-linux-gnu/doc/Doxyfile-1
warning: Tag 'OUTPUT_TEXT_DIRECTION' at line 102 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'HTML_TIMESTAMP' at line 1282 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'FORMULA_TRANSPARENT' at line 1587 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'LATEX_SOURCE_CODE' at line 1900 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'LATEX_TIMESTAMP' at line 1916 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'RTF_SOURCE_CODE' at line 1990 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'DOCBOOK_PROGRAMLISTING' at line 2095 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'CLASS_DIAGRAMS' at line 2282 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'OUTPUT_TEXT_DIRECTION' at line 102 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile-1' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'DOT_FONTNAME' at line 2324 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'DOT_FONTSIZE' at line 2331 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'DOT_TRANSPARENT' at line 2577 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'HTML_TIMESTAMP' at line 1282 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile-1' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'FORMULA_TRANSPARENT' at line 1587 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile-1' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'LATEX_SOURCE_CODE' at line 1900 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile-1' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'LATEX_TIMESTAMP' at line 1916 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile-1' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'RTF_SOURCE_CODE' at line 1990 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile-1' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
warning: Tag 'DOCBOOK_PROGRAMLISTING' at line 2095 of file 
'/<>/obj-i686-linux-gnu/doc/Doxyfile-1' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade 

Bug#1064021: gss: FTBFS on armhf: FAIL: krb5context

[Sebastian Ramacher]

Source: gss
Version: 1.0.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=gss=armhf=1.0.4-1%2Bb1=1707506511=0

PASS: threadsafety.sh
../../build-aux/test-driver: line 112: 31890 Segmentation fault  "$@" >> 
"$log_file" 2>&1
FAIL: krb5context
PASS: saslname
PASS: basic
==
   GNU Generic Security Service 1.0.4: tests/test-suite.log
==

# TOTAL: 4
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: krb5context
=

==31890== 
==31890== Process terminating with default action of signal 11 (SIGSEGV)
==31890==  Access not within mapped region at address 0xBDB33984
==31890==at 0x4856C00: shishi_key_parse (in 
/usr/lib/arm-linux-gnueabihf/libshishi.so.0.1.3)
==31890==  If you believe this happened as a result of a stack
==31890==  overflow in your program's main thread (unlikely but
==31890==  possible), you can try to increase the size of the
==31890==  main thread stack using the --main-stacksize= flag.
==31890==  The main thread stack size used in this run was 8388608.
FAIL krb5context (exit status: 139)


Testsuite summary for GNU Generic Security Service 1.0.4

# TOTAL: 4
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

Cheers
-- 
Sebastian Ramacher

Bug#1064020: ulfius: FTBFS on armel, armhf, i386: 3 - framework (Failed)

[Sebastian Ramacher]

Source: ulfius
Version: 2.7.15-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=ulfius=i386=2.7.15-1%2Bb1=1707543312=0

Running suite(s): Ulfius framework function tests
96%: Checks: 28, Failures: 0, Errors: 1
./test/framework.c:5491:P:test_ulfius_framework:test_ulfius_simple_endpoint:0: 
Passed
./test/framework.c:5637:P:test_ulfius_framework:test_ulfius_net_type_endpoint:0:
 Passed
./test/framework.c:5746:P:test_ulfius_framework:test_ulfius_endpoint_parameters:0:
 Passed
./test/framework.c:5797:P:test_ulfius_framework:test_ulfius_endpoint_injection:0:
 Passed
./test/framework.c:5872:P:test_ulfius_framework:test_ulfius_endpoint_multiple:0:
 Passed
./test/framework.c:5899:P:test_ulfius_framework:test_ulfius_endpoint_multiple_with_unauthorized:0:
 Passed
./test/framework.c:5927:P:test_ulfius_framework:test_ulfius_endpoint_multiple_with_error:0:
 Passed
./test/framework.c:5954:P:test_ulfius_framework:test_ulfius_endpoint_multiple_with_complete:0:
 Passed
./test/framework.c:5981:P:test_ulfius_framework:test_ulfius_endpoint_multiple_with_continue:0:
 Passed
./test/framework.c:6008:P:test_ulfius_framework:test_ulfius_endpoint_multiple_with_ignore:0:
 Passed
./test/framework.c:6031:P:test_ulfius_framework:test_ulfius_endpoint_stream:0: 
Passed
./test/framework.c:6065:P:test_ulfius_framework:test_ulfius_endpoint_ignored:0: 
Passed
./test/framework.c:6096:P:test_ulfius_framework:test_ulfius_utf8_not_ignored:0: 
Passed
./test/framework.c:6128:P:test_ulfius_framework:test_ulfius_utf8_ignored:0: 
Passed
./test/framework.c:6155:P:test_ulfius_framework:test_ulfius_endpoint_callback_position:0:
 Passed
./test/framework.c:6187:P:test_ulfius_framework:test_ulfius_MHD_set_response_with_other_free:0:
 Passed
./test/framework.c:6220:P:test_ulfius_framework:test_ulfius_send_smtp:0: Passed
./test/framework.c:6250:P:test_ulfius_framework:test_ulfius_send_rich_smtp:0: 
Passed
./test/framework.c:6280:P:test_ulfius_framework:test_ulfius_follow_redirect:0: 
Passed
./test/framework.c:6302:P:test_ulfius_framework:test_ulfius_shared_data:0: 
Passed
./test/framework.c:6361:E:test_ulfius_framework:test_ulfius_malformed_requests:0:
 (after this point) Received signal 11 (Segmentation fault)
./test/framework.c:6448:P:test_ulfius_framework:test_ulfius_large_posts_check_utf8_no:0:
 Passed
./test/framework.c:6517:P:test_ulfius_framework:test_ulfius_large_posts_check_utf8_yes:0:
 Passed
./test/framework.c:6744:P:test_ulfius_framework:test_ulfius_post_processor_flag:0:
 Passed
./test/framework.c:6798:P:test_ulfius_framework:test_ulfius_send_http_request:0:
 Passed
./test/framework.c:6845:P:test_ulfius_framework:test_ulfius_send_http_request_with_limit:0:
 Passed
./test/framework.c:6866:P:test_ulfius_framework:test_ulfius_server_ca_trust:0: 
Passed
./test/framework.c:6942:P:test_ulfius_framework:test_ulfius_client_certificate:0:
 Passed

Start 4: example_callbacks
4/5 Test #4: example_callbacks    Passed0.18 sec
Start 5: websocket
5/5 Test #5: websocket    Passed1.55 sec

80% tests passed, 1 tests failed out of 5

Total Test time (real) =   2.59 sec

The following tests FAILED:
  3 - framework (Failed)

Cheers
-- 
Sebastian Ramacher

Bug#1064019: stdgpu: FTBFS on armel: Build killed with signal TERM after 150 minutes of inactivity

[Sebastian Ramacher]

Source: stdgpu
Version: 1.3.0+git20220507.32e0517-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=stdgpu=armel=1.3.0%2Bgit20220507.32e0517-5%2Bb1=1707543753=0

1: stdgpu::deque::push_front : Object full
1: [   OK ] stdgpu_deque.push_front_too_many (40 ms)
1: [ RUN  ] stdgpu_deque.push_front_const_type
1: [   OK ] stdgpu_deque.push_front_const_type (13 ms)
1: [ RUN  ] stdgpu_deque.push_front_nondefault_type
1: [   OK ] stdgpu_deque.push_front_nondefault_type (14 ms)
1: [ RUN  ] stdgpu_deque.emplace_front_some
1: [   OK ] stdgpu_deque.emplace_front_some (17 ms)
1: [ RUN  ] stdgpu_deque.emplace_front_all
1: [   OK ] stdgpu_deque.emplace_front_all (40 ms)
1: [ RUN  ] stdgpu_deque.emplace_front_too_many
1: stdgpu::deque::push_front : Object full
1: [   OK ] stdgpu_deque.emplace_front_too_many (41 ms)
1: [ RUN  ] stdgpu_deque.emplace_front_const_type
1: [   OK ] stdgpu_deque.emplace_front_const_type (14 ms)
1: [ RUN  ] stdgpu_deque.emplace_front_nondefault_type
1: [   OK ] stdgpu_deque.emplace_front_nondefault_type (13 ms)
1: [ RUN  ] stdgpu_deque.push_back_circular
1: [   OK ] stdgpu_deque.push_back_circular (32 ms)
1: [ RUN  ] stdgpu_deque.push_front_circular
1: [   OK ] stdgpu_deque.push_front_circular (32 ms)
1: [ RUN  ] stdgpu_deque.clear
1: [   OK ] stdgpu_deque.clear (14 ms)
1: [ RUN  ] stdgpu_deque.clear_full
1: [   OK ] stdgpu_deque.clear_full (14 ms)
1: [ RUN  ] stdgpu_deque.clear_circular
1: [   OK ] stdgpu_deque.clear_circular (21 ms)
1: [ RUN  ] stdgpu_deque.clear_nondefault_type
1: [   OK ] stdgpu_deque.clear_nondefault_type (13 ms)
1: [ RUN  ] stdgpu_deque.clear_nondefault_type_full
1: [   OK ] stdgpu_deque.clear_nondefault_type_full (13 ms)
1: [ RUN  ] stdgpu_deque.clear_nondefault_type_circular
1: [   OK ] stdgpu_deque.clear_nondefault_type_circular (20 ms)
1: [ RUN  ] stdgpu_deque.simultaneous_push_back_and_pop_back
E: Build killed with signal TERM after 150 minutes of inactivity

Cheers
-- 
Sebastian Ramacher

Bug#1061811: mdanalysis fails its autopkg tests with Python 3.12

[Andreas Tille]

Hi,

I wanted to see whether latest upstream 2.7.0 might fix this bug, but I
learned that it needs packaging of mda-xdrlib[1] first.  I gave up at
this point but I pushed branch 2.7.0 to Git where you might cherry-pick
from once you might want to upgrade.

Hope this helps at least a bit
Andreas.

[1] https://github.com/MDAnalysis/mda-xdrlib

-- 
http://fam-tille.de

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Zaha]

Hi,

I'm not sure if this is an user error or my mirror is just outdated, so ignore 
this if it was already dealt with.

I'm running stable, with the addition of pu to sources.list, setting its 
priority to 100 and pinning *nvidia* from pu with priority of 500.

First, nvidia-cuda-dev and/or nvidia-cuda-toolkit (I was trying to follow the 
official debian wiki to install cuda) are not installable because they (or one 
of these packages) pull the tesla driver which is still the unpatched version 
and thus the build fails with the same GPL compliant error.

Second, nvidia-driver-libs:i386 cannot be installed because some packages do 
not have an updated version available yet:
> The following packages have unmet dependencies:
>  nvidia-driver-libs:i386 : Depends: libgl1-nvidia-glvnd-glx:i386 (= 
> 525.147.05-7~deb12u1) but it is not going to be installed
>Depends: nvidia-egl-icd:i386 (= 
> 525.147.05-7~deb12u1) but it is not going to be installed
>Recommends: libglx-nvidia0:i386 (= 
> 525.147.05-7~deb12u1) but it is not going to be installed
>Recommends: libgles-nvidia1:i386 (= 
> 525.147.05-7~deb12u1) but it is not going to be installed
>Recommends: libgles-nvidia2:i386 (= 
> 525.147.05-7~deb12u1) but it is not going to be installed
>Recommends: libnvidia-encode1:i386 (= 
> 525.147.05-7~deb12u1) but it is not going to be installed
>Recommends: nvidia-vulkan-icd:i386 (= 
> 525.147.05-7~deb12u1) but it is not going to be installed
>Recommends: libnvidia-allocator1:i386 (= 
> 525.147.05-7~deb12u1) but it is not going to be installed
> E: Unable to correct problems, you have held broken packages.

Thanks,
Zaha

signature.asc
Description: OpenPGP digital signature

Bug#1052605: pyroute2: Vcs-Git refers to non-public repository

[Bastian Germann]

Control: retitle -1 pyroute2: Vcs-Git refers to non-existing repository

The repo is available (with "-team") at
https://salsa.debian.org/openstack-team/third-party/pyroute2

Bug#1057386: [Pkg-electronics-devel] imsprog , #1057386

[Carsten Schoenert]

Hello Ivan,

Am 14.02.24 um 09:07 schrieb Kosolapov Ivan:

Good day!
I am developer of the imsprog package.
(https://mentors.debian.net/package/imsprog , #1057386)
  This is a GUI tool for programming BIOS chips, automotive memory, 
satellite and TV receiver memory chips and much more using the popular 
CH341a programmer. It has no analogues in linux-systems. By many 
parameters it surpasses flashrom, because IMSProg can program not only 
SPI FLASH ROM chips, but also chips of I2C and MicroWire series, and 
also uses graphical interface. Some IMSProg functions are unique, such 
as reading the SFDP register and the ability to modify the chip's system 
registers.
I would be very grateful if this package could appear in Debian. I need 
a sponsor.


that looks like an interesting package.
I'm will to have a look and also to sponsor later potentially.

--
Regards
Carsten

Bug#1064017: python-requests-unixsocket: Please run python-requests-unixsocket test-suite as part of autopkgtest

[Olivier Gayot]

Package: python-requests-unixsocket
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

The recent migration of urllib3 and src:requests broke
python-requests-unixsocket (see bug 1063892 [1]). This could have been
easily noticed if request_unisocket's test-suite had run as an autopkg
test.

python-requests-unixsocket does not use pybuild so I came up with a
small d/t/control + d/t/python3-requests-unixsocket to make the
test-suite run during autopkgtest execution.

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

  * Execute test-suite as part of autopkgtest (LP: #2053267)

Thanks for considering the patch.

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

-- 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.1.0-16-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 python-requests-unixsocket-0.3.0/debian/tests/control 
python-requests-unixsocket-0.3.0/debian/tests/control
--- python-requests-unixsocket-0.3.0/debian/tests/control   1970-01-01 
01:00:00.0 +0100
+++ python-requests-unixsocket-0.3.0/debian/tests/control   2024-02-15 
19:59:04.0 +0100
@@ -0,0 +1,2 @@
+Tests: python3-requests-unixsocket
+Depends: @, @builddeps@
diff -Nru 
python-requests-unixsocket-0.3.0/debian/tests/python3-requests-unixsocket 
python-requests-unixsocket-0.3.0/debian/tests/python3-requests-unixsocket
--- python-requests-unixsocket-0.3.0/debian/tests/python3-requests-unixsocket   
1970-01-01 01:00:00.0 +0100
+++ python-requests-unixsocket-0.3.0/debian/tests/python3-requests-unixsocket   
2024-02-15 19:59:02.0 +0100
@@ -0,0 +1,13 @@
+#!/bin/bash
+
+set -efu
+
+python3_all="$(py3versions -s 2>/dev/null)"
+
+cp -r requests_unixsocket/tests "$AUTOPKGTEST_TMP/"
+cd "$AUTOPKGTEST_TMP"
+
+for py in $python3_all; do
+echo "=== $py ==="
+$py -m pytest --verbose 2>&1
+done

Bug#1064016: adwaita-icon-theme: v46 cursor theme is missing legacy X11 icon names expected by many applications

[Simon McVittie]

Package: adwaita-icon-theme
Version: 46~beta-1
Severity: important
Tags: upstream
Control: affects -1 firefox firefox-esr chromium libsdl2-2.0-0
Forwarded: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/278

adwaita-icon-theme 46~beta removed a lot of symlinks representing legacy
X11 cursor names, such as left_ptr, hand2 and xterm.

Instead, it exclusively contains cursor names corresponding to the CSS
cursor list: https://drafts.csswg.org/css-ui/#cursor
which is the same as the freedesktop.org cursor spec, minus the proposed
"up-arrow" which is in neither CSS nor Adwaita:
https://www.freedesktop.org/wiki/Specifications/cursor-spec/

Unfortunately, lots of applications expect/assume that the legacy X11
cursor names will exist, and use them in preference to the CSS names.
Depending on the application, this can result in it either falling
back to the default arrow, or a nasty-looking pixelated X11 cursor,
or an empty rectangle.

A particularly visible symptom for this is that in affected applications,
the cursor does not change from its default shape to an I-beam when
hovering over selectable text, and does not change to a pointing finger
when hovering over a hyperlink.

For the cursors that have a corresponding entry in the legacy
X11 vocabulary and the CSS vocabulary, it's very easy to provide
backwards-compat by creating symlinks, for example left_ptr -> default,
hand2 -> pointer, xterm -> text. If upstream are not going to do this,
then I think it would be pragmatic for Debian and other distros to do it.

I am *not* intending to create or ship cursors that existed in the X11
cursor vocabulary but do not exist in the CSS vocabulary, some of which
are frankly baffling (I'm pretty sure we don't actually need boat,
pirate or umbrella, for example). Applications wanting those cursors
can either use unthemed X11 cursors or ship their own.

smcv



For reference, the CSS cursor names are as follows:

alias
all-scroll
cell
col-resize
context-menu
copy
crosshair
default
e-resize
ew-resize
grab
grabbing
help
move
n-resize
ne-resize
nesw-resize
no-drop
not-allowed
ns-resize
nw-resize
nwse-resize
pointer
progress
row-resize
s-resize
se-resize
sw-resize
text
vertical-text
w-resize
wait
zoom-in
zoom-out

and the X11 cursor names are:

X_cursor
arrow
based_arrow_down
based_arrow_up
boat
bogosity
bottom_left_corner
bottom_right_corner
bottom_side
bottom_tee
box_spiral
center_ptr
circle
clock
coffee_mug
cross
cross_reverse
crosshair
diamond_cross
dot
dotbox
double_arrow
draft_large
draft_small
draped_box
exchange
fleur
gobbler
gumby
hand1
hand2
heart
icon
iron_cross
left_ptr
left_side
left_tee
leftbutton
ll_angle
lr_angle
man
middlebutton
mouse
pencil
pirate
plus
question_arrow
right_ptr
right_side
right_tee
rightbutton
rtl_logo
sailboat
sb_down_arrow
sb_h_double_arrow
sb_left_arrow
sb_right_arrow
sb_up_arrow
sb_v_double_arrow
shuttle
sizing
spider
spraycan
star
target
tcross
top_left_arrow
top_left_corner
top_right_corner
top_side
top_tee
trek
ul_angle
umbrella
ur_angle
watch
xterm

Bug#1064015: rust-wasmtime - upcoming rust-hashbrown update.

[Peter Green]

Package: rust-wasmtime

Now that rust-ahash 0.8 is in trixie and noble I hope to update
rust-hashbrown and rust-indexmap soon to versions 0.14
and version 2 respectively.

I have tested that simply relaxing the (build-)dependencies
is enough to make rust-wasmtime build and pass it's autopkgtests
with the new hashbrown. The debdiff I used for testing is attached.
diff -Nru rust-wasmtime-16.0.0+dfsg/debian/changelog 
rust-wasmtime-16.0.0+dfsg/debian/changelog
--- rust-wasmtime-16.0.0+dfsg/debian/changelog  2024-01-01 15:01:24.0 
+
+++ rust-wasmtime-16.0.0+dfsg/debian/changelog  2024-02-15 18:27:59.0 
+
@@ -1,3 +1,10 @@
+rust-wasmtime (16.0.0+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump hashbrown dependencies to 0.14.
+
+ -- Peter Michael Green   Thu, 15 Feb 2024 18:27:59 +
+
 rust-wasmtime (16.0.0+dfsg-2) unstable; urgency=medium
 
   * no-changes source-only upload to enable testing migration
diff -Nru rust-wasmtime-16.0.0+dfsg/debian/control 
rust-wasmtime-16.0.0+dfsg/debian/control
--- rust-wasmtime-16.0.0+dfsg/debian/control2023-12-30 16:07:22.0 
+
+++ rust-wasmtime-16.0.0+dfsg/debian/control2024-02-15 18:27:59.0 
+
@@ -13,8 +13,8 @@
  librust-bumpalo-3+default-dev ,
  librust-capstone-0.11+default-dev ,
  librust-gimli-dev (<< 0.29) ,
- librust-hashbrown-0.12+default-dev ,
- librust-hashbrown-0.12+raw-dev ,
+ librust-hashbrown-0.14+default-dev ,
+ librust-hashbrown-0.14+raw-dev ,
  librust-log-0.4-dev ,
  librust-regalloc2-0.9+checker-dev ,
  librust-regalloc2-0.9+default-dev ,
@@ -46,8 +46,8 @@
  librust-capstone-0.11+default-dev,
  librust-codespan-reporting-0.11+default-dev,
  librust-gimli-dev (<< 0.29),
- librust-hashbrown-0.12+default-dev,
- librust-hashbrown-0.12+raw-dev,
+ librust-hashbrown-0.14+default-dev,
+ librust-hashbrown-0.14+raw-dev,
  librust-log-0.4-dev,
  librust-regalloc2-0.9+checker-dev,
  librust-regalloc2-0.9+default-dev,

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Andreas Beckmann]

On 15/02/2024 19.54, Jonathan Wiltshire wrote:
>Revised draft:
ACK.


This update addresses problems in three non-free driver packages supporing

s/supporing/supporting/

Andreas

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Henrique de Moraes Holschuh]

On Thu, Feb 15, 2024, at 15:45, Mario Limonciello wrote:
> On 2/15/2024 12:39, Henrique de Moraes Holschuh wrote:
>> While adding linux-firmware's amdtee/ directory to the Debian 
>> amd64-microcode package, I have noticed that  the linux-firmware WHENCE file 
>> mentions a symbolic link that is not present in the git repository.
>> 
>> The missing symlink is:
>> amdtee/amd_pmf_v3.bin -> 773bd96f-b83f-4d52-b12dc529b13d8543.bin
>> 
>> Is the amd_pmf driver functional without that symlink ?
>> 
>
> symlinks are created by copy-firmware.sh

Thanks. I have to take that into account, then.  Hopefully this is the first 
instance of that bug in the amd64-microcode packaging, I will check every other 
file in there to ensure no links were missed.

-- 
  Henrique de Moraes Holschuh 

Bug#1034091: RFP: whisper -- Robust Speech Recognition via Large-Scale Weak Supervision

[Petter Reinholdtsen]

I just came across the article "Whispering in Norwegian: Navigating
Orthographic and Dialectic Challenges" Per E Kummervold, Javier de la
Rosa, Freddy Wetjen, Rolv-Arild Braaten and Per Erik Solberg,
https://arxiv.org/pdf/2402.01917.pdf>.

I found this quote particularly interesting:

  Although the original PyTorch training code was not released by
  OpenAI, a collaborative effort with HuggingFace led to an alternative
  implementation in the Transformers library.  This has also been
  adapted for Jax. The project participated in developing and
  open-sourcing training scripts for TPU-v4-pods, enabling dynamic
  changes to the training data during runtime (The National Library of
  Norway, 2024).

The reference point to https://www.github.com/NbAiLab/nostram >.
I have not investigated further.  Perhaps the alternative implementation
can be used to make a model from scratch and provide source for the
files requested by the ftpmasters?

Unrelated to this, there is an alternative implementation using the
whisper models called whisper.cpp, available from
https://github.com/ggerganov/whisper.cpp.git >.  It might be
easier to package than the openai whisper implementation.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1063968: freedombox: autopkgtest regression with pytest 8

[Sunil Mohan Adapa]

Control: tags -1 patch

On Thu, 15 Feb 2024 11:35:26 +0100 roehl...@debian.org wrote:
[...]

Dear maintainer,

your package has a autopkgtest regression with pytest 8.


Thank you for the bug report. We have a patch pending to fix this issue 
with pytest 8 and another with pytest 9[1]. This patch will be part of 
the upcoming bi-weekly release.


1) https://salsa.debian.org/freedombox-team/freedombox/-/merge_requests/2444

--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Jonathan Wiltshire]

Hi,

On Thu, Feb 15, 2024 at 05:48:37PM +, Dan Coleman wrote:
> As a user facing this issue, I'd rather have the release as soon as possible. 
> It's already been a couple days. But that's just a user perspective!
 
If you really can't wait another 24 hours, please feel free to install the
packages from bookworm-proposed-updates and help with testing them.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Jonathan Wiltshire]

On Thu, Feb 15, 2024 at 07:08:30PM +0100, Andreas Beckmann wrote:
> On 15/02/2024 18.44, Jonathan Wiltshire wrote:
> > On Thu, Feb 15, 2024 at 02:24:05PM +0100, Andreas Beckmann wrote:
> > > On 14/02/2024 11.01, Jonathan Wiltshire wrote:
> > > > On Sun, Feb 11, 2024 at 11:23:00PM +0100, Andreas Beckmann wrote:
> > > > > We need to push 4 packages together to stable-updates:
> > > > > nvidia-graphics-drivers
> > > > > nvidia-settings
> > > > > nvidia-graphics-drivers-tesla-470
> > > > > nvidia-graphics-drivers-tesla
> > > > 
> > > > According to my list there's just nvidia-graphics-drivers-tesla missing
> > > > now; does that match yours?
> > > 
> > > Seems installable in sid now, so just uploaded to PU. These 4 should be
> > > ready for stable-updates.
> > 
> > Thanks; accepted all four, and the builds have just come in.
> > 
> > I can release as early as tonight (19:52) but I don't know if that's a bit
> > of a rush. Should I hang on until tomorrow evening in case of any
> > late-breaking issues?
> 
> Tomorrow is probably better.

Agreed.

> > We also need to put some thought into an announcement text. Here's a draft
> > starting point:
> > 
> > ===
> > This update addresses problems in four non-free packages to support nVidia
> > graphics cards.
> 
> three non-free driver packages ?

Oh, I counted nvidia-graphics-drivers twice, sorry.

> > The Linux kernel update included in Debian 12.5 marked two functions as
> > GPL-only, making them inaccessible to non-free kernel modules.
> not correct ...
> 
> The Linux kernel update in Debian 12.5 changed an inlined function to call
> two GPL-only symbols, making that function inaccessible to non-free kernel
> modules.

Yes, ok.

> > As a result,
> > the nVidia kernel modules cannot be built via DKMS at installation time for
> > the updated kernel.
> > 
> > This issue could not be resolved in time for the release of Debian 12.5.
> 
> (And perhaps something along this:)
> 
> Additionally src:nvidia-graphics-drivers and src:nvidia-settings have been
> enabled to build for ppc64el, in order to turn
> src:nvidia-graphics-drivers-tesla into transitional packages to ease future
> updates.

That's a bit wordy - I'll draft below.

> > The following packages have been updated to correct the problem.
> 
> > , as well as
> > fixing detection of Tesla 470 compatibility:
> Drop, that was a regression introduced in -6 and -6~deb12u1, it only existed
> for a few days.

Ok.

Revised draft:

===
This update addresses problems in three non-free driver packages supporing
nVidia graphics cards.
 
The Linux kernel released in Debian 12.5 changed an inlined function to call
two GPL-only symbols, making that function inaccessible to non-free kernel
modules.

As a result, the nVidia kernel modules cannot be built via DKMS at
installation time for the updated kernel. This issue could not be resolved
in time for the release of Debian 12.5.

In addition, the source packages nvidia-graphics-drivers and
nvidia-settings now build binaries for ppc64el, and
nvidia-graphics-drivers-tesla builds transitional packages to
ease future updates.

The following packages have been updated to correct the problem:

Source package Fixed version
== =
nvidia-graphics-drivers
nvidia-graphics-drivers-tesla
nvidia-graphics-drivers-tesla-470
nvidia-settings
 
If you use the affected packages, we recommend you upgrade to these
versions.
===

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1064014: dgit - unable to import dscs due to server issues.

[Peter Green]

Package: dgit

Something seems to be wrong with the dgit infrastructure, I've been unable to
import any dscs from Debian that include a dgit: header for a week or two now.
I get messages like


['dgit', 'import-dsc', 
'/build/workingrepo/pool/main/g/giada/giada_0.22.0-4.dsc', '+workingbranch']
"my" variable $date masks earlier declaration in same scope at /usr/bin/dgit 
line 2188.
Dgit metadata in .dsc: specified git info (debian)
dgit: import-dsc of .dsc with Dgit field, using git hash
.dsc names distro debian: fetching rewrite map
fatal: Could not read from remote repository.

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Mario Limonciello]

On 2/15/2024 12:39, Henrique de Moraes Holschuh wrote:

While adding linux-firmware's amdtee/ directory to the Debian amd64-microcode 
package, I have noticed that  the linux-firmware WHENCE file mentions a 
symbolic link that is not present in the git repository.

The missing symlink is:
amdtee/amd_pmf_v3.bin -> 773bd96f-b83f-4d52-b12dc529b13d8543.bin

Is the amd_pmf driver functional without that symlink ?



symlinks are created by copy-firmware.sh

$ make install DESTDIR=tmp
install -d tmp/lib/firmware
./copy-firmware.sh  tmp/lib/firmware

$ ls tmp/lib/firmware/amdtee/ -l
total 16
-rw-r--r-- 1 supermario supermario 12864 Feb 15 12:44 
773bd96f-b83f-4d52-b12dc529b13d8543.bin
lrwxrwxrwx 1 supermario supermario39 Feb 15 12:44 amd_pmf_v3.bin -> 
773bd96f-b83f-4d52-b12dc529b13d8543.bin

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Henrique de Moraes Holschuh]

While adding linux-firmware's amdtee/ directory to the Debian amd64-microcode 
package, I have noticed that  the linux-firmware WHENCE file mentions a 
symbolic link that is not present in the git repository.

The missing symlink is:
amdtee/amd_pmf_v3.bin -> 773bd96f-b83f-4d52-b12dc529b13d8543.bin

Is the amd_pmf driver functional without that symlink ?

-- 
  Henrique de Moraes Holschuh 

Bug#1033012: reportbug: miniupnpd does not work in Debian Stable

[Nazarii Kretovych]

Package: miniupnpd
Version: 2.3.1-1
Followup-For: Bug #1033012
X-Debbugs-Cc: nazarii.kretov...@gmail.com

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: 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/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages miniupnpd depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  lsb-base   11.6
ii  miniupnpd-nftables 2.3.1-1
ii  sysvinit-utils [lsb-base]  3.06-4
ii  uuid-runtime   2.38.1-5+b1

miniupnpd recommends no packages.

miniupnpd suggests no packages.

-- debconf information:
* miniupnpd/start_daemon: true
  miniupnpd/ip6script: false
* miniupnpd/listen: br0
* miniupnpd/iface: lan1
  miniupnpd/force_igd_desc_v1: false

Bug#1063938: closed by Philip Chung (Re: Bug#1063938: tmux: Does not automatically set mode-keys to vi based on VISUAL or EDITOR environment)

[Romain Francoise]

On Thu, Feb 15, 2024 at 04:21:03PM +, Philip Chung  wrote:
> The original behavior I reported seems to come from how I invoked
> tmux, which was actually through xfce4-terminal ("xfce4-terminal -x
> tmux"), and for some reason the EDITOR variable I export in .bashrc is
> not being set there for tmux to read. When I start a new tmux server
> from a shell with the variable set, mode-keys is set to vi as
> expected.

In that situation xfce4-terminal executes tmux directly, it's not going
through your shell at all. You can however use the trick of running
`bash -c tmux` or similar to force tmux to be launched from a shell, if
that helps.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Henrique de Moraes Holschuh]

On Tue, Feb 13, 2024, at 17:04, Diederik de Haas wrote:
> I'll add the `amdtee` dir to `Files-Excluded` in firmware-nonfree and 
> Henrique 
> can add those files to the amd64-microcode package.

Agreed.   For now, let's have amd64-microcode package to be the 
"SoC-and-CPU-related" firmware distribution for AMD, and keep the firmware for 
other AMD hardware, such as GPU adapter cards in the other firmware packages.

Since Diederik confirmed that amd-tee has never been shipped in a firmware-* 
package in Debian, it will not cause issues for amd64-microcode backports.  
Good, I can just have it on every branch, then.

I am currently waiting my updated gpg subkey to be activated (it is already in 
keyring.d.o, but it needs to wait for the monthly push).  It should happen in 
about 10 days, and then I will upload the new packages to unstable.

Meanwhile, I will prepare the updated packages in salsa.debian.org, if there's 
a need for a faster upload, we can ask someone to sponsor it next week.

PS: Mario, we're considering the newer AMD processor microcode sitting in 
linux-firmware to be a non-critical functional update since nobody was informed 
otherwise AFAIK, and I could not find the newer revisions listed in any AMD 
advisories.   If you know otherwise, drop us a note privately (e.g. inform the 
Debian security team, or inform me directly) and we will issue it as a security 
update.

-- 
  Henrique de Moraes Holschuh 

Bug#1064013: RM: trollimage [mips64el] -- ROM; FTBFS

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: trollim...@packages.debian.org
Control: affects -1 + src:trollimage
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove trollimage from mips64el where it FTBFS.

Its three rdeps are not blockers because they're arch:all.

Kind Regards,

Bas

Bug#1044079: augur: FTBFS with pandas 2.0

[Andreas Tille]

Control: tags -1 pending

Hi,

thanks a lot for this hint.

Am Wed, Feb 14, 2024 at 10:36:05AM +0100 schrieb s3v:
> I don't know if renaming is a drop-in replacement

Me neither but I simply trust that its passing its test
suite.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Andreas Beckmann]

On 15/02/2024 18.44, Jonathan Wiltshire wrote:

On Thu, Feb 15, 2024 at 02:24:05PM +0100, Andreas Beckmann wrote:

On 14/02/2024 11.01, Jonathan Wiltshire wrote:

On Sun, Feb 11, 2024 at 11:23:00PM +0100, Andreas Beckmann wrote:

We need to push 4 packages together to stable-updates:
nvidia-graphics-drivers
nvidia-settings
nvidia-graphics-drivers-tesla-470
nvidia-graphics-drivers-tesla


According to my list there's just nvidia-graphics-drivers-tesla missing
now; does that match yours?


Seems installable in sid now, so just uploaded to PU. These 4 should be
ready for stable-updates.


Thanks; accepted all four, and the builds have just come in.

I can release as early as tonight (19:52) but I don't know if that's a bit
of a rush. Should I hang on until tomorrow evening in case of any
late-breaking issues?


Tomorrow is probably better.


We also need to put some thought into an announcement text. Here's a draft
starting point:

===
This update addresses problems in four non-free packages to support nVidia
graphics cards.


three non-free driver packages ?


The Linux kernel update included in Debian 12.5 marked two functions as
GPL-only, making them inaccessible to non-free kernel modules.

not correct ...

The Linux kernel update in Debian 12.5 changed an inlined function to 
call two GPL-only symbols, making that function inaccessible to non-free 
kernel modules.



As a result,
the nVidia kernel modules cannot be built via DKMS at installation time for
the updated kernel.

This issue could not be resolved in time for the release of Debian 12.5.


(And perhaps something along this:)

Additionally src:nvidia-graphics-drivers and src:nvidia-settings have 
been enabled to build for ppc64el, in order to turn 
src:nvidia-graphics-drivers-tesla into transitional packages to ease 
future updates.



The following packages have been updated to correct the problem.



, as well as
fixing detection of Tesla 470 compatibility:
Drop, that was a regression introduced in -6 and -6~deb12u1, it only 
existed for a few days.



   PackageFixed version
   =====
   nvidia-graphics-drivers
   nvidia-graphics-drivers-tesla
   nvidia-graphics-drivers-tesla-470
   nvidia-settings

If you use the affected packages, we recommend you upgrade to these
versions.
===

Feedback?

Thanks,

Bug#1064012: RFS: oaknut/2.0.2-1 [ITP] -- C++20 assembler for AArch64 (ARMv8.0 to ARMv8.2)

[David James]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: davidjamescastor...@proton.me

Dear mentors,

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

 * Package name : oaknut
   Version  : 2.0.2-1
   Upstream contact : merryhime 
 * URL  : https://github.com/merryhime/oaknut
 * License  : Expat
 * Vcs  : https://salsa.debian.org/Castor216/oaknut
   Section  : libdevel

The source builds the following binary packages:

  liboaknut-dev - C++20 assembler for AArch64 (ARMv8.0 to ARMv8.2)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/oaknut/oaknut_2.0.2-1.dsc

Changes for the initial release:

 oaknut (2.0.2-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1061078)

Regards,
-- 
  David James

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Dan Coleman]

 Original Message 
On Feb 15, 2024, 12:44 PM, Jonathan Wiltshire < j...@debian.org> wrote:
On Thu, Feb 15, 2024 at 02:24:05PM +0100, Andreas Beckmann wrote: > On 
14/02/2024 11.01, Jonathan Wiltshire wrote: > > On Sun, Feb 11, 2024 at 
11:23:00PM +0100, Andreas Beckmann wrote: > > > We need to push 4 packages 
together to stable-updates: > > > nvidia-graphics-drivers > > > nvidia-settings 
> > > nvidia-graphics-drivers-tesla-470 > > > nvidia-graphics-drivers-tesla > > 
> > According to my list there's just nvidia-graphics-drivers-tesla missing > > 
now; does that match yours? > > Seems installable in sid now, so just uploaded 
to PU. These 4 should be > ready for stable-updates. Thanks; accepted all four, 
and the builds have just come in. I can release as early as tonight (19:52) but 
I don't know if that's a bit of a rush. Should I hang on until tomorrow evening 
in case of any late-breaking issues?

As a user facing this issue, I'd rather have the release as soon as possible. 
It's already been a couple days. But that's just a user perspective!

We also need to put some thought into an announcement text. Here's a draft 
starting point: === This update addresses problems in four non-free 
packages to support nVidia graphics cards. The Linux kernel update included in 
Debian 12.5 marked two functions as GPL-only, making them inaccessible to 
non-free kernel modules. As a result, the nVidia kernel modules cannot be built 
via DKMS at installation time for the updated kernel. This issue could not be 
resolved in time for the release of Debian 12.5. The following packages have 
been updated to correct the problem, as well as fixing detection of Tesla 470 
compatibility: Package Fixed version === == 
nvidia-graphics-drivers nvidia-graphics-drivers-tesla 
nvidia-graphics-drivers-tesla-470 nvidia-settings If you use the affected 
packages, we recommend you upgrade to these versions. === Feedback? Thanks, 
-- Jonathan Wiltshire j...@debian.org Debian Developer 
http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 
5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: 
CA619D65A72A7BADFC96D280196418AAEB74C8A1 -- To unsubscribe, send mail to 
1063675-unsubscr...@bugs.debian.org.

Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition

[Steve Langasek]

On Thu, Feb 15, 2024 at 10:22:34AM +0100, Christoph Berg wrote:
> Re: Steve Langasek
> > postgresql-server-dev-16 also shows up as impacted by LFS but the output is
> > confusing, mentioning only redefinitions of constants from perl and python
> > headers, why should those have disappeared based on defining LFS flags?  The
> > changes are suspicious enough that I'm not prepared to conclusively declare
> > it a false positive.

> postgresql-16 as a whole source package contains a single affected
> symbol that is not used by any external user (as per
> codesearch.debian.org and github.com).

Sorry, did you manage to get sensible a-c-c output?  Otherwise, how did you
determine that there was a single symbol affected?  The only compat_report
output I have shows *zero* symbols affected but also shows a bunch of
garbage output that makes me not trust it at all.

> Please exclude postgresql-16 from the transition.

> Where am I supposed to file these requests so they don't get
> forgotten?

my inbox is fine :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Jonathan Wiltshire]

On Thu, Feb 15, 2024 at 02:24:05PM +0100, Andreas Beckmann wrote:
> On 14/02/2024 11.01, Jonathan Wiltshire wrote:
> > On Sun, Feb 11, 2024 at 11:23:00PM +0100, Andreas Beckmann wrote:
> > > We need to push 4 packages together to stable-updates:
> > > nvidia-graphics-drivers
> > > nvidia-settings
> > > nvidia-graphics-drivers-tesla-470
> > > nvidia-graphics-drivers-tesla
> > 
> > According to my list there's just nvidia-graphics-drivers-tesla missing
> > now; does that match yours?
> 
> Seems installable in sid now, so just uploaded to PU. These 4 should be
> ready for stable-updates.

Thanks; accepted all four, and the builds have just come in.

I can release as early as tonight (19:52) but I don't know if that's a bit
of a rush. Should I hang on until tomorrow evening in case of any
late-breaking issues?

We also need to put some thought into an announcement text. Here's a draft
starting point:

===
This update addresses problems in four non-free packages to support nVidia
graphics cards.

The Linux kernel update included in Debian 12.5 marked two functions as
GPL-only, making them inaccessible to non-free kernel modules. As a result,
the nVidia kernel modules cannot be built via DKMS at installation time for
the updated kernel.

This issue could not be resolved in time for the release of Debian 12.5. 

The following packages have been updated to correct the problem, as well as
fixing detection of Tesla 470 compatibility:

  PackageFixed version
  =====
  nvidia-graphics-drivers
  nvidia-graphics-drivers-tesla
  nvidia-graphics-drivers-tesla-470
  nvidia-settings

If you use the affected packages, we recommend you upgrade to these
versions.
===

Feedback?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1064011: wayfire-dev: Missing -dev package dependencies

[Boyuan Yang]

Package: wayfire-dev
Version: 0.7.4-3
Severity: important
Control: fixed -1 0.7.5-2
Tags: bookworm

Package wayfire-dev is missing binary dependency on several -dev packages.
This bug was fixed in 0.7.5-2, but the version currently in Debian 12 is
not fixed yet.

Thanks,
Boyuan Yang


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

Bug#1062259: libcomps: NMU diff for 64-bit time_t transition

[Holger Levsen]

On Wed, Feb 14, 2024 at 10:31:21AM -0800, Steve Langasek wrote:
> Well, these packages will be garbage collected from experimental upon the
> next upload of a package to unstable or experimental with a higher version;

which might happen next month or next year or in 2027...

> so this is a low priority vs the work to actually get the transition done
> successfully.

I'd appreciate if transitions would be less messy for random bystanders.
it takes you one email to ask for the removal of all errously uploaded
packages.

i'm not impressed.


-- 
cheers,
Holger

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

The planet we think we're living on no longer exists.


signature.asc
Description: PGP signature

Bug#1060761: lomiri-ui-toolkit: FTBFS with Qt ≥ 5.15.11: error: invalid use of non-static member function ‘QV4::CompiledData::Binding::Type QV4::CompiledData::Binding::type() const’

[James Addison]

Source: lomiri-ui-toolkit
Followup-For: Bug #1060761
X-Debbugs-Cc: sunwea...@debian.org, mity...@debian.org

Hi Mike, Dmitry,

Is the second patch here (to disable the failing unit test) likely to be
uploaded to unstable in the nearish future?

I'm eager to see the results of some build reproducibility improvements in
qttools from 5.15.12 (#1059592, #1059631) and this is tagged as a blocker for
the relevant qtbase ABI migration.

Regards,
James

Bug#974217: RFS: python-radexreader/1.2.4-1 [ITP] -- Reader for the RADEX RD1212 Geiger counter

[code]

v1.2.4-1 was uploaded to mentors
I think that all previous comment was fixed

Bug#974209: RFS: human-theme-gtk/2.2.0-1 [ITP] -- Human theme for GTK

[code]

Hi Tobias!

I'm so sorry, I didn't see your answer.
My bad! This is a scandal!

Yes:
- I removed the logic for libpango
- I changed the mv to cp in rules (yes I can also rename the file 
directly... it's just shortened like that)



For the file in /etc/profile.d:

export FREETYPE_PROPERTIES="truetype:interpreter-version=35"
-> to configure pango rendering like before

export GTK_OVERLAY_SCROLLING=0
-> to disable overlay scrolling of gtk3, so to use classic scroll bars

export GTK_BACKDROP=1
-> to enable backdrop state with gtk3-classic (when a window doesn't 
have focus)


export GTK_FOCUS_VISIBLE=1
-> to enable "full focus" on first toolbar element with gtk3/4-classic
-> without the outline is not rendered

export GTK_PROGRESS_TEXT_INSIDE=1
-> to restore dual text color for progress bars with gtk3/4-classic

export GTKM_INSERT_EMOJI=1
-> I don't remember exactly :D, for gtk3-classic

export QT_QPA_PLATFORMTHEME=gtk2
-> to use gtk2 theme for qt5 apps

export GTK_USE_IEC_UNITS=1
-> to use IEC units with open/save dialog when it's configured with 
gtk3/4-classic


gtk3-classic & gtk4-classic
https://gist.github.com/luigifab/0fce786cdb93b5687069a82f490ea95e


v2.2.0-1 was uploaded to mentors
Thanks

Bug#1064009: initramfs-tools-core: initrd fails to boot stating root fs is missing with LVM RAID1 in degraded mode

[Petr Vyhnal]

Package: initramfs-tools-core
Version: 0.142
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Consider having VM with two ~21.5GB disks and doing fresh installation
Debian installer partitioner setup
1) Created partitions as follows
/dev/vda1   500MB EFI
/dev/vda2   21GB LVM
/dev/vdb1   500MB EFI
/dev/vdb2   21GB LVM

2) Setup LVM as follows
vg_main as VG consists of /dev/vda2 & /dev/vdb2 PVs (~ 2*20GB)
lv_root ext4 10GB LV in vg_main
lv_swap swap 1GB LV in vg_main

Both LVs are created as linear by the installer

3) Finish Debian installation & reboot

4) Boot new system and convert lv_root linear LV to RAID 1
lvconvert --type raid1 vg_main/lv_root -m 1

5) Reboot the machine to ensure it boots and check lvs status
  LV VG  Attr   LSize   Pool Origin Data%  Meta%  Move 
Log Cpy%Sync Convert
  lv_rootvg_main rwi-aor---   9.31g 
   100.00  
  [lv_root_rimage_0] vg_main iwi-aor---   9.31g 
   
  [lv_root_rimage_1] vg_main iwi-aor---   9.31g 
   
  [lv_root_rmeta_0]  vg_main ewi-aor---   4.00m 
   
  [lv_root_rmeta_1]  vg_main ewi-aor---   4.00m 
   
  lv_swapvg_main -wi-ao 952.00m 
   

6) shutdown the machine, disconnect vdb disk and start it again

7) initrd drops to initramfs shell stating it's unable to find root file system

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Created a script /etc/initramfs-tools/scripts/local-top/startlvm with the 
following content
#!/bin/sh
PREREQ=""
prereqs()
{
   echo "$PREREQ"
}
case $1 in
prereqs)
   prereqs
   exit 0
   ;;
esac
. /scripts/functions
# Begin real processing below this line
lvm vgchange -ay --activationmode degraded --sysinit

   * What was the outcome of this action?
LVM was able to start root LV even if one PV was missing.

   * What outcome did you expect instead?
I would expect this to be handled without a need for a custom script.

-- 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=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 initramfs-tools-core depends on:
ii  coreutils9.1-1
ii  cpio 2.13+dfsg-7.1
ii  e2fsprogs1.47.0-2
ii  klibc-utils  2.0.12-1
ii  kmod 30+20221128-1
ii  logsave  1.47.0-2
ii  udev 252.22-1~deb12u1

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.35.0-4+b3
ii  zstd 1.5.4+dfsg2-5

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.11-6

-- no debconf information

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Dirk Hünniger]

Hi Georges,

I forgot to metion that that the line 52 (chromium-sandbox) should be 
change in the same manner as line 51. So it should look like:


chromium-sandbox [!armel !mips64el !s390x],

Yours Dirk

On 15.02.24 16:03, Paul Gevers wrote:

Hi,

On 15-02-2024 15:56, Dirk Hünniger wrote:
So could you Paul please post some information on how to do that. 
Maybe an example.


See [1] after the first example. Replace [2] with
 chromium [!armel !mips64el !s390x],

Paul

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html
[2] 
https://sources.debian.org/src/mediawiki2latex/8.7-2/debian/control/#L51

Bug#1060398: code not installed

[dann frazier]

forwarded 1060398 https://gitlab.com/kraxel/virt-firmware/-/issues/10
tags 1060398 + upstream
severity 1060398 minor
thanks

Thanks Michael. We don't currently install the impacted code, but I've
gone ahead and reported this upstream.

Bug#1061229: numpydoc: Failing autopkgtest

[Paul Gevers]

Control: found -1 1.5.0-1

Hi,

On Sat, 20 Jan 2024 18:47:50 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= 
 wrote:

numpydoc's autopkgtest is failing. Matthias added a path to Ubuntu to
mark it as expected fail, but without further explanation. I am
attaching a version of his patch.


The version in testing now fails too.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Dirk Hünniger]

Hi Paul, Georges

thanks a lot Paul for explanation on the syntax. Georges, could you 
please follow the instruction given below.


Yours Dirk

On 15.02.24 16:03, Paul Gevers wrote:

Hi,

On 15-02-2024 15:56, Dirk Hünniger wrote:
So could you Paul please post some information on how to do that. 
Maybe an example.


See [1] after the first example. Replace [2] with
 chromium [!armel !mips64el !s390x],

Paul

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html
[2] 
https://sources.debian.org/src/mediawiki2latex/8.7-2/debian/control/#L51

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Paul Gevers]

Hi,

On 15-02-2024 15:56, Dirk Hünniger wrote:
So could you Paul please post some information on 
how to do that. Maybe an example.


See [1] after the first example. Replace [2] with
 chromium [!armel !mips64el !s390x],

Paul

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html
[2] https://sources.debian.org/src/mediawiki2latex/8.7-2/debian/control/#L51



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063928: Patch v3

[cen]

New patch as suggested on irc
From 3db7fb418de6f14833299f6a5993b90b575f2a1b Mon Sep 17 00:00:00 2001
From: cen 
Date: Thu, 15 Feb 2024 15:55:13 +0100
Subject: [PATCH] add missing import for field_parse_binary_source, invoke
 conditionally on whitespace present in package name

---
 scripts/debrebuild.pl | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/debrebuild.pl b/scripts/debrebuild.pl
index 561db866..6ce88a56 100755
--- a/scripts/debrebuild.pl
+++ b/scripts/debrebuild.pl
@@ -20,6 +20,7 @@ use autodie;
 use Getopt::Long qw(:config gnu_getopt no_bundling no_auto_abbrev);
 
 use Dpkg::Control;
+use Dpkg::Control::FieldsCore;
 use Dpkg::Index;
 use Dpkg::Deps;
 use Dpkg::Source::Package;
@@ -230,7 +231,10 @@ if (not defined($host_arch)) {
 
 my $srcpkgname = $cdata->{Source};
 my $srcpkgver  = $cdata->{Version};
-{
+
+# in some cases the source field contains a version in the form: name (version)
+# for example: binclock (1.5-6)
+if ($srcpkgname =~ / /) {
 # make $@ local, so we don't print "Undefined subroutine" error message
 # in other parts where we evaluate $@
 local $@ = '';
-- 
2.39.2

Bug#1063898: pipewire-bin: customization file in ALSA profile-sets wrongly packaged

[Sander van Grieken]

On donderdag 15 februari 2024 15:43:47 CET Dylan Aïssi wrote:
> Hi,
> 
> Le mer. 14 févr. 2024 à 13:45, Sander van Grieken
>  a écrit :
> >
> > The file /usr/share/alsa-card-profile/mixer/profile-sets/-custom.conf,
> > which is packaged as part of pipewire-bin and intended to be customized by 
> > the
> > user, is packaged in a way that it is overwritten by upgrades.
> >
> > The file -custom.conf should not be included, or included with a 
> > different
> > name, e.g. -custom.conf.example
> >
> 
> This file/feature was implemented with the idea of using dpkg-divert on it, 
> see
> https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/1686
> 
> Any reason of not using dpkg-divert?

Not really, just unusual, as I haven't really needed to use dpkg-divert before, 
probably because it's rare
to have config files outside the usual locations.

Using dpkg-divert is fine. Maybe adding a single comment line mentioning 
dpkg-divert in /usr/share/alsa-card-profile/mixer/profile-sets/default.conf, 
just above the include of -custom.conf would be helpful.

grtz,
Sander

Bug#1064008: vncsnapshot: Recommends vnc4server but unable to find a Provides: vnc4server

[Tj]

Source: vncsnapshot
Version: 1.2a-5.2 
Severity: normal

Whilst investigating guacamole-server I noticed that libguac-client-vnc0
and vncsnapshot recommends "vnc4server" but I've been unable to find any 
packages that
provide that.

~/tmp/debian-sid$ awk '/^Package:/{p=$0} /^Recommends: .*vnc4server/{print p; 
print $0} /^Package: vnc4server/{print $0}' var/lib/apt/lists/deb.debian.org_de 
  bian_dists_sid_main_binary-amd64_Packages
Package: libguac-client-vnc0
Recommends: vnc4server
Package: vncsnapshot
Recommends: vnc4server | tightvncserver

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Dirk Hünniger]

Hi,

If I have the choice, I would go for the second solution. So tell the 
system to build on all architectures and remove the runtime dependency 
to chromium on s390x armel and mips64el . I think mediawiki2latex can 
still be used in a practical way even if chromium is not available. For 
many years mediawiki2latex was used without any option to use chromium 
any way. I am not sure if Georges knows the syntax to add such an 
architecture qualified depends on chromium. I didn't find any out in a 
quick internet search. So could you Paul please post some information on 
how to do that. Maybe an example.


Yours Dirk

On 15.02.24 15:33, Paul Gevers wrote:

Hi,

On 15-02-2024 08:40, Dirk Hünniger wrote:
So it still wants to build on s390x armel and mips64el. Possibly its 
not possible to drop support for an architecture that once was 
supported.


This is not the solution *I* had in mind. I was thinking about just 
adding an architecture qualified depends on chromium, not only build 
on the non-chromium architectures. If you want to continue the current 
route, instead of hardcoding the architectures, I would add a 
*build*-depends on chromium to prevent building on architectures where 
it's not available. Then the package automatically builds on those 
once chromium becomes available.


Once an architecture builds successfully, it requires actions from 
ftp-master to remove the binaries. So, $(reportbug ftp.debian.org) if 
the architectures are fully unsupported.


So possible we need to tell the system that it can still build on all 
architectures, but the the dependency to chromium is only needed on 
all architectures but s390x armel and mips64el


That's what I had in mind indeed.

Paul

Bug#1064007: Recommends vnc4server but cannot find any package doing Provides: vnc4server

[Tj]

Package: libguac-client-vnc0
Version: 1.3.0-1.1+b3
Severity: normal

Whilst investigating guacamole-server I noticed that libguac-client-vnc0
recommends "vnc4server" but I've been unable to find any packages that
provide that.

~/tmp/debian-sid$ awk '/^Package:/{p=$0} /^Recommends: .*vnc4server/{print p; 
print $0} /^Package: vnc4server/{print $0}' 
var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_binary-amd64_Packages
Package: libguac-client-vnc0
Recommends: vnc4server
Package: vncsnapshot
Recommends: vnc4server | tightvncserver

Bug#1063914: nvidia-graphics-drivers-tesla 525.147.05-7~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1063914 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-tesla
Version: 525.147.05-7~deb12u1

Explanation: restore compatibility with newer Linux kernel builds

Bug#1063898: pipewire-bin: customization file in ALSA profile-sets wrongly packaged

[Dylan Aïssi]

Hi,

Le mer. 14 févr. 2024 à 13:45, Sander van Grieken
 a écrit :
>
> The file /usr/share/alsa-card-profile/mixer/profile-sets/-custom.conf,
> which is packaged as part of pipewire-bin and intended to be customized by the
> user, is packaged in a way that it is overwritten by upgrades.
>
> The file -custom.conf should not be included, or included with a different
> name, e.g. -custom.conf.example
>

This file/feature was implemented with the idea of using dpkg-divert on it, see
https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/1686

Any reason of not using dpkg-divert?

Best regards,
Dylan

Bug#1063881: nvidia-graphics-drivers: provide dependency package to catch all packages of given version

[Drew Parsons]

On 2024-02-15 14:20, Andreas Beckmann wrote:

On 14/02/2024 00.37, Drew Parsons wrote:

It would be much easier to switch between versions in unstable and
experimental, or upgrade from experimental, if there were a dummy
dependency package that depends on all the manifold nvidia component
packages for the given version.  It could be called nvidia-driver-all,
for instance.  Then only the one package needs to be marked for
upgrade (or downgrade) and will bring in all the others.

Can it be done?


Yes. I'd probably call it nvidia-driver-full (as in texlive-full)
since -all could be mistaken as 'installs all (supported) driver
series'.


That sounds sensible.


And you would want hard Depends and no Recommends ?


I think it would need to be a hard Depends.  Otherwise a Recommends 
would only activate once the first time the dependency package is 
installed. Since it's not mandatory, it wouldn't succeed in maintaining 
consistent versions when upgrading or downgrading.  A Recommends (=) 
together with a Conflicts would not work since the versioned 
dependencies don't have a != operator to use with Conflicts.



Is there anything that should be excluded?


Only question I can think of for exclusion is whether cuda should be 
included. For sure not everyone who would want the driver upgrade would 
necessarily want cuda as well, in the sense that they simply aren't 
using cuda.   So one option is make two dependency packages, 
nvidia-driver-full for the drivers without cuda, and nvidia-cuda-full 
(or just cuda-full) for the cuda components.  I guess nvidia-opencl-icd 
(nvidia-opencl-common) might belong in nvidia-driver-full since it's 
kind of a "conflict of interest" to put it with cuda.


Two dependency packages like this would meet requirements fine I think.  
But if it's too much trouble to split them that way and you'd prefer one 
dependency package, then I'd suggest including the cuda packages in it.



Are there any binary packages from different source packages that
should be included as well? Mainly thinking about bits that are
included in the .run file but since source is available, we build it
from source instead. nvidia-settings, nvidia-xconfig,
nvidia-persistenced?


I don't think the dependency package would need to set external 
dependencies.  The actual binary packages would bring these in as needed 
in their own Dependencies.  The dependency package would just need to 
make sure all the nvidia package versions remain in step.


Drew

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Paul Gevers]

Hi,

On 15-02-2024 08:40, Dirk Hünniger wrote:
So it still wants to build on s390x armel and mips64el. Possibly its not 
possible to drop support for an architecture that once was supported.


This is not the solution *I* had in mind. I was thinking about just 
adding an architecture qualified depends on chromium, not only build on 
the non-chromium architectures. If you want to continue the current 
route, instead of hardcoding the architectures, I would add a 
*build*-depends on chromium to prevent building on architectures where 
it's not available. Then the package automatically builds on those once 
chromium becomes available.


Once an architecture builds successfully, it requires actions from 
ftp-master to remove the binaries. So, $(reportbug ftp.debian.org) if 
the architectures are fully unsupported.


So possible we need to tell the system that it can still build on all 
architectures, but the the dependency to chromium is only needed on all 
architectures but  s390x armel and mips64el


That's what I had in mind indeed.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060042: qemu-efi-aarch64: Saving OVMF configuration changes fail

[dann frazier]

On Thu, Feb 15, 2024 at 10:06:35AM +, Simon John wrote:
> I have the same problem when changing settings or even
> starting an existing aarch64 VM in virt-manager, the error
> I get is:
> 
> Error starting domain: operation failed: Unable to find
> 'efi' firmware that is compatible with the current
> configuration
> 
> Downgrading to qemu-efi-aarch64_2023.11-6_all.deb and
> qemu-efi-arm_2023.11-6_all.deb fixes the issue, so the
> breakage is in -7

Hi Simon,

I see nothing in common between the issue you are describing and
this bug. Please report a new issue.

  -dann

Bug#1064006: src:user-mode-linux: unsatisfied build dependency in testing: linux-source-6.5

[Paul Gevers]

Source: user-mode-linux
Version: 6.5um1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064005: netcfg: "get_netmask string 255.255.255.255" not working

[Arzhel Younsi]

Source: netcfg
Version: 1.187
Severity: normal

Dear Maintainer,

Setting a netmask of 255.255.255.255 (in my case using preseed, but I guess the 
same happens if using the UI)
fails the installer with Unreachable gateway (even if the gateway is set).
I agree it can be seen as an odd setup, but it's valid and works when 
configured manually in busybox and Linux.
My usecase is creating routed Debian VMs, where the host have a static route to 
the guest's IP (or v6 /128).
With a smaller subnet (like /23), we would have to use proxy ARP which is 
usually not recommended.

You can see more information in:
https://phabricator.wikimedia.org/phame/post/view/312/ganeti_on_modern_network_design/

My current workaround is to use a smaller netmask then run the following in 
early_command:
IFACE=$(ip -4 route list 0/0 | sed -r 's/.*dev ([^ ]*) .*/\1/' | head -1)
IP="$(ip address show dev $IFACE | egrep '^[[:space:]]+inet ' | cut -d ' ' -f 6 
| cut -d '/' -f 1)"
ip addr del $IP dev $IFACE
ip addr add $IP/32 dev $IFACE
ip route add 10.192.24.1 dev $IFACE scope link
ip route add default via 10.192.24.1

Right after "netcfg"
It would of course be cleaner if netcfg were to handle a /32 "out of the box".

Similarly, DHCP can allocate such IPs, see for example :
https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/
I haven't tested DHCP in Debian Installer with such setup though.

Please let me know if I can be of any help.

Thanks

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/1 CPU thread; 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)

Bug#1064004: src:cross-toolchain-base-ports: unsatisfied build dependency in testing: linux-source-6.5 (>= 6.5.8)

[Paul Gevers]

Source: cross-toolchain-base-ports
Version: 64
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064003: src:cross-toolchain-base: unsatisfied build dependency in testing: linux-source-6.5 (>= 6.5.8)

[Paul Gevers]

Source: cross-toolchain-base
Version: 68
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063370: vulkan-tools: Fails to build from source.

[Diederik de Haas]

Control: tag -1 upstream fixed-upstream

On Tue, 06 Feb 2024 13:45:14 -0800 Elizabeth Loss-Cutler-Hull 
 wrote:
> Package: vulkan-tools
> Version: 1.3.268.0+dfsg1-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> In file included from /<>/vulkaninfo/vulkaninfo.cpp:33:
> /<>/vulkaninfo/generated/vulkaninfo.hpp: In function 
> ‘std::vector 
> VkVideoCodecOperationFlagBitsKHRGetStrings(VkVideoCodecOperationFlagBitsKHR)’:
> /<>/vulkaninfo/generated/vulkaninfo.hpp:1337:9: error: 
> ‘VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_EXT’ was not declared in this 
> scope; did you mean ‘VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_KHR’?
>  1337 | if (VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_EXT & value) 
> strings.push_back("VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_EXT");
>   | ^~~~
>   | VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_KHR
> /<>/vulkaninfo/generated/vulkaninfo.hpp:1338:9: error: 
> ‘VK_VIDEO_CODEC_OPERATION_ENCODE_H265_BIT_EXT’ was not declared in this 
> scope; did you mean ‘VK_VIDEO_CODEC_OPERATION_ENCODE_H265_BIT_KHR’?
>  1338 | if (VK_VIDEO_CODEC_OPERATION_ENCODE_H265_BIT_EXT & value) 
> strings.push_back("video_codec_operation_encode_h265_bit_ext");
>   | ^~~~
>   | vk_video_codec_operation_encode_h265_bit_khr
> 
> i confirmed that building through sbuild in a sid chroot behaves exactly
> the same way as building on my sid machine.
> 
> ...
> -- system information:
> ii  libvulkan1  1.3.275.0-1

The mismatch between 1.3.268 and 1.2.275 is likely the problem.
https://github.com/KhronosGroup/Vulkan-Tools/commit/64d9218726083ece79099341249890c75a5c4491
is where this issue was fixed and that commit is part of 1.3.274 (and higher).

If you downgrade src:vulkan-loader to 1.3.268.0-1 then it should compile again.

Looks like the vulkan-sdk versions need to be in sync.


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

Bug#1064002: ITP: ocaml-crunch -- convert a filesystem into a static OCaml module

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-crunch
  Version : 3.3.1
  Upstream Contact: Anil Madhavapeddy
* URL : https://github.com/mirage/ocaml-crunch
* License : ISC
  Programming Lang: OCaml
  Description : convert a filesystem into a static OCaml module

 ocaml-crunch takes a directory of files and compiles them into a
 standalone OCaml module which serves the contents directly from
 memory. This can be convenient for libraries that need a few embedded
 files (such as a web server) and do not want to deal with all the
 trouble of file configuration.

This package is a new dependency of ocaml-odoc. Il will be maintained
in the OCaml team.

Bug#1064001: cme removing a valid testsuite for python packages

[Lin Qigang]

Package: cme
Version: 1.040-1
Severity: normal
Tags: sid

I noticed an issue when running routine-update (0.1.5) on some python 
packages, but I do not think it is an error in the routine-update script 
exactly. It seems that cme is removing the testsuite for 
autopkgtest-pkg-pybuild from packages. presto [1] is a good example 
package to reproduce this. Running the following in the packages root 
directory should reproduce this bug:


```
$ cme fix dpkg-control
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Warning in 'source Testsuite': Unknown value
Offending value: 'autopkgtest-pkg-pybuild'

Changes applied to dpkg-control configuration:
- source Testsuite deleted value: 'autopkgtest-pkg-pybuild' # applied 
fix for :Unknown value

```

After this, routine-update adds in a testsuite for 
autopkgtest-pkg-python, since no testsuite is present.


[1] https://salsa.debian.org/med-team/presto

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


OpenPGP_0x903649294C33F9B7.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063999: libhdf4-0-alt: is not multi-arch compatible

[Sebastiaan Couwenberg]

Control: tags -1 pending

Thanks for the patch, it's applied in git.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Andreas Beckmann]

On 14/02/2024 11.01, Jonathan Wiltshire wrote:

On Sun, Feb 11, 2024 at 11:23:00PM +0100, Andreas Beckmann wrote:

We need to push 4 packages together to stable-updates:
nvidia-graphics-drivers
nvidia-settings
nvidia-graphics-drivers-tesla-470
nvidia-graphics-drivers-tesla


According to my list there's just nvidia-graphics-drivers-tesla missing
now; does that match yours?


Seems installable in sid now, so just uploaded to PU. These 4 should be 
ready for stable-updates.


Andreas

Bug#1064000: unzip: Unzip fails on Microsoft ZIP64 files

[Marc Deslauriers]

Package: unzip
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch




*** /tmp/tmp5xum1hdh/bug_body

unzip rejects Microsoft OneDrive zip files. See the detailed explanation here:

https://www.bitsgalore.org/2020/03/11/does-microsoft-onedrive-export-large-ZIP-files-that-are-corrupt

tl;dr;
Microsoft mishandles the "Total number of disks" field when using the ZIP64 
extension. It should start at 1, they use 0, which isn't a valid value. Unzip 
doesn't properly handle the invalid value.


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


  * Properly handle Microsoft ZIP64 file (LP: #2051952)
- debian/patches/handle_windows_zip64.patch: ignore invalid "Total
  number of disks" field in process.c.


Thanks for considering the patch.


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

Kernel: Linux 6.1.0-1029-oem (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru unzip-6.0/debian/patches/handle_windows_zip64.patch 
unzip-6.0/debian/patches/handle_windows_zip64.patch
--- unzip-6.0/debian/patches/handle_windows_zip64.patch 1969-12-31 
19:00:00.0 -0500
+++ unzip-6.0/debian/patches/handle_windows_zip64.patch 2024-02-01 
10:48:08.0 -0500
@@ -0,0 +1,18 @@
+Description: Properly handle Microsoft ZIP64 file by ignoring invalid
+ "Total number of disks" field
+Origin: https://sourceforge.net/p/infozip/bugs/42/
+Bug: https://sourceforge.net/p/infozip/bugs/42/
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/2051952
+Author: Roy Tam
+
+--- a/process.c
 b/process.c
+@@ -1281,7 +1281,7 @@ static int find_ecrec64(__G__ searchlen)
+ fprintf(stdout,"\nnumber of disks (ECR) %u, (ECLOC64) %lu\n",
+ G.ecrec.number_this_disk, ecloc64_total_disks); fflush(stdout);
+ #endif
+-if ((G.ecrec.number_this_disk != 0x) &&
++if ((G.ecrec.number_this_disk != 0x) && ecloc64_total_disks &&
+ (G.ecrec.number_this_disk != ecloc64_total_disks - 1)) {
+   /* Note: For some unknown reason, the developers at PKWARE decided to
+  store the "zip64 total disks" value as a counter starting from 1,
diff -Nru unzip-6.0/debian/patches/series unzip-6.0/debian/patches/series
--- unzip-6.0/debian/patches/series 2023-05-30 06:34:18.0 -0400
+++ unzip-6.0/debian/patches/series 2024-02-01 10:46:59.0 -0500
@@ -27,3 +27,4 @@
 26-cve-2019-13232-fix-bug-in-uzinflate.patch
 27-zipgrep-avoid-test-errors.patch
 28-cve-2022-0529-and-cve-2022-0530.patch
+handle_windows_zip64.patch