Bug#1050683: pep517: Should not be released with Trixie

[Scott Kitterman]

Source: pep517
Severity: serious
Justification: Maintainer opinion

This package has been replace by python-pyproject-hooks and should not
be in Trixie.

Scott K

Bug#918914: Enabling -fstack-clash-protection for trixie

[Guillem Jover]

Hi!

On Sun, 2023-08-06 at 23:25:23 +0200, Moritz Mühlenhoff wrote:
> Following the procedure to modify default dpkg-buildflags I propose to
> enable -fstack-clash-protection on amd64. The bug for dpkg tracking this
> is #918914.
> 
> | -fstack-clash-protection
> | Generate code to prevent stack clash style attacks. When this option
> | is enabled, the compiler will only allocate one page of stack space
> | at a time and each page is accessed immediately after allocation.
> | Thus, it prevents allocations from jumping over any stack guard page
> | provided by the operating system.
> 
> This has been enabled on other distros for many years already (e.g.
> Fedora since 27, RHEL since 8, OpenSUSE since 15.1, Ubuntu since 19.10).
> 
> I worked with Lucas a while back and he made an archive rebuild on amd64,
> only a minimal list of packages will need to be adapted:
> http://qa-logs.debian.net/2023/05/24/
> 
> The open question is whether to also enable this for arm64, mips64el,
> ppc64el, riscv and s390x. I'm adding the respective porter lists, if there's
> consensus among porters of a given arch other than amd64 to also add
> the flag, please post a followup to #918914.

Given the results from the rebuilds for amd64 and arm64 with minimal
fallout, and no complaints, I'm going to enable this for amd64 and the
three arm arches (arm64, armhf and armel) with dpkg 1.22.0, to be
uploaded later today. We can later on modify the set of architectures
(by request from porters) or tune them if it ends up causing problems.

Thanks,
Guillem

Bug#1050682: WiFi stopped working

[Daniel]

Package: firmware-ath9k-htc
Version: 1.4.0-108-gd856466+dfsg1-1.4

In a recent upgrade, firmware-ath9k-htc has been installed
and firmware-atheros has been removed, after a system reboot my WiFi
stopped working. To fix it I had to download and reinstall firmware-atheros.

lspci shows
Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless Network
Adapter (rev 31)

I'm using Linux debian 6.4.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.11-1
(2023-08-17) x86_64 GNU/Linux

Bug#992918: re: gwenview: fails to save jpg/jpeg image

[Fufu Fang]

I got home, and followed Ian's suggestion, and removed "*.jfif" from
the top of the list. The problem is now resolved. 

Bug#1050681: bookworm-pu: package inn2/2.7.1-1~deb12u1

