Bug#1023436: unusable on mipsel: unexpected breakpoint at 0x...

[Johannes Schauer Marin Rodrigues]

Package: ltrace
Version: 0.7.3-6.3
Severity: grave

Hi,

running ltrace on mipsel, I get:

$ ltrace echo
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ee8
unexpected breakpoint at 0x77e74ee8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ee8
unexpected breakpoint at 0x77e74ee8
unexpected breakpoint at 0x77e74ee8
unexpected breakpoint at 0x77e74ee8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77e74ef8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926d8
unexpected breakpoint at 0x77d926c8
unexpected breakpoint at 0x77d926c8

+++ exited (status 0) +++

This makes the package unusable.

Thanks!

cheers, josch

Bug#1023419: transition: freeglut

[Anton Gladky]

Hi Sebastian,

rename was done to match the real shared object name to the
package name:
/usr/lib/x86_64-linux-gnu/libglut.so.3.11.0 will go to libglut3.11.

At the moment source uploads are not necessary as libglut-dev provides
freeglut3-dev. But after the transition yes, the batch of NMUs is planned.

> why is there no transitional freeglut3-dev

I thought it was enough that libglut-dev "provides" the freeglu3-dev.
If not - I will
add it.

Thanks

Regards

Anton

Am Do., 3. Nov. 2022 um 22:51 Uhr schrieb Sebastian Ramacher
:
>
> Control: tags -1 moreinfo
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-freeglut.html
>
> On 2022-11-03 20:12:03 +0100, Anton Gladky wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> >
> > New version of freeglut library and binary renaming.
> > Reverse depends were rebuilt against new lib.
> >
> >
> > Ben file:
> >
> > title = "freeglut";
> > is_affected = .depends ~ "freeglut3|freeglut3-dev" | .depends ~ 
> > "libglut-dev|libglut3.12";
> > is_good = .depends ~ "libglut-dev|libglut3.12";
> > is_bad = .depends ~ "freeglut3|freeglut3-dev";
>
> What's the deal with the renamed -dev package? Do we need sourceful
> uploads for all the reverse dependencies? What's the upgrade path for
> users?  Or in other words: why is there no transitional freeglut3-dev
> package?
>
> Cheers
> --
> Sebastian Ramacher

Bug#966573: progress packaging awscli v2

[Noah Meyerhans]

