Bug#1039878: gnome-shell: Many zombie xprop processes

[Stéphane Glondu]

Control: reassign -1 gnome-shell-extension-pixelsaver
Control: tags -1 - moreinfo

Le 29/06/2023 à 11:25, Simon McVittie a écrit :

I noticed there are many zombie "xprop" processes on my system, whose
parent is gnome-shell. They disappear when I restart the session, but
then start reappearing progressively.


gnome-shell doesn't have any mentions of xprop in its source code,
so this is probably a Shell extension (which run as part of the
gnome-shell process and are just as powerful as Shell itself, but with
less experienced upstream maintainers). Please disable all extensions
and see whether the problem persists.

Based on codesearch.debian.net I'm going to guess that you probably
use gnome-shell-extension-pixelsaver, which is documented as "depends
on Xorg's `xprop` and `xwininfo` utilities", and contains at least one
suspicious use of GLib.SpawnFlags.DO_NOT_REAP_CHILD which seems likely
to cause zombie processes.


Indeed, you seem to be right: after disabling this extension, xprop 
zombies are gone.



(I don't know why pixelsaver is using xprop to communicate "please don't
draw a titlebar", rather than making use of its ability to execute
arbitrary code in gnome-shell to not draw the titlebar even if the app
asked for one.)


--
Stéphane

Bug#1040821: RM: ocaml-melt -- ROM; FTBFS; dead upstream

[Stéphane Glondu]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ocaml-m...@packages.debian.org
Control: affects -1 + src:ocaml-melt

Dear FTP Team,

Please remove ocaml-melt from unstable. It has been FTBFS since 2020
and upstream seems dead.


Cheers,

-- 
Stéphane

Bug#1040771: openjdk-22 should not be in stable releases

[Matthias Klose]

Control: severity -1 important

not being available for stable releases doesn't mean it can't be available in 
testing.

Bug#1037190: closed by Debian FTP Masters (reply to Martin-Éric Racine ) (Bug#1037190: fixed in dhcpcd 10.0.1-1)

[Salvatore Bonaccorso]

Hi Martin-Éric,

On Tue, Jul 11, 2023 at 08:05:18AM +0300, Martin-Éric Racine wrote:
> On Sun, Jul 9, 2023 at 10:26 PM Martin-Éric Racine
>  wrote:
> >
> > On Sun, Jul 9, 2023 at 4:32 PM Martin-Éric Racine
> >  wrote:
> > >
> > > On Sat, Jul 8, 2023 at 12:57 PM Martin-Éric Racine
> > >  wrote:
> > > >
> > > > On Sat, Jul 8, 2023 at 12:42 PM Andreas Beckmann  
> > > > wrote:
> > > > > Thanks for fixng it in sid. Please backport the epoch related changes 
> > > > > to
> > > > > src:dhcpcd5 and get this fix into bookworm-pu over the next week s.t. 
> > > > > it
> > > > > can be included in the first point release.
> > > >
> > > > Welcome.
> > > >
> > > > I'm still missing the dhcpcd.preinst patch you submitted. I was
> > > > waiting for 10.0.1-1, which was already sitting in NEW, to get
> > > > accepted into the archive to merge it. I can do this now.
> > >
> > > The preinst in included in 10.0.1-2 and waiting on Mentors.
> > >
> > > > For bookworm-pu, I welcome feedback on any other cherry-pick since
> > > > 9.4.1-22 that would be worth including. I'll also need a sponsor to
> > > > ensure timely upload for Bookworm's point release.
> > >
> > > If you have a debdiff for Bookworm, please attach it to this bug.
> >
> > This is what I would push to stable-proposed-updates (see attachment).
> > Would this do the trick? If yes, I can upload to Mentors. If not,
> > please explain.
> 
> Package waiting on Mentors.
> 
> Btw, this will apparently also require approval by the release team,
> since it goes to s-p-u. I've never had to upload anything there, so I
> have no idea what is the procedure. Help is welcome.

Yes this is correct. There is some documentation for that in the
dev-ref at
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions

(the easiest thing to get all the metadata correctly is to use
reportbug against release.debian.org for the bookworm-pu proposed
update).

Does this helps?

Regards,
Salvatore

Bug#1040820: bash-completion: ~ (tilde) should not be quoted if a file contains a $ (dollar)

[Ben Wong]

Package: bash-completion
Version: 1:2.11-6
Severity: normal
X-Debbugs-Cc: bugs.debian@wongs.net

Dear Maintainer,

Currently, if a file with '$' (dollar sign) in it exists, Bash
completion will quote a leading '~' (tilde) and not quote the tilde.

To reproduce (where '^I' represents hitting the Tab key):

$ touch ~/'APL$FONT'

$ echo ~/APL^I
   -> echo \~/APL$FONT

As you can see, the wrong symbol was quoted. Even worse, if the $ had
been quoted using '\' (backslash), the backslash will be removed.

$ echo ~/APL\$FONT^I
   -> echo \~/APL$FONT

Note that using $HOME fails in the same ways. It does not add a
backslash and will remove one that the user types.

$ echo $HOME/APL^I
   -> echo $HOME/APL$FONT
   
$ echo $HOME/APL\$FONT^I
   -> echo $HOME/APL$FONT
   
However, replacing the ~ or $HOME with the full path does work as
it should. (Mostly. See below.)

$ echo /home/ben/APL^I
   -> echo /home/ben/APL\$FONT

I believe the following is not relevant for this bug, but I include it
for completeness.