[Marco d'Itri]

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

This stable upload contains two patches backported from the upstream 
repository on request of the upstream maintainer.
The patches are also part of the package which is currently in testing.

One patch fixes hangs in nnrpd, while the other allows the package to 
process the high-precision syslog timestamps format which is currently 
the default for Debian.

The package also contains a minor security fix which changes the default 
permissions of two configuration files which contain secrets, which has 
already been added to the next unstable upload.

For a better view of the changes please see
https://salsa.debian.org/md/inn2/-/commits/bookworm .

-- 
ciao,
Marco
diff -Nru inn2-2.7.1/debian/changelog inn2-2.7.1/debian/changelog
--- inn2-2.7.1/debian/changelog	2023-05-01 19:25:42.0 +0200
+++ inn2-2.7.1/debian/changelog	2023-08-28 02:04:59.0 +0200
@@ -1,3 +1,13 @@
+inn2 (2.7.1-1~deb12u1) bookworm; urgency=medium
+
+  * Added patch backport_a1f2e9323: this upstream commit fixes nnrpd hangs
+when compression is enabled.
+  * Added patch backport_f7d111aad: this upstream commit adds support for
+high-precision syslog timestamps which now are the default in Debian.
+  * Made inn-{radius,secrets}.conf not world readable.
+
+ -- Marco d'Itri   Mon, 28 Aug 2023 02:04:59 +0200
+
 inn2 (2.7.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru inn2-2.7.1/debian/patches/backport_a1f2e9323 inn2-2.7.1/debian/patches/backport_a1f2e9323
--- inn2-2.7.1/debian/patches/backport_a1f2e9323	1970-01-01 01:00:00.0 +0100
+++ inn2-2.7.1/debian/patches/backport_a1f2e9323	2023-08-28 02:04:59.0 +0200
@@ -0,0 +1,154 @@
+From: Enrik Berkhan 
+Subject: nnrpd: avoid hang due to misplaced select()
+Origin: upstream, commit:a1f2e932338a17eb4111243f29fcade52d39e0a7
+
+The select() call in nnrpd's input data processing is moved right
+before the related read() call to avoid blocking when it shouldn't.
+
+Without this change, there could still remain data to be inflated, that
+has already been read, if compression had been activated.  The select()
+can then time out because the client might already have sent all data
+before, and the yet to be inflated data will not be used until after
+the timeout.
+
+Resolves: #269
+
+diff --git a/nnrpd/line.c b/nnrpd/line.c
+index fc68b15dd..6c048720c 100644
+--- a/nnrpd/line.c
 b/nnrpd/line.c
+@@ -79,12 +79,11 @@ line_reset(struct line *line)
+ }
+ 
+ /*
+-**  Timeout is used only if HAVE_OPENSSL is defined.
+ **  Returns -2 on timeout, -1 on read error, and otherwise the number of
+ **  bytes read.
+ */
+ static ssize_t
+-line_doread(void *p, size_t len, int timeout UNUSED)
++line_doread(void *p, size_t len, int timeout)
+ {
+ ssize_t n;
+ 
+@@ -122,6 +121,22 @@ line_doread(void *p, size_t len, int timeout UNUSED)
+ }
+ #endif /* HAVE_ZLIB */
+ 
++/* It seems that the SSL_read cannot be mixed with select()
++ * as in the current code.  TLS communicates in its own data
++ * blocks and handshaking.  The line_doread using SSL_read
++ * could return, but still with a partial line in the SSL_read
++ * buffer.  Then the server TLS routine would sit there waiting
++ * for completion of that data block while nnrpd sat at the
++ * select() routine waiting for more data from the server.
++ *
++ * Here, we decide to just bypass the select() wait.  Unlike
++ * innd with multiple threads, the select on nnrpd is just
++ * waiting on a single file descriptor, so it is not really
++ * essential with blocked read like SSL_read.  Using an alarm
++ * signal around SSL_read for non active timeout, TLS works
++ * without dead locks.  However, without the select() wait,
++ * the IDLE timer stat won't be collected...
++ */
+ #ifdef HAVE_OPENSSL
+ if (tls_conn) {
+ int err;
+@@ -152,9 +167,38 @@ line_doread(void *p, size_t len, int timeout UNUSED)
+ xsignal(SIGALRM, SIG_DFL);
+ } else
+ #endif /* HAVE_OPENSSL */
++{
++fd_set rmask;
++int i;
++
++/* Wait for activity on stdin, updating timer stats as we go. */
++do {
++struct timeval t;
++
++FD_ZERO();
++FD_SET(STDIN_FILENO, );
++t.tv_sec = timeout;
++t.tv_usec = 0;
++TMRstart(TMR_IDLE);
++i = select(STDIN_FILENO + 1, , NULL, NULL, );
++TMRstop(TMR_IDLE);
++if (i == -1 && errno != EINTR) {
++syswarn("%s can't select", Client.host);
++break;
++}
++} while (i == -1);
++
++/* If stdin 

Bug#1050680: yubikey-luks: Depends on removed package cryptsetup-run

[Guilhem Moulin]

On Mon, 28 Aug 2023 at 01:56:04 +0200, Guilhem Moulin wrote:
> cryptsetup-run has been a transitional package since the buster release,
> and has now been removed following #1038285.  Looks like I failed to
> properly check reverse depends; yubikey-luks should replace ‘Depends:
> cryptsetup-run’ with ‘Depends: cryptsetup’.

Uploaded the attached debdiff to DELAYED/7.

-- 
Guilhem.
diffstat for yubikey-luks-0.5.1+29.g5df2b95 yubikey-luks-0.5.1+29.g5df2b95

 changelog |8 
 control   |2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff -Nru yubikey-luks-0.5.1+29.g5df2b95/debian/changelog 
yubikey-luks-0.5.1+29.g5df2b95/debian/changelog
--- yubikey-luks-0.5.1+29.g5df2b95/debian/changelog 2022-10-15 
12:58:53.0 +0200
+++ yubikey-luks-0.5.1+29.g5df2b95/debian/changelog 2023-08-28 
01:59:49.0 +0200
@@ -1,3 +1,11 @@
+yubikey-luks (0.5.1+29.g5df2b95-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace ‘Depends: cryptsetup-run’ with ‘Depends: cryptsetup’ as
+src:cryptsetup no longer ships the former (Closes: #1050680)
+
+ -- Guilhem Moulin   Mon, 28 Aug 2023 01:59:49 +0200
+
 yubikey-luks (0.5.1+29.g5df2b95-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru yubikey-luks-0.5.1+29.g5df2b95/debian/control 
yubikey-luks-0.5.1+29.g5df2b95/debian/control
--- yubikey-luks-0.5.1+29.g5df2b95/debian/control   2021-01-02 
17:38:35.0 +0100
+++ yubikey-luks-0.5.1+29.g5df2b95/debian/control   2023-08-28 
01:59:43.0 +0200
@@ -13,7 +13,7 @@
 
 Package: yubikey-luks
 Architecture: all
-Depends: cryptsetup-run, initramfs-tools, yubikey-personalization (>= 1.5), 
${misc:Depends}
+Depends: cryptsetup, initramfs-tools, yubikey-personalization (>= 1.5), 
${misc:Depends}
 Recommends: cryptsetup-initramfs, expect
 Description: YubiKey two factor authentication for LUKS disks
  With this extension to the initramfs-tools, you can unlock a LUKS encrypted


signature.asc
Description: PGP signature

Bug#1050680: yubikey-luks: Depends on removed package cryptsetup-run

[Guilhem Moulin]

Source: yubikey-luks
Version: 0.5.1+29.g5df2b95-6.1
Severity: serious

Hi,

cryptsetup-run has been a transitional package since the buster release,
and has now been removed following #1038285.  Looks like I failed to
properly check reverse depends; yubikey-luks should replace ‘Depends:
cryptsetup-run’ with ‘Depends: cryptsetup’.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1038285: please drop transitional package cryptsetup-run from src:cryptsetup

[Luca Boccassi]

On Fri, 16 Jun 2023 18:45:41 +0200 Holger Levsen
 wrote:
> Package: cryptsetup-run
> Version: 2:2.6.1-4
> Severity: normal
> user: qa.debian@packages.debian.org
> usertags: transitional
> 
> Please drop the transitional package cryptsetup-run (from the source
package 
> cryptsetup) for trixie, as it has been released with bullseye and
bookworm 
> already.
> 
> 
> Description: transitional dummy package for cryptsetup
> Package: cryptsetup-run
> Version: 2:2.6.1-4
> 
> Thanks for maintaining cryptsetup!

It looks like there was still one package depending on cryptsetup-run?
https://packages.debian.org/sid/yubikey-luks

-- 
Kind regards,
Luca Boccassi


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

Bug#1050677: Issue 1475278

[Adnane Tidghi]

Just clarifying that issue 1475278 is in bugs.chromium.org not Debian's
tracker

Bug#1050679: Acknowledgement (golang-github-twstrike-gotk3adapter: Unnecessary build dependency libgio-cil)

[Bastian Germann]

I am uploading a NMU in order to fix this. The debdiff is atached.diff -Nru 
golang-github-twstrike-gotk3adapter-0.0~git20170505.0.901a95d+ds/debian/changelog
 
golang-github-twstrike-gotk3adapter-0.0~git20170505.0.901a95d+ds/debian/changelog
--- 
golang-github-twstrike-gotk3adapter-0.0~git20170505.0.901a95d+ds/debian/changelog
   2021-01-09 12:29:24.0 +0100
+++ 
golang-github-twstrike-gotk3adapter-0.0~git20170505.0.901a95d+ds/debian/changelog
   2023-08-28 00:58:49.0 +0200
@@ -1,3 +1,10 @@
+golang-github-twstrike-gotk3adapter (0.0~git20170505.0.901a95d+ds-3.2) 
unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop libgio-cil from Build-Depends. (Closes: #1050679)
+
+ -- Bastian Germann   Mon, 28 Aug 2023 00:58:49 +0200
+
 golang-github-twstrike-gotk3adapter (0.0~git20170505.0.901a95d+ds-3.1) 
unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru 
golang-github-twstrike-gotk3adapter-0.0~git20170505.0.901a95d+ds/debian/control 
golang-github-twstrike-gotk3adapter-0.0~git20170505.0.901a95d+ds/debian/control
--- 
golang-github-twstrike-gotk3adapter-0.0~git20170505.0.901a95d+ds/debian/control 
2018-07-04 17:24:14.0 +0200
+++ 
golang-github-twstrike-gotk3adapter-0.0~git20170505.0.901a95d+ds/debian/control 
2023-08-28 00:58:22.0 +0200
@@ -11,7 +11,6 @@
libcairo2-dev,
libpango1.0-dev,
libgtk-3-dev,
-   libgio-cil,
xvfb,
xauth
 Standards-Version: 4.1.4

Bug#1050677: Mitigation seems like working but really it does not

[Adnane Tidghi]

Dear Maintainer,

Using The flag --enable-features=VaapiVideoDecodeLinuxGL seems to list
all codecs as hardware accelerated but they aren't. intel_gpu_top
reports Video/0 engine usage at 0.00%, so I think the bug exists.

Best regards,

Bug#1031086: piupart: fails in many packages for /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service not owned that is not related to package tested

[Manphiz]

I've been dealing with similar spurious error of piuparts when testing
some packages that it reports that package purging left files on system:

,
| 0m45.6s ERROR: FAIL: Package purging left files on system:
|   /etc/default/locale -> ../locale.conf  not owned
|   /etc/vconsole.conf -> default/keyboard not owned
|   /root/.ssh/not owned
|   /var/cache/private/not owned
|   /var/lib/private/  not owned
|   /var/lib/systemd/coredump/ not owned
|   /var/lib/systemd/ephemeral-trees/  not owned
|   /var/lib/systemd/pstore/   not owned
|   /var/log/private/  not owned
| 
| 0m45.6s ERROR: FAIL: Installation and purging test.
`

Full piuparts log attached.

Wondering what is the rational to check not-owned files?  Is it safe to
just ignore them in piuparts?

+--+
| Post Build   |
+--+


piuparts


0m0.0s INFO: 
--
0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of 
this logfile.
0m0.0s INFO: FAQ available at https://wiki.debian.org/piuparts/FAQ
0m0.0s INFO: The FAQ also explains how to contact us in case you think piuparts 
is wrong.0m0.0s INFO: 
--
0m0.0s INFO: piuparts version 1.1.7 starting up.
0m0.0s INFO: Command line arguments: /usr/sbin/piuparts --schroot 
unstable-amd64-sbuild --no-eatmydata 
/home/xiyueden/Projects/debian-devel/build-area/emacs-buttercup_1.31-1_amd64.changes
0m0.0s INFO: Running on: Linux debian-hx90 6.1.0-11-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08) x86_64
0m0.0s DEBUG: Starting command: ['dpkg', '--info', 
'/home/xiyueden/Projects/debian-devel/build-area/elpa-buttercup_1.31-1_all.deb']
0m0.0s DUMP: 
   new Debian package, version 2.0.
   size 44500 bytes: control archive=1400 bytes.
   786 bytes,19 lines  control  
  1192 bytes,14 lines  md5sums  
   435 bytes, 9 lines   *  postinst #!/bin/sh
   298 bytes, 7 lines   *  prerm#!/bin/sh
   Package: elpa-buttercup
   Source: emacs-buttercup
   Version: 1.31-1
   Architecture: all
   Maintainer: Debian Emacsen team 
   Installed-Size: 162
   Depends: dh-elpa-helper, emacsen-common, emacs (>= 1:28.2+1-9)
   Enhances: emacs
   Section: lisp
   Priority: optional
   Homepage: https://github.com/jorgenschaefer/emacs-buttercup/
   Description: behaviour-driven testing for Emacs Lisp packages
Buttercup is a behavior-driven development framework for testing
Emacs Lisp code. It allows the programmer to group related tests so
they can share common set-up and tear-down code, and it allows the
programmer to spy on functions to ensure they are called with the
right arguments during testing.
.
The testing framework is inspired by the Jasmine JavaScript test framework.
0m0.0s DEBUG: Command ok: ['dpkg', '--info', 
'/home/xiyueden/Projects/debian-devel/build-area/elpa-buttercup_1.31-1_all.deb']
0m0.0s DEBUG: Starting command: ['schroot', '--begin-session', '--chroot', 
'unstable-amd64-sbuild', '--session-name', 
'unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts']
0m0.1s DUMP: 
  unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts
0m0.1s DEBUG: Command ok: ['schroot', '--begin-session', '--chroot', 
'unstable-amd64-sbuild', '--session-name', 
'unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts']
0m0.1s DEBUG: Starting command: ['schroot', '--chroot', 
'session:unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts', 
'--location']
0m0.1s DUMP: 
  
/var/run/schroot/mount/unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts
0m0.1s DEBUG: Command ok: ['schroot', '--chroot', 
'session:unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts', 
'--location']
0m0.1s INFO: New schroot session in 
'/var/run/schroot/mount/unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts'
0m0.1s DEBUG: sources.list:
  deb https://deb.debian.org/debian/ sid main
  deb https://deb.debian.org/debian/ sid contrib
  deb https://deb.debian.org/debian/ sid non-free
  deb https://deb.debian.org/debian/ sid non-free-firmware
0m0.1s DEBUG: Created policy-rc.d and chmodded it.
0m0.1s DEBUG: Created resolv.conf.
0m0.1s DEBUG: Starting command: ['schroot', '--preserve-environment', 
'--run-session', '--chroot', 
'session:unstable-amd64-sbuild-4fab0f3e-44dd-11ee-a063-1c834129f55e-piuparts', 
'--directory', '/', '-u', 'root', '--', 'apt-get', 'update']
0m2.9s DUMP: 
  Get:1 https://deb.debian.org/debian sid InRelease [210 kB]
  Get:2 https://deb.debian.org/debian sid/main amd64 Packages [9568 kB]
  Get:3 

Bug#1050677: Fix/Mitigation from Chromium Bug Tracker

[Adnane Tidghi]

Dear Maintainer,

As In Issue 1475278, the problem seems across all linux distributions.

Adding --enable-features=VaapiVideoDecodeLinuxGL to the list of flags
seems to resolve (or mitigate) this problem.

So this version (and possibly every release in the future) will require
this flag for achieving video acceleration if they don't revert this
behavior.

P.S: It seems like (possibly) it wasn't right to report this bug really
fast without much. I posted this in the hope that it will be helpful.

Best regards,

Bug#1050679: golang-github-twstrike-gotk3adapter: Unnecessary build dependency libgio-cil

[Bastian Germann]

Source: golang-github-twstrike-gotk3adapter
Severity: minor
Version: 0.0~git20170505.0.901a95d+ds-3.1

libgio-cil is a C# library and not even its development package.
There is no reason to have this in a go package so please drop it.

Bug#1050001: Unwinding directory aliasing [and 3 more messages]

[Luca Boccassi]

On Sun, 27 Aug 2023 at 11:30, Matthew Vernon  wrote:
>
> Dear Luca,
>
> On 27/08/2023 03:16, Luca Boccassi wrote:
>
> [things]
>
> You've already been asked by a couple of people to moderate your tone in
> this thread. I appreciate there is a lot of frustration around
> /usr-merge, but your contributions are not helping with that at all. Nor
> do they help us have a constructive discussion.

Constructive discussions about past events need to be based on facts
and evidence. Both are conspicuously absent from the bug submitter's
messages. Without any of that, there was never any possibility that
this bug could be in any way constructive since the  moment it was
opened, long before I first replied.

> The DEP-17 work continues whilst this discussion is ongoing; this
> discussion is not delaying that work.
>
> I think it is fair to say that when ctte decided on /usr-merge it was
> expected that a) the process would be reasonably straightforward and b)
> dpkg could be taught to understand directory aliasing, so we would not
> have to be doing things "behind dpkg's back", as it were.

Sure, but then it turned out that package maintainers are not only
allowed to ignore the CTTE and its formal decisions, but can also
actively block them in their packages. How could responsibility of
that be assigned to anybody but those who chose to do that completely
eludes me - and yet, that's exactly what the bug submitter does.

> I think the need for a releases-long moratorium on moving files and the
> volume and depth of technical work represented by DEP17 demonstrate that
> those expectations turned out not to be met.
>
> Given that, it seems to me that a) warnings that "it's not that simple &
> easy" were not FUD and describing them thus is unhelpful b) it's
> reasonable to at least ask the question "given what we know now, are we
> still sure this is the correct approach?"

a) except that warnings weren't as mild and meek as "it's not that
simple", we were clearly told everything would break left and right,
and yet that didn't happen. Sure, dpkg has annoying bugs that need
workarounds, but that's hardly surprising given its situation. But
these are all packaging-only issues that affect some distribution
maintainers for some package builds and maintenance tasks, and that's
about it. No installation is affected. No user is affected. No
external/third party developer is affected. So, yes, all of that was
and still is FUD.
b) no, in August 2023 it is very much not reasonable, and no fully
informed and evidence-based good faith discussion would ever ask
something like that. The reasonable questions to ask in August 2023
are along the lines of "what's the best way to work around those dpkg
bugs and lift the moratorium?", which is what we are doing in actual
good faith discussions elsewhere, with very productive results.

> Any such consideration must be mindful of the fact that the majority of
> Debian installs are now /usr-merged, which means that the complexity of
> unwinding such installs has to be a heavy factor in thinking about
> alternative approaches.
>
> I'm hopeful, but not certain, that the DEP17 work will get us to a
> coherent state again by foxy (which still feels a long time off); I
> don't think we should underestimate the work to be done in properly
> completing /usr-merge.
>
> This discussion has, I think, been broadly useful in clarifying some
> folks' thinking in this area. I would very much like if we could keep it
> focused on the technical matters.

I honestly cannot see how there can be any useful technical discussion
about a completely evidence-free proposal to move to a symlinks-farm
layout in 2023, with all the already well-known wider context that has
been explained multiple times. The useful and productive and
high-quality technical discussions are happening elsewhere.

Bug#1050678: rust-async-process - update for new rustix.

[Peter Michael Green]

Package: rust-async-process
Version: 1.7.0-2

I'm preparing an update for rustix, it's a new semver but so-far everything
seems to build with just the dependency bumped. I've uploaded it to 
experimental.
and assuming no showstoppers show up I hope to re-upload it to 
experimental soon.


I have prepared a patch for this package, are you ok if I just NMU it at 
the same time
as I'm uploading the rest of the reverse dependencies or do you want to 
handle the

update yourself?

diff -Nru rust-async-process-1.7.0/debian/changelog 
rust-async-process-1.7.0/debian/changelog
--- rust-async-process-1.7.0/debian/changelog   2023-08-14 10:57:58.0 
+
+++ rust-async-process-1.7.0/debian/changelog   2023-08-27 19:54:23.0 
+
@@ -1,3 +1,10 @@
+rust-async-process (1.7.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch to bump rustix dependency.
+
+ -- Peter Michael Green   Sun, 27 Aug 2023 19:54:23 +
+
 rust-async-process (1.7.0-2) unstable; urgency=medium
 
   * update dh-cargo fork;
diff -Nru rust-async-process-1.7.0/debian/control 
rust-async-process-1.7.0/debian/control
--- rust-async-process-1.7.0/debian/control 2023-07-16 09:41:54.0 
+
+++ rust-async-process-1.7.0/debian/control 2023-08-27 19:52:22.0 
+
@@ -12,8 +12,8 @@
  librust-futures-lite-1+default-dev ,
  librust-async-io-1+default-dev ,
  librust-libc-0.2+default-dev ,
- librust-rustix-0.37+fs-dev ,
- librust-rustix-0.37+std-dev ,
+ librust-rustix-0.38+fs-dev ,
+ librust-rustix-0.38+std-dev ,
  librust-signal-hook-0.3+iterator-dev ,
  libstring-shellquote-perl,
 Maintainer: Jonas Smedegaard 
@@ -34,8 +34,8 @@
  librust-futures-lite-1+default-dev,
  librust-async-io-1+default-dev,
  librust-libc-0.2+default-dev,
- librust-rustix-0.37+fs-dev,
- librust-rustix-0.37+std-dev,
+ librust-rustix-0.38+fs-dev,
+ librust-rustix-0.38+std-dev,
  librust-signal-hook-0.3+iterator-dev,
  ${misc:Depends},
 Provides:
diff -Nru rust-async-process-1.7.0/debian/patches/0001_update-rustix.patch 
rust-async-process-1.7.0/debian/patches/0001_update-rustix.patch
--- rust-async-process-1.7.0/debian/patches/0001_update-rustix.patch
1970-01-01 00:00:00.0 +
+++ rust-async-process-1.7.0/debian/patches/0001_update-rustix.patch
2023-08-27 19:49:35.0 +
@@ -0,0 +1,26 @@
+commit 171561685961330d561e660d8608f230f6a208f1
+Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
+Date:   Sun Jul 2 19:05:21 2023 -0700
+
+m: Update rustix requirement from 0.37 to 0.38
+
+Updates the requirements on 
[rustix](https://github.com/bytecodealliance/rustix) to permit the latest 
version.
+- [Release notes](https://github.com/bytecodealliance/rustix/releases)
+- 
[Commits](https://github.com/bytecodealliance/rustix/compare/v0.37.0...v0.38.2)
+
+---
+updated-dependencies:
+- dependency-name: rustix
+  dependency-type: direct:production
+...
+
+Signed-off-by: dependabot[bot] 
+Co-authored-by: dependabot[bot] 
<49699333+dependabot[bot]@users.noreply.github.com>
+
+diff --git a/Cargo.toml b/Cargo.toml
+index c42a1db..7963bdd 100644
+--- a/Cargo.toml
 b/Cargo.toml
+@@ -26,1 +26,1 @@ futures-lite = "1.11.0"
+-rustix = { version = "0.37", default-features = false, features = ["std", 
"fs"] }
++rustix = { version = "0.38", default-features = false, features = ["std", 
"fs"] }
diff -Nru rust-async-process-1.7.0/debian/patches/series 
rust-async-process-1.7.0/debian/patches/series
--- rust-async-process-1.7.0/debian/patches/series  2023-07-04 
08:20:52.0 +
+++ rust-async-process-1.7.0/debian/patches/series  2023-08-27 
19:41:57.0 +
@@ -1 +1,2 @@
+0001_update-rustix.patch
 2001_windows.patch

Bug#1042361: RFS: texlive-bin/2023.20230311.66589-3 -- TeX Live: Package split

[Preuße]

Control: tags -1 + moreinfo

On 27.07.2023 00:17, Hilmar Preusse wrote:

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "texlive-bin":

  * Package name : texlive-bin
Version  : 2023.20230311.66589-3
Upstream contact : k...@freefriends.org
  * URL  : https://www.tug.org/texlive/
  * License  : MIT, TeX-Live, GPL-2+
  * Vcs  : https://github.com/debian-tex/texlive-bin
Section  : tex



I'm using the -3 to push everything to unstable. I tag the bug moreinfo 
for now.


H.
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Gunnar Hjalmarsson]

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

Thanks for your report!

Tollef Fog Heen wrote:

With commit 0fb34101788d84e9a1d98b3730cc7b9295e0f19b in
xkeyboard-config, `group(alts_toggle)` changed behaviour in a way
such that the right alt no longer generates altgr.


Apparently the purpose of the change was to make the "Both Alts" 
shortcut work again, after a long period when it didn't work.


https://salsa.debian.org/xorg-team/data/xkeyboard-config/-/commit/0fb34101

And in a working state, I'm not surprised to hear that "Both Alts" 
conflicts with the use of Right Alt for accessing 3rd and 4th level symbols.


I can't help asking why you set the "group(alts_toggle)" option at all. 
You don't seem to use any other keyboard layout but Norwegian anyway. So 
even before you have answered, my advice would be to just drop that 
option wherever you set it and move on. ;)


In any case the issue is not severity "serious", especially not in a 
Debian distro context.


--
Regards,
Gunnar Hjalmarsson

Bug#1050516: checkit-tiff: FTBFS on big-endian platforms

[Andreas Romeyke]

Hi,

On Fri, 25 Aug 2023 17:39:39 +0200
Bastian Germann  wrote:

> Source: checkit-tiff
> Severity: serious
> X-Debbugs-Cc: a...@andreas-romeyke.de, oltma...@zib.de
> 
> The new checkit-tiff upstream version 1.4.3 does not build on
> big-endian platforms. Note: it was updated from 0.4.2, so the issue
> is not necessarily only in 1.4.3. You can get logs at
> https://buildd.debian.org/status/package.php?p=checkit-tiff
> 
> The issue triggers multiple times on running the test suite and ends
> up: "(HE)TIFF Header error, not a MAGIC BYTE for TIFF: 0x2a00"

There is a new v1.4.4 release which should fix the big-endian issues.
Sucessfully tested with m68k-linux-gnu-gcc, see file 'FAQ'. Not tested
with ICC proflib.

See https://git.fsfe.org/art1pirat/checkit_tiff/releases for a short
summary of the release.

Please do not hesitate to contact me, if you detect further bugs.

With best regards

Andreas

-- 
Dipl. Inf. (FH) Andreas Romeyke, http://andreas-romeyke.de/


pgpzuRQCwaTqn.pgp
Description: Digitale Signatur von OpenPGP

Bug#1042912: Merge the Debian-specific desktop file with the upstream one

[Amr Ibrahim]

Upstream desktop file in version 115.1.1:

https://salsa.debian.org/mozilla-team/thunderbird/-/blob/debian/sid/comm/taskcluster/docker/tb-flatpak/org.mozilla.Thunderbird.desktop

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Alexandru Mihail]

Hello Nicholas,



> They're about the same for me.  Honestly I'd prefer to do a git
upload
> at this time, and save the GPG key discussion for your next upload. 
> We can use dput and mentors then, and I think we'll both agree that 
> we've both worked hard enough for this first upload haha.

Indeed, it was quite a lot of work, but it is for a good cause ! :)


> At this point, please do a "dch -r" and ensure that the changelog
entry
> is refinalised; this will update the date stamp.  Hint: you may have
to
> make do a noop edit like + to make this work
properly.
> Commit the new changelog entry with a message like:
> And push that to the remote we're using for your MR.  Then make an
> annotated and optionally GPG signed tag.  I like to use "gbp tag" for
> this, but you can use whatever method you prefer.  Please make sure 
> the annotated tag is on the master branch and not a detached head.  
> Let me know, and I'll review, and upload when everything looks good,
> as it no doubt will.

I've commited and pushed the changes to the remote I was using for the
MR so far:
commit:
https://salsa.debian.org/alexandru_mihail/mini-httpd/-/commit/fc7c4f664dc1369b1bf5d46c8c9b7aa11de68407


But I think I may have not commited where I was supposed to, granted
you've already closed the MR. I've already created a GPG signed tag
accessible at:
https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4

The commit is not visible in the previous MR:
https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2?

Is there something I've glanced over here ?
Otherwhise, the commit & tag are per your requirements.

> Cheers,
> Nicholas

Have a great day !
Alexandru Mihail



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

Bug#806699: lxc: Confusion about default log output

[Mathias Gibbens]

Control: tags -1 + moreinfo

Hi Matthijs,

  I sorry that no one ever responded to your bug. I did confirm today
that the documentation and behavior of lxc seems unchanged from your
initial report.

  If this is still a concern of yours, please open a bug report on the
lxc github, as that would be the appropriate place to make changes to
lxc's logging behavior. If you do, we can link this bug to that report;
otherwise barring any other strong reason to keep this bug open I think
it can be closed as there's nothing to be done on Debian's end.

Mathias


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

Bug#964082: parsinsert fails it's tests when built with -O2 gcc-13

[Étienne Mollier]

Étienne Mollier, on 2023-08-26:
>   After suspecting hardening, it turned out
> that the following, when combined with build of ParsInsert.o
> with -O2 optimization, is causing the test failure:
> 
>   -specs=/usr/share/dpkg/no-pie-compile.specs

Rerunning these tests in a properly isolate chroot show me that
the hardening is also contributing to the improper results.
Hardening must be disabled and PIE must be enforced to ensure
the program runs appropriately 

 -O1  -O2   -O3
-fPIE + no hardening  OK   OKOK
-fno-PIE + no hardening   OK  FAIL  FAIL
-fPIE + hardening OK  FAIL  FAIL
-fno-PIE + hardening  OK  FAIL  FAIL

I'm considering pushing an upload that goes in the direction of
disabling hardening and enforcing PIE in the upcoming week,
unless there are reasons to hold on, or someone is faster than
me in uploading.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-on air: Dream Theater - Scene Three: II. Fatal Tragedy


signature.asc
Description: PGP signature

Bug#980819: g3data: Wrong homepage + new version

[Bastian Germann]

Control: retitle -1 g3data: new version

I am fixing the Homepage with the next revision.

Bug#1050677: chromium: VAAPI acceleration not working on Chromium 116

[adnane]

Package: chromium
Version: 116.0.5845.110-1~deb11u1
Severity: normal
X-Debbugs-Cc: adnane.tidghi...@gmail.com

Dear Maintainer,


   * What led up to the situation?
-Upgrading Chromium 115 to Chromium 116.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
-Tested that video acceleration is working with VLC (it works).
-The output of vainfo returns all functions supported by the driver (i915).
-Installed suggested packages chromium-driver and chromium-shell.
 
  * What was the outcome of this action?
-Concluding that video acceleration still working and proposing that the issue 
might be with Chromium.

   * What outcome did you expect instead?
-Working video acceleration in Chromium as it does in VLC and ffmpeg.


I wrote this bug report in the hope that it will be helpful to fix this minor 
bug (if it exists).


Best regards,



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

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

Versions of packages chromium depends on:
ii  chromium-common116.0.5845.110-1~deb11u1
ii  libasound2 1.2.4-1.1
ii  libatk-bridge2.0-0 2.38.0-1
ii  libatk1.0-02.36.0-2
ii  libatomic1 10.2.1-6
ii  libatspi2.0-0  2.38.0-4+deb11u1
ii  libbrotli1 1.0.9-2+b2
ii  libc6  2.31-13+deb11u6
ii  libcairo2  1.16.0-5
ii  libcups2   2.3.3op2-3+deb11u2
ii  libdbus-1-31.12.24-0+deb11u1
ii  libdouble-conversion3  3.1.5-6.1
ii  libdrm22.4.104-1
ii  libevent-2.1-7 2.1.12-stable-1
ii  libexpat1  2.2.10-2+deb11u5
ii  libflac8   1.3.3-2+deb11u1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1+deb11u1
ii  libgbm120.3.5-1
ii  libgcc-s1  10.2.1-6
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u3
ii  libjpeg62-turbo1:2.0.6-4
ii  libjsoncpp24   1.9.4-4
ii  liblcms2-2 2.12~rc1-2
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.29-1
ii  libnss32:3.61-1+deb11u3
ii  libopenjp2-7   2.4.0-3
ii  libopus0   1.3.1-0.1
ii  libpango-1.0-0 1.46.2-3
ii  libpng16-161.6.37-3
ii  libpulse0  14.2-2
ii  libsnappy1v5   1.1.8-1
ii  libstdc++6 10.2.1-6
ii  libwebp6   0.6.1-2.1+deb11u1
ii  libwebpdemux2  0.6.1-2.1+deb11u1
ii  libwebpmux30.6.1-2.1+deb11u1
ii  libwoff1   1.0.2-1+b1
ii  libx11-6   2:1.7.2-1+deb11u1
ii  libxcb11.14-3
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.5-2
ii  libxext6   2:1.3.3-1.1
ii  libxfixes3 1:5.0.3-2
ii  libxkbcommon0  1.0.3-2
ii  libxml22.9.10+dfsg-6.7+deb11u4
ii  libxnvctrl0470.141.03-1~deb11u1
ii  libxrandr2 2:1.5.1-1
ii  libxslt1.1 1.1.34-4+deb11u1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backen  1.8.0-1
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

Versions of packages chromium 

Bug#1050001: Unwinding directory aliasing [and 3 more messages]

[Luca Boccassi]

On Sun, 27 Aug 2023 at 18:03, Sam Hartman  wrote:
>
>
> TL;DR: I think I understand one of Ian's points.  I explain, but do not
> believe it is compelling as an argument to switch direction.
>
> > "Helmut" == Helmut Grohne  writes:
> >> I think "package management" is the wrong term here.  It's not
> >> just our tools and packages that are affected.  All forms of
> >> operating system management are affected: anything that changes
> >> the software, and not just its configuration.
> >>
> >> Affected tooling includes not just our .debs, but also remote
> >> configuration management systems like Ansible, image construction
> >> (Dockerfiles), and 3rd-party software installation progrmas
> >> (including both 3rd-party .debs and 3rd-party script-based
> >> installation systems).
>
> Helmut> I don't follow the reasoning. Much of the tasks you'd carry
> Helmut> out with (wlog) ansible - even when updating files - will
> Helmut> continue to work in the aliasing layout. The reason that
> Helmut> dpkg is more affected is that it has an inventory of files
> Helmut> and reasons about their ownership in terms of
> Helmut> packages. That's not how any kind of configuration
> Helmut> management operates.  If you just "make install" something,
> Helmut> chances are that it'll just work with an aliasing layout
> Helmut> even when installing with --prefix=/. I continue to argue
> Helmut> that the problems we are seeing are quite specific to dpkg
> Helmut> in large parts.
>
> I spent some time with Ian's paragraph you quote above trying to
> understand it, and I think I got somewhere.
> I considered replying yesterday but decided against, because I think we
> are already seeing these effects, and have been seeing them long enough
> that  we would  have a good feel for how serious the problems are.
>
> I do think that configuration management does have enough of an
> inventory of files and reasoning about structure that some of these
> problems could arise.  I agree that configuration management does not
> typically reason in terms of packages.
>
> But mechanisms like
>
> * ADD/COPY in Containerfile
>
> * The rsync module in ansible
> * The file module in Ansible
>
> * various inventories related to modification detection in
> configuration management do  reason about the filesystem.
>
> I don't know what would happen if I did
>
> hosts: lots
> remote_user: root
> name: Does this shoot me in the foot
> tasks:
>   - rsync: src=install_root dest=/
>
> where install_root has a bin directory containing a couple of scripts.
> I don't know if rsync will replace a symlink with a directory, or will
> just write through the symlink in that situation.
> If rsync happens to write through the symlink, there's probably some
> other tool somewhere else thatreplaces the symlink.
> And when an admin does that, they get an unbootable system, and fix
> their playbook/whatever.
>
> Similarly, I bet someone somewhere has integrity management scripts that
> want to look at what pam modules are installed under /lib/security, and
> depending on how it worked,
> they had to adjust the config when that moved to
> /lib/security/x86_64-linux-gnu and then again some of them had to adjust
> when /lib became a symlink.  And they were probably frustrated during
> the time when new installs had /lib as a symlink and upgrades did not.
>
> Similarly, I bet you can run into trouble with apparmor profiles if you
> try to profile /bin/python rather than /usr/bin/python or similar.
>
> I bet people who had custom selinux policies had to adjust their
> labeling rules and again some of them probably found the mixed state
> where upgraded systems behaved differently than installed systems
> frustrating.

AppArmor, SELinux, Ansible, Chef, Puppet and whatnot all exist and are
used on all distributions. Such distributions have install bases
vastly higher in numbers than Debian, and have adopted the usrmerged
layout a decade ago or so. Is there any evidence of AppArmor, SELinux,
Ansible, Chef, Puppet and whatnot breaking catastrophically as a
consequence?
Speculating about what might or might not happen with future events is
all good and well, but this is in the past. These things either all
broke and suddenly became unusable on Arch, Fedora, CentOS, RHEL,
Alma, Rocky, SUSE, Mandriva, Yocto, Ubuntu and so on, or they did not.
If there's no evidence they did, then it's not even worth mentioning
or discussing, it's all moot.

> I seem to recall having to make some minor adjustments at my day job
> related to usrmerge back in the buster/bullseye time frame.
> I don't remember what they were.

This is much more likely to be closer to reality. As with any change
or upgrade, there's some minor adjustment here or there, that most
won't even remember about after a while given how trivial it is. I
certainly do not remember all the changes I've had to do to software I
maintain when 

Bug#1050676: enblend-enfuse: FTBFS: dot: maze.c:311: chkSgraph: Assertion `np->cells[0]' failed.

[Aurelien Jarno]

Source: enblend-enfuse
Version: 4.2-10
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

enblend-enfuse fails to build from source. From my build log on amd64:

| /usr/bin/gnuplot --default-settings -e 'DATA_DIR="../../doc"' \
| -e 'set output "log-transform.tex"; set terminal epslatex color 
size 4.5in,3.375in' ../../doc/log-transform.gp && \
| mv log-transform.tex log-transform.pstex
| /usr/bin/m4 --fatal-warnings --prefix-builtins --synclines 
--define='dot_output_type=eps' ../../doc/uml-dot.m4 
../../doc/external-mask-workflow.dot | \
| /usr/bin/dot  -Teps -Gsize=4.75,8.5 -oexternal-mask-workflow.eps
| failed at node 36[0]
| dot: maze.c:311: chkSgraph: Assertion `np->cells[0]' failed.
| /bin/bash: line 2: 2820245 Done/usr/bin/m4 
--fatal-warnings --prefix-builtins --synclines --define='dot_output_type=eps' 
../../doc/uml-dot.m4 ../../doc/external-mask-workflow.dot
|  2820246 Aborted (core dumped) | /usr/bin/dot -Teps 
-Gsize=4.75,8.5 -oexternal-mask-workflow.eps
| make[5]: *** [Makefile:978: external-mask-workflow.eps] Error 134
| make[5]: Leaving directory '/<>/build-def/doc'
| make[4]: *** [Makefile:592: all-recursive] Error 1
| make[4]: Leaving directory '/<>/build-def/doc'
| make[3]: *** [Makefile:444: all-recursive] Error 1
| make[3]: Leaving directory '/<>/build-def'
| make[2]: *** [Makefile:385: all] Error 2
| make[2]: Leaving directory '/<>/build-def'
| dh_auto_build: error: cd build-def && make -j12 returned exit code 2
| make[1]: *** [debian/rules:37: override_dh_auto_build] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:66: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=enblend-enfuse=riscv64=4.2-10=1693064284=0

Regards
Aurelien

Bug#1050675: www.debian.org: French bookworm d-i web page jumped the shark

[Cyril Brulebois]

Package: www.debian.org
Severity: important
Tags: l10n
X-Debbugs-Cc: debian-l10n-fre...@lists.debian.org

Hi,

https://www.debian.org/releases/bookworm/debian-installer/index.fr.html
has an interesting view about the state of the Debian releases, claiming
Debian 12 has been overthrown by Debian 13, and recommending to install
Trixie instead.

Other translations look good to me, so I don't think this is a general
problem with a macro, but something really bad at the individual
translation level.

I haven't investigated the wml source though; French team in copy.


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

Bug#1050674: ispell-czech: FTBFS: Can't exec "/<>/debian/myspell-cs.install"

[Aurelien Jarno]

Source: ispell-czech
Version: 20040229-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

ispell-czech fails to build from source:

| install -o 0 -g 0 -m 644 ./czech.aff 
/<>/debian/tmp/usr/lib/ispell
| install -o 0 -g 0 -m 644 ./czech.hash 
/<>/debian/tmp/usr/lib/ispell
| rm -f ./czech.hash
| make[1]: Leaving directory '/<>'
|dh_install -a
| Can't exec "/<>/debian/myspell-cs.install": No such file or 
directory at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 1616.
| dh_install: error: cannot run debian/myspell-cs.install: No such file or 
directory
| make: *** [debian/rules:4: binary-arch] Error 25
| dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess 
returned exit status 2

A full build log is available:
https://buildd.debian.org/status/fetch.php?pkg=ispell-czech=arm64=20040229-6=1692525149=0

Regards
Aurelien

Bug#1050673: gmult: FTBFS: error: Argument 1: Cannot convert from `unowned uint8[]' to `unowned string'

[Aurelien Jarno]

Source: gmult
Version: 11.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

gmult fails to build from source. From my build log on amd64:

| valac -C --pkg=config --target-glib=2.70 --vapidir /<>/vapi 
--pkg gtk4 --target-glib ' 2.70' --pkg glib-2.0 --pkg libadwaita-1 
--color=always --directory gmult/gmult.p --basedir ../gmult 
--gresources=../data/resources.xml ../gmult/main.vala ../gmult/Canvas.vala 
../gmult/CharBox.vala ../gmult/DigitBox.vala ../gmult/GtkMult.vala 
../gmult/MultPuzzle.vala ../gmult/ScalingLetter.vala ../gmult/Separator.vala 
../gmult/TableBox.vala
| ../gmult/CharBox.vala:44.29-44.36: error: Argument 1: Cannot convert from 
`unowned uint8[]' to `unowned string'
|44 | provider.load_from_data(css.data);
|   | ^~~~  
| ../gmult/CharBox.vala:44.5-44.37: error: 1 missing arguments for `void 
Gtk.CssProvider.load_from_data (string, ssize_t)'
|44 | provider.load_from_data(css.data);
|   | ^ 
| ../gmult/ScalingLetter.vala:40.19-40.35: warning: 
`Gtk.Widget.get_style_context' has been deprecated since 4.10
|40 | var context = get_style_context();
|   |   ^   
| ../gmult/ScalingLetter.vala:40.9-40.15: warning: `Gtk.StyleContext' has been 
deprecated since 4.10
|40 | var context = get_style_context();
|   | ^~~   
| ../gmult/ScalingLetter.vala:41.5-41.22: warning: `Gtk.Snapshot.render_layout' 
has been deprecated since 4.10
|41 | snap.render_layout(context, x, y, layout);
|   | ^~
| ../gmult/CharBox.vala:56.5-56.28: warning: `Gtk.Widget.get_style_context' has 
been deprecated since 4.10
|56 | button.get_style_context().add_provider(provider, 
Gtk.STYLE_PROVIDER_PRIORITY_APPLICATION);
|   | ^~~~  
 
| ../gmult/TableBox.vala:28.5-28.16: warning: `Gtk.DropTarget.on_drop' has been 
deprecated since vala-0.58. Use DropTarget.drop
|28 | drag.on_drop.connect(handle_drag_drop);
|   | ^~~~   
| ../gmult/Separator.vala:13.17-13.33: warning: `Gtk.Widget.get_style_context' 
has been deprecated since 4.10
|13 | var style = get_style_context ();
|   | ^
| ../gmult/Separator.vala:13.9-13.13: warning: `Gtk.StyleContext' has been 
deprecated since 4.10
|13 | var style = get_style_context ();
|   | ^
| Compilation failed: 2 error(s), 7 warning(s)
| ninja: build stopped: subcommand failed.
| dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j12 -v 
returned exit code 1
| make: *** [debian/rules:6: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=gmult=riscv64=11.0-1=1693145453=0

Regards
Aurelien

Bug#1050672: granite-7: FTBFS: error: Argument 1: Cannot convert from `unowned uint8[]' to `unowned string'

[Aurelien Jarno]

Source: granite-7
Version: 7.3.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

granite-7 fails to build from source. From my build log on amd64:

| valac -C --define=LINUX --abi-stability --hide-internal --target-glib=2.50 
--pkg posix --pkg gtk4 --pkg gobject-2.0 --target-glib 2.50 --pkg glib-2.0 
--pkg gio-unix-2.0 --pkg gio-2.0 --pkg gee-0.8 --color=always --directory 
lib/libgranite-7.so.7.3.0.p --basedir ../lib --library granite-7 --header 
lib/granite-7.h --vapi ../granite-7.vapi --gir ../Granite-7.0.gir 
--gresources=../lib/Styles/styles.gresource.xml ../lib/DateTime.vala 
../lib/Constants.vala ../lib/Init.vala ../lib/Services/Application.vala 
../lib/Services/AsyncMutex.vala ../lib/Services/ContractorProxy.vala 
../lib/Services/Portal.vala ../lib/Services/Settings.vala 
../lib/Services/System.vala ../lib/Widgets/AbstractSettingsPage.vala 
../lib/Widgets/AbstractSimpleSettingsPage.vala ../lib/Widgets/AccelLabel.vala 
../lib/Widgets/DatePicker.vala ../lib/Widgets/Dialog.vala 
../lib/Widgets/HeaderLabel.vala ../lib/Widgets/HyperTextView.vala 
../lib/Widgets/MessageDialog.vala ../lib/Widgets/ModeSwitch.vala 
../lib/Widgets/OverlayBar.vala ../lib/Widgets/Placeholder.vala 
../lib/Widgets/SettingsSidebarRow.vala ../lib/Widgets/SettingsSidebar.vala 
../lib/Widgets/Settings.vala ../lib/Widgets/SwitchModelButton.vala 
../lib/Widgets/TimePicker.vala ../lib/Widgets/Toast.vala 
../lib/Widgets/Utils.vala ../lib/Widgets/ValidatedEntry.vala lib/Config.vala
| ../lib/Init.vala:53.9-53.24: warning: `Gtk.StyleContext' has been deprecated 
since 4.10
|53 | Gtk.StyleContext.add_provider_for_display (display, 
base_provider, Gtk.STYLE_PROVIDER_PRIORITY_THEME);
|   | ^~~~  

| ../lib/Init.vala:56.13-56.28: warning: `Gtk.StyleContext' has been deprecated 
since 4.10
|56 | Gtk.StyleContext.add_provider_for_display (display, 
app_provider, Gtk.STYLE_PROVIDER_PRIORITY_APPLICATION);
|   | ^~~~  
 
| ../lib/Widgets/AccelLabel.vala:110.43-110.71: warning: 
`Gtk.Widget.get_style_context' has been deprecated since 4.10
|   110 | var accel_label_context = 
accel_label.get_style_context ();
|   |   
^
| ../lib/Widgets/AccelLabel.vala:110.21-110.39: warning: `Gtk.StyleContext' has 
been deprecated since 4.10
|   110 | var accel_label_context = 
accel_label.get_style_context ();
|   | ^~~   
 
| ../lib/Widgets/HyperTextView.vala:252.9-252.20: warning: `Gtk.show_uri' has 
been deprecated since 4.10
|   252 | Gtk.show_uri (null, uri, Gdk.CURRENT_TIME);
|   | ^~~~   
| ../lib/Widgets/ModeSwitch.vala:91.9-91.37: warning: 
`Gtk.Widget.get_style_context' has been deprecated since 4.10
|91 | mode_switch.get_style_context ().add_class 
(Granite.STYLE_CLASS_MODE_SWITCH);
|   | ^ 
   
| ../lib/Widgets/SettingsSidebarRow.vala:83.9-83.37: warning: 
`Gtk.Widget.get_style_context' has been deprecated since 4.10
|83 | title_label.get_style_context ().add_class 
(Granite.STYLE_CLASS_H3_LABEL);
|   | ^ 

| ../lib/Widgets/SettingsSidebar.vala:95.17-95.39: warning: 
`Gtk.Widget.get_style_context' has been deprecated since 4.10
|95 | label.get_style_context ().add_class 
(Granite.STYLE_CLASS_H4_LABEL);
|   | ^~~   
  
| ../lib/Widgets/SwitchModelButton.vala:53.49-53.83: warning: 
`Gtk.Widget.get_style_context' has been deprecated since 4.10
|53 | unowned var description_style_context = 
description_label.get_style_context ();
|   | 
^~~
| ../lib/Widgets/SwitchModelButton.vala:53.21-53.45: warning: 
`Gtk.StyleContext' has been deprecated since 4.10
|53 | unowned var description_style_context = 
description_label.get_style_context ();
|   | ^ 
 
| ../lib/Widgets/Utils.vala:269.38-269.45: error: Argument 1: Cannot convert 
from `unowned uint8[]' to `unowned string'
|   269 | css_provider.load_from_data (css.data);
|   |  ^~~~  
| ../lib/Widgets/Utils.vala:269.9-269.46: error: 1 missing arguments for `void 
Gtk.CssProvider.load_from_data (string, ssize_t)'
|   

Bug#1050671: zabbix: FTBFS: malformed import path "[cmd/compile]": invalid char '['

[Aurelien Jarno]

Source: zabbix
Version: 1:6.0.14+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

zabbix fails to build from source. From my build log on amd64:

| make[1]: Leaving directory '/<>'
|dh_strip -a -O--max-parallel=4
|dh_makeshlibs -a -O--max-parallel=4
|dh_shlibdeps -a -O--max-parallel=4
|dh_installdeb -a -O--max-parallel=4
|debian/rules override_dh_gencontrol
| make[1]: Entering directory '/<>'
| if [ -d "debian/zabbix-agent2" ]; then DH_GOPKG="..." dh_golang 
--package=zabbix-agent2 --sourcedirectory=src/go/ ;fi
| malformed import path "[cmd/compile]": invalid char '['
| dh_golang: error: go list -f '\
| {{ .Dir }}/{{ index (or .GoFiles .CgoFiles .TestGoFiles .XTestGoFiles 
.IgnoredGoFiles) 0 }}' returned exit code 1
| make[1]: *** [debian/rules:197: override_dh_gencontrol] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:83: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=zabbix=riscv64=1%3A6.0.14%2Bdfsg-1=1693070592=0

Regards
Aurelien

Bug#1050670: mod-gnutls: FTBFS: GnuTLS: Failed to initialize: (-1250) An unimplemented or disabled feature has been requested.

[Aurelien Jarno]

Source: mod-gnutls
Version: 0.9.0-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

mod-gnutls fails to build from source due to testsuite issue. From my
build log on amd64:

| 
| Testsuite summary for mod_gnutls 0.9.0
| 
| # TOTAL: 34
| # PASS:  1
| # SKIP:  0
| # XFAIL: 0
| # FAIL:  33
| # XPASS: 0
| # ERROR: 0
| 
| See test/test-suite.log
| 

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=mod-gnutls=riscv64=0.9.0-1.1=1693057445=0

Regards
Aurelien

Bug#1050668: python3: Fails to import/work with SSL module due to ImportError

[Jonathan Weth]

Package: python3
Version: 3.11.4-5+b1
Severity: important
Tags: upstream
X-Debbugs-Cc: deb...@jonathanweth.de

Dear Maintainer,

after updating to the newest Python version and trying to work with Poetry (e. 
g. downloading packages),
the following problem related to the SSL module occured:

Traceback (most recent call last):
  File "/home/wethjo/.local/bin/poetry", line 8, in 
sys.exit(main())
 ^^
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/console/application.py",
 line 405, in main
exit_code: int = Application().run()
 ^^^
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/cleo/application.py",
 line 338, in run
self.render_error(e, io)
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/console/application.py",
 line 180, in render_error

self.set_solution_provider_repository(self._get_solution_provider_repository())
  

  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/console/application.py",
 line 394, in _get_solution_provider_repository
from 
poetry.mixology.solutions.providers.python_requirement_solution_provider import 
(  # noqa: E501
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/mixology/solutions/providers/__init__.py",
 line 3, in 
from 
poetry.mixology.solutions.providers.python_requirement_solution_provider import 
(
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/mixology/solutions/providers/python_requirement_solution_provider.py",
 line 9, in 
from poetry.puzzle.exceptions import SolverProblemError
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/puzzle/__init__.py",
 line 3, in 
from poetry.puzzle.solver import Solver
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/puzzle/solver.py",
 line 16, in 
from poetry.puzzle.provider import Indicator
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/puzzle/provider.py",
 line 25, in 
from poetry.packages.direct_origin import DirectOrigin
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/packages/direct_origin.py",
 line 10, in 
from poetry.inspection.info import PackageInfo
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/inspection/info.py",
 line 26, in 
from poetry.utils.env import EnvCommandError
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/poetry/utils/env.py",
 line 26, in 
import virtualenv
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/virtualenv/__init__.py",
 line 3, in 
from .run import cli_run, session_via_cli
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/virtualenv/run/__init__.py",
 line 11, in 
from ..seed.wheels.periodic_update import manual_upgrade
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/virtualenv/seed/wheels/__init__.py",
 line 3, in 
from .acquire import get_wheel, pip_wheel_env_run
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/virtualenv/seed/wheels/acquire.py",
 line 11, in 
from .bundle import from_bundle
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/virtualenv/seed/wheels/bundle.py",
 line 4, in 
from .periodic_update import periodic_update
  File 
"/home/wethjo/.local/share/pypoetry/venv/lib/python3.11/site-packages/virtualenv/seed/wheels/periodic_update.py",
 line 11, in 
import ssl
  File "/usr/lib/python3.11/ssl.py", line 100, in 
import _ssl # if we can't import it, let the error propagate
^^^
ImportError: 
/usr/lib/python3.11/lib-dynload/_ssl.cpython-311-x86_64-linux-gnu.so: undefined 
symbol: _PyModule_Add

There also seem to be other users experiencing this concrete issue as stated in 
 
https://github.com/python/cpython/issues/108525, for example.

Cheers,

Jonathan

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

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

Versions of packages python3 depends on:
ii  libpython3-stdlib  3.11.4-5+b1
ii  python3-minimal3.11.4-5+b1
ii  python3.11 3.11.5-2

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
ii  python3-tk3.11.5-1
pn  python3-venv  

-- no debconf information

Bug#1050669: openvswitch: FTBFS on riscv64: 1088: PMD - revalidator modify overlapping flows FAILED (pmd.at:1374)

[Aurelien Jarno]

Source: openvswitch
Version: 3.2.0-1
Severity: normal

Dear maintainer,

openvswitch *consistenly* fails to build from source on riscv64 with the
following testsuite error:

| 1088: PMD - revalidator modify overlapping flows  FAILED (pmd.at:1374)

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=openvswitch=riscv64=3.2.0-1=1693157983=0

At this time we haven't got time to investigate the issue, but as it
fails consistently it is probably better to track the issue in the bug
tracker than giving it back in a loop.

Regards
Aurelien

Bug#992918: gwenview: fails to save jpg/jpeg image

[RattusRattus]

Can not reproduce the bug on a different KDE installed on Bullseye with 
Fufu Fang sat next to me (original bug reporter).  We suspect something 
has been changed under the package on Fufu's PC



--
/RattusRattus
Debian is not always the answer, however it is surprising how many times 
it is...

Bug#1031046: Unacceptable - Asterisk is too popular to exclude

[debian . org]

Hello Moritz,

I've read your bug report at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031046


I believe it to be unacceptable to exclude Asterisk from Bookworm. 
Asterisk is used by a LOT of users worldwide and, as you've noted, is 
frequently the subject of security concerns.


The VoIP Team is currently working on a plan to resolve your concerns.

If we don't provide Debian users with secure packages, they will use 
packages from less reputable sources and chaos will ensue.


I believe the VoIP team can deliver on the commitments you are asking 
for, we are working on raising a bigger team of volunteers so we can 
more effectively address CVEs.


Stay tuned.

David

Bug#1050667: DSA for jupyter-core in oldstable triggers nbconvert autopkgtest

[Paul Gevers]

Source: nbconvert
Version: 5.6.1-3
Severity: serious
Tags: bullseye

[Please CC me on replies]

 Forwarded Message 
Subject: DSA for jupyter-core in oldstable triggers nbconvert autopkgtest
Date: Thu, 3 Aug 2023 11:37:04 +0200
From: Paul Gevers 
To: nbconv...@packages.debian.org
CC: debian-release 

Hi nbconvert maintainers,

DSA 5422 [1] seems to be triggering an autopkgtest regression in 
nbconvert. Looking at the name of the test, this could be a serious 
problem for nbconvert users on oldstable. Can you please investigate and 
let us know if you need to fix nbconvert in the next point release update?


 From the log [2]:
109s === FAILURES 
===
109s _ TestNbConvertApp.test_default_config 
_

109s
109s self = testMethod=test_default_config>

109s
109s def test_default_config(self):
109s """
109s Does the default config work?
109s """
109s with self.create_temp_cwd(['notebook*.ipynb', 
'jupyter_nbconvert_config.py']):

109s >   self.nbconvert('--log-level 0')
109s
109s 
/usr/lib/python3/dist-packages/nbconvert/tests/test_nbconvertapp.py:227:
109s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _

109s
109s self = testMethod=test_default_config>
109s parameters = ['--log-level', '0'], ignore_return_code = False, 
stdin = None

109s
109s def nbconvert(self, parameters, ignore_return_code=False, 
stdin=None):

109s """
109s Run nbconvert as a shell command, listening for both Errors and
109s non-zero return codes. Returns the tuple (stdout, stderr) of
109s output produced during the nbconvert run.
109s
109s Parameters
109s --
109s parameters : str, list(str)
109s List of parameters to pass to IPython.
109s ignore_return_code : optional bool (default False)
109s Throw an OSError if the return code
109s """
109s cmd = [sys.executable, '-m', 'nbconvert']
109s if sys.platform == 'win32':
109s if isinstance(parameters, string_types):
109s cmd = ' '.join(cmd) + ' ' + parameters
109s else:
109s cmd = ' '.join(cmd + parameters)
109s else:
109s if isinstance(parameters, string_types):
109s parameters = shlex.split(parameters)
109s cmd += parameters
109s p = Popen(cmd, stdout=PIPE, stderr=PIPE, stdin=PIPE)
109s stdout, stderr = p.communicate(input=stdin)
109s if not (p.returncode == 0 or ignore_return_code):
109s >   raise OSError(bytes_to_str(stderr))
109s E   OSError
109s
109s /usr/lib/python3/dist-packages/nbconvert/tests/base.py:162: OSError

Paul

[1] https://security-tracker.debian.org/tracker/DSA-5422
[2] 
https://ci.debian.net/data/autopkgtest/oldstable/amd64/n/nbconvert/36344377/log.gz


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050663: dar option --on‐fly‐isolate creates catalogue with broken slice_layout

[John Goerzen]

tags 1050663 upstream
thanks

Hi Thomas,

Thank you for this clear and well-documented report.  This looks like a
bug in upstream dar.  Would you please report it to Denis (upstream
author) on the mailing list at
https://sourceforge.net/projects/dar/lists/dar-support ?

I do also monitor that list and will chime in if there is anything
Debian-specific to add.  Denis is very responsive and is going to be
making a new release soon, so maybe this could get into the release he
is preparing.

Thanks,

John

On Sun, Aug 27 2023, Thomas wrote:

> Package: dar
> Version: 2.7.10-2+b2
> Severity: normal
> X-Debbugs-Cc: debianbts-20230827181...@racbu.de
>
> Dear Maintainer,
>
> I try to do a differential backup with an earlier on-fly-isolated
> catalogue. It seems dar can't read the isolated catalogues anymore.
>
> , [ Error ]
> | Final memory cleanup...
> |  exception type = [BUG] --
> | [source]
> | File ../../../src/libdar/slice_layout.cpp line 48 : it seems to be 
> a bug here
> | stack dump :
> | 
> /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar4EbugC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi+0x140)
> | [0x7f4ff3f79d50]
> | stack dump : /lib/x86_64-linux-gnu/libdar64.so.6000(+0xf83bb) 
> [0x7f4ff3ef83bb]
> | stack dump :
> | 
> /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar14header_version4readERNS_12generic_fileERNS_16user_interactionEb+0x264)
> | [0x7f4ff3fbc944]
> | stack dump :
> | 
> /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar24macro_tools_open_archiveERKSt10shared_ptrINS_16user_interactionEERKS0_INS_8entrepotEERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_8limitintImEESG_NS_11crypto_algoERKNS_11secu_stringEjRNS_4pileERNS_14header_versionESG_SG_SG_RSI_RNS9_4listINS_8signatorESaISV_EEERNS_12slice_layoutEmmb+0x3aa)
> | [0x7f4ff3fe526a]
> | stack dump :
> | 
> /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar7archive9i_archiveC1ERKSt10shared_ptrINS_16user_interactionEERKNS_4pathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESH_RKNS_20archive_options_readE+0x44f)
> | [0x7f4ff3fc1d6f]
> | stack dump :
> | 
> /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar7archiveC2ERKSt10shared_ptrINS_16user_interactionEERKNS_4pathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESG_RKNS_20archive_options_readE+0xd6)
> | [0x7f4ff3f248c6]
> | stack dump : dar(+0x49306) [0x560a2c6b1306]
> | stack dump : dar(+0x5158c) [0x560a2c6b958c]
> | stack dump : dar(+0x247d1) [0x560a2c68c7d1]
> | stack dump : /lib/x86_64-linux-gnu/libc.so.6(+0x276ca) 
> [0x7f4ff38456ca]
> | stack dump : 
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f4ff3845785]
> | stack dump : dar(+0x24821) [0x560a2c68c821]
> | [most outside call]
> | ---
> `
>
> Reproduce the error
> 
> This is a minimal example to reproduce the error.
>
> ### Create som structure to backup
> $ export BASE=/tmp/dar_debug
> $ mkdir -p ${BASE}/bak ${BASE}/cat ${BASE}/files
> $ touch ${BASE}/files/file1
>
> ### Create the backup and the on-fly-isolation
> $ dar --create ${BASE}/bak/full --fs-root ${BASE}/files/ --aux 
> ${BASE}/cat/full_onthefly
>
> ### Do a manual isolation after the backup is done
> $ dar --ref ${BASE}/bak/full --isolate ${BASE}/cat/full_isolate
>
> ### As described in the man page on-fly-isolation is always compressed so
> ### lets do this manually, too
> $ dar --ref ${BASE}/bak/full --compression=bzip2 --isolate 
> ${BASE}/cat/full_isolate_compressed
>
> ### checking the results
> # the backup itself and the after backup-catalogues are working:
> $ dar --list ${BASE}/bak/full
> [Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size|  
> Date |filename
> ++---+---+-+---+
> [Saved][ ]   [-L-][ ][ ]  -rw-r--r--   thomas thomas  0   Sun Aug 
> 27 18:45:31 2023file1
>
> $ dar --list ${BASE}/cat/full_isolate
> [Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size|  
> Date |filename
> ++---+---+-+---+
> [InRef][ ]   [-L-][-][ ]  -rw-r--r--   thomas thomas  0   Sun Aug 
> 27 18:45:31 2023file1
>
> $ dar --list ${BASE}/cat/full_isolate_compressed
> [Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size|  
> Date |filename
> ++---+---+-+---+
> [InRef][ ]   [-L-][-][ ]  -rw-r--r--   thomas thomas  0   Sun Aug 
> 27 18:45:31 2023file1
>
>
> # dar can't read the on-fly-catalogue and reports the error above:
> $ dar --list ${BASE}/cat/full_onthefly
> 

Bug#1050666: make exiv2 -T honor the timezone and the subseconds, or remove the option -T

[Alma Madeleine]

Package: exiv2
Version: 0.27.6-1

The time zone stored in the photo may be very different from the time 
zone on the machine which runs exiv2.  Consider the following example:


$ exiv2 -T test.jpg
$ exiftool test.jpg
ExifTool Version Number : 12.57
File Name   : test.jpg
Directory   : .
File Size   : 496 kB
File Modification Date/Time : 2019:12:07 16:09:14+01:00
File Access Date/Time   : 2023:08:27 21:06:46+02:00
File Inode Change Date/Time : 2023:08:27 21:06:45+02:00
File Permissions: -rw---
File Type   : JPEG
File Type Extension : jpg
MIME Type   : image/jpeg
Exif Byte Order : Big-endian (Motorola, MM)
Make: Apple
Camera Model Name   : iPhone SE
Orientation : Rotate 180
X Resolution: 72
Y Resolution: 72
Resolution Unit : inches
Software: 13.2.3
Modify Date : 2019:12:07 16:09:14
Y Cb Cr Positioning : Centered
Exposure Time   : 1/109
F Number: 2.4
Exposure Program: Program AE
ISO : 50
Exif Version: 0231
Date/Time Original  : 2019:12:07 16:09:14
Create Date : 2019:12:07 16:09:14
Offset Time : +10:00
Offset Time Original: +10:00
Offset Time Digitized   : +10:00
Components Configuration: Y, Cb, Cr, -
Shutter Speed Value : 1/109
Aperture Value  : 2.4
Brightness Value: 6.134006728
Exposure Compensation   : 0
Metering Mode   : Multi-segment
Flash   : Auto, Did not fire
Focal Length: 2.1 mm
Maker Note Version  : 11
Run Time Flags  : Valid
Run Time Value  : 13593698360583
Run Time Scale  : 10
Run Time Epoch  : 0
AE Stable   : Yes
AE Target   : 214
AE Average  : 211
AF Stable   : Yes
Acceleration Vector : -0.9600369334 0.03025732003 -0.222530246
HDR Image Type  : HDR Image
Image Unique ID : 06F21219-30C6-4DDC-AC64-E896F45FB857
Live Photo Video Index  : 0
Signal To Noise Ratio   : 0
Sub Sec Time Original   : 455
Sub Sec Time Digitized  : 455
Flashpix Version: 0100
Color Space : sRGB
Exif Image Width: 1280
Exif Image Height   : 960
Sensing Method  : One-chip color area
Scene Type  : Directly photographed
Custom Rendered : HDR (original saved)
Exposure Mode   : Auto
White Balance   : Auto
Focal Length In 35mm Format : 31 mm
Scene Capture Type  : Standard
Lens Info   : 2.15mm f/2.4
Lens Make   : Apple
Lens Model  : iPhone SE front camera 2.15mm f/2.4
Compression : JPEG (old-style)
Thumbnail Offset: 1418
Thumbnail Length: 12873
XMP Toolkit : XMP Core 5.4.0
Region Area Y   : 0.64202
Region Area W   : 0.28498
Region Area X   : 0.19748
Region Area H   : 0.38006
Region Area Unit: normalized
Region Type : Face
Region Extensions Angle Info Yaw: 0
Region Extensions Angle Info Roll: 150
Region Extensions Confidence Level: 1000
Region Extensions Time Stamp: 326245557611
Region Extensions Face ID   : 12
Region Applied To Dimensions H  : 960
Region Applied To Dimensions W  : 1280
Region Applied To Dimensions Unit: pixel
Image Width : 1280
Image Height: 960
Encoding Process: Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components: 3
Y Cb Cr Sub Sampling: YCbCr4:2:0 (2 2)
Run Time Since Power Up : 3:46:34
Aperture: 2.4
Image Size  : 1280x960
Megapixels  : 1.2
Scale Factor To 35 mm Equivalent: 14.4
Shutter Speed   : 1/109
Create Date : 2019:12:07 16:09:14.455+10:00
Date/Time Original  : 2019:12:07 16:09:14.455+10:00
Modify Date : 2019:12:07 16:09:14+10:00
Thumbnail Image : (Binary data 12873 bytes, use -b 
option to extract)

Circle Of Confusion : 0.002 mm
Field Of View   : 60.3 deg
Focal Length: 2.1 mm (35 mm 

Bug#1050665: clutter-1.0: FTBFS on riscv64 due to test timeout

[Aurelien Jarno]

Source: clutter-1.0
Version: 1.26.4+git2779b932+dfsg-5
Severity: important
Tags: patch ftbfs
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear maintainer,

clutter-1.0 fails to build from source on riscv64 with a timeout in on test:

| === 25/25 
| test: clutter:actor / actor-pick
| start time:   05:39:05
| duration: 30.17s
| result:   killed by signal 15 SIGTERM
| command:  G_ENABLE_DIAGNOSTIC=0 
LD_LIBRARY_PATH=/<>/obj-riscv64-linux-gnu/clutter 
CLUTTER_ENABLE_DIAGNOSTIC=0 
G_TEST_BUILDDIR=/<>/obj-riscv64-linux-gnu/tests/conform 
MALLOC_PERTURB_=247 G_TEST_SRCDIR=/<>/tests/conform 
CLUTTER_BACKEND=x11 
/<>/obj-riscv64-linux-gnu/tests/conform/actor-pick
| --- stdout ---
| TAP version 13
| # random seed: R02Sb54186406fb0014222d460465642f460
| 1..1
| # Start of actor tests
| ==
| 
| 
| Summary of Failures:
| 
| 25/25 clutter:actor / actor-pick TIMEOUT30.17s   
killed by signal 15 SIGTERM
| 
| Ok: 24  
| Expected Fail:  0   
| Fail:   0   
| Unexpected Pass:0   
| Skipped:0   
| Timeout:1   
| dh_auto_test: error: cd obj-riscv64-linux-gnu && LC_ALL=C.UTF-8 
MESON_TESTTHREADS=4 meson test returned exit code 1
| make[1]: *** [debian/rules:61: override_dh_auto_test] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:26: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=clutter-1.0=riscv64=1.26.4%2Bgit2779b932%2Bdfsg-5=1691732382=0

After investigation, it appeared the test actually passes, but needs
more time than the default 30 seconds timeout of meson. The following
patch, increasing the timeout to 100 seconds is enough to get the test
pass:

--- clutter-1.0-1.26.4+git2779b932+dfsg.orig/tests/conform/meson.build
+++ clutter-1.0-1.26.4+git2779b932+dfsg/tests/conform/meson.build
@@ -91,6 +91,7 @@ foreach suite: conformance_suites
 test(t, test_bin,
   suite: suite_name,
   env: test_env,
+  timeout: 100,
 )
   endforeach
 endforeach

I guess it might also fix the same issue on a few other architectures.

Regards
Aurelien

Bug#647884: cron wrong time in logs

[Georges Khaznadar]

Hi, this bug report is now twelve years old. Christian Kastner asked for
a snippet of a log file, which was not sent, and explained that this
kind of bug is now fixed in recent versions of cron.

So, I clode this bug report.

Best regards,   Georges.

Christian Kastner a écrit :
> severity 647884 normal
> thanks
> 
> Hi,
> 
> On 2011-11-07 10:34, Serguei wrote:
> > Package: cron
> > Version: 3.0pl1-116
> > Severity: critical
> ^^^
> Bug severities have a very specific meaning in Debian, see
> 
> http://www.debian.org/Bugs/Developer#severities
> 
> I'm downgrading this to "normal" according to said policy.
> 
> > i have timezone /etc/timezone which is equal to Europe/Moscow. After 29
> > october When all world moved clock to winter time our timezone left on
> > summer time.
> > 
> > first problem: cron runs task as scheduled but puts time into syslog
> > with timeshift minus 1 hour
> 
> cron does not specify any time at all -- the timestamp in syslog comes
> from the syslog daemon. So whatever the problem is, it can only be
> resolved there.
> 
> Could you post a short snippet of your log file with a valid entry
> shortly before the DST change and the first invalid entry?
> 
> > second problem: each time crontab file changes cron daemon must be
> > restarted to reread crontab
> 
> This issue (previously reported as #625495 and #627859) has been
> resolved in package version 3.0pl1-117.
> 
> 
> Christian
> 



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#617898: cron.d snippets have different default PATH from crontab/cron.{daily,...}

[Georges Khaznadar]

Hello, this bug report is now twelve years old.

As root users are supposed to read manpages of important commands, they
are aware of the possibility to define environment variables like PATH
in crontab files.

So, I consider this bug as fixed, per the manpages.

Best regards,   Georges.

Josip Rodin a écrit :
> severity 617898 normal
> thanks
> 
> Hi,
> 
> Recently I added a logrotate setup that was very similar to apache2's, but
> I ran it from a cron.d file, and it obviously failed because the normal
> logrotate runs from /etc/crontab, which has a different PATH set.
> 
> I think this is not a wishlist item to change this, rather it is a genuine
> bug, because I don't see the actual rationale for the behavior of
> /etc/crontab and cron(8) to differ in such a fundamental way, and it's
> clearly causing a number of users to have to amend their cron.d files
> in a way that is redundant and error-prone (having to redefine PATH
> everywhere reminds me of the dark days of 1990s Unix systems, and it is
> NOT something we want to replicate ever again).
> 
> I certainly don't see a downside with adding the sbin variants, because
> on Debian systems they're expected to be as reliable as bin variants,
> and there should be no confusing overlaps.
> 
> For local, an argument could be made that it exposes a possibility of
> problems with random local binaries getting in the way, but it would
> still probably be better to do this kind of a transition to get everything
> consistent. Random complexity just leads to more trouble.
> 
> Please fix this. TIA.
> 
> -- 
> Josip Rodin
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1050664: firehol: please install contrib/ipset-apply.sh into firehol-tools

[Fabio Pedretti]

Package: firehol
Version: 3.1.7+ds-2.1
Severity: wishlist
X-Debbugs-Cc: pedretti.fa...@gmail.com

Dear Maintainer,

firehol source package has 2 tools in the contrib dir: dnsbl-ipset.sh
and ipset-apply.sh.
The latter however is not installed. Please install also ipset-apply.sh
since it is a useful tool.

Thanks.

Bug#647193: /usr/sbin/cron: (*system*) NUMBER OF HARD LINKS > 1 (/etc/crontab)

[Georges Khaznadar]

Hello,

this bug report is now twelve years old.

As Christian Kastner proposed a reasonable workaround for xavier
renaut's use case, and as xavier renaut sent no reply for many years, I
close this bug report.

Best regards,   Georges.

Christian Kastner a écrit :
> Hi,
> 
> On 2011-10-31 15:32, xavier renaut wrote:
> > I  hard link /etc/crontab to track it under svn, but 
> > to have the checkout somewhere else than /etc/
> > 
> > So /etc/crontab has 2 hardlinks,
> > and cron is now complaining about it :
> > Oct  3 09:35:01 natch /usr/sbin/cron[3878]: (*system*) NUMBER OF HARD LINKS 
> > > 1 (/etc/crontab)
> >
> > Is there something to do ? or the security gain is too high for this to be 
> > fixed ?
> 
> I'm afraid it's the latter; we can't allow that for security reasons.
> 
> What you could do is make /etc/crontab a symlink to the file in svn. The
> symlink owner must be root, see cron(8).
> 
> Christian
> 
> PS: Personally, I can highly recommend the use a configuration
> management system such as puppet or cfengine. etckeeper might also be of
> interest to you.
> 
> 



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#702712: Use crond -L 5 to get the "(failed)" subject back

[Georges Khaznadar]

Hello,

as this bug report has been concluded by Sam Morris' enlightenment,
which details how to activate the desired feature, I close it.

Best regards,   Georges.

Sam Morris a écrit :
> This was caused by:
> 
>   * do_command.c, cron.h, cron.8: 
> - Change the behaviour when logging the information of the child 
> processes.
>   A new loglevel (8) is introduced and documented in cron.8. The 
> previous
>   log format is kept unless the sysadmin choses to select this 
> new option.
>   (Closes: #637295)
> 
> The exit status of jobs is ignored unless log_level &
> CRON_LOG_JOBFAILED. Put EXTRA_OPTS='-L 5' into /etc/default/cron and
> restart cron and the mails will be fixed.
> 
> Regards,
> 
> -- 
> Sam Morris
> https://robots.org.uk/
>  
> PGP key id 1024D/5EA01078
> 3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1043144: transition: mutter/gnome-shell 44

[Jeremy Bícha]

On Sat, Aug 26, 2023 at 6:31 AM Graham Inggs  wrote:
> libmutter-11-0 is gone from testing and gnome-shell has migrated.  Is
> anything outstanding, or can we consider this transition done?

This transition is done, but I think gnome-shell-extension-dashtodock
is popular enough that it's helpful to hint 87+really84-1 in sooner.

Thank you,
Jeremy Bícha

Bug#691275: cron: symlink races in crontab

[Georges Khaznadar]

Hello,

this bug report has received no additional information for eleven years
now. As Javier Fernández-Sanguino Peña considered that the security
issue was not confirmed and asked Jann Horn to describe a proof of
concept, without being replied ... I close this bug report.

Best regards,   Georges.

Javier Fernández-Sanguino Peña a écrit :
> tags 691275 moreinfo 
> thanks
> 
> On Tue, Oct 23, 2012 at 09:28:05PM +0200, Jann Horn wrote:
> > Debian's crontab contains multiple symlink races. If
> > crontab was setuid root (which I think it normally is), this could be used
> > to e.g. wipe directories (vulnerable code is in cleanup_tmp_crontab) or for
> > other attacks. However, as it is only setgid crontab on debian, the only
> > attack this can be used for is to block cron access for a user named
> > "crontab" by invoking "crontab -e" and replacing the
> > folder in /tmp with a symlink before crontab creates the file "crontab"
> > inside the folder. The code vulnerable to this attack is in
> > create_tmp_crontab.
> 
> Could you please detail where do you see the symlink races or show, at least, 
> a
> proof of concept of the symlink race in action and how can I reproduce this
> bug?
> 
> Reviewing the code: the directory used in cleanup_tmp_crontab is actually 
> defined in
> create_tmp_crontab using mkdtemp(). Mkdtemp ensures that the directory
> created is both unique as well as restricted to the user running it.
> 
> This means that, as far as I know, any files created within that directory 
> (and removed
> afterwards) should be "safe". This includes the unlink() codes in
> cleanup_tmp_crontab, as well as the rmdir() call there.
> 
> Best regards
> 
> Javier
> 



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1050663: dar option --on‐fly‐isolate creates catalogue with broken slice_layout

[Thomas]

Package: dar
Version: 2.7.10-2+b2
Severity: normal
X-Debbugs-Cc: debianbts-20230827181...@racbu.de

Dear Maintainer,

I try to do a differential backup with an earlier on-fly-isolated
catalogue. It seems dar can't read the isolated catalogues anymore.

, [ Error ]
| Final memory cleanup...
|  exception type = [BUG] --
| [source]
| File ../../../src/libdar/slice_layout.cpp line 48 : it seems to be a 
bug here
| stack dump : 
/lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar4EbugC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi+0x140)
 [0x7f4ff3f79d50]
| stack dump : /lib/x86_64-linux-gnu/libdar64.so.6000(+0xf83bb) 
[0x7f4ff3ef83bb]
| stack dump : 
/lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar14header_version4readERNS_12generic_fileERNS_16user_interactionEb+0x264)
 [0x7f4ff3fbc944]
| stack dump : 
/lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar24macro_tools_open_archiveERKSt10shared_ptrINS_16user_interactionEERKS0_INS_8entrepotEERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_8limitintImEESG_NS_11crypto_algoERKNS_11secu_stringEjRNS_4pileERNS_14header_versionESG_SG_SG_RSI_RNS9_4listINS_8signatorESaISV_EEERNS_12slice_layoutEmmb+0x3aa)
 [0x7f4ff3fe526a]
| stack dump : 
/lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar7archive9i_archiveC1ERKSt10shared_ptrINS_16user_interactionEERKNS_4pathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESH_RKNS_20archive_options_readE+0x44f)
 [0x7f4ff3fc1d6f]
| stack dump : 
/lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar7archiveC2ERKSt10shared_ptrINS_16user_interactionEERKNS_4pathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESG_RKNS_20archive_options_readE+0xd6)
 [0x7f4ff3f248c6]
| stack dump : dar(+0x49306) [0x560a2c6b1306]
| stack dump : dar(+0x5158c) [0x560a2c6b958c]
| stack dump : dar(+0x247d1) [0x560a2c68c7d1]
| stack dump : /lib/x86_64-linux-gnu/libc.so.6(+0x276ca) 
[0x7f4ff38456ca]
| stack dump : /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) 
[0x7f4ff3845785]
| stack dump : dar(+0x24821) [0x560a2c68c821]
| [most outside call]
| ---
`

Reproduce the error

This is a minimal example to reproduce the error.

### Create som structure to backup
$ export BASE=/tmp/dar_debug
$ mkdir -p ${BASE}/bak ${BASE}/cat ${BASE}/files
$ touch ${BASE}/files/file1

### Create the backup and the on-fly-isolation
$ dar --create ${BASE}/bak/full --fs-root ${BASE}/files/ --aux 
${BASE}/cat/full_onthefly

### Do a manual isolation after the backup is done
$ dar --ref ${BASE}/bak/full --isolate ${BASE}/cat/full_isolate

### As described in the man page on-fly-isolation is always compressed so
### lets do this manually, too
$ dar --ref ${BASE}/bak/full --compression=bzip2 --isolate 
${BASE}/cat/full_isolate_compressed

### checking the results
# the backup itself and the after backup-catalogues are working:
$ dar --list ${BASE}/bak/full
[Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size|
  Date |filename
++---+---+-+---+
[Saved][ ]   [-L-][ ][ ]  -rw-r--r--   thomas   thomas  0   Sun Aug 
27 18:45:31 2023file1

$ dar --list ${BASE}/cat/full_isolate
[Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size|
  Date |filename
++---+---+-+---+
[InRef][ ]   [-L-][-][ ]  -rw-r--r--   thomas   thomas  0   Sun Aug 
27 18:45:31 2023file1

$ dar --list ${BASE}/cat/full_isolate_compressed
[Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size|
  Date |filename
++---+---+-+---+
[InRef][ ]   [-L-][-][ ]  -rw-r--r--   thomas   thomas  0   Sun Aug 
27 18:45:31 2023file1


# dar can't read the on-fly-catalogue and reports the error above: 
$ dar --list ${BASE}/cat/full_onthefly
Final memory cleanup...
 exception type = [BUG] --
[source]
File ../../../src/libdar/slice_layout.cpp line 48 : it seems to be a 
bug here
stack dump : 
/lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar4EbugC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi+0x140)
 [0x7f4ff3f79d50]
stack dump : /lib/x86_64-linux-gnu/libdar64.so.6000(+0xf83bb) 
[0x7f4ff3ef83bb]
stack dump : 
/lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar14header_version4readERNS_12generic_fileERNS_16user_interactionEb+0x264)
 [0x7f4ff3fbc944]
stack dump : 

Bug#1050662: efivar: update d/watch file

[Patrice Duroux]

Source: efivar
Version: 37-6
Severity: minor

Dear Maintainer,

Here is a patch for.

Thanks,
Patrice


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

Kernel: Linux 6.5.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
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
diff --git a/debian/watch b/debian/watch
index 2f0bc43..86bd4fe 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,12 +1,4 @@
-# You can run the "uscan" command to check for upstream updates and more.
-# See uscan(1) for format
-
-# Compulsory line, this is a version 3 file
-version=3
-
-#opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/efivar-$1\.tar\.gz/ \
-#https://github.com/vathpela/efivar/tags .*/v?(\d\S*)\.tar\.gz
-
-https://github.com/rhinstaller/efivar/releases \
-.*[^n]/(?:|v|version-|r|REL_|rel-|efivar(?:_|-))(\d[^\s/]*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)
-
+version=4
+opts="filenamemangle=s%(?:.*?)?v?@ANY_VERSION@(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%" 
\
+https://github.com/rhinstaller/@PACKAGE@/tags \
+(?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@

Bug#1050482: cron: Multiple issues with the cron_now feature

[Georges Khaznadar]

Dear Guillem, thank you for your detailed bug report.

You are right, with the suggestion to create a new switch for cron,
instead of creating a separate command. I hesitated to choose this
method, but you convinced me.

I shall upload shortly a new release, with the possibility to launch
`cron -N` instead of `cron_now`.

Best regards,   Georges.

Guillem Jover a écrit :
> Source: cron
> Source-Version: 3.0pl1-173
> Severity: normal
> 
> Hi!
> 
> While reading the changelog [C] during an upgrade I noticed a suspicious
> entry, and when I went checking to confirm it noticed multiple issues
> with the cron_now feature:
> 
>   * There's a hardcoded libselinux1 dependency in the binary stanza
> in debian/control, which is wrong, as that should be generated
> automatically by dpkg-shlibdeps when needed (would make part of
> the gratuitous non-linux restriction unnecessary).
> 
>   * The implementation and scaffolding for this cron_new features seems
> overly complicated and not ideal:
> 
> - It uses a python script to "patch" the original cron.c to create
>   a new command. A better, simpler and more future-proof way would
>   have been to simply patch cron.c directly.
> 
> - Builds this new command ignoring all system dpkg-buildflags, and
>   hard-codes optional features already handled as such in
>   debian/rules and the upstream build system. Making the package
>   gratuitously non-portable (unconditional use of pam, selinux and
>   audit).
> 
> - The current hardcoding includes maintainer specific system paths
>   such as «/home/georgesk/developpement/cron/collab/cron».
> 
> - Nit: could use execute_after_ to avoid calling the
>   overridden command. Or simply use stuff like debian/clean
>   instead of any dh_auto_clean override at all. But this is all
>   completely unnecessary if there is no cron_new, or if its build
>   is handled by the upstream build system.
> 
>   * There is a new interface (the cron_new program), instead of say
> adding a new option flag, which complicates the build system and
> duplicates the functionality in two programs. Is this public new
> interface in the form of a new program really justified (instead
> of simply adding a flag)?
> 
> (If you'd insist with this new cron_now interface, then this could
> be done in a better way by patching the original code in cron.c
> within «#ifdef» blocks or similar, and then modifying the upstream
> build system for this new target, taking into account build flags
> and variable features).
> 
> 
> [C] BTW, please describe what the actual changes do, writing something
> like “applied one change proposed by Helge Kreutzmann (thanks!).”
> is not very helpful and requires going to the bug report.
> 
> Thanks,
> Guillem
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1050661: proxytunnel: options to enforce IPv4 or IPv6 (compare telnet, ssh or rsync)

[Sven Geuer]

Package: proxytunnel
Version: 1.10.20210604-2
Severity: wishlist
Tags: upstream

The support of options enforcing IPv4 or IPv6 like available with telnet, ssh
or rsync would help to connect to the local (first) proxy in a special case I
encountered.

I plan to implement these options as upstream is not engaged in active
development any more.


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

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

Versions of packages proxytunnel depends on:
ii  libc62.37-7
ii  libssl3  3.0.10-1

proxytunnel recommends no packages.

Versions of packages proxytunnel suggests:
pn  ssh  

-- no debconf information

Bug#1042376: Digikam with illegal instruction on an AMD Athlon II.

[Karine Crèvecœur]

Hi,

I read the thread for this bug with attention. I use debian/sid.
Digikam version is 8.1.0-3 from debian repository.

I encounter the same bug, on my pretty old dual core :

  $ lscpu
Architecture:   x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes:  48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list:0,1
Vendor ID:  AuthenticAMD
Model name: AMD Athlon(tm) II X2 220 Processor
CPU family: 16
Model:  6
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s):  1
Stepping:   3
CPU(s) scaling MHz: 88%
CPU max MHz:2800.
CPU min MHz:800.
BogoMIPS:   5586.12
Flags:  fpu vme de pse tsc msr pae mce cx8 apic 
sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext 
fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl 
nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm 
extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt 
hw_pstate vmmcall npt lbrv svm_lock nrip_save
…

   $ cpuid -1 -l1

CPU:
   version information (1/eax):
  processor type  = primary processor (0)
  family  = 0xf (15)
  model   = 0x6 (6)
  stepping id = 0x3 (3)
  extended family = 0x1 (1)
  extended model  = 0x0 (0)
  (family synth)  = 0x10 (16)
  (model synth)   = 0x6 (6)
   miscellaneous (1/ebx):
  process local APIC physical ID = 0x1 (1)
  maximum IDs for CPUs in pkg= 0x2 (2)
  CLFLUSH line size  = 0x8 (8)
  brand index= 0x0 (0)
   brand id = 0x00 (0): unknown
   feature information (1/edx):
  x87 FPU on chip= true
  VME: virtual-8086 mode enhancement = true
  DE: debugging extensions   = true
  PSE: page size extensions  = true
  TSC: time stamp counter= true
  RDMSR and WRMSR support= true
  PAE: physical address extensions   = true
  MCE: machine check exception   = true
  CMPXCHG8B inst.= true
  APIC on chip   = true
  SYSENTER and SYSEXIT   = true
  MTRR: memory type range registers  = true
  PTE global bit = true
  MCA: machine check architecture= true
  CMOV: conditional move/compare instr   = true
  PAT: page attribute table  = true
  PSE-36: page size extension= true
  PSN: processor serial number   = false
  CLFLUSH instruction= true
  DS: debug store= false
  ACPI: thermal monitor and clock ctrl   = false
  MMX Technology = true
  FXSAVE/FXRSTOR = true
  SSE extensions = true
  SSE2 extensions= true
  SS: self snoop = false
  hyper-threading / multi-core supported = true
  TM: therm. monitor = false
  IA64   = false
  PBE: pending break event   = false
   feature information (1/ecx):
  PNI/SSE3: Prescott New Instructions = true
  PCLMULDQ instruction= false
  DTES64: 64-bit debug store  = false
  MONITOR/MWAIT   = true
  CPL-qualified debug store   = false
  VMX: virtual machine extensions = false
  SMX: safer mode extensions  = false
  Enhanced Intel SpeedStep Technology = false
  TM2: thermal monitor 2  = false
  SSSE3 extensions= false
  context ID: adaptive or shared L1 data  = false
  SDBG: IA32_DEBUG_INTERFACE  = false
  FMA instruction = false
  CMPXCHG16B instruction  = true
  xTPR disable= false
  PDCM: perfmon and debug = false
  PCID: process context identifiers   = false
  DCA: direct cache access= false
  SSE4.1 extensions   = false
  SSE4.2 extensions   = false
  x2APIC: extended xAPIC support  = false
  MOVBE instruction   = false
  POPCNT instruction  = true
  time stamp counter deadline

Bug#810908: lxc fails to register the memory consumption of the Java process (Jessie)

[Mathias Gibbens]

Control: tags -1 + moreinfo
Hi Nemanja,

  I'm sorry that no one ever responded to your bug -- is this still an
issue on a current Debian install (bullseye or bookworm)?

  Given that this is such an old bug, without additional information or
confirmation that it's still affecting a supported version of Debian
this bug will be closed in a few months.

Mathias


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

Bug#1050660: fontconfig-config: dangling symlink /etc/fonts/conf.d/10-no-sub-pixel.conf

[Jörg-Volker Peetz]

Package: fontconfig-config
Version: 2.14.2-3
Severity: normal

Dear Debian freedesktop.org maintainers,

the removal of /usr/share/fontconfig/conf.avail/10-no-sub-pixel.conf left a
dangling symlink:

/etc/fonts/conf.d/10-no-sub-pixel.conf

Regards,
Jörg.


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

Kernel: Linux 6.4.12 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages fontconfig-config depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  fonts-dejavu-core  2.37-8
ii  fonts-freefont-otf 20211204+svn4273-2
ii  fonts-liberation   1:2.1.5-3
ii  fonts-noto-core20201225-2
ii  fonts-texgyre  20180621-6
ii  fonts-urw-base35   20200910-7

fontconfig-config recommends no packages.

fontconfig-config suggests no packages.

-- debconf information:
* fontconfig/hinting_type: Native
* fontconfig/subpixel_rendering: Never
* fontconfig/enable_bitmaps: false
  fontconfig/hinting_style: hintslight

Bug#1049372: RM: gio-sharp -- RoQA; depends on gtk2; dead upstream; low popcon

[Scott Kitterman]

On Sat, 26 Aug 2023 09:21:21 +0200 Bastian Germann  wrote:
> Control: tags -1 - moreinfo
> 
> Am 26.08.23 um 01:18 schrieb Scott Kitterman:
> > Checking reverse dependencies...
> > # Broken Depends:
> > smuxi: smuxi-frontend-gnome
> > 
> > Dependency problem found.
> 
> That package is gone now.

Thanks.  I don't know why, but this one didn't show up before (or I missed 
it):

Checking reverse dependencies...
# Broken Build-Depends:
golang-github-twstrike-gotk3adapter: libgio-cil

Dependency problem found.

This also needs to be addressed.  Once again, please remove the moreinfo tag 
once it's resolved.

Scott K

Bug#1050659: libseccomp: update d/watch file

[Patrice Duroux]

Source: libseccomp
Version: 2.5.4-1
Severity: minor

Dear Maintainer,

Here is a patch for this.

Thanks,
Patrice


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

Kernel: Linux 6.5.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
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
diff --git a/debian/watch b/debian/watch
index a94a868..4af64e2 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,5 @@
 version=4
-opts="dversionmangle=s/\+dfsg//,pgpsigurlmangle=s/$/.asc/" \
-https://github.com/seccomp/libseccomp/releases \
-.*/libseccomp-(.*)\.tar\.gz
+opts="filenamemangle=s%(?:.*?)?v?@ANY_VERSION@(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%" 
\
+https://github.com/seccomp/@PACKAGE@/tags \
+(?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@
+

Bug#1043157: ITS: g3data

[Bastian Germann]

Control: retitle -1 O: g3data -- extract data from scanned graphs
Control: reassing -1 wnpp
Control: severity -1 normal

I am orphaning g3data. Please only adopt if you can afford the time
that is needed to keep the package up to date.

Description: extract data from scanned graphs
 g3data is used for extracting data from graphs.  For example, graphs
 are typically published in scientific journals without tables of the
 actual data; g3data makes the process of extracting these data easy.

Bug#1050001: Unwinding directory aliasing [and 3 more messages]

[Sam Hartman]

TL;DR: I think I understand one of Ian's points.  I explain, but do not
believe it is compelling as an argument to switch direction.

> "Helmut" == Helmut Grohne  writes:
>> I think "package management" is the wrong term here.  It's not
>> just our tools and packages that are affected.  All forms of
>> operating system management are affected: anything that changes
>> the software, and not just its configuration.
>> 
>> Affected tooling includes not just our .debs, but also remote
>> configuration management systems like Ansible, image construction
>> (Dockerfiles), and 3rd-party software installation progrmas
>> (including both 3rd-party .debs and 3rd-party script-based
>> installation systems).

Helmut> I don't follow the reasoning. Much of the tasks you'd carry
Helmut> out with (wlog) ansible - even when updating files - will
Helmut> continue to work in the aliasing layout. The reason that
Helmut> dpkg is more affected is that it has an inventory of files
Helmut> and reasons about their ownership in terms of
Helmut> packages. That's not how any kind of configuration
Helmut> management operates.  If you just "make install" something,
Helmut> chances are that it'll just work with an aliasing layout
Helmut> even when installing with --prefix=/. I continue to argue
Helmut> that the problems we are seeing are quite specific to dpkg
Helmut> in large parts.

I spent some time with Ian's paragraph you quote above trying to
understand it, and I think I got somewhere.
I considered replying yesterday but decided against, because I think we
are already seeing these effects, and have been seeing them long enough
that  we would  have a good feel for how serious the problems are.

I do think that configuration management does have enough of an
inventory of files and reasoning about structure that some of these
problems could arise.  I agree that configuration management does not
typically reason in terms of packages.

But mechanisms like

* ADD/COPY in Containerfile

* The rsync module in ansible
* The file module in Ansible

* various inventories related to modification detection in
configuration management do  reason about the filesystem.

I don't know what would happen if I did

hosts: lots
remote_user: root
name: Does this shoot me in the foot
tasks:
  - rsync: src=install_root dest=/

where install_root has a bin directory containing a couple of scripts.
I don't know if rsync will replace a symlink with a directory, or will
just write through the symlink in that situation.
If rsync happens to write through the symlink, there's probably some
other tool somewhere else thatreplaces the symlink.
And when an admin does that, they get an unbootable system, and fix
their playbook/whatever.

Similarly, I bet someone somewhere has integrity management scripts that
want to look at what pam modules are installed under /lib/security, and
depending on how it worked,
they had to adjust the config when that moved to
/lib/security/x86_64-linux-gnu and then again some of them had to adjust
when /lib became a symlink.  And they were probably frustrated during
the time when new installs had /lib as a symlink and upgrades did not.

Similarly, I bet you can run into trouble with apparmor profiles if you
try to profile /bin/python rather than /usr/bin/python or similar.

I bet people who had custom selinux policies had to adjust their
labeling rules and again some of them probably found the mixed state
where upgraded systems behaved differently than installed systems
frustrating.


I seem to recall having to make some minor adjustments at my day job
related to usrmerge back in the buster/bullseye time frame.
I don't remember what they were.

I think we've already committed to this pain, and I think we have enough
of a window into that commitment that it doesn't seem to be very much
pain.
I mean spread across all our users, yes people have had to spend
hundreds or thousands of hours dealing with this.
But that's true with any upgrade.

If we move back--if we unwind--things would get much much worse  WRT
this type of pain for a while.
I think many more things would be sensitive to /bin/perl being a symlink
than to /bin being a symlink.
You could get into situations where /usr/bin/perl and /bin/perl were
both files and differed.
You could get into situations where /bin/perl vanished on one system.
Etc.

And if we actually try to have a symlink flower patch rather than a
symlink farm, we are left with the pain of where things live differing
between distributions and releases in a distribution.

Mostly all we have left is the dpkg database.
That pain will only affect people producing debs, which isn't just us.
And yes, it will dis proportionally affect people who don't have our
infrastructure and the ability to catch problems.  Perhaps we should
think about ways to mitigate that.

There will be other smaller pains; if someone else had a system 

Bug#1050628: lua-lxc: Downgrade to lua5.1

[Mathias Gibbens]

Control: tags -1 + help

  I'm not familiar enough with lua to be comfortable making that change
myself, so tagging with help. It would seem preferable to try to use
the latest version of lua and then forward any needed changes upstream.

Mathias


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

Bug#1050625: asterisk: Downgrade to lua5.1

[debian . org]

On 2023-08-27 12:14, Jonas Smedegaard wrote:

Hi David,

Quoting debian@spam.lublink.net (2023-08-27 16:04:20)

I wrote and applied the required patch ( see attached ).


I built the asterisk package 1:20.4.0~dfsg+~cs6.13.40431414-2 and 
signed

it successfully.

I installed the new package on my local machine and tested a lua
dialplan. I connected using chan_sip+baresip, and setup a new lua
context in extensions.lua. I called this context and listened to some
menus. ( I had audio ).


Thanks a lot for the thorough testing!

I am now building the package and (unless something surprising happens)
will release it within an hour.



Since the patch only affects lua integration, I saw no reason to do
further testing.


Agreed.


Since I am a new contributor, I'll need help actually pushing this 
patch

into Salsa and Debian master.


For a change this tiny there is really no need to make a formal patch -
simply posting here on the list that you've succesfully tested a build
with build-dependency changed from liblua5.2-dev to liblua5.1-dev is
fine.



@jonas can you grant me salsa access and/or review my patch and
integrate it into salsa?


Please don't use the merge-request feature: I am not comfortable using
that, but more importantly I find it better to keep conversation about
the packaging in bugreports, not some parts in gitlab.




(In addition to concerete discussions about bugs I am happy to have
casual conversations as well, at our irc channel that we don't need to
keep track of - I just currently have trouble reaching it from matrix).

In future, please make simple git commits pushed directly to the branch
debian/latest where first line of your commit message is sensible to
list in Debian changelog - and please *don't* edit debian/changelog.
This approach makes it easier to revert or cherry-pick e.g. for a 
stable

backport, and debian/changelog is easily populated using "gpb dch" just
before building the package.


In bug #1023306 I am looking at version bumping to 3.4.0. Should I also 
commit this directly to debian/latest or should I use a branch?




Please request membership at
https://salsa.debian.org/pkg-voip-team/asterisk/-/project_members to
gain write access to the git repo.



I've sent my request. I'm waiting for approval.


(I have now disabled the MR feature for this package, which also killed
the conversation you started there - I forgot to take note of your
account so cannot invite you into the group myself).

...and while writing this the build finished and I have now pushed it 
to

Debian :-)


Nice!





Also, I ran dput, but got no response from debian masters ( probably
because I am not authorized to build the asterisk package ) .


Correct: dput works but the resulting uploaded source package gets
silently dropped because a) your OpenPGP signature is not in the list 
of
trusted Debian Developers, and b) because it was uploaded by someone 
not

