Bug#1026696: golang-github-prometheus-client-model: FTBFS: make: *** [debian/rules:6: binary] Error 25

[Shengjing Zhu]

On Thu, Dec 22, 2022 at 02:46:49PM +1300, Daniel Swarbrick wrote:
> Updating the 01-Use_go_generate.patch as follows results in a successful
> build (without needing to add golang-google-protobuf-dev as a dependency):
> 
> diff --git a/debian/patches/01-Use_go_generate.patch
> b/debian/patches/01-Use_go_generate.patch
> index cafa5e2..ffa83cf 100644
> --- a/debian/patches/01-Use_go_generate.patch
> +++ b/debian/patches/01-Use_go_generate.patch
> @@ -6,4 +6,4 @@ Description: Use go generate to avoid depending on special
> make rules in
>  @@ -0,0 +1,3 @@
>  +package io_prometheus_client
>  +
> -+//go:generate protoc --proto_path=../io/prometheus/client
> --go_out=paths=source_relative:. metrics.proto
> ++//go:generate protoc --proto_path=../io/prometheus/client 
> --go_out=paths=source_relative,Mgoogle/protobuf/timestamp.proto=github.com/golang/protobuf/ptypes/timestamp:.
> metrics.proto
> 
> However, the generated metrics.pb.go still uses *timestamppb.Timestamp for
> the timestamp fields, which will cause undesirable side-effects on
> downstream packages.
> 
> I am not aware of any way to influence protoc to use the old timestamp type.

Hmm, this works for me, the generated pb.go uses old timestamp type.
I have added above change and built the package, then checked the result.

Bug#1025119: python-ratelimiter: (autopkgtest) needs update for python3.11: module 'asyncio' has no attribute 'coroutine'

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/RazerM/ratelimiter/issues/18

Bug#1026838: cryptsetup: Can't compile it twice with unrepresentable changes to source errors

[Guilhem Moulin]

Control: tag -1 = pending

On Thu, 22 Dec 2022 at 12:56:10 +1100, Russell Coker wrote:
> I run dpkg-buildpackage twice and I get the following errors:
> […]
> The following patch allows it to build twice.

Fixed using d/clean instead:
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/fa7ea7ec4ee02d6320216bdd282355e5f3695a74

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1026842: RM: asmjit [mipsel] -- ROM; FTBFS due to OOM

[Andrius Merkys]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove asmjit binaries for mipsel. The build has increased its 
RAM consumption and mipsel buildd does not seem to handle that much anymore.


Andrius

Bug#1026666: Please make liblog4j2-java depend on junit5

[Pierre Gruet]

Hi tony,

Le 21/12/2022 à 22:58, tony mancill a écrit :

On Tue, Dec 20, 2022 at 11:45:54PM +0100, Pierre Gruet wrote:

Control: retitle -1 Please make liblog4j2-java depend on junit5

Hello,

In version 2.19.0-1 of liblog4j2-java, the file

/usr/share/maven-repo/org/apache/logging/log4j/log4j/debian/log4j-debian.pom
declares the junit-bom artifact as a dependency. It is shipped in junit5.

If this dependency is not added, reverse dependencies of liglog4j2-java fail
to build (see logs above) as the junit-bom artifact is not found.


Hi Pierre,

I'm wondering if it wouldn't better to remove junit-bom from log4j pom.
I don't believe we actually need junit5 at runtime for log4j2, so
packages depending on liblog4j2-java should not have to install junit5.

Any concerns with taking that approach and addressing the bug by
adjusting the pom shipped with liblog4j2-java?


Thanks for having a look; I haven't looked further but I also fail to 
imagine why junit5 would be needed, so I agree with the proposed fix!




Thanks,
tony


Cheers,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002470: opensearch: RFP -> ITP

[Andrius Merkys]

Control: retitle -1 ITP: opensearch -- search engine, fork of Elasticsearch
Control: owner -1 !

Hello,

I had some success in building OpenSearch with Debian-provided 
dependencies. Some parts of the source had to be skipped, but not much. 
I will push my packaging to salsa once I figure out the source does not 
contain anything non-free.


Andrius

Bug#1021980: RFP: libonvif -- ONVIF client access library and tools

[Petter Reinholdtsen]

The package is currently in NEW, waiting for approval.  Upstream and I
have worked together and I am sponsoring his upload.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1026841: RFS: dnshistory/1.3-3 [QA] [RC] -- Translating and storing of IP addresses from log files

[Bo YU]

Package: sponsorship-requests
Severity: important


Dear mentors,

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

 * Package name : dnshistory
   Version  : 1.3-3
   Upstream contact : [fill in name and email of upstream]
 * URL  : http://www.stedee.id.au/dnshistory/
 * License  : [fill in]
 * Vcs  : [fill in URL of packaging vcs]
   Section  : web

The source builds the following binary packages:

  dnshistory - Translating and storing of IP addresses from log files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.3-3.dsc

Changes since the last upload:

 dnshistory (1.3-3) unstable; urgency=medium
 .
   * QA upload.
   * Set Debian QA as maintainer. See #1001813
   * Update debhelper, fix ftbfs. (Closes: #965493)
   * Drop debian/compat
   * Set std-ver to 4.6.1
   * Remove autotools-dev in B-D
   * Add build-arch and build-indep in debian/rules
   * Drop dh_clean -k to use dh_prep instead


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1024795: python-llvmlite

[Diane Trout]

Hi,

I was trying to update numba, and need the updated version of llvmlite
built against llvm-14

The version that's currently in unstable is still built against llvml-
11

https://packages.debian.org/sid/python3-llvmlite

I've checked out out the llvmlite repository and rebuilt it locally
using commit c65b3e662b7b08920172b710419d7a06b660be59 against llvm-14

and llvmlite's test cases pass. (And most of numba's passed too. And I
think the remaining test failures aren't related to llvmlite)

Is there a chance we could get an updated version released soon?

Thanks
Diane Trout


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

Bug#1026832: wiki.debian.org: BridgeNetworkConnections wrong usage of bridge_hw parameter?

[Paul Wise]

On Wed, 2022-12-21 at 21:18 +, Steffen Dettmer wrote:


> I visited https://wiki.debian.org/BridgeNetworkConnections and read
> an example:
...
> but this does not work (for me on 1 host tested only).

Please contact our support channels for help using Debian:

https://www.debian.org/support

Once the correct solution has been found, please register an account in
order to edit and correct the content of the Debian wiki.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1026362: Upload of binutils-sh-elf

[John Scott]

Hi,

So, my package got auto-rejected. I talked to the FTP Masters, and
they'd much rather that a workaround be incorporated into my package
than them having to manually make it pass through. I've uploaded the
one-line change to mentors.debian.net; if you could upload it once more,
there shouldn't be any problems now.

Thank you,
John


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

Bug#983539: Lintian bug causes non-overridable rejection of packages

[John Scott]

Control: affects -1 ftp.debian.org

This caused my package to get rejected, and Lintian overrides cannot be
used to mitigate it.


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

Bug#1025951: comment

[Thomas Lange]

You are right, it makes no sense to keep this patch. My justification
for the patch was wrong. I will fix that.
-- 
viele Grüße Thomas

Bug#1026840: Apt-Setup udeb package bug in mirror configuration script

[Smith, Brett A]

Package: apt-mirror-setup
Version: 0.166

Description:
Affected file: ./usr/lib/apt-setup/generators/50mirror
Line(s): 273
General:
When using a preseeded installation on Debian 11.6 using netboot, with the 
following line added:

Apt-mirror-setup apt-setup/mirror/error select Ignore

The Debian installer ends up in an loop because line 273 of 50mirror sets the 
error setting to Retry:

db_set apt-setup/mirror/error Retry
db_input critical apt-setup/mirror/error || true
db_go || exit 10
db_get apt-setup/mirror/error
if [ "$RET" = "Change mirror" ]; then
choose-mirror -n || true
db_capb backup progresscancel
elif [ "$RET" = Ignore ]; then
exit 1
fi

As a result, the option to ignore an error in the mirrors configuration is 
ignored and the installer never completes. This is problematic for a fully 
automated preseed installation of many nodes, as it requires console access on 
each node to fix. Usually our method of fixing has been to import our own 
repositories gpg key (as we aren't using a mirror, we are using our own local 
mirror copy from dvd media where we have to sign the Packages file with our own 
key. This is listed as an issue for others, but we accept that it would be 
technically problematic to have the DVD/CD build servers have access to the 
private signing key to put the gpg keys into the media). We can't use reprepro 
to make a repo either. Our implementation "challenges" aside, it is a bug in 
this file and I believe could be corrected by removing the offending line. It 
appears like a debug line was accidentally committed.

This bug is also present in the most recent unstable release of this package  - 
0.172. I cannot see when this bug was introduced as I honestly don't know how 
Debian's git repositories work or where they are located. I am sure this is 
documented, I am just unfamiliar is all.

Of note, this script seems to ignore settings apt-setup/no_mirror and 
apt-setup/use_mirror unless it is a cdrom installation. This is also 
potentially a bug or it could be a misunderstanding on usage of the parameters 
in the preseed, but, I think it's outside of scope of what I am raising here.

Cheers,
Brett

Bug#1026839: systemd: kills --user services after logging out

[Philippe Cerfon]

Package: systemd
Version: 252.3-2
Severity: normal

Hey.

What I do is about the following:

I log on via SSH to some node, and a "special" remote command starts a
VNC server as systemd --user service and upon certain signals it stops
it, while on HUP it just exits.
The idea is that in the HUP case one likely wants to keep the VNC
server running, so that it can be later re-connected to.

Now this works fine with e.g. SUSE's 246.16 systemd, but already fails
with the systemd in bullseye.

What seems to happen is that just a while after SSH's remote command
has exited, systemd kills off the whole --user session.

After googling a bit I found:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394
and already though that this would be what happens.

But as far as I understand the default was actually reverted to not
kill user processes, and that's also what loginctl show-seat shows.

My SSH remote commands looks like this:
Host VNC_example.org
HostNameexample.org
LocalForwardlocalhost:51006 localhost:5903
StreamLocalBindUnlink   yes
ExitOnForwardFailureyes
ControlPath none
RequestTTY  force
RemoteCommand   displaynumber=3;
id="${LOGNAME}"; trap -- 'trap -- - EXIT INT TERM QUIT; exit 0' HUP;
trap -- 'exit 0' INT TERM QUIT; trap -- "systemctl --quiet --user
is-active \"tigervncserver@:\${displaynumber}_\${id}.service\"; [
\"\$?\" -ne 3 ]  &&  systemctl --user stop
\"tigervncserver@:\${displaynumber}_\${id}.service\"; exit 0" EXIT;
systemctl --quiet --user is-active
"tigervncserver@:${displaynumber}_${id}.service"  &&  printf '%%sVNC
server (`%%s`) already running and re-used.%%s\n' "$(tput setaf 6
2>/dev/null)" "tigervncserver@:${displaynumber}.service" "$(tput sgr0
2>/dev/null)" >&2  ||   { systemd-run --quiet --user --no-ask-password
--unit="tigervncserver@:${displaynumber}_${id}.service" --collect
--service-type=exec --working-directory="${HOME}" tigervncserver
":${displaynumber}" -fg  &&  printf '%%sVNC server (`%%s`)
started.%%s\n' "$(tput setaf 2 2>/dev/null)"
"tigervncserver@:${displaynumber}.service" "$(tput sgr0 2>/dev/null)"
>&2; }; while true; do sleep 6; systemctl --quiet --user is-active
"tigervncserver@:${displaynumber}_${id}.service"  ||  exit 0; done

A bit easier to read:
displaynumber='';
vncserver_extra_options="";
unit_name_suffix="%C";
trap -- 'trap -- - EXIT INT TERM QUIT;
 exit 0'
 HUP;