--
Trying to use a single tick (') to quote the dollar sign does not work
and completion fails with no possibilities. However, that appears to
be a general lack in bash_completion and probably should be its own
bug.

$ echo ~/'APL^I^I
   -> echo ~/'APL

$ echo $HOME/'APL^I^I
   -> echo $HOME/'APL

$ echo /home/ben/'APL^I^I
   -> echo /home/ben/'APL

Single tick does work if at the beginning of a fully specified
pathname, but of course that doesn't help for ~ or $HOME.

$ echo '/home/ben/APL^I
   -> echo '/home/ben/APL$FONT'
   
--

By the way, I was a bit confounded debugging this. I traced through
all the functions in /usr/share/bash-completion/bash_completion and it
seems like it is correctly detecting the leading '~' and makes an
effort to avoid quoting it.

I even tried `shopt -u progcomp` and was still experiencing the bug!

The only way I could stop it was to disable tab completion completely
in Bash using `bind "set disable-completion on"`. Could it be a bug in
readline? Whatever it is, there is deeper magic going on here than I
understand.


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

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

-- no debconf information

Bug#1040819: gitlab postinst fails with gem version number parsing error

[Jakob Bohm]

Package: gitlab
Version: 15.10.8+ds1-1~fto12+1
Severity: normal

Dear Maintainer,

When trying to install gitlab (fasttrack) in a mostly blank bookworm VM,
postinst fails with the following messages:

  Setting up gitlab (15.10.8+ds1-1~fto12+1) ...
  Could not find gem 'pg (~> 1.4.5, >= 1.4.5)' in cached gems or installed
  locally.

  The source contains the following gems matching 'pg':
* pg-1.5.2
  dpkg: error processing package gitlab (--configure):
  installed gitlab package post-installation script subprocess returned
  error exit status 1

This looks like an error parsing some notation that version 1.4.5 or later
of some ruby gem is needed when version 1.5.2 is actually available.

I suspect the version relationship was expressed in a way not supported by
the only available ruby-rubygems package, but possibly by some other not
available implementation not explicitly specified as a gitlab dependency
rule.  Of cause it could be some other ruby package responsible for the
expression in the error message or its parsing.

P.S.

A mostly blank bookworm VM would consist only of bookworm core packages,
SysV init, git packages and site specific configuration of stuff such as
networking.

P.P.S.

I am not Irish, its just the only English EU locale


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (100, 
'bookworm-fasttrack'), (100, 'bookworm-backports-staging')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages gitlab depends on:
ii  apache2 [httpd] 2.4.57-2
ii  asciidoctor 2.0.18-2
ii  bc  1.07.1-3+b1
ii  bundler 2.3.15-2
ii  bzip2   1.0.8-5+b1
ii  dbconfig-pgsql  2.0.24
ii  debconf [debconf-2.0]   1.5.82
ii  fonts-font-awesome [node-font-awesome]  5.0.10+really4.7.0~dfsg-4.1
ii  gitlab-common   15.10.8+dfsg-1~bpo12+1
ii  gitlab-workhorse15.10.8+ds1-1~fto12+1
ii  katex [node-katex]  0.16.4+~cs6.1.0-1
ii  libjs-pdf [node-pdfjs-dist] 2.14.305+dfsg-2
ii  libjs-popper.js [node-popper.js]1.16.1+ds-6
ii  libruby3.1 [ruby-rexml] 3.1.2-7
ii  libssl-dev  3.0.9-1
ii  lsb-base11.6
ii  node-autosize   4.0.4~dfsg1+~4.0.0-2
ii  node-axios  1.2.1+dfsg-1
ii  node-babel-loader   9.1.0-3
ii  node-babel-plugin-lodash3.3.4+~cs2.0.1-6
ii  node-babel7 7.20.15+ds1+~cs214.269.168-3
ii  node-bootstrap  5.2.3+dfsg-8
ii  node-brace-expansion2.0.1-2
ii  node-cache-loader   4.1.0+~cs2.0.0-4
ii  node-clipboard  2.0.11+ds+~cs9.6.11-1
ii  node-compression-webpack-plugin 10.0.0-2
ii  node-copy-webpack-plugin11.0.0-3
ii  node-core-js3.26.1-3
ii  node-core-js-compat 3.26.1-3
ii  node-core-js-pure   3.26.1-3
ii  node-cron-validator 1.3.1-3
ii  node-css-loader 6.7.2+~cs14.0.11-1
ii  node-d3 5.16.0-10
ii  node-d3-selection   1.4.0-8
ii  node-dateformat 5.0.3-5
ii  node-dompurify  2.4.1+dfsg+~2.4.0-1
ii  node-exports-loader 4.0.0-1
ii  node-file-loader6.2.0-3
ii  node-fuzzaldrin-plus0.6.0+dfsg+~0.6.2-3
ii  node-glob   8.0.3+~cs8.4.15-1
ii  node-imports-loader 0.8.0-6
ii  node-jed1.1.1-4
ii  node-jquery 3.6.1+dfsg+~3.5.14-1
ii  node-jquery-ujs 1.2.3-2
ii  node-js-cookie  3.0.1+~3.0.0-3
ii  node-js-yaml4.1.0+dfsg+~4.0.5-7
ii  node-jszip  3.10.1+dfsg-1
ii  node-jszip-utils0.1.0+dfsg-1
ii  node-lodash 4.17.21+dfsg+~cs8.31.198.20210220-9
ii  node-marked 4.2.3+ds+~4.0.7-2
ii  node-minimatch  5.1.1+~5.1.2-1
ii  node-miragejs   0.1.46+~cs5.6.11-1
ii  node-mousetrap  1.6.5~ds+~1.6.8-1
ii  node-postcss8.4.20+~cs8.0.23-1
ii  node-prismjs1.29.0+dfsg+~1.26.0-1
ii  

Bug#1037190: closed by Debian FTP Masters (reply to Martin-Éric Racine ) (Bug#1037190: fixed in dhcpcd 10.0.1-1)

[Martin-Éric Racine]

On Sun, Jul 9, 2023 at 10:26 PM Martin-Éric Racine
 wrote:
>
> On Sun, Jul 9, 2023 at 4:32 PM Martin-Éric Racine
>  wrote:
> >
> > On Sat, Jul 8, 2023 at 12:57 PM Martin-Éric Racine
> >  wrote:
> > >
> > > On Sat, Jul 8, 2023 at 12:42 PM Andreas Beckmann  wrote:
> > > > Thanks for fixng it in sid. Please backport the epoch related changes to
> > > > src:dhcpcd5 and get this fix into bookworm-pu over the next week s.t. it
> > > > can be included in the first point release.
> > >
> > > Welcome.
> > >
> > > I'm still missing the dhcpcd.preinst patch you submitted. I was
> > > waiting for 10.0.1-1, which was already sitting in NEW, to get
> > > accepted into the archive to merge it. I can do this now.
> >
> > The preinst in included in 10.0.1-2 and waiting on Mentors.
> >
> > > For bookworm-pu, I welcome feedback on any other cherry-pick since
> > > 9.4.1-22 that would be worth including. I'll also need a sponsor to
> > > ensure timely upload for Bookworm's point release.
> >
> > If you have a debdiff for Bookworm, please attach it to this bug.
>
> This is what I would push to stable-proposed-updates (see attachment).
> Would this do the trick? If yes, I can upload to Mentors. If not,
> please explain.

Package waiting on Mentors.

Btw, this will apparently also require approval by the release team,
since it goes to s-p-u. I've never had to upload anything there, so I
have no idea what is the procedure. Help is welcome.

Martin-Éric

Bug#1040803: Please update dependency on libblockdev-mdraid2

[Martin Pitt]

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/19092
Control: tag -1 pending

Hello Michael,

Michael Biebl [2023-07-10 22:37 +0200]:
> the latest update of libblockdev from version 2.28 to 3.0 has seen some
> major changes, among them an SONAME bump.
>
> Please test cockpit(-storaged) against the new libblockdev and update
> the libblockdev-mdraid2 dependency to libblockdev-mdraid3.

Thanks for the heads-up! I'll fix this for this Wednesday's release, see PR
above.

Pitti

Bug#1040799: nmu: libnginx-mod-http-modsecurity_1.0.3-1+b1

[Tobias Frost]

( sent to early) please do a binnmu for bookworm:

nmu libnginx-mod-http-modsecurity_1.0.3-1+b1 . ANY . bookworm . -m "rebuild 
against pcre2 (Closes: #1037226)" 


and for unstable:

nmu libnginx-mod-http-modsecurity_1.0.3-1+b1 . ANY . unstable . -m "rebuild 
against pcre2 (Closes: #1037226)" 

> Regards,
> 
> Adam
> 
> 
> 

Bug#1039934: Acknowledgement (gcc-12: __builtin_cpu_supports does not detect SSE2 on VIA CPU, patch available)

[ValdikSS]

Can confirm that the gcc (4:12.3.0-1) from testing works correctly.
Thanks!


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040799: nmu: libnginx-mod-http-modsecurity_1.0.3-1+b1

[Tobias Frost]

On Mon, 10 Jul 2023 21:08:14 +0100 "Adam D. Barratt"  
wrote:
> Control: tags -1 + bookworm moreinfo
> 
> On Mon, 2023-07-10 at 21:55 +0200, Ervin Hegedüs wrote:
> > nmu libnginx-mod-http-modsecurity_1.0.3-1+b1 . ANY . bookworm . -m
> > "Closes: 1037226"
> 
> *Please* include information in binNMU requests that allows us to
> identify the actual problem without having to dig around. As an
> additional note, the text in the "message" argument (-m) is copied
> verbatim into changelogs, which will then be visible to users and
> anyone else viewing the changelog. It needs to be more descriptive than
> a bug number.
> 
> The BTS metadata for #1037226 indicates that it also affects unstable
> and testing. Is that correct? If so, it needs to be fixed there first.
> If not, please explain why unstable is not affected despite having
> exactly the same package version.
> 

I was in contact with Ervin and suggested him to file the binnmu -- for stable 
*and* for unstable to get #1037226 fixed.

the mentioned pr is related to a new nginx version and orthogonal to the 
problem in said bug report, beside that the the pr improves the packaging in 
that aspect. for now a rebuild suffices also for unstable.

summary of  #1037226:

That lead to the issue:

- nginx uploaded with OLD PCRE
- libnginx-mod-http-modsecurity entered NEW and had been accepted
- it uses the OLD PCRE, as it is compiled against libmodsecurity3, which uses 
PCRE at that time
- nginx uploaded with NEW PCRE2
- modsecurity uploaded with PCRE2

Situation:
nginx -> PCRE2
modsecurity -> PCRE2
libnginx-mod-http-modsecurity -> OLD PCRE

--> a binnmu will rectify that.

please do a binnmu for bookworm:

nmu libnginx-mod-http-modsecurity_1.0.3-1+b1 . ANY . bookworm . -m "rebuild 
against pcre2 (Closes: #1037226)" 



> Regards,
> 
> Adam
> 
> 
> 

Bug#1029792: Info received (Bug#1029792: sse2-support: SSE2 support not detected on VIA Eden Eshter)

[ValdikSS]

gcc has been updated with the fix for this issue
gcc (4:12.3.0-1) from testing already includes it.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040818: bookworm-pu: package libxml2/2.9.14+dfsg-1.3~deb12u1

[Salvatore Bonaccorso]

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

Hi stable release managers,

[ Reason ]
libxml2 in bookworm and older is affected by CVE-2022-2309.
The issue does not warrant a DSA, so I prepared an update to be
included in the next point release.

[ Impact ]
CVE-2022-2309 remains open for bookworm.

[ Tests ]
None specifically.

[ Risks ]
The two commits are isolated.

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

[ Changes ]
The two commits from upstream do reset ctxt->nsNr to 0 in xmlCtxtReset
(the original report) and as well in htmlCtxtReset to address the
issue in libxml2.

[ Other info ]
None.

Thanks for considering accepting the update as well for bookworm. I'm
aiming as well to do the same for bullseye-pu, but this has not been
done yet.

Regards,
Salvatore
diff -Nru libxml2-2.9.14+dfsg/debian/changelog 
libxml2-2.9.14+dfsg/debian/changelog
--- libxml2-2.9.14+dfsg/debian/changelog2023-04-15 16:25:06.0 
+0200
+++ libxml2-2.9.14+dfsg/debian/changelog2023-07-10 21:58:07.0 
+0200
@@ -1,3 +1,17 @@
+libxml2 (2.9.14+dfsg-1.3~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm
+
+ -- Salvatore Bonaccorso   Mon, 10 Jul 2023 21:58:07 +0200
+
+libxml2 (2.9.14+dfsg-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Reset nsNr in xmlCtxtReset (CVE-2022-2309) (Closes: #1039991)
+  * Also reset nsNr in htmlCtxtReset (CVE-2022-2309) (Closes: #1039991)
+
+ -- Salvatore Bonaccorso   Sat, 08 Jul 2023 21:18:29 +0200
+
 libxml2 (2.9.14+dfsg-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
libxml2-2.9.14+dfsg/debian/patches/Also-reset-nsNr-in-htmlCtxtReset.patch 
libxml2-2.9.14+dfsg/debian/patches/Also-reset-nsNr-in-htmlCtxtReset.patch
--- libxml2-2.9.14+dfsg/debian/patches/Also-reset-nsNr-in-htmlCtxtReset.patch   
1970-01-01 01:00:00.0 +0100
+++ libxml2-2.9.14+dfsg/debian/patches/Also-reset-nsNr-in-htmlCtxtReset.patch   
2023-07-10 21:58:07.0 +0200
@@ -0,0 +1,27 @@
+From: Nick Wellnhofer 
+Date: Thu, 28 Jul 2022 21:35:17 +0200
+Subject: Also reset nsNr in htmlCtxtReset
+origin: 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/a82ea25fc83f563c574ddb863d6c17d9c5abdbd2
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-2309
+Bug-Debian: https://bugs.debian.org/1039991
+
+---
+ HTMLparser.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/HTMLparser.c b/HTMLparser.c
+index 9079fa8aa52d..1520663ba2af 100644
+--- a/HTMLparser.c
 b/HTMLparser.c
+@@ -6743,6 +6743,8 @@ htmlCtxtReset(htmlParserCtxtPtr ctxt)
+ ctxt->nameNr = 0;
+ ctxt->name = NULL;
+ 
++ctxt->nsNr = 0;
++
+ DICT_FREE(ctxt->version);
+ ctxt->version = NULL;
+ DICT_FREE(ctxt->encoding);
+-- 
+2.40.1
+
diff -Nru libxml2-2.9.14+dfsg/debian/patches/Reset-nsNr-in-xmlCtxtReset.patch 
libxml2-2.9.14+dfsg/debian/patches/Reset-nsNr-in-xmlCtxtReset.patch
--- libxml2-2.9.14+dfsg/debian/patches/Reset-nsNr-in-xmlCtxtReset.patch 
1970-01-01 01:00:00.0 +0100
+++ libxml2-2.9.14+dfsg/debian/patches/Reset-nsNr-in-xmlCtxtReset.patch 
2023-07-10 21:58:07.0 +0200
@@ -0,0 +1,27 @@
+From: Nick Wellnhofer 
+Date: Mon, 18 Jul 2022 20:59:45 +0200
+Subject: Reset nsNr in xmlCtxtReset
+origin: 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/5930fe01963136ab92125feec0c6204d9c9225dc
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-2309
+Bug-Debian: https://bugs.debian.org/1039991
+
+---
+ parser.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/parser.c b/parser.c
+index d278638dd6d4..e660b0a7d499 100644
+--- a/parser.c
 b/parser.c
+@@ -14820,6 +14820,8 @@ xmlCtxtReset(xmlParserCtxtPtr ctxt)
+ ctxt->nameNr = 0;
+ ctxt->name = NULL;
+ 
++ctxt->nsNr = 0;
++
+ DICT_FREE(ctxt->version);
+ ctxt->version = NULL;
+ DICT_FREE(ctxt->encoding);
+-- 
+2.40.1
+
diff -Nru libxml2-2.9.14+dfsg/debian/patches/series 
libxml2-2.9.14+dfsg/debian/patches/series
--- libxml2-2.9.14+dfsg/debian/patches/series   2023-04-15 16:25:06.0 
+0200
+++ libxml2-2.9.14+dfsg/debian/patches/series   2023-07-10 21:58:07.0 
+0200
@@ -6,3 +6,5 @@
 schemas-Fix-null-pointer-deref-in-xmlSchemaCheckCOSS.patch
 CVE-2023-28484-Fix-null-deref-in-xmlSchemaFixupCompl.patch
 CVE-2023-29469-Hashing-of-empty-dict-strings-isn-t-d.patch
+Reset-nsNr-in-xmlCtxtReset.patch
+Also-reset-nsNr-in-htmlCtxtReset.patch

Bug#969482: ITP: glab -- An open-source GitLab command line tool

[Nicolas Schier]

FTR: Unit193 uploaded an initial version yesterday, it is pending in the new
queue.

Kind regards,
Nicolas

Bug#1040817: glibc: Please ignore some tests on sparc64

[John Paul Adrian Glaubitz]

Source: glibc
Version: 2.37-5
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi!

The list of currently failing tests on sparc64 is:

FAIL: elf/tst-audit24a
FAIL: elf/tst-audit24b
FAIL: elf/tst-audit24c
FAIL: elf/tst-audit24d
FAIL: elf/tst-rtld-run-static
FAIL: nptl/tst-cancel24-static
FAIL: nptl/tst-cancel30
FAIL: socket/tst-socket-timestamp
FAIL: stdlib/isomac

According to upstream, the following audit tests are not going to be
fixed soon since the SPARC ABI makes it more difficult:

FAIL: elf/tst-audit24a
FAIL: elf/tst-audit24b
FAIL: elf/tst-audit24c
FAIL: elf/tst-audit24d

These are going to be fixed upstream soon, the fixes are supposedly
trivial:

FAIL: elf/tst-rtld-run-static
FAIL: nptl/tst-cancel24-static
FAIL: nptl/tst-cancel30

This test is supposedly a kernel issue:

FAIL: socket/tst-socket-timestamp

And this one allegedly not related to sparc64:

FAIL: stdlib/isomac

So, my suggestion would be to ignore the following tests for now:

FAIL: elf/tst-audit24a
FAIL: elf/tst-audit24b
FAIL: elf/tst-audit24c
FAIL: elf/tst-audit24d
FAIL: socket/tst-socket-timestamp
FAIL: stdlib/isomac

And looking at the testsuite results with 32-bit tests enabled [1], it looks 
like
the failures are the same. So, I think we can just ignore the above tests and 
then
re-enable testing on 32 bit as well.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=glibc=sparc64=2.37-1=1684283585=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1040816: dgit: gpg signing fail when comment section exist in gpg key

[Boyuan Yang]

Package: dgit
Version: 10.7
Severity: normal


This looks like a rare corner case, but currently when executing
"dgit push-source --overwrite" in my dgit-enabled repo, the gpg
signing will fail. Example:


[~/src/debian/debian/a2ps] [dgit/sid]
-> % LC_ALL=C dgit push-source --overwrite
Format `3.0 (quilt)', need to check/update patch stack
canonical suite name for unstable is sid
examining quilt state (multiple patches, linear mode)
dgit: base trees orig=4a009d596d191de47129 o+d/p=f1fc1e16b704bfe79d25
dgit: quilt differences: src:  ## orig ## gitignores:  == orig ==
dgit: quilt differences:  HEAD == o+d/p   HEAD == o+d/p
starting quiltify (multiple patches, linear mode)
quiltify linearisation planning successful, executing...
nothing quilty to commit, ok.
dpkg-source: info: using options from work/debian/source/options: --extend-
diff-ignore=^(FAQ|doc/(a2ps.info|stamp-
vti|version.texi)|man/(a2ps.1|card.1|fixps.1|pdiff.1|psmandup.1|psset.1))$
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: verifying ./a2ps_4.15.5.orig.tar.gz.asc
dpkg-source: info: building a2ps using existing ./a2ps_4.15.5.orig.tar.gz
dpkg-source: info: building a2ps using existing ./a2ps_4.15.5.orig.tar.gz.asc
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building a2ps in a2ps_4.15.5-1.debian.tar.xz
dpkg-source: info: building a2ps in a2ps_4.15.5-1.dsc
changelog will contain changes since 1:4.15.5-1
dpkg-genchanges: warning: 'since' option specifies most recent version
'1:4.15.5-1', ignoring
dpkg-genchanges: info: including full source code in upload
last upload to archive: NO git hash
using existing a2ps_4.15.5.orig.tar.gz
using existing a2ps_4.15.5.orig.tar.gz.asc
using existing a2ps_4.15.5-1.debian.tar.xz
dpkg-source: info: extracting a2ps in a2ps-4.15.5
dpkg-source: info: unpacking a2ps_4.15.5.orig.tar.gz
dpkg-source: info: unpacking a2ps_4.15.5-1.debian.tar.xz
synthesised git commit from .dsc 1:4.15.5-1
nothing quilty to commit, ok.
Checking package changelog for archive version 1:4.15.5-1 ...
checking that a2ps_4.15.5-1.dsc corresponds to HEAD
dpkg-source: warning: extracting unsigned source package
(/home/hosiet/src/debian/debian/a2ps/../a2ps_4.15.5-1.dsc)
dpkg-source: info: extracting a2ps in a2ps-4.15.5
dpkg-source: info: unpacking a2ps_4.15.5.orig.tar.gz
dpkg-source: info: unpacking a2ps_4.15.5-1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 06-encoding.diff
dpkg-source: info: applying etcmakefile.-pass-arguments-to-date-to-s.patch
dpkg-source: info: applying doca2ps.texi-remove-dates-from-generated.patch
edited .changes for archive .orig contents: removed a2ps_4.15.5.orig.tar.gz
edited .changes for archive .orig contents: removed
a2ps_4.15.5.orig.tar.gz.asc
gpg: skipped "Boyuan Yang ": No secret key
gpg: signing failed: No secret key
dgit: failed command: gpg --detach-sign --armor -u 'Boyuan Yang
' /home/hosiet/src/debian/debian/a2ps/.git/dgit/tag.tmp

dgit: error: subprocess failed with error exit status 2
! Push failed, while signing the tag.
! You can retry the push, after fixing the problem, if you like.
===


Obviously dgit is trying to invoke gpg using the following argument:

gpg --detach-sign -u '$DEBFULLNAME <$DEBEMAIL>' /path/to/file

However, my gpg key has a comment section:

-> % LC_ALL=C gpg --list-secret-keys 
/home/hosiet/.gnupg/pubring.kbx
---
sec   rsa4096 2016-11-10 [SC] [expires: 2034-03-14]
  7E7729476D87D6F11D91ACCBC293E7B461825ACE
uid   [ultimate] Boyuan Yang (Debian Project) 
uid   [ultimate] Boyuan Yang <073p...@gmail.com>
uid   [ultimate] Yang, Boyuan (University of Pittsburgh)

ssb   rsa4096 2016-11-10 [E] [expires: 2034-03-13]

Which means that -u '$DEBFULLNAME <$DEBEMAIL>' will fail, and only invoking
-u '$DEBFULLNAME ($GPG_COMMENT) <$DEBMEAIL>' will success:


==
-> % LC_ALL=C gpg --sign -u 'Boyuan Yang ' ChangeLog ; echo
$?   
gpg: skipped "Boyuan Yang ": No secret key
gpg: signing failed: No secret key
2


-> % LC_ALL=C gpg --sign -u 'Boyuan Yang (Debian Project) '
ChangeLog ; echo $?
0
=

Can we make the invocation to gpg more robust? Or, can we allow using
some environment variable to provide the gpg key fingerprint used for
signature? If there is indeed such config option somewhere, please let me
know. Thanks!


Best,
Boyuan Yang


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

Bug#987753: youtube-dl: python3-xattr alternative to python3-pyxattr

[Andres Salomon]

Control: reassign -1 yt-dlp

Since youtube-dl is going away and this bug report is still relevant to 
the yt-dlp package, I'm reassigning it in case it would still be useful.


On Thu, 29 Apr 2021 02:47:57 +0200 Christoph Anton Mitterer 
 wrote:

> Package: youtube-dl
> Version: 2021.02.10-1
> Severity: wishlist
>
>
> Hi.
>
> According to youtube-dl's changelog:
> "Support pyxattr as well as python-xattr..."
> it already supports by itself both.
>
> So maybe it makes sense to list it as an explicit alternative to 
python3-pyxattr

> in the Recommends?
>
> Cheers,
> Chris.
>
>

Bug#1024216: mkchromecast: please change dependency from youtube-dl to yt-dlp

[Andres Salomon]

Control: severity -1 serious



On Wed, 04 Jan 2023 01:42:22 -0500 Andres Salomon  
wrote:
> On Wed, 16 Nov 2022 00:58:30 -0500 Andres Salomon 


> wrote:
[...]
>  >
>  > This bug is filed as normal for now, but will likely become
>  > release-critical once the new youtube-dl dummy package is 
uploaded to

>  > unstable.
>  >
>
> The new youtube-dl dummy package has now been uploaded to unstable.
> However, I'm not raising the severity on this bug because youtube-dl 
is

> only used if mkchromecast is called with '-y '. So that will now
> be broken until you switch to yt-dlp, but mkchromecast appears usable
> without that functionality.
>


I'm raising the severity of this bug now that bookworm has been 
released and we're planning to ask the ftpmasters to remove the 
youtube-dl package from sid & trixie. Please go ahead and change the 
dependency to yt-dlp instead, as it is the last package in the archive 
with a hard dependency on the youtube-dl package.

Bug#521406: bash-completion: leading tilde always expanded

[Ben Wong]

Package: bash-completion
Followup-For: Bug #521406
X-Debbugs-Cc: bugs.debian@wongs.net

Dear Maintainer,

Shouldn't this bug be closed since it was fixed? Or, if it is closed,
why is reportbug suggesting it to me in the bugs list?

Thanks.

--Ben




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

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

-- no debconf information

Bug#653837: bash-completion: Fixed. Please close.

[Ben Wong]

Package: bash-completion
Followup-For: Bug #653837
X-Debbugs-Cc: bugs.debian@wongs.net

Dear Maintainer,

This bug can be closed as it no longer occurs, at least as of version
1:2.11-6 which I just tested.

In the following, "^I" represents where I hit the Tab key and the line
after "->" shows the output after hitting Tab.

  $ dir $HOME/^I
 -> dir $HOME/

  $ dir $HOME/^I^I
... (shows files in $HOME)

  $ dir $HOM^I
 -> dir $HOME 


  



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

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

-- no debconf information

Bug#1040815: golang-gitlab-gitlab-org-labkit build-depends unsatisfiable due to version restriction.

[Peter Green]

Package: golang-gitlab-gitlab-org-labkit
Version: 1.17.0-2
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

golang-gitlab-gitlab-org-labkit build-depends on golang-google-grpc-dev:amd64 
(< 1.38~)
however the version of golang-google-grpc-dev in testing/unstable is now
1.38.0+really1.33.3-1

Bug#1040814: coq-quickchick build-depends on dropped transitional package.

[Peter Green]

Package: coq-quickchick
Version: 2.0-1
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

coq-quickchick build-depends on dune, in bullseye this was a transitional 
package
built by the ocaml-dune source package and depending on the ocaml-dune
binary package. However in ocaml-dune 3.8.2-1 the transitional package
was dropped. It is still present in unstable as a cruft package but
is completely gone from testing.

Presumablly you need to update your build-dependency to build-depend on
dune instead of ocaml-dune.

Bug#1040813: ocaml-unix-errno build-depends on dropped transitional package.

[Peter Green]

Package: ocaml-unix-errno
Version: 0.6.1-2
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

ocaml-pprint build-depends on dune, in bullseye this was a transitional package
built by the ocaml-dune source package and depending on the ocaml-dune
binary package. However in ocaml-dune 3.8.2-1 the transitional package
was dropped. It is still present in unstable as a cruft package but
is completely gone from testing.

Presumablly you need to update your build-dependency to build-depend on
dune instead of ocaml-dune.

Bug#1040812: ocaml-pprint build-depends on dropped transitional package.

[Peter Green]

Package: ocaml-pprint
Version: 20220103-1
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

ocaml-pprint build-depends on dune, in bullseye this was a transitional package
built by the ocaml-dune source package and depending on the ocaml-dune
binary package. However in ocaml-dune 3.8.2-1 the transitional package
was dropped. It is still present in unstable as a cruft package but
is completely gone from testing.

Presumablly you need to update your build-dependency to build-depend on
dune instead of ocaml-dune.

Bug#1040811: ocaml-mm build-depends on dropped transitional package.

[Peter Green]

Package: ocaml-mm
Version: 0.8.1-1
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

ocaml-mm build-depends on dune, in bullseye this was a transitional package
built by the ocaml-dune source package and depending on the ocaml-dune
binary package. However in ocaml-dune 3.8.2-1 the transitional package
was dropped. It is still present in unstable as a cruft package but
is completely gone from testing.

Presumablly you need to update your build-dependency to build-depend on
dune instead of ocaml-dune.

Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)

[Huacai Chen]

On Mon, Jul 10, 2023 at 4:14 PM Jiaxun Yang  wrote:
>
> Hi all,
>
> I don't have much idea on firmware, so I don't know if firmware update
> is possible
> for that system.
>
> @Huacai, is it acceptable to revert MRRS/MPS workaround patch all MIPS based
> Loongson system? Or leave a cmdline option to configure workaround type?
Contact the machine provider to get new firmwares?

Huacai
>
> Thanks
> - Jiaxun
>
> 在 2023/7/8 18:11, Aurelien Jarno 写道:
> > Hi,
> >
> > On 2023-06-24 11:46, Aurelien Jarno wrote:
> >> Hi,
> >>
> >> On 2023-06-19 09:37, Huacai Chen wrote:
> >>> On Sun, Jun 18, 2023 at 5:24 PM Aurelien Jarno  wrote:
>  Hi,
> 
>  On 2023-05-07 19:22, Jiaxun Yang wrote:
> >
> >> 2023年5月6日 01:58，YunQiang Su  写道：
> >>
> >> Aurelien Jarno  于2023年5月6日周六 04:30写道：
> >>> Source: linux
> >>> Version: 5.10.178-3
> >>> Severity: important
> >>> X-Debbugs-Cc: d...@debian.org, debian-m...@lists.debian.org, 
> >>> s...@debian.org
> >>>
> >>> Following the point release, the buildd mipsel-osuosl-03.d.o does not
> >>> boot anymore, with errors in the AHCI controller:
> >>>
> >>> [   35.912147] ata4.00: exception Emask 0x0 SAct 0x2000 SErr 0x0 
> >>> action 0x6 frozen
> >>> [   35.919769] ata4.00: failed command: WRITE FPDMA QUEUED
> >>> [   35.924968] ata4.00: cmd 61/20:e8:00:f0:e1/00:00:00:00:00/40 tag 
> >>> 29 ncq dma 16384 out
> >>> [   35.924968]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 
> >>> 0x4 (timeout)
> >>> [   35.940097] ata4.00: status: { DRDY }
> >>> [   35.943743] ata4: hard resetting link
> >>>
> >>> While that initially looks like a hardware issue, it appears that
> >>> reverting the kernel to 5.10.162-1 (from 5.10.178-3) fixes the issue.
> >>> Strangely mipsel.osuosl-05.d.o, which seems to be similar hardware 
> >>> (CPU,
> >>> motherboard and SATA drive), does not exhibit the same issue.
> >>>
> >> Maybe the different firmwares are used for them...
> >> CCed Huacai and Jiaxun.
> > I’m unable to reproduce on my side. Perhaps different hardware.
> > Is it possible to bisect Kernel on that machine to see of reverting 
> > that two commits do help?
>  I have bisected the issue and I confirm the intuition from Cyril. The
>  first bad commit is 654ae539254d10042869fdc77ad04c09e7eff1fd. Reverting
>  both commits (they are linked) indeed fixes the issue.
> >>> Seems a firmware bug, latest firmware should configure a suitable MRRS.
> >> Ok, thanks for the feedback. Given it's not a kernel bug, I am closing
> >> it.
> >>
> >> That said, can someone please send us the procedure to upgrade the
> >> firmware on this machine, so that we can continue using it as a buildd?
> > Any news about that? We need to be able to run the latest stable kernel
> > on the build daemon.
> >
> > Thanks,
> > Aurelien
> >
>

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Dirk Eddelbuettel]

On 10 July 2023 at 19:43, Dirk Eddelbuettel wrote:
| Someone simply didn't update our Debian package, so it lacks this change and
| fingers point at r-base when the fault, if there is one, is to let our
| package slip behind a compilation and code standard established at CRAN for
| the R 4.3.0 relese in April.
| 
| I still have hopes that we can let technical excellence rule and not require
| blunt instruments such as forced recompilation.
| 
| Because with slips like this, even forcing recompilation of over 1000+
| sources packages times 10+ architectures (for binary-any) will not help
| against stale code, and hence mismatched expectations in the language engine
| (r-base) and its client packages. 

I should have double-checked. 1.22.1-1 is in unstable, so that is good, and
hence works with R 4.3.[01].  So what tripped me up is the (known, and
expected, if "you know") failure in the (hence not all that informative)
autopkgtest of trying R 4.3.1 with the outdated maldiquant 1.22 (not 1.22.1).

I am not versed well-enough in the mechanics of release details. If the only
way to get r-base into testing consists of having a Breaks for
r-cran-maldiquant (<< 1.22.1) then I guess that is what we need to do.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Dirk Eddelbuettel]

Paul,

Here is a case in point from looking at the current excluses list (which is
by now indeed a little shorter).

One package that jumps out is r-cran-maldiquant. We are at version 1.22, with
Debian build 1.22-1.

But one second at the CRAN site and the page for the package shows that it is
upstream at 1.22.1, since March, with a sole entry in NEWS being

  CHANGES IN MALDIquant VERSION 1.22.1 [2023-03-20]:
  --

  * Use symbols instead of names in `.Call` for faster lookup of C functions.

So there it is.

Someone simply didn't update our Debian package, so it lacks this change and
fingers point at r-base when the fault, if there is one, is to let our
package slip behind a compilation and code standard established at CRAN for
the R 4.3.0 relese in April.

I still have hopes that we can let technical excellence rule and not require
blunt instruments such as forced recompilation.

Because with slips like this, even forcing recompilation of over 1000+
sources packages times 10+ architectures (for binary-any) will not help
against stale code, and hence mismatched expectations in the language engine
(r-base) and its client packages. 

Best,  Dirk


-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1040716: libc6: Stack Traces

[Tim McConnell]

On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2023-07-09 17:15, Tim McConnell wrote:
> > Hi Aurelien, 
> > The Stack Traces started showing up in my System Event logs
> > yesterday
> > and has totaled up to 18 times so far. As far as issues, the system
> > is
> > slower than usual and occasionally freezes. 
> >  I ran apt-file search lib.so and came up with libc6 so that's
> > where I
> > filed the bug. I tried running gdb on it (libc6) and it told me
> > file
> > not found, I'd be happy to give more information just tell me how
> > to
> > get it. 
> 
> Thanks for the details, however I am afraid it is not enough. libc6
> is a
> library, for understanding the issue, I would need to know by which
> program it is used in the corresponding stack traces. The issue might
> not be in the library but in another library or another program. Do
> you
> have some more log entries around those stack traces?
> 
> All that said, it appears that the locales package in versions 2.37-2
> to
> 2.37-4 is buggy and might cause random crashes in libc6. You might
> want
> to upgrade to version 2.37-5 to check if it solves your issue. The
> package is currently only available in sid, but it is expected to
> migrate to testing in the next days.
> 
> Regards
> Aurelien
> 
Checking Journalctl I found this: 
Jul 10 19:02:11 DebianTim systemd-coredump[3869]: [] Process 992
(collectd) of user 0 dumped core.
  
  Module libudev.so.1
from deb systemd-252.11-1.amd64
  Stack trace of thread
1424:
  #0 
0x7f7cbbfce9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2)
  #1 
0x7f7cbbd856d9 rrd_write (librrd.so.8 + 0x346d9)
  #2 
0x7f7cbbd90acd n/a (librrd.so.8 + 0x3facd)
  #3 
0x7f7cbbd92962 n/a (librrd.so.8 + 0x41962)
  #4 
0x7f7cbbdec370 n/a (rrdtool.so + 0x3370)
  #5 
0x7f7cbbee93ec start_thread (libc.so.6 + 0x883ec)
  #6 
0x7f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c)
  
  Stack trace of thread
1431:
  #0 
0x7f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
  #1 
0x7f7cbbee8afc __pthread_cond_wait_common (libc.so.6 + 0x87afc)
  #2 
0x5586e89f93a2 n/a (collectd + 0x123a2)
  #3 
0x7f7cbbee93ec start_thread (libc.so.6 + 0x883ec)
  #4 
0x7f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c)
  
  Stack trace of thread
1432:
  #0 
0x7f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
  #1 
0x7f7cbbee8afc __pthread_cond_wait_common (libc.so.6 + 0x87afc)
  #2 
0x5586e89f93a2 n/a (collectd + 0x123a2)
  #3 
0x7f7cbbee93ec start_thread (libc.so.6 + 0x883ec)
  #4 
0x7f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c)
  
  Stack trace of thread
1427:
  #0 
0x7f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
  #1 
0x7f7cbbee8818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
  #2 
0x5586e89f7d1b n/a (collectd + 0x10d1b)
  #3 
0x7f7cbbee93ec start_thread (libc.so.6 + 0x883ec)
  #4 
0x7f7cbbf69a1c __clone3 (libc.so.6 + 0x108a1c)
  
  Stack trace of thread
1429:
  #0 
0x7f7cbbee6156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
  #1 
0x7f7cbbee8818 __pthread_cond_wait_common (libc.so.6 + 0x87818)
  #2 
0x5586e89f7d1b n/a (collectd + 0x10d1b)
  Stack trace of 

Bug#1040810: ITP: readpe -- command-line tools to manipulate Windows PE files

[David da Silva Polverari]

Package: wnpp
Severity: wishlist
Owner: David da Silva Polverari 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: readpe
  Version : 0.82
  Upstream Contact: https://github.com/mentebinaria/readpe/issues
* URL : https://github.com/mentebinaria/readpe
* License : GPL-2+ with OpenSSL Exception
  Programming Lang: C
  Description : command-line tools to manipulate Windows PE files

readpe is a toolkit designed to analyze Microsoft Windows PE (Portable
Executable) binary files.  Its tools can parse and compare PE32/PE32+
executable files (EXE, DLL, OCX, etc), and analyze them in search of
suspicious characteristics.

It can be used to get information from those executable files, such as
headers, sections, resources and more. It also provides tools to disassemble
PE files and determine their security mitigations.  It is useful for
application security research, digital forensics and incident response, and
malware analysis.

It is similar to elftools, only designed for PE files. It has more features
than other more specific PE tools, such as icoextract or ntldd.

This package provides the ofs2rva, pedis, pehash, peldd, pepack, peres,
pescan, pesec, pestr, readpe and rva2ofs commands.

This package is a newer version of the pev package (already maintained
in Debian by me), as upstream renamed it to readpe. I plan to maintain
it inside the pkg-security team umbrella.

Bug#1040716: libc6: Stack Traces

[Tim McConnell]

On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2023-07-09 17:15, Tim McConnell wrote:
> > Hi Aurelien, 
> > The Stack Traces started showing up in my System Event logs
> > yesterday
> > and has totaled up to 18 times so far. As far as issues, the system
> > is
> > slower than usual and occasionally freezes. 
> >  I ran apt-file search lib.so and came up with libc6 so that's
> > where I
> > filed the bug. I tried running gdb on it (libc6) and it told me
> > file
> > not found, I'd be happy to give more information just tell me how
> > to
> > get it. 
> 
> Thanks for the details, however I am afraid it is not enough. libc6
> is a
> library, for understanding the issue, I would need to know by which
> program it is used in the corresponding stack traces. The issue might
> not be in the library but in another library or another program. Do
> you
> have some more log entries around those stack traces?
> 
> All that said, it appears that the locales package in versions 2.37-2
> to
> 2.37-4 is buggy and might cause random crashes in libc6. You might
> want
> to upgrade to version 2.37-5 to check if it solves your issue. The
> package is currently only available in sid, but it is expected to
> migrate to testing in the next days.
> 
> Regards
> Aurelien
> 
I'll check journalctl and see if that has better info. I'll also
upgrade the package you were talking about to see if it fixes the issue
. I will let you know.  

Bug#1040807: debian-reference: typo hdparam(8) -> hdparm(8)

[肖盛文]

Control: tags -1 pending

Thanks for your report.

Fixed in salsa:
https://salsa.debian.org/debian/debian-reference/-/commit/13f25579d11745782272c5bf29ae0ef98f450432


在 2023/7/11 07:36, sohplz+95lz11mflatts@cs.email 写道:

Package: debian-reference
Severity: normal

Dear Maintainer,

In 9.6.9. of debian-reference there is the typo 'hdparam(8)', it should instead 
be 'hdparm(8)'



--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040809: bugs.debian.org: Horizontal Flicker after pressing Enter on Gnome Login

[Aleks]

Package: bugs.debian.org
Severity: important
X-Debbugs-Cc: sekto...@gmx.de

Dear Maintainer,

   * What led up to the situation?
This occurred on a fresh bookworm installation after upgrading the kernel from
6.1.0-9-amd64 to 6.1.0-10-amd64. Another user reported the same issue here:
https://www.reddit.com/r/debian/comments/14s8nda/kernel_update_broke_my_debian_stable_61010/.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I updated the system via Gnome Software and rebooted as suggested.

   * What was the outcome of this action?
The system booted normally to Gnome login screen. Then, after pressing enter, a
horizontal flicker came up like this: https://imgbb.com/NtgZN7v (from the above
post). The password entry dialog is not shown. By the way, I think the OP from
reddit uses a HP notebook like me.

   * What outcome did you expect instead?
I expected to see the standard password login prompt of Gnome to enter my
password.


All works well when booting kernel 6.1.0-9-amd64.

Can I provide something additional that helps?

A

Bug#1040808: ITP: golang-github-hashicorp-terraform-config-inspect -- helper library for shallow inspection of Terraform configurations

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-hashicorp-terraform-config-inspect
  Version : 0.0~git20230614.f32df32-1
  Upstream Author : HashiCorp, Inc.
* URL : https://github.com/hashicorp/terraform-config-inspect
* License : MPL-2.0
  Programming Lang: Go
  Description : helper library for shallow inspection of Terraform 
configurations

 terraform-config-inspect is a helper library and CLI tool for extracting
 high-level metadata about Terraform modules from their source code. It
 processes only a subset of the information Terraform itself would process,
 and in return it's able to be broadly compatible with modules written for
 many different versions of Terraform.
 .
 The primary way to use this is as a Go library, but as a convenience it
 also contains a CLI tool called terraform-config-inspect that allows
 viewing module information in either a Markdown-like format or in JSON
 format.

Reason for packaging: Needed by terraform-switcher (ITP: #1014440)

Bug#1040806: [3dprinter-general] Bug#1040806: cura-engine: ADT failure "Trying to retrieve setting with no value given: 'adhesion_extruder_nr'"

[Gregor Riepl]

Hi Dan,


Visible in both Sid and Ubuntu Mantic is the following autopkgtest error:
[ERROR] Trying to retrieve setting with no value given: 'adhesion_extruder_nr'

See the attached patch, which is just a trivial backport of
https://github.com/Ultimaker/CuraEngine/pull/1693


Thanks for that patch, it looks like it's still relevant for cura-engine 
5.0.0: 
https://ci.debian.net/data/autopkgtest/testing/amd64/c/cura-engine/35613243/log.gz


I'll test it and see if it helps.

sid and trixie will get cura-engine 5.0.0 as soon as some remaining 
issues are fixed. We've had to hold back with the release before 
bookworm due to a lack of time, unfortunately.


Since bookworm is stuck with 4.13, the patch might also be a candidate 
there.


Regards,
Gregor

Bug#1040807: debian-reference: typo hdparam(8) -> hdparm(8)

[sohplz+95lz11mflatts]

Package: debian-reference
Severity: normal

Dear Maintainer,

In 9.6.9. of debian-reference there is the typo 'hdparam(8)', it should instead 
be 'hdparm(8)'

Bug#1040806: cura-engine: ADT failure "Trying to retrieve setting with no value given: 'adhesion_extruder_nr'"

[Dan Bungert]

Source: cura-engine
Version: 1:4.13.0-1build1
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

Visible in both Sid and Ubuntu Mantic is the following autopkgtest error:
[ERROR] Trying to retrieve setting with no value given: 'adhesion_extruder_nr'

See the attached patch, which is just a trivial backport of
https://github.com/Ultimaker/CuraEngine/pull/1693

(I submitted this bug twice before, if duplicates show up later for some
reason please forgive me)

-Dan
Description: Fix ADT - setting with no value given: 'adhesion_extruder_nr'
Origin:  
https://github.com/Ultimaker/CuraEngine/pull/1693/commits/adecda53fff5c77ccf43a54ee37d5654a4032858
Bug-Ubuntu:  https://bugs.launchpad.net/bugs/2026769
Bug: https://github.com/Ultimaker/CuraEngine/pull/1693
Forwarded:   not-needed
Last-Update: 2023-07-10
--- a/src/raft.cpp
+++ b/src/raft.cpp
@@ -18,7 +18,7 @@
 void Raft::generate(SliceDataStorage& storage)
 {
 assert(storage.raftOutline.size() == 0 && "Raft polygon isn't generated 
yet, so should be empty!");
-const Settings& settings = 
Application::getInstance().current_slice->scene.current_mesh_group->settings.get("adhesion_extruder_nr").settings;
+const Settings& settings = 
Application::getInstance().current_slice->scene.current_mesh_group->settings.get("raft_base_extruder_nr").settings;
 const coord_t distance = settings.get("raft_margin");
 constexpr bool include_support = true;
 constexpr bool include_prime_tower = true;
@@ -51,16 +51,19 @@
 
 coord_t Raft::getTotalThickness()
 {
-const ExtruderTrain& train = 
Application::getInstance().current_slice->scene.current_mesh_group->settings.get("adhesion_extruder_nr");
-return train.settings.get("raft_base_thickness")
-+ train.settings.get("raft_interface_layers") * 
train.settings.get("raft_interface_thickness")
-+ train.settings.get("raft_surface_layers") * 
train.settings.get("raft_surface_thickness");
+const Settings& mesh_group_settings 
=Application::getInstance().current_slice->scene.current_mesh_group->settings;
+const ExtruderTrain& base_train = 
mesh_group_settings.get("raft_base_extruder_nr");
+const ExtruderTrain& interface_train = 
mesh_group_settings.get("raft_interface_extruder_nr");
+const ExtruderTrain& surface_train = 
mesh_group_settings.get("raft_surface_extruder_nr");
+return base_train.settings.get("raft_base_thickness")
++ interface_train.settings.get("raft_interface_layers") * 
interface_train.settings.get("raft_interface_thickness")
++ surface_train.settings.get("raft_surface_layers") * 
surface_train.settings.get("raft_surface_thickness");
 }
 
 coord_t Raft::getZdiffBetweenRaftAndLayer1()
 {
 const Settings& mesh_group_settings = 
Application::getInstance().current_slice->scene.current_mesh_group->settings;
-const ExtruderTrain& train = 
mesh_group_settings.get("adhesion_extruder_nr");
+const ExtruderTrain& train = 
mesh_group_settings.get("raft_surface_extruder_nr");
 if (mesh_group_settings.get("adhesion_type") != 
EPlatformAdhesion::RAFT)
 {
 return 0;
@@ -94,12 +97,15 @@
 
 size_t Raft::getTotalExtraLayers()
 {
-const ExtruderTrain& train = 
Application::getInstance().current_slice->scene.current_mesh_group->settings.get("adhesion_extruder_nr");
-if (train.settings.get("adhesion_type") != 
EPlatformAdhesion::RAFT)
+const Settings& mesh_group_settings 
=Application::getInstance().current_slice->scene.current_mesh_group->settings;
+const ExtruderTrain& base_train = 
mesh_group_settings.get("raft_base_extruder_nr");
+const ExtruderTrain& interface_train = 
mesh_group_settings.get("raft_interface_extruder_nr");
+const ExtruderTrain& surface_train = 
mesh_group_settings.get("raft_surface_extruder_nr");
+if (base_train.settings.get("adhesion_type") != 
EPlatformAdhesion::RAFT)
 {
 return 0;
 }
-return 1 + train.settings.get("raft_interface_layers") + 
train.settings.get("raft_surface_layers") + getFillerLayerCount();
+return 1 + interface_train.settings.get("raft_interface_layers") + 
surface_train.settings.get("raft_surface_layers") + 
getFillerLayerCount();
 }
 
 
--- a/src/sliceDataStorage.cpp
+++ b/src/sliceDataStorage.cpp
@@ -595,12 +595,15 @@
 }
 
 coord_t adhesion_size = 0; //Make sure there is enough room for the 
platform adhesion around support.
-const ExtruderTrain& adhesion_extruder = 
mesh_group_settings.get("adhesion_extruder_nr");
+const ExtruderTrain& base_train = 
mesh_group_settings.get("raft_base_extruder_nr");
+const ExtruderTrain& interface_train = 
mesh_group_settings.get("raft_interface_extruder_nr");
+const ExtruderTrain& surface_train = 
mesh_group_settings.get("raft_surface_extruder_nr");
+const ExtruderTrain& skirt_brim_train = 
mesh_group_settings.get("skirt_brim_extruder_nr");
 coord_t extra_skirt_line_width = 0;
 const std::vector is_extruder_used = getExtrudersUsed();
   

Bug#858337: apt-show-versions: wrong output when version of an installed package is missing from the Packages files

[Vincent Lefevre]

Hi Christoph,

On 2023-07-10 16:36:56 +0200, Christoph Martin wrote:
> Am 05.07.23 um 12:13 schrieb Vincent Lefevre:
> > Control: retitle -1 apt-show-versions gives unreliable information
> > Control: severity -1 grave
> 
> I still can not reproduce your problem.
> 
> Please try to find out, which value is missing in a Packages file, which
> triggers this error, so that I can reproduce the problem.

/var/lib/apt/lists/ftp.debian.org_debian_dists_unstable_main_binary-amd64_Packages
contains

Package: libreoffice-common
Source: libreoffice
Version: 4:7.5.4-4
Installed-Size: 57718
Maintainer: Debian LibreOffice Maintainers 
Architecture: all
[...]

So this appears to be correct.

Only the "Architecture: all" packages seem to be affected:

cventin:~> apt-show-versions -u | grep manually
fonts-opensymbol:all/experimental *manually* upgradeable from 
4:102.12+LibO7.5.4-4 to 4:102.12+LibO7.5.5~rc1-2
liblibreoffice-java:all/experimental *manually* upgradeable from 4:7.5.4-4 to 
4:7.5.5~rc1-2
libreoffice-common:all/experimental *manually* upgradeable from 4:7.5.4-4 to 
4:7.5.5~rc1-2
libreoffice-java-common:all/experimental *manually* upgradeable from 4:7.5.4-4 
to 4:7.5.5~rc1-2
libreoffice-nlpsolver:all/experimental *manually* upgradeable from 
4:0.9+LibO7.5.4-4 to 4:0.9+LibO7.5.5~rc1-2
libreoffice-report-builder:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-script-provider-bsh:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-script-provider-js:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-script-provider-python:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-style-colibre:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-style-elementary:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-wiki-publisher:all/experimental *manually* upgradeable from 
4:1.2.0+LibO7.5.4-4 to 4:1.2.0+LibO7.5.5~rc1-2
libunoloader-java:all/experimental *manually* upgradeable from 4:7.5.4-4 to 
4:7.5.5~rc1-2

FYI, the output for an "Architecture: all" package vs the output
of an arch-dependent package:

cventin:~> apt-show-versions -a libreoffice-common
libreoffice-common:all 4:7.5.4-4 install ok installed
libreoffice-common:all 4:7.4.5-3 stable   ftp.debian.org
No stable-updates version
libreoffice-common:all 4:7.4.5-3 testing  ftp.debian.org
libreoffice-common:all 4:7.4.5-3 unstable ftp.debian.org
libreoffice-common:all 4:7.5.5~rc1-2 experimental ftp.debian.org
libreoffice-common:all/experimental *manually* upgradeable from 4:7.5.4-4 to 
4:7.5.5~rc1-2

cventin:~> apt-show-versions -a libreoffice
libreoffice:amd64 4:7.5.4-4 install ok installed
libreoffice:amd64 4:7.4.5-3 stable   ftp.debian.org
No stable-updates version
libreoffice:amd64 4:7.4.5-3 testing  ftp.debian.org
libreoffice:amd64 4:7.5.4-4 unstable ftp.debian.org
libreoffice:amd64 4:7.5.5~rc1-2 experimental ftp.debian.org
libreoffice:amd64/unstable 4:7.5.4-4 uptodate
libreoffice:i386 4:7.4.5-3 stable   ftp.debian.org
No stable-updates version
libreoffice:i386 4:7.4.5-3 testing  ftp.debian.org
libreoffice:i386 4:7.4.5-3 unstable ftp.debian.org
libreoffice:i386 4:7.5.5~rc1-2 experimental ftp.debian.org
libreoffice:i386 not installed

Note that for the foreign architecture:

/var/lib/apt/lists/ftp.debian.org_debian_dists_unstable_main_binary-i386_Packages
contains

Package: libreoffice-common
Source: libreoffice
Version: 4:7.4.5-3
Installed-Size: 58639
Maintainer: Debian LibreOffice Maintainers 
Architecture: all
[...]

because of a build failure for 4:7.5.4-4 on i386:

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

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

Bug#1038191: dosbox: Depends on SDL 1.2

[Alexandre Detiste]

The most sensible thing would be to switch to an alive fork: dosbox-x

See also:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022779

Greetings

Bug#1024997: what kind of bug was it?

[Preuße]

On 01.07.2023 05:39, Junichi Uekawa wrote:

On Sat, 01 Jul 2023 06:35:06 +0900,
Preuße, Hilmar wrote:


Hello Junichi,


To be honest: I don't really care. I know the issue is solved in
texinfo 7.0.x, hence I perform no further investigation. Uploading TI
7.0 to unstable however will break a few packages [1], currently I'm
waiting that at least the new version of octave hits unstable.

If you think this could be a security issue, let me know.


As bookworm shipped with this bug which dumps some kind of corrupted
buffer content, I am concerned this can be a security issue.

I've uploaded TeXInfo 7.0.x to unstable, so in theory on could close the 
issue. If you think, we need a fix for 6.x (i.e. Debian (old)stable) I 
guess we have to ask the upstream authors.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037362: should be quite common

[Peter Gervai]

Hello,

1) ldd was old. When upgraded libc-bin then things became much happier.

2) Caused by the "unsupported" double major upgrade. While I understand that 
"we do not support it" it should be noted that huge amount of people are or 
will be bitten by this and the libcrypt "bug" (or future incompatibility).

3) What exactly happens, or at least it did for me several times now, that 
dist-upgrade chokes on libcrypt, and it requires libpam0g, libc6 and libcrypt 
upgrade to work. It does not "require" (deps) libc-bin, so ldd stayed old. But 
I guess that made usrmerge really angry. Up to the point of a seemingly 
unexplainable and unfixable error. 

If I was the maintainer I would loudly complain about not supported upgrade 
path but would still patch around that line 222 to check ldd, check the ldd 
output (old one see the cp static) and handle the case, at least providing a 
clear reason and suggest possible ways to get up from the bottom of the dark 
pit. 

Updating libc-bin, as mentioned, helps a lot in this particular case. 

g.

Bug#1039906: libreoffice: FTBFS on riscv64: uitest throws "index out of range"

[Rene Engelhard]

Hi,

Am 10.07.23 um 22:45 schrieb Rene Engelhard:

[build UIT] cui_tabpages

[...]

Tests run: 2
Tests failed: 0
Tests errors: 0
Tests skipped: 0


That said, before that a make uicheck in cui or a make uicheck toplevel 
gets:


[build ECH] CustomTarget/instsetoo_native/setup/setuprc
/bin/sh: 1: git: not found
[build ECH] CustomTarget/instsetoo_native/setup/versionrc
/bin/sh: 1: git: not found
[build LOC] top level modules: libreoffice
[build CUS] instsetoo_native/setup
[build PKG] instsetoo_native_setup
[build BIN] instsetoo_native
[build UIT] cui_dialogs
[build UIT] cui_tabpages
[build UIT] conditional_format
testSvxCharEffectsPage (chardlg.Test.testSvxCharEffectsPage) ... 
testThemePage (themepage.Test.testThemePage) ... OfficeConnection: 
connecting to: 
uno:pipe,name=pytest60b76514-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR
testSvxCharEffectsPageTheme (chardlg.Test.testSvxCharEffectsPageTheme) 
... OfficeConnection: connecting to: 
uno:pipe,name=pytest61580f0a-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR
testSvxCharEffectsPageWriter (chardlg.Test.testSvxCharEffectsPageWriter) 
... OfficeConnection: connecting to: 
uno:pipe,name=pytest61f5ecac-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR
testSvxCharEffectsPageWriterAutomatic 
(chardlg.Test.testSvxCharEffectsPageWriterAutomatic) ... 
OfficeConnection: connecting to: 
uno:pipe,name=pytest62935cda-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR
test_tdf145978 (macroselectordlg.tdf145978.test_tdf145978) ... 
OfficeConnection: connecting to: 
uno:pipe,name=pytest6330c6c8-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR
testGetFormat (pastedlg.Test.testGetFormat) ... OfficeConnection: 
connecting to: 
uno:pipe,name=pytest63ce3dea-1f69-11ee-832a-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
ERROR

==
ERROR: testSvxCharEffectsPage (chardlg.Test.testSvxCharEffectsPage)
--
Traceback (most recent call last):
  File "/home/rene/libreoffice-7.5.5~rc1/uitest/uitest/framework.py", 
line 25, in setUp

self.connection.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 175, in setUp

conn.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 56, in setUp

self.xContext = self.connect(socket)

  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 103, in connect

raise Exception("soffice has stopped.")
Exception: soffice has stopped.

==
ERROR: testSvxCharEffectsPageTheme 
(chardlg.Test.testSvxCharEffectsPageTheme)

--
Traceback (most recent call last):
  File "/home/rene/libreoffice-7.5.5~rc1/uitest/uitest/framework.py", 
line 25, in setUp

self.connection.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 175, in setUp

conn.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 56, in setUp

self.xContext = self.connect(socket)

  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 103, in connect

raise Exception("soffice has stopped.")
Exception: soffice has stopped.

==
ERROR: testSvxCharEffectsPageWriter 
(chardlg.Test.testSvxCharEffectsPageWriter)

--
Traceback (most recent call last):
  File "/home/rene/libreoffice-7.5.5~rc1/uitest/uitest/framework.py", 
line 25, in setUp

self.connection.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 175, in setUp

conn.setUp()
  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 56, in setUp

self.xContext = self.connect(socket)

  File 
"/home/rene/libreoffice-7.5.5~rc1/uitest/libreoffice/connection.py", 
line 103, in connect

raise Exception("soffice has stopped.")
Exception: soffice has stopped.
[...]

so it's at least better than before (and this bug is fixed) but still it 
has problems :)


(The UITests fwiw are not ran anymore on riscv64 per default)

Regards,

Rene

Bug#1018206: luatex loses or changes text when discretionaries with priorities are used

[Preuße]

On 07.07.2023 00:05, Preuße...@buxtehude.debian.org, Hilmar wrote:

On 06.07.2023 20:44, Preuße...@buxtehude.debian.org, Hilmar wrote:


Hello,

Oh my gosh.  Losing formatting would indeed be not severe.  
Distorting contents is IS severe, especially if this goes unnoticed.  
Heaven knows how much text has already been and will be silently 
changed in all the years of Debian 12.  Therefore, a kind request: 
please push it into the next update of Debian (12.1) or at least one 
of the next updates.


I guess this is [1] according to [2]. I'll try to do something, but it 
won't be for 12.1, which will be released soon.




I used that one [1], but it does not solve the issue. ;-(


I put patches from ad3b0d706c71bb6f3309a236e98e8fb644121bc6 &
be0377afd9573be47495ac97be42ecc4dae5f0a2 into the repo and it seems to 
solve the issue. Maybe one of the patches is surplus.


As said: the first point release is around the corner, I'll try to push 
the fix to 12.2.


Hilmar



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040650: console-setup: transition from /etc/default/keyboard to /etc/vconsole.conf

[sohe4b+2fz7rb0ixc53g]

Package: console-setup
Version: 1.221
Followup-For: Bug #1040650

I believe wayland does not come into effect here, since both /etc/vconsole.conf 
and /etc/default/keyboard modify the environment even for terminals with no 
graphical interface (only text interface).

https://github.com/systemd/systemd/issues/24228 and the links in there might be 
related to this debian bugreport.

Bug#1040716: libc6: Stack Traces

[Aurelien Jarno]

Hi,

On 2023-07-09 17:15, Tim McConnell wrote:
> Hi Aurelien, 
> The Stack Traces started showing up in my System Event logs yesterday
> and has totaled up to 18 times so far. As far as issues, the system is
> slower than usual and occasionally freezes. 
>  I ran apt-file search lib.so and came up with libc6 so that's where I
> filed the bug. I tried running gdb on it (libc6) and it told me file
> not found, I'd be happy to give more information just tell me how to
> get it. 

Thanks for the details, however I am afraid it is not enough. libc6 is a
library, for understanding the issue, I would need to know by which
program it is used in the corresponding stack traces. The issue might
not be in the library but in another library or another program. Do you
have some more log entries around those stack traces?

All that said, it appears that the locales package in versions 2.37-2 to
2.37-4 is buggy and might cause random crashes in libc6. You might want
to upgrade to version 2.37-5 to check if it solves your issue. The
package is currently only available in sid, but it is expected to
migrate to testing in the next days.

Regards
Aurelien

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

Bug#1040804: RFS: cdw/1.0-2 [ITA] -- Tool for burning CD's - console version

[Matteo Bini]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : cdw
   Version  : 0.8.1-3
   Upstream contact : https://sourceforge.net/projects/cdw/support
 * URL  : https://cdw.sourceforge.net/
 * License  : GPL-2+
   Section  : otherosfs

The source builds the following binary packages:

  cdw - Tool for burning CD's - console version

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/c/cdw/cdw_0.8.1-3.dsc

Changes since the last upload:

 cdw (0.8.1-3) unstable; urgency=medium
 .
   * New maintainer (Closes: #1001962).
   * debian/control:
 - Change Maintainer.
 - Change libncurses5-dev and libncursesw5-dev dependencies to
   libncurses-dev.
 - Update Standards-Version to 4.6.2.
 - Add Rules-Requires-Root to no.
   * debian/copyright:
 - Add new maintainer.
 - Clean file up, better formatting.
   * debian/upstream/metadata:
 - Add basic upstream meta-information.

Regards,
-- 
  Matteo Bini


Dear Laszlo Boszormenyi,
I would love to be the new maintainer of cdw, a software I use and like.

I've emailed upstream regarding the required change of libraries and
I've received their blessing to keep maintaining the software. I hope to
start working on the migration from wodim and genisoimage to xorriso and
libburnia this summer.

In the meantime, I hope I can release you from your duties for this
package.

Thank you for your work so far.

--
Matteo Bini

Bug#1040690: me too

[Richard Lewis]

On Mon, 10 Jul 2023 20:07:30 +0100 Richard Lewis <
richard.lewis.deb...@googlemail.com> wrote:
> i've only ever run stable, i get the following list
>
> Warning (comp): Cannot look-up eln file as no source file was found for
> /usr/share/emacs/site-lisp/elpa/helpful-0.18/helpful.elc Warning (comp):
> Cannot look-up eln file as no source file was found for
> /usr/share/emacs/site-lisp/elpa/elisp-refs-1.3/elisp-refs.elc Warning
> (comp): Cannot look-up eln file as no source file was found for
> /usr/share/emacs/site-lisp/elpa/dash-2.17.0/dash.elc Warning (comp):
Cannot
> look-up eln file as no source file was found for
> /usr/share/emacs/site-lisp/elpa/loop-1.3/loop.elc
> Warning (comp): Cannot look-up eln file as no source file was found for
> /usr/share/emacs/site-lisp/elpa/dash-functional-1.2.0/dash-functional.elc

And elpa-dash-functional, elpa-loop, elpa-transient were all purged when i
upgraded to bookworm (same aptitude run that upgraded dh-elpa and the other
emacs packages)

(do say if other info helpful and/or if this is not helping)

Bug#1030385: flite: FTBFS with TeXInfo 7.0.x

[Preuße]

Control: severity -1 serious

On 03.02.2023 21:54, Hilmar Preusse wrote:

Hello,


For now TeXInfo 7.0 is available in experimental. This bug is not RC
for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and
the bug will become RC.


I've uploaded TexInfo 7.0.x to unstable, your package will fail to build
soon.

Hilmar
--
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030375: proofgeneral: FTBFS with TeXInfo 7.0.x

[Preuße]

Control: severity -1 serious

On 03.02.2023 17:30, Hilmar Preusse wrote:

Hello,


For now TeXInfo 7.0 is available in experimental. This bug is not RC
for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and
the bug will become RC.


I've uploaded TexInfo 7.0.x to unstable, your package will fail to build
soon.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030367: festival: FTBFS with TeXInfo 7.0.x

[Preuße]

Control: severity -1 serious

On 03.02.2023 16:46, Hilmar Preusse wrote:

Hello,


For now TeXInfo 7.0 is available in experimental. This bug is not RC
for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and
the bug will become RC.


I've uploaded TexInfo 7.0.x to unstable, your package will fail to build
soon.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030346: elpa-transient: FTBFS with TeXInfo 7.0.x

[Preuße]

Control: severity -1 serious

On 03.02.2023 12:17, Hilmar Preusse wrote:

Hello,


For now TeXInfo 7.0 is available in experimental. This bug is not RC
for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and
the bug will become RC.


I've uploaded TexInfo 7.0.x to unstable, your package will fail to build
soon.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030350: fweb: FTBFS with TeXInfo 7.0.x

[Preuße]

Control: severity -1 serious

On 03.02.2023 12:59, Hilmar Preusse wrote:

Hello,


For now TeXInfo 7.0 is available in experimental. This bug is not RC
for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and
the bug will become RC.


I've uploaded TexInfo 7.0.x to unstable, your package will fail to build
soon.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040793: [Pkg-utopia-maintainers] Bug#1040793: udisks2: last sid upload introduced a crash

[Michael Biebl]

Control: severity -1 serious
Control: retitle -1 udisks2 crashes when libblockdev plugins are missing

Am 10.07.23 um 19:42 schrieb Patrice Duroux:

In a daily upgrade basis of a sid system with some extra rc-buggy packages
(GNOME 44 relatives mainly),
the recent upload of udisks2 introduced the following issue:


[snip crash]



Let me know if I can help more or close the bug if it's noise and expected by
the transition.



The crash is definitely not expected.

libblockdev-{crypto3,mdraid3,nvme3} are currently optional (Recommends 
or Suggests).
It appears though, if they are missing udisks2 is crashing. So for a 
short-term fix, you can manually install those packages.


Will have to check, whether to make those plugins hard dependencies or 
if a different solution can be found.


Help welcome.

Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030328: quelcom: FTBFS with TeXInfo 7.0.x

[Preuße]

Control: severity -1 serious

On 02.02.2023 23:55, Hilmar Preusse wrote:

Hello,


For now TeXInfo 7.0 is available in experimental. This bug is not RC
for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and
the bug will become RC.


I've uploaded TexInfo 7.0.x to unstable, your package will fail to build
soon.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#414092: airport-utils 2-8

[Ricky Ricardo]

Hello. I have the same problem as reported on message #5 of this bug report.
I am using a Raspberry Pi Model 4B with Raspberry Pi OS (most recent
version, 32-bit).

I installed the airport-utils 2-8 from the repository.
Installation was okay, but when running airport-config from the terminal
nothing happened.

Would like these utilities to work so that I can re-configure an old Apple
Airport Express (or Extreme?) unit.

Thanks,
Rick

Bug#1030322: gnushogi: FTBFS with TeXInfo 7.0.x

[Preuße]

Control: tags -1 + patch
Control: severity -1 serious

On 02.02.2023 22:04, Hilmar Preusse wrote:

Hello,


For now TeXInfo 7.0 is available in experimental. This bug is not RC
for now, but after bookworm we'll upload TeXInfo 7.0 to unstable and
the bug will become RC.


I've uploaded TexInfo 7.0.x to unstable, your package will fail to build
soon.

Hilmar
--
sigfault

Bug#1039906: libreoffice: FTBFS on riscv64: uitest throws "index out of range"

[Rene Engelhard]

Hi,

forgot one sentence.

Am 10.07.23 um 22:45 schrieb Rene Engelhard:
So I had the idea to try a export DEB_BUILD_OPTIONS="noopt" build 
(resulting into -O0) and it looks better:


So I guess I'll workaround this by building with -O0. (riscv64 isn't 
alone there, see


https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/rules#L746
(upto line 771)

Regards,

Rene

Bug#1039906: libreoffice: FTBFS on riscv64: uitest throws "index out of range"

[Rene Engelhard]

tag 1039906 - moreinfo

thanks


Hi,

Am 29.06.23 um 17:29 schrieb Rene Engelhard:
It seems that the exception only throws in current Debian package. If 
I build LibreOffice (both 7.6 and 7.5 version) with external tarballs 

and upstream compiler flags, see below
(that means, I pass parameters to autogen.sh as less as possible), 
this bug disappears. Therefore maybe some system-internal component 
are not configured correctly.


> [...]

It occurred to me that dpkg-buildflags forces -O2 whereas LO does

rene@frodo:~/LibreOffice/git/libreoffice-7-6$ cat 
solenv/gbuild/platform/LINUX_RISCV64_GCC.mk

# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
#
# This file is part of the LibreOffice project.
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
#

#please make generic modifications to unxgcc.mk or linux.mk
gb_COMPILEROPTFLAGS := -Os

include $(GBUILDDIR)/platform/linux.mk

# vim: set noet sw=4:
rene@frodo:~/LibreOffice/git/libreoffice-7-6$

which probably was cargo-culted over when porting from other 
solenv/platform/*.mk, but anyways :)



So I had the idea to try a export DEB_BUILD_OPTIONS="noopt" build 
(resulting into -O0) and it looks better:


rene@debian-riscv64-porterbox-01 ~/libreoffice-7.5.5~rc1/cui
 % make UITest_cui_tabpages

[build UIT] cui_tabpages
S=/home/rene/libreoffice-7.5.5~rc1 && I=$S/instdir && W=$S/workdir &&  
rm -rf $W/UITest/cui_tabpages/ && mkdir -p 
$W/UITest/cui_tabpages//user/user && cp 
$S/qadevOOo/qa/registrymodifications.xcu 
$W/UITest/cui_tabpages//user/user/ &&  rm -fr 
$W/UITest/cui_tabpages/done.core && mkdir -p 
$W/UITest/cui_tabpages/user/ && mkdir $W/UITest/cui_tabpages/done.core 
&& cd $W/UITest/cui_tabpages/done.core &&   ( 
TEST_LIB=$W/LinkTarget/Library/libtest.so 
URE_BOOTSTRAP=vnd.sun.star.pathname:$I/program/fundamentalrc 
PYTHONPATH="$S/uitest:$S/unotest/source/python:$I/program:$S/cui/qa/uitest/tabpages/" 
TestUserDir="file://$W/UITest/cui_tabpages/" PYTHONDONTWRITEBYTECODE=0   
MAX_CONCURRENCY=4 MOZILLA_CERTIFICATE_FOLDER=dbm: 
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp 
LIBO_LANG=C   /usr/bin/python3 $S/uitest/test_main.py 
--soffice="path:$I/program/soffice" 
--userdir=file://$W/UITest/cui_tabpages/user 
--dir=$S/cui/qa/uitest/tabpages/  2>&1)
testThemePage (themepage.Test.testThemePage) ... OfficeConnection: 
connecting to: 
uno:pipe,name=pyteste5c58cc0-1f61-11ee-8c20-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
['OnNew']
OnCreate
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnFocus
['OnNew']
OnViewCreated
['OnNew']
OnModeChanged
['OnNew']
DialogExecute
['DialogClosed']
OnModeChanged
['OnNew']
OnModeChanged
['OnNew']
DialogClosed
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['DialogExecute']
OnModeChanged
['OnNew']
OnModeChanged
['OnNew']
DialogExecute
['DialogClosed']
OnModeChanged
['DialogExecute']
OnModeChanged
['OnNew']
OnModeChanged
['DialogExecute']
DialogClosed
['OnNew']
DialogClosed
['OnNew']
OnTitleChanged
['OnNew']
OnViewClosed
['OnNew']
OnUnload
['OnNew']
OnUnfocus
Execution time for themepage.Test.testThemePage: 20.341
at ./framework/source/helper/ocomponentenumeration.cxx:83
tearDown: calling terminate()...
...done
ok
testSvxColorTabPageTheme (tpcolor.Test.testSvxColorTabPageTheme) ... 
OfficeConnection: connecting to: 
uno:pipe,name=pytestfe6faaa8-1f61-11ee-8c20-70b3d592f466;urp;StarOffice.ComponentContext

NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
NoConnectException: sleeping...
['OnNew']
OnCreate
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnModifyChanged
['OnNew']
OnTitleChanged
['OnNew']
OnFocus
['OnNew']
OnViewCreated
['OnNew']
OnModeChanged
['OnNew']
DialogExecute
['DialogClosed']
OnModeChanged
['OnNew']
OnModeChanged
['OnNew']
DialogClosed
['OnNew']
OnTitleChanged

Bug#1040797: [Pkg-utopia-maintainers] Bug#1040797: udisks2: still recommends old libblockdev-mdraid2

[Christoph Anton Mitterer]

On Mon, 2023-07-10 at 22:32 +0200, Michael Biebl wrote:
> Good catch, thanks

Thank *you*, for maintaining! :-)

Bug#1040803: Please update dependency on libblockdev-mdraid2

[Michael Biebl]

Package: cockpit-storaged
Version: 295-1
Severity: important

Hi,

the latest update of libblockdev from version 2.28 to 3.0 has seen some
major changes, among them an SONAME bump.

Please test cockpit(-storaged) against the new libblockdev and update
the libblockdev-mdraid2 dependency to libblockdev-mdraid3.

Regards,
Michael



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

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 cockpit-storaged depends on:
ii  cockpit-bridge   295-1
ii  libblockdev-mdraid2  2.28-2
ii  python3  3.11.4-5
ii  python3-dbus 1.3.2-4+b1
ii  udisks2  2.10.0-2

cockpit-storaged recommends no packages.

Versions of packages cockpit-storaged suggests:
pn  udisks2-lvm2  

-- no debconf information

Bug#1040797: [Pkg-utopia-maintainers] Bug#1040797: udisks2: still recommends old libblockdev-mdraid2

[Michael Biebl]

Am 10.07.23 um 21:19 schrieb Christoph Anton Mitterer:

Package: udisks2
Version: 2.10.0-2
Severity: normal


Hey.

I guess it was forgotten to bump the Suggests of libblockdev-mdraid2 to
…3 as well :-)


Good catch, thanks





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040799: nmu: libnginx-mod-http-modsecurity_1.0.3-1+b1

[Hegedüs Ervin]

Hi,


On Mon, Jul 10, 2023 at 09:08:14PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + bookworm moreinfo
> 
> On Mon, 2023-07-10 at 21:55 +0200, Ervin Hegedüs wrote:
> > nmu libnginx-mod-http-modsecurity_1.0.3-1+b1 . ANY . bookworm . -m
> > "Closes: 1037226"
> 
> *Please* include information in binNMU requests that allows us to
> identify the actual problem without having to dig around. As an
> additional note, the text in the "message" argument (-m) is copied
> verbatim into changelogs, which will then be visible to users and
> anyone else viewing the changelog. It needs to be more descriptive than
> a bug number.

right.

Should I send a new request? Or how can I append the requested
info to the original NMU request?
 
> The BTS metadata for #1037226 indicates that it also affects unstable
> and testing. Is that correct?

Yes, it is - but meanwhile Nginx has a new version in unstable
(1.24 - stable: 1.22), so there is a PR for the unstable package:

https://salsa.debian.org/modsecurity-packaging-team/libnginx-mod-http-modsecurity/-/merge_requests/1/diffs

> If so, it needs to be fixed there first.

The package in unstable will be modified soon - but those
modifications will produce a different package. Would it be
allowed in case of stable (related to freeze policy)?

> If not, please explain why unstable is not affected despite having
> exactly the same package version.

Theoretically there are the same issue in all releases (stable,
testing, unstable). But as the core application has a new
version, I think it would be better to recompile the source
package in stable, and after apply the modifications, then upload
the new package to unstable. (And - I guess - after that the
package will be migrated to unstable)


Thanks,


a.

Bug#1040056: [Pkg-opencl-devel] Bug#1040056: spirv-tools breaks spirv-llvm-translator-15 autopkgtest: exactly one input file must be specified.

[Paul Gevers]

Hi,

On 10-07-2023 11:30, Andreas Beckmann wrote:

Does this issue affect spirv-llvm-translator-16, too?
I tried to trigger the corresponding tests (which succeeded), but I'm 
not sure if it really tested the correct setup.


https://release.debian.org/britney/excuses.yaml.gz tells me that -16 was 
tested too and that it didn't fail (NEUTRAL; link to the log is in the 
excuses.yaml).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Tollef Fog Heen]

Package: xkb-data
Version: 2.38-2
Severity: serious
Justification: makes a subset of systems effectively unusable
X-Debbugs-Cc: none, Tollef Fog Heen 

With commit 0fb34101788d84e9a1d98b3730cc7b9295e0f19b in
xkeyboard-config, `group(alts_toggle)` changed behaviour in a way such
that the right alt no longer generates altgr.  This is very problematic
with keyboard layouts such as Norwegian where that is required to type @
(altgr-2) or $ (altgr-4).

setxkmap no -print on my system outputs:

xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include 
"pc+no+inet(evdev)+level3(ralt_switch)+compose(caps)+group(alts_toggle)"
};
xkb_geometry  { include "pc(pc105)" };
};

which includes the problematic toggle.  I don't know if the right fix is
to revert the relevant commit (reintroducing the problem in
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/316)
or something else, but the current way it works is not great.

Happy to help debug this further, let me know what I can provide.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1040303: magpie/0.9.2-1 [ITP] -- Window manager and compositor library for the Budgie Desktop)

[David Mohammed]

Hi,

  I have taken the opportunity to simplify the packaging - one less
binary and no longer needs postinst and preinst scripts

Please accept this version as a sponsorship request



The source builds the following binary packages:

  gir1.2-magpie-0 - GObject introspection data for magpie
  libmagpie-0-0 - window manager library from the magpie window manager
  libmagpie-0-dev - Development files for the magpie window manager
  magpie-common - shared files for the magpie window manager

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/magpie/magpie_0.9.2-1.dsc

Changes since the last upload:

 magpie (0.9.2-1) experimental; urgency=medium
 .
   * Initial Release (Closes: #1040005)

Bug#1040801: mcomix: pillow 10.0.0 not recognized as higher than 6.0.0

[Sebastien KALT]

Package: mcomix
Version: 2.1.0-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Since python3-pil:amd64 upgrade from 9.5.0-1 to 10.0.0-1, it's impossible to
launch mcomix :

$ mcomix
22:02:01 [MainThread] ERROR: You don't have the required version of the Python
Imaging Library Fork (Pillow) installed.
22:02:01 [MainThread] ERROR: Installed Pillow version is: 10.0.0
22:02:01 [MainThread] ERROR: Required Pillow version is: 6.0.0 or higher

Downgrading python3-pil to 9.5.0-1 solves the problem, but it removes other
packages I use (qgis, matplotlib).

Regards,

Sébastien


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

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mcomix depends on:
ii  gir1.2-gtk-3.03.24.37-2
ii  python3   3.11.4-5
ii  python3-cairo 1.24.0-1
ii  python3-gi3.42.2-3+b1
ii  python3-gi-cairo  3.42.2-3+b1
ii  python3-pil   10.0.0-1

Versions of packages mcomix recommends:
ii  python3-chardet  5.1.0+dfsg-2

Versions of packages mcomix suggests:
pn  lhasa
ii  mupdf-tools  1.22.2+ds1-1
ii  p7zip16.02+dfsg-8
ii  unrar1:6.2.8-1
ii  unzip6.0-28

-- no debconf information

Bug#1040799: nmu: libnginx-mod-http-modsecurity_1.0.3-1+b1

[Adam D. Barratt]

Control: tags -1 + bookworm moreinfo

On Mon, 2023-07-10 at 21:55 +0200, Ervin Hegedüs wrote:
> nmu libnginx-mod-http-modsecurity_1.0.3-1+b1 . ANY . bookworm . -m
> "Closes: 1037226"

*Please* include information in binNMU requests that allows us to
identify the actual problem without having to dig around. As an
additional note, the text in the "message" argument (-m) is copied
verbatim into changelogs, which will then be visible to users and
anyone else viewing the changelog. It needs to be more descriptive than
a bug number.

The BTS metadata for #1037226 indicates that it also affects unstable
and testing. Is that correct? If so, it needs to be fixed there first.
If not, please explain why unstable is not affected despite having
exactly the same package version.

Regards,

Adam

Bug#1040800: lomiri-ui-toolkit: FTBFS on i386: file:///<>/qml/Lomiri/Metrics/qmldir:2:1: plugin cannot be loaded for module "Lomiri.Metrics": Cannot protect module Lomiri.Metrics 0 as it

[Sebastian Ramacher]

Source: lomiri-ui-toolkit
Version: 1.3.5010+dfsg-1
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=lomiri-ui-toolkit=i386=1.3.5010%2Bdfsg-1%2Bb1=1688977672=0

import Lomiri.Metrics 0.1 as ALomiri_Metrics_0_1
QtObject { }

file:///<>/qml/Lomiri/Metrics/qmldir:2:1: plugin cannot be loaded 
for module "Lomiri.Metrics": Cannot protect module Lomiri.Metrics 0 as it was 
never registered
make[3]: *** [Makefile:743: check] Error 1
make[2]: *** [Makefile:476: test] Error 2
dh_auto_test: error: make -j1 test returned exit code 2
Tail of xvfb-run output:
Creating QML component for Lomiri.Metrics
Failed to load Lomiri.Metrics
import QtQuick 2.0
import Lomiri.Metrics 0.1 as ALomiri_Metrics_0_1
QtObject { }

file:///<>/qml/Lomiri/Metrics/qmldir:2:1: plugin cannot be loaded 
for module "Lomiri.Metrics": Cannot protect module Lomiri.Metrics 0 as it was 
never registered
make[3]: *** [Makefile:743: check] Error 1
make[2]: *** [Makefile:476: test] Error 2

Cheers
-- 
Sebastian Ramacher

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi Dirk,

On 09-07-2023 21:09, Dirk Eddelbuettel wrote:

So this is where R 4.3.[01] will possibly break with some older packages.
But the fix is simple because when R 4.3.0 came out all packages at CRAN
complied. We need to have current packages that correspond to the R 4.3.0
standard.

(If one were super picky one could call this an ABI/API change and reason for
forcing _all_ packages to be rebuild. I never advocated for that but I am
getting tired of this process. But we need to throw that bomb at some point
just say 'fsck it' and rebuild _all_ packages. Feels like overkill but so is
wasting weeks on this.


Reading this a second time, I think your proposal is to acknowledge that 
r-base sometimes introduces unanticipated changes, and if we want to be 
on the safe side, we should rebuild everything when the minor version 
bumps. I guess that's more or less (I'm not sure how different r is in 
that respect) what other interpretation based languages like python, 
ruby, php and perl are doing too. r-base already has a "handle" for 
that: r-api-*. We *could* decide to just bump that on every minor bump 
of r-base and that would mean a transition every time that happens 
(mostly like those other languages except ruby, python and php also have 
a "defaults" package to explicitly switch from one version to the next), 
but at least our tools would help there. Apart from the potential 
overkill, the major (current) drawback is that for arch:all binaries, we 
still need source-full uploads as binNMU's don't work for them.


Is that what you are proposing? (For next time maybe?)

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040799: nmu: libnginx-mod-http-modsecurity_1.0.3-1+b1

[Ervin Hegedüs]

Package: release.debian.org
Control: affects -1 + src:libnginx-mod-http-modsecurity
X-Debbugs-Cc: libnginx-mod-http-modsecur...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

nmu libnginx-mod-http-modsecurity_1.0.3-1+b1 . ANY . bookworm . -m "Closes: 
1037226"

Bug#1040776: [Debian-med-packaging] Bug#1040776: python-biopython: autopkgtest regression

[Étienne Mollier]

Hi Adrian,

Adrian Bunk, on 2023-07-10:
> 580s ModuleNotFoundError: No module named 'reportlab.graphics._renderPM'

Thanks for your report, migrations of biopython and reportlab
seem to have gone entangled.  I'll bump the version requirement
of python3-reportlab to unlock the situation.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: Scale The Summit - Whales


signature.asc
Description: PGP signature

Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks

[sohe4b+2fz7rb0ixc53g]

Package: base-files
Version: 12.4
Followup-For: Bug #1039979

PS: making /var/run and /var/lock relative symlinks makes it much nicer and 
safer to work with chroots, avoiding the risk of damaging the real system's /run

It's also what archlinux does.

Bug#1040798: RM: ruby-derailed-benchmarks -- ROM; rc-buggy, no longer needed

[Praveen Arimbrathodiyil]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ruby-derailed-benchma...@packages.debian.org
Control: affects -1 + src:ruby-derailed-benchmarks
Control: block 1039916 by -1

This is affected by rc bug #1039916 and blocking testing migration of 
ruby-memory-profiler. This was originally packaged for gitlab, but it is 
now only required for tests.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks

[sohe4b+2fz7rb0ixc53g]

Package: base-files
Version: 12.4
Followup-For: Bug #1039979

Debian policy "9.1.1. File System Structure" 
https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure 
states:

"8. /var/run is required to be a symbolic link to /run, and /var/lock is 
required to be a symbolic link to /run/lock."

Additional clarification is provided in 
https://www.debian.org/doc/debian-policy/ch-files.html#id24

"This is necessary to allow top-level directories to be symlinks. If linking 
/var/run to /run were done with the relative symbolic link ../run, but /var 
were a symbolic link to /srv/disk1, the symbolic link would point to /srv/run 
rather than the intended target."

That part of the policy is certainly out of date with modern practices, where 
bind mounts and other solutions are commonplace and provide a much better 
solution to the described problem.

For this bugreport to be fixed, it would require changing those parts of debian 
policy.

However, the question is whether this is something against the letter of the 
policy but not against the spirit of the policy. My interpretation of the 
policy is that /var/run should end up pointing at the location of /run and it 
would be satisfied through relative symlinks too. Same for /var/lock

Bug#1040797: udisks2: still recommends old libblockdev-mdraid2

[Christoph Anton Mitterer]

Package: udisks2
Version: 2.10.0-2
Severity: normal


Hey.

I guess it was forgotten to bump the Suggests of libblockdev-mdraid2 to
…3 as well :-)

Thanks,
Chris.

Bug#1040690: me too

[Richard Lewis]

i've only ever run stable, i get the following list

Warning (comp): Cannot look-up eln file as no source file was found for
/usr/share/emacs/site-lisp/elpa/helpful-0.18/helpful.elc Warning (comp):
Cannot look-up eln file as no source file was found for
/usr/share/emacs/site-lisp/elpa/elisp-refs-1.3/elisp-refs.elc Warning
(comp): Cannot look-up eln file as no source file was found for
/usr/share/emacs/site-lisp/elpa/dash-2.17.0/dash.elc Warning (comp): Cannot
look-up eln file as no source file was found for
/usr/share/emacs/site-lisp/elpa/loop-1.3/loop.elc
Warning (comp): Cannot look-up eln file as no source file was found for
/usr/share/emacs/site-lisp/elpa/dash-functional-1.2.0/dash-functional.elc

Bug#1039973: base-files: /var/local is root:staff 2775 instead of root:root 0755

[sohe4b+2fz7rb0ixc53g]

Package: base-files
Version: 12.4
Followup-For: Bug #1039973

a similar bug existed for /usr/local/share/texmf #962419

where it had 'staff' as group ownership, despite /etc/staff-group-for-usr-local 
not existing.

The same bug exists for /usr/local/share/fonts #962420

My interpretation of debian policy is that no directories should be owned by 
the group 'staff' unless /etc/staff-group-for-usr-local or similar file exists.

Bug#1040096: python-eventlet: deprecation of Python libraries asyncore and asynchat

[Louis-Philippe Véronneau]

On 2023-07-05 07 h 38, Thomas Goirand wrote:

On 7/2/23 03:44, Louis-Philippe Véronneau wrote:

Source: python-eventlet
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: asyncore-asynchat-deprecation

Dear maintainer(s),

In Python 3.6, asyncore and asynchat have been formally marked as 
deprecated. Code that imports these libraries will no longer work from 
Python 3.12, which is currently in Trixie.


Since python-eventlet uses either of these Python libraries, please 
prepare for this removal and migrate away from them.


See this link for more details: 
https://peps.python.org/pep-0594/#deprecated-modules


Hi Louis,

The only place where I can see the use of these libs, is where Eventlet 
is monkey patching that lib. See 
https://github.com/eventlet/eventlet/blob/master/eventlet/green/asyn{core,chat}.py. In such a case, do we still have an issue?


Cheers,

Thomas Goirand (zigo)



I'm not familiar enough with this code, but if the import is called with 
python 3.12, it will fail. I don't know how much this library depends on it.


You can always test it out yourself with python3.12 (currently in trixie 
and sid).


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1040796: Reports "release not available in the sources" when packages list is empty

[Guido Günther]

Package: apt
Version: 2.6.1
Severity: normal

With the sources.list below this works:

```
"apt-get" "-o" "Debug::pkgDepCache::AutoInstall=false" "-o" 
"APT::Get::Show-Versions=false" "-u" "dist-upgrade" "--print-uris" "--yes" "-t" 
 bookworm-security 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
```

while this gives an error:

```
# "apt-get" "-o" "Debug::pkgDepCache::AutoInstall=false" "-o" 
"APT::Get::Show-Versions=false" "-u" "dist-upgrade" "--print-uris" "--yes" "-t" 
 bookworm-updates
Reading package lists... Done
E: The value 'bookworm-updates' is invalid for APT::Default-Release as such a 
release is not available in the sources
```

I assume that's because there's not yet a point release for bookworm and
hence the Packages file is empty. This currently trips up the munin
apt_all plugin on bookworm. I'm aware there's better ways to figure out missing
upgrades but wanted to report it nevertheless.

Cheers,
 -- Guido

-- Package-specific info:

-- (no /etc/apt/preferences present) --

-- (/etc/apt/sources.list present) --

deb http://deb.debian.org/debian bookworm-updates main
deb http://deb.debian.org/debian bookworm main
deb http://deb.debian.org/debian-security/ bookworm-security main


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.134
ii  debian-archive-keyring  2023.3
ii  gpgv2.2.40-1.1
ii  libapt-pkg6.0   2.6.1
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libgnutls30 3.7.9-2
ii  libseccomp2 2.5.4-1+b3
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.6-1

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.21.22
ii  gnupg2.2.40-1.1
ii  powermgmt-base   1.37

-- no debconf information

Bug#1040795: edb-debugger: FTBFS against capstone5

[Hilko Bengen]

Package: edb-debugger
Version: 1.3.0-2
Severity: normal
Tag: upstream, patch
X-Debbugs-Cc: none, Hilko Bengen 

Dear Maintainer,

edb-debugger fails to build from source against capstone 5 (now in
experimental) due to 2 identifiers (X86_INS_VCVTPD2DQX,
X86_INS_VCVTPD2PSX) that are now missing from header files.

Upstream has fixed this in Git commti
b1bc4d02bfc7ca9c871e7b518aeb795d83e7f88b, see attached patch.

I have verified that this patch does fix the issue.

Cheers,
-Hilko
>From b1bc4d02bfc7ca9c871e7b518aeb795d83e7f88b Mon Sep 17 00:00:00 2001
From: Sam James 
Date: Tue, 13 Sep 2022 19:51:08 +0100
Subject: [PATCH] Fix build with Capstone 5 (#824)

Capstone 5 drops X86_INS_VCVTPD2DQX and X86_INS_VCVTPD2PSX from
x86.h (happened in https://github.com/capstone-engine/capstone/commit/dd91f03fef5102492352756e2adb5972dd79a70f
but no real explanation).

Given:
1. these instructions had no wiring up;
2. other Capstone consumers have done the same
let's drop them entirely as we have no idea what they are. They don't
appear in any Intel documentation and there's very little reference
to them online at all.

Bug: https://bugs.gentoo.org/843755
Closes: https://github.com/eteran/edb-debugger/issues/823
Signed-off-by: Sam James 

Signed-off-by: Sam James 
---
 src/capstone-edb/Instruction.cpp | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/capstone-edb/Instruction.cpp b/src/capstone-edb/Instruction.cpp
index 7b2dfc8a..e5fe0f1b 100644
--- a/src/capstone-edb/Instruction.cpp
+++ b/src/capstone-edb/Instruction.cpp
@@ -880,8 +880,6 @@ bool is_SIMD_PD(const Operand ) {
 	case X86_INS_CVTPD2PI:
 	case X86_INS_CVTPD2PS:
 	case X86_INS_VCVTPD2PS:
-	case X86_INS_VCVTPD2DQX: // FIXME: what's this?
-	case X86_INS_VCVTPD2PSX: // FIXME: what's this?
 	// case X86_INS_VCVTPD2QQ: // FIXME: Capstone seems to not support it
 	case X86_INS_VCVTPD2UDQ:
 		// case X86_INS_VCVTPD2UQQ: // FIXME: Capstone seems to not support it
-- 
2.39.2

Bug#1021428: weston: debian/watch is obsolete

[Patrice Duroux]

Hi,
And so weston 12.0.1 has been available since.
Thanks,
Patrice

Bug#1040201: closed by Debian FTP Masters (reply to Patrick Matthäi ) (Bug#1040201: fixed in xine-lib-1.2 1.2.13+hg20230704-1)

[Patrick Matthäi]

Hey

Am 07.07.2023 um 14:31 schrieb Janek Stolarek:

Thanks. Would it be possible to make another pull from libxine2 upstream? One 
more fix was added
and we need that to fix volume in TDE.

Done, I have just uploaded 1.2.13+hg20230710-1


Also, what needs to happen for this upstream version of libxine2 to be migrated 
to testing?

Janek
It needs some "aging" and should not introduce new critical bugs, also 
the other dependencies have to fullfil these requirements. The last 
upload from me just migrated to testing. You can check the status (why 
is it not in testing yet) here 
https://qa.debian.org/excuses.php?package=xine-lib-1.2

Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation

[Luca Boccassi]

On Mon, 10 Jul 2023 17:14:48 +0100 Steve McIntyre 
wrote:
> Hi, and thanks for your bug report!
> 
> On Mon, Jul 10, 2023 at 05:27:50PM +0200, yogg wrote:
> >Package: installation-reports
> >Severity: serious
> >Tags: d-i
> >Justification: https://wiki.debian.org/MachineId
> >
> 
> ...
> 
> >After installation was finished and the system has been restarted
the
> >files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not
linked
> >in any way (no soft or hardlink) and the ID inside the files differ
> >from each other.
> 
> I've confirmed this bug just now, doing a clean installation from the
> 12.0.0 amd64 netinst.

As a wild guess, maybe the split of src:dbus into multiple packages
affected the order in which the postinsts run, and now systemd's runs
first and creates /etc/machine-id, and then dbus-daemon's runs and
creates /var/lib/dbus/machine-id.

There is a tmpfiles.d shipped by dbus-daemon that creates
/var/lib/dbus/machine-id as a symlink to /etc/machine-id if it exists,
but this snippet runs _after_ the dbus-uuidgen so effectively it is
always a no-op on package install:

$ cat /var/lib/dpkg/info/dbus-daemon.postinst 
#!/bin/sh

set -e

if [ "$1" = configure ]; then
# This is idempotent, so it's OK to do every time. The system bus' init
# script does this anyway, but you also have to do this before a session
# bus will work on non-systemd systems, so we do this here for the
# benefit of people starting a temporary session bus in a chroot.
mkdir -p "${DPKG_ROOT:-/}var/lib/dbus"
dbus-uuidgen --ensure="${DPKG_ROOT:-/}var/lib/dbus/machine-id"
fi

# Automatically added by dh_installtmpfiles/13.11.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -x "$(command -v systemd-tmpfiles)" ]; then
systemd-tmpfiles ${DPKG_ROOT:+--root="$DPKG_ROOT"} --create 
dbus.conf >/dev/null || true
fi
fi
# End automatically added section

It seems to me a safe way to fix this and do the right thing is to swap
the #DEBHELPER# token and the manual dbus-uuidgen block in dbus-
daemon's postinst. Then on systemd systems the tmpfiles will win and on
other systems dbus-uuidgen will do its job.

-- 
Kind regards,
Luca Boccassi


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

Bug#1040793: udisks2: last sid upload introduced a crash

[Patrice Duroux]

Package: udisks2
Version: 2.10.0-2
Severity: normal

Dear Maintainer,

In a daily upgrade basis of a sid system with some extra rc-buggy packages
(GNOME 44 relatives mainly),
the recent upload of udisks2 introduced the following issue:

  PID: 4640 (udisksd)
   UID: 0 (root)
   GID: 0 (root)
Signal: 5 (TRAP)
 Timestamp: Mon 2023-07-10 19:27:28 CEST (2min 12s ago)
  Command Line: /usr/libexec/udisks2/udisksd
Executable: /usr/libexec/udisks2/udisksd
 Control Group: /system.slice/udisks2.service
  Unit: udisks2.service
 Slice: system.slice
   Boot ID: a278c0ac4f4542c1aac6ab19b860f94a
Machine ID: be351e757dc049ffa300ddbaf0f4856a
  Hostname: X
   Storage:
/var/lib/systemd/coredump/core.udisksd.0.a278c0ac4f4542c1aac6ab19b860f94a.4640.168901004800.zst
(present)
  Size on Disk: 340.8K
   Message: Process 4640 (udisksd) of user 0 dumped core.

Module libudev.so.1 from deb systemd-253.5-1.amd64
Module libsystemd.so.0 from deb systemd-253.5-1.amd64
Stack trace of thread 4640:
#0  0x7faa5ad3c1e7 g_log_writer_default (libglib-2.0.so.0 +
0x641e7)
#1  0x7faa5ad39b61 g_log_structured_array (libglib-2.0.so.0
+ 0x61b61)
#2  0x7faa5ad39ecb g_log_structured (libglib-2.0.so.0 +
0x61ecb)
#3  0x556c3f1aed34 udisks_log (udisksd + 0x53d34)
#4  0x556c3f17a303 n/a (udisksd + 0x1f303)
#5  0x7faa5ae37fe6 n/a (libgobject-2.0.so.0 + 0x1bfe6)
#6  0x7faa5ae39bc3 g_object_new_valist (libgobject-2.0.so.0
+ 0x1dbc3)
#7  0x7faa5ae3a219 g_object_new (libgobject-2.0.so.0 +
0x1e219)
#8  0x556c3f17aaac udisks_daemon_new (udisksd + 0x1faac)
#9  0x556c3f1796f2 n/a (udisksd + 0x1e6f2)
#10 0x7faa5af92421 n/a (libgio-2.0.so.0 + 0x116421)
#11 0x7faa5af2d5e3 n/a (libgio-2.0.so.0 + 0xb15e3)
#12 0x7faa5af2e1d3 n/a (libgio-2.0.so.0 + 0xb21d3)
#13 0x7faa5af82e32 n/a (libgio-2.0.so.0 + 0x106e32)
#14 0x7faa5af2d5e3 n/a (libgio-2.0.so.0 + 0xb15e3)
#15 0x7faa5af2d619 n/a (libgio-2.0.so.0 + 0xb1619)
#16 0x7faa5ad31e2f g_main_context_dispatch
(libglib-2.0.so.0 + 0x59e2f)
#17 0x7faa5ad32208 n/a (libglib-2.0.so.0 + 0x5a208)
#18 0x7faa5ad324bf g_main_loop_run (libglib-2.0.so.0 +
0x5a4bf)
#19 0x556c3f17942e main (udisksd + 0x1e42e)
#20 0x7faa5ab1d6ca __libc_start_call_main (libc.so.6 +
0x276ca)
#21 0x7faa5ab1d785 __libc_start_main_impl (libc.so.6 +
0x27785)
#22 0x556c3f179551 _start (udisksd + 0x1e551)

Stack trace of thread 4643:
#0  0x7faa5abf6eb9 syscall (libc.so.6 + 0x100eb9)
#1  0x7faa5ad8bb4c g_cond_wait_until (libglib-2.0.so.0 +
0xb3b4c)
#2  0x7faa5acfbfc1 n/a (libglib-2.0.so.0 + 0x23fc1)
#3  0x7faa5ad5efe2 n/a (libglib-2.0.so.0 + 0x86fe2)
#4  0x7faa5ad5e63d n/a (libglib-2.0.so.0 + 0x8663d)
#5  0x7faa5ab7e3ec start_thread (libc.so.6 + 0x883ec)
#6  0x7faa5abfea1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 4642:
#0  0x7faa5abf6eb9 syscall (libc.so.6 + 0x100eb9)
#1  0x7faa5ad8b9a0 g_cond_wait (libglib-2.0.so.0 + 0xb39a0)
#2  0x7faa5acfbfeb n/a (libglib-2.0.so.0 + 0x23feb)
#3  0x7faa5ad5ec82 n/a (libglib-2.0.so.0 + 0x86c82)
#4  0x7faa5ad5e63d n/a (libglib-2.0.so.0 + 0x8663d)
#5  0x7faa5ab7e3ec start_thread (libc.so.6 + 0x883ec)
#6  0x7faa5abfea1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 4644:
#0  0x7faa5abf19ef __GI___poll (libc.so.6 + 0xfb9ef)
#1  0x7faa5ad3217e n/a (libglib-2.0.so.0 + 0x5a17e)
#2  0x7faa5ad324bf g_main_loop_run (libglib-2.0.so.0 +
0x5a4bf)
#3  0x7faa5af98156 n/a (libgio-2.0.so.0 + 0x11c156)
#4  0x7faa5ad5e63d n/a (libglib-2.0.so.0 + 0x8663d)
#5  0x7faa5ab7e3ec start_thread (libc.so.6 + 0x883ec)
#6  0x7faa5abfea1c __clone3 (libc.so.6 + 0x108a1c)

Stack trace of thread 4641:
#0  0x7faa5abf19ef __GI___poll (libc.so.6 + 0xfb9ef)
#1  0x7faa5ad3217e n/a (libglib-2.0.so.0 + 0x5a17e)
#2  0x7faa5ad3229c g_main_context_iteration
(libglib-2.0.so.0 + 0x5a29c)
#3  0x7faa5ad322e1 n/a (libglib-2.0.so.0 + 0x5a2e1)
#4  0x7faa5ad5e63d n/a (libglib-2.0.so.0 + 0x8663d)
 

Bug#1040689: Workaround without init and site file

[Balbir Thomas]

Hi David,

I can confirm that deleting /usr/share/emacs/site-lisp/elpa/org-9.4 fixes
the issue and org-export-dispatch works again. Thank you.

On Mon, Jul 10, 2023 at 11:44 AM David Bremner  wrote:

> Balbir Thomas  writes:
>
> > Thanks to bremner on IRC it was found that
> > launching emacs disabling the init and site lisp file
> > ("emacs -Q") seems to fix the issue i.e. org-export-dispatch
> > does work and and exported file is generated.
>
> I was thinking about this a bit more, and I wonder if the two bugs you
> filed are related. In particular I wonder if the problems you are having
> with org-mode are related to your having .elc files from an old version
> of org-mode still in your file system. Perhaps try removing the
> directory /usr/share/emacs/site-lisp/elpa/org-9.4 (or moving it to some
> location outside emacs search path, like /tmp).
>
>

Bug#1040472: p11-kit FTCBFS: AC_RUN_IFELSE

[Andreas Metzler]

Control: tags -1 fixed-upstream

On 2023-07-09 Helmut Grohne  wrote:
> On Sun, Jul 09, 2023 at 04:04:20PM +0200, Andreas Metzler wrote:
[...]
> > Also wouldn't using AC_FUNC_STRERROR_R be a better fix? (I do not expect
> > you to provide this, I asking for your opinion)

> After having read the documentation of that macro, I am unsure whether
> it resolves what is being checked here. AC_FUNC_STRERROR_R checks for
> the function and also for how it is being declared, but makes no
> statement about its return value. If there is a connection between
> return type and return value that I don't see, then yes, this may be
> better. Otherwise, this probably still is better than using
> AC_CHECK_FUNC outside. Maybe that connection is XSI <=> int return, GNU
> <=> pointer return?

Hello,

Yes, afaiu the two different strerrors can be distinguished by their return
type (according to strerror_r(3)) and that is exactly what
AC_FUNC_STRERROR_R provides without needing AC_RUN_IFELSE. The
AC_RUN_IFELSE check also tests whether strerror_r() returns 0 (XSI) or a
pointer (i.e. <>0).

Nevermind ... this has been fixed upstream. (With AC_COMPILE_IFELSE).
https://github.com/p11-glue/p11-kit/commit/3ba2c55dfdc8ff20de369f07f6c57d08718d3add

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

Bug#1040792: linux-image-6.1.0-10-amd64 - computer crashes after log-in

[Jonathan Joseph Chiarella]

Erratum:


Kernel linux-image-6.1.09-amd64 works fine.


Kernel linux-image-6.1.0-9-amd64 works fine.

--
Jonathan Joseph Chiarella

PGP Fingerprint: 8B54 67AE 714B 8A5B D479 F578 6AAB 963C 0402 061A

Bug#1040792: linux-image-6.1.0-10-amd64 - computer crashes after log-in

[Jonathan Joseph Chiarella]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1

When running Debian 12.0 (stable) on kernel linux-image-6.1.0-10-amd64 on an 
AMD64 computer (A9-9420 Radeon R5), the system crashes after logging in as a 
user. This only happens after logging in. The lightdm display manager 
disappears and begins to log in to the user. Then the screen flashes, goes 
black, and a hard reset ensues. This happens no matter how many times I try. 
Sometimes, there a is a black screen and white console text appears. It only 
appears briefly.

Kernel linux-image-6.1.09-amd64 works fine.

Error messages on the black screen that sometimes appear:

Hardware error Processor 2
mce: CPU 0: [something I couldn't get ] Check: 0
Bank 4: f20001120c0f
i2c_designwave AMD0010:00:controller timed out
TSC0
PROCESSOR 2:670f00
TIME 1688732464 SOCKET 0 APIC 0 microcode 6006705


I had to take photographs of the screen or videos with my cell phone camera. 
The error message text only appears for a moment.

--
Jonathan Joseph Chiarella

PGP Fingerprint: 8B54 67AE 714B 8A5B D479 F578 6AAB 963C 0402 061A

Bug#833313: Fwd: -sc -cdb misses that there are already asterisks in the comments

[Santiago Vila]

Hello.

A long time ago, I received the following report from the Debian bug system.

I've just checked and it still happens in indent 2.2.13 (which I plan to
upload for Debian unstable soon).

Note: There are a few more indent bugs here, already forwarded, it would be
wonderful if you could take a look at some of them before the next release:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=indent

Thanks.

 Mensaje reenviado 
Asunto: -sc -cdb misses that there are already asterisks in the comments
Fecha: Tue, 02 Aug 2016 14:03:57 +0200
De: Wouter Verhelst 
Para: Debian Bug Tracking System 

Package: indent
Version: 2.2.11-4
Severity: normal

Hi,

input:

int main(void) {
/* Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras ut
 * sodales turpis, scelerisque auctor erat. In lobortis purus ac
 * fringilla ultricies. Vivamus ut odio a est convallis aliquet nec ac
 * sem. In posuere dolor a fermentum bibendum. Aliquam non massa sed
 * augue blandit ultricies nec id velit. Vestibulum fringilla mi vel
 * varius malesuada. Nunc vel libero et dui pharetra lobortis at eget
 * erat.*/
return 0;
}

running indent -sc -cdb over that produces:

int
main (void)
{
  /*
   * Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras ut
   * * sodales turpis, scelerisque auctor erat. In lobortis purus ac
   * * fringilla ultricies. Vivamus ut odio a est convallis aliquet nec ac
   * * sem. In posuere dolor a fermentum bibendum. Aliquam non massa sed
   * * augue blandit ultricies nec id velit. Vestibulum fringilla mi vel
   * * varius malesuada. Nunc vel libero et dui pharetra lobortis at eget
   * * erat.
   */
  return 0;
}

the extra vertical line of asterisks here is obviously superfluous, and should
not appear.

[...]

Bug#1040257: schleuder-cli does not work with Ruby >= 3.0.0

[Georg Faerber]

Hi,

Thanks for your report.

On 23-07-03 23:50:03, s3lph wrote:
> [...]
>
> Upstream has fixed the issue on the main branch, but has not yet
> created a new release containing the fix.  The fix is quite small,
> only two lines diff:
> 
> https://0xacab.org/schleuder/schleuder-cli/-/commit/68754cf94cc2d9b2a400ff19d2e48a7ffa2ec1f2
> 
> With this patch applied manually, schleuder-cli works as expected:
>
> [...]

Indeed, I forgot to pull this into Debian, apologies for that. That's
fixed now via 0.1.0-5.

bookworm-pu is tracked via #1040791.

Cheers,
Georg

Bug#1040688: wx3.2-examples: Some examples do not compile

[Scott Talbert]

On Sun, 9 Jul 2023, joel wrote:


Package: wx3.2-examples
Version: 3.2.2+dfsg-2
Severity: normal
X-Debbugs-Cc: j.o.elpub...@gmail.com

Dear Maintainer,

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

  * What led up to the situation?
Tried to compile examples to understand wx-config flags.

  * What exactly did you do (or not do) that was effective (or
ineffective)?
Installed a clean debian VM.
Installed wx3.2-examples and the suggested libwxgtk3.2-dev + g++ and make
Copied /usr/share/doc/wx3.2-examples/examples/samples to a writable dir.
make
# failed
Iterate over each directory and make in each.
Some are windows only and generate compile errors, but I have omitted
those.

  * What was the outcome of this action?
The following did not compile due to link errors:
archive
console
ipc
sockets

--
eg:
/usr/bin/ld: console_console.o: warning: relocation against 
`_ZTV17wxMDIClientWindow' in read-only section 
`.text._ZN17wxMDIClientWindowC2Ev[_ZN17wxMDIClientWindowC5Ev]'
/usr/bin/ld: console_console.o: in function `wxWindowBase::GetBestVirtualSize() 
const':
console.cpp:(.text._ZNK12wxWindowBase18GetBestVirtualSizeEv[_ZNK12wxWindowBase18GetBestVirtualSizeEv]+0x25):
 undefined reference to `wxWindowBase::GetBestSize() const'
/usr/bin/ld: console_console.o: in function `wxWindowBase::CanBeFocused() 
const':


Thanks for the bug report.  I can confirm the issue.  It looks like the 
console-based (ie, non-GUI) samples are mistakenly being compiled with GUI 
support, which fails at the link stage.  I'll report this upstream.


Thanks,
Scott

Bug#1040791: bookworm-pu: package schleuder-cli/0.1.0-4+deb12u1

[Georg Faerber]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debianb...@s3lph.me
Control: affects -1 + src:schleuder-cli

Dear release team,

[ Reason ]
Ruby 3.1, as shipped in bookworm, changes the way values are escaped, in
contrast to Ruby <= 3.0. This was fixed upstream in schleuder-cli quite
some time ago, but so far not released.

The patch was pulled into Debian unstable via 0.1.0-5.

[ Impact ]
Severe, as schleuder-cli ceases to work, and throws a traceback due to
an "undefined method".

[ Tests ]
Tests were done both manually and via the upstream CI. The correctness
of the patch was confirmed via #1040257.

[ Risks ]
There should be none.

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

[ Changes ]
An upstream patch was pulled in to correctly handle escaping values in
Ruby 3.1.

For details, see the attached debdiff of 0.1.0-4, as currently present
in bookworm, and 0.1.0-4+deb12u1.

Thanks for your work!

Cheers,
Georg
diff -Nru schleuder-cli-0.1.0/debian/changelog schleuder-cli-0.1.0/debian/changelog
--- schleuder-cli-0.1.0/debian/changelog	2021-02-01 22:47:06.0 +
+++ schleuder-cli-0.1.0/debian/changelog	2023-07-10 16:06:00.0 +
@@ -1,3 +1,11 @@
+schleuder-cli (0.1.0-4+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
+- Pull in upstream patch to fix escaping values in Ruby 3.
+  (Closes: #1040257)
+
+ -- Georg Faerber   Mon, 10 Jul 2023 16:06:00 +
+
 schleuder-cli (0.1.0-4) unstable; urgency=medium
 
   [ Utkarsh Gupta ]
diff -Nru schleuder-cli-0.1.0/debian/patches/0004-Ruby-3-fix-escaping-values.patch schleuder-cli-0.1.0/debian/patches/0004-Ruby-3-fix-escaping-values.patch
--- schleuder-cli-0.1.0/debian/patches/0004-Ruby-3-fix-escaping-values.patch	1970-01-01 00:00:00.0 +
+++ schleuder-cli-0.1.0/debian/patches/0004-Ruby-3-fix-escaping-values.patch	2023-07-10 16:06:00.0 +
@@ -0,0 +1,31 @@
+Description: Ruby 3: fix escaping values
+Origin: https://0xacab.org/schleuder/schleuder-cli/-/commit/68754cf94cc2d9b2a400ff19d2e48a7ffa2ec1f2
+Reviewed-by: Georg Faerber 
+Last-Update: 2023-07-10
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: schleuder-cli/lib/schleuder-cli.rb
+===
+--- schleuder-cli.orig/lib/schleuder-cli.rb	2023-07-10 15:42:53.037304520 +
 schleuder-cli/lib/schleuder-cli.rb	2023-07-10 15:42:53.029303960 +
+@@ -3,6 +3,7 @@
+ require 'pathname'
+ require 'net/https'
+ require 'uri'
++require 'cgi'
+ require 'singleton'
+ require 'yaml'
+ require 'base64'
+Index: schleuder-cli/lib/schleuder-cli/helper.rb
+===
+--- schleuder-cli.orig/lib/schleuder-cli/helper.rb	2023-07-10 15:42:53.037304520 +
 schleuder-cli/lib/schleuder-cli/helper.rb	2023-07-10 15:42:53.029303960 +
+@@ -19,7 +19,7 @@
+   u = "/#{args.join('/')}.json"
+   if params
+ paramstring  = params.map do |k,v|
+-  "#{URI.escape(k.to_s)}=#{URI.escape(v.to_s)}"
++  "#{CGI.escape(k.to_s)}=#{CGI.escape(v.to_s)}"
+ end.join('&')
+ u << "?#{paramstring}"
+   end
diff -Nru schleuder-cli-0.1.0/debian/patches/series schleuder-cli-0.1.0/debian/patches/series
--- schleuder-cli-0.1.0/debian/patches/series	2021-02-01 22:47:06.0 +
+++ schleuder-cli-0.1.0/debian/patches/series	2023-07-10 16:06:00.0 +
@@ -1,3 +1,4 @@
+0004-Ruby-3-fix-escaping-values.patch
 0003-gemspec-relax-thor-version.patch
 0002-spec-remove-bundler.patch
 0001-lib-use-require-instead-of-require-relative.patch

Bug#1040714: dhcpcd: Missing epoch from souce package version

[Martin-Éric Racine]

On Mon, Jul 10, 2023 at 7:05 PM Salvatore Bonaccorso  wrote:
> On Sun, Jul 09, 2023 at 10:39:59PM +0300, Martin-Éric Racine wrote:
> > On Sun, Jul 9, 2023 at 10:33 PM Salvatore Bonaccorso  
> > wrote:
> > > On Sun, Jul 09, 2023 at 09:25:33PM +0200, Salvatore Bonaccorso wrote:
> > > > Source: dhcpcd
> > > > Version: 10.0.1-1
> > > > Severity: serious
> > > > Justification: Debian version goes backwards from previous released 
> > > > versions
> > > > X-Debbugs-Cc: car...@debian.org
> > > >
> > > > Hi
> > > >
> > > > The new src:dhcpcd has a lower version of any previous released
> > > > src:dhcpd version, which had an epoch:
> > >
> > > Apologies for the typo, should be src:dhcpcd in both cases obviously
> > > :(
> >
> > Which is a slightly different issue than what Andtreas reported at
> > #1037190.  Sorry.
>
> No problem, just reopenng while we discuss it.

Agreed.

> > Unless I'm mistaken, we're basically looking at 2 separate issues:
> >
> > 1) bin:dhcpcd from Wheezy has a higher epoch that the one in Bookworm.
> > This is easily fixed as explained in #1037190 for Bookworm.
> >
> > 2) Since transiting the source from src:dhcpcd5 to src:dhcpcd we're
> > missing an epoch for everything. This requires reverting the above fix
> > and simply introducing an epoch for the whole src and binaries.
>
> Yes correct, this is maninly as well what I was referring to. But that
> would solve as well at same time the former issue right, if we drop
> all special casing for epoch on the binary packages, is this correct?

In Trixie, for the version, it would. Just insert the epoch for the
whole source (which would apply to the binaries generated too) and
we're done.

However, we still need that preinst script to clean up possible Wheezy
leftovers.

In Bookworm, we'll still need the version mingle just for one binary
target. debdiff for stable-proposed-updates are on #1037190 and the
upload is ready on Mentors.

> So if we add the epoch to the whole src;dhcpcd version, and to the
> produced binaries I think all the issues should be resolved.
>
> My background is here:
> https://security-tracker.debian.org/tracker/source-package/dhcpcd
> e.g. https://security-tracker.debian.org/tracker/CVE-2002-1403 will be
> considered not yet fixed, because for dpkg:
>
> $ dpkg --compare-versions 1:1.3.22pl2-2 lt 10.0.1-1
> $ echo $?
> 1

I was actually wondering how to close those old CVE against the old fork.

> > Or have I misunderstood the issue?
>
> No, I think we are on the same page in my understnding!

Excellent.

Martin-Éric

Bug#1040689: List of emacs related packages installed

[Balbir Thomas]

I am able to reproduce this problem with just the following emacs packages
and NO elpa-* package installed

emacs
emacs-bin-common
emacs-common
emacs-common-non-dfsg
emacs-el
emacs-gtk
emacsen-common

I did this by first "apt remove --purge" all elpa-* packages and also
emacs-goodies-el. The I also did "apt autoremove".

Hope this helps.


On Mon, Jul 10, 2023 at 10:39 AM David Bremner  wrote:

> Balbir Thomas  writes:
>
> > As requested I am listing below all Emacs related
> > packages installed. These list was generated using
> > "dpkg --get-selections" and grepping for "emacs" and
> > "elpa".
>
> On IRC you later mentioned you duplicated the problem with a smaller set
> of packages installed. It would be helpful to know what precisely the
> packages are. Note that emacs-goodies-el is just a dependency package
> that brings in a bunch of "elpa-*" packages, so it doesn't really make
> sense that (as I thought I understood you say), only the "emacs-*"
> packages from the list were installed.
>
> d
>

Bug#1037420: bookworm-pu: package systemd/252.11-1~deb12u1

[Felix Geyer]

Hi Luca,

On Mon, 12 Jun 2023 15:33:45 +0100 Luca Boccassi  wrote:
> Dear Release Team,
>
> 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. This is the first upload to bookworm-p-u so this is
> a pre-approval request.

This stable update is affected by the regression (compared to what's in stable)
described in #1040149

I saw you merged the fix [1] into the upstream 252 stable branch.
Since the 12.1 deadline is approaching fast, are you planning to do another
stable upload with that commit cherry-picked?

Cheers,
Felix

[1] 
https://github.com/systemd/systemd-stable/commit/34e834f496338fdc2a8a8cc771cba4082079cf9a

Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation

[Steve McIntyre]

Hi, and thanks for your bug report!

On Mon, Jul 10, 2023 at 05:27:50PM +0200, yogg wrote:
>Package: installation-reports
>Severity: serious
>Tags: d-i
>Justification: https://wiki.debian.org/MachineId
>

...

>After installation was finished and the system has been restarted the
>files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked
>in any way (no soft or hardlink) and the ID inside the files differ
>from each other.

I've confirmed this bug just now, doing a clean installation from the
12.0.0 amd64 netinst.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
 kittens, except the kittens randomly appear and disappear because they
 have day jobs." -- Matt Mackall

Bug#1017520: Still alive in 4:2.27.5-2

[Karl Schmidt]

I checked the file it mentions - it exists (probably the source of the error?)

The file belongs to plasma-workspace-data

The error fires off in the log in sets of 4 -

2023-07-09T19:44:13.921511-05:00 singapore plasmashell[2077]: Could not find the Plasmoid for 
Plasma::FrameSvgItem(0x7f7214028120) QQmlContext(0x558176238800) 
QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")





--

Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street  Ph (785) 841-3089
Lawrence, KS 66049

Collective intelligence fails - science is not a popularity contest.
kps

Bug#940312: /etc/issue: /etc/issue is being updated by Debian when it doesn't need to

[Santiago Vila]

El 10/7/23 a las 17:57, Ben Wong escribió:

Thanks for the tip! I will look into ansible. I had thought it was for large 
organizations, but if it is what Debian recommends for upgrades, then I am 
happy to learn it.


Ok, just to clarify: ansible was only one of many options available, and also
I'm not speaking on behalf of Debian, only based on my personal experience.

For upgrading without dpkg questions, you might want to try the 
"unattended-upgrades"
package first, which is quite popular.

The reason I suggested ansible is because I have used it in the past to upgrade
some servers in my last job, from oldstable to stable, and it worked well 
enough,
but in my case I wanted to do extra steps after the upgrade and ansible was well
suited for that.

Thanks.

Bug#1040237: New project leader of Masqmail: Oswald Buddenhagen

[markus schnalke]

Hoi,

it has been several years without any work by me on masqmail.
Recently, Debian decided to kick the masqmail package out of its
repos, which is understandable as it has been RC-buggy for years
without a maintainer. This motivated Oswald Buddenhagen to revive
the project. :-)

We exchanged emails and now I officially want to hand over the
project to him.

The new home of masqmail is:

https://github.com/ossilator/masqmail

My masqmail website will remain as an archive. If there's a wish or
need to change the mailinglist, it'll be announced here.


It's nice to see masqmail come back to life again, in a way similar
to when I took it over from Oliver Kurth. Oswald, however, is not
new to the project; he used it long before I even heard of it. ;-)


meillo

Bug#1040714: dhcpcd: Missing epoch from souce package version

[Salvatore Bonaccorso]

Control: reopen -1 

Hi Martin-Eric,

On Sun, Jul 09, 2023 at 10:39:59PM +0300, Martin-Éric Racine wrote:
> On Sun, Jul 9, 2023 at 10:33 PM Salvatore Bonaccorso  
> wrote:
> > On Sun, Jul 09, 2023 at 09:25:33PM +0200, Salvatore Bonaccorso wrote:
> > > Source: dhcpcd
> > > Version: 10.0.1-1
> > > Severity: serious
> > > Justification: Debian version goes backwards from previous released 
> > > versions
> > > X-Debbugs-Cc: car...@debian.org
> > >
> > > Hi
> > >
> > > The new src:dhcpcd has a lower version of any previous released
> > > src:dhcpd version, which had an epoch:
> >
> > Apologies for the typo, should be src:dhcpcd in both cases obviously
> > :(
> 
> Which is a slightly different issue than what Andtreas reported at
> #1037190.  Sorry.

No problem, just reopenng while we discuss it.

> Unless I'm mistaken, we're basically looking at 2 separate issues:
> 
> 1) bin:dhcpcd from Wheezy has a higher epoch that the one in Bookworm.
> This is easily fixed as explained in #1037190 for Bookworm.
> 
> 2) Since transiting the source from src:dhcpcd5 to src:dhcpcd we're
> missing an epoch for everything. This requires reverting the above fix
> and simply introducing an epoch for the whole src and binaries.

Yes correct, this is maninly as well what I was referring to. But that
would solve as well at same time the former issue right, if we drop
all special casing for epoch on the binary packages, is this correct?

So if we add the epoch to the whole src;dhcpcd version, and to the
produced binaries I think all the issues should be resolved.

My background is here:
https://security-tracker.debian.org/tracker/source-package/dhcpcd
e.g. https://security-tracker.debian.org/tracker/CVE-2002-1403 will be
considered not yet fixed, because for dpkg:

$ dpkg --compare-versions 1:1.3.22pl2-2 lt 10.0.1-1
$ echo $?
1

> Or have I misunderstood the issue?

No, I tink we are on the same page in my understnding!

Thank you for looking into this issue.

Regards,
Salvatore