trusted that someone could have forged a bogus contact address so it
won't be contacted to avoid backscatter.


thank you for the explanation.

How can I learn more about the VoIP Team workflow so that I can 
contribute more effectively ?






 - Jonas


- David

Bug#1050658: liblocale-gettext-perl: update d/watch file

[Patrice Duroux]

Package: liblocale-gettext-perl
Version: 1.07-5
Severity: minor

Dear Maintainer,

Here is a patch for.

Thanks,
Patrice


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

Kernel: Linux 6.5.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
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 liblocale-gettext-perl depends on:
ii  libc6   2.37-7
ii  perl-base [perlapi-5.36.0]  5.36.0-8

liblocale-gettext-perl recommends no packages.

liblocale-gettext-perl suggests no packages.

-- no debconf information
diff --git a/debian/watch b/debian/watch
index 9687138..e10cb1a 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,2 @@
 version=4
-
-https://metacpan.org/release/gettext   .*/gettext-v?@ANY_VERSION@@ARCHIVE_EXT@$
+https://metacpan.org/dist/Locale-gettext 
.*/Locale-gettext-v?@ANY_VERSION@@ARCHIVE_EXT@$

Bug#1050657: UDD/vcswatch importer: add support for ci_status, ci_url, merge_requests

[Lucas Nussbaum]

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