trap -- 'exit 0' INT TERM QUIT;
trap -- "systemctl --quiet --user is-active
\"tigervncserver@:\${displaynumber}_\${unit_name_suffix}.service\";
 [ \"\$?\" -ne 3 ]  &&  systemctl --user stop
\"tigervncserver@:\${displaynumber}_\${unit_name_suffix}.service\";
 exit 0"
 EXIT;
systemctl --quiet --user is-active
"tigervncserver@:${displaynumber}_${unit_name_suffix}.service"  &&
printf '%%sVNC server (`%%s`) already running and re-used.%%s\n'
"$(tput setaf 6 2>/dev/null)"
"tigervncserver@:${displaynumber}.service" "$(tput sgr0 2>/dev/null)"
>&2  ||
{ systemd-run --quiet --user --no-ask-password
--unit="tigervncserver@:${displaynumber}_${unit_name_suffix}.service"
--collect --service-type=exec --working-directory="${HOME}"
tigervncserver ":${displaynumber}" -fg ${vncserver_extra_options}  &&
printf '%%sVNC server (`%%s`) started.%%s\n' "$(tput setaf 2
2>/dev/null)" "tigervncserver@:${displaynumber}.service" "$(tput sgr0
2>/dev/null)" >&2; };
while true; do
sleep 60;
systemctl --quiet --user is-active
"tigervncserver@:${displaynumber}_${unit_name_suffix}.service"  ||
exit 0;
done



journal log after the SSH disconnect (which I do via ~. for a HUP):
Dec 22 03:01:33 example.org sshd[3409]: Received disconnect from
2003:... port 55458:11: disconnected by user
Dec 22 03:01:33 example.org sshd[3409]: Disconnected from user user
2003:... port 55458
Dec 22 03:01:33 example.org sshd[3386]: pam_unix(sshd:session):
session closed for user user
Dec 22 03:01:33 example.org systemd-logind[579]: Session 5 logged out.
Waiting for processes to exit.
Dec 22 03:01:36 example.org systemd[1]: session-5.scope: Deactivated
successfully.
Dec 22 03:01:36 example.org systemd-logind[579]: Removed session 5.
Dec 22 03:01:46 example.org systemd[1]: Stopping User Manager for UID 1000...
Dec 22 03:01:46 example.org systemd[3389]: Activating special unit
Exit the Session...
Dec 22 03:01:46 example.org systemd[3389]: Stopped target Main User Target.
Dec 22 03:01:46 example.org systemd[3389]: Stopping D-Bus User Message Bus...
Dec 22 03:01:46 example.org systemd[3389]: Stopping
/usr/bin/tigervncserver :3 -fg...
Dec 22 03:01:46 example.org systemd[3389]: Stopped D-Bus User Message Bus.
Dec 22 03:01:46 example.org systemd[3389]: Removed slice User Core
Session Slice.
Dec 22 03:01:46 example.org tigervncserver[3413]: Killing Xtigervnc
process ID 3428... success!
Dec 22 03:01:46 example.org systemd[3389]: Stopped

Bug#1026838: cryptsetup: Can't compile it twice with unrepresentable changes to source errors

[Russell Coker]

Package: cryptsetup
Version: 2:2.6.0-2
Severity: normal
Tags: ftbfs patch

I run dpkg-buildpackage twice and I get the following errors:
dpkg-source: error: cannot represent change to po/sr.gmo: binary file contents 
changed
dpkg-source: error: add po/sr.gmo in debian/source/include-binaries if you want 
to store the modified binary in the debian tarball
dpkg-source: error: cannot represent change to po/sv.gmo: binary file contents 
changed
dpkg-source: error: add po/sv.gmo in debian/source/include-binaries if you want 
to store the modified binary in the debian tarball
dpkg-source: error: cannot represent change to po/uk.gmo: binary file contents 
changed
dpkg-source: error: add po/uk.gmo in debian/source/include-binaries if you want 
to store the modified binary in the debian tarball
dpkg-source: error: cannot represent change to po/vi.gmo: binary file contents 
changed
dpkg-source: error: add po/vi.gmo in debian/source/include-binaries if you want 
to store the modified binary in the debian tarball
dpkg-source: error: cannot represent change to po/zh_CN.gmo: binary file 
contents changed
dpkg-source: error: add po/zh_CN.gmo in debian/source/include-binaries if you 
want to store the modified binary in the debian tarball
dpkg-source: error: unrepresentable changes to source
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 1

The following patch allows it to build twice.

--- cryptsetup-2.6.0.bak/debian/rules   2022-11-30 01:42:25.0 +1100
+++ cryptsetup-2.6.0/debian/rules   2022-12-22 12:47:59.960788266 +1100
@@ -80,6 +80,8 @@
if [ -f $(CURDIR)/debian/cryptsetup-initramfs.preinst.in ]; then \
mv -fT $(CURDIR)/debian/cryptsetup-initramfs.preinst.in 
$(CURDIR)/debian/cryptsetup-initramfs.preinst; \
fi
+   rm -f po/*.gmo po/stamp-po
+   rm -f man/*.8
 
 override_dh_bugfiles:
dh_bugfiles -A

-- Package-specific info:

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:2.6.0-2
ii  debconf [debconf-2.0]  1.5.80
ii  dmsetup2:1.02.185-2
ii  libc6  2.36-6

cryptsetup recommends no packages.

Versions of packages cryptsetup suggests:
ii  cryptsetup-initramfs2:2.6.0-2
ii  dosfstools  4.2-1
ii  keyutils1.6.3-1
ii  liblocale-gettext-perl  1.07-5

-- debconf information excluded

Bug#1026696: golang-github-prometheus-client-model: FTBFS: make: *** [debian/rules:6: binary] Error 25

[Daniel Swarbrick]

Updating the 01-Use_go_generate.patch as follows results in a successful 
build (without needing to add golang-google-protobuf-dev as a dependency):


diff --git a/debian/patches/01-Use_go_generate.patch 
b/debian/patches/01-Use_go_generate.patch

index cafa5e2..ffa83cf 100644
--- a/debian/patches/01-Use_go_generate.patch
+++ b/debian/patches/01-Use_go_generate.patch
@@ -6,4 +6,4 @@ Description: Use go generate to avoid depending on 
special make rules in

 @@ -0,0 +1,3 @@
 +package io_prometheus_client
 +
-+//go:generate protoc --proto_path=../io/prometheus/client 
--go_out=paths=source_relative:. metrics.proto
++//go:generate protoc --proto_path=../io/prometheus/client 
--go_out=paths=source_relative,Mgoogle/protobuf/timestamp.proto=github.com/golang/protobuf/ptypes/timestamp:. 
metrics.proto


However, the generated metrics.pb.go still uses *timestamppb.Timestamp 
for the timestamp fields, which will cause undesirable side-effects on 
downstream packages.


I am not aware of any way to influence protoc to use the old timestamp type.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024811: linux: /proc/[pid]/stat unparsable

[Thorsten Glaser]

On Sat, 26 Nov 2022, Alexey Dobriyan wrote:

>/proc never escaped "comm" field of /proc/*/stat.

Yes, that’s precisely the bug.

>To parse /proc/*/stat reliably, search for '(' from the beginning, then
>for ')' backwards. Everything in between parenthesis is "comm".

That’s not guaranteed to stay reliable: fields can be, and have
been in the past, added, and new %s fields will break this. Do
not rely on it either.

>Everything else are numbers separated by spaces.

Currently, yes.

But the field is *clearly* documented as intended to be
parsable by scanf(3), which splits on white space. So the
Linux kernel MUST encode embedded whitespace so the
documented(!) access method works.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1026804: WIFI doesn't work for kernel 6.1

[Zhang Ning]

On Wed, Dec 21, 2022 at 05:29:25PM +0100, Diederik de Haas wrote:
> On Wednesday, 21 December 2022 17:11:55 CET Diederik de Haas wrote:
> > Given that it worked with 6.0 but no more with 6.1-1~exp1 which I assume is
> > a self-built kernel from current master, it seems more likely to be an
> > upstream issue/regression.
> 
> I just noticed the following part from that linux-amlogic post:
> > I native build kernel from debian's kernel repo:
> > https://salsa.debian.org/kernel-team/linux/ with some Amlogic patches:
> > https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/feat
> > ures/arm64/meson all follow debian's kernel config.
original patches are:
https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/features/npu
and
0001, 0002, 0004, 0005, 0006, 0007, 0021, 0022, 0037 in
https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/features/khadas

> 
> That path doesn't seem to exist anymore, but got redirected to 'just' the 
> master branch and noticed the latest commit "update patches from khadas".
> When I looked into that, I saw there were a LOT of additional patches :-O
> https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/
> features/khadas

I just want to apply all vendor patches to check whether wifi works.

you can review all patches, it not related to WIFI, thus I don't think
WIFI could magicly work.

> 
> The test I suggested in my previous reply would still be useful, but it could 
> also be that your patch-set is at fault.
this is reasonable suspect.

I also use default debian kernel:
https://packages.debian.org/experimental/arm64/linux-image-6.1.0-0-arm64/download
WIFI stop work in 2mins. Logs are same, I don't duplicate.

Default debian kernel 6.0 is good, and 6.1 is bad, this is a regression.

upstream and vendor said they didn't see this issue, thus report to
debian for help.

BR.
Ning.

Bug#1026804: WIFI doesn't work for kernel 6.1

[Zhang Ning]

On Wed, Dec 21, 2022 at 05:29:25PM +0100, Diederik de Haas wrote:
> On Wednesday, 21 December 2022 17:11:55 CET Diederik de Haas wrote:
> > Given that it worked with 6.0 but no more with 6.1-1~exp1 which I assume is
> > a self-built kernel from current master, it seems more likely to be an
> > upstream issue/regression.
> 
> I just noticed the following part from that linux-amlogic post:
> > I native build kernel from debian's kernel repo:
> > https://salsa.debian.org/kernel-team/linux/ with some Amlogic patches:
> > https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/feat
> > ures/arm64/meson all follow debian's kernel config.
These patches are confirmed not related this issue.
> 
> That path doesn't seem to exist anymore, but got redirected to 'just' the 
> master branch and noticed the latest commit "update patches from khadas".
> When I looked into that, I saw there were a LOT of additional patches :-O
> https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/
> features/khadas


khadas is the vendor, I tried to apply vendor's patches to make wifi
work.

you can just use default debian 6.1 kernel, to reproduce the issue.

> 
> The test I suggested in my previous reply would still be useful, but it could 
> also be that your patch-set is at fault.

Bug#1026114: RFS: ruby-mdl/1.0-1 [ITP] -- Markdown lint tool

[Norwid Behrnd]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ruby-mdl":

 * Package name : ruby-mdl
   Version  : 0.12.0-1
   Upstream contact : ["p...@ipom.com"]
 * URL  : https://github.com/markdownlint/markdownlint
 * License  : MIT
 * Vcs  : https://salsa.debian.org/ruby-team/ruby-mdl
   Section  : ruby

The source builds the following binary packages:

  ruby-mdl - Markdown lint tool

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

  https://mentors.debian.net/package/ruby-mdl/

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

  dget -x
  https://mentors.debian.net/debian/pool/main/r/ruby-mdl/ruby-mdl_0.12.0-1.dsc

Changes for the initial release:

 ruby-mdl (0.12.0-1) unstable; urgency=medium
 .
   * Initial release of ruby-mdl for Debian. (Closes: #1026114)

Regards,
-- 
  Norwid Behrnd

Bug#1022573: procps transition status at Dec 22

[Craig Small]

#1024218 - apitrace - patch available
#1024219 - cpu-x - patch available at upstream git
#1024220 - deepin-screen-recorder - nil
#1024221 - intel-gpu-tools - patch available upstream, version issues
#1024223 - obs-advanced-scene-switcher - Done!
#1024224 - openscap - Done!
#1024225 - veyon - nil

I have patches for all but some cannot be tested due to the odd way their
build systems work.

Bug#1022573: transition: procps

[Craig Small]

(added the bug report for igt)
On Thu, 22 Dec 2022 at 08:29, Craig Small  wrote:

> On Thu, 22 Dec 2022 at 07:46, Paul Gevers  wrote:
>
>> An actual upload. If the maintainer isn't doing it, I think an NMU is
>> appropriate if you're sure of the fix.
>>
> Ah, I thought you were the igt maintainer :)
>
> I'll have a go recreating it and uploading it tonight. I'm pretty
> confident about the patches but don't use the package myself.
>
So the issue is that the changelog has updated the version to
1.26+git20221011-1 but this isn't uploaded or tagged.
I can either:
  Attach my patch for 1024221 to bug #1024221 and wait
  Update to 20221011 and add the patch, this both links to libproc2 and
updates the version
  Roll-back to 20220524 and add the patch, keeps the binary the same linked
to libproc2 but moves the changelog back

Ideally, I'd like 20221011 linked to libproc2 but I don't want to release a
new version of intel-gpu-tools as I'm not the maintainer and there might be
a reason its not being updated.

BUT, procps is in transition and this linking needs to happen before the
first freeze milestone so I will upload 20220525 linked to libproc2 if we
get near to running out of time.

 - Craig


>  - Craig
>
>

Bug#1026834: linux-image-5.10.0-20-amd64: no audio with device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 11)

[Diederik de Haas]

Control: reassign src:linux 5.10.158-2

On Wednesday, 21 December 2022 22:45:12 CET sapcie wrote:
> Package: linux-image-5.10.0-20-amd64
> Version: latest
> Severity: normal

Bug https://bugs.debian.org/1010733 also mentions that same audio device, 
although that seems to have failed with 5.10.0-13 already ...

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

Bug#923023: original-awk FTCBFS: builds for the wrong architecture

[Santiago Vila]

El 23/2/19 a las 7:29, Helmut Grohne escribió:

Source: original-awk
Version: 2012-12-20-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

original-awk fails to cross build from source, because the packaging
forces the build architecture compiler "gcc". Using a triplet-prefixed
compiler fixes that, but makes executing maketab fail. [...]


Hi.

The upstream makefile now has a CC and a HOSTCC for cross-builds.
So I guess now we just need to pass CC as CC and CC_FOR_BUILD as HOSTCC.

Can you try this and tell me if it works?

git clone g...@salsa.debian.org:sanvila/original-awk.git

(I've set the default branch to be a pre-release for 2022-01-22-1)

Thanks.

Bug#1026811: RFS: d11amp/0.59-1 [ITP] -- Simple MP3 player

[Soren Stoutner]

Thomas,

I would just like to say that I don’t consider the existence of any number of 
other MP3 players in Debian to be a good reason to prohibit the introduction 
of another one.  I am not yet a Debian Developer, but if I were I would 
sponsor your package.

Soren

On Wednesday, December 21, 2022 6:22:07 AM MST Thomas Dettbarn wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I would like to point out that there is still a BADASS-LOOKING package
> "d11amp"
> waiting to be sponsored.
> 
> 
> 
> 
> * Package name : d11amp
> Version : 0.59-1
> Upstream contact : Thomas Dettbarn 
> * URL : https://www.dettus.net/d11amp/
> * License : BSD-2-Clause
> * Vcs : https://github.com/dettus/d11amp/
> Section : sound
> 
> The source builds the following binary packages:
> 
> d11amp - Simple MP3 player
> 
> To access further information about this package, please visit the
> following URL:
> 
> https://mentors.debian.net/package/d11amp/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
> dget -x
> https://mentors.debian.net/debian/pool/main/d/d11amp/d11amp_0.59-1.dsc
> 
> Changes for the initial release:
> 
> d11amp (0.59-1) unstable; urgency=low


-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1024980: Related to Debian changes to use trust-dns 0.21

[Reinhard Tartler]

On 12/11/22 4:43 PM, Duncan Findlay wrote:

I tried reproducing this issue with several modified versions of
aardvark-dns to see if I could narrow down the cause.

I could not reproduce this with upstream source at head, nor with
upstream source at v1.0.3.


Thanks for your test report. I'm currently updating trust-dns to version 0.22,
and am hopeful that this will resolve the issue.

In fact, trust-dns in version 0.21 had to disable quite some features that
I didn't think would impact how aardvark-dns was using it. Maybe I was wrong,
in which case the upgrade would help.

-rt

Bug#1026837: debuild: fatal error at line 359

[Erik de Castro Lopo]

Package: devscripts
Version: 2.22.2
Severity: normal

Dear Maintainer,

Trying to build a package in s 32 bit chroot on an x86_64 system.

The command is
```
debuild -us -uc -rfakeroot -j4 --lintian-opts -iI --color always
```
and the error is:
```
debuild: fatal error at line 359:
internal error: dpkg opts list missing proper header
```

Line 359 is:
```
if (shift @othervars ne ">>> $dpkg_opts_var BEGIN <<<") {
```


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

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

Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_AU.UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.12
ii  fakeroot  1.30.1-1
ii  file  1:5.41-4
ii  gnupg 2.2.40-1
ii  gpgv  2.2.40-1
ii  libc6 2.36-6
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005004-3
ii  libwww-perl   6.67-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-6
ii  python3   3.10.6-3
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-3

Versions of packages devscripts recommends:
ii  apt 2.5.4
ii  curl7.86.0-2
ii  dctrl-tools 2.24-3
ii  debian-keyring  2022.11.30
ii  dput1.1.3
ii  equivs  2.3.1
ii  libdistro-info-perl 1.2
ii  libdpkg-perl1.21.12
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.26-2
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-2
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.17-1
ii  licensecheck3.3.0-1
ii  lintian 2.115.3
ii  man-db  2.11.1-1
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.5.0
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.26-2
ii  python3-requests2.28.1+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  5.10-1
ii  unzip   6.0-27
ii  wget1.21.3-1+b1
ii  xz-utils5.4.0-0.1

Versions of packages devscripts suggests:
pn  adequate 
pn  at   
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20220412cvs-1
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.11.3
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  elpa-devscripts  
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-3
pn  libdbd-pg-perl   
pn  libfile-desktopentry-perl
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
pn  libyaml-syck-perl
pn  mmdebstrap   
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:9.1p1-1
pn  piuparts 
pn  postgresql-client
pn  pristine-lfs 
pn  quilt
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information

Bug#1026836: RFS: runit-services/0.5.2 -- UNIX init scheme with service supervision (services)

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Dear mentors,

I am looking for a sponsor for my package "runit-services":

 * Package name : runit-services
   Version  : 0.5.2
   Upstream contact : [fill in name and email of upstream]
 * URL  : [fill in URL of upstream's web site]
 * License  : BSD-3-Clause, CC0-1.0
 * Vcs  : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services
   Section  : admin

The source builds the following binary packages:

  runit-services - UNIX init scheme with service supervision (services)

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

  https://mentors.debian.net/package/runit-services/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.2.dsc

Git repo:

  https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next

Changes since the last upload:

 runit-services (0.5.2) experimental; urgency=medium
 .
   * Improve purge documentation (Closes: #1024962)
   * Fix wrong boot order for sysv dbus-services (Closes: #1024969)
   * Automate d/copyright update for runscripts:
 - add a simple copyright header to each runfile
 - add d/copyright.in
 - add a script that automatically update d/copyright
   based on copyright.in and runscripts headers
   * update copyright and copyright.in
   * d/prerm: fix wrong path for meta files
   * All runscripts cleanup:
 - do not set -e, relevant commands are tested
 - do not use redundant 'sv check' for checking service
   dependencies, 'sv start' is enough

Regards,
-- 
  Lorenzo Puliti

Bug#1026835: ITP: deprecation -- Library to handle automated depreciations

[Josenilson Ferreira da Silva]

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

* Package name: deprecation
  Version : 2.1.0
  Upstream Author : Brian Curtin 
* URL : https://github.com/briancurtin/deprecation
* License : MIT/Expat
  Programming Lang: Python
  Description : Library to handle automated depreciations
 
 deprecation is a dependency for deprecation-alias.
 And the deprecation-alias is a required dependency for the
 Whey package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021204

Bug#1026696: golang-github-prometheus-client-model: FTBFS: make: *** [debian/rules:6: binary] Error 25

[Daniel Swarbrick]

Hi,

On 22.12.22 00:41, Shengjing Zhu wrote:

Hi,

The workaroud could be like this:
https://salsa.debian.org/go-team/packages/notary/-/commit/b0a072faa72857f7523c8245ecaa8814d5a60051


Fixing the build failure in golang-github-prometheus-client-model is a 
simple matter of including golang-google-protobuf-dev in the build-deps.


However, as the resulting metrics.pb.go now has a different type for the 
timestamp fields, and downstream packages that use this will likely need 
patching.


I already had to patch golang-github-prometheus-common[1] and 
golang-github-prometheus-client-golang[2] for similar issues not long 
ago. With those patches in place, and the new metrics.pb.go, those 
packages FTBFS. Dropping those patches fixes the build, but 
prometheus-common then panics with a Go reflect error in one of the tests.


So I'm not really sure of the best course of action at the moment.

[1]: 
https://salsa.debian.org/go-team/packages/golang-github-prometheus-common/-/blob/debian/sid/debian/patches/01-support-outdated-protobuf-build-deps.patch
[2]: 
https://salsa.debian.org/go-team/packages/golang-github-prometheus-client-golang/-/blob/debian/sid/debian/patches/02-support-outdated-protobuf-build-deps.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026503: libembperl-perl: FTBFS: Expected 6 more error(s) in logfile, tagging 1026503

[Axel Beckert]

Hi,

gregor herrmann wrote:
> > > Bug #1026503 [src:libembperl-perl] ibembperl-perl: FTBFS: Expected 6 more 
> > > error(s) in logfile
> 
> (Thanks for fixing this copypaste mistake!)

You're welcome.

>From the build log:
> #8 plainblock.htm...  ok
> #15 error.htm...  
> 
> Expected 6 more error(s) in logfile
> 
> Input:  test/html/error.htm
> Output: test/tmp/out.htm
> Log:test/tmp/test.log
> Testparameter:
>   version = 2
>   condition = $] >= 5.01
>   cgi = 0
>   repeat = 3
>   errors = 6
> 
>  ERRORS detected! NOT all tests have been passed successfully
> 
> cat: test/tmp/httpd.pid: No such file or directory

Just a short note: That last line is a red herring. It's just a follow
up error when the test suite tries to run the already no more running
httpd:

test.pl:system "kill `cat $tmppath/httpd.pid`  2> /dev/null" if ($EPHTTPD 
ne '' && !$opt_nokill) ;

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#973875: Closing the bug

[Anton Gladky]

As far as I understand the issue, it is already
resolved in the current versions of the package.

Thus, I am closing it.

Please feel free to reopen, if you think the issue is still here.

Thanks

Anton

Bug#1026666: Please make liblog4j2-java depend on junit5

[tony mancill]

On Tue, Dec 20, 2022 at 11:45:54PM +0100, Pierre Gruet wrote:
> Control: retitle -1 Please make liblog4j2-java depend on junit5
> 
> Hello,
> 
> In version 2.19.0-1 of liblog4j2-java, the file
>   
> /usr/share/maven-repo/org/apache/logging/log4j/log4j/debian/log4j-debian.pom
> declares the junit-bom artifact as a dependency. It is shipped in junit5.
> 
> If this dependency is not added, reverse dependencies of liglog4j2-java fail
> to build (see logs above) as the junit-bom artifact is not found.

Hi Pierre,

I'm wondering if it wouldn't better to remove junit-bom from log4j pom.
I don't believe we actually need junit5 at runtime for log4j2, so
packages depending on liblog4j2-java should not have to install junit5.

Any concerns with taking that approach and addressing the bug by
adjusting the pom shipped with liblog4j2-java?

Thanks,
tony


signature.asc
Description: PGP signature

Bug#1026834: linux-image-5.10.0-20-amd64: no audio with device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 11)

[sapcie]

Package: linux-image-5.10.0-20-amd64
Version: latest
Severity: normal

Dear Maintainer,

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

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

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


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

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

Versions of packages linux-image-5.10.0-20-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-20-amd64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-20-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.06-3~deb11u5

-- INFO --

I've removed the 5.10.0-20-amd64 kernel. With 5.10.0-19-amd64 I've no problem
with audio ...

Bug#1026833: git-annex: git-annex-addurl(1): Documentation and behaviour of --file= differ

[Axel Beckert]

Package: git-annex
Version: 10.20221003-3
Severity: minor
Tags: upstream

Hi,

Because youtube-dl can't cope with some sites, I downloaded a file with
yt-dlp manually and wanted to add it with "git annex addurl" later.

The man page says:

  --file=name

Use with a filename that does not yet exist to add a new file
with the specified name and the content downloaded from the url.

If the file already exists, addurl will record that it can be
downloaded from the specified url(s).

So I tried the following:

  $ yt-dlp -o existing_file.mp4 
https://some.videosite.example.com/existing_file.mp4
  $ git annex addurl --raw --relaxed --file=existing_file.mp4 
https://some.videosite.example.com/existing_file.mp4

But the latter failed as follows:

  addurl https://some.videosite.example.com/existing_file.mp4
existing_file.mp4 already exists; not overwriting
  failed
  addurl: 1 failed

But that's not what is expected to happen according to the man page.

What actually did help was running the following command inbetween the
two commands above:

  $ git annex add existing_file.mp4

But that's not (exactly) what the man page says. So I see two ways to
fix this issue:

  1. Update the man page to state that "already exists" actually means
"already exists in the index or repository".

  2. Update the behaviour of "git annex addurl --file=" to also accept
 existing, but not yet added files and add them in the same run,
 too.

(This is probably an upstream issue, tagging as such.)

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages git-annex depends on:
ii  curl7.86.0-2
ii  git 1:2.39.0-1
ii  libc6   2.36-6
ii  libffi8 3.4.4-1
ii  libgmp102:6.2.1+dfsg1-1.1
ii  libmagic1   1:5.41-4
ii  libsqlite3-03.40.0-2
ii  libyaml-0-2 0.2.5-1
ii  netbase 6.4
ii  openssh-client  1:9.1p1-1
ii  rsync   3.2.7-1
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages git-annex recommends:
ii  aria2  1.36.0-1
ii  bind9-host 1:9.18.8-1
ii  git-remote-gcrypt  1.5-1
ii  gnupg  2.2.40-1
ii  lsof   4.95.0-1
ii  nocache1.1-1+b1

Versions of packages git-annex suggests:
ii  adb 1:29.0.6-21
ii  bup 0.32-3+b1
ii  libnss-mdns 0.15.1-3
ii  magic-wormhole  0.12.0-1
pn  tahoe-lafs  
ii  tor 0.4.7.12-1
ii  uftp4.10.2-1.1+b2
ii  xdot1.2-3
ii  yt-dlp  2022.11.11-1

-- no debconf information

Bug#1022573: transition: procps

[Craig Small]

On Thu, 22 Dec 2022 at 07:46, Paul Gevers  wrote:

> An actual upload. If the maintainer isn't doing it, I think an NMU is
> appropriate if you're sure of the fix.
>
Ah, I thought you were the igt maintainer :)

I'll have a go recreating it and uploading it tonight. I'm pretty confident
about the patches but don't use the package myself.

 - Craig

Bug#1026832: wiki.debian.org: BridgeNetworkConnections wrong usage of bridge_hw parameter?

[Steffen Dettmer]

Package: wiki.debian.org
Severity: minor

Dear Maintainer,

I visited https://wiki.debian.org/BridgeNetworkConnections and read an
example:

   pre-up iwconfig wlan0 essid $YOUR_ESSID
   bridge_hw $MAC_ADDRESS_OF_YOUR_WIRELESS_CARD

but this does not work (for me on 1 host tested only).
After spending quite some time on troubleshooting I think it should be

   pre-up iwconfig wlan0 essid $YOUR_ESSID
   bridge_hw $DEVICE_NAME_OF_YOUR_WIRELESS_CARD

or better simply:

   pre-up iwconfig wlan0 essid $YOUR_ESSID
   hwaddress $MAC_ADDRESS_OF_YOUR_WIRELESS_CARD

(bridge_hw seems to expect an interface name). Unfortunately I did not
find the right man page or definition to be sure (man interfaces does
not meantion any of bridge_hw or hwaddress). It's Debian 11.

As I now spent too much time on that (assuming a problem with DHCP
server) I would like to help others by reporting this in the hope
some expert could take a look.

Best regards,
Steffen

Bug#1026617: libjt400-java: FTBFS: [javac] /<>/java8/com/ibm/as400/data/RecordFormatDocument.java:149: error: reference to Record is ambiguous

[tony mancill]

On Wed, Dec 21, 2022 at 12:07:24PM +0100, Hans Joachim Desserud wrote:
> tags 1026617 patch
> thanks
> 
> > [javac]   both class com.ibm.as400.access.Record in
> > com.ibm.as400.access and class java.lang.Record in java.lang match
> > [javac]
> > /<>/java8/com/ibm/as400/data/RecordFormatDocument.java:1375:
> > error: reference to Record is ambiguous
> 
> Looks like the ambiguity stems from the new Record class introduced in new
> JDKS which hit when rebuilt with JDK 17. See the attached patch which adds
> an explicit import to the "local" Record class, which has been the one
> imported up until now.
> 
> With this patch in place, the package builds successfully again on Debian
> Sid.

Thank you for the patch!  Applied and uploaded.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1026718: lazpaint: FTBFS: /usr/bin/ld.bfd: cannot find -lpangocairo-1.0: No such file or directory

[Juliette DAMON-ELSASS]

Relevant part is:
> (9015) Linking /<>/lazpaint/release/bin/lazpaint
> /usr/bin/ld.bfd: cannot find -lgdk-x11-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lgtk-x11-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lX11: No such file or directory
> /usr/bin/ld.bfd: cannot find -lgdk_pixbuf-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lgobject-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lglib-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lgthread-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lgmodule-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lpango-1.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lcairo: No such file or directory
> /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lpangocairo-1.0: No such file or directory
> /<>/lazpaint/lazpaint.lpr(229,1) Error: (9013) Error while 
> linking

It does not find the libraries. Is there a change of availability of those?

Bug#1022573: transition: procps

[Paul Gevers]

Hi,

On 21-12-2022 21:42, Craig Small wrote:
Is there something else you need? This one was one of the easier ones to 
fix.


An actual upload. If the maintainer isn't doing it, I think an NMU is 
appropriate if you're sure of the fix.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022573: transition: procps

[Craig Small]

On Thu, 22 Dec 2022 at 05:54, Paul Gevers  wrote:

> The issue is that src:intel-gpu-tools is a key packages but currently
> unfixed. Having procps migrate to testing now would cause it to be
> instantaneously RC buggy, but because it is key, we can't simply remove
> it from bookworm. Can you help fix this package in unstable?
>
I'm surprised there is an issue:
 * There has been a patch for it for a while now
 * Upstream have the patch and I believe is either in or still being
discussed
 * I've personally built igt Debian packages with that patch

Is there something else you need? This one was one of the easier ones to
fix.

 - Craig

Bug#1026831: systemd: CVE-2022-4415: systemd-coredump not respecting fs.suid_dumpable kernel setting

[Salvatore Bonaccorso]

Source: systemd
Version: 252.3-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 247.3-7+deb11u1
Control: found -1 247.3-7

Hi,

The following vulnerability was published for systemd.

CVE-2022-4415[0]:
| systemd-coredump not respecting fs.suid_dumpable kernel setting

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-4415
https://www.cve.org/CVERecord?id=CVE-2022-4415
[1] https://www.openwall.com/lists/oss-security/2022/12/21/3
[2] 
https://github.com/systemd/systemd-stable/commit/bb47600aeb38c68c857fbf0ee5f66c3144dd81ce

Regards,
Salvatore

Bug#1019937: NMU: elfutils: Missing licenses in d/copyright

[Sergio Durigan Junior]

On Wednesday, December 21 2022, Bastian Germann wrote:

> I am uploading a NMU to DELAYED/10 to fix this. debdiff is attached.

Hi Bastian,

Thanks for the heads up, and sorry for the delay.  I applied your
changes, made a few cosmetic adjustments and uploaded a new version to
unstable.  Could you cancel your NMU upload, please?

Thanks a lot,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Paul Gevers]

Control: tags -1 confirmed

Dear Ondřej,

On 15-12-2022 20:15, Ondřej Surý wrote:

I think everything is mostly ready in experimental. I'll try to sort out
the rest of the missing extensions over the weekend (imagick, memcached,
redis and maybe few others).


Assuming this happened (more or less).


The bump from 8.x to 8.2 is relatively painless, so can we schedule the
transition in few days/weeks?


Please go ahead.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026830: curl: CVE-2022-43552: HTTP Proxy deny use-after-free

[Salvatore Bonaccorso]

Source: curl
Version: 7.86.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 7.74.0-1.3

Hi,

The following vulnerability was published for curl.

CVE-2022-43552[0]:
| HTTP Proxy deny use-after-free

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-43552
https://www.cve.org/CVERecord?id=CVE-2022-43552
[1] https://curl.se/docs/CVE-2022-43552.html

Regards,
Salvatore

Bug#1026829: curl: CVE-2022-43551: Another HSTS bypass via IDN

[Salvatore Bonaccorso]

Source: curl
Version: 7.86.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 7.74.0-1.3

Hi,

The following vulnerability was published for curl.

CVE-2022-43551[0]:
| Another HSTS bypass via IDN

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-43551
https://www.cve.org/CVERecord?id=CVE-2022-43551
[1] https://curl.se/docs/CVE-2022-43551.html

Regards,
Salvatore

Bug#916475: ghdl: various suggestions to simplify the packaging

[Nicolas Boulenguez]

Source: ghdl
Followup-For: Bug #916475

Hello.

I see that you have committed most suggestions in this bug report.
Great!

Four were ignored, probably because you are busy with the build
failures.

Just in case, a rebased version is attached.

I have not tried a full rebuild, because it is also possible that you
prefer the existing code.
>From 9b98af64ac20f6e58674034bf07d8b6a589a3c33 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Wed, 14 Dec 2022 13:48:00 +0100
Subject: [PATCH 1/4] Simplify installation of the ghdl wrapper

---
 debian/ghdl-common.install| 7 ++-
 debian/installed-names/README | 2 ++
 debian/{ghdl.wrapper => installed-names/ghdl} | 0
 debian/rules  | 1 -
 4 files changed, 8 insertions(+), 2 deletions(-)
 create mode 100644 debian/installed-names/README
 rename debian/{ghdl.wrapper => installed-names/ghdl} (100%)
 mode change 100644 => 100755

diff --git a/debian/ghdl-common.install b/debian/ghdl-common.install
index d76d810e..7ac15337 100644
--- a/debian/ghdl-common.install
+++ b/debian/ghdl-common.install
@@ -1,3 +1,8 @@
-usr/bin/ghdl
+# This Debian-specific script lives under debian/, but cannot be named
+# debian/ghdl because this path is used by dh_install tools.
+# dh_install cannot rename it during the installation phase, so it
+# lives in debian/installed-names.
+debian/installed-names/ghdl usr/bin
+
 usr/lib/ghdl/src
 usr/lib/ghdl/include
diff --git a/debian/installed-names/README b/debian/installed-names/README
new file mode 100644
index ..2b391142
--- /dev/null
+++ b/debian/installed-names/README
@@ -0,0 +1,2 @@
+A comment in debian/ghdl-common.install explains why this directory
+exists.
diff --git a/debian/ghdl.wrapper b/debian/installed-names/ghdl
old mode 100644
new mode 100755
similarity index 100%
rename from debian/ghdl.wrapper
rename to debian/installed-names/ghdl
diff --git a/debian/rules b/debian/rules
index 9644cf9a..b1c90406 100755
--- a/debian/rules
+++ b/debian/rules
@@ -159,7 +159,6 @@ override_dh_auto_build:
 	fi
 
 override_dh_auto_install:
-	install -pD debian/ghdl.wrapper $(CURDIR)/debian/tmp/usr/bin/ghdl
 	@echo
 	@echo 
 	@echo Installing with mcode backend
-- 
2.30.2

>From 246eb3cb650ba8de44d05d6483356e960c3ae674 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Wed, 14 Dec 2022 14:02:42 +0100
Subject: [PATCH 2/4] Replace some hand-written commands with dh_install or
 link debhelper files

This should be a no-op, but reduce the overall complexity.

Shell/Make tests are replaced with package names in the debhelper
configuration file name.

Symbolic links are explicitly marked as such instead of created in the
already complex debian/rules, then installed as normal files by
debian/*.install.
---
 debian/ghdl-common.install |  6 +-
 debian/ghdl-gcc.install|  1 -
 debian/ghdl-gcc.links  |  3 +++
 debian/ghdl-llvm.install   |  1 -
 debian/ghdl-llvm.links |  3 +++
 debian/ghdl-mcode.install  |  1 -
 debian/ghdl-mcode.links|  3 +++
 debian/rules   | 19 ++-
 8 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/debian/ghdl-common.install b/debian/ghdl-common.install
index 7ac15337..5b739b1b 100644
--- a/debian/ghdl-common.install
+++ b/debian/ghdl-common.install
@@ -4,5 +4,9 @@
 # lives in debian/installed-names.
 debian/installed-names/ghdl usr/bin
 
-usr/lib/ghdl/src
+# Depending on DEB_BUILD_PROFILES, between one and three copies are
+# installed under debian/tmp. A redundant shell wildcard should be
+# sufficient as long as the contents match.
+usr/lib/ghdl/*/vhdl/src/usr/lib/ghdl
+
 usr/lib/ghdl/include
diff --git a/debian/ghdl-gcc.install b/debian/ghdl-gcc.install
index b721e0cd..a7c5c6f0 100644
--- a/debian/ghdl-gcc.install
+++ b/debian/ghdl-gcc.install
@@ -7,6 +7,5 @@ usr/lib/ghdl/gcc/vhdl/*.a
 usr/lib/ghdl/gcc/vhdl/grt.*
 usr/lib/ghdl/gcc/vhdl/grt-*.*
 
-usr/lib/ghdl/gcc/vhdl/src
 usr/lib/ghdl/gcc/vhdl/std
 usr/lib/ghdl/gcc/vhdl/ieee
diff --git a/debian/ghdl-gcc.links b/debian/ghdl-gcc.links
index 6ba63a7b..70f476c2 100644
--- a/debian/ghdl-gcc.links
+++ b/debian/ghdl-gcc.links
@@ -1 +1,4 @@
+# The actual files are provided by the ghdl-common package.
+usr/lib/ghdl/srcusr/lib/ghdl/gcc/vhdl/src
+
 usr/share/man/man1/ghdl.1.gz usr/share/man/man1/ghdl-gcc.1.gz
diff --git a/debian/ghdl-llvm.install b/debian/ghdl-llvm.install
index b9abd68e..d2236f97 100644
--- a/debian/ghdl-llvm.install
+++ b/debian/ghdl-llvm.install
@@ -6,6 +6,5 @@ usr/lib/ghdl/llvm/vhdl/*.a
 usr/lib/ghdl/llvm/vhdl/grt.*
 usr/lib/ghdl/llvm/vhdl/grt-*.*
 
-usr/lib/ghdl/llvm/vhdl/src
 usr/lib/ghdl/llvm/vhdl/std
 usr/lib/ghdl/llvm/vhdl/ieee
diff --git a/debian/ghdl-llvm.links b/debian/ghdl-llvm.links
index 52b5924a..e4471ded 100644
--- a/debian/ghdl-llvm.links
+++ b/debian/ghdl-llvm.links
@@ -1 +1,4 @@
+# The actual files 

Bug#1026828: libgmpada: FTBFS on i386: raised ADA.ASSERTIONS.ASSERTION_ERROR : demo.adb:119

[Nicolas Boulenguez]

Source: libgmpada
Version: 1.5-1
Severity: serious
Tags: ftbfs
Justification: fails to build on a supported architecture

A post-build test fails on i386 buildds:
https://buildd.debian.org/status/fetch.php?pkg=libgmpada=i386=1.5-1=1671621582=0
https://buildd.debian.org/status/fetch.php?pkg=libgmpada=i386=1.5-1=1661971646=0
but succeeds on an i386 porterbox.

Bug#1023712: why3 breaks frama-c (autopkgtest): missing versioned Breaks?

[Paul Gevers]

Control: reassign -1 frama-c

Dear maintainers,

On Tue, 8 Nov 2022 21:53:18 +0100 Paul Gevers  wrote:

[kernel] User Error: cannot load plug-in 'frama-c-wp': cannot load module
   Details: implementation mismatch on Why3
[kernel] User Error: Deferred error message was emitted during 
execution. See above messages for more information.

[kernel] Frama-C aborted: invalid user input.
autopkgtest [20:18:19]: test eva


I'm now seeing the above error message in the frama-c test in testing, 
so it seems that the issue is rather that the autopkgtest of frama-c 
doesn't properly declare it's *versioned* test dependency on why3? 
Should the Recommends be versioned? (Not sure if that actually works as 
intended, but apparently the tested plug-in only works correctly with 
the right version of why3).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#885433: Forbidden access to wiki.debian.org

[Adam Krajkowski]

Dear Maintainer

my IP is forbidden when trying to reach wiki.debian.org.


Please, can you unblock 176.221.120.161 ?

Bug#1004932: lifelines: diff for NMU version 3.0.61-3

[Boyuan Yang]

Control: tags 1004932 + patch
Control: tags 1004932 + pending

Dear maintainer,

I've prepared an NMU for lifelines (versioned as 3.0.61-3) and
uploaded it to DELAYED/6. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru lifelines-3.0.61/debian/changelog lifelines-
3.0.61/debian/changelog
--- lifelines-3.0.61/debian/changelog   2022-12-20 16:46:33.0 -0500
+++ lifelines-3.0.61/debian/changelog   2022-12-21 15:01:58.0 -0500
@@ -1,3 +1,11 @@
+lifelines (3.0.61-3) unstable; urgency=medium
+
+  * QA upload.
+  * Orphan the package. (Closes: #1004932)
+  * debian/control: Add Vcs-* packaging fields on Debian Salsa.
+
+ -- Boyuan Yang   Wed, 21 Dec 2022 15:01:58 -0500
+
 lifelines (3.0.61-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
@@ -101,7 +109,7 @@
 
 lifelines (3.0.50-1) unstable; urgency=low
 
-  * New upstream. (Closes: #345138) 
+  * New upstream. (Closes: #345138)
 - #345138 (lifelines-3.0.50) and #335437 (lifelines-3.0.49) were
merged.
   * Change Build-Depends to use libncursesw5-dev instead of libncurses5-
dev.
 - UTF-8 support since lifelines-3.0.49
@@ -116,7 +124,7 @@
 
 lifelines (3.0.46.1-1) unstable; urgency=low
 
-  * New upstream. 
+  * New upstream.
 
  -- Felipe Augusto van de Wiel (faw)   Sun, 26
Jun 2005 05:55:02 -0300
 
@@ -209,7 +217,7 @@
 config.guess (20040813 to 20041112)
 
  -- Christian Perrier   Fri, 26 Nov 2004 18:06:37 +0100
- 
+
 lifelines (3.0.37.2-2) unstable; urgency=low
 
   * Prospectively added dh_buildinfo to debian/rules. New Build-Depends on
@@ -376,7 +384,7 @@
   * Modified debian/rules for using config.{guess,sub} from autotools-dev
 if they're more recent than upstream ones. Added an autotools
 target for this. Build dependency on autotools-dev and devscripts
-  * As a consequence of the above, build dependency on automake has been 
+  * As a consequence of the above, build dependency on automake has been
 removed
   * Hope I understood all the above stuff properly..:-)
 
@@ -384,7 +392,7 @@
 
 lifelines (3.0.16-1) unstable; urgency=low
 
-  * Updated config.guess and config.sub with files coming from 
+  * Updated config.guess and config.sub with files coming from
 the autotools-dev package (Closes: 14). I'll reopen
 the bug if I'm wrong..:-). Next lifelines upstream release
 will have updated files according to LL mailing list
diff -Nru lifelines-3.0.61/debian/control lifelines-3.0.61/debian/control
--- lifelines-3.0.61/debian/control 2022-12-20 16:46:33.0 -0500
+++ lifelines-3.0.61/debian/control 2022-12-21 15:01:23.0 -0500
@@ -1,10 +1,12 @@
 Source: lifelines
 Section: misc
 Priority: optional
-Maintainer: Felipe Augusto van de Wiel (faw) 
+Maintainer: Debian QA Group 
 Build-Depends: libncurses-dev, bison, debhelper (>= 9), docbook-utils,
ghostscript, autoconf (>= 2.5), autotools-dev, devscripts, dh-buildinfo,
lynx
 Standards-Version: 3.9.3
 Homepage: http://lifelines.github.io/lifelines/
+Vcs-Git: https://salsa.debian.org/debian/lifelines.git
+Vcs-Browser: https://salsa.debian.org/debian/lifelines
 
 Package: lifelines
 Architecture: any


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

Bug#1026827: xrdp: initially xrdp worked ok, but later it broke, and the problem was /etc/xrdp/startwm.sh that changed

[Dominik George]

Control: tags -1 + moreinfo
Control: severity -1 normal

Hi,

> Severity: critical
> Justification: breaks the whole system

I doubt that very much. Are you sure that the whole system stopped
working because you could not start a session in xrdp? As in, no login
on the tty possible, the kernel crashing, boot failed, or the like?

>* What led up to the situation?

What did yo udo *before* the file was renamed?

I am pretty certain that this is not something the package did.

How is the syste mmanaged?

Did the change happen in correlation with a package update?

-nik


signature.asc
Description: PGP signature

Bug#1026790: snmptrapd options in systemd service

[Paul Szabo]

Sorry to be so contrary... but the current version does not seem to be
like that. The man page says:

...
-L[efos]
Specify where logging output should be directed (standard error
or output, to a file or via syslog).  See  LOGGING  OPTIONS  in
snmpcmd(1) for details.
...
-O [abeEfnqQsStTuUvxX]
Specifies how MIB objects and other output should be displayed.
See  the  section  OUTPUT OPTIONS in the snmpcmd(1) manual page
for details.
...

I believe that -Lsd means (L) log to (s) syslog with (d) LOG_DAEMON
facility. Seems that -L cannot be used on its own; and I do not see any
meaning for neither -Ow nor for -w.

As proof of pudding... it did not work for me with -LOw, nothing went
into syslog; things are working well with -Lsd.

Cheers, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia

Join our enterprise bargaining campaign for a better University.
I support the NTEU claims!Join the NTEU:   www.nteu.au/join

Bug#986458: python-pangolearn_2022-02-02+dfsg-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Wed, Dec 21, 2022 at 07:00:10PM + schrieb Thorsten Alteholz:
> shouldn't be that license better GPL-3.0 only?

I admit I have no idea what in

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

makes you believe that this should be better GPL-3.0 but since we really
need this package for Covid-19 and I do not want to risk another reject
delaying any things even longer I simply follow your advise.

Kind regards and thanks for spending your pre-Christmas days on
ftpmaster tasks
Andreas.

-- 
http://fam-tille.de

Bug#1022404: raqm: diff for NMU version 0.7.0-4.1

[Nilesh Patra]

On Sat, 19 Nov 2022 21:19:24 +0200 Adrian Bunk  wrote:
> Control: tags 1022404 + patch
> Control: tags 1022404 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for raqm (versioned as 0.7.0-4.1) and uploaded
> it to DELAYED/15. Please feel free to tell me if I should cancel it.

It has been 15 days past your upload but it has not reflected yet in
the archive. Did you happen to cancel your NMU?

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#958853: Fix

[Julian Gilbey]

On Wed, Dec 21, 2022 at 07:24:38PM +0100, Dan O'Huiginn wrote:
> Upstream has now moved away from Bazel: 
> https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4b202c08bd740c7bb37763
> 
> The new build system uses cargo and ninja. It'll still be a substantial job 
> to package this for Debian, but hopefully more feasible than before.

Oh wow, that's good news, thanks!  I don't know whether I'll have time
to do it before the freeze, though - I am very overloaded at the
moment, unfortunately.  (And unless something's changed, upstream were
using some locally modified Rust crates, which just added to the
pain.)

Best wishes,

   Julian

Bug#1022573: transition: procps

[Paul Gevers]

Dear Craig, ChangZhuo,

This is a heads up that I just added a block against procps to prevent 
the package in unstable from migrating to testing too soon.


The issue is that src:intel-gpu-tools is a key packages but currently 
unfixed. Having procps migrate to testing now would cause it to be 
instantaneously RC buggy, but because it is key, we can't simply remove 
it from bookworm. Can you help fix this package in unstable?


ChangZhuo, src:lxqt-session is in the same boat, but already changed 
it's Build-Dependency in experimental. An upload to unstable would be 
appreciated.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026812: urgency

[Fabian Grünbichler]

I am not sure how fast this upgrade makes sense - there is barely
anything depending on 0.20 since it's been out less than two weeks,
including sccache, which only has the dependency bumped in git[0].

if sccache releases before base64 is upgraded in Debian, the change looks
fairly mechanical and should thus be easy to temporarily revert.

AFAICT:
librust-alacritty-terminal-dev   0.17.0-1
librust-cookie-dev   0.16.0-1base64 0.20 upstream release exists
librust-fernet-dev   0.1.4-1+b1  
librust-grep-printer-dev 0.1.6-1 (optional)
librust-pem-dev  1.0.2-1 
librust-plist-dev1.3.1-1 (no upstream release for a year)
librust-postgres-protocol-dev0.6.4-1+b1  
librust-reqwest-dev  0.11.11-3   
librust-ron-dev  0.7.1-1 (one major release behind)
librust-rustls-pemfile-dev   1.0.0-1+b1  
librust-sequoia-autocrypt-dev0.24.0-1(no upstream release for a year)
librust-sequoia-net-dev  0.25.0-2
librust-sequoia-openpgp-dev  1.10.0-4(explicitly bumped to < 0.20!)
librust-sniffglue-dev0.15.0-3(no upstream release for 10 months)
librust-totp-rs-dev  3.0.1-2 (optional)
librust-ureq-dev 2.5.0-4 

except for cookie, which had a release seemingly just for updating base64,
these are *all* still on 0.13 upstream. I'd rather not have to patch all
of them to be compatible with the new interface, including checking for
subtle bugs, when the single thing using it so far (in an unreleased
version!) can be trivially made comaptible with the old, currently
packaged version. once we reach some critical mass w.r.t. rdeps wanting
0.20, or if someone else steps up that wants to do that work, this
obviously changes..

hope that's okay for the time being :) feel free to ping the bug if you
have the feeling that the situation has changed!

0: 
https://github.com/mozilla/sccache/commit/9bf4e41e4c1d27b84c9790d68f4dab0eb7272a07

Bug#1026827: xrdp: initially xrdp worked ok, but later it broke, and the problem was /etc/xrdp/startwm.sh that changed

[alex]

Package: xrdp
Version: 0.9.12-1.1
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: alexb...@gmail.com

Dear Maintainer,

   * What led up to the situation?
the remmina-rdp and android ms-rdesktop initially worked ok, 
but after this change began to show a black screen and close it.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
upstream discussion led me to check /etc/xrdp/startwm.sh that not only seemed 
broken, 
but the version that seemed ok (and later worked indeed) was renamed to 
/etc/xrdp/startwm.sh0.
the broken version was also in a file /etc/xrdp/startwm.sh1.
   * What was the outcome of this action?
xrdp was initially working until the day before, when it showed a black window 
and disconnected.
   * What outcome did you expect instead?
after i suspected this file was broken, and replaced it with 
/etc/xrdp/startwm.sh0 that was by it's side.


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

Kernel: Linux 5.10.0-20-cloud-amd64 (SMP w/6 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 xrdp depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u5
ii  libfuse2 2.9.9-5
ii  libjpeg62-turbo  1:2.0.6-4
ii  libopus0 1.3.1-0.1
ii  libpam0g 1.4.0-9+deb11u1
ii  libssl1.11.1.1n-0+deb11u3
ii  libx11-6 2:1.7.2-1
ii  libxfixes3   1:5.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  lsb-base 11.1.0
ii  ssl-cert 1.1.0+nmu1

Versions of packages xrdp recommends:
ii  fuse3 [fuse]  3.10.3-2
ii  xorgxrdp  1:0.2.12-1

Versions of packages xrdp suggests:
pn  guacamole  
pn  xrdp-pulseaudio-installer  

Versions of packages xorgxrdp depends on:
ii  libc6  2.31-13+deb11u5
ii  libepoxy0  1.5.5-1
pn  xorg-input-abi-24  
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.11-1+deb11u4

Versions of packages xorgxrdp recommends:
ii  xorg  1:7.7+22

Versions of packages xrdp is related to:
pn  vnc-server   
ii  xserver-xorg-legacy  2:1.20.11-1+deb11u4

-- Configuration Files:
/etc/xrdp/startwm.sh changed:
if [ -r /etc/default/locale ]; then
. /etc/default/locale
export LANG LANGUAGE
fi
startxfce4

/etc/xrdp/xrdp.ini changed:
[Globals]
; xrdp.ini file version number
ini_version=1
; fork a new process for each incoming connection
fork=true
; ports to listen on, number alone means listen on all interfaces
; 0.0.0.0 or :: if ipv6 is configured
; space between multiple occurrences
;
; Examples:
;   port=3389
;   port=unix://./tmp/xrdp.socket
;   port=tcp://.:3389   127.0.0.1:3389
;   port=tcp://:3389*:3389
;   port=tcp://:3389  192.168.1.1:3389
;   port=tcp6://.:3389  ::1:3389
;   port=tcp6://:3389   *:3389
;   port=tcp6://{}:3389   {FC00:0:0:0:0:0:0:1}:3389
;   port=vsock://:
port=3389
;port=tcp://.:3389
; 'port' above should be connected to with vsock instead of tcp
; use this only with number alone in port above
; prefer use vsock://: above
use_vsock=false
; regulate if the listening socket use socket option tcp_nodelay
; no buffering will be performed in the TCP stack
tcp_nodelay=true
; regulate if the listening socket use socket option keepalive
; if the network connection disappear without close messages the connection 
will be closed
tcp_keepalive=true
; set tcp send/recv buffer (for experts)
; security layer can be 'tls', 'rdp' or 'negotiate'
; for client compatible layer
security_layer=negotiate
; minimum security level allowed for client for classic RDP encryption
; use tls_ciphers to configure TLS encryption
; can be 'none', 'low', 'medium', 'high', 'fips'
crypt_level=high
; X.509 certificate and private key
; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 
365
; note this needs the user xrdp to be a member of the ssl-cert group, do with 
e.g.
;$ sudo adduser xrdp ssl-cert
certificate=
key_file=
; set SSL protocols
; can be comma separated list of 'SSLv3', 'TLSv1', 'TLSv1.1', 'TLSv1.2', 
'TLSv1.3'
ssl_protocols=TLSv1.2, TLSv1.3
;ssl_protocols=TLSv1, TLSv1.1, TLSv1.2, TLSv1.3
; set TLS cipher suites
; Section name to use for automatic login if the client sends username
; and password. If empty, the domain name sent by the client is used.
; If empty and no domain name is given, the first suitable section in
; this file will be used.
autorun=
allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
max_bpp=32
new_cursors=true
; fastpath - can be 

Bug#958853: Fix

[Dan O'Huiginn]

Upstream has now moved away from Bazel: 
https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4b202c08bd740c7bb37763

The new build system uses cargo and ninja. It'll still be a substantial job to 
package this for Debian, but hopefully more feasible than before.

Bug#1026826: RM: debian-lan-config -- ROM; superseded by configuration management systems; not maintained/tested anymore

[Andreas B. Mundt]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: debian-lan-con...@packages.debian.org, a...@debian.org
Control: affects -1 + src:debian-lan-config

Hi,

please exclude debian-lan-config from the bookworm release.
The package has no reverse dependencies and contains only a
FAI config space.  However, it is not tested anymore and more 
appropriate configuration management systems are available.

Thanks,

  Andi

Bug#1026825: python3.11 as default

[Matthias Klose]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian-pyt...@lists.debian.org

Please setup a transition window for python 3.11 as the default python3 version.
 A tracker is setup at

https://release.debian.org/transitions/html/python3.11-default.html

Thanks to many Debian and Ubuntu developers, this transition is now finished for
Ubuntu, and outstanding bug reports should be filed as
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.11;users=debian-pyt...@lists.debian.org

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Bill Allombert]

On Wed, Dec 21, 2022 at 03:23:09PM +0100, Adam Borowski wrote:
> On Mon, Dec 19, 2022 at 10:44:12PM +0100, Bill Allombert wrote:
> > Which raise the question: does the corresponding user group moved to UTF-8 ?
> > Judging from ,
> > neither Chinese nor Japanese users have overwhelmingly moved to UTF-8,
> > so it would be problematic to stop supporting BIG5, GB18030 and EUC-JP.
> 
> We actually do have data about locale usage in Debian.
> I've copied .report files from bugs-mirror, and
> grep -arm1 ^Locale: */*/*.report
> shows that:
> * most recent use of BIG5 is #925894 from March 2019
> * there's no use of any GB locale (other than en_GB :p) past #609517 (2011)
> * for EUC there's #1001207 (2021) #953616 #939588 #939494 #893625

I do not think bug submitters expect the Locale field to be used for locale
usage statistics, so it does not seem fair to use it for that purpose.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#947325: snapd: strict confinement is not enabled

[Peter Allebone]

Hi there,

I am also affected by this issue. I am a Debian testing (currently
bookworm) user and am using snaps for front end apps so as to have updates
for them immediately available, and was under the impression the
confinement was working until I noticed a problem. For example using
firefox-esr via the snap version I had expected sandboxing and confinement
to be on par with the sister project Ubuntu.

However checking:
snap debug sandbox-features
Shows output:
confinement-options:  classic devmode

The expected result would be confinement-options:  classic devmode *strict*

Also checking
*:*
snap debug confinement
Shows output:
partial

The expected result would be *strict*

As a result it appears to me that a security issue is present. I realise
that this is an older bug report but there has not been any movement on it
for some time. Is there anything that can be done to try to progress this
issue towards a resolution while not making anyone unhappy, so I dont want
to upset anyone. Please let me know who I can ask kindly for help on this
if possible? I love everyone and Debian and just want features downstream
to make their way back up so that Debian stays strong and the number 1
choice for users needing a free and open source solution. Thank you in
advance.

Kind regards
Peter

Bug#1026824: RFS: cglm/0.8.8-1 -- Optimized OpenGL Mathematics library for C

[Leon Marz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : cglm
   Version  : 0.8.8-1
   Upstream contact : Recep Aslantas 
 * URL  : https://github.com/recp/cglm
 * License  : Expat
 * Vcs  : https://salsa.debian.org/debian/cglm
   Section  : libs

The source builds the following binary packages:

  libcglm-doc - Documentation for the cglm library
  libcglm-dev - Development files for the cglm library
  libcglm0 - Optimized OpenGL Mathematics library for C

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/c/cglm/cglm_0.8.8-1.dsc

Changes since the last upload:

 cglm (0.8.8-1) unstable; urgency=medium
 .
   * New upstream release
   * d/control: janitor: Apply multi-arch hints
   * d/patches: Remove (fixed by upstream)
   * d/control: Update feature list in description
   * d/watch: Use the example from uscan(1)
   * d/control: Bump Standards-Version to 4.6.2
 - no changes needed

- Leon


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Adam Borowski]

On Mon, Dec 19, 2022 at 07:08:09PM +, Simon McVittie wrote:
> On Fri, 16 Dec 2022 at 19:21:37 +0100, Adam Borowski wrote:
> > As of Bookworm, legacy locales are no longer officially supported.
> 
> For clarity, I think when you say "legacy locales" you mean locales
> whose character encoding is either explicitly or implicitly something
> other than UTF-8 ("legacy national encodings"), like en_US (implicitly
> ISO-8859-1 according to /usr/share/i18n/SUPPORTED) and en_GB.ISO-8859-15
> (explicitly ISO-8859-15 in its name). True?

Aye.

> Many of the non-UTF-8 encodings are single-byte encodings in the
> ISO-8859 family, but if I understand correctly, your reasoning applies
> equally to multi-byte east Asian encodings like BIG5, GB18030 and EUC-JP.
> Also true?

Aye.  Anything but UTF-8.

> Meanwhile, locales with a UTF-8 character encoding, like en_AG
> (implicitly UTF-8 according to /usr/share/i18n/SUPPORTED) or en_US.UTF-8
> (explicitly UTF-8), are the ones you are considering to be non-legacy.
> Also true?

Right.

> I think for Policy use, this would have to say something more precise,
> like "locales with a non-UTF-8 character encoding". I wouldn't want to
> get en_US speakers trying to argue that en_GB.UTF-8 is a legacy locale,
> or en_GB speakers like me trying to argue that en_US.UTF-8 is a legacy
> locale :-)

English (traditional) vs English (simplified) :p

> When you say "officially supported" here, do you refer to the extent
> to which they are supported by the glibc maintainers, or some other
> group? Or are you describing a change request that they *should not*
> be officially supported by Debian - something that is not necessarily
> true yet, but in this bug you are asking for it to become true?

My primary source is glibc, especially the debconf questions from "locales",
although bit-rot and/or outright droppage is widespread in other packages.

> > * Software may assume they always run in an UTF-8 locale, and emit or
> >   require UTF-8 input/output without checking.
> 
> I suspect this is already common: for example, ikiwiki is strictly
> UTF-8-only and ignores locales' character sets, which is arguably a bug
> right now but would become a non-bug with your proposed policy.

Exactly, I want to declare that a non-bug, thus saving developer time.

> This is a "may" so it can't possibly make a package gain bugs. It might
> make packages have fewer bugs.

Aye.

> > * The execution environment (usually init system or a container) must
> >   default to UTF-8 encoding unless explicitly configured otherwise.
> 
> Is this already true? This seems like the sort of thing which should be
> fixed in at least the major init systems and container managers before it
> goes into Policy, in the interests of not making those init systems and
> container managers retroactively buggy.

Systemd does so since version 240, sysvinit relies on settings in /etc/
thus in the case of bare debootstrap the variables might be unset -- which
is mostly moot since glibc 2.35.  We briefly discussed an one-line patch
to ensure there's a fallback default, it's currently not applied (but can
be).  This would be relevant only for corner cases like an unconfigured
system running non-glibc non-musl binaries that rely on LC_*.

I'm less knowledgeable about containers, but they appear to work.  It might
be due to copying variables from the host or having template defaults...

Anyway, my aim is more to tell packages that they are allowed to misbehave
when the settings are missing than to hunt misuse scenarios.  But, if such
a scenario is found, with the current Policy there is no recourse, while
if this rule is added it would be a bug.

> > * Legacy locales are no longer officially supported, and packages may
> >   drop support for them and/or exclude them from their testsuites.
> > * Packages may retain support for legacy locales, but related bug reports
> >   (unless security related) are considered to be of wishlist severity.
> 
> Is the C (aka POSIX) locale still a non-UTF-8 locale (if I remember
> correctly its character encoding is officially 7-bit ASCII), or has it
> been redefined to be UTF-8? Given the special status of the C locale in
> defaults and standards, it might be necessary to say that it's the only
> supported locale with a non-UTF-8 character encoding.

Hmm... if I recall correctly, old POSIX left the behaviour of characters
above 126 undefined, making C.UTF-8 _almost_ match the requirements (with
only exception being iswblank() IIRC), but current version specifies ASCII
(rather than C standard's "portable subset") with no additions to character
classes other than cntrl and punct allowed.

This is the locale all processes start with, until they call setlocale().
I'm still not decided whether it should be allowed as the system locale
(ie, when a process says it wants locale handling enabled).

Having it breaks non-ASCII in GUIs, some text output, causes misalignment,
etc.  Thus maybe we can relegate it to the 

Bug#1026823: RFS: zvbi/0.2.39-1 -- Vertical Blanking Interval (VBI) utilities

[Ileana Dumitrescu]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : zvbi
   Version  : 0.2.39-1
   Upstream contact : Ileana Dumitrescu 
 * URL  : https://github.com/zapping-vbi/zvbi
 * License  : GPL-2+, LGPL-2.1+, LGPL-2+, GPL-2+ or 
BSD-3-Clause, MIT, GPL-2, BSD-2-Clause

 * Vcs  : https://salsa.debian.org/debian/zvbi
   Section  : devel

The source builds the following binary packages:

  libzvbi0 - Vertical Blanking Interval decoder (VBI) - runtime files
  libzvbi-dev - Vertical Blanking Interval decoder (VBI) - development 
files

  libzvbi-common - Vertical Blanking Interval decoder (VBI) - common files
  libzvbi-doc - Vertical Blanking Interval decoder (VBI) - 
documentation files

  zvbi - Vertical Blanking Interval (VBI) utilities

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zvbi/zvbi_0.2.39-1.dsc


Changes since the last upload:

 zvbi (0.2.39-1) unstable; urgency=medium
 .
   * New upstream release.
   * debian/rules: Remove NOCONFIGURE=1.



I am also hoping to work with a mentors team member to help secure a key 
endorsement for my DM application. Please let me know what I can do!




Regards,

--
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026822: dkms: dkms status reporting wrong information as of v3.0.9

[Michael Prokop]

Package: dkms
Version: 3.0.9-1
Severity: important

Hi,

this seems to be a regression introduced with v3.0.9:

| # dkms --version
| dkms-3.0.8
| # dkms status
| 
ngcp-rtpengine/11.2.0.0+0~mr11.2.0.0+0~20221221143425.14231+bookworm~1.gbpd751bc,
 6.0.0-6-amd64, x86_64: installed

vs:

| # dkms --version
| dkms-3.0.9
| # dkms status
| 
ngcp-rtpengine/11.2.0.0+0~mr11.2.0.0+0~20221221143425.14231+bookworm~1.gbpd751bc,
 6.0.0-6-amd64, x86_64: installed (WARNING! Diff between built and installed 
module!)

Executing `dkms status` under `bash -x` shows:

| [...]
| ++ compare_module_version 
/var/lib/dkms/ngcp-rtpengine/kernel-6.0.0-6-amd64-x86_64/module/xt_RTPENGINE.ko 
/lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko
| ++ for l in $locations
| +++ compressed_or_uncompressed /lib/modules/6.0.0-6-amd64/extra xt_RTPENGINE
| +++ local test1=/lib/modules/6.0.0-6-amd64/extra/xt_RTPENGINE.ko
| +++ local test2=/lib/modules/6.0.0-6-amd64/extra/xt_RTPENGINE.ko
| +++ [[ -e /lib/modules/6.0.0-6-amd64/extra/xt_RTPENGINE.ko ]]
| +++ [[ -e /lib/modules/6.0.0-6-amd64/extra/xt_RTPENGINE.ko ]]
| ++ installed=
| ++ [[ -n '' ]]
| + real_dest=
| ++ compressed_or_uncompressed /lib/modules/6.0.0-6-amd64 xt_RTPENGINE
| ++ local test1=/lib/modules/6.0.0-6-amd64/xt_RTPENGINE.ko
| ++ local test2=/lib/modules/6.0.0-6-amd64/xt_RTPENGINE.ko
| ++ [[ -e /lib/modules/6.0.0-6-amd64/xt_RTPENGINE.ko ]]
| ++ [[ -e /lib/modules/6.0.0-6-amd64/xt_RTPENGINE.ko ]]
| + real_dest_mod=
| + diff -q 
/var/lib/dkms/ngcp-rtpengine/11.2.0.0+0~mr11.2.0.0+0~20221221143425.14231+bookworm~1.gbpd751bc/6.0.0-6-amd64/x86_64/module/xt_RTPENGINE.ko
 ''
| + echo -n ' (WARNING! Diff between built and installed module!)'
|  (WARNING! Diff between built and installed module!)+ (( count++ ))
| + (( count < 1 ))
| + echo
| [...]

Note the `diff -q 
/var/lib/dkms/ngcp-rtpengine/11.2.0.0+0~mr11.2.0.0+0~20221221143425.14231+bookworm~1.gbpd751bc/6.0.0-6-amd64/x86_64/module/xt_RTPENGINE.ko
 ''`
which clearly is wrong and can't work as-is, while the underlying
modules are identical:

| # md5sum 
/var/lib/dkms/ngcp-rtpengine/kernel-6.0.0-6-amd64-x86_64/module/xt_RTPENGINE.ko 
/lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko
| 73c0b2503d9981d64df89aa9aadefd68  
/var/lib/dkms/ngcp-rtpengine/kernel-6.0.0-6-amd64-x86_64/module/xt_RTPENGINE.ko
| 73c0b2503d9981d64df89aa9aadefd68  
/lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko

When running `dkms status` under `bash -x` with dkms v3.0.8 it's fine:

| ++ diff 
/var/lib/dkms/ngcp-rtpengine/kernel-6.0.0-6-amd64-x86_64/module/xt_RTPENGINE.ko 
/lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko
| ++ echo /updates/dkms
| ++ return 0
| + real_dest=/updates/dkms
| ++ compressed_or_uncompressed /lib/modules/6.0.0-6-amd64/updates/dkms 
xt_RTPENGINE
| ++ local test1=/lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko
| ++ local test2=/lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko
| ++ [[ -e /lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko ]]
| ++ echo /lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko
| + real_dest_mod=/lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko
| + diff -q 
/var/lib/dkms/ngcp-rtpengine/11.2.0.0+0~mr11.2.0.0+0~20221221143425.14231+bookworm~1.gbpd751bc/6.0.0-6-amd64/x86_64/module/xt_RTPENGINE.ko
 /lib/modules/6.0.0-6-amd64/updates/dkms/xt_RTPENGINE.ko
| + (( count++ ))
| + (( count < 1 ))

So something about setting the $real_dest_mod seems to have been
broken with latest version.

regards
-mika-

Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'

[olivier sallou]

On Wed, 2022-12-21 at 19:39 +0530, Nilesh Patra wrote:
> On Wed, 21 Dec 2022 12:32:25 +0100 olivier sallou
>  wrote:
> > On Wed, 2022-12-21 at 11:02 +0100, olivier sallou wrote:
> > > looks like a python3 issue (though was already adapter to py3...)
> > > 
> > > will have a look and reproduce
> > 
> > I could reproduce and found an issue with demo_checker.py handling
> > with
> > python3
> > 
> > I have a patch. will test it and upload
> 
> I wrote a patch as well, and was going to upload, but you beat me to
> it, hah :/

sorry, I did not set me as bug owner but sent comments anyway so that
others are aware I was on issue

and this package is so long to build.

> My patch is quite similar to yours, though.
> 

I fixed py2 / py3 bytes error in 2 places and skipped mason2 tests as
described in patch and previous message

Just uploaded fixed package

Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#1019521: blhc: False positive for Qt6 moc

[Eriberto]

Em qua., 21 de dez. de 2022 às 11:23, Simon Ruderich
 escreveu:
> Hi Ross,
>
> thanks for the patch. Looks good. Pushed to [1].
>
> Best,
> Simon
>
> [1] 
> https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=018466d7ddd9c78f1e1efbafbb7be2f969e1bbd1


Thanks Simon.

Bug#1026804: WIFI doesn't work for kernel 6.1

[Diederik de Haas]

On Wednesday, 21 December 2022 17:11:55 CET Diederik de Haas wrote:
> Given that it worked with 6.0 but no more with 6.1-1~exp1 which I assume is
> a self-built kernel from current master, it seems more likely to be an
> upstream issue/regression.

I just noticed the following part from that linux-amlogic post:
> I native build kernel from debian's kernel repo:
> https://salsa.debian.org/kernel-team/linux/ with some Amlogic patches:
> https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/feat
> ures/arm64/meson all follow debian's kernel config.

That path doesn't seem to exist anymore, but got redirected to 'just' the 
master branch and noticed the latest commit "update patches from khadas".
When I looked into that, I saw there were a LOT of additional patches :-O
https://salsa.debian.org/zhangn1985/linux/-/tree/master/debian/patches/
features/khadas

The test I suggested in my previous reply would still be useful, but it could 
also be that your patch-set is at fault.


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

Bug#1026821: python-matplotlib-doc: Broken search functionality

[Cédric Hannotier]

Package: python-matplotlib-doc
Version: 3.5.2-4
Severity: normal

Dear Maintainer,

Search does not work anymore.
It fails with the following message:

```
Uncaught ReferenceError: SPHINX_HIGHLIGHT_ENABLED is not defined
at Object.query (searchtools.js:279)
at Object.performSearch (searchtools.js:238)
at HTMLDocument.init (searchtools.js:179)
```

Rebuilding the package solves the issue.
IMO, its due to the major version bump of libjs-sphinxdoc.

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 python-matplotlib-doc depends on:
ii  libjs-jquery 3.6.1+dfsg+~3.5.14-1
ii  libjs-sphinxdoc  5.3.0-2

python-matplotlib-doc recommends no packages.

python-matplotlib-doc suggests no packages.

-- no debconf information

-- 

Cédric Hannotier

Bug#1026804: WIFI doesn't work for kernel 6.1

[Diederik de Haas]

On Wednesday, 21 December 2022 12:47:45 CET Zhang Ning wrote:
> Package: linux-image-arm64
> Version: 6.1-1~exp1
> 
> WIFI works well for my Arm64 SBCs (Khadas VIM1 & VIM3), both are Amlogic
> SBC, S905x and A311D, with kernel 6.0 and early versions.
> 
> these two boards are well supported by debian kernel, with all functions
> work out of box.
> 
> After update to 6.1, it stops work.
> 
> WIFI doesn't response, please check attached logs.
> 
> before send this bug to debian, I have asked upsteam[0], and device
> vendor, whether they observe same issue, but the answers are no.
> 
> thus I suspect this is the problem of debian kernel.
> 
> [0]
> http://lists.infradead.org/pipermail/linux-amlogic/2022-December/014544.htm
> l

Given that it worked with 6.0 but no more with 6.1-1~exp1 which I assume is a 
self-built kernel from current master, it seems more likely to be an upstream 
issue/regression.

In the linux-amlogic post [0] it was tested with 6.1-rc8.
https://tracker.debian.org/pkg/linux shows there have been several uploads of 
6.1-rcX to experimental, so could you test those first?

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

Bug#1026819: regression in DB?

[Ivan Sergio Borgonovo]

Package: php-horde-db
Version: 2.4.1-4

Upgrading from 2.4.1-3

got me

A fatal error has occurred
Return value of Horde_Db_Adapter_Base_Result::current() must be an 
instance of mixed, array returned

in /usr/share/php/Horde/Db/Adapter/Base/Result.php:136

Since I run a manually patched version and I've lost track of the 
patches that reached upstream I can't say if it is a regression or a 
previously unoticed problem or something I forgot to report but


line 131 of /usr/share/php/Horde/Db/Adapter/Base/Result.php

should be

public function current(): array

thanks


--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#1026648: parole: FTBFS: make[1]: *** [debian/rules:22: override_dh_missing] Error 25

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2022-12-20 at 18:38 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_missing --fail-missing -X .la
> > dh_missing: warning: usr/parole/pixmaps/no-cover.png exists in debian/tmp
> > but is not installed to anywhere 
> > dh_missing: warning: usr/parole/pixmaps/play.png exists in debian/tmp but
> > is not installed to anywhere 
> > dh_missing: warning: usr/parole/pixmaps/replay.png exists in debian/tmp
> > but is not installed to anywhere 
> > dh_missing: error: missing files, aborting
> > The following debhelper tools have reported what they installed
> > (with files per package)
> >  * dh_install: parole (5), parole-dev (1)
> >  * dh_installdocs: parole (0), parole-dev (0)
> >  * dh_installman: parole (1), parole-dev (0)
> > If the missing files are installed by another tool, please file a
> > bug against it.
> > When filing the report, if the tool is not part of debhelper
> > itself, please reference the
> > "Logging helpers and dh_missing" section from the "PROGRAMMING"
> > guide for debhelper (10.6.3+).
> >   (in the debhelper package:
> > /usr/share/doc/debhelper/PROGRAMMING.gz)
> > Be sure to test with dpkg-buildpackage -A/-B as the results may
> > vary when only a subset is built
> > If the omission is intentional or no other helper can take care of
> > this consider adding the
> > paths to debian/not-installed.
> > make[1]: *** [debian/rules:22: override_dh_missing] Error 25

Hi Lucas, thanks for the report. It seems that the pixmaps aren't installed to
the correct path, because pixmapsdir isn't defined to the correct place, in
turn because DATADIRNAME isn't defined anymore.

I'm unsure what changed in Debian since the initial upload in 2021, maybe some
autoconf macros or something.

It *seems* that DATADIRNAME might be obsolete (since a long time), it's not in
/usr/share/aclocal/gettext.m4 but I can see a lot of embedded copies with
https://codesearch.debian.net/search?q=DATADIRNAME (I looked at the gettext
changelog but couldn't find a reference).

It's likely an upstream issue but still I'm unsure where to point them.
Apparently there's datadir/datarootdir but as I'm not an autoconf expert I'm
not sure if it'd work in place.

Any pointer appreciated here.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmOjJl8ACgkQ3rYcyPpX
RFv/XwgA4Ly4KInLEQ2j60tBvndrsJ7B4RIRyJH8Lb1nxwdP/XAWq93o3p/6bgTR
SCdYYhret3y2M2jbZiJLY51/9EpOzKc2Ut8K2+mtm3sHpT+mMWLs3qbufOTE2MpL
VMPtWg0dMHT9/eOjXbrcKCrNFhJLm/oxsIgdSXzsNL/5z70ARCo7MYi97bt22KjW
uEFXrctxqDRdG6srwtj3cfYGufMAtYFWGwLcj+zvR730IZcjdscXrhbb4yHGKF/R
p9hrzKS6l/smBfRJyf9h1lSxH8Pw1AKV+qBO4n5sX7GJ6rdDHpsc3kuZlivvpgSM
UmL9nyEmuhOyrhdL1VgZr+9FfEE76w==
=kpYg
-END PGP SIGNATURE-

Bug#1026818: ITP: usagef -- A tool to print formatted usage messages

[Justin Morgan]

Package: wnpp
Severity: wishlist
Owner: Justin Morgan <2justinmor...@gmail.com>
X-Debbugs-Cc: debian-de...@lists.debian.org, 2justinmor...@gmail.com

* Package name: usagef
  Version : 0.1.0
  Upstream Author : Name <2justinmor...@gmail.com>
* URL : https://github.com/litelibs/usagef/
* License : (MIT/X)
  Programming Lang: (C)
  Description : A tool to print formatted usage messages

Designed for developers of shell scripts, the usagef terminal tool
prints consistent formatted usage messages that contain the information
passed as argv args of the usagef program. 

Here is an example of how usagef can be used to print the usage message
of a custom script, deploy.sh.

$ usagef \
  --name "deploy.sh" \
  --argv "[options]  " \
  --description "Deploy a package to the specified environment" \
  --item "Options:-f, --force:Forces the deployment" \
  --item "Options:-t, --api-token :Specify the api token used" \
  --item "Options:-r, --report :Email a report to someone" \
  --item "Options:-j, --json:Prints output in json format" \
  --item "Environment:dev:Deploy to dashboard.dev.company.com" \
  --item "Environment:preprod:Deploy to dashboard.preprod.company.com" \
  --item "Environment:prod:Deploy to dashboard.company.com" \
  --item "Package:user:Deploys updated user accounts" \
  --item "Package:security:Deploys vetted security protocols"  \
  --item "Package:logging:Deploys a new, and archives old logs"

[OUTPUT]

Usage: deploy.sh [options]  

Deploy a package to the specified environment

Options:
  -f, --force  Forces the deployment
  -t, --api-token   Specify the api token used
  -r, --report  Email a report to someone
  -j, --json   Prints output in json format

Environment:
  dev  Deploy to dashboard.dev.company.com
  preprod  Deploy to dashboard.preprod.company.com
  prod Deploy to dashboard.company.com

Package:
  user  Deploys updated user accounts
  security  Deploys vetted security protocols
  logging   Deploys a new, and archives old logs



- Why is this package useful/relevant? 
  This package is useful because it bypasses the repeat efforts of
  maintaining consistent formatting of shell script usage messages.
- Is it a dependency for another package?
  No, this is not a dependency for another package.
- Do you use it?
  Yes, it is self-used. A few prototypes have been developed, thus inspiring
  the development of this package.
- If there are other packages providing similar functionality, how does it
  compare?
  There are no known packages that provide similar functionality.
- How do you plan to maintain it?
  Maintenance is planned to be a request-driven method that serves
  user's needs mentioned in https://github.com/litelibs/usagef/issues.
- Inside a packaging team (check list at https://wiki.debian.org/Teams)?
  No, maintenance will not be coordinated via Debian teams. However, a team at
  https://wiki.debian.org/Teams may be needed for future works of usagef.
- Are you looking for co-maintainers?
  No, a co-maintainer is not needed. However, a co-maintainer may be needed for
  future works of usagef.
- Do you need a sponsor?
  No, it is believed that a sponsor is not needed. However, a sponsor would be
  nice to have.

Bug#997224: btag: FTBFS: InteractiveTagger.cpp:201:34: error: ‘bool TagLib::String::isNull() const’ is deprecated [-Werror=deprecated-declarations]

[Eric Long]

tag -1 patch thanks

Also, it seemed that zlib is missing from building dependencies in my 
sbuild chroot:


```
[ 46%] Linking CXX executable btag
/usr/bin/cmake -E cmake_link_script CMakeFiles/btag.dir/link.txt 
--verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Werror -Wl,-z,relro -Wl,-z,now -rdynamic 
CMakeFiles/btag.dir/src/BasicStringFilter.cpp.o 
CMakeFiles/btag.dir/src/ConfirmationHandler.cpp.o 
CMakeFiles/btag.dir/src/EnglishTitleLocalizationHandler.cpp.o 
CMakeFiles/btag.dir/src/InteractiveTagger.cpp.o 
CMakeFiles/btag.dir/src/main.cpp.o 
CMakeFiles/btag.dir/src/RenamingFilter.cpp.o 
CMakeFiles/btag.dir/src/SimpleCapitalizationFilter.cpp.o 
CMakeFiles/btag.dir/src/SpanishTitleLocalizationHandler.cpp.o 
CMakeFiles/btag.dir/src/StandardConsole.cpp.o 
CMakeFiles/btag.dir/src/TitleCapitalizationFilter.cpp.o 
CMakeFiles/btag.dir/src/TitleLocalizationHandler.cpp.o -o btag 
/usr/lib/riscv64-linux-gnu/libboost_filesystem.so.1.74.0 
/usr/lib/riscv64-linux-gnu/libboost_system.so.1.74.0 -ltag -lz

/usr/bin/ld: cannot find -lz: No such file or directory
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/btag.dir/build.make:262: btag] Error 1
```

By adding `zlib1g-dev` to Build-Depends in d/control, this is fixed.

Cheers,
Eric

Bug#997224: btag: FTBFS: InteractiveTagger.cpp:201:34: error: ‘bool TagLib::String::isNull() const’ is deprecated [-Werror=deprecated-declarations]

[Eric Long]

Source: btag
Version: 1.1.3-1
Followup-For: Bug #997224
X-Debbugs-Cc: i...@hack3r.moe

tag -1 patch thanks

Hello,

Attached is a patch that replaces deprecated methods and variables according to
TagLib official docs [1]. It fixes FTBFS and it should work well too.

If more help is needed, please let me know.

Cheers,
Eric

[1]: https://taglib.org/api/classTagLib_1_1String.html
--- a/src/InteractiveTagger.cpp
+++ b/src/InteractiveTagger.cpp
@@ -198,7 +198,7 @@
 
 // Ask for the artist
 artist_confirmation.reset();
-if (!f.tag()->artist().isNull())
+if (!f.tag()->artist().isEmpty())
 
artist_confirmation.set_local_default(m_input_filter->filter(f.tag()->artist().toWString()));
 artist_confirmation.ask(L"Artist:");
 while (!artist_confirmation.complies())
@@ -207,7 +207,7 @@
 
 // Ask for the album
 album_confirmation.reset();
-if (!f.tag()->album().isNull())
+if (!f.tag()->album().isEmpty())
 
album_confirmation.set_local_default(m_input_filter->filter(f.tag()->album().toWString()));
 album_confirmation.ask(L"Album:");
 while (!album_confirmation.complies())
@@ -236,7 +236,7 @@
 // Ask for the song title
 ConfirmationHandler title_confirmation(*m_terminal, m_input_filter, 
m_output_filter);
 title_confirmation.reset();
-if (!f.tag()->title().isNull())
+if (!f.tag()->title().isEmpty())
 
title_confirmation.set_local_default(m_input_filter->filter(f.tag()->title().toWString()));
 title_confirmation.ask(L"Title:");
 while (!title_confirmation.complies())
@@ -244,8 +244,8 @@
 f.tag()->setTitle(title_confirmation.answer());
 
 // Reset the comment and genre fields
-f.tag()->setComment(TagLib::String::null);
-f.tag()->setGenre(TagLib::String::null);
+f.tag()->setComment(TagLib::String());
+f.tag()->setGenre(TagLib::String());
 
 // Add it to the list of unsaved files
 m_unsaved_files.push_back(f);

Bug#784182: blhc: warns about disabled flags

[Simon Ruderich]

On Fri, Sep 30, 2022 at 11:19:16AM +0200, IOhannes m zmoelnig wrote:
> i've bumped into this with my 'o2' builds (which also uses "-fortify") on
> salsa, so it is not really "fixed" (as of 2022-09)
>
> of course i could add a 'blhc: ignore-line-regexp:', but in practice that
> would disable the entire blhc check.
> or I could add some "--ignore-flag -D_FORTIFY_SOURCE=2"  to the invocation
> of blhc.
> but really i'd like to not do this, as it requires me to manually check
> which flags get disabled by which DEB_BUILD_MAINT_OPTIONS=hardening option
> and fix this blhc-invocation whenever a package requires special hardening
> flags...

Hi IOhannes,

I'm somewhat out of the loop regarding Debian's build process. Is
this something blhc can extract from the build log?

Best,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'

[olivier sallou]

upstream, in develop branch has disabled mason2 testing for gcc > 10 ,
don't know why, but let's do the same as it is the one failing now with
indeed superior gcc

I am adapting the patch and testing again.



gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#1019521: blhc: False positive for Qt6 moc

[Simon Ruderich]

On Wed, Dec 21, 2022 at 11:00:56AM -0300, Eriberto wrote:
> Hi Simon,
>
> Could you check the patch below?
>
> Regards,
>
> Eriberto
>
> Em qua., 21 de dez. de 2022 às 03:51, Ross Vandegrift
>  escreveu:
>>
>> Package: blhc
>> Version: 0.13-2
>> Followup-For: Bug #1019521
>> X-Debbugs-Cc: rvandegr...@debian.org
>>
>> Hello,
>>
>> I also ran into this- moc is now at /usr/lib/qt6/libexec/moc.  I think the
>> attached patch should address this.

Hi Ross,

thanks for the patch. Looks good. Pushed to [1].

Best,
Simon

[1] 
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=018466d7ddd9c78f1e1efbafbb7be2f969e1bbd1
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Adam Borowski]

On Mon, Dec 19, 2022 at 10:44:12PM +0100, Bill Allombert wrote:
> Which raise the question: does the corresponding user group moved to UTF-8 ?
> Judging from ,
> neither Chinese nor Japanese users have overwhelmingly moved to UTF-8,
> so it would be problematic to stop supporting BIG5, GB18030 and EUC-JP.

We actually do have data about locale usage in Debian.
I've copied .report files from bugs-mirror, and
grep -arm1 ^Locale: */*/*.report
shows that:
* most recent use of BIG5 is #925894 from March 2019
* there's no use of any GB locale (other than en_GB :p) past #609517 (2011)
* for EUC there's #1001207 (2021) #953616 #939588 #939494 #893625

Thus:
* Chinese encodings are totally dead for being used as a system locale
* Japanese are nearly so

That Wikipedia page presents stuff from 2008 as new developments, thus is
a wee bit outdated...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver!
⠈⠳⣄

Bug#1023557: rygel: consider After=network.target in rygel.service for lingering

[Barak A. Pearlmutter]

Cool!

I had assumed, from the log messages etc, that this was likely a race
condition between the network configuration changing and rygel being
notified of, and adjusting to, said configuration.

Bug#1026816: speedcrunch: FTBFS: KeyError: 'extra-doc-strings'

[Lucas Nussbaum]

Source: speedcrunch
Version: 0.12.0-5.1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20221221 ftbfs-bookworm

Hi,

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


Relevant part (hopefully):
> make[4]: Entering directory '/<>/build-docs'
> [100%] Generating manual.qrc
> Running Sphinx v5.3.0
> WARNING: Invalid configuration value found: 'language = None'. Update your 
> configuration to a valid language code. Falling back to 'en' (English).
> loading translations [en_US]... not available for built-in messages
> 
> Exception occurred:
>   File "/<>/doc/src/extensions/translations.py", line 29, in _
> return locale.translators[_CATALOG].gettext(message)
> KeyError: 'extra-doc-strings'
> The full traceback has been saved in /tmp/sphinx-err-avr0b5ds.log, if you 
> want to report the issue to the developers.
> Please also report this if it was a user error, so that a better error 
> message can be provided next time.
> A bug report can be filed in the tracker at 
> <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
> Building docs for en_US...
> Traceback (most recent call last):
>   File "/<>/doc/src/doc-tool.py", line 208, in 
> main(sys.argv)
>   File "/<>/doc/src/doc-tool.py", line 202, in main
> args.func(tools, args)
>   File "/<>/doc/src/doc-tool.py", line 135, in build_bundled_docs
> build_docs(tools, args.source_dir, args.build_dir, lang,
>   File "/<>/doc/src/doc-tool.py", line 77, in build_docs
> return tools.sphinx_build(*args)
>   File "/<>/doc/src/doc-tool.py", line 52, in 
> return lambda *args: self.run_tool(name, *args)
>   File "/<>/doc/src/doc-tool.py", line 49, in run_tool
> return subprocess.check_call(cmd)
>   File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
> raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['/usr/bin/sphinx-build', 
> '/<>/doc/src', '/<>/build-docs/en_US', '-b', 
> 'qthelp2', '-D', 'qthelp_basename=manual-en_US', '-D', 'language=en_US', 
> '-t', 'sc_bundled_docs']' returned non-zero exit status 2.
> make[4]: *** [CMakeFiles/manual.dir/build.make:102: manual.qrc] Error 1


The full build log is available from:
http://qa-logs.debian.net/2022/12/21/speedcrunch_0.12.0-5.1_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221221;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20221221=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Bug#1026817: lomiri-indicator-network: FTBFS: Critical: getprop process failed: "execvp: No such file or directory" ((null):0, (null))

[Lucas Nussbaum]

Source: lomiri-indicator-network
Version: 1.0.0~git20220718.2ca3619-4
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20221221 ftbfs-bookworm

Hi,

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


Relevant part (hopefully):
> [--] Global test environment tear-down
> [==] 66 tests from 6 test suites ran. (3020373 ms total)
> [  PASSED  ] 36 tests.
> [  FAILED  ] 30 tests, listed below:
> [  FAILED  ] TestIndicator.BasicMenuContents
> [  FAILED  ] TestIndicator.OneDisconnectedAccessPointAtStartup
> [  FAILED  ] TestIndicator.OneConnectedAccessPointAtStartup
> [  FAILED  ] TestIndicator.AddOneDisconnectedAccessPointAfterStartup
> [  FAILED  ] TestIndicator.AddOneConnectedAccessPointAfterStartup
> [  FAILED  ] TestIndicator.SecondModem
> [  FAILED  ] TestIndicator.SimStates_NoSIM
> [  FAILED  ] TestIndicator.SimStates_NoSIM2
> [  FAILED  ] TestIndicator.SimStates_LockedSIM
> [  FAILED  ] TestIndicator.SimStates_LockedSIM2
> [  FAILED  ] TestIndicator.SimStates_UnlockedSIM
> [  FAILED  ] TestIndicator.SimStates_UnlockedSIM2
> [  FAILED  ] TestIndicator.FlightMode_NoSIM
> [  FAILED  ] TestIndicator.FlightMode_LockedSIM
> [  FAILED  ] TestIndicator.FlightMode_WifiOff
> [  FAILED  ] TestIndicator.FlightMode_WifiOn
> [  FAILED  ] TestIndicator.GroupedWiFiAccessPoints
> [  FAILED  ] TestIndicator.WifiStates_SSIDs
> [  FAILED  ] TestIndicator.WifiStates_Connect1AP
> [  FAILED  ] TestIndicator.WifiStates_Connect2APs
> [  FAILED  ] TestIndicator.WifiStates_AddAndActivate
> [  FAILED  ] TestIndicator.EnterpriseWifiConnect
> [  FAILED  ] TestIndicator.CellDataEnabled
> [  FAILED  ] TestIndicator.CellDataDisabled
> [  FAILED  ] TestIndicator.UnlockSIM_MenuContents
> [  FAILED  ] TestIndicator.UnlockSIM_Cancel
> [  FAILED  ] TestIndicator.UnlockSIM_CancelFirstUnlockSecond
> [  FAILED  ] TestIndicator.UnlockSIM_CorrectPin
> [  FAILED  ] TestIndicator.UnlockSIM_IncorrectPin
> [  FAILED  ] TestIndicator.UnlockSIM2_IncorrectPin
> 
> 30 FAILED TESTS
> 
> 
> 50% tests passed, 1 tests failed out of 2
> 
> Total Test time (real) = 3020.58 sec
> 
> The following tests FAILED:
> 1 - integration-tests (Failed)
> Errors while running CTest
> make[1]: *** [Makefile:74: test] Error 8
> make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j8 test 
> ARGS\+=--verbose ARGS\+=-j8 returned exit code 2


The full build log is available from:
http://qa-logs.debian.net/2022/12/21/lomiri-indicator-network_1.0.0~git20220718.2ca3619-4_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221221;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20221221=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Bug#1026815: ball: FTBFS: Package 'mpi-cxx', required by 'virtual:world', not found

[Lucas Nussbaum]

Source: ball
Version: 1.5.0+git20180813.37fc53c-10
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20221221 ftbfs-bookworm

Hi,

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


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> mkdir -p build
> cd build && LDFLAGS="-Wl,-z,relro -Wl,-z,now -ltirpc" CXXFLAGS="-g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -I/usr/include/tirpc" CFLAGS="-g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" \
> cmake .. -DCMAKE_SOURCE_DIR=/<> 
> -DCMAKE_INSTALL_PREFIX=./usr \
>   -DBALL_PATH=/usr -DBALL_DATA_PATH=/usr/share/BALL-1.5/data \
>   -DCMAKE_VERBOSE_MAKEFILE=ON
> CMake Deprecation Warning at CMakeLists.txt:10 (CMAKE_POLICY):
>   The OLD behavior for policy CMP0042 will be removed from a future version
>   of CMake.
> 
>   The cmake-policies(7) manual explains that the OLD behaviors of all
>   policies are deprecated and that a policy should be set to OLD only under
>   specific short-term circumstances.  Projects should be ported to the NEW
>   behavior and not rely on setting a policy to OLD.
> 
> 
> -- The C compiler identification is GNU 12.2.0
> -- The CXX compiler identification is GNU 12.2.0
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Compiler checks for conversion: OFF
> -- Looking for sys/types.h
> -- Looking for sys/types.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for stddef.h
> -- Looking for stddef.h - found
> -- Check size of char
> -- Check size of char - done
> -- Check size of short
> -- Check size of short - done
> -- Check size of int
> -- Check size of int - done
> -- Check size of long
> -- Check size of long - done
> -- Check size of size_t
> -- Check size of size_t - done
> -- Check size of void*
> -- Check size of void* - done
> -- Check size of unsigned short
> -- Check size of unsigned short - done
> -- Check size of unsigned int
> -- Check size of unsigned int - done
> -- Check size of unsigned long
> -- Check size of unsigned long - done
> -- Check size of unsigned long long
> -- Check size of unsigned long long - done
> -- Check size of float
> -- Check size of float - done
> -- Check size of double
> -- Check size of double - done
> -- Check size of uint64_t
> -- Check size of uint64_t - done
> -- Check size of uint32_t
> -- Check size of uint32_t - done
> -- Check size of uint16_t
> -- Check size of uint16_t - done
> -- Looking for C++ include unistd.h
> -- Looking for C++ include unistd.h - found
> -- Looking for C++ include process.h
> -- Looking for C++ include process.h - not found
> -- Looking for C++ include time.h
> -- Looking for C++ include time.h - found
> -- Looking for C++ include dirent.h
> -- Looking for C++ include dirent.h - found
> -- Looking for C++ include direct.h
> -- Looking for C++ include direct.h - not found
> -- Looking for C++ include pwd.h
> -- Looking for C++ include pwd.h - found
> -- Looking for C++ include stdint.h
> -- Looking for C++ include stdint.h - found
> -- Looking for C++ include sys/time.h
> -- Looking for C++ include sys/time.h - found
> -- Looking for C++ include sys/stat.h
> -- Looking for C++ include sys/stat.h - found
> -- Looking for C++ include sys/times.h
> -- Looking for C++ include sys/times.h - found
> -- Looking for C++ include sys/types.h
> -- Looking for C++ include sys/types.h - found
> -- Looking for C++ include sys/param.h
> -- Looking for C++ include sys/param.h - found
> -- Looking for C++ include sys/sysinfo.h
> -- Looking for C++ include sys/sysinfo.h - found
> -- Performing Test BALL_HAS_MODE_T
> -- Performing Test BALL_HAS_MODE_T - Success
> -- Looking for C++ include ieeefp.h
> -- Looking for C++ include ieeefp.h - not found
> -- Looking for kill
> -- Looking for kill - found
> -- Looking for sysconf
> -- Looking for sysconf - found
> -- Performing Test BALL_ALLOW_LONG64_TYPE_OVERLOADS
> -- Performing Test BALL_ALLOW_LONG64_TYPE_OVERLOADS - Failed
> -- Performing Test BALL

Bug#1026814: kreport: FTBFS: dh_install: error: missing files, aborting

[Lucas Nussbaum]

Source: kreport
Version: 3.2.0-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20221221 ftbfs-bookworm

Hi,

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


Relevant part (hopefully):
> make[2]: Entering directory '/<>/obj-x86_64-linux-gnu'
> make[2]: Nothing to be done for 'preinstall'.
> make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> Install the project...
> /usr/bin/cmake -P cmake_install.cmake
> -- Install configuration: "Debian"
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig/KReport3.pc
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/af/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ar/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ast/LC_MESSAGES/kreport_barcodeplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ast/LC_MESSAGES/kreport_mapsplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ast/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ast/LC_MESSAGES/kreport_webplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/be/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/bg/LC_MESSAGES/kreport_barcodeplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/bg/LC_MESSAGES/kreport_mapsplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/bg/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/br/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/bs/LC_MESSAGES/kreport_barcodeplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/bs/LC_MESSAGES/kreport_mapsplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/bs/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/bs/LC_MESSAGES/kreport_webplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ca/LC_MESSAGES/kreport_barcodeplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ca/LC_MESSAGES/kreport_mapsplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ca/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ca/LC_MESSAGES/kreport_webplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ca@valencia/LC_MESSAGES/kreport_barcodeplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ca@valencia/LC_MESSAGES/kreport_mapsplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ca@valencia/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/ca@valencia/LC_MESSAGES/kreport_webplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/cs/LC_MESSAGES/kreport_barcodeplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/cs/LC_MESSAGES/kreport_mapsplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/cs/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/cs/LC_MESSAGES/kreport_webplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/cy/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/da/LC_MESSAGES/kreport_barcodeplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/da/LC_MESSAGES/kreport_mapsplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/da/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/da/LC_MESSAGES/kreport_webplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/de/LC_MESSAGES/kreport_barcodeplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/de/LC_MESSAGES/kreport_mapsplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/de/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/de/LC_MESSAGES/kreport_webplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/el/LC_MESSAGES/kreport_barcodeplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/el/LC_MESSAGES/kreport_mapsplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/el/LC_MESSAGES/kreport_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/el/LC_MESSAGES/kreport_webplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/en_GB/LC_MESSAGES/kreport_barcodeplugin_qt.qm
> -- Installing: 
> /<>/debian/tmp/usr/share/locale/en_GB/LC_MESSAGES/kreport_mapsplugin_qt.qm
> -- Installing: 
> /<>/d

Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'

[Nilesh Patra]

On Wed, 21 Dec 2022 12:32:25 +0100 olivier sallou  
wrote:
> On Wed, 2022-12-21 at 11:02 +0100, olivier sallou wrote:
> > looks like a python3 issue (though was already adapter to py3...)
> > 
> > will have a look and reproduce
> 
> I could reproduce and found an issue with demo_checker.py handling with
> python3
> 
> I have a patch. will test it and upload

I wrote a patch as well, and was going to upload, but you beat me to
it, hah :/
My patch is quite similar to yours, though.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'

[olivier sallou]

I pushed a patch d/patches/fix_python3_tests whic fixes almost all test 
issues(python3 related)

BUT remains a failing test with mason2 which is not related to py3
issue (no bytes-like error)




after build, can be reproduced with

in a temp dir:

python3 /<>/apps/mason2/tests/run_tests.py
/opt/debian/build-area/seqan2-2.4.0+dfsg /<>/obj-x86_64-
linux-gnu/ 


it basically compare some generated files with some comparison files
and for mason2 they are different, and program itself raise no error
but result not as expected. Seems that many sequences output result are
shifted by 1 character




-- 


gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#1023557: rygel: consider After=network.target in rygel.service for lingering

[Jens Georg]

On Mi, Dez 21 2022 at 13:34:15 +, Barak A. Pearlmutter 
 wrote:

Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to
FF0E::C: Error sending message: Network is unreachable
Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to
FF0E::C: Error sending message: Network is unreachable
Dec 21 09:00:20 sweat rygel[853]: Error creating GUPnP context: Failed
to bind socketError binding to address
[fe80::4f84:2ae9:bb96:f67f%3]:1900: Cannot assign requested address


This is upstream ticket 
 - I believe I have 
fixed that with the release of GUPnP 1.6.3.


Sorry for resending, debian bugtracker does not love my primary mail 
address

Bug#1019521: blhc: False positive for Qt6 moc

[Eriberto]

Hi Simon,

Could you check the patch below?

Regards,

Eriberto

Em qua., 21 de dez. de 2022 às 03:51, Ross Vandegrift
 escreveu:
>
> Package: blhc
> Version: 0.13-2
> Followup-For: Bug #1019521
> X-Debbugs-Cc: rvandegr...@debian.org
>
> Hello,
>
> I also ran into this- moc is now at /usr/lib/qt6/libexec/moc.  I think the
> attached patch should address this.
>
> Thanks,
> Ross
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (40, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.0.0-4-amd64 (SMP w/16 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 blhc depends on:
> ii  libdpkg-perl  1.21.9
>
> blhc recommends no packages.
>
> blhc suggests no packages.
>
> -- no debconf information

Bug#1026813: Please drop unused python3-contextlib2 build dependency

[Jochen Sprickerhof]

Source: cloud-init
Version: 22.4.2-1
Severity: wishlist
Tags: patch

Hi cloud team,

can you please upload a new cloud-init version with the
python3-contextlib2 build dependency dropped? contextlib2 is no longer
needed since Python 3.10 and currently RC buggy and blocking the Python
3.11 transition. cloud-init is the last package that makes contextlib2 a
key package, so dropping the dependency would be great.

I've opened a merge request for your convenience:

https://salsa.debian.org/cloud-team/cloud-init/-/merge_requests/7

and would do a NMU in the coming days if no one objects.

Cheers Jochen


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

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

Bug#1026812: rust-base64: please upgrade to branch v0.20

[Jonas Smedegaard]

Source: rust-base64
Version: 0.13.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to newer upstram branch 0.20.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmOjEKwACgkQLHwxRsGg
ASHfGg/9FEbnTEGI0wm/LaQRn7Zl5XnVUXHhYtwVk/8kJ9v3HWZP5XidhN9cdrKh
Wqx3niVAAKpxTFDMvV156aCMkCCSEu7zVZtuoL5GGTdIQ0hO9c7wNgsAyfCgRwsR
O3VxwkdMblgT+E5gyxJhSdYWcUz7yb3lBpS2FwBdXak+O9fZj7pZ44qDZBX+/s4o
yQnVlyY0iOmD7xJb9dNrJCXqwBrBpP8sqFn5O96KFV0E0zRu7VlTqH2YhttgW+MU
81NWG+wm4/SemQca+mHJAD8O1mRArlYM0F9rAg9EJpnfrCK/qgBg+qFj8XP2z1dJ
vDbMhJEBwc8F9HEEeW3ATGobyA5iyxBbedTKQYxCt2lF/eMLZYNZ1vA2xk7UBSQL
6qplzR2KEXldM7uH41b9D+ql9Z3FCI+9/VZAQjd3VxpO/aupoBLZS4/E3ZtBSgtQ
PN8YO+H9Jg1Y3jeFY786VnpzYTzwuhlK3GK61Ix8pxzB23aQjwQLD0faaK8fY5/H
7GDJeFTlHDGda2rRykWtMWCTsktVe5yBTtrlIiDe0vH6c0n9cWUkxZB8M1dD9dh4
WKXVDdB396WvF796Ir30C9/5OxYK0uX8XVzMCxI9S8Uwpo03Pcxdln0nFQv/FS7W
bQcNjdXXlQnjw+lCXR+5HfH+yCLxF+1O0yXmNlxrJSsbWrs2ouo=
=psj9
-END PGP SIGNATURE-

Bug#1026810: Bring back "lit" tool

[Thomas Viehmann]

(with the bug email included)
> I think it still exists, no?


> llvm-15-tools: /usr/lib/llvm-15/build/utils/lit/lit.py

Ah, yes, I've been searching for "lit" (and so was triton).
Thank you.

Best regards

Thomas

Bug#1023557: rygel: consider After=network.target in rygel.service for lingering

[Barak A. Pearlmutter]

Okay, here's a manifestation of some network-change rygel-stops issue.
This is rygel 0.42.0-2.
Logs below.
After "systemctl --user restart rygel.service" it works fine.

$ last -1 reboot
reboot   system boot  6.0.0-6-amd64Wed Dec 21 09:00   still running

$ systemctl --user status rygel.service
○ rygel.service - Rygel DLNA/UPnP server
 Loaded: loaded (/usr/lib/systemd/user/rygel.service; enabled;
preset: enabled)
 Active: inactive (dead) since Wed 2022-12-21 09:00:46 GMT; 13min ago
   Duration: 30.065s
Process: 853 ExecStart=/usr/bin/rygel (code=exited, status=0/SUCCESS)
   Main PID: 853 (code=exited, status=0/SUCCESS)
CPU: 6.485s

Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to
FF0E::C: Error sending message: Network is unreachable
Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to
FF0E::C: Error sending message: Network is unreachable
Dec 21 09:00:20 sweat rygel[853]: Error creating GUPnP context: Failed
to bind socketError binding to address
[fe80::4f84:2ae9:bb96:f67f%3]:1900: Cannot assign requested address
Dec 21 09:00:46 sweat systemd[811]: Stopping Rygel DLNA/UPnP server...
Dec 21 09:00:46 sweat rygel[853]: Process check_async failed: Child
process killed by signal 15
Dec 21 09:00:46 sweat rygel[853]: g_file_new_for_uri: assertion 'uri
!= NULL' failed
Dec 21 09:00:46 sweat rygel[853]:
rygel_media_export_harvesting_task_on_extractor_error_cb: assertion
'file != NULL' failed
Dec 21 09:00:46 sweat mx-extract[2354]:
rygel-media-export-extract.vala:180: Started with descriptors 3 (in) 4
(out), extracting meta-data: true
Dec 21 09:00:46 sweat systemd[811]: Stopped Rygel DLNA/UPnP server.
Dec 21 09:00:46 sweat systemd[811]: rygel.service: Consumed 6.485s CPU time.

Bug#1026810: Bring back "lit" tool

[Sylvestre Ledru]

Hello

Le 21/12/2022 à 14:05, Thomas Viehmann a écrit :

Package: llvm-toolchain-15

Hi,

thank you for packaging LLVM!

Back in the day (2016), the LLVM tool LIT (LLVM Integrated Testing) 
was deemed internal and removed from the binary packages 
(interestingly, the man-page stayed).
It turns out that people/projects use lit, for example OpenAI 
Triton[1], and currently this does not work with the Debian LLVM.

Would it be possible to bring it back?


I think it still exists, no?


llvm-15-tools: /usr/lib/llvm-15/build/utils/lit/lit.py


Cheers

S

Bug#1026811: RFS: d11amp/0.59-1 [ITP] -- Simple MP3 player

[Thomas Dettbarn]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I would like to point out that there is still a BADASS-LOOKING package 
"d11amp"

waiting to be sponsored.




* Package name : d11amp
Version : 0.59-1
Upstream contact : Thomas Dettbarn 
* URL : https://www.dettus.net/d11amp/
* License : BSD-2-Clause
* Vcs : https://github.com/dettus/d11amp/
Section : sound

The source builds the following binary packages:

d11amp - Simple MP3 player

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/d11amp/d11amp_0.59-1.dsc


Changes for the initial release:

d11amp (0.59-1) unstable; urgency=low
.
* initial release.
* Closes: #1025668

Regards,

Bug#1026571: jnlp-servlet: FTBFS: src/classes/jnlp/sample/servlet/JnlpResource.java:47: error: cannot find symbol

[Hans Joachim Desserud]

Fwiw, java.util.jar.Pack200 was removed in JDK 14 and is thus missing 
when building with JDK 17.


https://openjdk.org/jeps/367

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#1026810: Bring back "lit" tool

[Thomas Viehmann]

Package: llvm-toolchain-15

Hi,

thank you for packaging LLVM!

Back in the day (2016), the LLVM tool LIT (LLVM Integrated Testing) was 
deemed internal and removed from the binary packages (interestingly, the 
man-page stayed).
It turns out that people/projects use lit, for example OpenAI Triton[1], 
and currently this does not work with the Debian LLVM.

Would it be possible to bring it back?

Best regards

Thomas


1. https://github.com/openai/triton/