On Thu, Nov 03, 2022 at 09:35:14PM -0700, Ross Vandegrift wrote:
> > Honestly, filing some of the ITPs would be quite helpful at this point.
> > We'll need to get the following projects packaged:
> > 
> > aws-c-auth
> > aws-c-cal
> > aws-c-compression
> > aws-c-event-stream
> > aws-c-http
> 
> I got this far, and then:
> 
> > SMTP send failure: {'sub...@bugs.debian.org': (451, b'sorry, only 5 reports 
> > per hour for
> > submission')}. You can retry, or save the report and exit. Do you want to 
> > retry [Y|n|q|?]?

That's hilarious.

I guess the rust team has been uploading their random crate dependencies
without an ITP bug at all, so we're probably not going to generate too
much unhappiness if we skip them.

One nice thing about having the wnpp bugs is that we can add them as
blockers to this bug, which is helpful for tracking progress:

$ bts block 966573 with 

I uploaded aws-c-common and aws-checksums today.  All the git repos
backing my uploads are owned by the cloud-team on salsa.  I'll try to
get another couple uploads done tomorrow.

noah

Bug#966573: progress packaging awscli v2

[Ross Vandegrift]

On Wed, Nov 02, 2022 at 10:26:50PM -0700, Noah Meyerhans wrote:
> Honestly, filing some of the ITPs would be quite helpful at this point.
> We'll need to get the following projects packaged:
> 
> aws-c-auth
> aws-c-cal
> aws-c-compression
> aws-c-event-stream
> aws-c-http

I got this far, and then:

> SMTP send failure: {'sub...@bugs.debian.org': (451, b'sorry, only 5 reports 
> per hour for
> submission')}. You can retry, or save the report and exit. Do you want to 
> retry [Y|n|q|?]?

Ross

Bug#1023435: RFP: node-animate-css -- A cross-browser library of CSS animations

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist
* Package name:  node-animate-css
  Upstream Author :   Daniel Eden
* URL :
https://notabug.org/themusicgod1/animate.css
* License : MIT
  Programming Lang: javascript
  Description :  As easy to use as an easy thing.

"Just-add-water CSS animation"
animate.css is a bunch of cool, fun, and cross-browser animations for
you to use in your projects. Great for emphasis, home pages, sliders,
and general just-add-water-awesomeness.

This package has been evacuated from NSA/Microsoft github.

it is a bower dependency of ethereum-harmony ( #926370 )

Bug#1023434: ITP: aws-c-http -- C99 implementation of the HTTP/1.1 and HTTP/2 specifications

[Ross Vandegrift]

Package: wnpp
Severity: wishlist
Owner: Ross Vandegrift 
X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org

* Package name: aws-c-http
  Version : 0.6.24
  Upstream Author : Amazon Web Services
* URL : https://github.com/awslabs/aws-c-http
* License : Apache-2.0
  Programming Lang: C
  Description : C99 implementation of the HTTP/1.1 and HTTP/2 specifications

 C99 implementation of the HTTP/1.1 and HTTP/2 specifications.

This package will be maintained by the cloud team.  Packaging is initially
being driven by awscli v2 dependencies.

Bug#1023433: ITP: aws-c-event-stream -- C99 implementation of the vnd.amazon.event-stream content-type

[Ross Vandegrift]

Package: wnpp
Severity: wishlist
Owner: Ross Vandegrift 
X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org

* Package name: aws-c-event-stream
  Version : 0.2.15
  Upstream Author : Amazon Web Services
* URL : https://github.com/awslabs/aws-c-event-stream/tags
* License : Apache-2.0
  Programming Lang: C
  Description : C99 implementation of the vnd.amazon.event-stream 
content-type

 C99 implementation of the vnd.amazon.event-stream content-type.

This package will be maintained by the cloud team.  Packaging is initially
being driven by awscli v2 dependencies.

Bug#1023432: ITP: aws-c-compression -- C99 implementation of huffman encoding/decoding

[Ross Vandegrift]

Package: wnpp
Severity: wishlist
Owner: Ross Vandegrift 
X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org

* Package name: aws-c-compression
  Version : 0.2.15
  Upstream Author : Amazon Web Services
* URL : https://github.com/awslabs/aws-c-compression
* License : Apache-2.0
  Programming Lang: C
  Description : C99 implementation of huffman encoding/decoding

 This is a cross-platform C99 implementation of compression algorithms such as
 gzip, and huffman encoding/decoding. Currently only huffman is implemented.

This package will be maintained by the cloud team.  Packaging is initially
being driven by awscli v2 dependencies.

Bug#1023431: ITP: aws-c-cal -- Cross-Platform, C99 wrapper for cryptography primitives

[Ross Vandegrift]

Package: wnpp
Severity: wishlist
Owner: Ross Vandegrift 
X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org

* Package name: aws-c-cal
  Version : 0.5.20
  Upstream Author : Amazon Web Services
* URL : https://github.com/awslabs/aws-c-cal
* License : Apache-2.0
  Programming Lang: C
  Description : Cross-Platform, C99 wrapper for cryptography primitives

 AWS Crypto Abstraction Layer: Cross-Platform, C99 wrapper for
 cryptography primitives.

This package will be maintained by the cloud team.  Packaging is initially
being driven by awscli v2 dependencies.

Bug#1023430: ITP: aws-c-auth -- C99 library implementation of AWS client-side authentication

[Ross Vandegrift]

Package: wnpp
Severity: wishlist
Owner: Ross Vandegrift 
X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org

* Package name: aws-c-auth
  Version : 0.6.18
  Upstream Author : Amazon Web Services
* URL : https://github.com/awslabs/aws-c-auth
* License : Apache-2.0
  Programming Lang: C
  Description : C99 library implementation of AWS client-side authentication

 C99 library implementation of AWS client-side authentication:
 standard credentials providers and signing.

This package will be maintained by the cloud team.  Packaging is initially
being driven by awscli v2 dependencies.

Bug#1023429: Acknowledgement (pgrep/pkill: remove trailing 0x00 from matching?)

[Christoph Anton Mitterer]

Actually, I noted that things are even more weird:

The first 0x0 should likely act as a string terminator anyway... so the matched 
string shouldn't see any trailing newlines.

But even even these non-anchored patterns don't match:
$ pgrep --full --exact --euid "${LOGNAME}" --list-full -- "^ssh: 
${HOME}/\.ssh/mux/.+ \[mux]"
$ pgrep --full --exact --euid "${LOGNAME}" --list-full -- "^ssh: 
${HOME}/\.ssh/mux/.+ \["
$ pgrep --full --exact --euid "${LOGNAME}" --list-full -- "^ssh: 
${HOME}/\.ssh/mux/.+ .m"
$ pgrep --full --exact --euid "${LOGNAME}" --list-full -- "^ssh: 
${HOME}/\.ssh/mux/.+ .m."
$ pgrep --full --exact --euid "${LOGNAME}" --list-full -- "^ssh: 
${HOME}/\.ssh/mux/.+ .m.."

Interestingly though, this matches:
$ pgrep --full --exact --euid "${LOGNAME}" --list-full -- "^ssh: 
${HOME}/\.ssh/mux/.+ ."
34724 ssh: /home/calestyo/.ssh/mux/r...@lcg-lrz-admin.grid.lrz.de:22 [mux] 


And trying grep itself:
$ grep -E "^ssh: ${HOME}/\.ssh/mux/.+ \[mux]$" /proc/34724/cmdline
grep: /proc/34724/cmdline: binary file matches
$ grep -E "^ssh: ${HOME}/\.ssh/mux/.+ \[mux]" /proc/34724/cmdline
grep: /proc/34724/cmdline: binary file matches

and with text mode:
$ grep -aE "^ssh: ${HOME}/\.ssh/mux/.+ \[mux]$" /proc/34724/cmdline
$ grep -aE "^ssh: ${HOME}/\.ssh/mux/.+ \[mux]" /proc/34724/cmdline
ssh: /home/calestyo/.ssh/mux/r...@lcg-lrz-admin.grid.lrz.de:22 [mux]


Since I'm actually pretty sure that my script used to work before...
maybe the bug/change was somewhere else? Perhaps glibc?

Cheers,
Chris.

Bug#1023429: pgrep/pkill: remove trailing 0x00 from matching?

[Christoph Anton Mitterer]

Package: procps
Version: 2:3.3.17-7.1
Severity: wishlist


Hey.

I have a script that matches on any ssh channel multiplexing process
(and then kills it) after printing them.

It basically does:
pgrep --full --exact --euid "${LOGNAME}" --list-full -- "^ssh: 
${HOME}/\.ssh/mux/.+ \[mux]$"
printf '\nPress return to kill these processes.\n'
read tmp
pkill --full --exact --euid "${LOGNAME}" -- "^ssh: ${HOME}/\.ssh/mux/.+ 
\[mux]$"

Where ".ssh/mux/" is simply my configured path.

I'm was also pretty sure that this script used to work (but no longer does now),
but I've tested on some ancient Debian, and even there it fails.

The reason seems to be, that there are trailing 0x00.

E.g. I have:
$ cat /proc/34724/cmdline | hd
  73 73 68 3a 20 2f 68 6f  6d 65 2f 63 61 6c 65 73  |ssh: /home/cales|
0010  74 79 6f 2f 2e 73 73 68  2f 6d 75 78 2f 72 6f 6f  |tyo/.ssh/mux/roo|
0020  74 40 6c 63 67 2d 6c 72  7a 2d 61 64 6d 69 6e 2e  |t@lcg-lrz-admin.|
0030  67 72 69 64 2e 6c 72 7a  2e 64 65 3a 32 32 20 5b  |grid.lrz.de:22 [|
0040  6d 75 78 5d 00 00 00 00  00 00|mux]..|
004a

$ pgrep --full --exact --euid "${LOGNAME}" --list-full -- "^ssh: 
${HOME}/\.ssh/mux/.+ \[mux]$"
$

$ pgrep --full --exact --euid "${LOGNAME}" --list-full -- "^ssh: 
${HOME}/\.ssh/mux/.+ \[mux].+$"
34724 ssh: /home/calestyo/.ssh/mux/r...@lcg-lrz-admin.grid.lrz.de:22 [mux] 
$
works again, but is of course inferior, as it would posibly match undesired
processes.


In POSIX EREs it should never be possible to match 0x00.

Wouldn't it therefore make sense to e.g. strip any trailing 0x00 from cmdline
and e.g. print a warning if any non-trailing ones are encountered?
Or maybe add some commant line switches, one that allows to ignore trailing
0x00 one, that allows to ignore non-trailing ones.



Thanks,
Chris.



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

Kernel: Linux 6.0.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages procps depends on:
ii  init-system-helpers  1.64
ii  libc62.36-4
ii  libncurses6  6.3+20220423-2
ii  libncursesw6 6.3+20220423-2
ii  libprocps8   2:3.3.17-7.1
ii  libtinfo66.3+20220423-2

Versions of packages procps recommends:
ii  psmisc  23.5-3

procps suggests no packages.

-- Configuration Files:
/etc/sysctl.conf changed [not included]

-- no debconf information

Bug#1020328: Acknowledgement (Native systemd units)

[Richard Lewis]

Hi trent - i am interested in this approach:

i see you are binding msmtp over /usr/sbin/sendmail  -  i dont
understand how this would lead to a different outcome: how else does
msmtp know where to send the mail? is there some implicit assumption
about local delivery here? i tried testing but msmtp  does not work at
all out of the box for me - complains that it has no configuration
file)

As far as i can tell, the issue isn't with the "send mail" part, but
the part where the mta (exim/postfix) tries to deliver it


(returning to  logcheck - id agree with losing the 'reboot' mail -
it's pretty clear from the log message that the system has been
rebooted, so not sure what value this is even under cron. I'd suggest
adding Persistent=true in the .timer's [Timer] so that it runs after a
resuming from suspend. Perhaps set it to skip if on battery too )

Bug#1020690: fakemachine should depend on systemd-resolved

[Diederik de Haas]

On 25 Sep 2022 Christopher Obbard  wrote:
> Package: fakemachine
> Version: 0.0~git20210901.fc48786-1+b2
> Severity: important
> 
> The latest systemd packages do not include systemd-resolved; it was split
> out into a seperate package.
> 
> Because of this, on a machine which does not have systemd-resolved
> installed, fakemachine no longer works as intended.

Due to https://salsa.debian.org/raspi-team/image-specs/-/issues/64 I installed
`fakemachine`, but without systemd-resolved and I got the same build failure:
E: Failed getting release file 
http://deb.debian.org/debian/dists/bookworm/Release

I have no idea why, as it works with any other program.

I didn't install systemd-resolved as I have resolvconf installed and installing
systemd-resolved would remove resolvconf.

I don't get why it would need that exact program for network connectivity.
I found https://github.com/go-debos/fakemachine/pull/115 and ofc this bug,
where the problem seems to be directed at the packaging (i.e. not 
hard-depending on systemd-resolved), while it seems a problem with the program
itself (fakemachine).

FWIW: version is 0.0.3-3 on Debian Sid

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

Bug#1022806: [SOLVED UPSTREAM?] linux-image-5.10.0-19-amd64: amggpu unbootable problem persists

[Cosimo Agati]

I experienced this problem on a machine with the following
hardware:

CPU: AMD FX-8350 (8) @ 4.000GHz
GPU: AMD ATI Radeon R7 370 / R9 270/370 OEM

After bisecting from the 5.10.149 sources, I found that the commit
responsible for this bug was
867b2b2b6802fb3995a0065fc39e0e7e20d8004d, corresponding to
upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820.

This commit was reverted already on the 5.10 tree:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=357db159e965efa6a0b7b6f9efa1c34bf876db2d

Indeed, vanilla Linux 5.10.153, which contains this revert and
which is the currently latest release in the 5.10 branch, seems to
boot properly with the amdgpu driver.

The Debian package linux-image-5.10.0-19-amd64 is built from
sources corresponding to the upstream release 5.10.149, which did
NOT contain the fix.  This seems to explain why many people with
AMD GPUs, myself included, were experiencing problems during boot.

Since this problem seems to have been fixed upstream, I don’t
think there is anything to do on the Debian side... except of
course packaging the next linux-image package with a Linux source
tree containing these fixes.

I’m happy to provide more information about this if anyone deems
it necessary.

Best regards.

-- 
Cosimo Agati

Bug#1023428: RM: objcryst-fox [armel armhf i386 mips64el mipsel] -- ROM; cctbx unavailable on 32-bit

[Scott Talbert]

Package: ftp.debian.org
Severity: normal

Bug#822061: kalarm: KF5 version requires plasma-workspace to work properly

[David Jarvie]

This bug is no longer applicable. KAlarm no longer uses ktimezoned with Qt5 
because it now uses QTimeZone.

-- 
David Jarvie.
KDE developer, KAlarm author.

Bug#792639: apt-listbugs: should use https to access bug tracking system

[Francesco Poli]

On Wed, 02 Nov 2022 16:52:08 +0100 marc wrote:

> Hello, OpenSSL 3.0.5 is in bookworm. Are there other blockers
> to fix this issue?

Hello Marc,
thanks for your interest in apt-listbugs!

Yes, there are some blockers, but I agree that the main one (OpenSSL
licensing) is solved.

The remaining blockers (apart from the need to get around to actually
modify apt-listbugs and test the implementation: time has been scarce
for me lately...) are:

 * sorting out the licensing of some indirect dependencies of
   apt-listbugs, which seem to include GPLv2-only parts (Apache v2.0 is
   GPLv3-compatible, but GPLv2-incompatible, hence, if apt-listbugs
   links with GPLv2-only libraries, it cannot use an
   Apache-v2.0-licensed OpenSSL)

 * figuring out how the (indirect) dependency on OpenSSL v3.0 or later
   may be expressed, since apt-listbugs does not currently depend on
   OpenSSL in an explicit way

I am afraid I won't be able to work on this until after bookworm is out.
Sorry about that.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpgKbZMt0bxT.pgp
Description: PGP signature

Bug#999056: xwatch: diff for NMU version 2.11-16.1

[Marcos Talau]

Control: tags 999056 + patch
Control: tags 999056 + pending


Dear maintainer,

I've prepared an NMU for xwatch (versioned as 2.11-16.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru xwatch-2.11/debian/changelog xwatch-2.11/debian/changelog
--- xwatch-2.11/debian/changelog	2020-05-29 10:54:31.0 -0300
+++ xwatch-2.11/debian/changelog	2022-11-03 20:02:23.0 -0300
@@ -1,3 +1,10 @@
+xwatch (2.11-16.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999056).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 20:02:23 -0300
+
 xwatch (2.11-16) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru xwatch-2.11/debian/rules xwatch-2.11/debian/rules
--- xwatch-2.11/debian/rules	2020-05-29 10:35:53.0 -0300
+++ xwatch-2.11/debian/rules	2022-11-03 20:02:23.0 -0300
@@ -90,4 +90,7 @@
 	$(checkdir)
 	test root = "`whoami`"
 
-.PHONY: binary binary-arch binary-indep clean checkroot
+build-arch: build
+build-indep: build
+
+.PHONY: build-arch build-indep binary binary-arch binary-indep clean checkroot

Bug#999086: xpuzzles: diff for NMU version 7.7.1-1.2

[Marcos Talau]

Control: tags 999086 + patch
Control: tags 999086 + pending


Dear maintainer,

I've prepared an NMU for xpuzzles (versioned as 7.7.1-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru xpuzzles-7.7.1/debian/changelog xpuzzles-7.7.1/debian/changelog
--- xpuzzles-7.7.1/debian/changelog	2018-01-06 19:19:27.0 -0200
+++ xpuzzles-7.7.1/debian/changelog	2022-11-03 19:55:25.0 -0300
@@ -1,3 +1,10 @@
+xpuzzles (7.7.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999086).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 19:55:25 -0300
+
 xpuzzles (7.7.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xpuzzles-7.7.1/debian/rules xpuzzles-7.7.1/debian/rules
--- xpuzzles-7.7.1/debian/rules	2018-01-06 19:18:25.0 -0200
+++ xpuzzles-7.7.1/debian/rules	2022-11-03 19:55:25.0 -0300
@@ -132,4 +132,8 @@
 	  -uscan --force-download --repack --rename
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary

Bug#999137: sredird: diff for NMU version 2.2.1-2.1

[Marcos Talau]

Control: tags 999137 + patch
Control: tags 999137 + pending


Dear maintainer,

I've prepared an NMU for sredird (versioned as 2.2.1-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru sredird-2.2.1/debian/changelog sredird-2.2.1/debian/changelog
--- sredird-2.2.1/debian/changelog	2016-12-30 02:44:42.0 -0200
+++ sredird-2.2.1/debian/changelog	2022-11-03 19:46:01.0 -0300
@@ -1,3 +1,10 @@
+sredird (2.2.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999137).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 19:44:49 -0300
+
 sredird (2.2.1-2) unstable; urgency=medium
 
   * Merged NMU and updated to debhelper 9.
diff -Nru sredird-2.2.1/debian/rules sredird-2.2.1/debian/rules
--- sredird-2.2.1/debian/rules	2003-07-08 10:37:07.0 -0300
+++ sredird-2.2.1/debian/rules	2022-11-03 19:46:01.0 -0300
@@ -95,4 +95,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#1023123: linux-image-5.19.0-1-arm64: RPi3 fails to boot when headless

[Diederik de Haas]

On Thursday, 3 November 2022 22:18:53 CET Salvatore Bonaccorso wrote:
> >From the cover letter in the series:
> > The first patch will fix this, and the second will make sure we avoid that
> > situation entirely in the future. This has been tested with 5.19.12.
> > Earlier versions might need a backport of 88110a9f6209 ("clk: bcm2835:
> > fix bcm2835_clock_choose_div").
> 
> So I think it is safe to consider it fixed in all those versions where
> the first patch was applied.

Excellent, thanks for confirming :-)

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

Bug#999026: sjeng: diff for NMU version 11.2-8.2

[Marcos Talau]

Control: tags 999026 + patch
Control: tags 999026 + pending


Dear maintainer,

I've prepared an NMU for sjeng (versioned as 11.2-8.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u sjeng-11.2/debian/changelog sjeng-11.2/debian/changelog
--- sjeng-11.2/debian/changelog
+++ sjeng-11.2/debian/changelog
@@ -1,3 +1,10 @@
+sjeng (11.2-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999026).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 19:41:02 -0300
+
 sjeng (11.2-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u sjeng-11.2/debian/rules sjeng-11.2/debian/rules
--- sjeng-11.2/debian/rules
+++ sjeng-11.2/debian/rules
@@ -98,4 +98,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install 
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#999294: sisc: diff for NMU version 1.16.6-1.3

[Marcos Talau]

Control: tags 999294 + patch
Control: tags 999294 + pending


Dear maintainer,

I've prepared an NMU for sisc (versioned as 1.16.6-1.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru sisc-1.16.6/debian/changelog sisc-1.16.6/debian/changelog
--- sisc-1.16.6/debian/changelog	2021-01-07 10:00:35.0 -0300
+++ sisc-1.16.6/debian/changelog	2022-11-03 19:36:47.0 -0300
@@ -1,3 +1,10 @@
+sisc (1.16.6-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999294).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 19:36:47 -0300
+
 sisc (1.16.6-1.2) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru sisc-1.16.6/debian/rules sisc-1.16.6/debian/rules
--- sisc-1.16.6/debian/rules	2013-01-27 10:15:30.0 -0200
+++ sisc-1.16.6/debian/rules	2022-11-03 19:36:47.0 -0300
@@ -89,4 +89,8 @@
 # We have nothing to do by default.
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#999293: proj-ps-doc: diff for NMU version 4.3.3-5.2

[Marcos Talau]

Control: tags 999293 + patch
Control: tags 999293 + pending


Dear maintainer,

I've prepared an NMU for proj-ps-doc (versioned as 4.3.3-5.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u proj-ps-doc-4.3.3/debian/changelog proj-ps-doc-4.3.3/debian/changelog
--- proj-ps-doc-4.3.3/debian/changelog
+++ proj-ps-doc-4.3.3/debian/changelog
@@ -1,3 +1,10 @@
+proj-ps-doc (4.3.3-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999293).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 19:33:09 -0300
+
 proj-ps-doc (4.3.3-5.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u proj-ps-doc-4.3.3/debian/rules proj-ps-doc-4.3.3/debian/rules
--- proj-ps-doc-4.3.3/debian/rules
+++ proj-ps-doc-4.3.3/debian/rules
@@ -47,4 +47,8 @@
 binary-arch: binary-indep
 
 binary: binary-indep
-.PHONY: build clean binary-indep binary-arch binary
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary

Bug#999239: pct-scanner-scripts: diff for NMU version 0.0.4-3.2

[Marcos Talau]

Control: tags 999239 + patch
Control: tags 999239 + pending


Dear maintainer,

I've prepared an NMU for pct-scanner-scripts (versioned as 0.0.4-3.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u pct-scanner-scripts-0.0.4/debian/changelog pct-scanner-scripts-0.0.4/debian/changelog
--- pct-scanner-scripts-0.0.4/debian/changelog
+++ pct-scanner-scripts-0.0.4/debian/changelog
@@ -1,3 +1,10 @@
+pct-scanner-scripts (0.0.4-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999239).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 19:27:36 -0300
+
 pct-scanner-scripts (0.0.4-3.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u pct-scanner-scripts-0.0.4/debian/rules pct-scanner-scripts-0.0.4/debian/rules
--- pct-scanner-scripts-0.0.4/debian/rules
+++ pct-scanner-scripts-0.0.4/debian/rules
@@ -59,4 +59,8 @@
 # We have nothing to do by default.
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#998932: pentium-builder: diff for NMU version 0.21+nmu2

[Marcos Talau]

Control: tags 998932 + patch
Control: tags 998932 + pending


Dear maintainer,

I've prepared an NMU for pentium-builder (versioned as 0.21+nmu2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru pentium-builder-0.21+nmu1/debian/changelog pentium-builder-0.21+nmu2/debian/changelog
--- pentium-builder-0.21+nmu1/debian/changelog	2021-01-08 10:37:12.0 -0300
+++ pentium-builder-0.21+nmu2/debian/changelog	2022-11-03 19:30:32.0 -0300
@@ -1,3 +1,10 @@
+pentium-builder (0.21+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998932).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 19:30:32 -0300
+
 pentium-builder (0.21+nmu1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru pentium-builder-0.21+nmu1/debian/rules pentium-builder-0.21+nmu2/debian/rules
--- pentium-builder-0.21+nmu1/debian/rules	2016-08-17 22:49:03.0 -0300
+++ pentium-builder-0.21+nmu2/debian/rules	2022-11-03 19:30:32.0 -0300
@@ -64,4 +64,8 @@
 	@echo >&2 'source and diff are obsolete - use dpkg-source -b'; false
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

On Friday, October 28, 2022 4:09:45 AM MST Agustin Martin wrote:
> I am not particularly happy about this (see details below), but seems
> we will have to package all these .bdic files because qtwebengine and
> chromium use them. Since some .bdic may fail to build I would rather
> prefer them to be generated during package creation, where it is
> easier not to create them if required. If done during package install
> I think everything should be handled from qtwebengine package. In this
> case some fine tuning can be done to improve efficiency (handling
> symlinks better, regenerate only when a new version of dict package is
> installed or incompatibilities in qtwebengine hunspell appear, ...)

I agree with you.  I am also unhappy that Chromium and QtWebEngine want to use 
a specialized file format instead of just using the standard Hunspell files.  
However, as much as I don’t like it, I also agree with you that the best thing 
Debian can do in the short term is to move forward with the packaging of these 
.bdic files while we wait to see if we can make any changes upstream.

Given that nobody else responded to this question, I think there is a 
consensus that it is best to create the .bdic files during package creation.

The next question that needs to be answered is if we should create new binary 
packages for the .bdic files or if we should ship them as part of the existing 
Hunspell language binary packages.  The opinions that have been expressed so 
far have run the gamut on both sides, but my sense is they lean a little 
towards shipping them in the existing Hunspell packages so as to not add 80+ 
new packages to Debian that only contain a few files each.

Is there anyone who feels strongly that they should not be shipped in the 
existing files?

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

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

Bug#1023427: pixman: diff for NMU version 0.40.0-1.1

[Salvatore Bonaccorso]

Control: tags 1023427 + patch
Control: tags 1023427 + pending


Dear maintainer,

I've prepared an NMU for pixman (versioned as 0.40.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -u pixman-0.40.0/debian/changelog pixman-0.40.0/debian/changelog
--- pixman-0.40.0/debian/changelog
+++ pixman-0.40.0/debian/changelog
@@ -1,3 +1,11 @@
+pixman (0.40.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Avoid integer overflow leading to out-of-bounds write (CVE-2022-44638)
+(Closes: #1023427)
+
+ -- Salvatore Bonaccorso   Thu, 03 Nov 2022 23:07:46 +0100
+
 pixman (0.40.0-1) unstable; urgency=medium
 
   * New upstream release. (Closes: #958298, #832579, #838650)
diff -u pixman-0.40.0/debian/patches/series pixman-0.40.0/debian/patches/series
--- pixman-0.40.0/debian/patches/series
+++ pixman-0.40.0/debian/patches/series
@@ -1 +1,2 @@
 test-increase-timeout.diff
+Avoid-integer-overflow-leading-to-out-of-bounds-writ.diff
only in patch2:
unchanged:
--- pixman-0.40.0.orig/debian/patches/Avoid-integer-overflow-leading-to-out-of-bounds-writ.diff
+++ pixman-0.40.0/debian/patches/Avoid-integer-overflow-leading-to-out-of-bounds-writ.diff
@@ -0,0 +1,32 @@
+From: Matt Turner 
+Date: Wed, 2 Nov 2022 12:07:32 -0400
+Subject: Avoid integer overflow leading to out-of-bounds write
+Origin: https://gitlab.freedesktop.org/pixman/pixman/-/commit/a1f88e842e0216a5b4df1ab023caebe33c101395
+Bug: https://gitlab.freedesktop.org/pixman/pixman/-/issues/63
+Bug-Debian: https://bugs.debian.org/1023427
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-44638
+
+Thanks to Maddie Stone and Google's Project Zero for discovering this
+issue, providing a proof-of-concept, and a great analysis.
+
+Closes: https://gitlab.freedesktop.org/pixman/pixman/-/issues/63
+---
+ pixman/pixman-trap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pixman/pixman-trap.c b/pixman/pixman-trap.c
+index 91766fdbfca0..7560405ee2e4 100644
+--- a/pixman/pixman-trap.c
 b/pixman/pixman-trap.c
+@@ -74,7 +74,7 @@ pixman_sample_floor_y (pixman_fixed_t y,
+ 
+ if (f < Y_FRAC_FIRST (n))
+ {
+-	if (pixman_fixed_to_int (i) == 0x8000)
++	if (pixman_fixed_to_int (i) == 0x8000)
+ 	{
+ 	f = 0; /* saturate */
+ 	}
+-- 
+2.37.2
+

Bug#998968: openoffice.org-thesaurus-pl: diff for NMU version 1.5-4.2

[Marcos Talau]

Control: tags 998968 + patch
Control: tags 998968 + pending


Dear maintainer,

I've prepared an NMU for openoffice.org-thesaurus-pl (versioned as 1.5-4.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u openoffice.org-thesaurus-pl-1.5/debian/changelog openoffice.org-thesaurus-pl-1.5/debian/changelog
--- openoffice.org-thesaurus-pl-1.5/debian/changelog
+++ openoffice.org-thesaurus-pl-1.5/debian/changelog
@@ -1,3 +1,10 @@
+openoffice.org-thesaurus-pl (1.5-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998968).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 19:08:36 -0300
+
 openoffice.org-thesaurus-pl (1.5-4.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u openoffice.org-thesaurus-pl-1.5/debian/rules openoffice.org-thesaurus-pl-1.5/debian/rules
--- openoffice.org-thesaurus-pl-1.5/debian/rules
+++ openoffice.org-thesaurus-pl-1.5/debian/rules
@@ -47,4 +47,8 @@
 binary-arch: build install
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#999193: openoffice.org-hyphenation-pl: diff for NMU version 1:3.0a-4.2

[Marcos Talau]

Control: tags 999193 + patch
Control: tags 999193 + pending


Dear maintainer,

I've prepared an NMU for openoffice.org-hyphenation-pl (versioned as 
1:3.0a-4.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u openoffice.org-hyphenation-pl-3.0a/debian/changelog openoffice.org-hyphenation-pl-3.0a/debian/changelog
--- openoffice.org-hyphenation-pl-3.0a/debian/changelog
+++ openoffice.org-hyphenation-pl-3.0a/debian/changelog
@@ -1,3 +1,10 @@
+openoffice.org-hyphenation-pl (1:3.0a-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999193).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 19:05:58 -0300
+
 openoffice.org-hyphenation-pl (1:3.0a-4.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u openoffice.org-hyphenation-pl-3.0a/debian/rules openoffice.org-hyphenation-pl-3.0a/debian/rules
--- openoffice.org-hyphenation-pl-3.0a/debian/rules
+++ openoffice.org-hyphenation-pl-3.0a/debian/rules
@@ -40,4 +40,8 @@
 binary-arch: build install
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#998969: ninvaders: diff for NMU version 0.1.1-4.1

[Marcos Talau]

Control: tags 998969 + patch
Control: tags 998969 + pending


Dear maintainer,

I've prepared an NMU for ninvaders (versioned as 0.1.1-4.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u ninvaders-0.1.1/debian/changelog ninvaders-0.1.1/debian/changelog
--- ninvaders-0.1.1/debian/changelog
+++ ninvaders-0.1.1/debian/changelog
@@ -1,3 +1,10 @@
+ninvaders (0.1.1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998969).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 19:02:56 -0300
+
 ninvaders (0.1.1-4) unstable; urgency=low
 
   * Fix build problems for gcc-10.  Closes: #957609.
diff -u ninvaders-0.1.1/debian/rules ninvaders-0.1.1/debian/rules
--- ninvaders-0.1.1/debian/rules
+++ ninvaders-0.1.1/debian/rules
@@ -68,4 +68,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#999062: netmaze: diff for NMU version 0.81+jpg0.82-16.1

[Marcos Talau]

Control: tags 999062 + patch
Control: tags 999062 + pending


Dear maintainer,

I've prepared an NMU for netmaze (versioned as 0.81+jpg0.82-16.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u netmaze-0.81+jpg0.82/debian/changelog netmaze-0.81+jpg0.82/debian/changelog
--- netmaze-0.81+jpg0.82/debian/changelog
+++ netmaze-0.81+jpg0.82/debian/changelog
@@ -1,3 +1,10 @@
+netmaze (0.81+jpg0.82-16.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999062).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 18:57:40 -0300
+
 netmaze (0.81+jpg0.82-16) unstable; urgency=medium
 
   [ John Goerzen ]
diff -u netmaze-0.81+jpg0.82/debian/rules netmaze-0.81+jpg0.82/debian/rules
--- netmaze-0.81+jpg0.82/debian/rules
+++ netmaze-0.81+jpg0.82/debian/rules
@@ -76,4 +76,7 @@
 		*.o *~ Makefile *.bak
 	-rm nmlogo.gif
 
-.PHONY: clean binary binary-indep binary-arch
+build-arch: build
+build-indep: build
+
+.PHONY: build-arch build-indep binary binary-indep binary-arch clean

Bug#999285: net-telnet-cisco: diff for NMU version 1.10-5.4

[Marcos Talau]

Control: tags 999285 + patch
Control: tags 999285 + pending


Dear maintainer,

I've prepared an NMU for net-telnet-cisco (versioned as 1.10-5.4) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u net-telnet-cisco-1.10/debian/changelog net-telnet-cisco-1.10/debian/changelog
--- net-telnet-cisco-1.10/debian/changelog
+++ net-telnet-cisco-1.10/debian/changelog
@@ -1,3 +1,10 @@
+net-telnet-cisco (1.10-5.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999285).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 18:54:46 -0300
+
 net-telnet-cisco (1.10-5.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u net-telnet-cisco-1.10/debian/rules net-telnet-cisco-1.10/debian/rules
--- net-telnet-cisco-1.10/debian/rules
+++ net-telnet-cisco-1.10/debian/rules
@@ -84,4 +84,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#999123: minisapserver: diff for NMU version 0.3.6-1.2

[Marcos Talau]

Control: tags 999123 + patch
Control: tags 999123 + pending


Dear maintainer,

I've prepared an NMU for minisapserver (versioned as 0.3.6-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u minisapserver-0.3.6/debian/changelog minisapserver-0.3.6/debian/changelog
--- minisapserver-0.3.6/debian/changelog
+++ minisapserver-0.3.6/debian/changelog
@@ -1,3 +1,10 @@
+minisapserver (0.3.6-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999123).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 18:51:48 -0300
+
 minisapserver (0.3.6-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u minisapserver-0.3.6/debian/rules minisapserver-0.3.6/debian/rules
--- minisapserver-0.3.6/debian/rules
+++ minisapserver-0.3.6/debian/rules
@@ -104,4 +104,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install 
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#1023419: transition: freeglut

[Sebastian Ramacher]

Control: tags -1 moreinfo
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-freeglut.html

On 2022-11-03 20:12:03 +0100, Anton Gladky wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> 
> New version of freeglut library and binary renaming.
> Reverse depends were rebuilt against new lib.
> 
> 
> Ben file:
> 
> title = "freeglut";
> is_affected = .depends ~ "freeglut3|freeglut3-dev" | .depends ~ 
> "libglut-dev|libglut3.12";
> is_good = .depends ~ "libglut-dev|libglut3.12";
> is_bad = .depends ~ "freeglut3|freeglut3-dev";

What's the deal with the renamed -dev package? Do we need sourceful
uploads for all the reverse dependencies? What's the upgrade path for
users?  Or in other words: why is there no transitional freeglut3-dev
package?

Cheers
-- 
Sebastian Ramacher

Bug#999244: midish: diff for NMU version 1.0.4-1.2

[Marcos Talau]

Control: tags 999244 + patch
Control: tags 999244 + pending


Dear maintainer,

I've prepared an NMU for midish (versioned as 1.0.4-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru midish-1.0.4/debian/changelog midish-1.0.4/debian/changelog
--- midish-1.0.4/debian/changelog	2012-01-31 00:21:12.0 -0200
+++ midish-1.0.4/debian/changelog	2022-11-03 18:49:04.0 -0300
@@ -1,3 +1,10 @@
+midish (1.0.4-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999244).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 18:49:04 -0300
+
 midish (1.0.4-1.1) unstable; urgency=low
 
   * Non-maintainer upload, fixes FTBFS. (Closes: #604947, #652177)
diff -Nru midish-1.0.4/debian/rules midish-1.0.4/debian/rules
--- midish-1.0.4/debian/rules	2010-10-31 08:25:39.0 -0200
+++ midish-1.0.4/debian/rules	2022-11-03 18:49:04.0 -0300
@@ -51,4 +51,7 @@
 
 binary: binary-arch binary-indep
 
-.PHONY: build clean binary-indep binary-arch binary install configure
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#999328: mbw: diff for NMU version 1.2.2-1.1

[Marcos Talau]

Control: tags 999328 + patch
Control: tags 999328 + pending


Dear maintainer,

I've prepared an NMU for mbw (versioned as 1.2.2-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u mbw-1.2.2/debian/rules mbw-1.2.2/debian/rules
--- mbw-1.2.2/debian/rules
+++ mbw-1.2.2/debian/rules
@@ -87,4 +87,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure
diff -u mbw-1.2.2/debian/changelog mbw-1.2.2/debian/changelog
--- mbw-1.2.2/debian/changelog
+++ mbw-1.2.2/debian/changelog
@@ -1,3 +1,10 @@
+mbw (1.2.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999328).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 18:45:56 -0300
+
 mbw (1.2.2-1) unstable; urgency=low
 
   * New release correcting a bug.

Bug#1023352: transition: draco

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-11-02 19:49:09 +0100, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> I'd like to transition draco after the new release had a SONAME bump.
> All reverse-dependencies build successfully on amd64.
> 
> The auto-generated Ben tracker is good:
> https://release.debian.org/transitions/html/auto-draco.html

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#998950: mailsync: diff for NMU version 5.2.7-3.1

[Marcos Talau]

Control: tags 998950 + patch
Control: tags 998950 + pending


Dear maintainer,

I've prepared an NMU for mailsync (versioned as 5.2.7-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru mailsync-5.2.7/debian/changelog mailsync-5.2.7/debian/changelog
--- mailsync-5.2.7/debian/changelog	2020-11-15 15:55:25.0 -0300
+++ mailsync-5.2.7/debian/changelog	2022-11-03 18:42:44.0 -0300
@@ -1,3 +1,10 @@
+mailsync (5.2.7-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998950).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 18:39:28 -0300
+
 mailsync (5.2.7-3) unstable; urgency=low
 
   * Update aclocal.m4 during build. Hopefully this should make
diff -Nru mailsync-5.2.7/debian/rules mailsync-5.2.7/debian/rules
--- mailsync-5.2.7/debian/rules	2020-11-15 15:52:51.0 -0300
+++ mailsync-5.2.7/debian/rules	2022-11-03 18:42:44.0 -0300
@@ -83,4 +83,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#1023427: pixman: CVE-2022-44638

[Salvatore Bonaccorso]

Source: pixman
Version: 0.40.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://gitlab.freedesktop.org/pixman/pixman/-/issues/63
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for pixman.

CVE-2022-44638[0]:
| In libpixman in Pixman before 0.42.2, there is an out-of-bounds write
| (aka heap-based buffer overflow) in rasterize_edges_8 due to an
| integer overflow in pixman_sample_floor_y.


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-44638
https://www.cve.org/CVERecord?id=CVE-2022-44638
[1] https://gitlab.freedesktop.org/pixman/pixman/-/issues/63
[2] 
https://gitlab.freedesktop.org/pixman/pixman/-/commit/a1f88e842e0216a5b4df1ab023caebe33c101395

Regards,
Salvatore

Bug#1023426: gnucash: Crash importing a QFX/OFX file

[Kevin McCarthy]

Package: gnucash
Version: 1:4.12-1
Severity: important
Tags: patch

Dear Maintainer,

Starting with 4.12-1, gnucash is crashing when trying to import a
QFX/OFX file (for example from my bank).

This has been reported and fixed upstream at:
https://bugs.gnucash.org/show_bug.cgi?id=798629

And a patch has been commited to their maint branch at:
https://github.com/Gnucash/gnucash/commit/14fe4d862f9cd797fb947bc20403b9cf4bb9eece

This is having a severe usability impact (at least for me), so I was 
opening this ticket to ask (or to beg ;-)) if you would consider adding 
the above commit as a patch until 4.13 releases?

Thank you!

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

Kernel: Linux 6.0.0-2-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 gnucash depends on:
ii  gnucash-common 1:4.12-1
ii  guile-3.0  3.0.8-2
ii  guile-3.0-libs 3.0.8-2
ii  libaqbanking44 6.5.3-1
ii  libboost-filesystem1.74.0  1.74.0-17
ii  libboost-locale1.74.0  1.74.0-17
ii  libboost-program-options1.74.0 1.74.0-17
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu71]  1.74.0-17
ii  libc6  2.35-4
ii  libcairo2  1.16.0-6
ii  libcrypt-ssleay-perl   0.73.06-2+b1
ii  libdate-manip-perl 6.89-1
ii  libdbi10.9.0-6
ii  libfinance-quote-perl  1.53-1
ii  libgcc-s1  12.2.0-3
ii  libgdk-pixbuf-2.0-02.42.9+dfsg-1
ii  libglib2.0-0   2.74.1-1
ii  libgtk-3-0 3.24.34-3
ii  libgwengui-gtk3-79 5.10.1-1
ii  libgwenhywfar795.10.1-1
ii  libhtml-tableextract-perl  2.15-2
ii  libhtml-tree-perl  5.07-2
ii  libicu71   71.1-3
ii  libofx71:0.10.5-1
ii  libpango-1.0-0 1.50.10+ds-1
ii  libpangocairo-1.0-01.50.10+ds-1
ii  libpython3.10  3.10.8-1
ii  libsecret-1-0  0.20.5-3
ii  libstdc++6 12.2.0-3
ii  libwebkit2gtk-4.0-37   2.38.0-3
ii  libwww-perl6.67-1
ii  libxml22.9.14+dfsg-1+b1
ii  perl   5.36.0-4
ii  zlib1g 1:1.2.11.dfsg-4.1

Versions of packages gnucash recommends:
pn  gnucash-docs 
ii  python3-gnucash  1:4.12-1
pn  yelp 

Versions of packages gnucash suggests:
pn  libdbd-mysql
pn  libdbd-pgsql
pn  libdbd-sqlite3  

-- no debconf information

Bug#999230: madwimax: diff for NMU version 0.1.1-1.1

[Marcos Talau]

Control: tags 999230 + patch
Control: tags 999230 + pending


Dear maintainer,

I've prepared an NMU for madwimax (versioned as 0.1.1-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u madwimax-0.1.1/debian/rules madwimax-0.1.1/debian/rules
--- madwimax-0.1.1/debian/rules
+++ madwimax-0.1.1/debian/rules
@@ -86,4 +86,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install 
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install
diff -u madwimax-0.1.1/debian/changelog madwimax-0.1.1/debian/changelog
--- madwimax-0.1.1/debian/changelog
+++ madwimax-0.1.1/debian/changelog
@@ -1,3 +1,10 @@
+madwimax (0.1.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999230).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 18:32:01 -0300
+
 madwimax (0.1.1-1) unstable; urgency=low
 
   * Initial release (Closes: #533173).

Bug#1021125: soci: ABI break in soci::session causes crashes in Linphone

[Dennis Filder]

Control: severity -1 important

I'm downgrading this for now since the relinked reverse-dependencies
have migrated to testing making this less urgent.  But this still
needs addressing for bookworm so no one upgrading from bullseye will
think they can do a partial upgrade.

Regards.

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Andrea Corallo]

Eli Zaretskii  writes:

>> Date: Thu, 3 Nov 2022 11:13:08 +0100
>> From: Vincent Lefevre 
>> Cc: spwhit...@spwhitton.name, 58...@debbugs.gnu.org,
>>  1017...@bugs.debian.org
>> 
>> On 2022-11-03 08:47:06 +0200, Eli Zaretskii wrote:
>> > > On 2022-11-02 14:24:51 +0200, Eli Zaretskii wrote:
>> > > > Signal 1 is SIGHUP, AFAIU.  Why should Emacs receive SIGHUP in the
>> > > > middle of GC, I have no idea.  Maybe ask the user what was he doing at
>> > > > that time.  E.g., could that be a remote Emacs session?
>> > > 
>> > > No, it is on my local machine.
>> > 
>> > So how come Emacs gets a SIGHUP?  This is the crucial detail that is
>> > missing here.  Basically, if SIGHUP is delivered to Emacs, Emacs is
>> > supposed to die a violent death.
>> 
>> I suspect the SIGHUP comes from Emacs itself. According to strace
>> output, the only processes started by Emacs are "/usr/bin/emacs"
>> (there are many of them). I don't see what other process could be
>> aware of the situation. Unfortunately, I couldn't reproduce the
>> issue with strace (I suspect some race condition).
>> 
>> > > I run emacs, and quit it immediately. The generation of the core dump
>> > > is almost 100% reproducible. Ditto with "emacs -nw".
>> > 
>> > Wait, you mean the crash is during exiting Emacs?
>> 
>> For this test, yes. In general, I don't know.
>> 
>> > That could mean Emacs receives some input event when it's half-way
>> > through the shutdown process, and the input descriptor is already
>> > closed.
>> 
>> Note that the process that crashes is not the Emacs I started,
>> but a subprocess run by Emacs itself, since it has arguments like
>> "-no-comp-spawn --batch -l /tmp/emacs-async-comp-url.el-FGov4z.el".
>
> Andrea, could you please look into this?  The SIGHUP could be because
> the parent process exits, but that shouldn't cause a crash in the
> sub-process that performs native compilation?

Hi Eli,

AFAIU the Emacs subprocess we use to compile should behave like a
regular Emacs.

Now, the only option that comes to my mind is that libgccjit (being
strictly derived from the GCC codebase) might be registering a signal
handler of some kind that alters the behaviour we expect.  But if this
is the case we should find trace of it the strace, or we can use gdb
setting a break point into 'signal' as well to check.

Indeed if this theory is true I think should be classified as a
libgccjit bug.

  Andrea

Bug#1023425: gnome-shell: crash on startup after upgrade from 42.4

[Kjö Hansi Glaz]

Subject: gnome-shell: crash on startup after upgrade from 42.4
Package: gnome-shell
Version: 43.0-2
Severity: important

Dear Maintainer,

   * What led up to the situation?

Upgrade my sid system from gnome-shell 42.4-2 to 43.0-2

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

Restart the system.

   * What was the outcome of this action?

The system boots up to gdm service startup, then the display blinks. It 
is not possible to access a tty to login in a shell.


I had to start in recovery mode and to downgrade gnome-shell and mutter 
by hand to version 42.4-2


   * What outcome did you expect instead?

The graphical session to start up, or in case of failure, being able to 
access a shell.



My system is MacBookPro9,2 with i915 graphics.

Please find below "coredumpctl info" output.

Please let me know if you need more information

Thanks for maintaing gnome-shell.


lspci -vv -s 00:02.0


00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core 
processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])

Subsystem: Apple Inc. 3rd Gen Core processor Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 48, IOMMU group 2
Memory at a000 (64-bit, non-prefetchable) [size=4M]
Memory at 9000 (64-bit, prefetchable) [size=256M]
I/O ports at 2000 [size=64]
Expansion ROM at 000c [virtual] [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915


coredumpctl info


PID: 2371 (gnome-shell)
UID: 1000 (kjo)
GID: 1000 (kjo)
Signal: 11 (SEGV)
Timestamp: Thu 2022-11-03 21:09:10 CET (45min ago)
Command Line: /usr/bin/gnome-shell
Executable: /usr/bin/gnome-shell
Control Group: 
/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service

Unit: user@1000.service
User Unit: org.gnome.Shell@wayland.service
Slice: user-1000.slice
Owner UID: 1000 (kjo)
Boot ID: 9752a2d6fde049f5b76c872b3827824d
Machine ID: b9adf7e9bf9f26d80afe8bdb52d7f9a8
Hostname: ziggy
Storage: 
/var/lib/systemd/coredump/core.gnome-shell.1000.9752a2d6fde049f5b76c872b3827824d.2371.166750615000.zst 
(present)

Disk Size: 12.0M
Message: Process 2371 (gnome-shell) of user 1000 dumped core.

Module linux-vdso.so.1 with build-id 
e14a78332591687c6ecc5aaab7d80c97f73059c7
Module libgiognomeproxy.so with build-id 
0eb1e3b029ee38a2fd88831bdc072db7e6b0fa24
Module libgioremote-volume-monitor.so with build-id 
5924f54f8ceb9aed48745b79550c4c0e68d9fae2
Module libtelepathy-logger.so.3 with build-id 
9c5ee58594405138f1c5907cf075afe223f9e93b
Module libdbus-glib-1.so.2 with build-id 
90430c691f4ef85d90b05889fe88a181f2fdc767
Module libtelepathy-glib.so.0 with build-id 
f86f22bc6f26f556280365ef5b9fcab7a1b002db
Module libmp3lame.so.0 with build-id 
5608dbb8e56f055feb7a55ce4e83ffc66fc7

Module libmpg123.so.0 with build-id b109ea5988217206e2f3037d18a153d2345e3532
Module libopus.so.0 with build-id c660cf724fd7835d53a33b5f2d494471104cb556
Module libvorbisenc.so.2 with build-id 
15116f34e1cc88f88c13d4e6ce5aab9a05c2ad55

Module libFLAC.so.8 with build-id d002f9c229612cbb6ac63c0e833401a3b63bb1fa
Module libasyncns.so.0 with build-id 
2f138035552f4b777ccafb65b22b5da8983ea7ac
Module libsndfile.so.1 with build-id 
abfba3b21e81f0b27d5c90ab17a053dc7d45f8f8
Module libpulsecommon-16.1.so with build-id 
0f7e302d4bc34228488b6b4fce8c1b986e422f03
Module libpulse-mainloop-glib.so.0 with build-id 
dc346fd641bc6c776c8ab2b2ae30227b6c12d1d5

Module libpulse.so.0 with build-id 1ace166a6383f89cba02f7829ef3245bfc15f532
Module libgvc.so with build-id b42a251e93669ff08d865bc0e7cd340396305f77
Module libcrypt.so.1 with build-id 2442239fad26c8122cf7dd8e54af2b15c7a17fa6
Module libaccountsservice.so.0 with build-id 
39cf83accf4e52a9de65a52077e30f8bc0afe618
Module libgeocode-glib-2.so.0 with build-id 
d5fab0a8e95aecc0b1e1d6b42e3928e0b45c3303
Module libgweather-4.so.0 with build-id 
2bd9a031123ff85b51526f28c9dffd9dc5741aee

Module librsvg-2.so.2 with build-id db07b8609508e07840554ca6563f953996daa8e9
Module libpixbufloader-svg.so with build-id 
ea2347470e47e8305d6f383ab5ec3beb6a02c786

Module libgdm.so.1 with build-id 4f65c3e33bbd076fb2a246bcb40e920c9f90765c
Module libgeoclue-2.so.0 with build-id 
97b46636b6eb153ea751280fce8614533c90df10
Module libmalcontent-0.so.0 with build-id 
efb0cc8c610e11042dd1765462df3c34d7dd97f3
Module libibus-1.0.so.5 with build-id 
577a1aad70179d19924e940a6f4e8be6a0c7691e
Module libnghttp2.so.14 with build-id 
da1f9cf6839a6882e78d2551e3bb321a5e7e83fd

Module libpsl.so.5 with build-id ea212f1398c6f4a35aef2b84e2ba67792550e0a8
Module libsqlite3.so.0 with build-id 
8a18485a5acac1fc54a1ed3bb699b9e70b67f964
Module libsoup-3.0.so.0 with build-id 
abf3e3b10f1e0a26f23ce37e95cd85ec9b67efb3

Module 

Bug#1023123: linux-image-5.19.0-1-arm64: RPi3 fails to boot when headless

[Salvatore Bonaccorso]

Hi Diederik!

On Thu, Nov 03, 2022 at 12:37:19PM +0100, Diederik de Haas wrote:
> Control: found -1 6.0.5-1
> Control: fixed -1 6.0.6-2
> Control: fixed -1 6.1~rc3-1~exp1
> Control: severity -1 grave
> Control: tag -1 -moreinfo
> Control: tag -1 upstream fixed-upstream
> Control: retitle -1 RPi 0-3 fail to boot on kernel 5.19+ without HDMI 
> connected
> Control: forwarded -1 
> https://lore.kernel.org/all/20220929-rpi-pi3-unplugged-fixes-v1-0-cd22e9622...@cerno.tech/
> 
> On Monday, 31 October 2022 00:37:54 CET Diederik de Haas wrote:
> > Control: found -1 5.19.6-1
> > Control: severity -1 important
> > Control: tag -1 moreinfo
> > 
> > On 30 Oct 2022 13:24:55 +0100 Jan Huijsmans  
> > wrote:
> > > Package: linux-image-5.19.0-1-arm64
> > > Severity: critical
> > > Justification: breaks the whole system
> > 
> > Only affecting RPi3 in certain conditions, thus lowering severity.
> 
> I was able to reproduce this on a RPi 1, found that is was reported upstream 
> here:
> https://lore.kernel.org/dri-devel/20220922145448.w3xfywkn5ecak...@pengutronix.de/
> 
> and found the patches that were applied upstream in 6.1-rc2 where there were
> 2 commits and saw that 1 commit was backported to the linux-6.0 branch, but
> that seemed sufficient as installing kernel 6.0.6-2 from unstable, fixed the
> issue.

>From the cover letter in the series:

> The first patch will fix this, and the second will make sure we avoid that
> situation entirely in the future. This has been tested with 5.19.12. Earlier
> versions might need a backport of 88110a9f6209 ("clk: bcm2835: fix
> bcm2835_clock_choose_div").

So I think it is safe to consider it fixed in all those versions where
the first patch was applied.

Regards,
Salvatore

Bug#1023178: microprofile: Contains non-free source

[Andrea Pappacoda]

Control: tag -1 + pending

I've just fixed the mentioned issues and uploaded the package to 
mentors.

Bug#1023424: Re; Bug#1023424: Vulnerabilities CVE-2022-1292, CVE-2022-2068, CVE-2022-2097

[Adam D. Barratt]

Control: severity -1 important
Control: tags -1 - bullseye

On Thu, 2022-11-03 at 20:35 +, nospam099-git...@yahoo.com wrote:
> The component OpenSSL1.1.1n-0+deb11u3 suffers from 3 vulnerabilities:
> * (CVE-2022-1292)[https://nvd.nist.gov/vuln/detail/CVE-2022-1292]
> (critical)
> * (CVE-2022-2068)[https://nvd.nist.gov/vuln/detail/CVE-2022-2068]
> (critical)

No. Both of the above are already resolved in 1.1.1n-0+deb11u3, as
indicated by https://security-tracker.debian.org/tracker/CVE-2022-1292
and https://security-tracker.debian.org/tracker/CVE-2022-2068 (indeed,
the former was fixed in 1.1.1n-0+deb11u2).

> * (CVE-2022-2097)[https://nvd.nist.gov/vuln/detail/CVE-2022-2097]
> (medium)
> 

and https://security-tracker.debian.org/tracker/CVE-2022-2097 has this
tagged as waiting for additional updates to fix it alongside.

Regards,

Adam

Bug#1023317: Bug#1023318: / Bug#1023317: {screen,zsh}: re-adds /usr/bin/{screen,zsh} to /etc/shells on upgrade

[Axel Beckert]

Hi Helmut,

Helmut Grohne wrote:
> On Thu, Nov 03, 2022 at 12:26:18AM +0100, Axel Beckert wrote:
> > Some more hints about how this all is meant to work and why it
> > actually works would have been appreciated, though:
> 
> Thank you for the quick reply and thank you for bringing up the lack of
> documentation.

You're welcome. And thanks for not being annoyed of my reply. :-)

> > Helmut Grohne wrote:
> > It took me quite a while to where this
> > /usr/share/debianutils/shells.d/ comes from and where it is this
> > documented,
> 
> I'm sorry for using your time in such a bad way. Consider asking for
> feedback earlier next time.

Well, you know, I first try to figure out things myself before asking
others too quickly. And I usually dig further if I have the feeling,
I'm very close to the answer. In the end you got my way through the
problem as I tend to protocol what I've done.

> > /usr/share/doc/debianutils/README.shells.gz clearly states that I
> > should use add-shell and remove-shell:
> 
> In all my work, I happen to not have run into this, but I really should.
> Thank you for pointing it out. Failing to update it is an obvious
> omission in retrospect and this is the place that should have told you
> all that you wanted to know.

Indeed.

> I have thus filed #1023380 to fix that.

Thanks a lot! Looks good to me and clearly improves the situation a lot.

> Please let me know if you miss anything else.

Maybe the man pages add-shell(8) and remove-shell(8) should mention
update-shells(8) under "SEE ALSO" or mention that there's also a
trigger-based invocation of them (with pointers then). That would have
helped me as well. (Cc'ing #1023380 for these suggestions.)

P.S.: Will work on the two issues you've reported soon-ish. Thanks
again for making us aware of them.

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#1023424: Vulnerabilities CVE-2022-1292, CVE-2022-2068, CVE-2022-2097

[Ondřej Surý]

Control: close -1Please read the Debian change logs and use security tracker rather than blindly using upstream version number for assessing the status of security vulnerabilities in stable Debian release:. The information you are looking for can be found there:Information on source package opensslsecurity-tracker.debian.orgCheers,Ondrej--Ondřej Surý  (He/Him)On 3. 11. 2022, at 20:39, nospam099-git...@yahoo.com wrote:Package: OpenSSLVersion: 1.1.1n-0+deb11u3Severity: criticalTags: bullseye security fixed-upstreamDescription:The component OpenSSL1.1.1n-0+deb11u3 suffers from 3 vulnerabilities:* (CVE-2022-1292)[https://nvd.nist.gov/vuln/detail/CVE-2022-1292] (critical)* (CVE-2022-2068)[https://nvd.nist.gov/vuln/detail/CVE-2022-2068] (critical)* (CVE-2022-2097)[https://nvd.nist.gov/vuln/detail/CVE-2022-2097] (medium)Fix:Updating the package to version (OpenSSL1.1.1s)[https://github.com/openssl/openssl/releases/tag/OpenSSL_1_1_1s] would resolve them.-- System Information:Debian Release: 11.5  APT prefers stable-updates  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')Architecture: amd64 (x86_64)

Bug#1023424: Vulnerabilities CVE-2022-1292, CVE-2022-2068, CVE-2022-2097

[nospam099-git...@yahoo.com]

Package: OpenSSL
Version: 1.1.1n-0+deb11u3
Severity: critical
Tags: bullseye security fixed-upstream

Description:
The component OpenSSL1.1.1n-0+deb11u3 suffers from 3 vulnerabilities:
* (CVE-2022-1292)[https://nvd.nist.gov/vuln/detail/CVE-2022-1292] (critical)
* (CVE-2022-2068)[https://nvd.nist.gov/vuln/detail/CVE-2022-2068] (critical)
* (CVE-2022-2097)[https://nvd.nist.gov/vuln/detail/CVE-2022-2097] (medium)

Fix:
Updating the package to version 
(OpenSSL1.1.1s)[https://github.com/openssl/openssl/releases/tag/OpenSSL_1_1_1s] 
would resolve them.

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

Bug#1023423: bullseye-pu: package pysubnettree/0.33-1

[Scott Kitterman]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: 1005...@bugs.debian.org


[ Reason ]
Package is totally broken in Bullseye (see #1005044) and this fixes it.

[ Impact ]
Package remains unusable

[ Tests ]
None in this version.  For unstable, I wrote an autopkgtest to detect if
this issue happens again, but did not include it here to keep thing
compact.  I did manually replicate the problem on the current bullseye
version of the package and then repeat the process with the update to
verify the problem is corrected.

[ Risks ]
None.  Package can't get more useless than it is currently.  Fix is
pretty trivial anyway.  The problem was that (me being an idiot) managed
to get one file used in the build process from upstream (swig 3) and one
from the Debian build (swig 4) and that did not go well.

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

[ Changes ]
This is a swig package.  To make sure that the package can be built from
source, it has long moved SubnetTree_wrap.cc aside to force a rebuild.
Unfortunately, I then put it back meanging that the pacakge got built
with the upstream SubnetTree_wrap.cc and the SubnetTree.py from the
rebuild.  This was all fine until we switched to Swig 4 and they were no
longer compatible.

The update moves them both aside (and puts them back in clean so we
leave the package like we found it) and doesn't put SubnetTree_wrap.cc
back during the build so that both rebuilt files are used in the build.
Also, fixed a minor error in clean, for completeness.

[ Other info ]
The identical fix is in Unstable in 0.36.1.
diff -Nru pysubnettree-0.33/debian/changelog pysubnettree-0.33/debian/changelog
--- pysubnettree-0.33/debian/changelog  2020-02-15 15:59:24.0 -0500
+++ pysubnettree-0.33/debian/changelog  2022-11-03 16:09:00.0 -0400
@@ -1,3 +1,11 @@
+pysubnettree (0.33-1+deb11u1) bullseye; urgency=medium
+
+  * Fix moving/copying files in debian/rules so as not to leave a mix of
+rebuilt and non-rebuilt files in the binary and update clean rule
+(Closes: #1005044)
+
+ -- Scott Kitterman   Thu, 03 Nov 2022 16:09:00 -0400
+
 pysubnettree (0.33-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru pysubnettree-0.33/debian/rules pysubnettree-0.33/debian/rules
--- pysubnettree-0.33/debian/rules  2020-02-15 12:28:51.0 -0500
+++ pysubnettree-0.33/debian/rules  2022-11-03 16:07:10.0 -0400
@@ -7,9 +7,9 @@
dh $@ --with python3
 
 override_dh_auto_build:
-   mv $(CURDIR)/SubnetTree_wrap.cc $(CURDIR)/not.SubnetTree_wrap.cc
+   mv -n $(CURDIR)/SubnetTree_wrap.cc $(CURDIR)/not.SubnetTree_wrap.cc
+   mv -n $(CURDIR)/SubnetTree.py $(CURDIR)/not.SubnetTree.py
dh_auto_build
-   mv $(CURDIR)/not.SubnetTree_wrap.cc $(CURDIR)/SubnetTree_wrap.cc
 
 override_dh_auto_install:
dh_install -ppython3-subnettree
@@ -20,8 +20,9 @@
 override_dh_clean:
dh_clean
-cp -f $(CURDIR)/not.SubnetTree_wrap.cc $(CURDIR)/SubnetTree_wrap.cc
-   rm -f $(CURDIR)/not.SubnetTree_wrap.cc
-   rm -rf $(CURDIR)/build
+   -cp -f $(CURDIR)/not.SubnetTree.py $(CURDIR)/SubnetTree.py
+   rm -f $(CURDIR)/not.SubnetTree*
+   rm -rf $(CURDIR)/__pycache__
 
 override_dh_auto_test:
:

Bug#1023399: Bug#1023401: src:python-biopython: unsatisfied build dependency in testing: python3-rdflib

[Paul Gevers]

Hi,

On 03-11-2022 18:03, Andreas Tille wrote:

its all about the fact that rdflib is broken and removed from testing.
We are nagging upstream constantly[1] with no success so far.  This
issue creates noise about testing removals in about 100 packages and
is extremely annoying.

&&
On 03-11-2022 17:58, Jonas Smedegaard wrote:
> no comment at bug#1012482 which includes a
> suggestion (which I agree with) to lower the severity of that bug to
> simply not be release-critical: Yes, naïve implementations of the RDF
> protocol can be tricked into pulling data from the filesystem, because
> URIs are not necessarily all http-based and failing to care for that
> may lead to surprises - which would be neat if generic RDF processing
> tools were to ensure protection against but in my opinion unreasonable
> to *require*: As I understand it, the equivalent would be to kick out
> libcurl from Debian because it doesn't offer the heavy and complex
> sandboxing mechanisms implemented in (only the biggest) web browsers.

I haven't spent time yet to make up *my* mind about the severity of the 
problem, but if people have serious doubts about the severity, the 
Release Team is the appropriate body in Debian to make that call. So if 
you believe the bug severity is too high, by all means bring it to the RT.


On 03-11-2022 18:03, Andreas Tille wrote:

I assume if you want to file bugs about missing python3-rdflib manually
its quite a waste of time for you since the problem is known and more
bug reports will not make things more visible.


Well, there were only 4 packages due to python3-rdflib; the total amount 
of packages flagged by dose (in testing) [1] is rather limited and I 
also have automated it by now. *Build* dependencies are unfortunately 
not automatically ensured in testing, so it needs a tiny bit of 
baby-sitting. That's why I filed these bugs today.


Paul

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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023038: Acknowledgement (oath-toolkit: FTBFS with xmlsec1 1.2.35)

[Rene Engelhard]

Control: tag -1 + patch

Hi,

> So basically the reference file needs to be updated but then it probably
> breaks with 1.2.34...

diff -Nru oath-toolkit-2.6.7/debian/control 
oath-toolkit-2.6.7/debian/control

--- oath-toolkit-2.6.7/debian/control    2021-08-20 11:04:06.0 +0200
+++ oath-toolkit-2.6.7/debian/control    2022-11-03 20:27:54.0 +0100
@@ -9,7 +9,7 @@
    gengetopt,
    libpam0g-dev,
    libxml2-utils,
-   libxmlsec1-dev
+   libxmlsec1-dev (>= 1.2.35)
 Standards-Version: 4.6.0
 Homepage: https://www.nongnu.org/oath-toolkit/
 Vcs-Browser: https://salsa.debian.org/debian/oath-toolkit
diff -Nru 
oath-toolkit-2.6.7/debian/patches/fix-tests-with-xmlsec1-1.2.35.diff 
oath-toolkit-2.6.7/debian/patches/fix-tests-with-xmlsec1-1.2.35.diff
--- oath-toolkit-2.6.7/debian/patches/fix-tests-with-xmlsec1-1.2.35.diff 
1970-01-01 01:00:00.0 +0100
+++ oath-toolkit-2.6.7/debian/patches/fix-tests-with-xmlsec1-1.2.35.diff 
2022-11-03 20:40:10.0 +0100

@@ -0,0 +1,45 @@
+Description: fix tests with xmlsec1 1.2.35
+ Seems the output changed subtly, just adapt
+Author: Rene Engelhard 
+
+---
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/1023038
+Forwarded: 
https://lists.nongnu.org/archive/html/oath-toolkit-help/2022-10/msg0.html

+Last-Update: 2022-11-03
+
+--- oath-toolkit-2.6.7.orig/libpskc/configure.ac
 oath-toolkit-2.6.7/libpskc/configure.ac
+@@ -52,7 +52,7 @@ AC_ARG_WITH(xmlsec-crypto-engine,
+ AC_MSG_NOTICE([xmlsec crypto engine: $xmlsecengine])
+
+ PKG_CHECK_MODULES(XML2, libxml-2.0,, [AC_MSG_ERROR([Cannot find 
libxml2])])

+-PKG_CHECK_MODULES(XMLSEC, xmlsec1$xmlsecengine, [xmlsec=yes], [xmlsec=no])
++PKG_CHECK_MODULES(XMLSEC, xmlsec1$xmlsecengine >= 1.2.35, 
[xmlsec=yes], [xmlsec=no])

+ AC_PATH_PROG(XMLCATALOG, xmlcatalog)
+ if test -z "$ac_cv_path_XMLCATALOG"; then
+   xmlsec=no
+--- oath-toolkit-2.6.7.orig/libpskc/examples/pskc-hotp-signed.xml
 oath-toolkit-2.6.7/libpskc/examples/pskc-hotp-signed.xml
+@@ -38,7 +38,8 @@ rIXbwqKhnBP943U4Ch31oEbZtbo+XRbiq11wv6dL
+ rMxnil6ChoIBvSSPGHhJuj1bW1EPW92JtIa6byrAj1m4RwSviQy2i65YoIdtrhRt
+ CWekj2zuL/0szv5rZMCCvxioOCA8znqELEPMfs0Aa/cACD2MZcC4gGXehNCvzYJr
+ TmB6lFpxP6f0g6eO7PVcqYN9NCwECxb5Cvx2j2uNlereY35/9oPR6YJx+V7sL+DB
+-n6F0mN8OUAFxDamepKdGRApU8uZ35624o/I4
++n6F0mN8OUAFxDamepKdGRApU8uZ35624o/I4
++
+ 
+ 
+ 
+--- oath-toolkit-2.6.7.orig/pskctool/tests/pskc-all-signed.xml
 oath-toolkit-2.6.7/pskctool/tests/pskc-all-signed.xml
+@@ -38,7 +38,8 @@ rIXbwqKhnBP943U4Ch31oEbZtbo+XRbiq11wv6dL
+ rMxnil6ChoIBvSSPGHhJuj1bW1EPW92JtIa6byrAj1m4RwSviQy2i65YoIdtrhRt
+ CWekj2zuL/0szv5rZMCCvxioOCA8znqELEPMfs0Aa/cACD2MZcC4gGXehNCvzYJr
+ TmB6lFpxP6f0g6eO7PVcqYN9NCwECxb5Cvx2j2uNlereY35/9oPR6YJx+V7sL+DB
+-n6F0mN8OUAFxDamepKdGRApU8uZ35624o/I4
++n6F0mN8OUAFxDamepKdGRApU8uZ35624o/I4
++
+ 
+ 
+ 
diff -Nru oath-toolkit-2.6.7/debian/patches/series 
oath-toolkit-2.6.7/debian/patches/series
--- oath-toolkit-2.6.7/debian/patches/series    1970-01-01 
01:00:00.0 +0100
+++ oath-toolkit-2.6.7/debian/patches/series    2022-11-03 
20:39:54.0 +0100

@@ -0,0 +1 @@
+fix-tests-with-xmlsec1-1.2.35.diff

is doing exactly this.

If you apply this I can upload xmlsec1 1.2.36 to unstable immediately. 
(python-xmlsec as the other one has -  unless oath-tookit) no 
reverse-depends at all so can be AUTORMed if needed).


Regards,


Rene

Bug#1022945: smbclient: ambiguous duplications in the smbclient(1) manpage

[Andrew Bartlett]

Can we move this discussion to an upstream bug, and even better propose
a patch per https://wiki.samba.org/index.php/Contribute on GitLab for
Samba master?
There is nothing debian-specific here and it is all going to have to be
solved upstream anyway.  
Hard work has been started to have our manpages and even more
importantly code use common elements so that we have consistent
behaviour and consistent documentation, the rough edges just need a
clean up and this would be an awesome contributed patch, as it just
takes time.
Andrew Bartlett
On Thu, 2022-11-03 at 20:04 +0100, Patrice Duroux wrote:
> Thanks Michael!
> I have also dig a bit into the samba source.There are similar
> duplicates in the smbcacls(1) manpage.
> $ rgrep -n "max-protocol" *docs-
> xml/build/DTD/samba.entities:559: cmdline.common.connection.max-protocol 'docs-
> xml/build/DTD/samba.entities:561: -m|--max-
> protocol=MAXPROTOCOLdocs-
> xml/build/DTD/samba.entities:580:
> protocol;docs-xml/manpages/rpcclient.1.xml:37: choice="opt">-m|--max-protocol=MAXPROTOCOLdocs-
> xml/manpages/smbcquotas.1.xml:41: -m|
> --max-protocol=MAXPROTOCOLdocs-xml/manpages/winexe.1.xml:37:
>   -m|--max-protocol=MAXPROTOCOLdocs-
> xml/manpages/smbcacls.1.xml:51:   -m|
> --max-protocol=MAXPROTOCOLdocs-xml/manpages/smbcacls.1.xml:182: 
>   -m|--max-protocol PROTOCOL_NAMEdocs-
> xml/manpages/smbcacls.1.xml:190:  a max-protocol of SMB3
> is required.docs-xml/manpages/mdsearch.1.xml:37:   choice="opt">-m|--max-protocol=MAXPROTOCOLdocs-
> xml/manpages/nmblookup.1.xml:43:  -m|
> --max-protocol=MAXPROTOCOLdocs-xml/manpages/smbclient.1.xml:46: 
>   -m|--max-protocol=MAXPROTOCOLdocs-
> xml/manpages/smbclient.1.xml:193: -m|--max-protocol 
> protocoldocs-xml/manpages/smbclient.1.xml:201: a max-
> protocol of SMB3 is required.docs-xml/manpages/samba-
> regedit.8.xml:33: -m|--max-
> protocol=MAXPROTOCOLdocs-xml/manpages/net.8.xml:35: 
> -m|--max-
> protocol=MAXPROTOCOLlib/cmdline/cmdline.c:705:  .longNa
> me   = "max-protocol",source3/selftest/tests.py:508:for options in
> ["", "--option=clientntlmv2auth=no", "--option=clientusespnego=no",
> "--option=clientusespnego=no --option=clientntlmv2auth=no", "
> --option=clientntlmv2auth=no --option=clientlanmanauth=yes --max-
> protocol=LANMAN2", "--option=clientntlmv2auth=no --
> option=clientlanmanauth=yes --
> option=clientmaxprotocol=NT1"]:source3/utils/smbcquotas.c:627:
>   .longName   = "max-
> protocol",source3/utils/net_help_common.c:67: d_printf(_("\t-m|--max-
> protocol=MAXPROTOCOL\t\tSet max protocol level\n"));
> I think that samba.dtd contents some common shared entries and
> bothsmbclient.1.xml and smbcacls.1.xml should not have their
> own
> I did not try to check by removing them.
> More annoying is small discrepancy regarding the '-U|--user' option.
> $ rgrep -n "\-U|--user" *docs-xml/build/DTD/samba.entities:591:   
> -U|--user=[DOMAIN\]USERNAME[PASSWORD]docs-
> xml/manpages/rpcclient.1.xml:42:  -U|
> --user=[DOMAIN/]USERNAME[%PASSWORD]docs-
> xml/manpages/smbcquotas.1.xml:46: -U|
> --user=[DOMAIN/]USERNAME[%PASSWORD]docs-
> xml/manpages/winexe.1.xml:42: -U|
> --user=[DOMAIN/]USERNAME%[PASSWORD]docs-
> xml/manpages/smbcacls.1.xml:56:   -U|
> --user=[DOMAIN/]USERNAME[%PASSWORD]docs-
> xml/manpages/mdsearch.1.xml:42:  -U|
> --user=[DOMAIN/]USERNAME[%PASSWORD]docs-
> xml/manpages/smbclient.1.xml:51:  -U|
> --user=[DOMAIN/]USERNAME%[PASSWORD]docs-xml/manpages/samba-
> regedit.8.xml:38: -U|
> --user=[DOMAIN/]USERNAME[%PASSWORD]docs-
> xml/manpages/smbtree.1.xml:34:-U|
> --user=[DOMAIN/]USERNAME[%PASSWORD]docs-
> xml/manpages/net.8.xml:40:-U|
> --user=[DOMAIN/]USERNAME[%PASSWORD]docs-
> xml/manpages/pdbedit.8.xml:33:-U|
> --user SID=STRINGsource3/utils/net_help_common.c:75:d_print
> f(_("\t-U|--user=[DOMAIN/]USERNAME[%%PASSWORD]\tSet the "
> The separator to the DOMAIN value (ie. [DOMAIN\] or [DOMAIN/]) and
> the positionof the pourcent % should be inside the brackets (ie.
> [%PASSWORD] and not%[PASSWORD]).
> Finally, I found more to say about the documentation versus the
> output of helpoption on the different samba commands.Let see with
> what upstream have to say.
> To conclude, be free to close this wish.
> Regards,Patrice
> On Wed, 2 Nov 2022 19:53:02 +0300 Michael Tokarev 
> wrote:
> > 28.10.2022 10:28, Patrice DUROUX wrote:
> > > Package: smbclientVersion: 2:4.16.6+dfsg-5Severity: wishlist
> > > Dear Maintainer,
> > > The smbclient(1) manpage contains some multiple entries in the
> > > OPTIONSsection regarding the SYNOPSIS list.
> > > Here are the two detected cases:
> > > 71:   -m|--max-protocol protocol72-   This allows the
> > > user to select the highest SMB protocol level
> that smbclient will use to connect to the 

Bug#1023422: FTBFS: test failure

[gregor herrmann]

Source: minilla
Version: 3.1.11-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


As also seen on ci.debian.net, minilla recently started to fail its
test suite, which also makes it FTBFS:

#   Failed test 'No tests run for subtest "FileGatherer"'
#   at t/filegatherer.t line 46.
Minilla::Error::CommandExit at /build/minilla-3.1.19/blib/lib/Minilla/Logger.pm 
line 56.
Minilla::Logger::errorf("Giving up.\x{a}") called at 
/build/minilla-3.1.19/blib/lib/Minilla/Util.pm line 150
Minilla::Util::cmd("git", "submodule", "add", "file:///tmp/cNMz9BGy3K", 
"libfoo") called at /build/minilla-3.1.19/blib/lib/Minilla/Git.pm line 43
Minilla::Git::git_submodule_add("file:///tmp/cNMz9BGy3K", "libfoo") 
called at t/filegatherer.t line 70
main::init() called at t/filegatherer.t line 17
main::__ANON__() called at /usr/share/perl/5.36/Test/Builder.pm line 374
eval {...} called at /usr/share/perl/5.36/Test/Builder.pm line 374
Test::Builder::subtest(Test::Builder=HASH(0x55b66779e4c0), 
"FileGatherer", CODE(0x55b667d4a8a0)) called at 
/usr/share/perl/5.36/Test/More.pm line 809
Test::More::subtest("FileGatherer", CODE(0x55b667d4a8a0)) called at 
t/filegatherer.t line 46
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 2.
t/filegatherer.t .
ok 1 - Minilla::FileGatherer->can('new')
# Subtest: FileGatherer
[cNMz9BGy3K] $ git init
Initialized empty Git repository in /tmp/cNMz9BGy3K/.git/
[cNMz9BGy3K] $ git add .
[cNMz9BGy3K] $ git commit -m submodule
[main (root-commit) 928d506] submodule
 1 file changed, 1 insertion(+)
 create mode 100644 foo.c
[1X4gcCt02H] $ git init
Initialized empty Git repository in /tmp/1X4gcCt02H/.git/
[1X4gcCt02H] $ git add .
[1X4gcCt02H] $ git commit -m submodule
[main (root-commit) fcf8e7d] submodule
 1 file changed, 1 insertion(+)
 create mode 100644 bar.c
[75BXf3LiVD] $ git init
Initialized empty Git repository in /tmp/75BXf3LiVD/.git/
[75BXf3LiVD] $ git add .
[75BXf3LiVD] $ git submodule add file:///tmp/cNMz9BGy3K libfoo
1..0
not ok 2 - No tests run for subtest "FileGatherer"
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/2 subtests
Cloning into '/tmp/t_vUmqA512/libbar'...
fatal: transport 'file' not allowed
fatal: clone of 'file:///tmp/VnuWv09juk' into submodule path 
'/tmp/t_vUmqA512/libbar' failed
Giving up.
# No tests run!

#   Failed test 'No tests run for subtest "FileGatherer"'
#   at t/filegatherer/submodules-recursive.t line 46.
Minilla::Error::CommandExit at /build/minilla-3.1.19/blib/lib/Minilla/Logger.pm 
line 56.
Minilla::Logger::errorf("Giving up.\x{a}") called at 
/build/minilla-3.1.19/blib/lib/Minilla/Util.pm line 150
Minilla::Util::cmd("git", "submodule", "add", "file:///tmp/VnuWv09juk", 
"libbar") called at /build/minilla-3.1.19/blib/lib/Minilla/Git.pm line 43
Minilla::Git::git_submodule_add("file:///tmp/VnuWv09juk", "libbar") 
called at t/filegatherer/submodules-recursive.t line 86
main::create_deep_submodule_repo("foo") called at 
t/filegatherer/submodules-recursive.t line 52
main::init() called at t/filegatherer/submodules-recursive.t line 17
main::__ANON__() called at /usr/share/perl/5.36/Test/Builder.pm line 374
eval {...} called at /usr/share/perl/5.36/Test/Builder.pm line 374
Test::Builder::subtest(Test::Builder=HASH(0x55c165f41840), 
"FileGatherer", CODE(0x55c166599dd0)) called at 
/usr/share/perl/5.36/Test/More.pm line 809
Test::More::subtest("FileGatherer", CODE(0x55c166599dd0)) called at 
t/filegatherer/submodules-recursive.t line 46
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 2.
t/filegatherer/submodules-recursive.t 
ok 1 - Minilla::FileGatherer->can('new')
# Subtest: FileGatherer
[t_vUmqA512] $ git init
Initialized empty Git repository in /tmp/t_vUmqA512/.git/
[t_vUmqA512] $ git add .
[t_vUmqA512] $ git commit -m submodule
[main (root-commit) 4dc9adf] submodule
 1 file changed, 1 insertion(+)
 create mode 100644 foo.c
[eq_ln5HmOW] $ git init
Initialized empty Git repository in /tmp/eq_ln5HmOW/.git/
[eq_ln5HmOW] $ git add .
[eq_ln5HmOW] $ git commit -m submodule
[main (root-commit) 4dc9adf] submodule
 1 file changed, 1 insertion(+)
 create mode 100644 foo.c
[VnuWv09juk] $ git init
Initialized empty Git repository in /tmp/VnuWv09juk/.git/
[VnuWv09juk] $ git add .
[VnuWv09juk] $ git commit -m submodule
[main (root-commit) 9290497] submodule
 1 file changed, 1 insertion(+)
 create mode 100644 bar.c
[t_vUmqA512] $ git add .
[t_vUmqA512] $ git submodule add file:///tmp/VnuWv09juk libbar
1..0
not ok 2 - No tests run for subtest "FileGatherer"
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/2 subtests


#   Failed test 'No tests run for subtest 

Bug#1020641: dhcpcd5: dhcpcd > 7.1.0 don't work well with dhcpcd-gtk

[Martintxo]

Hello...

After several failed test guided by Martin-Éric Racine and driven outside of
this bug report, her ask me to put my working config and changes in the bug
report. So this is how I have wireless conectivity in my ancient laptop, an
Emachines 355 with a CPU Intel Atom at 1,66 Ghz and 1 Gb of RAM

I am running Debian Testing, and have installed the following packages related
to dhcpcd:
- dhcpcd-base 9.4.1-9
- dhcpcd-dbus 0.6.1-3
- dhcpcd-gtk 0.7.8-1
- dhcpcd5 9.4.1-9

For make dhcpcd-gtk work with Debian, I copied the config of the Raspberry Pi
Desktop for PC and Mac that I see in action in my laptop with this live-cd:
https://www.raspberrypi.com/software/raspberry-pi-desktop/

I see, later, that this config is compatible with the dhcpcd-gtk manual page. I
will put excerpts of that man page on this text, bellow. I think that my config
is compilant with these excerpts, but I not totally sure.

1. In /etc/network/interfaces there is not to be anything. The manual page says
that: "dhcpcd(8) needs to be running in Master mode for dhcpcd-gtk to work with
it", so it need to be started in the boot process by systemd or init.d, and no
by /etc/network/interfaces.

2. The manual page says that: "dhcpcd-gtk relies on wpa_supplicant(8) being
configured to write its sockets to /var/run/wpa_supplicant. If dhcpcd-gtk is
used to select and set pass phrases for wireless networks then update_config=1
needs to be set in wpa_supplicant.conf." So I put this in
/etc/wpa_supplicant/wpa_supplicant.conf:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

3. I check that wpa_supplicant need to be started by dhcpcd. For this I make
this symbolic link: 
$ sudo ln -s /usr/share/dhcpcd/hooks/10-wpa_supplicant
/usr/lib/dhcpcd/dhcpcd-hooks

4. The man page says that: "If dhcpcd-gtk is used to make configuration changes
then the user needs to be able to write to the privileged dhcpcd control socket
as well as /etc/dhcpcd.conf." For that, I change the permissions of
/etc/dhcpcd.conf to these: rw-rw-r-- root:netdev. I put my normal user in the
netdev group too. So, I run these commands:
$ sudo chown root:netdev /etc/dhcpcd.conf
$ sudo chmod 664 /etc/dhcpcd.conf
$ sudo adduser "myuser" netdev

5. As said in my prior email in this bug report, prior to dhcpcd 9.4.1 with
these changes, my setup was working well. But in 9.4.1 dhcpcd is starting at
boot by systemd (prior was by an init script), and this have a "sandboxing"
part that is preventing it from working. So now I need to remove all these lines
from the systemd unit. For this I made:
- Copy that unit to /etc/systemd/system:
   $ sudo cp /lib/systemd/system/dhcpcd.service /etc/systemd/system
- Edit /etc/systemd/system/dhcpcd.service and coment/remove all this lines:
#
# sandboxing
#
ProtectSystem=strict
ReadWritePaths=/var/lib/dhcpcd /run/dhcpcd /etc/resolv.conf
ProtectHome=true
PrivateTmp=true
PrivateDevices=true
ProtectClock=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
RestrictNamespaces=true
LockPersonality=true
MemoryDenyWriteExecute=true
RestrictRealtime=true
RestrictSUIDSGID=true
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native

Whit this, dhcpcd is starting well in the laptop boot, and later, I start
dhcpcd-gtk with my desktop environment and is working well. I can select a
wireless net, type it's passphrase and the system conects to it...

That's all for this to work. I made another change, by this is not needed for
all users, I think. I put this line in /etc/dhcpcd.conf for dhcpcd to not to
change my /etc/resolv.conf file:
nohook resolv.conf
But there are some other modes to achieve this, as well, I think...

Well. So this is the way I work. I understand that it is a very particular way,
and that it does not have to be useful for everyone. But I think it's the only
way to get dhcpcd-gtk to work well in a Debian desktop environment.

Many thanks for all your work. Greetings. Martintxo.

Bug#1023041: FTBFS: uninstalled files; dh_missing errors out

[Rene Engelhard]

Control: severity -1 serious

Am 03.11.22 um 19:36 schrieb Håvard F. Aasen:

As already stated in the provided IRC log, it's CMake that finds a systemd 
module,
and therefore install some extra files. I'll probably include a patch from 
upstream
and add an additional config option to CMake in d/rules.


Or just rm -f them before dh_missing if you don't want them ;-)

Regards,

Rene

Bug#1023421: FTBFS: test failure in t/12_response/10_error_dumper_without_clone.t

[gregor herrmann]

Source: libdancer-perl
Version: 1.3202+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libdancer-perl doesn't build anymore, one test fails (also seen on
ci.debian.net and cpantesters):

Devel::Hide hides Clone.pm
Can't locate Clone.pm in @INC (hidden)
BEGIN failed--compilation aborted at /usr/share/perl5/HTTP/Headers.pm line 8.
Compilation failed in require at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/Response.pm line 14.
BEGIN failed--compilation aborted at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/Response.pm line 14.
Compilation failed in require at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/SharedData.pm line 8.
BEGIN failed--compilation aborted at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/SharedData.pm line 8.
Compilation failed in require at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/Request.pm line 13.
BEGIN failed--compilation aborted at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/Request.pm line 13.
Compilation failed in require at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/Route.pm line 13.
BEGIN failed--compilation aborted at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/Route.pm line 13.
Compilation failed in require at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/Route/Registry.pm line 8.
BEGIN failed--compilation aborted at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/Route/Registry.pm line 8.
Compilation failed in require at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/App.pm line 12.
BEGIN failed--compilation aborted at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer/App.pm line 12.
Compilation failed in require at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer.pm line 10.
BEGIN failed--compilation aborted at 
/build/libdancer-perl-1.3513+dfsg/blib/lib/Dancer.pm line 10.
Compilation failed in require at t/12_response/10_error_dumper_without_clone.t 
line 17.
BEGIN failed--compilation aborted at 
t/12_response/10_error_dumper_without_clone.t line 17.
t/12_response/10_error_dumper_without_clone.t ...
Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run


I _think_ the issue is that t/12_response/10_error_dumper_without_clone.t
hides Clone (via Devel::Hide), and libhttp-message-perl, since
6.44-1, requires Clone at runtime …


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmNkFhZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZ8cQ//XhISykm6JQWlHvaXe2Wm4e9IQvlqDCYmnWF51RId3R0rkdQ1rck31uSv
KnH332ehOCWwx7rIvyq6DOH7f8fnkwppOvtM6glcEFo+f/Tn9kWRJpcWD2AMqdPY
cobaxFPsLmb4DUcEQl0G+VeVdnHojg5gDtfzemwv+fyWIjv7Gj/uRnL5Lz2lO3kY
+ZtbPzYvdSxsKPeWk/nC773T7MZmkzVc0Pc4ZyqhZ8HUiOaafamyVUXV4NsVSa7i
30fgYm8xb6wCzJwBpj9YRUib17Mbl5OU+6EQpF6mRoEQuDFuWoWni1EZ8zbXd68X
rXk3lSnKX8uuOeRbgHiTFE9S/pM/p60bWDiO72E04JNwkbHJ+HNgRqmDFzQlXW0R
lBctZkW0so4S6UrNeHXK5FPFTw7E7iCz/nEvEpQqQinYDNIm6/Q44OGa1hJ4lnv0
JVHUaJFUpql5PmRueaVNkTmYNYsmz3vLNWEg+DCid16AWfVod9aXJBuBeMwdzViV
K0rtgXGoWnmlETNvPCaSoxYQMDW581rp4/ko6ILE8ObCLovZV1fBZ0GNrU/b8lG/
z30d5ExTMfhNk5ZkJ/vxPb8WmkM2hoOiKjvQyUAS6htVshV49HXuXQRNhAwiegT8
RzEOMFDlSBdUiLpTRqoQAg8DtKr6ZJSht5+wgQR68Hf6CgCKZYI=
=X687
-END PGP SIGNATURE-

Bug#999142: liblip: diff for NMU version 2.0.0-1.3

[Marcos Talau]

Control: tags 999142 + patch
Control: tags 999142 + pending


Dear maintainer,

I've prepared an NMU for liblip (versioned as 2.0.0-1.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u liblip-2.0.0/debian/changelog liblip-2.0.0/debian/changelog
--- liblip-2.0.0/debian/changelog
+++ liblip-2.0.0/debian/changelog
@@ -1,3 +1,10 @@
+liblip (2.0.0-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999142).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 16:18:09 -0300
+
 liblip (2.0.0-1.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u liblip-2.0.0/debian/rules liblip-2.0.0/debian/rules
--- liblip-2.0.0/debian/rules
+++ liblip-2.0.0/debian/rules
@@ -89,4 +89,7 @@
 	$(checkdir)
 	test root = "`whoami`"
 
-.PHONY: binary binary-arch binary-indep clean checkroot
+build-arch: build
+build-indep: build
+
+.PHONY: binary binary-arch binary-indep build-arch build-indep clean checkroot

Bug#998986: libjpeg9: diff for NMU version 1:9d-1.1

[Marcos Talau]

Control: tags 998986 + patch
Control: tags 998986 + pending


Dear maintainer,

I've prepared an NMU for libjpeg9 (versioned as 1:9d-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru libjpeg9-9d/debian/changelog libjpeg9-9d/debian/changelog
--- libjpeg9-9d/debian/changelog	2020-02-02 17:47:45.0 -0300
+++ libjpeg9-9d/debian/changelog	2022-11-03 16:14:38.0 -0300
@@ -1,3 +1,10 @@
+libjpeg9 (1:9d-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998986).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 16:14:38 -0300
+
 libjpeg9 (1:9d-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru libjpeg9-9d/debian/rules libjpeg9-9d/debian/rules
--- libjpeg9-9d/debian/rules	2018-09-13 14:25:39.0 -0300
+++ libjpeg9-9d/debian/rules	2022-11-03 16:14:38.0 -0300
@@ -80,4 +80,7 @@
 
 binary:	binary-indep binary-arch
 
-.PHONY: clean binary-indep binary-arch binary build
+build-arch: build
+build-indep: build
+
+.PHONY: clean binary-indep binary-arch binary build build-arch build-indep

Bug#999306: libjpeg6b: diff for NMU version 1:6b2-3.1

[Marcos Talau]

Control: tags 999306 + patch
Control: tags 999306 + pending


Dear maintainer,

I've prepared an NMU for libjpeg6b (versioned as 1:6b2-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru libjpeg6b-6b2/debian/changelog libjpeg6b-6b2/debian/changelog
--- libjpeg6b-6b2/debian/changelog	2017-08-11 19:06:40.0 -0300
+++ libjpeg6b-6b2/debian/changelog	2022-11-03 16:10:54.0 -0300
@@ -1,3 +1,10 @@
+libjpeg6b (1:6b2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999306).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 16:10:54 -0300
+
 libjpeg6b (1:6b2-3) unstable; urgency=medium
 
   * debian/control:
diff -Nru libjpeg6b-6b2/debian/rules libjpeg6b-6b2/debian/rules
--- libjpeg6b-6b2/debian/rules	2017-08-06 06:22:52.0 -0300
+++ libjpeg6b-6b2/debian/rules	2022-11-03 16:10:54.0 -0300
@@ -87,4 +87,7 @@
 
 binary:	binary-indep binary-arch
 
-.PHONY: clean binary-indep binary-arch binary build
+build-arch: build
+build-indep: build
+
+.PHONY: clean binary-indep binary-arch binary build build-arch build-indep

Bug#1023420: libvirt FTBFS: missing Build-Depends: mount

[Helmut Grohne]

Source: libvirt
Version: 8.5.0-1
Severity: serious
Tags: ftbfs

libvirt fails to build from source in unstable on a minimal chroot.
mount is no longer essential nor build-essential, so you must add it to
Build-Depends explicitly.

Helmut

Bug#1023419: transition: freeglut

[Anton Gladky]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition


New version of freeglut library and binary renaming.
Reverse depends were rebuilt against new lib.


Ben file:

title = "freeglut";
is_affected = .depends ~ "freeglut3|freeglut3-dev" | .depends ~ 
"libglut-dev|libglut3.12";
is_good = .depends ~ "libglut-dev|libglut3.12";
is_bad = .depends ~ "freeglut3|freeglut3-dev";


Thanks

Anton

Bug#998991: libapache-mod-removeip: diff for NMU version 1.0b-5.4

[Marcos Talau]

Control: tags 998991 + patch
Control: tags 998991 + pending


Dear maintainer,

I've prepared an NMU for libapache-mod-removeip (versioned as 1.0b-5.4) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru libapache-mod-removeip-1.0b/debian/changelog libapache-mod-removeip-1.0b/debian/changelog
--- libapache-mod-removeip-1.0b/debian/changelog	2019-08-18 17:49:03.0 -0300
+++ libapache-mod-removeip-1.0b/debian/changelog	2022-11-03 16:07:18.0 -0300
@@ -1,3 +1,10 @@
+libapache-mod-removeip (1.0b-5.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998991).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 16:07:18 -0300
+
 libapache-mod-removeip (1.0b-5.3) unstable; urgency=medium
 
   * Drop dpatch, move to source format 3.0 (quilt)
diff -Nru libapache-mod-removeip-1.0b/debian/rules libapache-mod-removeip-1.0b/debian/rules
--- libapache-mod-removeip-1.0b/debian/rules	2019-08-18 17:48:33.0 -0300
+++ libapache-mod-removeip-1.0b/debian/rules	2022-11-03 16:07:18.0 -0300
@@ -43,4 +43,8 @@
 binary-indep: build install
 
 binary: binary-arch binary-indep
-.PHONY: build clean binary-indep binary-arch binary install configure
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#1022945: smbclient: ambiguous duplications in the smbclient(1) manpage

[Patrice Duroux]

Thanks Michael!

I have also dig a bit into the samba source.
There are similar duplicates in the smbcacls(1) manpage.

$ rgrep -n "max-protocol" *
docs-xml/build/DTD/samba.entities:559:-m|--max-protocol=MAXPROTOCOL
docs-xml/build/DTD/samba.entities:580:
docs-xml/manpages/rpcclient.1.xml:37:   -m|--max-protocol=MAXPROTOCOL
docs-xml/manpages/smbcquotas.1.xml:41:  -m|--max-protocol=MAXPROTOCOL
docs-xml/manpages/winexe.1.xml:37:  -m|--max-protocol=MAXPROTOCOL
docs-xml/manpages/smbcacls.1.xml:51:-m|--max-protocol=MAXPROTOCOL
docs-xml/manpages/smbcacls.1.xml:182:   -m|--max-protocol 
PROTOCOL_NAME
docs-xml/manpages/smbcacls.1.xml:190:   a max-protocol of SMB3 is 
required.
docs-xml/manpages/mdsearch.1.xml:37:  -m|--max-protocol=MAXPROTOCOL
docs-xml/manpages/nmblookup.1.xml:43:   -m|--max-protocol=MAXPROTOCOL
docs-xml/manpages/smbclient.1.xml:46:   -m|--max-protocol=MAXPROTOCOL
docs-xml/manpages/smbclient.1.xml:193:  -m|--max-protocol 
protocol
docs-xml/manpages/smbclient.1.xml:201:  a max-protocol of SMB3 is 
required.
docs-xml/manpages/samba-regedit.8.xml:33:   -m|--max-protocol=MAXPROTOCOL
docs-xml/manpages/net.8.xml:35: -m|--max-protocol=MAXPROTOCOL
lib/cmdline/cmdline.c:705:  .longName   = "max-protocol",
source3/selftest/tests.py:508:for options in ["", 
"--option=clientntlmv2auth=no", "--option=clientusespnego=no", 
"--option=clientusespnego=no --option=clientntlmv2auth=no", 
"--option=clientntlmv2auth=no --option=clientlanmanauth=yes 
--max-protocol=LANMAN2", "--option=clientntlmv2auth=no 
--option=clientlanmanauth=yes --option=clientmaxprotocol=NT1"]:
source3/utils/smbcquotas.c:627: .longName   = "max-protocol",
source3/utils/net_help_common.c:67: 
d_printf(_("\t-m|--max-protocol=MAXPROTOCOL\t\tSet max protocol level\n"));

I think that samba.dtd contents some common shared entries and both
smbclient.1.xml and smbcacls.1.xml should not have their own


I did not try to check by removing them.

More annoying is small discrepancy regarding the '-U|--user' option.

$ rgrep -n "\-U|--user" *
docs-xml/build/DTD/samba.entities:591:  
-U|--user=[DOMAIN\]USERNAME[PASSWORD]
docs-xml/manpages/rpcclient.1.xml:42:   -U|--user=[DOMAIN/]USERNAME[%PASSWORD]
docs-xml/manpages/smbcquotas.1.xml:46:  -U|--user=[DOMAIN/]USERNAME[%PASSWORD]
docs-xml/manpages/winexe.1.xml:42:  -U|--user=[DOMAIN/]USERNAME%[PASSWORD]
docs-xml/manpages/smbcacls.1.xml:56:-U|--user=[DOMAIN/]USERNAME[%PASSWORD]
docs-xml/manpages/mdsearch.1.xml:42:  -U|--user=[DOMAIN/]USERNAME[%PASSWORD]
docs-xml/manpages/smbclient.1.xml:51:   -U|--user=[DOMAIN/]USERNAME%[PASSWORD]
docs-xml/manpages/samba-regedit.8.xml:38:   -U|--user=[DOMAIN/]USERNAME[%PASSWORD]
docs-xml/manpages/smbtree.1.xml:34: -U|--user=[DOMAIN/]USERNAME[%PASSWORD]
docs-xml/manpages/net.8.xml:40: -U|--user=[DOMAIN/]USERNAME[%PASSWORD]
docs-xml/manpages/pdbedit.8.xml:33: -U|--user 
SID=STRING
source3/utils/net_help_common.c:75: 
d_printf(_("\t-U|--user=[DOMAIN/]USERNAME[%%PASSWORD]\tSet the "

The separator to the DOMAIN value (ie. [DOMAIN\] or [DOMAIN/]) and the position
of the pourcent % should be inside the brackets (ie. [%PASSWORD] and not
%[PASSWORD]).

Finally, I found more to say about the documentation versus the output of help
option on the different samba commands.
Let see with what upstream have to say.

To conclude, be free to close this wish.

Regards,
Patrice

On Wed, 2 Nov 2022 19:53:02 +0300 Michael Tokarev  wrote:
> 
> 28.10.2022 10:28, Patrice DUROUX wrote:
> > Package: smbclient
> > Version: 2:4.16.6+dfsg-5
> > Severity: wishlist
> > 
> > Dear Maintainer,
> > 
> > The smbclient(1) manpage contains some multiple entries in the OPTIONS
> > section regarding the SYNOPSIS list.
> > 
> > Here are the two detected cases:
> > 
> > 71:   -m|--max-protocol protocol
> > 72-   This allows the user to select the highest SMB protocol level
that smbclient will use to connect to the server. By default this is set to
highest available SMB3
> > and
> > 259:   -m|--max-protocol=MAXPROTOCOL
> > 260-   The value of the parameter (a string) is the highest protocol
level that will be supported by the client.
> 
> samba manpages are generated. And this is interesting.
> 
> The first text above comes from docs-xml/manpages/smbclient.1.xml:
> 
>  -m|--max-protocol protocol
>  This allows the user to select the
>  highest SMB protocol level that smbclient will use to
>  connect to the server. By default this is set to..
> 
> And the second text comes from docs-
xml/smbdotconf/protocol/clientmaxprotocol.xml:
> 
>       context="G"
>   type="enum"
>   function="_client_max_protocol"
>   

Bug#1023041: FTBFS: uninstalled files; dh_missing errors out

[Håvard F . Aasen]

On 03.11.2022 18:41, Rene Engelhard wrote:
> Control: severity -1 important
> Control: tags -1 - moreinfo
> Control: tags -1 - unreproducible
> thanks
> 
> Am Sun, Oct 30, 2022 at 07:19:24AM +0100 schrieb Håvard F. Aasen:
dh_missing
 dh_missing: warning: lib/systemd/system/oscap-remediate.service exists in 
 debian/tmp but is not installed to anywhere
 dh_missing: warning: usr/bin/oscap-remediate-offline exists in debian/tmp 
 but is not installed to anywhere
 dh_missing: warning: usr/libexec/oscap-remediate exists in debian/tmp but 
 is not installed to anywhere
 dh_missing: warning: usr/share/man/man8/oscap-remediate-offline.8 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: libopenscap-dev (4), libopenscap-perl (2), libopenscap25 
 (4), openscap-common (3), openscap-doc (2), openscap-scanner (2), 
 openscap-utils (8), python3-openscap (1)
 * dh_installdocs: libopenscap-dev (3), libopenscap-perl (0), 
 libopenscap25 (0), openscap-common (0), openscap-doc (0), openscap-scanner 
 (1), openscap-utils (0), python3-openscap (0)
 * dh_installexamples: libopenscap-dev (0), libopenscap-perl (0), 
 libopenscap25 (0), openscap-common (0), openscap-doc (0), openscap-scanner 
 (1), openscap-utils (0), python3-openscap (0)
 * dh_installman: libopenscap-dev (0), libopenscap-perl (0), 
 libopenscap25 (0), openscap-common (0), openscap-doc (0), openscap-scanner 
 (1), openscap-utils (7), python3-openscap (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: *** [debian/rules:68: binary] Error 25
 dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
 status 2
 debuild: fatal error at line 1182:
 dpkg-buildpackage -us -uc -ui -b failed

 Doesn't look related to xmlsec1 1.2.35 so I did a cross-check with sid
 and it also FTBFS there.

>>>
>>> Would you mind providing a complete build log? I actually can't reproduce
>>> this on my end in unstable. This was also rebuilt in the main archive just
>>> eight days ago, but sure, a lot can happen in that time.
>>>
>>
>> I uploaded a new version to unstable with changes unrelated to this bug. That
>> version successfully built in the main archive, I am therefore lowering the
>> severity to normal. Please provide a build log if this is a problem.
> 
> It would have been be helpful if you actually wrote to me instead of just the 
> bug
> (n...@bugs.debian.org only goes to the bug), as the Reply-To: of each
> bugreport already does (or do it manually, or use
> nnn-submit...@bugs.debuan.org); so that people actually see it. I just
> saw it by chance today when looking at my submitted bugs' page and saw
> the downgrade.
> 
> Anyways, buildlog attached.
> 
> Note that this admittedly is a unclean chroot, but a FTBFS then also is
> a bug (important I think, but see [1]. 
> cowbuilder login sid chroot +
>  apt-build-dep lasso +
>  apt-build-dep libaqbanking +
>  apt build-dep libreoffice +
>  apt-build-dep nordugrid-arc +
>  apt-build-dep oath-toolkit +
>  apt build-dep open-vm-tools
> 
> is the actual chroot used. (Actually it was in my libreoffice build
> chroot, so those were preexisting)
> 
> Regards,
> 
> Rene
> 
> [1]
> 18:32 < _rene_> what severity are "FTBFS in 'unclean' chroots" again?
> 18:32 -!- KBDharunKrishna[m]1 [~kbdkmatri@2a01:4f9:c010:c8f3:1::28d] has 
> joined #debian-devel
> 18:32 < _rene_> builds in a clean (as it only build-deps) apparently
> 18:33 < kibi> important at most
> 18:34 < kibi> (long time no see though, there might be special circumstances 
> that would make it warrant more)
> 18:36 < Sebastinas> We recently had a bunch of "FTBFS with systemd installed" 
> recently which we treated as RC.
> 18:36 < Sebastinas> (Triggered by some essential packages pulling systemd)
> 18:37 < Sebastinas> So: depends(tm)
> 18:37 < _rene_> that sounds related
> 18:37 < _rene_> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023041)
> 18:37 -zwiebelbot:#debian-devel- Debian#1023041: FTBFS: uninstalled files; 
> dh_missing errors out - https://bugs.debian.org/1023041
> 18:38 < _rene_> >> dh_missing: warning: 
> lib/systemd/system/oscap-remediate.service exists 

Bug#1023418: libpciaccess: FTBFS on hurd-i386: symbol list update

[Samuel Thibault]

Source: libpciaccess
Version: 0.17-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

The newer libpciaccess doesn't build on hurd-i386 because the newer
upstream version modified some symbols. The attached patch fixes that. I
checked that indeed no package is using the old
pci_device_x86_map/unmap_legacy/range (they were used only internally by
the library).

Could you apply it?

Thanks,
Samuel

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

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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/libpciaccess0.symbols.original   2022-11-03 18:16:21.0 
+
+++ debian/libpciaccess0.symbols2022-11-03 18:17:26.0 +
@@ -45,14 +45,10 @@
  pci_device_vgaarb_trylock@Base 0.10.7
  pci_device_vgaarb_unlock@Base 0.10.7
  (arch=hurd-i386)pci_device_x86_close_io@Base 0.16
- (arch=hurd-i386)pci_device_x86_map_legacy@Base 0.16
- (arch=hurd-i386)pci_device_x86_map_range@Base 0.16
  (arch=hurd-i386)pci_device_x86_open_legacy_io@Base 0.16
  (arch=hurd-i386)pci_device_x86_read16@Base 0.16
  (arch=hurd-i386)pci_device_x86_read32@Base 0.16
  (arch=hurd-i386)pci_device_x86_read8@Base 0.16
- (arch=hurd-i386)pci_device_x86_unmap_legacy@Base 0.16
- (arch=hurd-i386)pci_device_x86_unmap_range@Base 0.16
  (arch=hurd-i386)pci_device_x86_write16@Base 0.16
  (arch=hurd-i386)pci_device_x86_write32@Base 0.16
  (arch=hurd-i386)pci_device_x86_write8@Base 0.16
@@ -72,5 +68,6 @@
  pci_system_init@Base 0
  pci_system_init_dev_mem@Base 0.10.2
  (arch=hurd-i386)pci_system_x86_destroy@Base 0.16
+ (arch=hurd-i386)pci_system_x86_map_dev_mem@Base 0.17
  (arch=hurd-i386)x86_disable_io@Base 0.16
  (arch=hurd-i386)x86_enable_io@Base 0.16

Bug#1023369: ITP: s2n-tls -- C99 implementation of the TLS/SSL protocols

[Andreas Metzler]

On 2022-11-02 Noah Meyerhans  wrote:
> * Package name: s2n-tls
[...]
>  s2n-tls implements SSLv3, TLS1.0, TLS1.1, and TLS1.2. For encryption,
[...]

Hello,

I was wondering whether we should still add new TLS implementations to
Debian that did not support TLS1.3. However README.md since 1.3.2 says
"s2n-tls implements SSLv3, TLS1.0, TLS1.1, TLS1.2, and TLS1.3."

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

Bug#1022868: closed by Andreas Beckmann (Re: Certificate change breaks signald)

[martin f krafft]

Regarding the following, written by "Debian Bug Tracking System" on 2022-10-30 
at 18:27 Uhr +:
This is not an official Debian package. Please report any issues to 
the provider of this third-party package.


Autsch. I am sorry. :/

--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#1023417: FTBFS: setuptools vs distutils

[Samuel Thibault]

Package: devscripts
Version: 2.22.2
Severity: serious
Tags: patch
Justification: FTBFS

Hello,

devscripts currently FTBFS in sid:

make[2]: Leaving directory '/tmp/devscripts-2.22.2/doc'
python3 setup.py clean -a
/tmp/devscripts-2.22.2/scripts/setup.py:5: DeprecationWarning: The distutils 
package is deprecated and slated for removal in Python 3.12. Use setuptools or 
check PEP 632 for potential alternatives
  from distutils.command.clean import clean as BaseCleanCommand
/usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18: UserWarning: 
Distutils was imported before Setuptools, but importing Setuptools also 
replaces the `distutils` module in `sys.modules`. This may lead to undesirable 
behaviors or errors. To avoid these issues, avoid using distutils directly, 
ensure that setuptools is installed in the traditional way (e.g. not an 
editable install), and/or make sure that setuptools is always imported before 
distutils.
  warnings.warn(
/usr/lib/python3/dist-packages/_distutils_hack/__init__.py:33: UserWarning: 
Setuptools is replacing distutils.
  warnings.warn("Setuptools is replacing distutils.")
Traceback (most recent call last):
  File "/tmp/devscripts-2.22.2/scripts/setup.py", line 37, in 
setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 87, in 
setup
return distutils.core.setup(**attrs)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 
172, in setup
ok = dist.parse_command_line()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
474, in parse_command_line
args = self._parse_command_opts(parser, args)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1107, in 
_parse_command_opts
nargs = _Distribution._parse_command_opts(self, parser, args)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
540, in _parse_command_opts
raise DistutilsClassError(
distutils.errors.DistutilsClassError: command class  must subclass Command

The attached patch does the suggested change, and indeed fixes the
issue.

Samuel

-- Package-specific info:

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

--- ~/.devscripts ---
DEBSIGN_KEYID="0xE691B4B575781F62!"
DEBCHANGE_AUTO_NMU=no
DEBSIGN_PROGRAM="gpg --use-agent"

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.9
ii  fakeroot  1.29-1
ii  file  1:5.41-4
ii  gnupg 2.2.40-1
ii  gnupg22.2.40-1
ii  gpgv  2.2.40-1
ii  libc6 2.35-4
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-1
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-4
ii  python3   3.10.6-1
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.5.3+b1
ii  curl7.85.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.08.11
ii  dput-ng [dput]  1.35
ii  dupload 2.9.11
ii  equivs  2.3.1
ii  libdistro-info-perl 1.2
ii  libdpkg-perl1.21.9
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-1
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-1
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.16-1
ii  licensecheck3.3.0-1
ii  lintian 2.115.3
ii  man-db  2.11.0-1+b1
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.3.0+nmu1
ii  python3-debian  0.1.48
ii  python3-magic   2:0.4.26-2
ii  python3-requests2.27.1+dfsg-1
ii  

Bug#955479: apparmor fixes for xline_db and geoip

[Björn Lässig]

Hi There

On Fri, 2021-01-22 at 05:20 +0900, Marc Dequènes (duck) wrote:
> Quack,
> 
> On 2021-01-17 02:20, Filippo Giunchedi wrote:
> > On Wed, Apr 01, 2020 at 07:03 PM, Marc Dequènes wrote:
> > > I added this line to the apparmor policy:
> > >   /usr/share/GeoIP/GeoIP.dat r,
> > > 
> > > Btw the package could also Suggest geoip-database needed for this 
> > > module.
> > 
> > Thank you for the report, I'm not an apparmor expert but I'm happy to
> > include support in the package (at
> > https://salsa.debian.org/debian/inspircd)
> > 
> > Suggesting 'geoip-database' is a good idea, I'll add that!
> 
>  […]
> 
> Another suggestion: to allow admins to add little fixes or adaptations 
> to the apparmor policy I saw that several packages include a file in 
> /etc/apparmor.d/local/ (chronyd for eg), which is ignored if the file is 
> missing, very practical. For Inspircd that would give (at the end of the 
> rules but inside the braquets):
> #include 

This Bug hit me too for using the permchannel module.
It would really really help us, if at least the 

  #include 

would make it to the next debian release.

greeting and thanks
Björn Lässig

Bug#1023386: pacman-package-manager: Please backport to bullseye-backports

[Ben Westover]

Hello Dylan,

On 11/3/22 10:30 AM, Dylan Aïssi wrote:
> The backport will have to go through the backport NEW queue, so you
> need a DD to sponsor the initial version. I can sponsor it if you
> want, I just need a git repo with a backport branch to build it :-).
> Meanwhile, you can request to have your uid in the backports Access
> Control Lists [1] for future updates.

Thanks for the link. I have uploaded my backport to Mentors [1] for your
sponsorship, and it's also available in the debian/bullseye branch of my
package repo [2]. Can you provide DM access after it passes NEW?

Thanks,
--
Ben Westover

[1] https://mentors.debian.net/package/pacman-package-manager/
[2] https://salsa.debian.org/BenTheTechGuy/pacman/-/tree/debian/bullseye


OpenPGP_signature
Description: PGP signature

Bug#1023280: [Pkg-nagios-devel] Bug#1023280: monitoring-plugins-basic: check_disk always segfaults

[Stephane Bortzmeyer]

On Thu, Nov 03, 2022 at 10:46:29AM +0100,
 Jan Wagner  wrote 
 a message of 21 lines which said:

> I'm unable to reproduce this on bullseye/amd64

As you've seen, it's on ARM so it may be ARM-specific.

Bug#998951: leaktracer: diff for NMU version 2.4-6.1

[Marcos Talau]

Control: tags 998951 + patch
Control: tags 998951 + pending


Dear maintainer,

I've prepared an NMU for leaktracer (versioned as 2.4-6.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u leaktracer-2.4/debian/changelog leaktracer-2.4/debian/changelog
--- leaktracer-2.4/debian/changelog
+++ leaktracer-2.4/debian/changelog
@@ -1,3 +1,10 @@
+leaktracer (2.4-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998951).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 14:35:22 -0300
+
 leaktracer (2.4-6) unstable; urgency=medium
 
   * Switch to debhelper v9 (Closes: #817515).
diff -u leaktracer-2.4/debian/rules leaktracer-2.4/debian/rules
--- leaktracer-2.4/debian/rules
+++ leaktracer-2.4/debian/rules
@@ -92,4 +92,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#1022183: config.h is missing

[Yadd]

On 02/11/2022 15:54, Yadd wrote:

Hi,

recent upload now includes .h files but they refer to a missing "config.h":

   In file included from /usr/include/cmark-gfm/chunk.h:8,
    from /usr/include/cmark-gfm/map.h:4,
    from /usr/include/cmark-gfm/references.h:4,
    from /usr/include/cmark-gfm/parser.h:5,
    from ../src/markdown.cc:4:
   /usr/include/cmark-gfm/buffer.h:9:10: fatal error: config.h: No such
    file or directory
   9 | #include "config.h"
     |  ^~

This file is generated during build and stored in a temporary directory. 
Could you add it to /usr/include/cmark-gfm/ ?


Cheers,
Yadd


Hi,

Here is a simple patch that fixes this last problem:

diff --git a/debian/libcmark-gfm-dev.install 
b/debian/libcmark-gfm-dev.install

index b4fe0e3..13ee5bf 100644
--- a/debian/libcmark-gfm-dev.install
+++ b/debian/libcmark-gfm-dev.install
@@ -6,3 +6,4 @@ usr/include/cmark-gfm_export.h
 usr/include/cmark-gfm.h
 usr/include/cmark-gfm_version.h
 usr/include/cmark-gfm
+*/src/config.h usr/include/cmark-gfm

Note also that a debian/clean should be added to drop test files:

diff --git a/debian/clean b/debian/clean
new file mode 100644
index 000..40776c2
--- /dev/null
+++ b/debian/clean
@@ -0,0 +1 @@
+test/__pycache__/

Many thanks!

Cheers,
Yadd

Bug#1023416: ITP: python-django-constance -- Dynamic Django settings

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-constance
  Version : 2.9.1
  Upstream Author : Jannis Leidel 
* URL : https://github.com/jazzband/django-constance/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Dynamic Django settings

 A Django app for storing dynamic settings in pluggable backends (Redis and
 Django model backend built in) with an integration with the Django admin app.
 .
 Features:
  * Easily migrate your static settings to dynamic settings.
  * Edit the dynamic settings in the Django admin interface.

I intend to maintain this package as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmNj+HkRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrDxwgAkxtbOblZWpK+rnJ6TAj1G7reykYwvYAe
NbTDlHRCQj8BjnBtD9jQxNDuksKHlxNiPTnR9Hrj7JeDsocpCwj115PjMPD/5Jt1
KRZCxOPiPkjLeoPn0RS0FdCvN1L97+aoX/aYERKBWXQTZWFNGK/ulL82cOu6NYII
uAQUzDDDEO3yJ14ZrC40juJG8flN+Oxv4sPVG6XBmUqE2bE5WysaLueDWz6YldM/
ETBnzVL+FDOxLwcnbhlrwybcKyrSOw9zJSB8xnXdk9IODjOhfDHrSpfAal1ggVI0
x9BLHXX6AXv4h4pmvsIaBhPfX3Cg1lUOQbvKhyqnrVj4ldpQMEe2dg==
=EVcf
-END PGP SIGNATURE-

Bug#1023282: wnpp/debrebuild-fepitre: reassign to devscripts

[Holger Levsen]

control: reassign -1 descripts
thanks

Hi,

as discussed during the r-b summit in Venice this should rather be included
in src:devscripts, reassigning accordingly.


-- 
cheers,
Holger

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

Never waste a crisis.


signature.asc
Description: PGP signature

Bug#1023415: ITP: aws-checksums -- fast, cross-platform CRC32c/CRC32 implementations

[Noah Meyerhans]

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

* Package name: aws-checksums
  Version : 0.1.13
  Upstream Author : Amazon Web Services
* URL : https://github.com/awslabs/aws-checksums
* License : Apache 2.0
  Programming Lang: C
  Description : fast, cross-platform CRC32c/CRC32 implementations

 Cross-Platform HW accelerated CRC32c and CRC32 with fallback to
 efficient SW implementations. C interface with language bindings for
 each of our SDKs

This package will be maintained by the cloud team.  Packaging is initially
being driven by awscli v2 dependencies.

Bug#1023400: Bug#1023401: src:python-biopython: unsatisfied build dependency in testing: python3-rdflib

[Andreas Tille]

Control: block -1 by 1012482
Control: tags -1 upstream
Control: forwarded -1 https://github.com/RDFLib/rdflib/issues/1844

Hi Paul,

its all about the fact that rdflib is broken and removed from testing.
We are nagging upstream constantly[1] with no success so far.  This
issue creates noise about testing removals in about 100 packages and
is extremely annoying.

I assume if you want to file bugs about missing python3-rdflib manually
its quite a waste of time for you since the problem is known and more
bug reports will not make things more visible.

Kind regards
   Andreas.

[1] https://github.com/RDFLib/rdflib/issues/1844

-- 
http://fam-tille.de

Bug#1023414: emacs-gtk: "lax space matching" no longer works

[Vincent Lefevre]

Package: emacs-gtk
Version: 1:28.2+1-3
Severity: normal
Tags: upstream
Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58992

(I assume that this is an upstream bug, but I didn't test an official
upstream version.)

The Emacs manual says:

15.9 Lax Matching During Searching
==
[...]
   By default, search commands perform “lax space matching”: each space,
or sequence of spaces, matches any sequence of one or more whitespace
characters in the text.  (Incremental regexp search has a separate
default; see *note Regexp Search::.)  Hence, ‘foo bar’ matches
‘foo bar’, ‘foo  bar’, ‘foo   bar’, and so on (but not ‘foobar’).  More
[...]

This is working with GNU Emacs 27, but not with GNU Emacs 28.2
(tested under Debian/unstable).

To reproduce with emacs -Q, consider a file with

ab
cd
ab cd

and search for "b c" with

  C-s b c

Only the one in the 3rd line is found.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common 1:28.2+1-3
ii  emacs-common 1:28.2+1-3
ii  libacl1  2.3.1-1
ii  libasound2   1.2.7.2-1
ii  libc62.35-1
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.4-1
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libgccjit0   12.2.0-7
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libgif7  5.2.1-2.5
ii  libglib2.0-0 2.74.1-1
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libgnutls30  3.7.8-4
ii  libgpm2  1.20.7-10+b1
ii  libgtk-3-0   3.24.34-3
ii  libharfbuzz0b5.2.0-2
ii  libice6  2:1.0.10-1
ii  libjansson4  2.14-2
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  liblcms2-2   2.13.1-1+b1
ii  libm17n-01.8.0-4
ii  libotf1  0.9.16-3+b1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpng16-16  1.6.38-2
ii  librsvg2-2   2.54.5+dfsg-1
ii  libselinux1  3.4-1+b2
ii  libsm6   2:1.2.3-1
ii  libsystemd0  252-2
ii  libtiff5 4.4.0-5
ii  libtinfo66.3+20220423-2
ii  libx11-6 2:1.8.1-2
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxml2  2.9.14+dfsg-1.1
ii  libxrender1  1:0.9.10-1.1
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages emacs-gtk recommends:
ii  fonts-noto-color-emoji  2.038-1

Versions of packages emacs-gtk suggests:
ii  emacs-common-non-dfsg  1:28.2+1-2

-- no debconf information

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

Bug#1012482: Bug#1023399: src:zeitgeist: unsatisfied build dependency in testing: python3-rdflib

[Jonas Smedegaard]

Quoting Paul Gevers (2022-11-03 13:30:20)
> Dose [1] is reporting a build issue with your package, it's missing a
> build dependency. Obviously your build dependencies shouldn't be
> removed from testing, but unfortunately there are multiple scenarios
> where that can happen nevertheless. To uphold our social contract,
> Debian requires that packages can be rebuild from source in the suite
> we are shipping them, so currently this is a serious issue with your
> package in testing.
> 
> Can you please investigate the situation and figure out how to resolve
> it? Regularly, if the build dependency is available in unstable,
> helping the maintainer of your Build-Depends to enable migration to
> testing is a great way to solve the issue. If your build dependency is
> gone from unstable and testing, you'll have to fix the build process
> in some other way.

I don't know how python3-rdflib managed to get kicked from testing
without its reverse build-dependencies getting kicked as well.  That
looks like the real (meta)bug here to me.

Reason python3-rdflib got kicked seems to be that its maintainer (the
Python team) has spent *zero* time on the one RC bug filed against the
package: They have made no comment at bug#1012482 which includes a
suggestion (which I agree with) to lower the severity of that bug to
simply not be release-critical: Yes, naïve implementations of the RDF
protocol can be tricked into pulling data from the filesystem, because
URIs are not necessarily all http-based and failing to care for that
may lead to surprises - which would be neat if generic RDF processing
tools were to ensure protection against but in my opinion unreasonable
to *require*: As I understand it, the equivalent would be to kick out
libcurl from Debian because it doesn't offer the heavy and complex
sandboxing mechanisms implemented in (only the biggest) web browsers.

If bug#1012482 should continue to be treated as RC then I see no other
approach for zeitgeist than to kick that as well.  Which I find sad and
unfair, but oh well - solving the upstream bug seems pretty challenging
(and seems to attract little effort due to being relatively academic).


 - Jonas

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

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

signature.asc
Description: signature

Bug#1019613: ruby-capybara: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error: raise LoadError, 'Capybara is unable to load `puma` for its server, please add `puma` to your project or sp

[Nilesh Patra]

Control: tags -1 moreinfo

It builds fine for me locally. Could you please try a re-build?


--
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1023224: [Pkg-swan-devel] Bug#1023224: Bug#1023224: strongswan: autopkgtest regression: depends on no longer built strongswan-scepclient

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2022-11-02 at 19:14 +0100, Paul Gevers wrote:
> Hi Yves-Alexis,
> 
> On 02-11-2022 17:27, Yves-Alexis Perez wrote:
> > I'm not sure why the test is failing then and what I should have done
> > differently. Could you give me some pointers here?
> 
> https://sources.debian.org/src/strongswan/5.9.8-1/debian/tests/control/
> 
> line 2 says that the *first* two tests Depends on strongswan-scepclient. 
> That means that autopkgtests tries to install that binary package, which 
> fails because it's no longer available. Either remove the tests (if they 
> need that binary), or adapt the Depends line to what is required for the 
> test.

I did a -2 upload but it's likely to fail again because I noticed afterwards
that the _copyright test will fail as well since the util has been removed.

I'll do a -3 upload when possible.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmNj7gwACgkQ3rYcyPpX
RFugOwf9FZWN9C368efVEJVid7Bau6PQcocSRRCUO9dmfHbh99tzczX80FD2ob7v
OcW7CD/2HWM0wdXzpFv9wG+9jwWJWZgL1NhHY+DY0YsltvMlaM/iS1Q6CTfPa+w+
Z1h70shIkgRFLKVxrYBry/Y2tqOyU+PII/jof7ySY8NHe44o1OXQhb4kqQLKcWAE
i5Llcl174sx2lgRcLiEMhNIrANptYr4Sedz+sLo05MOZsvUSdhC3xf6af0DAodrK
1WG9R64TxVTJM5JHPX85vZOl4yci8m7EmUK7wqkIRDwvtKYr/v7ZbCV4mZrFYwGp
15mAJsc/5Zlmz5lDVyxBVij/T1p0nA==
=SQsI
-END PGP SIGNATURE-

Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7

[Bill Allombert]

On Thu, Nov 03, 2022 at 12:25:17PM +0100, Jerome BENOIT wrote:
> > 
> > Indeed, the GAP patch debian/patches/program-path adds
> > /usr/share/gap/pkg/guava/bin/ to this list.
> > 
> > > However only the last dir[ectory] may work on muti-architecture boxes.
> > > Here we would need a "/usr/share/gap/pkg/guava/bin/ between 
> > > the two current ones:
> > > can gap support this ?
> > 
> > GAP does not have the notion of the Debian triplet, so it is difficult to 
> > write a patch
> > to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/
> 
> I guess that a patch can be written to do so.

This probably requires changing the C code to define a new 
GAPInfo.DEB_HOST_MULTIARCH field.
Do you have a better idea ?

> > There is a single /usr/bin for all archs, so in particular a single 
> > /usr/bin/gap,
> > so I do not see why we need to support several /usr/share/gap/pkg/guava/bin,
> > especially since mismatched gap-core and gap-guava-bin should work.
> 
> Along this reasonning, 
> /usr/share/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv8/ has no use.

Indeed. gap only need to support it for compatibility with non-debian-packaged 
gap packages,
that uses this kind of directory name.

> Please let me fix this guava issue by the week-end.

OK, thanks!
Bill.

Bug#1020527: pam-p11: upcoming FTBFS

[Bastian Germann]

Control: severity -1 serious

This is now happening.

Bug#1023413: dh-cargo: should prevent dh_clean from removing Cargo.toml.orig

[Daniel Kahn Gillmor]

Package: dh-cargo
Version: 28
Control: affects -1 debhelper src:rust-document-features debcargo

When packaging Rust crates, the rust-team typically packages from the
bundles published on crates.io.  Those are published with a modified
version of Cargo.toml, and the original upstream source for Cargo.toml
is present as Cargo.toml.orig.

debhelper's dh_clean by default removes all files matching *.orig, which
means that the upstream Cargo.toml.orig is getting stripped before the
build happens. (dh_clean is typically invoked before a build)

This is problematic for tools like the document-features crate, which
relies on comments in Cargo.toml.orig to extract documention about the
features of any given crate.

See the upstream discussion at
https://github.com/slint-ui/document-features/issues/15

If dh-cargo were able to force the exclusion Cargo.toml.orig, that would
be great, but i tried hacking on the clean() function in cargo.pm to
push something into @{dh{EXCLUDE}} and i couldn't get it to work.  Maybe
someone who knows debhelper or dh-cargo better than me can figure out
how to do it.

Or, maybe a newer version of debhelper itself could just generically
avoid destroying Cargo.toml.orig in the top-level of any source tree,
even though it removes all the other *.orig files ?

Alternately, debcargo could be modified to add the following stanza to
its autogenerated debian/rules:

--- debian/rules
+++ debian/rules
@@ -4,3 +4,6 @@
 
 override_dh_auto_test:
dh_auto_test -- test --all
+
+override_dh_clean:
+   dh_clean -XCargo.toml.orig


If the dh-cargo folks think it should be fixed in either debhelper or
debcargo, feel free to reassign this bug report.

Thanks,

--dkg


signature.asc
Description: PGP signature

Bug#1023412: ITP: aws-c-common -- C99 package for AWS SDK for C

[Noah Meyerhans]

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

* Package name: aws-c-common
  Version : 0.8.4
  Upstream Author : Amazon Web Services
* URL : https://github.com/awslabs/aws-c-common
* License : Apache 2.0
  Programming Lang: C
  Description : C99 package for AWS SDK for C

 Core c99 package for AWS SDK for C. Includes cross-platform
 primitives, configuration, data structures, and error handling.

This package will be maintained by the cloud team.  It is initially being
packaged as a dependency for awscli v2.

Bug#1023393: policykit-1: Not prompted to authenticate with my own identity any more

[Sam Morris]

On 03/11/2022 13:39, Simon McVittie wrote:

On Thu, 03 Nov 2022 at 11:51:52 +, Sam Morris wrote:

Here's my configuration:

 # cat /etc/polkit-1/localauthority.conf.d/60-sam.conf
 [Configuration]
 AdminIdentities=unix-user:sam.mor...@domain.example.com


Is that really your Unix/PAM login name, the one you'd get from `id -nu`
or `su - $user` or similar? Or is your login name something like sam.morris
or sam?


Yes - the user account lives in an Active Directory domain which is 
projected into the POSIX world by FreeIPA. The user name is the SAM 
Account Name of the user @ The AD domain's DNS FQDN.



The usual setup with a modern polkit version is that the admin identities
are handled by /usr/share/polkit-1/rules.d/40-debian-sudo.rules,
which returns "unix-group:sudo", meaning "any member of the sudo group
is a local sysadmin".


Having my username in the pklocalauthority like that is sort of a 
workaround for a number of unfortunate things about how polkit 
enumerates groups & because FreeIPA isn't able to put AD users into 
netgroups.


You're right, adding my user to the (local) sudo group will probably do 
the job.



It's usually unnecessary to configure this, either in the old PKLA
backend or in the newer JS backend, so the way this interoperates with
the legacy PKLA configuration is unlikely to be particularly well-tested.

I wonder whether the problem here might be that 40-debian-sudo.rules is
sequenced earlier than 49-polkit-pkla-compat.rules, which means only the
function defined in 40-debian-sudo.rules gets called, and the one in
49-polkit-pkla-compat.rules is ignored?


You're right. I actually just commented out the contents of 
40-debian-sudo.rules entirely. polkit immediately reloads the rules and 
my pkcheck command is once again prompting me for my own credentials.



polkit keeps calling admin rule functions until one returns a non-empty
result, so only the first one that returns a result (in lexicographic
order by filename) is practically useful.


Argh, that's a really annoying. I wonder why they don't call all the 
admin rules and collect all of the results...


Anyway, that's all I need to get our systems working sensibly again.

But I suppose this should become a bug against polkitd-pkla since in 
practice its 49-polkit-pkla-compat.rules will never be called since 
40-debian-sudo.rules is called first.


Perhaps one solution would be to renumber to << 40, and ship a 
pklocalauthority config file with 'unix-group:sudo'. This will ensure 
that systems where polkitd-pkla is installed will match the default 
behaviour of systems where it isn't installed.



 smcv


Thanks for your help! :)

--
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Bug#1019752: libpcre3-udeb: Can this be dropped?

[Cyril Brulebois]

Bastian Germann  (2022-11-03):
> On Wed, 14 Sep 2022 20:05:53 +0200 Bastian Germann  wrote:
> > grep 3.8-1 has switched to pcre2. If I am not mistaken, grep is the
> > last reverse dependency of libpcre3-udeb.  When the new grep version
> > has migrated to bookworm, please ask the installer team if it is
> > okay to drop libpcre3-udeb.
> 
> grep's libpcre3-udeb is now gone from bookworm.
> Is there a chance of eliminating libpcre3-udeb?

As far as I can see, no reverse dependencies in unstable, should be fine
to drop. You might want to wait a few days, someone else might spot
something I might have missed.


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


signature.asc
Description: PGP signature

Bug#954781: libqt5core5a: QT will not use Wayland on Gnome

[Carlos Henrique Lima Melara]

On Thu, Nov 03, 2022 at 06:02:03PM +0300, Dmitry Shachnev wrote:
> > 3. The only problem is that qtwayland5 wayland platform plugin is not
> > installed by default in a clean install of debian so applications fail
> > to run wayland natively (fallback to xcb).
> >
> > I think we would need the qtwayland5 installed by default when gnome is
> > installed (since wayland is the default there). Do you know which
> > package should Depends or Recommends qtwayland5 (maybe gnome-core or
> > some other package)?
> 
> libqt5gui5 currently suggests it. Do you think it needs to be a
> recommendation?

I think it should be at least a recommendation when wayland is installed
since we're defaulting to run natively. Can we make this behaviour
promoting qtwayland5 to Recommends in libqt5gui5? Because I think people
running X11 will also get the qtwayland5, right? If so, is there other
package that we could use to recommend or depend so it's only installed
when wayland is installed?

I forgot to mention in the first email, but there is a bug filled
against qtwayland5 regarding this matter too [1].

> > The terminal output below shows 3 executions of kristall. The first was
> > using the version from unstable. The second was using the experimental
> > version - fallback to xcb because the wayland platform plugin wasn't
> > installed. The third is using experimental's version after qtwayland5
> > was installed.
> >
> > charles@debianSid-vm:~$ kristall 
> > Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
> > QT_QPA_PLATFORM=wayland to run on Wayland anyway.
> > defaultServiceProvider::requestService(): no service found for - 
> > "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > charles@debianSid-vm:~$ kristall 
> > qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
> > defaultServiceProvider::requestService(): no service found for - 
> > "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > charles@debianSid-vm:~$ kristall 
> > QSocketNotifier: Can only be used with threads started with QThread
> > defaultServiceProvider::requestService(): no service found for - 
> > "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > ignoring 1 out of 1
> > 2 0 "text/gemini"
> > Loaded 1265 bytes of type "text" / "gemini"
> > cache: pushing url  QUrl("gemini://gemini.circumlunar.space/")
> > ignoring 1 out of 1
> > 2 0 "text/gemini"
> > Loaded 350 bytes of type "text" / "gemini"
> > cache: pushing url  QUrl("gemini://gemini.circumlunar.space/news/")
> > qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> > qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> > Loaded 79 bytes of type "text" / "gemini"
> 
> This is probably just debug output, does not indicate actual errors.

I think so too. I just left for completeness :-)

Thanks,
Charles

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


signature.asc
Description: PGP signature

Bug#1022151:

[Alexander Korsunsky]

Upstream bug:
https://github.com/pypa/pip/issues/11309

Workaround:
pip config set global.disable-pip-version-check true

Seems to be fixed in pip 22.3:
https://github.com/pypa/pip/blob/main/NEWS.rst#bug-fixes

Bug#1023411: nmu: 2.4.3.7-4+b3

[Alberto Gonzalez Iniesta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu tripwire_2.4.3.7-4+b3 . ANY . unstable . -m "Rebuild with new libc (Closes 
#1022791)"

Tripwire is statically build and libc updates break it.

Thanks.

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

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

Bug#954781: libqt5core5a: QT will not use Wayland on Gnome

[Renato Gallo]

I think it should be more than a recommendation

On Thu, Nov 3, 2022 at 4:06 PM Dmitry Shachnev  wrote:

> Hi Carlos!
>
> On Mon, Oct 31, 2022 at 06:55:49PM -0300, Carlos Henrique Lima Melara
> wrote:
> > Took a little while, sorry. Last week was pretty busy. I managed to try
> > it today. I will attach the terminal output in the end. So my feedback
> > is below.
> >
> > 1. I wasn't able to reproduce the misplaced menus (QTBUG-68636) in
> > unstable or experimental versions.
>
> Me too, actually.
>
> > 2. Your patch makes qt choose the wayland plugin on gnome's wayland
> > session by default.
>
> Good. It will reach unstable together with next transition, 5.15.7
> or 5.15.8.
>
> > 3. The only problem is that qtwayland5 wayland platform plugin is not
> > installed by default in a clean install of debian so applications fail
> > to run wayland natively (fallback to xcb).
> >
> > I think we would need the qtwayland5 installed by default when gnome is
> > installed (since wayland is the default there). Do you know which
> > package should Depends or Recommends qtwayland5 (maybe gnome-core or
> > some other package)?
>
> libqt5gui5 currently suggests it. Do you think it needs to be a
> recommendation?
>
> > The terminal output below shows 3 executions of kristall. The first was
> > using the version from unstable. The second was using the experimental
> > version - fallback to xcb because the wayland platform plugin wasn't
> > installed. The third is using experimental's version after qtwayland5
> > was installed.
> >
> > charles@debianSid-vm:~$ kristall
> > Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
> QT_QPA_PLATFORM=wayland to run on Wayland anyway.
> > defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > charles@debianSid-vm:~$ kristall
> > qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
> > defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > charles@debianSid-vm:~$ kristall
> > QSocketNotifier: Can only be used with threads started with QThread
> > defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> > Loaded 79 bytes of type "text" / "gemini"
> > ignoring 1 out of 1
> > 2 0 "text/gemini"
> > Loaded 1265 bytes of type "text" / "gemini"
> > cache: pushing url  QUrl("gemini://gemini.circumlunar.space/")
> > ignoring 1 out of 1
> > 2 0 "text/gemini"
> > Loaded 350 bytes of type "text" / "gemini"
> > cache: pushing url  QUrl("gemini://gemini.circumlunar.space/news/")
> > qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> > qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> > Loaded 79 bytes of type "text" / "gemini"
>
> This is probably just debug output, does not indicate actual errors.
>
> --
> Dmitry Shachnev
>

Bug#954781: libqt5core5a: QT will not use Wayland on Gnome

[Dmitry Shachnev]

Hi Carlos!

On Mon, Oct 31, 2022 at 06:55:49PM -0300, Carlos Henrique Lima Melara wrote:
> Took a little while, sorry. Last week was pretty busy. I managed to try
> it today. I will attach the terminal output in the end. So my feedback
> is below.
> 
> 1. I wasn't able to reproduce the misplaced menus (QTBUG-68636) in
> unstable or experimental versions.

Me too, actually.

> 2. Your patch makes qt choose the wayland plugin on gnome's wayland
> session by default.

Good. It will reach unstable together with next transition, 5.15.7
or 5.15.8.

> 3. The only problem is that qtwayland5 wayland platform plugin is not
> installed by default in a clean install of debian so applications fail
> to run wayland natively (fallback to xcb).
>
> I think we would need the qtwayland5 installed by default when gnome is
> installed (since wayland is the default there). Do you know which
> package should Depends or Recommends qtwayland5 (maybe gnome-core or
> some other package)?

libqt5gui5 currently suggests it. Do you think it needs to be a
recommendation?

> The terminal output below shows 3 executions of kristall. The first was
> using the version from unstable. The second was using the experimental
> version - fallback to xcb because the wayland platform plugin wasn't
> installed. The third is using experimental's version after qtwayland5
> was installed.
>
> charles@debianSid-vm:~$ kristall 
> Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
> QT_QPA_PLATFORM=wayland to run on Wayland anyway.
> defaultServiceProvider::requestService(): no service found for - 
> "org.qt-project.qt.mediaplayer"
> Loaded 79 bytes of type "text" / "gemini"
> charles@debianSid-vm:~$ kristall 
> qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
> defaultServiceProvider::requestService(): no service found for - 
> "org.qt-project.qt.mediaplayer"
> Loaded 79 bytes of type "text" / "gemini"
> charles@debianSid-vm:~$ kristall 
> QSocketNotifier: Can only be used with threads started with QThread
> defaultServiceProvider::requestService(): no service found for - 
> "org.qt-project.qt.mediaplayer"
> Loaded 79 bytes of type "text" / "gemini"
> ignoring 1 out of 1
> 2 0 "text/gemini"
> Loaded 1265 bytes of type "text" / "gemini"
> cache: pushing url  QUrl("gemini://gemini.circumlunar.space/")
> ignoring 1 out of 1
> 2 0 "text/gemini"
> Loaded 350 bytes of type "text" / "gemini"
> cache: pushing url  QUrl("gemini://gemini.circumlunar.space/news/")
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> Loaded 79 bytes of type "text" / "gemini"

This is probably just debug output, does not indicate actual errors.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#999195: konfont: diff for NMU version 0.1-8.2

[Marcos Talau]

Control: tags 999195 + patch
Control: tags 999195 + pending


Dear maintainer,

I've prepared an NMU for konfont (versioned as 0.1-8.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u konfont-0.1/debian/changelog konfont-0.1/debian/changelog
--- konfont-0.1/debian/changelog
+++ konfont-0.1/debian/changelog
@@ -1,3 +1,10 @@
+konfont (0.1-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999195).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 11:56:46 -0300
+
 konfont (0.1-8.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u konfont-0.1/debian/rules konfont-0.1/debian/rules
--- konfont-0.1/debian/rules
+++ konfont-0.1/debian/rules
@@ -58,4 +58,8 @@
 binary-arch: build install
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#999164: ipfm: diff for NMU version 0.11.5-4.3

[Marcos Talau]

Control: tags 999164 + patch
Control: tags 999164 + pending


Dear maintainer,

I've prepared an NMU for ipfm (versioned as 0.11.5-4.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru ipfm-0.11.5/debian/changelog ipfm-0.11.5/debian/changelog
--- ipfm-0.11.5/debian/changelog	2016-06-27 08:59:36.0 -0300
+++ ipfm-0.11.5/debian/changelog	2022-11-03 11:53:05.0 -0300
@@ -1,3 +1,10 @@
+ipfm (0.11.5-4.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999164).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 11:53:05 -0300
+
 ipfm (0.11.5-4.2) unstable; urgency=low
 
   * Non-maintainer upload to solve release goal and fix RC bug.
diff -Nru ipfm-0.11.5/debian/rules ipfm-0.11.5/debian/rules
--- ipfm-0.11.5/debian/rules	2016-06-27 08:46:10.0 -0300
+++ ipfm-0.11.5/debian/rules	2022-11-03 11:53:05.0 -0300
@@ -85,4 +85,8 @@
 	@echo >&2 'source and diff are obsolete - use dpkg-source -b'; false
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary

Bug#998952: ink-generator: diff for NMU version 0.4-2.2

[Marcos Talau]

Control: tags 998952 + patch
Control: tags 998952 + pending


Dear maintainer,

I've prepared an NMU for ink-generator (versioned as 0.4-2.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u ink-generator-0.4/debian/changelog ink-generator-0.4/debian/changelog
--- ink-generator-0.4/debian/changelog
+++ ink-generator-0.4/debian/changelog
@@ -1,3 +1,10 @@
+ink-generator (0.4-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998952).
+
+ -- Marcos Talau   Thu, 03 Nov 2022 11:49:01 -0300
+
 ink-generator (0.4-2.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u ink-generator-0.4/debian/rules ink-generator-0.4/debian/rules
--- ink-generator-0.4/debian/rules
+++ ink-generator-0.4/debian/rules
@@ -27,4 +27,7 @@
 	dh_md5sums
 	dh_builddeb
 
-.PHONY: clean build install binary binary-arch binary-indep
+build-arch: build
+build-indep: build
+
+.PHONY: clean build build-arch build-indep install binary binary-arch binary-indep

Bug#1023410: rtl8723bt-firmware: Missing firmware for the rtl8723ds

[Isaac True]

Package: rtl8723bt-firmware
Version: 20181104-1
Severity: wishlist
X-Debbugs-Cc: isaac.t...@canonical.com

Dear Maintainer,

The rtl8723ds is a chip in the same family as the other Bluetooth adapters
supported by this package which requires a different set of firmware binaries.

The firmware binaries are available from the following GitHub repository:
https://github.com/armbian/firmware/tree/master/rtl_bt

According to the WHENCE file in the package, the existing firmware files were
also sourced from this repository.

However it's not fully clear if these firmware files fall under the same
license as the existing rtl_bt files, as there is no license information
in the Armbian firmware repository. Do you have any information about
where the license for the existing firmware files came from, and if the
others are covered under the same license?

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

Kernel: Linux 5.15.0-52-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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