Hi,

vcswatch knows about the last pipeline status, and the number of merge
requests, in /srv/udd.debian.org/mirrors/qa.debian.org-vcswatch.

See ci_url, ci_status, merge_requests.

but UDD does not import that data.

It could also be added to DMD.

Lucas

Bug#1050629: mpv: Downgrade to lua5.1

[Bastian Germann]

Am 27.08.23 um 18:22 schrieb Sebastian Ramacher:

Shouldn't lua5.1 be removed instead of lua5.2?


It should probably be removed as well some time.
But it is not as easy to get out because there are many more packages depending 
on it.

Bug#1050629: mpv: Downgrade to lua5.1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-08-27 12:56:26 +0200, Bastian Germann wrote:
> Source: mpv
> Severity: wishlist
> Version: 0.36.0-1
> 
> Please build your package with lua5.1 so we can drop v5.2 from the archive.
> The build system supports it as fallback but you can certainly also try 
> patching to a more up to date lua version.

Shouldn't lua5.1 be removed instead of lua5.2?

Cheers
-- 
Sebastian Ramacher

Bug#1050625: asterisk: Downgrade to lua5.1

[Jonas Smedegaard]

Hi David,

Quoting debian@spam.lublink.net (2023-08-27 16:04:20)
> I wrote and applied the required patch ( see attached ).
> 
> 
> I built the asterisk package 1:20.4.0~dfsg+~cs6.13.40431414-2 and signed 
> it successfully.
> 
> I installed the new package on my local machine and tested a lua 
> dialplan. I connected using chan_sip+baresip, and setup a new lua 
> context in extensions.lua. I called this context and listened to some 
> menus. ( I had audio ).

Thanks a lot for the thorough testing!

I am now building the package and (unless something surprising happens)
will release it within an hour.


> Since the patch only affects lua integration, I saw no reason to do 
> further testing.

Agreed.


> Since I am a new contributor, I'll need help actually pushing this patch 
> into Salsa and Debian master.

For a change this tiny there is really no need to make a formal patch -
simply posting here on the list that you've succesfully tested a build
with build-dependency changed from liblua5.2-dev to liblua5.1-dev is
fine.


> @jonas can you grant me salsa access and/or review my patch and 
> integrate it into salsa?

Please don't use the merge-request feature: I am not comfortable using
that, but more importantly I find it better to keep conversation about
the packaging in bugreports, not some parts in gitlab.

(In addition to concerete discussions about bugs I am happy to have
casual conversations as well, at our irc channel that we don't need to
keep track of - I just currently have trouble reaching it from matrix).

In future, please make simple git commits pushed directly to the branch
debian/latest where first line of your commit message is sensible to
list in Debian changelog - and please *don't* edit debian/changelog.
This approach makes it easier to revert or cherry-pick e.g. for a stable
backport, and debian/changelog is easily populated using "gpb dch" just
before building the package.

Please request membership at
https://salsa.debian.org/pkg-voip-team/asterisk/-/project_members to
gain write access to the git repo.

(I have now disabled the MR feature for this package, which also killed
the conversation you started there - I forgot to take note of your
account so cannot invite you into the group myself).

...and while writing this the build finished and I have now pushed it to
Debian :-)


> Also, I ran dput, but got no response from debian masters ( probably 
> because I am not authorized to build the asterisk package ) .

Correct: dput works but the resulting uploaded source package gets
silently dropped because a) your OpenPGP signature is not in the list of
trusted Debian Developers, and b) because it was uploaded by someone not
trusted that someone could have forged a bogus contact address so it
won't be contacted to avoid backscatter.


 - 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#1050656: telegram-desktop: Bus Error whenever a channel has a video

[Shai Berger]

Package: telegram-desktop
Version: 4.8.1+ds-2+b2
Severity: important

Dear Maintainer,

Since the last update of telegram-desktop, every time I get to a video
in a channel or group, the program crashes.

I have run the program under gdb, and am attaching the traceback.
I hope it is useful.

-- Package-specific info:

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

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

Versions of packages telegram-desktop depends on:
ii  libabsl20220623  20220623.1-3
ii  libavcodec-extra60 [libavcodec60]7:6.0-5
ii  libavfilter-extra9 [libavfilter9]7:6.0-5
ii  libavformat-extra60 [libavformat60]  7:6.0-5
ii  libavutil58  7:6.0-5
ii  libc62.37-7
ii  libgcc-s113.2.0-2
ii  libglib2.0-0 2.77.2-1
ii  libglibmm-2.68-1 2.77.0-1
ii  libhunspell-1.7-01.7.2+really1.7.2-10
ii  libjpeg62-turbo  1:2.1.5-2
ii  libkf5coreaddons55.107.0-1
ii  liblz4-1 1.9.4-1
ii  libminizip1  1:1.2.13.dfsg-3
ii  libopenal1   1:1.23.1-3
ii  libopus0 1.4-1
ii  libqrcodegencpp1 1.8.0-1.1
ii  libqt5core5a [qtbase-abi-5-15-10]5.15.10+dfsg-3
ii  libqt5gui5   5.15.10+dfsg-3
ii  libqt5network5   5.15.10+dfsg-3
ii  libqt5qml5   5.15.10+dfsg-2
ii  libqt5quickwidgets5  5.15.10+dfsg-2
ii  libqt5svg5   5.15.10-2
ii  libqt5waylandcompositor5 5.15.10-2
ii  libqt5widgets5   5.15.10+dfsg-3
ii  librlottie0-10.1+dfsg-4
ii  libsigc++-3.0-0  3.4.0-7
ii  libsrtp2-1   2.5.0-3
ii  libssl3  3.0.10-1
ii  libstdc++6   13.2.0-2
ii  libswresample4   7:6.0-5
ii  libswscale7  7:6.0-5
ii  libvpx7  1.12.0-1
ii  libwayland-client0   1.22.0-2
ii  libx11-6 2:1.8.6-1
ii  libxcb-keysyms1  0.4.0-1+b2
ii  libxcb-record0   1.15-1
ii  libxcb-screensaver0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  libxxhash0   0.8.1-1
ii  libyuv0  0.0~git20230616.a366ad7-1
ii  qt5-image-formats-plugins5.15.10-2
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans   1.11-2
ii  libwebkit2gtk-4.0-37  2.40.5-1
ii  libwebkit2gtk-4.1-0   2.40.5-1

telegram-desktop suggests no packages.

Versions of packages telegram-desktop is related to:
ii  xdg-desktop-portal   1.16.0-3
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1
ii  xdg-desktop-portal-kde [xdg-desktop-portal-backend]  5.27.7-1

-- no debconf information
[2023.08.27 14:12:03] Launched version: 4008001, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2023.08.27 14:12:03] Executable dir: /usr/bin/, name: telegram-desktop
[2023.08.27 14:12:03] Initial working dir: /home/shai/Documents/
[2023.08.27 14:12:03] Working dir: /home/shai/.local/share/TelegramDesktop/
[2023.08.27 14:12:03] Command line: /usr/bin/telegram-desktop
[2023.08.27 14:12:03] Executable path before check: /usr/bin/telegram-desktop
[2023.08.27 14:12:03] Logs started
[2023.08.27 14:12:03] Launcher filename: org.telegram.desktop.desktop
[2023.08.27 14:12:03] We use allocator from /lib/x86_64-linux-gnu/libc.so.6
[2023.08.27 14:12:06] Connecting local socket to 
/tmp/735a4fdec5600e9bc6df96b79a9689ee-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2023.08.27 14:12:06] Socket connect error 0, starting server and app...
[2023.08.27 14:12:06] Moved logging from 
'/home/shai/.local/share/TelegramDesktop/log_start0.txt' to 
'/home/shai/.local/share/TelegramDesktop/log.txt'!
[2023.08.27 14:12:06] Global devicePixelRatio: 1
[2023.08.27 14:12:06] QT_AUTO_SCREEN_SCALE_FACTOR: 0
[2023.08.27 14:12:06] QT_DPI_ADJUSTMENT_POLICY: AdjustDpi
[2023.08.27 14:12:06] Primary screen DPI: 96.1263, 

Bug#1049912: FWD: Please upgrade soul to v3.0 or higher

[Preuße]

Control: tags -1 + pending

On 16.08.2023 19:48, Al Ma wrote:

Hi,

Both issues have been solved upstream; I've just tested soul 2023-06-14 
v3.1.  According to my old log files, even soul v3.0 might work.  We 
kindly ask for an upgrade of the soul package, preferrably into Debian 
12.2. Though this is not urgent, I'd personally welcome an upgrade very 
much (because these issues prevent recompilation of my old sources with 
TeX Live from Debian stable, and recompiling my old sources with the 
current upstream TeXLive 2023 doesn't work properly for different 
reasons (NewTX is partially broken; cf. 
https://tex.stackexchange.com/questions/693396)).


I'll upload v3.0 to unstable ASAP, but I won't provide a fix for Debian 
stable. Please install the updated version into your local TEXMF tree to 
get the fix.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1050180: bookworm-pu: package freeradius/3.2.1+dfsg-4+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Mon, Aug 21, 2023 at 04:16:12PM +0200, Bernhard Schmidt wrote:
> [ Reason ]
> I would like to fix a regression in the bookworm release of FreeRADIUS where
> the TLS-Client-Cert-Common-Name attribute contains the wrong value, breaking
> some use-cases (Bug#1043282)
> 
> It has been fixed in the new upstream version in sid, the two relevant commits
> apply cleanly. The reporter has confirmed that this fixes his problem.

Please go ahead.

Thanks,

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

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

Bug#1050612: rar 6.23-1~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: rar
Version: 6.23-1~deb12u1

Explanation: upstream bugfix release [CVE-2023-40477]

Bug#1050301: dgit 10.7+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: dgit
Version: 10.7+deb12u1

Explanation: use the old /updates security map only for buster

Bug#1050655: rust-rustls-webpki - autopkgtest failure.

[Peter Michael Green]

Package: rust-rustls-webpki
Version: 0.101.4-2
Severity serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-rustls-webpki/37179484/log.gz


  92s debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose', '-j64', 
'--target', 'x86_64-unknown-linux-gnu', '--all-targets', 
'--no-default-features'],) {}
  92s error: no matching package found
  92s searched package name: `rcgen`
  92s perhaps you meant:  regex or rayon
  92s location searched: registry `crates-io`
  92s required by package `rustls-webpki v0.101.4 
(/usr/share/cargo/registry/rustls-webpki-0.101.4)`
  92s autopkgtest [04:21:34]: test rust-rustls-webpki-0.101:: 
---]
  92s autopkgtest [04:21:34]: test rust-rustls-webpki-0.101::  - - - - - - - - 
- - results - - - - - - - - - -
  92s rust-rustls-webpki-0.101: FAIL non-zero exit status 101
Dev-dependencies are not feature specific, so the dependency needs to be 
present for all autopkgtests.

Bug#1050654: linux-image-6.4.0-3-amd64: Virtualbox kernel modules fail to load on linux-image-6.4.0-3-amd64

[Timothy M Dowd]

Package: src:linux
Version: 6.4.11-1
Severity: important
X-Debbugs-Cc: mrdowdsouthmo...@gmail.com

Dear Maintainer,

Upon update to kernel 6.4.0-3-amd64, Virtualbox kernel modules no longer load. 
Virtualbox works normally when booting with kernel 6.4.0-2

-- Package-specific info:
** Version:
Linux version 6.4.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-2) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC 
Debian 6.4.11-1 (2023-08-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.4.0-3-amd64 
root=UUID=ad35bc11-3df5-42f2-b165-43cd90fb4c8d ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

I looked at dmesg and didn't see anything related to Virtualbox

** Model information
sys_vendor: HP
product_name: HP Notebook
product_version: Type1ProductConfigId
chassis_vendor: Hewlett-Packard
chassis_version: Chassis Version
bios_vendor: Insyde
bios_version: F.14
board_vendor: HP
board_name: 81F1
board_version: 64.31

** Loaded modules:
rfcomm
ctr
ccm
qrtr
cmac
algif_hash
algif_skcipher
af_alg
bnep
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
btusb
btrtl
btbcm
btintel
btmtk
bluetooth
uvcvideo
videobuf2_vmalloc
jitterentropy_rng
uvc
videobuf2_memops
videobuf2_v4l2
drbg
videodev
videobuf2_common
ansi_cprng
ecdh_generic
mc
ecc
intel_powerclamp
coretemp
snd_hda_codec_hdmi
snd_ctl_led
kvm_intel
snd_hda_codec_realtek
rtl8723be
snd_hda_codec_generic
kvm
ledtrig_audio
btcoexist
rtl8723_common
rtl_pci
irqbypass
snd_hda_intel
rtlwifi
snd_intel_dspcfg
snd_intel_sdw_acpi
mac80211
snd_hda_codec
snd_hda_core
ghash_clmulni_intel
sha512_ssse3
libarc4
snd_hwdep
sha512_generic
cfg80211
snd_pcm
processor_thermal_device_pci_legacy
aesni_intel
mei_hdcp
mei_pxp
processor_thermal_device
snd_timer
joydev
hp_wmi
snd
crypto_simd
cryptd
iTCO_wdt
mei_txe
rmi_smbus
sparse_keymap
soundcore
rmi_core
intel_rapl_msr
intel_pmc_bxt
mei
processor_thermal_rfim
processor_thermal_mbox
processor_thermal_rapl
intel_cstate
pcspkr
intel_rapl_common
platform_profile
iTCO_vendor_support
at24
rfkill
watchdog
intel_xhci_usb_role_switch
wmi_bmof
roles
sg
ac
intel_int0002_vgpio
pwm_lpss_platform
intel_soc_dts_iosf
pwm_lpss
serio_raw
evdev
int3403_thermal
int3400_thermal
int340x_thermal_zone
acpi_thermal_rel
parport_pc
ppdev
lp
parport
dm_mod
fuse
loop
efi_pstore
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
crc64_rocksoft
crc64
sr_mod
crc_t10dif
cdrom
crct10dif_generic
i915
ahci
drm_buddy
i2c_algo_bit
libahci
xhci_pci
drm_display_helper
libata
cec
xhci_hcd
rc_core
ttm
drm_kms_helper
scsi_mod
usbcore
r8169
crct10dif_pclmul
crct10dif_common
realtek
i2c_i801
crc32_pclmul
mdio_devres
drm
psmouse
crc32c_intel
libphy
i2c_smbus
lpc_ich
usb_common
scsi_common
fan
battery
video
wmi
button

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug enp3s0
iface enp3s0 inet dhcp

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute 
   valid_lft forever preferred_lft forever
2: enp3s0:  mtu 1500 qdisc fq_codel state 
DOWN group default qlen 1000
link/ether 98:e7:f4:88:c3:03 brd ff:ff:ff:ff:ff:ff
inet 169.254.12.68/16 brd 169.254.255.255 scope link enp3s0:avahi
   valid_lft forever preferred_lft forever
3: wlp2s0:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
link/ether cc:b0:da:63:f1:87 brd ff:ff:ff:ff:ff:ff
inet 192.168.254.20/24 brd 192.168.254.255 scope global dynamic 
noprefixroute wlp2s0
   valid_lft 13401sec preferred_lft 13401sec
inet6 fe80::404c:717d:d383:2b62/64 scope link noprefixroute 
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:8786 100000 0  0 0 8786 
100000 0   0  0
enp3s0:   0   0000 0  0 00  
 0000 0   0  0
wlp2s0:  4288711327000 0  0 0   109879 
362000 0   0  0


** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Atom/Celeron/Pentium Processor 
x5-E8000/J3xxx/N3xxx Series SoC Transaction Register [8086:2280] (rev 35)
Subsystem: Hewlett-Packard Company Atom/Celeron/Pentium Processor 
x5-E8000/J3xxx/N3xxx Series SoC Transaction Register [103c:81f1]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-

Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'

[Thorsten Glaser]

reassign 1050429 gcc-13 13.2.0-2
notfound 1050429 12.3.0-8
affects 1050429 musl-tools
thanks

Dixi quod…

>The -EL is not even musl-specific?!
>
>(sid_mips64el-dchroot)tg@eller:~$ cat 
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
[…]

Worse, doing mips64el-linux-gnuabi64-gcc{,-12} -dumpspecs and
diffing the result, there’s no change regarding -EL either.

This looks like a genuine GCC bug? I’m reassigning.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#1049135: m17n-db: Fails to build source after successful build

[Gunnar Hjalmarsson]

Control: tags -1 + pending

Fixed in repo:

https://salsa.debian.org/input-method-team/m17n-db/-/commit/d283ffbf

Bug#1048110: sunpinyin: Fails to build source after successful build

[Gunnar Hjalmarsson]

Control: tags -1 + pending

Fixed in repo:

https://salsa.debian.org/debian/sunpinyin/-/commit/aaef82a5

Bug#1047346: ibus-table-chinese: Fails to build source after successful build

[Gunnar Hjalmarsson]

Control: tags -1 + pending

Fixed in repo:

https://salsa.debian.org/input-method-team/ibus-table-chinese/-/commit/3d8e4789

Bug#1050620: coccinelle: Drop pcre

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this as the package is 
affected by a RC bug.
The debdiff is attached.diff -Nru coccinelle-1.1.1.deb/debian/changelog 
coccinelle-1.1.1.deb/debian/changelog
--- coccinelle-1.1.1.deb/debian/changelog   2023-08-17 13:35:00.0 
+0200
+++ coccinelle-1.1.1.deb/debian/changelog   2023-08-27 17:04:39.0 
+0200
@@ -1,3 +1,10 @@
+coccinelle (1.1.1.deb-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Drop pcre support (Closes: #1050620)
+
+ -- Bastian Germann   Sun, 27 Aug 2023 17:04:39 +0200
+
 coccinelle (1.1.1.deb-4) unstable; urgency=medium
 
   * Team upload
diff -Nru coccinelle-1.1.1.deb/debian/control 
coccinelle-1.1.1.deb/debian/control
--- coccinelle-1.1.1.deb/debian/control 2023-08-17 13:35:00.0 +0200
+++ coccinelle-1.1.1.deb/debian/control 2023-08-27 17:04:39.0 +0200
@@ -9,7 +9,6 @@
  dh-python,
  libmenhir-ocaml-dev,
  libparmap-ocaml-dev,
- libpcre-ocaml-dev,
  libstdcompat-ocaml-dev,
  libpyml-ocaml-dev,
  menhir,

Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'

[Thorsten Glaser]

Dixi quod…

>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -EL
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -specs 
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
>mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL'
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -EL
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -specs 
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
>(sid_mips64el-dchroot)tg@eller:~$ _
>
>… but a regression (?) in GCC 13 versus GCC 12.

The -EL is not even musl-specific?!

(sid_mips64el-dchroot)tg@eller:~$ cat 
"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
%rename cpp_options old_cpp_options

*cpp_options:
-nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s 
%(old_cpp_options)

*cc1:
%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem 
include%s

*link_libgcc:
-L/usr/lib/mips64el-linux-musl -L .%s

*libgcc:
libgcc.a%s %:if-exists(libgcc_eh.a%s)

*startfile:
%{!shared: /usr/lib/mips64el-linux-musl/Scrt1.o} 
/usr/lib/mips64el-linux-musl/crti.o crtbeginS.o%s

*endfile:
crtendS.o%s /usr/lib/mips64el-linux-musl/crtn.o

*link:
-dynamic-linker /lib/ld-musl-mips64el.so.1 -nostdlib %{shared:-shared} 
%{static:-static} %{rdynamic:-export-dynamic}

*esp_link:


*esp_options:


*esp_cpp_options:


(sid_mips64el-dchroot)tg@eller:~$ _

There’s no -EL in that file‽ So apparently GCC 13 is breaking of itself?

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'

[Thorsten Glaser]

Dixi quod…

>According to upstream documentation, -EL is supposed to be supported
>by the compiler driver:

OK so it’s not the compiler *driver*…

(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -EL
(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -specs 
"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL'
(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -EL
(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -specs 
"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
(sid_mips64el-dchroot)tg@eller:~$ _

… but a regression (?) in GCC 13 versus GCC 12.

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#1050334: bookworm-pu: package reprepro/5.3.1-1+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Aug 23, 2023 at 01:13:43PM +0200, Helmut Grohne wrote:
> reprepro uses internal decompressors for most compression formats except
> zstd. When dealing with zstd compressed .debs (such as those for
> Ubuntu), decompression may fail due to a race condition. Naturally, this
> bug originally surfaced in Ubuntu as
> https://bugs.launchpad.net/ubuntu/+source/reprepro/+bug/2008508. While
> originally, it seemed only reproducible on s390x, it turned out that if
> you generate Contents indices, it is more widely reproducible. I can
> reliably reproduce it on Freexian infrastructure and filed #1050321.

Please go ahead.

Thanks,

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

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

Bug#1050653: emacs: fix ftbfs(workaround) on riscv64

[Bo YU]

Source: emacs
Version: 1:29.1+1-4
Severity: important
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

The emacs has ftbfs issue on riscv64 maybe due to switch to gcc-13:

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

We know the fixed/uploading is 1:28.2+1-16 but it has no chance to build
on riscv64 with the version:

https://buildd.debian.org/status/logs.php?pkg=emacs=riscv64

But Ubuntu has confirmed the bug:
https://launchpad.net/ubuntu/+source/emacs/1:28.2+1-15ubuntu1
https://bugs.launchpad.net/ubuntu/+source/gcc-12/+bug/2011487

This workaround was first suggested by Aurelien Jarno 
and I can confirm it works. Because the emacs package is very important
package so the fixing is to help Debian riscv64 official rebootstrap
currently.

I'd suggest leaving the bug open for now to trace the issue to be fixed
from upstream even if you apply this patch.:)

Thanks.

-- 
Regards,
--
  Bo YU

diff -Nru emacs-29.1+1/debian/changelog emacs-29.1+1/debian/changelog
--- emacs-29.1+1/debian/changelog   2023-08-23 13:33:41.0 +
+++ emacs-29.1+1/debian/changelog   2023-08-26 07:46:18.0 +
@@ -1,3 +1,11 @@
+emacs (1:29.1+1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Workaround to fix ftbfs issue with not with-native-compilation on
+riscv64 from Aurelien Jarno .
+
+ -- Bo YU   Sat, 26 Aug 2023 07:46:18 +
+
 emacs (1:29.1+1-4) unstable; urgency=medium
 
   * Take emacs-el from the pgtk build too to fix arch:all-only build.
diff -Nru emacs-29.1+1/debian/.gitignore emacs-29.1+1/debian/.gitignore
--- emacs-29.1+1/debian/.gitignore  2023-08-23 13:33:41.0 +
+++ emacs-29.1+1/debian/.gitignore  1970-01-01 00:00:00.0 +
@@ -1,95 +0,0 @@
-*~
-.\#*
-/*-stamp
-/.debhelper/
-/build-gtk/
-/build-pgtk/
-/build-lucid/
-/build-nox/
-/build-src/
-/build-x/
-/elgz-canary
-/elgz-info
-/emacs
-/emacs-bin-common
-/emacs-bin-common.README.Debian
-/emacs-bin-common.debhelper.log
-/emacs-bin-common.lintian-overrides
-/emacs-bin-common.postinst
-/emacs-bin-common.postrm
-/emacs-bin-common.prerm
-/emacs-bin-common.substvars
-/emacs-common
-/emacs-common.README.00
-/emacs-common.README.01
-/emacs-common.README.Debian
-/emacs-common.debhelper.log
-/emacs-common.docs
-/emacs-common.links
-/emacs-common.lintian-overrides
-/emacs-common.postinst
-/emacs-common.postinst.debhelper
-/emacs-common.postrm.debhelper
-/emacs-common.prerm
-/emacs-common.prerm.debhelper
-/emacs-common.substvars
-/emacs-el
-/emacs-el.debhelper.log
-/emacs-el.prerm
-/emacs-el.substvars
-/emacs-gtk
-/emacs-gtk.README.Debian
-/emacs-gtk.debhelper.log
-/emacs-gtk.desktop
-/emacs-gtk.links
-/emacs-gtk.lintian-overrides
-/emacs-gtk.menu
-/emacs-gtk.postinst
-/emacs-gtk.postinst.debhelper
-/emacs-gtk.postrm
-/emacs-gtk.postrm.debhelper
-/emacs-gtk.prerm
-/emacs-gtk.substvars
-/emacs-pgtk
-/emacs-pgtk.README.Debian
-/emacs-pgtk.debhelper.log
-/emacs-pgtk.desktop
-/emacs-pgtk.links
-/emacs-pgtk.lintian-overrides
-/emacs-pgtk.menu
-/emacs-pgtk.postinst
-/emacs-pgtk.postinst.debhelper
-/emacs-pgtk.postrm
-/emacs-pgtk.postrm.debhelper
-/emacs-pgtk.prerm
-/emacs-pgtk.substvars
-/emacs-lucid
-/emacs-lucid.README.Debian
-/emacs-lucid.debhelper.log
-/emacs-lucid.desktop
-/emacs-lucid.lintian-overrides
-/emacs-lucid.menu
-/emacs-lucid.postinst
-/emacs-lucid.postinst.debhelper
-/emacs-lucid.postrm.debhelper
-/emacs-lucid.prerm
-/emacs-lucid.substvars
-/emacs-nox
-/emacs-nox.README.Debian
-/emacs-nox.debhelper.log
-/emacs-nox.desktop
-/emacs-nox.links
-/emacs-nox.lintian-overrides
-/emacs-nox.menu
-/emacs-nox.postinst
-/emacs-nox.postinst.debhelper
-/emacs-nox.postrm
-/emacs-nox.postrm.debhelper
-/emacs-nox.prerm
-/emacs-nox.substvars
-/emacs.debhelper.log
-/emacs.substvars
-/files
-/stamp-configured
-/tmp-alt-list
-\#*\#
diff -Nru emacs-29.1+1/debian/rules emacs-29.1+1/debian/rules
--- emacs-29.1+1/debian/rules   2023-08-23 13:33:41.0 +
+++ emacs-29.1+1/debian/rules   2023-08-26 07:46:09.0 +
@@ -281,7 +281,7 @@
 confflags += --without-gconf
 confflags += --with-mailutils
 # At the moment, there's no mips64el libgccjitN-dev
-ifeq (,$(filter $(DEB_HOST_ARCH),mips64el s390x))
+ifeq (,$(filter $(DEB_HOST_ARCH),mips64el riscv64 s390x))
   deb_native_compilation_enabled := 1
   confflags += --with-native-compilation
 endif


signature.asc
Description: PGP signature

Bug#873171: mdadm starts arrays on boot even though AUTO -all specified if no ARRAY in mdadm.conf

[Michael]

Seems like 2 bugs.

mkconf doesn't save the "AUTO" value from the existing mdadm.conf as 
defaults:


# save existing values as defaults
if [ -r "$CONFIG" ]; then
  DEVICE="$(sed -ne 's/^DEVICE //p' $CONFIG)"
  HOMEHOST="$(sed -ne 's/^HOMEHOST //p' $CONFIG)"
  PROGRAM="$(sed -ne 's/^PROGRAM //p' $CONFIG)"
fi


and then the initramfs-tools/hooks/mdadm looks for ^ARRAY and if not 
found, it doesn't use the mdadm.conf but rather uses mkconf to generate 
which of course ignores the AUTO option.



if [ ! -f $CONFIG ]; then



else
    cp -p $CONFIG ${DESTDIR}/etc/mdadm
    sed -i '/^CREATE/s/^/#/' $DESTMDADMCONF
    if ! grep -q '^ARRAY' $CONFIG; then
    tmpfile="${DESTMDADMCONF}.tmp"
    if /usr/share/mdadm/mkconf > $tmpfile; then
    cp -p $tmpfile $DESTMDADMCONF
    rm -f $tmpfile

Bug#1043521: bookworm-pu: package systemd/252.14-1~deb12u1

[Jonathan Wiltshire]

Control: tag -1 d-i

On Sat, Aug 12, 2023 at 01:05:25PM +0100, Luca Boccassi wrote:
> We would like to upload the latest stable point release of systemd 252
> to bookworm-p-u. Stable release branches are maintained upstream with
> the intention of providing bug fixes only and no compatibility
> breakages, and with automated non-trivial CI jobs that also cover
> Debian and Ubuntu. I have already uploaded to p-u.
> 
> Debdiff attached. No packaging changes besides refreshing patches.

Looks fine to me, but adding d-i to the loop for any objections.

Thanks,

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

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

Bug#1043444: gosa-plugins-systems 2.8~git20211027.5741b8f-4+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: gosa-plugins-systems
Version: 2.8~git20211027.5741b8f-4+deb12u1

Explanation: 

Bug#1043440: slbackup-php 0.4.5-4+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: slbackup-php
Version: 0.4.5-4+deb12u1

Explanation: bug fixes: log remote commands to stderr; disable SSH known host 
files; PHP 8 compatibility

Bug#1043442: gosa-plugins-netgroups 2.8~git20211022.3b6449d-4+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: gosa-plugins-netgroups
Version: 2.8~git20211022.3b6449d-4+deb12u1

Explanation: silence deprecation warnings in web interface

Bug#1050625: asterisk: Downgrade to lua5.1

[debian . org]

Merge request is in Salsa :

https://salsa.debian.org/pkg-voip-team/asterisk/-/merge_requests/4

On 2023-08-27 10:04, debian@spam.lublink.net wrote:

I wrote and applied the required patch ( see attached ).


I built the asterisk package 1:20.4.0~dfsg+~cs6.13.40431414-2 and 
signed it successfully.


I installed the new package on my local machine and tested a lua 
dialplan. I connected using chan_sip+baresip, and setup a new lua 
context in extensions.lua. I called this context and listened to some 
menus. ( I had audio ).


Since the patch only affects lua integration, I saw no reason to do 
further testing.


Since I am a new contributor, I'll need help actually pushing this 
patch into Salsa and Debian master.


@jonas can you grant me salsa access and/or review my patch and 
integrate it into salsa?


Also, I ran dput, but got no response from debian masters ( probably 
because I am not authorized to build the asterisk package ) .


Thank you,

David

Bug#1041810: librsvg: CVE-2023-38633

[Salvatore Bonaccorso]

Hi Simon,

On Sat, Aug 19, 2023 at 06:57:30PM +0200, Salvatore Bonaccorso wrote:
> Hi Simon,
> 
> On Sun, Jul 30, 2023 at 09:48:57PM +0100, Simon McVittie wrote:
> > On Sun, 30 Jul 2023 at 22:04:24 +0200, Salvatore Bonaccorso wrote:
> > > For bullseye I think we should simply pick the upstream commit?
> > 
> > Yes: we didn't keep up with upstream 2.50.x so there are a bunch of
> > unrelated fixes (2.50.4 up to .7) which would be out of scope for a
> > security update. If it was a package I knew better then I might be
> > advocating the new upstream release, but I can't really assess risk vs
> > benefit for librsvg, so cherry-picking the equivalent of .8 and .9 seems
> > more conservative.
> > 
> > 
> > compiles successfully, I'll try it in a bullseye VM next.
> 
> If you are happy with the results and coverage from unstable, would
> you be open to prepare/finalize next the respective updates for
> bookworm-security and bullseye-security?
> 
> Thanks a lot for your work so far on it!

With some delays DSA released for it. In fact, I guess anybody running
e.g. a webservice converting untrusted svg files would sandbox anyway
such a service. Upstream correctly noted that in the upstream issue.

Thanks for your work and contributing the update!

Regards,
Salvatore

Bug#1050558: Accepted prometheus-alertmanager 0.26.0+ds-1 (source) into unstable

[Salvatore Bonaccorso]

Source: prometheus-alertmanager
Source-Version: 0.26.0+ds-1

On Sat, Aug 26, 2023 at 04:06:58PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Sat, 26 Aug 2023 15:50:44 +
> Source: prometheus-alertmanager
> Architecture: source
> Version: 0.26.0+ds-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Go Packaging Team 
> Changed-By: Daniel Swarbrick 
> Changes:
>  prometheus-alertmanager (0.26.0+ds-1) unstable; urgency=medium
>  .
>* New upstream release (fixes CVE-2023-40577)
>* Add new dependency golang-github-hashicorp-golang-lru-v2-dev
>* debian/copyright: drop superfluous trailing slashes in Files-Excluded
>* debian/rules: modernize style to match other exporter packages
>* Drop obsolete 09-Avoid_port_clash.patch
>* Convert patches to gbp-pq format
>* Add new 0007-Revert-kingpin.v2-import-path.patch
>* Drop obsolete lintian overrides
>* Refresh default alertmanager.yml config
> Checksums-Sha1:
>  e41ed5d7bacc8e2f8845d49745cc442b7fadd576 3871 
> prometheus-alertmanager_0.26.0+ds-1.dsc
>  8aa8138ed145ea81c0470e286ad56d92c1d44802 1509595 
> prometheus-alertmanager_0.26.0+ds.orig.tar.gz
>  03f50efdcc4ede24c439a0fa5f3e7f7e2ae50cda 20272 
> prometheus-alertmanager_0.26.0+ds-1.debian.tar.xz
>  eae194886954c3d5830659a569991dc28e0c7397 14540 
> prometheus-alertmanager_0.26.0+ds-1_amd64.buildinfo
> Checksums-Sha256:
>  b1d0fcca8b857214feb759f17d723b4b9da3bc451ae557e9ece49721c4b3c875 3871 
> prometheus-alertmanager_0.26.0+ds-1.dsc
>  26db3766a358d34e165fbbd176b1345a13368fa338956a70b0bc37915ded1b7e 1509595 
> prometheus-alertmanager_0.26.0+ds.orig.tar.gz
>  e4df34d93a3cbc43d06779e6a24d795106a00683523b5b365144d2daddd7c191 20272 
> prometheus-alertmanager_0.26.0+ds-1.debian.tar.xz
>  211f114126c304bf8af6902ff6789edca3724cac8ee7f2d553ca843e0968d0a6 14540 
> prometheus-alertmanager_0.26.0+ds-1_amd64.buildinfo
> Files:
>  251255697330451b80623c7f86b9b6fb 3871 net optional 
> prometheus-alertmanager_0.26.0+ds-1.dsc
>  6f9e3957a115aca761eaf0b441dafa36 1509595 net optional 
> prometheus-alertmanager_0.26.0+ds.orig.tar.gz
>  66e50225e47bffa6da0a4cd61364d43a 20272 net optional 
> prometheus-alertmanager_0.26.0+ds-1.debian.tar.xz
>  0a7998ce415a5c048db4de006280eca3 14540 net optional 
> prometheus-alertmanager_0.26.0+ds-1_amd64.buildinfo
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJKBAEBCgA0FiEEMD9oek78sa58GjWjtwAXP7uAWikFAmTqH9YWHGRzd2FyYnJp
> Y2tAZGViaWFuLm9yZwAKCRC3ABc/u4BaKfgLD/0WFcuc05QbgyLyaDgm08vY8Dd7
> MsW4eOya2aoNtqkHRY1k4B8hsnsbdCasdOunPrxhlrQK7ayEm7EMuAv2IA1XvHRP
> 120f7e1y7NjrtPcJOjQbpLyfOYRZCNSiZ5/sIefMr9Kon36u0SiOtjjly0vvhOJT
> OSMx9H+bcHdOQIhlu0+ybghBfqyrpDC+5triH/qSzQ7B3sCZv7ycJeOCIWWaoRVU
> DCdlxKEyWjGMCRxM7ryiG1EpyIDrGOi6fdl24JSrTCoRzyaglR5wi3QPo2d8mpr8
> alZ5QIsQM4CHahiWkg6907IaKMgL1nmV1kqCc3fsvMjhJqyiUCd503VNVONWmxWk
> 26XFkVO2WXydSjjA11/V7P1XmdqIctewh98IPhfyermxn9yau53uZ9wXJxOYB+sn
> ITenTJM4A3uvEENS3rx22hr6hKqUT7nANQ4CU6/rrsQQMUrzbBYUss9s6vlM4gZv
> gq39tKV39yK8HyK5vy6IB1HLIIqFWC0SSFbkgAdnceJrxxb4GKOTYNAB84cnwMrB
> pC6TpM/I9Wm8oQQm1fZy/prW4SpmRUhPNEAHlxJjG9S7v/KOhTDpMvEJCKgM0t/h
> ZksNzUVBp6mnjeTE5wYorzO6GGb9mn/iQS0zsZrCYa6JTMfnE0QwqiEthRBCu5wd
> Rdu6a+6ISbg8CS2O6g==
> =t37U
> -END PGP SIGNATURE-
> 

Bug#1050001: Unwinding directory aliasing [and 3 more messages]

[Helmut Grohne]

Hi Ian,

On Sat, Aug 26, 2023 at 11:24:33AM +0100, Ian Jackson wrote:
> Helmut Grohne writes ("Bug#1050001: Unwinding directory aliasing"):
> > On Wed, Aug 23, 2023 at 05:04:36PM +0100, Ian Jackson wrote:
> > > And, the approach being taken very seriously privileges Debian itself,
> > > and those well-staffed derivatives able to do the necessary transition
> > > auditing (albeit, indeed, with tooling from Debian).  I am
> > > firmly ideologically opposed to such a tradeoff.
> > 
> > I have difficulties disagreeing with that. Getting this done is more
> > important to me though.
> 
> I have hoisted this to the start of the mail.  I think it is a hugely
> important point.
> 
> Debian is not simply a technical project trying to thread its way in a
> complicated world.  Debian is an ideological project.  At its best,
> Debian is the infrastructrure that enables vast swathes of people to
> massively enhance their own technological autonomy.  Many of our most
> controversial decisions served this goal, and stood the test of time.
> 
> That's why *I'm* involved in Debian.  Our technical choices should
> serve those goals, always.
> 
> (To an extent, this divergence in goals may explain why at times our
> comments have been talking slightly past each other.)

I think I understand this and it resonates with me, but there are limits
to that. I don't think that Debian is that technological leader that you
perceive it to be. I hoped that other distributions would adopt the
multiarch directory layout to regain compatibility with Debian and none
did even though there is a clear, technical advantage to doing this.
Debian does not exist in isolation. It is dependent on a lot of
upstreams and in order for that relationship to be healthy, there needs
to be cooperation.

> If you want to think about it on more practical (or even, selfish)
> level, we want Debian to continue to be the preferred choice, when
> someone is choosing an upstream.  We didn't get where we are today by
> following bad technical decisions made by others.

In the grand theme of things, the aliasing symlinks may be a suboptimal
technical approach. Please keep in mind though, that this change in
large parts is about people rather than something deeply technical.
After we stopped supporting booting without /usr being mounted in the
initramfs, the split between / and /usr was effectively random and stuff
was moving back and forth every so often and inconsistent between
different distributions or releases. I still remember iptables being an
annoying instance in this regard. So leaving technical aspects aside,
having large parts of the open source community agree on having those
aliasing symlinks already is a significant benefit even if it has
technical downsides.

In order to prefer Debian over something else, we want it to be similar
enough to make switching feasible while making it differ from others
enough to make switching worthwhile. Not having aliasing symlinks hardly
seems like an aspect that makes Debian more suitable to people. I guess
that you disagree with this and that is fine.

> This is indeed a plausible practical reason to do it the aliased way.
> >From my point of view, it amounts to saying "everyone else has made
> this mistake, so to be compatible, we must too".

I wouldn't say it that way, but it comes quite close.

> But I think that seriously underestimates our influence.  Debian
> derivatives make up well over half of all Linux installations.
> They're the default basis for most CI images.  If we decide this was a
> failed experiment, then indeed there will be some pain for a while,
> but fairly soon people will stop making this assumption.

Quite evidently, we judge this differently. The two of us value the
benefit of the end states differently and the cost to getting to each of
them. Therefore we arrive at different conclusions.

> I don't like the phrase "symlink farm" because it suggests that all,
> most, or even a substantial minority, of files have these symlinks.
> True, at the start, there will be at least a symlink allotment
> but I'm hoping that in the end it'll be a symlink flowerbed.

Let me suggest that this is wishful thinking. It's not only me saying
this, but you can read this from other responses as well. I encourage
you to use codesearch.d.n to see how your flowerbed really is a farm.
Let me give some examples to get you started:
 libreoffice -> /bin/python
 ghostscript, imagemagick, mesa -> /bin/env
 bind9, manpages, net-snmp, qtbase-opensource-src -> /bin/perl

So I see that we either get a symlink farm or we get to include a lot of
Debian-specific patches or we get to argue with a lot of upstreams about
something that may seem entirely pointless to them. In any of these
cases, I consider that a significant cost.

> But pushing ahead won't lead to such a state.  As I say, I think
> people will keep introducing new references to files by their
> non-physical names, and we'll keep getting lossage, essentially
> 

Bug#1050331: bookworm-pu: package inetutils/2:2.4-2+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Aug 23, 2023 at 12:41:35PM +0200, Guillem Jover wrote:
> This update fixes a minor security issue, that the security team did
> not feel worth a DSA. It is now fixed already in unstable and testing.

Please go ahead.

Thanks,

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

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

Bug#1050651: apfsprogs FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: apfsprogs
Version: 0+git20230807+ds-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

apfsprogs fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes apfsprogs cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru apfsprogs-0+git20230807+ds/debian/changelog 
apfsprogs-0+git20230807+ds/debian/changelog
--- apfsprogs-0+git20230807+ds/debian/changelog 2023-08-07 08:29:29.0 
+0200
+++ apfsprogs-0+git20230807+ds/debian/changelog 2023-08-27 08:50:13.0 
+0200
@@ -1,3 +1,10 @@
+apfsprogs (0+git20230807+ds-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 27 Aug 2023 08:50:13 +0200
+
 apfsprogs (0+git20230807+ds-1) unstable; urgency=medium
 
   * New upstream version.
diff --minimal -Nru apfsprogs-0+git20230807+ds/debian/rules 
apfsprogs-0+git20230807+ds/debian/rules
--- apfsprogs-0+git20230807+ds/debian/rules 2023-08-07 08:29:29.0 
+0200
+++ apfsprogs-0+git20230807+ds/debian/rules 2023-08-27 08:50:12.0 
+0200
@@ -14,9 +14,9 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) -C mkapfs
-   $(MAKE) -C apfsck
-   $(MAKE) -C apfs-snap
+   dh_auto_build -D mkapfs
+   dh_auto_build -D apfsck
+   dh_auto_build -D apfs-snap
 
 override_dh_auto_install:
@echo skip install target

Bug#1042343: binutils-msp430: FTBFS: make[1]: *** [debian/rules:36: override_dh_auto_build] Error 1

[Thiago Marques]

On Sun, Aug 27, 2023 at 12:25:53PM +0200, Bastian Germann wrote:
> The stuff that is currently in debian/patches should be patched at the 
> binutils-source package (if the files were 
> available, which they are not). Please hand in your patches there and only 
> maintain binutils patches that are 
> platform-specific.
> 
> Thanks!
Hi,
Ok, I will do it.
I'm working on a new version of this package with the fix. I will use
the upstream (Texas Instruments, Inc) patch.

Regards,

Bug#1050625: asterisk: Downgrade to lua5.1

[debian . org]

I wrote and applied the required patch ( see attached ).


I built the asterisk package 1:20.4.0~dfsg+~cs6.13.40431414-2 and signed 
it successfully.


I installed the new package on my local machine and tested a lua 
dialplan. I connected using chan_sip+baresip, and setup a new lua 
context in extensions.lua. I called this context and listened to some 
menus. ( I had audio ).


Since the patch only affects lua integration, I saw no reason to do 
further testing.


Since I am a new contributor, I'll need help actually pushing this patch 
into Salsa and Debian master.


@jonas can you grant me salsa access and/or review my patch and 
integrate it into salsa?


Also, I ran dput, but got no response from debian masters ( probably 
because I am not authorized to build the asterisk package ) .


Thank you,

David-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- From 1bb7f853f963a05846f4994b0737657e2e9754d3 Mon Sep 17 00:00:00 2001
From: david 
Date: Sun, 27 Aug 2023 08:56:30 -0400
Subject: [PATCH]   * downgrade liblua dependency to 5.1 closes bug #1050625

- ---
 debian/changelog | 10 ++
 debian/control   |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 3c752b06..d36f5e39 100644
- --- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+asterisk (1:20.4.0~dfsg+~cs6.13.40431414-2) unstable; urgency=medium
+
+  [ upstream ]
+  * no change
+
+  [ David Lublink ]
+  * downgrade liblua dependency to 5.1 closes bug #1050625
+
+ -- David Lublink   Sun, 27 Aug 2023 08:54:59 -0400
+
 asterisk (1:20.4.0~dfsg+~cs6.13.40431414-1) unstable; urgency=medium
 
   [ upstream ]
diff --git a/debian/control b/debian/control
index 1e56e578..ade1e090 100644
- --- a/debian/control
+++ b/debian/control
@@ -34,7 +34,7 @@ Build-Depends:
  libjack-dev,
  libjansson-dev,
  libldap-dev,
- - liblua5.2-dev,
+ liblua5.1-dev,
  libncurses-dev,
  libneon27-dev,
  libnewt-dev,
- -- 
2.39.2

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEmsrHNiyThbxy/27E6Uk97Y34rXwFAmTrU9cACgkQ6Uk97Y34
rXx+8g/9HD3KBpIvsLgUUUrQWX7beGdt6rIzP6+v2Tjpj6tGQBvnQ3PzR24CWTSp
/68D1d0udxo+wNnglC5bNsl7GZ5qUILamefMcgq5kPHT5JT1okhRuoaRc0J7qDes
ZUtEypdshfNrJ7jnyS/in+o3EPhw3OB9tzZaOJLvs8JhJM4+UavRmr3gR5eBwExV
16QWPlKje9wuuhhvkl8YJBw+IejtYCWOOilxaEJezpL/fuWAt+BPODf9v5hsicEJ
ldQuAPd35uz238ZJhczmR2LoiY4R5PRXsjqQzNp4CZUrcVzOAXTq4FLyvL3BVgbk
X2iObdEnEEC7WRW2yCsZSP8mjY1IBuoQFhby8Lvc3IVbAtvTAACyypreP+2UVvOr
FE/lrgRj1tKOIM420jK1vfAnyRwcPiRQHfwoDOMob3o/bzrVJ2WoQc0SjIV/+yoU
zGTUs+354tnC2oFPFlS975cZ+Qx2gN0IbrY57ukuJdkKjydXmz/OSTVwgqbcLnqC
Lu6HsKb3v/V8epo7WDV2x5Kg19trvbLHDjzHA4oPwnvbJKlUmpO6E69reC103VGq
mzn0jMgK5+ITfiMJlYUp0pyXK2IgFn6Ft3aQR5+uq+BbSgbdy7spRpQIrBc5Zf5T
figB7HwRIx/ELALvKt8r3yAdGqs8X3gm2kKYekSI+pCbpnv5Wg0=
=0WlF
-END PGP SIGNATURE-

Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'

[Thorsten Glaser]

Hm.

According to upstream documentation, -EL is supposed to be supported
by the compiler driver:

https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html

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

Bug#1050335: bookworm-pu: package sitesummary/0.1.55~deb12u1

[Mike Gabriel]

Hi Jonathan,

On  So 27 Aug 2023 14:58:37 CEST, Jonathan Wiltshire wrote:


Control: tag -1 moreinfo

On Wed, Aug 23, 2023 at 01:16:11PM +0200, Mike Gabriel wrote:

While working on the initial Debian Edu release, Guido Berhöster has
worked on the sitesummary package. All changes target Debian Edu 12, so
we want to release the current version (0.1.55) to Debian bookworm (as
0.1.55~deb12u1).


I haven't looked at the diff in detail (it's quite a lot of changes) but I
notice the equivalent version in sid is failing to migrate because it is
uninstallable. Might this package be affected in the same way?


Argh. Yes. I need to resolve the CRON job script file position. Fix is  
on its way to unstable. Will re-file a similar pu-bug once that is  
settled.


Please REJECT sitesummary/0.1.55~deb12u1.

Thanks!
Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgp9ASlgKGpeN.pgp
Description: Digitale PGP-Signatur

Bug#1042147: virt-manager: FTBFS: AssertionError: Conversion outputs did not match.

[Fabio Fantoni]

after saw the autoremove from testing on 08 September for an RC and 
nobody working on it I did a search upstream for the fix, was not 
present so I created the patch and forwarded upstream 
(https://github.com/virt-manager/virt-manager/pull/559). After I created 
an MR: 
https://salsa.debian.org/libvirt-team/virt-manager/-/merge_requests/16


can someone merge and release new build before the autoremove from 
testing please?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043412: bookworm-pu: package quicktext/5.6

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Thu, Aug 10, 2023 at 04:13:22PM +0200, Mechtilde Stehmann wrote:
> This package is an extension to thunderbird. After thunderbird
> will be updated to version 115.* in bookwork
> it is necessary to update this extension too.

Thunderbird is not 115 in bookworm at present, and I'm not aware of
currently plans for that to change. Have I missed something?

Thanks,

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

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

Bug#1050650: eom: deletion fails with "Couldn't access trash."

[Adam Borowski]

Package: eom
Version: 1.26.0-2
Severity: normal

Hi!
When trying to delete a file, I get:

Error on deleting image IMG_12345678_1234_123_LL.jpg

Couldn't access trash.

In this particular case, the filesystem is mounted with jmtpfs, but I
guess this can happen for plenty other reasons.  What matters though, is
that if whatever place eom tries to stick Windows-style "trash" into
has a layout not expected by eom, it will refuse the deletion at all.

I'd expect to be able to continue.

As, unusually, I can actually test Windows' behaviour today (where you
copied this idea from), and there it doesn't block the action, instead
slightly changing the wording depending on the filesystem layout the image
resides on: "Do you want to" ... "move to trash" vs "delete" ... "?".

I also recall a system somewhere that skipped any smarts, and presented the
user with two menu entries: "move to trash", "delete".

I can't seem to find any related settings in eom's preferences, nor any
hidden but semi-obvious combinations like Shift-Del.


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc5-00086-g156eb820897e (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  eom-common   1.26.0-2
ii  gir1.2-eom-1.0   1.26.0-2
ii  libatk1.0-0  2.49.90-5
ii  libc62.37-7
ii  libcairo21.16.0-7
ii  libexempi8   2.6.4-1
ii  libexif120.6.24-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.76.1-5
ii  libgl1   1.6.0-1
ii  libgl1-mesa-glx  23.1.3-1
ii  libglib2.0-0 2.77.2-1
ii  libgtk-3-0   3.24.38-4
ii  libjpeg62-turbo  1:2.1.5-2
ii  liblcms2-2   2.14-2
ii  libmate-desktop-2-17 1.26.1-1
ii  libpeas-1.0-01.36.0-2
ii  librsvg2-2   2.54.7+dfsg-2
ii  librsvg2-common  2.54.7+dfsg-2
ii  libx11-6 2:1.8.6-1
ii  libxml2  2.9.14+dfsg-1.3
ii  mate-desktop-common  1.26.1-1
ii  shared-mime-info 2.2-1
ii  webp-pixbuf-loader   0.2.4-2
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages eom recommends:
ii  libgdk-pixbuf2.0-bin  2.42.10+dfsg-1+b1

eom suggests no packages.

-- no debconf information