Bug#1051249: linux: s390x: FTBFS: kernel-wedge install-files: missing modules mptfc, mptsas and mptspi

[Salvatore Bonaccorso]

Source: linux
Version: 6.5~rc4-1~exp1
Severity: serious
Tags: ftbfs
Justification: FTBFS
X-Debbugs-Cc: car...@debian.org

linux/6.5~rc4-1~exp1 onwards in experimental FTBFS for s390x:

https://buildd.debian.org/status/fetch.php?pkg=linux=s390x=6.5%7Erc4-1%7Eexp1=1691173177=0

Regards,
Salvatore

Bug#1051248: groff: URW fonts missing from 1.22.4-10 in Bookworm

[Nate Bargmann]

Package: groff
Version: 1.22.4-10
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

   * What led up to the situation?

Upgraded the system from Bullseye to Bookworm.

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

Looked for the U-PR font under
/usr/share/groff/1.22.4/font/devpdf and it is no longer there.

   * What was the outcome of this action?

I get the following error processing my document:

troff: :33: warning: can't find font 'U-PR'

In my document line 33 is:

.fam U-P

   * What outcome did you expect instead?

Not to be surprised by the removal of these fonts that are in
1.22.4-6 in Bullseye and in 1.23.0-2 in Trixie.

I see no mention of intentionally removing these fonts (perhaps
more?) in the Debian ChangeLog file.

I hope these fonts can be restored to Stable without resorting to
manually installing them from an older or newer package.

- - Nate

- -- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'bookworm-fasttrack')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages groff depends on:
ii  groff-base  1.22.4-10
ii  libc6   2.36-9+deb12u1
ii  libgcc-s1   12.2.0-14
ii  libstdc++6  12.2.0-14
ii  libx11-62:1.8.4-2+deb12u1
ii  libxaw7 2:1.0.14-1
ii  libxmu6 2:1.1.3-3
ii  libxt6  1:1.2.1-1.1

Versions of packages groff recommends:
ii  ghostscript  10.0.0~dfsg-11+deb12u1
ii  imagemagick  8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6
ii  libpaper11.1.29
ii  netpbm   2:11.01.00-2
ii  perl 5.36.0-7
ii  psutils  1.17.dfsg-4

groff suggests no packages.

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iGsEARECACsWIQSC1k9rDmfNQfaJu6b7LFEw1VqIGQUCZPakrQ0cbjBuYkBuMG5i
LnVzAAoJEPssUTDVWogZepsAnRzNXA7d+PXvLzzNE+88JNabc9QeAKCh7ef+R/KT
u1CrnwxqH/EDoMs2KA==
=hL1u
-END PGP SIGNATURE-

Bug#1016558: ITA: muse-el

[Manphiz]

Nicholas D Steeves  writes:

> Thank you for the ping!
>
> Manphiz  writes:
>
>> Nicholas D Steeves  writes:
>>> Manphiz  writes:
 Nicholas D Steeves  writes:
> Manphiz  writes:
>> Nicholas D Steeves  writes:
 Nicholas D Steeves  writes:
>>
 However, as it turns out, the savannah repo has a completely different
 layout compared to the current one we package (which is actually based
 on github).
>>>
>> I see.  Thanks for the background.  I think I was meant to say that "the
>> repo structure is more like the github one" to be clear.  Looking at the
>> git log on Savannah, it looks like they changed the directory structure
>> on the first commit when importing[2].
>
> You're welcome.  Yes, I agree that the github fork's structure has
> diverged less, and I vaguely remember that that may have been one of the
> reasons why I chose to watch it for future releases, but the then tag
> never materialised.  As noted previously, I'm ok with switching to the
> fork if that's what you'd prefer to do long-term!  As the maintainer you
> get to pick the most high-quality and well-maintained upstream for the
> Debian source, because you're the one who is responsible to our users.
>

Sounds good.  I'll give it a little more thoughts.

 In fact, the savannah one uses a Makefile that assumes the project
 layout as the github one while some of the directories like "lisp" are
 not even there (which makes me think whether targeting the savannah
 repo is the correct choice).
>>>
>>> Some words appear to be missing, so I don't understand what you mean.
>>> Please consult d/rules to learn why an upstream Makefile is irrelevant
>>> by-design to this package.  Also, consult the dh-elpa man page and
>>> perhaps also team documentation on our wiki.  It's also worth consulting
>>> MELPA packages (and the source used by MELPA) to see how Makefile's
>>> aren't needed there either.
>>
>> I kinda know that an Emacs addon doesn't really require a Makefile to be
>> usable for melpa.  Still, I still consider leaving a non-working
>> Makefile around a bad habit.  Anyway, point taken.
>
> Agreed, it's technical debt at this point.  As the new Debian
> maintainer, please consider sending this upstream a patch or a request
> to remove the unused file.
>

Indeed.  Will experiment some more when working on the next revision.

 Therefore, I'd like to postpone the sync with savannah repo to a
 future upload to avoid more immediate work for uploading if that's OK.
>>>
>>> That's OK with me!  As noted previously, I'll support the decision you
>>> make in your choice of future upstream, but it needs to be a conscious
>>> and principled decision.  If you don't want to decide at this time,
>>> please implement a method that will remind you (or a future maintainer)
>>> to investigate and fix this issue.  Tldr, we don't want to switch back
>>> and forth between GNU source and fork source.
>>>
>>
>> Added a reminder in d/watch as a future work[3].
>
> Do you mind if I enhance this significantly?  Find proposal in-line, at
> the end of the email.

No problem!  Patch applied, rebuilt, and reuploaded to mentors[1].
PTAL.

[1] https://mentors.debian.net/package/muse-el/

> Also, I'd like this to be more visible, so I'll
> file a bug titled something like "Choose living upstream for muse-el,
> and merge updates" if you don't.  I'm vaguely starting to remember that
> the issue about a future upstream was raised during my early
> contributions, but then I forgot all about it ;) Also, as the fixes for
> Emacs compat eventually start accumulating we'll end up becoming a
> second fork.
>

Makes sense.  Filed Bug#1051247 for tracking.  Will probably get to it
in the next revision.

 Another hackier way I can think of is to build-deps on git and run "git
 restore" in override_dh_auto_clean, but I felt requiring the repo to be
 a git repo may fail buildd? Not sure though.  Anyway, it seems using a
 patch is a cleaner solution compared to this.
>>>
>>> Right, you cannot use git restore.  If we used the upstream Makefile's
>>> "make clean" target, I would concede that patching the Makefile was the
>>> correct approach.
>>>
>>
>> Ah OK.  I understand your reasoning.  I've reverted the patch approach
>> and as an alternative implemented the approach in [4] in the spirit of
>> autoreconf.  PTAL.
>
> LGTM.
>
>
>
> diff --git a/debian/changelog b/debian/changelog
> index b172159..725e7bd 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -19,11 +19,15 @@ muse-el (3.20+dfsg-8) unstable; urgency=medium
>  workaround #1021502.
>* Drop section referencing non-existing file in debian/copyright to fix
>  lintian warning superfluous-file-pattern.
> -  * Fix d/watch to track the savannah git repo.
>* Drop lintian override of wrong-section-according-to-package-name.
>* Save and restore lisp/muse-autoloads.el to prevent it from changing
>  when build-twice-in-a-row.  Closes: 

Bug#1040066: RM: python-marshmallow-enum -- RoM; replaced by python-marshmallow >= 3.18.0

[Louis-Philippe Véronneau]

retitle 1040066 RM: python-marshmallow-enum -- RoM; replaced by python-marshmallow 
>= 3.18.0
reassign 1040066 ftp.debian.org
severity 1040066 normal
thanks


$ ssh po...@mirror.ftp-master.debian.org "dak rm -Rn flask-appbuilder"

Will remove the following packages from unstable:

flask-appbuilder | 4.1.4+ds-3 | source
python-flask-appbuilder-doc | 4.1.4+ds-3 | all
python3-flask-appbuilder | 4.1.4+ds-3 | all

Maintainer: Debian Python Team 

--- Reason ---

--


Checking reverse dependencies...
No dependency problem found.


flask-appbuilder still depends on this package, but:

* it is not in bookworm (removed from testing in 2022-12-16)
* it currently FTBFS from #1036167 and upstream still hasn't got a fix

Since flask-appbuilder is team-maintained, I did try to be a good citizen and 
make it build again.
Although I failed (since upstream still hasn't fixed #1036167), I did update 
the VCS to the latest upstream version
and triaged the BTS! (maybe this will get me some more leniency?? :D)

All in all:

* python-marshmallow-enum not being available anymore won't change anything for 
flask-appbuilder (it'll stay broken)
* the fix for flask-appbuilder with regards to the removal of 
python-marshmallow-enum is trivial and has already been committed in the VCS [1]

As such, please remove python-marshmallow-enum from the archive.


[1]: 
https://salsa.debian.org/python-team/packages/flask-appbuilder/-/commit/ccc94f13af57d72b1335ffb262e793b61d74ffd5

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051246: php8.2: ftbfs on some architectures: Cannot find sys/sdt.h which is required for DTrace support

[Bo YU]

Source: php8.2
Version: 8.2.10-1
Severity: serious
Tags: ftbfs patch

Dear Maintainer,

The php8.2 has ftbfs issue on some architectures due to common error[0]:
```
checking for sys/sdt.h... no
configure: error: Cannot find sys/sdt.h which is required for DTrace
support
cd ext-build && tail -v -n \+0 config.log
```

The full log you can get from:
https://buildd.debian.org/status/fetch.php?pkg=php8.2=riscv64=8.2.10-1=1693732277=0


But i found the systemtap-sdt-dev package was built on these
architectures[1]. Maybe I have missing something.

I can confirm the patch that is worked on riscv64.

[0]: https://buildd.debian.org/status/package.php?p=php8.2
[1]: https://packages.debian.org/unstable/systemtap-sdt-dev

-- 
Regards,
--
  Bo YU

diff -Nru php8.2-8.2.10/debian/control php8.2-8.2.10/debian/control
--- php8.2-8.2.10/debian/control2023-09-02 06:31:05.0 +
+++ php8.2-8.2.10/debian/control2023-09-02 06:31:05.0 +
@@ -67,7 +67,7 @@
netbase,
netcat-openbsd,
re2c,
-   systemtap-sdt-dev [amd64 i386 powerpc armel armhf ia64],
+   systemtap-sdt-dev,
tzdata,
unixodbc-dev,
zlib1g-dev


signature.asc
Description: PGP signature

Bug#1036167: flask-appbuilder: Fails to build against python3-flask-sqlalchemy 3.0.3-1

[Louis-Philippe Véronneau]

I can confirm this is still the case with upstream version 4.3.6.

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#975550: Package removal

[Alexander H.]

If the package is no longer being maintained, maybe it would be better to
remove it completely.

Bug#1051245: ITP: golang-github-bep-logg -- fast and structured logging package for Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-bep-logg
  Version : 0.2.0-1
  Upstream Authors: TJ Holowaychuk, Bjørn Erik Pedersen
* URL : https://github.com/bep/logg
* License : Expat
  Programming Lang: Go
  Description : fast and structured logging package for Go

 This is a fork of the exellent Apex Log (https://github.com/apex/log)
 library.
 .
 Main changes:
 .
  * Trim unneeded dependencies.
  * Make Fields into a slice to preserve log order.
  * Split the old Interface in two and remove all but one Log method (see
below).
  * This allows for lazy creation of messages in Log(fmt.Stringer) and
ignoring fields added in LevelLoggers with levels below the Loggers.
  * The pointer passed to HandleLog is not safe to use outside of the
current log chain, and needs to be cloned with Clone first if that's
needed.
 .
 This is probably the very fastest structured log library when logging is
 disabled.

Reason for packaging: a dependency of hugo (>= 0.114.0)

Bug#1051244: rust-tesseract-sys, upcoming rust-bindgen update.

[Peter Green]

Package: rust-tesseract-sys
Version: 0.5.14-3

In the rust team we are working on upgrading rust-bindgen from 0.60 to
0.66, there are a few reasons for this. Firstly it's part of the dependency 
stack
for the new version of rust-cargo. Secondly the version currently in sid has a
compatibility issue with new versions of llvm. Thirdly Jonas has filed a bug 
report
requesting the new upstream version.

bindgen bumps semver on most releases, however the changes tend to be
relatively minor. You can read the changelog at
https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#0610
I don't see anything too scary in there.

The new version of rust-bindgen has been uploaded to experimental so people
can test against it. After bumping the dependencies your package built
successfully and the autopkgtests passed. I Checked upstream and it seems
they have bumped to 0.64 with a commit that did not contain any code changes.

The attatched debdiff, raises the upper limit for the bindgen dependency.
diff -Nru rust-tesseract-sys-0.5.14/debian/changelog 
rust-tesseract-sys-0.5.14/debian/changelog
--- rust-tesseract-sys-0.5.14/debian/changelog  2023-08-20 09:21:50.0 
+
+++ rust-tesseract-sys-0.5.14/debian/changelog  2023-09-05 00:09:36.0 
+
@@ -1,3 +1,10 @@
+rust-tesseract-sys (0.5.14-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump bindgen dependency to 0.66
+
+ -- Peter Michael Green   Tue, 05 Sep 2023 00:09:36 +
+
 rust-tesseract-sys (0.5.14-3) unstable; urgency=medium
 
   * update DEP-3 patch headers
diff -Nru rust-tesseract-sys-0.5.14/debian/control 
rust-tesseract-sys-0.5.14/debian/control
--- rust-tesseract-sys-0.5.14/debian/control2023-02-03 09:53:28.0 
+
+++ rust-tesseract-sys-0.5.14/debian/control2023-09-05 00:09:36.0 
+
@@ -5,7 +5,7 @@
  clang ,
  debhelper-compat (= 13),
  dh-cargo (>= 25),
- librust-bindgen-0.60+default-dev ,
+ librust-bindgen-0.66+default-dev ,
  librust-leptonica-sys-0.4+default-dev ,
  librust-pkg-config-0.3+default-dev (>= 0.3.19) ,
  libstring-shellquote-perl,
@@ -22,7 +22,7 @@
 Architecture: all
 Multi-Arch: foreign
 Depends:
- librust-bindgen-0.60+default-dev,
+ librust-bindgen-0.66+default-dev,
  librust-leptonica-sys-0.4+default-dev,
  librust-pkg-config-0.3+default-dev (>= 0.3.19),
  libtesseract-dev,
diff -Nru rust-tesseract-sys-0.5.14/debian/patches/1001_bindgen.patch 
rust-tesseract-sys-0.5.14/debian/patches/1001_bindgen.patch
--- rust-tesseract-sys-0.5.14/debian/patches/1001_bindgen.patch 1970-01-01 
00:00:00.0 +
+++ rust-tesseract-sys-0.5.14/debian/patches/1001_bindgen.patch 2023-09-05 
00:09:32.0 +
@@ -0,0 +1,20 @@
+Description: update bindgen to 0.66
+ Upstream has already updated bindgen to 0.64, they did not seem to make
+ any code changes as part of the process
+Author: Peter Michael Green 
+Forwarded: no
+Last-Update: 2023-09-05
+
+Index: rust-tesseract-sys-0.5.14/Cargo.toml
+===
+--- rust-tesseract-sys-0.5.14.orig/Cargo.toml
 rust-tesseract-sys-0.5.14/Cargo.toml
+@@ -15,7 +15,7 @@ build = "build.rs"
+ leptonica-sys = "~0.4"
+ 
+ [build-dependencies]
+-bindgen = "0.60"
++bindgen = "0.66"
+ [target.'cfg(windows)'.build-dependencies]
+ vcpkg = "0.2.8"
+ [target.'cfg(any(target_os="macos", target_os="linux"))'.build-dependencies]
diff -Nru rust-tesseract-sys-0.5.14/debian/patches/2002_no_windows.patch 
rust-tesseract-sys-0.5.14/debian/patches/2002_no_windows.patch
--- rust-tesseract-sys-0.5.14/debian/patches/2002_no_windows.patch  
2023-08-14 10:19:32.0 +
+++ rust-tesseract-sys-0.5.14/debian/patches/2002_no_windows.patch  
2023-09-05 00:05:54.0 +
@@ -9,7 +9,7 @@
 @@ -16,7 +16,5 @@
  
  [build-dependencies]
- bindgen = "0.60"
+ bindgen = "0.66"
 -[target.'cfg(windows)'.build-dependencies]
 -vcpkg = "0.2.8"
  [target.'cfg(any(target_os="macos", target_os="linux"))'.build-dependencies]
diff -Nru rust-tesseract-sys-0.5.14/debian/patches/series 
rust-tesseract-sys-0.5.14/debian/patches/series
--- rust-tesseract-sys-0.5.14/debian/patches/series 2022-10-24 
15:06:57.0 +
+++ rust-tesseract-sys-0.5.14/debian/patches/series 2023-09-05 
00:08:00.0 +
@@ -1 +1,2 @@
+1001_bindgen.patch
 2002_no_windows.patch

Bug#1051243: tex-common: fmtutil failed on tex-common upgrade

[Brent]

Package: tex-common
Version: 6.18
Severity: normal
X-Debbugs-Cc: webe...@aim.com

When upgrading tex-common, I got the following error:

Processing triggers for tex-common (6.18) ...
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.EOWFLEkd
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
 tex-common

Not all changes and updates succeeded. For further details of the failure,
please expand the 'Details' panel below.



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

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

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  13.11.6

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libpaper-utils 1.1.29
ii  sensible-utils 0.0.20
ii  texlive-binaries   2023.20230311.66589-3
ii  ucf3.0043+nmu1
ii  xdg-utils  1.1.3-4.1

Versions of packages texlive-base recommends:
ii  lmodern  2.005-1

Versions of packages texlive-base suggests:
ii  acroread [pdf-viewer]9.5.5-dmo16
ii  evince [postscript-viewer]   45~alpha-2
ii  ghostscript [postscript-viewer]  10.01.2~dfsg-1
ii  perl-tk  1:804.036-1+b2
pn  xzdec

Versions of packages texlive-binaries depends on:
ii  libc6   2.37-7
ii  libcairo2   1.16.0-7
ii  libfontconfig1  2.14.2-4
ii  libfreetype62.13.2+dfsg-1
ii  libgcc-s1   13.2.0-2
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   8.0.1-1
ii  libicu7272.1-3
ii  libkpathsea62023.20230311.66589-3
ii  libmpfr64.2.0-1
ii  libpaper1   1.1.29
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-1
ii  libpotrace0 1.16-2
ii  libptexenc1 2023.20230311.66589-3
ii  libstdc++6  13.2.0-2
ii  libsynctex2 2023.20230311.66589-3
ii  libteckit0  2.5.11+ds1-1+b1
ii  libtexlua53-5   2023.20230311.66589-3
ii  libtexluajit2   2023.20230311.66589-3
ii  libx11-62:1.8.6-1
ii  libxaw7 2:1.0.14-1
ii  libxi6  2:1.8-1+b1
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.12-1.1
ii  libxt6  1:1.2.1-1.1
ii  libzzip-0-130.13.72+dfsg.1-1.1
ii  perl5.36.0-7
ii  t1utils 1.41-4
ii  zlib1g  1:1.2.13.dfsg-3

Versions of packages texlive-binaries recommends:
pn  dvisvgm   
ii  texlive-base  2022.20230122-3

-- debconf information:
  texlive-base/texconfig_ignorant:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil:   /etc/texmf/web2c/fmtutil.cnf
fmtutil [INFO]: writing formats under /var/lib/texmf/web2c
fmtutil [INFO]: --- remaking pdftex with pdftex
fmtutil: running `pdftex -ini   -jobname=pdftex -progname=pdftex 
-translate-file=cp227.tcx *pdfetex.ini' ...
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) (INITEX)
 restricted \write18 enabled.
 (/usr/share/texlive/texmf-dist/web2c/cp227.tcx)
entering extended mode
(/usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini
(/var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex)
(/usr/share/texlive/texmf-dist/tex/plain/etex/etex.src
(/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex
Preloading the plain format: codes, registers, parameters, fonts, more fonts,
macros, math definitions, output routines, hyphenation
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex
[skipping from \patterns to end-of-file...]))
(/usr/share/texlive/texmf-dist/tex/plain/etex/etexdefs.lib
Skipping module "grouptypes"; Loading module "interactionmodes";
Skipping module "nodetypes"; Skipping module "iftypes";)
(/var/lib/texmf/tex/generic/config/language.def
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex))
Augmenting the Plain TeX definitions: \tracingall;
Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone,
register allocation; extended register allocation; 
Recycling: \addlanguage, \@nswer (not defined), \@sk, \b@dresponsetrue,
\b@dresponsefalse, \ch@ckforyn, 

Bug#1051222: [debian-mysql] Bug#1051222: mariadb FTCBFS: passes host CFLAGS to the native build

[Otto Kekäläinen]

Thanks for your submission!

I cloned this into a MR at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/53
so others can review, and that CI can verify that it cross-builds work
now.

Bug#1051242: ITP: a2d/2.0.0-1 -- APRS to DAPNET portal

[Yogu NY3W]

Package: wnpp
Owner: Yogeswaran Umasankar 
Severity: wishlist

* Package name : a2d
   Version  : 2.0.0-1
   Upstream contact : Yogeswaran Umasankar 
 * URL  : https://github.com/NGC2023/a2d
 * License  : CC-BY-3.0, MIT
 * Vcs  : https://github.com/NGC2023/a2d
   Section  : hamradio
   Description: APRS to DAPNET portal

This portal serves as a bridge between the APRS
 Automatic Packet Reporting System and the DAPNET
 Decentralized Amateur Paging Network platform. It
 allows APRS users to relay their APRS messages and
 alerts to their DAPNET pager. This integration
 enables seamless communication between two distinct
 radio communication systems, enhancing the reach and
 accessibility of critical information for
 amateur radio enthusiasts.

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/a2d/a2d_2.0.0-1.dsc

Changes for the initial release:

 a2d (2.0.0-1) unstable; urgency=medium
 .
   * Initial release.
 - Fixed Debian-changelog-line-too-long.
 - Fixed maintainer-script-calls-systemctl.
 - Fixed maintainer-script-ignores-errors.
 - Removed subdirectories from usr/bin/.
 - Addressed rest of lintian warnings.

Regards,
-- 
  Yogeswaran Umasankar

Bug#1050929: telegram-desktop: System window decorations disabled on Wayland after 4.9.3

[z411]

Thanks for the reply. I'm not sure if I understand.

On Sat, 02 Sep 2023 16:39:47 +0300 Nicholas Guriev  
wrote:> Set the QT_QPA_PLATFORM environment variable to "xcb" value 
before running

Telegram Desktop. And the setting will reappear because of XWayland.


Telegram already used Wayland before this (as do all Qt5/Qt6 apps) and 
it had the option for system decorations. The icon also worked, for some 
reason it doesn't work now.


The latest official release (4.9.3) also works on Wayland with system 
decorations, and the 4.8.1 Debian package works as well. Even with 
QT_QPA_PLATFORM=wayland. It even shows some warnings related to Wayland 
and xeyes shows me it's not running under XWayland. Please correct me if 
I'm wrong.



In genuine Wayland there is no such thing as system decorations.


As far as I understand, there is, there's the xdg-decoration-v1 protocol 
supported by KWin and Sway which they use to draw system decorations on 
Wayland windows.


Again, please correct me if I'm wrong.
Cheers.

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

[Alexandru Mihail]

Greetings again,

#1
Changes rejected:
mini-httpd_1.30-4.dsc: Invalid size hash for mini-
httpd_1.30.orig.tar.gz:
According to the control file the size hash should be 43469,
but mini-httpd_1.30.orig.tar.gz has 43889.

If you did not include mini-httpd_1.30.orig.tar.gz in your upload, a
different version
might already be known to the archive software.
#2

> until you receive the "accepted" email before pushing your tag to
> g...@salsa.debian.org:debian/mini-httpd.git, and please push the
> master
> branch there at your earliest convenience.
> 
Just to recap here: following our previous mail's logic, namely:
  git clone g...@salsa.debian.org:debian/mini-httpd.git
  cd mini-httpd
  git remote add alex g...@salsa.debian.org:alexandru_mihail/mini-
httpd.git
  git fetch alex  # just so you have another backup
  dch -r
  git commit debian/changelog -m "Release 1.30-4 to unstable."
  # do your tagging procedure
  git push --delete alex debian/1.30-4
  git push -f alex master debian/1.30-4

This results in:
worker@Debian:~/git/mini-httpd$ git diff origin/master..HEAD
diff --git a/debian/changelog b/debian/changelog
index ad0073c..73a286b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,7 +14,7 @@ mini-httpd (1.30-4) unstable; urgency=medium
   * Clarified NCSA origins of mini-httpd htpasswd* by adding a
corresponding
 copyright entry with proper attribution.
 
- -- Alexandru Mihail   Tue, 04 Jul
2023 23:49:19 +0300
+ -- Alexandru Mihail   Tue, 05 Sep
2023 01:29:43 +0300
 
 mini-httpd (1.30-3) unstable; urgency=medium
 
worker@Debian:~/git/mini-httpd$ git show origin
commit 1c8f17316e8f1f787c478e0428cfdd27b5c9ca1b (origin/master,
origin/HEAD)
Merge: d736d78 acfc103
Author: Nicholas D Steeves <2201-s...@users.noreply.salsa.debian.org>
Date:   Wed Aug 23 21:50:16 2023 +

Merge branch 'master' into 'master'

Merge 1.30-4 release from new maintainer

See merge request debian/mini-httpd!2

Pushing tag & master would just amount to:
git push origin debian/1.30-4
git push
?
Going to sleep, looking forward to hearing from you tomorrow (its 3AM
here :D)

Have a nice $part_of_day !

> Congratulations, and enjoy your holidays! :)
> 
> Cheers,
> Nicholas
Thank you !
All the best,
Alexandru



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

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

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail  writes:

>>   # Fix git config email and gpg identity, then
[snip]
>> 
> I fixed my git config and redid the tag as discussed above

Thanks!

>> Sorry I only noticed this when I manually inspected and compared the
>> tag
> Yeah, sorry too :)
> I'll be going on vacation for two weeks so I will be available via mail
> but won't be able to push unless we coordinate that tomorrow (roughly
> 14 Hrs from now would be when I have to leave. If not I'll happily push
> afterwards (14th September).
> Tag is in the usual spot:
> https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4

I just uploaded and sent you an invitation that grants Maintainer
permissions for this repository.  You will receive two emails from the
FTP Masters (Debian archive).  The first will be a "processing" email
that says the release was uploaded successfully, and the second will be
that mini-httpd was accepted into Debian unstable/sid.  Please wait
until you receive the "accepted" email before pushing your tag to
g...@salsa.debian.org:debian/mini-httpd.git, and please push the master
branch there at your earliest convenience.

Congratulations, and enjoy your holidays! :)

Cheers,
Nicholas


signature.asc
Description: PGP signature

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

[Alexandru Mihail]

Hello Nicholas,

> Did you realise that you're still committing using your protonmail.ch
> address (and presumably GPG identity)?  Early in this process you
> switched to a gmail address, and I understood that that was the one
> that
> you would be using for for your Debian work.  

Damn, it seems the web GUI tricked us both..I was convinced I sorted
that out (GPG was already O.K but mail was not *sigh*) Many thanks for
your attention to detail :D


>   # Fix git config email and gpg identity, then
>   git clone g...@salsa.debian.org:debian/mini-httpd.git
>   cd mini-httpd
>   git remote add alex g...@salsa.debian.org:alexandru_mihail/mini-
> httpd.git
>   git fetch alex  # just so you have another backup
>   dch -r
>   git commit debian/changelog -m "Release 1.30-4 to unstable."
>   # do your tagging procedure
>   git push --delete alex debian/1.30-4
>   git push -f alex master debian/1.30-4
> 
I fixed my git config and redid the tag as discussed above
> Sorry I only noticed this when I manually inspected and compared the
> tag
Yeah, sorry too :)
I'll be going on vacation for two weeks so I will be available via mail
but won't be able to push unless we coordinate that tomorrow (roughly
14 Hrs from now would be when I have to leave. If not I'll happily push
afterwards (14th September).
Tag is in the usual spot:
https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4



> Cheers,
> Nicholas
> 
Have a great one,
Alexandru
> P.S. FYI, to get Salsa's Gitlab instance to show green verified
> commits
> and tags you may also need to update your email address and gpg key
> there.  I don't care about this so long as the actual git data is
> correct, but you (and/or others) might.
Did that too, no reason not to :)



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

Bug#1051241: headsup for gtk + pipewire update

[Matthias Geiger]

Package: helvum
Severity: normal
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Jonas. This is just a heads-up for the upcoming gtk + pipewire
transition I am working on. the latest (0.4.1) release of helvum
does depend on the versions I will update to anyway; so this won't be
much of an issue. A problem might be helvum 0.4.1 depending on rustc
1.70. Can you maybe test if you can get it to build with the older one
currently in debian ? note that I patched all gtk-rs crates to use the
older version; they are compiling fine.

I will upload gtk-rs probably until eow.

best,

werdahias 



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

Kernel: Linux 6.4.7-surface (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
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: openrc (via /sbin/openrc-init)
LSM: AppArmor: enabled

Versions of packages helvum depends on:
ii  libc62.36-9+deb12u1
ii  libcairo-gobject21.17.8-2
ii  libcairo21.17.8-2
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.76.3-1
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-4-1   4.10.3+ds-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpipewire-0.3-00.3.65-3

helvum recommends no packages.

helvum suggests no packages.

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmT2YUAVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1+fwQAKSe2qqGBhvD5ImMrjhj581ikyNP
hUqyFvOkGnxxjaGMS1t++zsI1WYzCLF0psr6uFxbZOLl4WmnixrwBcAm+VTYsEyt
KJhSnRc0oIPi6ZuIHli5RDTg1Tx+OJp7Ia092jZUSP4FAI29lxJBmdJSFInJx7BN
9AM247/d6u9TGsc4mwWehqOxg1rGTtj/3pB6qX6VOY2WZIvkkgfxomxveLf9EBT/
8ge6bZijVnwRRQa9clbULssoGdT1JGtctHLlxJ8OWtEiWCG3iG11H2Nny+mnq/0c
Fx0oCvnrXegiqSc/ZL2P/GWpJXmIpzu96sA3XTdlpX5l7m9TK61tO38F/Edx3CKJ
hHuHpi4lgwdL6JYVS/Dn6zUj1FlNeBomNvq6UvSuOk9Zt++sq5/n4PXx/hMv+Ebi
Ij71br9Lkdpza2nPhnG8NM6W5oe7Lp3fX6jVBPIJufpsDGuEjaCz2lo/2Rt62g+A
VMpS8JeikZ8rstORhunrywTKYMrR+kBY+l3QOFnAxQTGtEzYxQaT1DrJxkHHF5zd
DvCqhGFqp1Ec8OuWdaBcmdP8CunPncsjIn845pf9KcYSZHLe8DVwiX8IC8D7y1GW
dyLfZXv02z+qThLiOh1UIr0Pchpwzp1IWws/7eX/swTWGkfcLotmF9UwCXJjmV2y
8tvoLy+0GwCubbri
=FVYM
-END PGP SIGNATURE-

Bug#1051240: Symlink to 'compare' missing from graphicsmagick-imagemagick-compat

[Otto Kekäläinen]

Package: graphicsmagick-imagemagick-compat
Version: 1.4+really1.3.41-1

Hi!

I noticed that from the latest version of
https://packages.debian.org/sid/all/graphicsmagick-imagemagick-compat/filelist
the symlink to 'compare' is missing.

I added it manually on my system with:
  sudo ln -s gm /usr/bin/compare

At least basic case works just fine:

compare -file result.png before.jpg after.jpg

Bug#1051056: transmission-daemon: memory leaks lead to eventual memory exhaustion

[Fufu Fang]

This issue has been reported in Github. I think recent versions of
Transmission all have memory leak. 

For version 3.0, I think the first mention is here:
https://github.com/transmission/transmission/issues/3077

The latest bug fix in 4.0.0 branch is here: 
https://github.com/transmission/transmission/pull/5748

Bug#1015848: Salvaging xmlstarlet

[Matthias Geiger]

Control: retitle -1 ITA: xmlstarlet -- command line XML toolkit

I stumbled across this bug when I needed xmlstarlet for editing .gir 
files. I intend to adopt it and get it into better shape as it is now.


Since there is no upstream development anymore I'll focus on the following:

- Migrating the repo to salsa

- Updating the package to the latest packaging standards

- Fixing lintian and build errors

best,

--
Matthias Geiger (werdahias)



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051235: aircrack-ng: package file and binary reported as malware/mirai by 3 different malware scanners

[Samuel Henrique]

Hello Hugues,

> I obtain almost the same results with a subtle variant (Mirai.A ->
> Mirai.qahkj) while scanning the aircrack-ng binary itself, which I
> extracted directly from the .deb package:
>
> file: aircrack-ng/aircrack-ng_1.7-5_amd64/usr/bin/aircrack-ng
> sha256: 
> d58a36fa6360bac0419650786e690f4691a3ba62f3710eb7db24d6d5d90e7c71
>
> - bitdefender : Trojan.Linux.Generic.274536
> - avira : SPR/ANDR.Mirai.qahkj
> - fsecure : PrivacyRisk.SPR/ANDR.Mirai.qahkj (6, 1, 1)

Considering aircrack-ng is open source (and our aircrack-ng packaging
too), this seems very unlikely, it would have been caught much earlier
by other people.
It's also common for scanners to trigger false-positives on security
related tools.

> I struggle finding evidences of a possible false alert, making me
> considering this as a potentially credible issue. I would gladly help
> investigate this further on, if you need so.

What did you look for when investigating this as a false positive?

Do you get the same finding when scanning the package's source code?
https://salsa.debian.org/pkg-security-team/aircrack-ng

Thank you for the report,

-- 
Samuel Henrique 

Bug#1051239: bookworm-pu: package dar/2.7.8-2

[John Goerzen]

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


[ Reason ]

A bug was recently reported to Debian as #1050663, and subsequently to upstream.
This bug causes dar to create isolated catalog files that cannot be read by a
future dar invocation.  The catalog files are used as the basis for backups, so
this breaks users' backup flows.

Upstream has not yet pinned down the cause for the issue; however, reports are
that it looks tied to gcc versions 12 or above.  This version does exist in
bookworm.

A workaround patch has been developed that mitigates the problems on all tested
systems.  I have already applied that patch to 2.7.12-1, which is uploaded to
unstable.  The same patch applies to 2.7.8.

We are not yet certain of the trigger of the issue.  It is possible that some
binary builds on some archs in bookworm are not impacted.  However, for maximum
safety, this patch should be included.

[ Impact ]

While the initial full backup will be created fine, attempts to create future
incremental or differential backups could fail with a dar crash due to this
issue.

Reducing the impact of the issue: the issue only arises when --on-fly-isolate is
used.  That is not the only way to create an isolated catalog, and isolated
catalogs are not used in every workflow.  Also, the backups that dar does create
are fully intact.  However, a script that doesn't check the exit status of dar
may believe a backup was successfully created when it was not.

[ Tests ]

There is no automated test suite over this part of the code.  However, the patch
has been tested on the dar mailing list, including on Debian.

[ Risks ]

The patch is trivial.  Detection of corrupted catalogs should be fairly
immediate as well.

[ 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 ]

This includes just the small patch to address the issue.

[ Other info ]

Please advise whether or not the upload to bookworm should be source-only.
diff -Nru dar-2.7.8/debian/changelog dar-2.7.8/debian/changelog
--- dar-2.7.8/debian/changelog  2022-12-04 08:57:33.0 -0600
+++ dar-2.7.8/debian/changelog  2023-09-04 15:07:26.0 -0500
@@ -1,3 +1,10 @@
+dar (2.7.8-2) bookworm; urgency=high
+
+  * Include a patch that can prevent issues with creating isolated catalogs
+with dar built using gcc 12 or newer.  Closes: #1050663.
+
+ -- John Goerzen   Mon, 04 Sep 2023 15:07:26 -0500
+
 dar (2.7.8-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru dar-2.7.8/debian/patches/series dar-2.7.8/debian/patches/series
--- dar-2.7.8/debian/patches/series 2022-12-04 08:57:33.0 -0600
+++ dar-2.7.8/debian/patches/series 2023-09-04 15:07:12.0 -0500
@@ -2,3 +2,4 @@
 fix_dcf_path.patch
 fix_Hurd_FTBFS.patch
 link_with_assuan.patch
+slice_layout.cpp-remove_ternary_operator.patch
diff -Nru 
dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch 
dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch
--- dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch 
1969-12-31 18:00:00.0 -0600
+++ dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch 
2023-09-04 15:07:02.0 -0500
@@ -0,0 +1,21 @@
+Description: Fix on-fly-isolate with recent GCC #1050663
+Author: Thomas 
+Last-Update: 2023-08-30
+
+---
+
+--- DAR_a/src/libdar/slice_layout.cpp  2023-09-02 09:08:49.657051708 +0200
 DAR_b/src/libdar/slice_layout.cpp  2023-09-02 09:11:39.240669572 +0200
+@@ -54,7 +54,11 @@ namespace libdar
+ 
+ void slice_layout::write(generic_file & f) const
+ {
+-  char tmp = older_sar_than_v8 ? OLDER_THAN_V8 : V8;
++  char tmp = V8;
++  if(older_sar_than_v8)
++  {
++  tmp = OLDER_THAN_V8;
++  }
+   first_size.dump(f);
+   other_size.dump(f);
+   first_slice_header.dump(f);

Bug#1041982: [pkg-php-pear] Upcoming transitions (Symfony, PHPUnit, etc.)

[David Prévot]

Hi,

Le 24/06/2023 à 01:29, William Desportes a écrit :

As far as I understand, there was no more change than the composer bump change 
needed for phpMyAdmin.

So I could introduce an OR to allow both versions.


That would be nice.


And tests pass you said.


Great, #1041982 does not have much blockers anymore, maybe we can 
schedule the transition then.


Regards,

taffit

Bug#1039731: php-laravel-lumen-framework: FTBFS with symfony 6: unsatisfiable build-dependencies

[David Prévot]

Hi,

Le Wed, Jun 28, 2023 at 03:41:28PM -0300, Athos Ribeiro a écrit :
> Source: php-laravel-lumen-framework
> Version: 8.3.4-1
[…]
> We are about to start the symfony 6 transition in unstable. During a test
> rebuild, php-laravel-lumen-framework was found to fail to build with symfony 
> 6.

Just documenting in the bug report that it’s a known issue, and that a
new major upstream version of Laravel is needed to use Symfony 6.

Regards

taffit


signature.asc
Description: PGP signature

Bug#1051238: ITP: biome -- formatter and linter for web languages

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Javascript Maintainers 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: biome
  Version : 1.0.0
  Upstream Contact: Rome Tools is Rome Tools, Inc.
* URL : https://biomejs.dev/
* License : Expat
  Programming Lang: Rust, Node.js
  Description : formatter and linter for web languages

 Biome formats and lints your code in a fraction of a second.
 .
 Biome supports JavaScript, TypeScript, JSON, and CSS.
 It aims to support all main languages of modern web development.
 .
 Biome has sane defaults and requires minimal configuration.
 Biome helps you as much as possible
 by displaying detailed and contextualized diagnostics.
 .
 Biome unifies functionality that has previously been separate tools.
 Building upon a shared base allows us to provide a cohesive experience
 for processing code, displaying errors, parallelizing work,
 caching, and configuration.
 .
 Biome is designed to eventually replace Babel, ESLint, webpack,
 Prettier, Jest, and others.

This package will be maintained in the collaborative debian section of
salsa, at https://salsa.debian.org/debian/biome
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmT2P20ACgkQLHwxRsGg
ASEZWg//TeQDd1oBh1KOyQvlEQkq6aducgElCNp/fas9oXJt+wIbw2E5o62c74Iw
4fqYiHJp7+hwA9Ld87G0llqdokhAPsq4+bwH21x4EDoNSaWBlcBjc1V6q8g22g/b
xm0cI2cQKC15MhVls+WuDKpdHeGZHqxp4F3dWoCXbmJtFK82nMkWJkXZOh3UiJ+P
/dPV5mI1Y/uexZZZmww+LKdt51ma100kZbAf+P4XgQOo43zKiiguE3RSVYd5CKgv
3i5i0V5OCFeoYr1vsXL2G1G0vrNZHDygJ6V88F2VpMe/AxHShLpnhL5PaQgAEFeq
scKmLpV7blYU4qDXp3im3OP9mJsetovNLhvr0b9HuLn8U3QhmJoOZ4CoydmMAoNJ
Kj8crKndk+ioZa3ct15SdUjOmQCrrQ5w47VjDvlyIpx7BrKeA7jquVLC367/LcZQ
H0MyMu4Gy6YvHYKXB6OvWO8GJPJo/63vVz/AJYYuR7NT3Q0C3eBKr/VW1p555Yyd
k/12Qv5p+QmlN0u0vniLX3i4Ftr3sGNhcjxCVAgYqsRZyTUR1rtdRgY9Bf9qTkFC
jbdUrxrUfiyuunQimUlTDbsAIykZQac5f4cHViDWiGdCv6niAJaVQOatwFHslM4B
SffnPOG3kdMjZpgIwlpGhVhxLEjETlPKcfE22EsOKmPiKtkzCaE=
=fldg
-END PGP SIGNATURE-

Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

[Helmut Grohne]

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

Dear release team,

you may be aware from d-devel@l.d.o discussions that things got rolling
regarding a way forward from our current /usr-merge state. The results
of various discussions have been recorded in DEP17[1]. The rough idea is
that files in all packages move from / to /usr. I think this change
qualifies as a transition and should be coordinated with you. If you
disagree with this and do not want to get involved, please just close
this transition request.

A major blocker regarding this finalization is the file move moratorium.
I note that this is given as advice/recommendation rather than being
mandatory (thanks Ansgar). However, the release team also indicated
enforcement[2] of it. The current best idea is to progressively lift the
moratorium by documenting the current state of lifting at
https://wiki.debian.org/UsrMerge (not yet documented there) and then
officially repealing the moratorium while recommending to follow those
guides.

As we move files, we will run into issues such as lost files. Some of
the issues are automatically identified by the Debian Usr Merge
Analysis Tool https://salsa.debian.org/helmutg/dumat. I'm regularly
updating the output https://subdivi.de/~helmut/dumat.yaml. The intention
is to automatically file RC bugs for some classes of issues (e.g file
conflicts), but at the time of this writing I'm still filing bugs
manually.

The exact way of lifting the moratorium is not clear at this time. It
shall be adapted depending on the amount of (expected and unexpected)
issues we face. In total, there are around 2000 affected binary
packages. More than half of them is only affected due to installing
systemd units. As such moving those units from / to /usr is the first
step. We first move those where upstream build systems install them and
debhelper is prepared to recognize units below /usr. Once that works
reasonably well, dh_installsystemd shall be changed to install to /usr.
This change will cause latent issues. When packages are restructured or
renamed the famous file loss scenario may happen. The dumat service
shall run for the entire release period and detect such issues before
they hit testing.

Moving beyond this step requires more preparation. While systemd still
deals nicely with users in / or /usr, other tools may not and our
buildds are still unmerged. We'll have to wait until DSA has updated
debootstrap to SPU request from Simon McVittie. Also moving files may
affect udebs and the debian-installer is still unmerged. The relevant MR
addressing this needs to be merged.

Once these issues have been resolved, we can move most files except for
a small set of essential packages. For those, a coordinated upload
moving their files will be needed as will be an upload of base-files
adding the aliasing symlinks there.

We probably have to use NMUs to convert remaining packages at this
point. Once everything is moved, we may think we're done, but we're not.
As packages are restructured throughout the release cycle, they may
introduce file loss scenarios. Continued monitoring for problems until
trixie is released is crucial.

As problems are located, context-dependent mitigations from DEP17 are to
be applied. We'll recommend that maintainers upload restructuring
changes to experimental first and given quick bug filing that should
reduce the number of issues in unstable and keep most issues out of
testing. In any case, you can only call this transition bug finished
once trixie is released. For the purpose of keeping bugs out of testing,
I intend to file all relevant bugs (such as file conflicts, file loss,
directory loss, ineffective diversions, missing trigger invocations,
etc.) at RC severity.

I hope this all makes sense to you. Let me know if you disagree about
any of this. Quite probably I am missing some important aspects here.

Unless there is disagreement, I intend to move forward with moving
systemd units on the grounds that the moratorium only is a
recommendation and this transition request.

Helmut

[1] https://salsa.debian.org/dep-team/deps/-/merge_requests/5
rendered version at https://subdivi.de/~helmut/dep17.html

[2] https://lists.debian.org/debian-devel-announce/2022/07/msg2.html

Bug#1051234: tabulate: too old for pandas 2.1

[Rebecca N. Palmer]

Salsa has 0.8.10, but it's been there for some time and I don't know why 
it hasn't been uploaded.

Bug#998834: Multiple subsystem options in sshd_config prevent sshd from starting

[Jan Wagner]

Hi,

Am 09.05.23 um 09:43 schrieb Jan Wagner:

https://bugzilla.mindrot.org/attachment.cgi?id=3591=diff==1=raw
 has a patch for this


what needs to happen to raise the chance to get that integrated? It's 
super annoying to work around this and (re)integrate this back after 
every dist upgrade. If Debian wants to be user friedly this is a feature 
which might underline it.
If there is anything I can help to move things forward, please let me 
know and I will try my best to do so.


Many thanks, Jan

Bug#1051236: proftpd-core: SSH key exchanges fail unexpectedly with "unable to write X bytes of raw data"

[Jeremy Lecour]

Package: proftpd-core
Version: 1.3.8+dfsg-4+deb12u1
Severity: normal

Dear Maintainer,

After upgrading to Debian 12, my SFTP client stopped working with errors when 
connecting.

I've opened a GitHub issue and the problem has been solved.
https://github.com/proftpd/proftpd/issues/1694

It will even be backported to the 1.3.8 branch, so I hope that it might be 
available in an upcoming update in Debian 12.


Thanks.


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

Kernel: Linux 6.1.0-11-cloud-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages proftpd-core depends on:
ii  adduser  3.134
ii  init-system-helpers  1.65.2
ii  libacl1  2.3.1-3
ii  libc62.36-9+deb12u1
ii  libcap2  1:2.66-4
ii  libcrypt11:4.4.33-2
ii  libhiredis0.14   0.14.1-3
ii  libidn2-02.3.3-1+b1
ii  libmemcached11   1.1.4-1
ii  libmemcachedutil21.1.4-1
ii  libncursesw6 6.4-4
ii  libpam-runtime   1.5.2-6
ii  libpam0g 1.5.2-6
ii  libpcre2-8-0 10.42-1
ii  libpcre2-posix3  10.42-1
ii  libssl3  3.0.9-1
ii  libtinfo66.4-4
ii  netbase  6.4
ii  ucf  3.0043+nmu1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages proftpd-core recommends:
pn  proftpd-doc  

Versions of packages proftpd-core suggests:
pn  openbsd-inetd | inet-superserver  
ii  openssl   3.0.9-1
ii  proftpd-mod-crypto1.3.8+dfsg-4+deb12u1
pn  proftpd-mod-geoip 
pn  proftpd-mod-ldap  
pn  proftpd-mod-mysql 
pn  proftpd-mod-odbc  
pn  proftpd-mod-pgsql 
pn  proftpd-mod-snmp  
pn  proftpd-mod-sqlite
ii  proftpd-mod-wrap  1.3.8+dfsg-4+deb12u1

-- Configuration Files:
/etc/init.d/proftpd [Errno 13] Permission denied: '/etc/init.d/proftpd'

-- debconf-show failed

Bug#1050350: flycheck: keep flycheck out of testing until it finds an uploader

[Nicholas D Steeves]

Manphiz  writes:

> control: merge 1050404 -1
> control: block -1 by 1050459
> control: tags -1 patch
>
> Hi,
>
> I've prepared an MR[1] to handle this, which requires a newer
> emacs-buttercup which is being prepared at [2].  PTAL.
>
> [1] https://salsa.debian.org/emacsen-team/flycheck/-/merge_requests/3
> [2] https://salsa.debian.org/emacsen-team/emacs-buttercup/-/merge_requests/1

Belated thank you!  I think it's completely just that a package whose
popularity is at the 99.86th percentile on MELPA and the 96.41th on
MELPA stable blocks a transition, and that your work enabled a more
ideal resolution of this situation.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1051232: bookworm-pu: package 7zip/23.01+dfsg-3~deb12u1

[Moritz Muehlenhoff]

On Tue, Sep 05, 2023 at 04:04:27AM +0900, YOKOTA Hiroshi wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: 7...@packages.debian.org, yokota.h...@gmail.com, 
> b...@debian.org, t...@security.debian.org
> Control: affects -1 + src:7zip
> 
> [ Reason ]
> 1. Fix security issue
>  CVE-2023-31102: https://www.zerodayinitiative.com/advisories/ZDI-23-1165/
>  CVE-2023-40481: https://www.zerodayinitiative.com/advisories/ZDI-23-1164/
>
> 2. Use 7zip-rar package for RAR archives.
>7zip-rar requires 7zip >= 22.01-9

What are the isolated fixes for CVE-2023-40481 and CVE-2023-31102, is there some
kind of public upstream VCS or can you ask upstream about it?

Cheers,
Moritz

Bug#1016558: ITA: muse-el

[Nicholas D Steeves]

Thank you for the ping!

Manphiz  writes:

> Nicholas D Steeves  writes:
>> Manphiz  writes:
>>> Nicholas D Steeves  writes:
 Manphiz  writes:
> Nicholas D Steeves  writes:
>>> Nicholas D Steeves  writes:
>
>>> However, as it turns out, the savannah repo has a completely different
>>> layout compared to the current one we package (which is actually based
>>> on github).
>>
> I see.  Thanks for the background.  I think I was meant to say that "the
> repo structure is more like the github one" to be clear.  Looking at the
> git log on Savannah, it looks like they changed the directory structure
> on the first commit when importing[2].

You're welcome.  Yes, I agree that the github fork's structure has
diverged less, and I vaguely remember that that may have been one of the
reasons why I chose to watch it for future releases, but the then tag
never materialised.  As noted previously, I'm ok with switching to the
fork if that's what you'd prefer to do long-term!  As the maintainer you
get to pick the most high-quality and well-maintained upstream for the
Debian source, because you're the one who is responsible to our users.

>>> In fact, the savannah one uses a Makefile that assumes the project
>>> layout as the github one while some of the directories like "lisp" are
>>> not even there (which makes me think whether targeting the savannah
>>> repo is the correct choice).
>>
>> Some words appear to be missing, so I don't understand what you mean.
>> Please consult d/rules to learn why an upstream Makefile is irrelevant
>> by-design to this package.  Also, consult the dh-elpa man page and
>> perhaps also team documentation on our wiki.  It's also worth consulting
>> MELPA packages (and the source used by MELPA) to see how Makefile's
>> aren't needed there either.
>
> I kinda know that an Emacs addon doesn't really require a Makefile to be
> usable for melpa.  Still, I still consider leaving a non-working
> Makefile around a bad habit.  Anyway, point taken.

Agreed, it's technical debt at this point.  As the new Debian
maintainer, please consider sending this upstream a patch or a request
to remove the unused file.

>>> Therefore, I'd like to postpone the sync with savannah repo to a
>>> future upload to avoid more immediate work for uploading if that's OK.
>>
>> That's OK with me!  As noted previously, I'll support the decision you
>> make in your choice of future upstream, but it needs to be a conscious
>> and principled decision.  If you don't want to decide at this time,
>> please implement a method that will remind you (or a future maintainer)
>> to investigate and fix this issue.  Tldr, we don't want to switch back
>> and forth between GNU source and fork source.
>>
>
> Added a reminder in d/watch as a future work[3].

Do you mind if I enhance this significantly?  Find proposal in-line, at
the end of the email.  Also, I'd like this to be more visible, so I'll
file a bug titled something like "Choose living upstream for muse-el,
and merge updates" if you don't.  I'm vaguely starting to remember that
the issue about a future upstream was raised during my early
contributions, but then I forgot all about it ;) Also, as the fixes for
Emacs compat eventually start accumulating we'll end up becoming a
second fork.

>>> Another hackier way I can think of is to build-deps on git and run "git
>>> restore" in override_dh_auto_clean, but I felt requiring the repo to be
>>> a git repo may fail buildd? Not sure though.  Anyway, it seems using a
>>> patch is a cleaner solution compared to this.
>>
>> Right, you cannot use git restore.  If we used the upstream Makefile's
>> "make clean" target, I would concede that patching the Makefile was the
>> correct approach.
>>
>
> Ah OK.  I understand your reasoning.  I've reverted the patch approach
> and as an alternative implemented the approach in [4] in the spirit of
> autoreconf.  PTAL.

LGTM.



diff --git a/debian/changelog b/debian/changelog
index b172159..725e7bd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -19,11 +19,15 @@ muse-el (3.20+dfsg-8) unstable; urgency=medium
 workaround #1021502.
   * Drop section referencing non-existing file in debian/copyright to fix
 lintian warning superfluous-file-pattern.
-  * Fix d/watch to track the savannah git repo.
   * Drop lintian override of wrong-section-according-to-package-name.
   * Save and restore lisp/muse-autoloads.el to prevent it from changing
 when build-twice-in-a-row.  Closes: #1048114.

+  [ Xiyue Deng & Nicholas D Steeves ]
+  * Correct watch file so that it tracks the official GNU project on Savannah,
+rather than the fork on Github.  Additionally, start tracking all upstream
+activity (not just tags).
+
  -- Xiyue Deng   Thu, 24 Aug 2023 14:12:01 -0700

 muse-el (3.20+dfsg-7) unstable; urgency=medium
diff --git a/debian/watch b/debian/watch
index 72b2e40..02072a0 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,5 +1,7 @@
-# The current repo is not yet synced to 

Bug#1039733: php-oscarotero-gettext: FTBFS with symfony 6: make[1]: *** [debian/rules:18: override_dh_auto_test] Error 1

[David Prévot]

Hi James,

Le Wed, Jun 28, 2023 at 03:42:21PM -0300, Athos Ribeiro a écrit :
> Source: php-oscarotero-gettext
> Version: 4.8.7-1
[…]
> We are about to start the symfony 6 transition in unstable. During a test
> rebuild, php-oscarotero-gettext was found to fail to build with symfony 6.

Looking at the composer.json file, the dependency seems to be of the 2
era… ("symfony/yaml": "~2",).

Version 5 of php-oscarotero-gettext published four years ago, doesn’t
depend (directly) on symfony/yaml anymore. Is it possible that the
reverse dependencies (shaarli?) can use the 5 branch?

Regards,

taffit


signature.asc
Description: PGP signature

Bug#1039732: php-monolog: FTBFS with symfony 6: make[1]: *** [debian/rules:25: override_dh_auto_test] Error 1

[David Prévot]

Hi,

Le Wed, Jun 28, 2023 at 03:41:55PM -0300, Athos Ribeiro a écrit :
[…]
> Relevant part (hopefully):
> > There were 2 failures:
> > 
> > 1) 
> > Monolog\Handler\StreamHandlerTest::testWriteNonExistingAndNotCreatablePath 
> > with data set "/foo/bar/…" ('/foo/bar/9033/4989')
> > Failed asserting that exception of type "UnexpectedValueException" is 
> > thrown.
> > 
> > 2) 
> > Monolog\Handler\StreamHandlerTest::testWriteNonExistingAndNotCreatablePath 
> > with data set "file:///foo/bar/…" ('file:///foo/bar/5691/6462')
> > Failed asserting that exception of type "UnexpectedValueException" is 
> > thrown.

It’s a false positive probably triggered by the build environment (this
version is used/usable by Symfony 6, that would have been weird ;).

Regards

taffit


signature.asc
Description: PGP signature

Bug#1050663: Fwd: Re: [Dar-support] Fwd: Bug#1050663: dar option --on-fly-isolate creates catalogue with broken slice_layout

[John Goerzen]

>From the thread on the dar support mailing list:

https://sourceforge.net/p/dar/mailman/message/37890758/

On Sat, Sep 02 2023, Thomas wrote:

> On Wed, Aug 30, 2023 at 03:24:12PM -0500, John Goerzen wrote:
>> On Wed, Aug 30 2023, Denis Corbin wrote:
>>
>> >> Summary
>> >> ===
>> >> g++ 10 works fine with optimization.
>> >> g++ 11 or newer work only without optimization.
>> >> Hope this helps.
>> >
>> > Thanks for confirming this is a gcc issue. I don't know what should be the 
>> > next
>> > step, if someone fills a bug report to gcc Debian maintainer?
>>
>> Well, to be sure, we have a couple of possibilities:
>>
>> 1) This is a gcc bug,
>>
>> or 2) There is something in dar (or, for that matter, bzip2 or some
>> other library) that is relying on some sort of C/C++ undefined behavior
>> (UB) that the optimizer is taking in a different direction.  Other
>> possibilities could include race conditions, etc.
>
> To find the root cause why the optimizer does something harmfull in our
> case is way over my head.
>
> But...
> I have found a workaround for dar. The appended patch works for me with
> dar v2.7.11 and g++ v13.2.0, v12.3.0 and v11.4.0. Means, files generated
> with OnFlyIsolation are readable again with default optimizations
> activated.
> It seems the optimizer does not like the used ternary operator.
>
> I tested the patch with g++ v10.4.0 and 9.3.0, too without problems but
> these versions are working with or without this patch anyway.
>
> Hope this helps.
>
> Tom
>
> [2. text/x-diff; slice_layout.cpp-remove_ternary_operator.patch]...

diff -rupN DAR_a/src/libdar/slice_layout.cpp DAR_b/src/libdar/slice_layout.cpp
--- DAR_a/src/libdar/slice_layout.cpp	2023-09-02 09:08:49.657051708 +0200
+++ DAR_b/src/libdar/slice_layout.cpp	2023-09-02 09:11:39.240669572 +0200
@@ -54,7 +54,11 @@ namespace libdar
 
 void slice_layout::write(generic_file & f) const
 {
-	char tmp = older_sar_than_v8 ? OLDER_THAN_V8 : V8;
+	char tmp = V8;
+	if(older_sar_than_v8)
+	{
+		tmp = OLDER_THAN_V8;
+	}
 	first_size.dump(f);
 	other_size.dump(f);
 	first_slice_header.dump(f);

Bug#1050256: autopkgtest fails on debci

[John Johansen]

On 9/4/23 12:32, Michael Biebl wrote:

Am 04.09.23 um 20:23 schrieb Mathias Gibbens:

On Mon, 2023-09-04 at 01:00 -0700, John Johansen wrote:

I took a quick look through v6.1..v6.3.1

there is a patch that I think is the likely fix, it first landed in v6.2

1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets


   Thanks for the pointer John -- I think that is the fix we've been
looking for!

   Commit 1cf26c3d2c4c doesn't apply cleanly to the v6.1 tree due to the
other commits from the patchset of Oct 3, 2022 that modified a bunch of
the apparmor code. Because I couldn't quickly cherry-pick all the
changes without amassing a large diff, I made the small proof-of-
concept patch at the end of this message and applied it to the  6.1.38-
4 kernel from bookworm. Booting with the patched kernel allows services
to start up in containers without any issues. :)

   So, I think the next step should be to get that commit properly
backported to the v6.1 longterm tree and included in an upstream
release. Hopefully that would be able to happen in enough time so that
it is bundled with the kernel updates for bookworm's point release next
month. If not, we should be sure to get it into Debian's packaging so
at least there's a proper fix available.



Thanks for the update Mathias, this looks very promising.
A stable update of the Linux 6.1.x kernel would obviously be the ideal solution.

John, could you help with getting this fix into 6.1.x?



yes, I am working on a patch.

Bug#1051235: aircrack-ng: package file and binary reported as malware/mirai by 3 different malware scanners

[Hugues Hiegel]

Package: aircrack-ng
Version: 1.7-5_amd64
Severity: normal
Tags: security
X-Debbugs-Cc: hug...@hiegel.fr, Debian Security Team 

Hello,

scanning an entire mirror of binary (amd64) packages from Debian stable
using a white station led to consistent alerts raised by three different
scanners (out of ~10) with aircrack-ng package. Following are the exact
alert messages:

file: aircrack-ng/aircrack-ng_1.7-5_amd64.deb
sha256: 2c128adb6fef5864952205dab30ca361fdc677ea1d3cfce4424790f7cc69bfc6

- bitdefender : Trojan.Linux.Generic.274536
- avira : SPR/ANDR.Mirai.A
- fsecure : PrivacyRisk.SPR/ANDR.Mirai.A (6, 1, 1)


I obtain almost the same results with a subtle variant (Mirai.A ->
Mirai.qahkj) while scanning the aircrack-ng binary itself, which I
extracted directly from the .deb package:

file: aircrack-ng/aircrack-ng_1.7-5_amd64/usr/bin/aircrack-ng
sha256: d58a36fa6360bac0419650786e690f4691a3ba62f3710eb7db24d6d5d90e7c71

- bitdefender : Trojan.Linux.Generic.274536
- avira : SPR/ANDR.Mirai.qahkj
- fsecure : PrivacyRisk.SPR/ANDR.Mirai.qahkj (6, 1, 1)


I struggle finding evidences of a possible false alert, making me
considering this as a potentially credible issue. I would gladly help
investigate this further on, if you need so.

With best regards,
Hugues.

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

Kernel: Linux 5.19.0-50-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1050256: autopkgtest fails on debci

[Michael Biebl]

Am 04.09.23 um 20:23 schrieb Mathias Gibbens:

On Mon, 2023-09-04 at 01:00 -0700, John Johansen wrote:

I took a quick look through v6.1..v6.3.1

there is a patch that I think is the likely fix, it first landed in v6.2

1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets


   Thanks for the pointer John -- I think that is the fix we've been
looking for!

   Commit 1cf26c3d2c4c doesn't apply cleanly to the v6.1 tree due to the
other commits from the patchset of Oct 3, 2022 that modified a bunch of
the apparmor code. Because I couldn't quickly cherry-pick all the
changes without amassing a large diff, I made the small proof-of-
concept patch at the end of this message and applied it to the  6.1.38-
4 kernel from bookworm. Booting with the patched kernel allows services
to start up in containers without any issues. :)

   So, I think the next step should be to get that commit properly
backported to the v6.1 longterm tree and included in an upstream
release. Hopefully that would be able to happen in enough time so that
it is bundled with the kernel updates for bookworm's point release next
month. If not, we should be sure to get it into Debian's packaging so
at least there's a proper fix available.



Thanks for the update Mathias, this looks very promising.
A stable update of the Linux 6.1.x kernel would obviously be the ideal 
solution.


John, could you help with getting this fix into 6.1.x?

Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Simon McVittie]

On Mon, 04 Sep 2023 at 21:03:30 +0200, Michael Stapelberg wrote:
> What do other Linux distributions do? Do they have a similar downstream patch?
> If not, maybe it doesn’t matter much and users aren’t relying on the portal
> functionality after all?

Variously:

* more opinionated distributions like Fedora, Ubuntu and Steam Deck make
  sure this sort of thing works for their flagship desktop environments,
  and anything beyond that is outside their scope;

* more DIY distributions like Arch and Gentoo will presumably expect each
  user of a non-major GUI environment to configure this for themselves,
  with an elaborate wiki page containing advice that might even be accurate;

* anything LTS doesn't have the version of xdg-desktop-portal with this
  change yet, and will have to deal with it when they get there

smcv

Bug#1042082: Please take over udev SysV init script

[Michael Biebl]

Am 03.09.23 um 19:25 schrieb Mark Hindley:

Control: reassign -1 initscripts

Michael,

We have decided that initscripts from src:sysvinit is a better fit for
/etc/init.d/udev. Therefore reassigning.

I have prepared a branch[1]. The only outstanding item I am aware of is to add
versioned Breaks/Replaces against the version of udev that no longer ships the
file.

In my testing of this transition, it became apparent that if udev uses either
dpkg-maintscript-helper rm_conffile or dpkg remove-on-upgrade, user
modifications to /etc/init.d/udev are not preserved. So, I would ask that you
not do that until Forky so we can be sure that any changes to those files are
correctly preserved.

Can you see any other issues?



This doesn't work. Once the ownership of the conffile has moved to 
initscripts, the udev package can no longer remove it (in forky), as 
this would be an instant RC bug.


So what I'm going to do instead is to a one-time clean-up via 
"rm_conffile /etc/init.d/udev" in udev (+ cleaning up the enablement 
symlinks in /etc/rc?.d/)


If /etc/init.d/udev was modified, rm_conffile will create a backup file 
/etc/init.d/udev.dpkg-bak


You can then adopt this backup file in initscripts, if you want.
What you do with it, is up to you: merge the changes in your init 
script, show an info message, etc.


If you want to steal the logic we used in src:systemd to move conffiles 
between packages, see e.g.

https://salsa.debian.org/systemd-team/systemd/-/commit/d6483013d57





OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Nicholas D Steeves]

Hello Alexandru,

Thank you for the ping :)

Alexandru Mihail  writes:

> I've commited and pushed the changes to the remote I was using for the
> MR so far:
> commit:
> https://salsa.debian.org/alexandru_mihail/mini-httpd/-/commit/fc7c4f664dc1369b1bf5d46c8c9b7aa11de68407
>
>
> But I think I may have not commited where I was supposed to, granted
> you've already closed the MR.

You committed in the right place, and yes, as requested pushed to the
remote in your personal namespace rather than to the collaborative space
where mini-httpd is maintained.  Yes, this is what I asked for, because
I wanted to make sure everything was in good order before uploading to
the archive and asking you to push to the actual project (thus making it
permanent).  I'm pulling from your remote directly rather than using the
gitlab now.  Tags on the actual project are immutable (or
should be treated thus), and should only be pushed after an upload has
been accepted, and this is why I wanted to check that everything was
100% good.

Yes, I had already merged your MR, and MRs are automatically closed when
they're merged.

> I've already created a GPG signed tag accessible at:
> https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4

Thanks!

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

This is because the MR was merged already (and thus already closed and
not open for updates).

> Is there something I've glanced over here ?

Did you realise that you're still committing using your protonmail.ch
address (and presumably GPG identity)?  Early in this process you
switched to a gmail address, and I understood that that was the one that
you would be using for for your Debian work.  You'll need to update your
git config to use the new gmail address and gpg identity (try
#debian-mentors on irc.oftc.net if you can't make sense of the docs).

Also, at this time please base your work on debian/mini-httpd.git rather
than alexandru_mihail/mini-httpd.git.

  # Fix git config email and gpg identity, then
  git clone g...@salsa.debian.org:debian/mini-httpd.git
  cd mini-httpd
  git remote add alex g...@salsa.debian.org:alexandru_mihail/mini-httpd.git
  git fetch alex  # just so you have another backup
  dch -r
  git commit debian/changelog -m "Release 1.30-4 to unstable."
  # do your tagging procedure
  git push --delete alex debian/1.30-4
  git push -f alex master debian/1.30-4

Sorry I only noticed this when I manually inspected and compared the tag
and release commit on the CLI...I feel like the web-thing hid this
information from me, and that might be confirmation bias, but it seems
like the same thing happened to you ;)


Cheers,
Nicholas

P.S. FYI, to get Salsa's Gitlab instance to show green verified commits
and tags you may also need to update your email address and gpg key
there.  I don't care about this so long as the actual git data is
correct, but you (and/or others) might.


signature.asc
Description: PGP signature

Bug#1051224: buildd.debian.org: Add osm2pgsql to Packages-arch-specific

[Aurelien Jarno]

Hi,

On 2023-09-04 21:16, Aurelien Jarno wrote:
> control: reassign -1 osm2pgsql
> 
> Hi,
> 
> On 2023-09-04 18:39, Bas Couwenberg wrote:
> > Package: buildd.debian.org
> > Severity: normal
> > Tags: patch
> > 
> > Dear Maintainer,
> > 
> > osm2pgsql upstream no longer supports 32bit architectures, no need to even 
> > try to build the package there.
> > 
> 
> Packages-arch-specific is deprecated and thus we do not add new entries.
> Instead please just list the supported architectures instead of using
> any. The package will appear in the auto-not-for-us section of the
> non-supported architectures and no build will be tried on those
> architectures.

As an alternative, you can also add a build-dependency on
architecture-is-64-bit.

Regards
Aurelien

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

Bug#1051234: tabulate: too old for pandas 2.1

[Rebecca N. Palmer]

Package: python3-tabulate
Version: 0.8.9-1
Severity: wishlist

Upstream pandas 2.1 will only use tabulate >= 0.8.10.  Nothing obviously 
breaks if I override this to accept Debian's 0.8.9, but it might be 
better to actually update tabulate.


(At least to the latest 0.8.x - I don't know whether going to 0.9 would 
break other reverse dependencies.)

Bug#1050638: bullseye-pu: package clamav/0.103.9+dfsg-0+deb11u1

[Sebastian Andrzej Siewior]

On 2023-09-04 19:52:23 [+0100], Adam D. Barratt wrote:
> On Sun, 2023-08-27 at 13:20 +0200, Sebastian Andrzej Siewior wrote:
> > This is a stable update from clamav upstream in the 0.103.x series.
> > It fixes the following CVE
> > - CVE-2023-20197 (Possible DoS in HFS+ file parser).
> > 
> 
> The next point release for both bullseye and bookworm is in a month.
> Were you looking to have the clamav updates published via -updates
> before that point?

I almost started preparing 0.103.10 I think it will be easier to go with
that one instead…

> Regards,
> 
> Adam

Sebastian

Bug#1051224: buildd.debian.org: Add osm2pgsql to Packages-arch-specific

[Aurelien Jarno]

control: reassign -1 osm2pgsql

Hi,

On 2023-09-04 18:39, Bas Couwenberg wrote:
> Package: buildd.debian.org
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> osm2pgsql upstream no longer supports 32bit architectures, no need to even 
> try to build the package there.
> 

Packages-arch-specific is deprecated and thus we do not add new entries.
Instead please just list the supported architectures instead of using
any. The package will appear in the auto-not-for-us section of the
non-supported architectures and no build will be tried on those
architectures.

Regards
Aurelien

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

Bug#1051182: wsjtx: new upstream version 2.7.x

[tony mancill]

On Sun, Sep 03, 2023 at 08:39:38PM -0700, tony mancill wrote:
> This bug is for coordination purposes.  I am in the process of preparing
> an upload of WSJT-X 2.7.0-rc2 to experimental, but I believe that it
> may require an upload of hamlib 4.6 (which will also likely need to go
> to experimental first).
> 
> The debian branch will be pushed to debian/experimental to follow DEP-14
> (https://dep-team.pages.debian.net/deps/dep14/), and if the team is okay
> with it, I propose switching from master -> debian/latest when the
> package is ready for upload to unstable.

I have built wsjtx_2.7.0~rc2+repack-1 against bookworm and tested WSJT-X
running against the current version of hamlib in bookworm without any
issues, so I don't think there is a requirement for this to be
coordinated with an upload of hamlib.

I'll do some more testing in trixie/unstable, but based on what I've
seen so far, I think 2.7.0~rc2 is a candidate for an upload to unstable.
Please let me know if there are any concerns.

Thanks,
tony


signature.asc
Description: PGP signature

Bug#1051233: openpyxl: too old for pandas 2.1

[Rebecca N. Palmer]

Package: python3-openpyxl
Version: 3.0.9-2
Severity: wishlist
Control: affects -1 python3-pandas

Upstream pandas 2.1 will only use openpyxl >= 3.0.10.  If I override 
this to accept Debian's 3.0.9, I get 2 test failures that plausibly 
might be caused by it (but I haven't actually tried it with a newer 
openpyxl).


Is there any particular reason that the recent upload didn't update to a 
newer upstream, or just lack of time/authority to do that?

Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Michael Stapelberg]

On Mon, 4 Sept 2023 at 19:54, Simon McVittie  wrote:

> On Mon, 04 Sep 2023 at 18:56:52 +0200, Michael Stapelberg wrote:
> > > i3 isn’t a desktop environment, it’s a window manager only.
> >
> > It's behaving like a (very small) desktop environment to the extent
> that
> > it installs a file in /usr/share/xsessions, which results in it
> appearing
> > in the menu of possible session types in display managers like gdm,
> > lightdm or sddm.
> >
> > Are you saying only desktop environments may install to the xsessions
> > directory?
> >
> > If so, what is the mechanism for window managers to show up in the
> display
> > manager menu?
>
> It depends where you draw the line between window manager and desktop
> environment. Where I would personally draw that line is:
>
> If it makes sense to log in to a thing as a desktop session in its own
> right, which has some way to run programs in order to be independently
> useful, and preferably some way to exit, then it makes sense to register
> it in xsessions, and it's effectively behaving like a tiny desktop
> environment. For instance, openbox and icewm are definitely this: each
> has a menu that can launch apps and exit. You could call this a desktop
> environment, or if you think that term has other connotations which
> don't apply here, you could call it something else, but it's certainly
> something that is useful to list as an option in e.g. lightdm.
>
> If it doesn't make sense to log in to a thing because it isn't useful on
> its own, then I don't think it should be registered in xsessions or show
> up in the display manager menu. For instance, the /usr/bin/mutter in the
> mutter package is a window manager, but it intentionally isn't registered
> as an xsession, because it isn't useful on its own: it will manage the
> windows of any programs you run some other way, but it doesn't have any
> built-in way to start any programs, so you need to add at least a way to
> run programs (some sort of menu or panel or hotkey mechanism, which it
> doesn't have built-in) to make a directly useful user-facing environment.
>
> I don't know which of those i3 wants to be.
>

i3 definitely aims to be useful on its own, but it also specifically does
not supply enough parts to constitute a full desktop environment.

For features that are unequivocally needed, even among niche window
managers,
i3 will have a component or recommendation (i3bar, i3status, i3lock, dmenu),
but you’re free to swap these out, or decide not to use them.


>
> > When we stop patching xdg-desktop-portal to hard-code its GTK backend
> > as a fallback, the default will be to use no portal backends at all,
> > which means the apps I described above will try and fail to make use
> of
> > those desktop features, unless the user has written a portals.conf(5)
> > of their own (which they can always do anyway, and it will overrule
> the
> > desktop environment's choices).
> >
> > Uhm, why would we actively remove the fallback?
> > I don’t understand the logic behind that.
> > It seems like a decision that will leave users worse off, for no benefit?
>
> The -gtk backend was never really intended to be a fallback: it was
> originally GNOME-specific, and only got used in other environments
> as a last resort because of implementation details of how the portal
> backend is selected. The upstream design of x-d-p was always intended
> to be that each GUI environment would provide its own choice of backend
> (either its own, or shared with other GUI environments) that implements
> the various interfaces in a desktop-appropriate way.
>
> I suggested in an upstream issue[1] that maybe x-d-p-gtk should be
> hard-coded as the portal backend of last resort (as I've done downstream
> in Debian for now), but upstream developers didn't think that was
> appropriate, and the user who originally opened the issue thought that
> an unconfigured x-d-p specifically *shouldn't* start any backends,
> so your opinion on this is noted but is not universally shared.
>
> [1] https://github.com/flatpak/xdg-desktop-portal/issues/1077


Ah, thanks for raising the backward compatibility point upstream.


> We have had some quite bad bugs in the past caused by portal backends
> being run outside their intended environment, failing to find the
> desktop-specific services that they need (for example for screen sharing
> and screencasting under Wayland, which are very implementation-specific),
> and causing crashes or arbitrary delays, so it's important to avoid
> x-d-p's old behaviour where it would arbitrarily pick *any* backend
> if there is none that declares that it supports the current desktop
> environment. I don't *think* x-d-p-gtk has any such interfaces, but I'm
> not in a position to routinely test it on every GUI environment offered
> by Debian.
>

Right. I don’t expect you (or anyone) to routinely test all environments.
But dropping x-d-p-gtk as fallback, which presumably works better than 

Bug#1051231: timg: CVE-2023-40968

[Salvatore Bonaccorso]

Source: timg
Version: 1.4.5-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/hzeller/timg/issues/115
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for timg.

CVE-2023-40968[0]:
| Buffer Overflow vulnerability in hzeller timg v.1.5.2 and before
| allows a remote attacker to cause a denial of service via the
| 0x6120045c address.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-40968
https://www.cve.org/CVERecord?id=CVE-2023-40968
[1] https://github.com/hzeller/timg/issues/115
[2] 
https://github.com/hzeller/timg/commit/2e9414e668144bbe0afc074dac17b74ef4acfdcf

Regards,
Salvatore

Bug#1051230: libxml2: CVE-2023-39615

[Salvatore Bonaccorso]

Source: libxml2
Version: 2.9.14+dfsg-1.3
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/libxml2/-/issues/535
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libxml2.

CVE-2023-39615[0]:
| Xmlsoft Libxml2 v2.11.0 was discovered to contain a global buffer
| overflow via the xmlSAX2StartElement() function at /libxml2/SAX2.c.
| This vulnerability allows attackers to cause a Denial of Service
| (DoS) via supplying a crafted XML file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-39615
https://www.cve.org/CVERecord?id=CVE-2023-39615
[1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/535

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1042543: Known upstream regression in 6.4: audio distortion on ThinkPad X1 Gen 11

[David Heidelberg]

Patch is included in recent stable release, available in unstable. Until 
it gets into testing, this should help:


 $ apt install -t unstable linux-image-amd64

I assume the bug can be closed.

David

On 18/08/2023 04:42, David wrote:

Version: 6.4.4-3

Hello,

1. the bug is still present

2. Dell XPS 9310 is also affected.

It's still not included in stable series, but got merged into for-next 
branch already [1].


Please apply.

Thank you

David

[1] https://www.spinics.net/lists/alsa-devel/msg163701.html

On Sat, 29 Jul 2023 19:58:50 -0700 Josh Triplett 
 wrote:

> Package: src:linux
> Version: 6.4.4-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: j...@joshtriplett.org
>
> See https://github.com/thesofproject/linux/issues/4482 and
> https://bugzilla.kernel.org/show_bug.cgi?id=217673 for the bug, and
> https://github.com/thesofproject/linux/pull/4484 for the fix.
>
> I can confirm that 6.4 has intermittent audio distortion on my system,
> and 6.3 does not.
>
> Please consider applying the fix.


--
David Heidelberg
Certified Linux Magician

Bug#1050638: bullseye-pu: package clamav/0.103.9+dfsg-0+deb11u1

[Adam D. Barratt]

On Sun, 2023-08-27 at 13:20 +0200, Sebastian Andrzej Siewior wrote:
> This is a stable update from clamav upstream in the 0.103.x series.
> It fixes the following CVE
> - CVE-2023-20197 (Possible DoS in HFS+ file parser).
> 

The next point release for both bullseye and bookworm is in a month.
Were you looking to have the clamav updates published via -updates
before that point?

Regards,

Adam

Bug#1051229: tlp 1.6 doesn't conflict with power-profile-daemon anymore

[Sebastien Bacher]

Package: tlp
Version: 1.6.0-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

Reading the changelog from 1.6.0-beta.1

    - Allow coexistence with power-profiles-daemon: do not apply
  PLATFORM_PROFILE_ON_AC/BAT, CPU_ENERGY_PERF_POLICY_ON_AC/BAT and
  CPU_BOOST_ON_BAT/BAT when it is running

The package conflicts isn't needed anymore, the attached patch removes it
diff -Nru tlp-1.6.0/debian/changelog tlp-1.6.0/debian/changelog
--- tlp-1.6.0/debian/changelog	2023-08-30 15:02:39.0 +0200
+++ tlp-1.6.0/debian/changelog	2023-09-04 20:43:27.0 +0200
@@ -1,3 +1,10 @@
+tlp (1.6.0-2) UNRELEASED; urgency=medium
+
+  * Remove the conflicts with power-profile-daemon, the new version
+has been made to adapt its behaviour when the service is installed
+
+ -- Sebastien Bacher   Mon, 04 Sep 2023 20:43:27 +0200
+
 tlp (1.6.0-1) unstable; urgency=medium
 
   * New upstream version 1.6.0
diff -Nru tlp-1.6.0/debian/control tlp-1.6.0/debian/control
--- tlp-1.6.0/debian/control	2023-08-30 15:02:24.0 +0200
+++ tlp-1.6.0/debian/control	2023-09-04 20:43:10.0 +0200
@@ -13,7 +13,7 @@
 Depends: hdparm, iw, pciutils, rfkill, usbutils, ${misc:Depends}
 Recommends: tlp-rdw, ethtool
 Suggests: tp-smapi-dkms, smartmontools, ${dist:Suggests}
-Conflicts: laptop-mode-tools, power-profiles-daemon
+Conflicts: laptop-mode-tools
 Description: Optimize laptop battery life
  TLP is a feature-rich command-line utility, saving laptop battery power
  without the need to delve deeper into technical details.

Bug#1051210: cinnamon: bug in cinnamon-settings

[Fabio Fantoni]

Il 04/09/2023 16:04, Walter Valenti ha scritto:

Package: cinnamon
Version: 5.6.8-1
Severity: minor
X-Debbugs-Cc: debian-cinna...@lists.debian.org, waltervale...@yahoo.it


In System Settings -> Appareance -> Backgrouds, in not possible change the
background image.
This the error for example:



Failed to convert /usr/share/desktop-base/joy-inksplat-
theme/wallpaper/contents/images/3840x2160.svg: module 'PIL.Image' has no
attribute 'ANTIALIAS'

Hi, thanks for report, I already saw it time ago at the merge of the fix 
upstream: 
https://github.com/linuxmint/cinnamon/commit/fce9aad1ebb290802dc550e8dae6344dddf9dec1


I was waiting for new upstream bugfix release but if will not be 
released I'll add that patch in debian/patches on next cinnamon upload 
to experimental or unstable




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051228: shiro: CVE-2023-34478

[Salvatore Bonaccorso]

Source: shiro
Version: 1.3.2-5
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for shiro.

CVE-2023-34478[0]:
| Apache Shiro, before 1.12.0 or 2.0.0-alpha-3, may be susceptible to
| a path traversal attack that results in an authentication bypass
| when used together with APIs or other web frameworks that route
| requests based on non-normalized requests.  Mitigation: Update to
| Apache Shiro 1.12.0+ or 2.0.0-alpha-3+


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-34478
https://www.cve.org/CVERecord?id=CVE-2023-34478
[1] https://lists.apache.org/thread/mbv26onkgw9o35rldh7vmq11wpv2t2qk

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1047929: irclog2html: Fails to build source after successful build

[stefanor]

Hi Lucas (2023.09.04_18:35:47_+)
> This was most likely fixed thanks to that change in dh-python
> 6.20230825:
>* Remove *.egg-info directories in clean step, as part of Debian's wider
>  effort to improve clean targets. Thanks Stuart Prescott for the patch.
> 
> So I'm closing this bug.
> 
> @ Stefano: do you know if something is planned to identify packages that
> are no longer failing after that change, add mass-close relevant bugs? I
> can help by re-checking packages if needed.

That would be appreciated, thank you. I've been meaning to ask you if
you could test-build affected packages, again.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1051209: dpkg-dev: dpkg-source --commit should use configured default editor instead of forcing nano

[Guillem Jover]

Hi!

On Mon, 2023-09-04 at 15:43:02 +0200, Axel Kittenberger wrote:
> Package: dpkg-dev
> Version: 1.22.0
> Severity: normal

>* What led up to the situation?
> 
>  using: dpkg-source --commit
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>  I used `update-alternatives --config editor` because I want to edit with 
> vim.
>  (actually it became the default editor already by manually install 
> vim-gtk3)
> 
>* What was the outcome of this action?
> 
> dpkg-source uses nano
> 
>* What outcome did you expect instead?
> 
> dpkg-source using vim (or just call `editor`)

It should already be using the following list in order when available:

  sensible-editor, $VISUAL, $EDITOR, vi

So, you might want to check whether some of these are set (directly or
indirectly) to «nano». If so, then this would not seem like a problem
in dpkg-source, but I notice this is not documented in the man page,
so I guess even then I'll document that. Otherwise this might need to
cloned and reassigned somewhere else I think?

Thanks,
Guillem

Bug#1050256: autopkgtest fails on debci

[Mathias Gibbens]

On Mon, 2023-09-04 at 01:00 -0700, John Johansen wrote:
> I took a quick look through v6.1..v6.3.1
> 
> there is a patch that I think is the likely fix, it first landed in v6.2
> 
> 1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets

  Thanks for the pointer John -- I think that is the fix we've been
looking for!

  Commit 1cf26c3d2c4c doesn't apply cleanly to the v6.1 tree due to the
other commits from the patchset of Oct 3, 2022 that modified a bunch of
the apparmor code. Because I couldn't quickly cherry-pick all the
changes without amassing a large diff, I made the small proof-of-
concept patch at the end of this message and applied it to the  6.1.38-
4 kernel from bookworm. Booting with the patched kernel allows services
to start up in containers without any issues. :)

  So, I think the next step should be to get that commit properly
backported to the v6.1 longterm tree and included in an upstream
release. Hopefully that would be able to happen in enough time so that
it is bundled with the kernel updates for bookworm's point release next
month. If not, we should be sure to get it into Debian's packaging so
at least there's a proper fix available.

  I'm happy to help test any proposed patch for this fix on my end.

Mathias

-

> --- a/security/apparmor/lib.c 2023-09-04 16:08:28.818066140 +
> +++ b/security/apparmor/lib.c 2023-09-04 16:09:17.56661 +
> @@ -355,6 +355,9 @@
>   perms->allow |= map_other(dfa_other_allow(dfa, state));
>   perms->audit |= map_other(dfa_other_audit(dfa, state));
>   perms->quiet |= map_other(dfa_other_quiet(dfa, state));
> +
> + // For testing only!
> + perms->allow |= AA_MAY_LOCK;
>  }
>  
>  /**


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

Bug#1051227: grub2: Block the 2.12 transition to testing

[Julian Andres Klode]

Source: grub2
Version: 2.12~rc1-7
Severity: serious
X-Debbugs-Cc: j...@debian.org

This bug is a blocking bug for grub2 to be lifted in in October
barring further issues such that we get more testing.

I sadly forgot to also adjust urgency to low.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Bug#1050021:

[Andreas Hasenack]

I have here a patch from upstream that fixes the crash, and a DEP8
test to do a simple check. This test can run in a container, so it
will run in debian's dep8 infrastructure, and it catches this type of
bug. It's less elaborate than the other dep8 tests, but they require a
VM.

These are currently in review on ubuntu at
https://code.launchpad.net/~ahasenack/ubuntu/+source/glusterfs/+git/glusterfs/+merge/450481
From 8c8e652c73958c2c62c3a80d0814a0e04e0d3096 Mon Sep 17 00:00:00 2001
From: Andreas Hasenack 
Date: Fri, 1 Sep 2023 10:19:57 -0300
Subject: [PATCH 2/2]   * d/t/control, d/t/smoke: add simple superficial smoke
 test

---
 debian/tests/control |  4 
 debian/tests/smoke   | 12 
 2 files changed, 16 insertions(+)
 create mode 100644 debian/tests/smoke

diff --git a/debian/tests/control b/debian/tests/control
index ad3ea8a582..47ad57c3af 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,7 @@
+Tests: smoke
+Restrictions: needs-root, superficial, isolation-container
+Depends: @
+
 Tests: create-volume
 Restrictions: allow-stderr, isolation-machine, breaks-testbed, needs-root
 Depends: @, xfsprogs
diff --git a/debian/tests/smoke b/debian/tests/smoke
new file mode 100644
index 00..1298bc0f02
--- /dev/null
+++ b/debian/tests/smoke
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+set -e
+
+systemctl start glusterd.service
+systemctl status glusterd.service
+
+gluster peer status
+gluster pool list
+gluster get-state glusterd
+cat /var/run/gluster/glusterd_state_*
+
-- 
2.39.2

From 6931add9aa5a689a2bd4c312cdf04235e572c99c Mon Sep 17 00:00:00 2001
From: Andreas Hasenack 
Date: Fri, 18 Aug 2023 17:16:34 -0300
Subject: [PATCH 1/2]   * d/p/09-fix-startup-crash.diff: fix glibc assertion
 error on startup of glusterd (LP: #2031905)

---
 debian/patches/09-fix-startup-crash.diff | 27 
 debian/patches/series|  1 +
 2 files changed, 28 insertions(+)
 create mode 100644 debian/patches/09-fix-startup-crash.diff

diff --git a/debian/patches/09-fix-startup-crash.diff b/debian/patches/09-fix-startup-crash.diff
new file mode 100644
index 00..0a22f1b501
--- /dev/null
+++ b/debian/patches/09-fix-startup-crash.diff
@@ -0,0 +1,27 @@
+commit f68929b872edd7ad7f4512a77df1c5a7787ed3c2 (upstream/release-11, release-11)
+Author: Niraj Kumar Yadav 
+Date:   Fri Jul 7 14:02:38 2023 +0530
+
+Revert structure of per_thread_pool_list_t (#4196)
+
+Signed-off-by: black-dragon74 
+
+Origin: upstream, https://github.com/gluster/glusterfs/commit/f68929b872edd7ad7f4512a77df1c5a7787ed3c2
+Bug: https://github.com/gluster/glusterfs/issues/4192
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/2031905
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050021
+Last-Update: 2023-09-01
+
+diff --git a/libglusterfs/src/glusterfs/mem-pool.h b/libglusterfs/src/glusterfs/mem-pool.h
+index 46f764f56e..416b7ddf1e 100644
+--- a/libglusterfs/src/glusterfs/mem-pool.h
 b/libglusterfs/src/glusterfs/mem-pool.h
+@@ -297,7 +297,7 @@ typedef struct per_thread_pool_list {
+  * in the implementation code so we just make it a single-element array
+  * here.
+  */
+-per_thread_pool_t pools[];
++per_thread_pool_t pools[1];
+ } per_thread_pool_list_t;
+ 
+ /* actual pool structure, shared between different mem_pools */
diff --git a/debian/patches/series b/debian/patches/series
index ed7b3ef9fe..f71dcc2a4c 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@
 04-systemd-extra-services.diff
 05-remove-hashbang.diff
 08-bash-term-in-posix-shell.diff
+09-fix-startup-crash.diff
-- 
2.39.2

Bug#1051192: solid-auth, liblog-any-perl: solid-auth became uninstallable after liblog-any-perl dropped liblog-any-adapter-perl Provides

[gregor herrmann]

On Mon, 04 Sep 2023 19:02:41 +0200, Axel Beckert wrote:

> > > → grep-aptavail -FDepends -P liblog-any-adapter-perl | fgrep 
> > > liblog-any-adapter-perl
> > Nice, I always forget the syntax.
> Didn't get it right on the first try, either. :-)

Heh :)
 
> > > Should we do this in solid-auth, too, or just use solely
> > > liblog-any-perl?
> > I'd go for only liblog-any-perl everywhere as is gone …
> The longer I think about the more I tend towards that direction, too.

Coolio
 
> Anyway, thanks for your efforts and sorry that I currently can't help
> that much with the actual work. (Lagging behind with fixing RC bugs in
> my non-team packages, too…)

No worries, thanks for reporting and helping me with grep-aptavail
and thinking about the issue!


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1042005: Info received (Bug#1042005: transition: mumps hypre2.28.0 superlu combblas)

[Graham Inggs]

Hi

On Thu, 31 Aug 2023 at 12:03, Sebastian Ramacher  wrote:
> Unfortunately trilinos is a key package and so cannot be removed without
> much effort from testing to complete the transition. Can you please take
> a look at fixing the current issues with trilinos?

As can be seen on salsa [1], packaging of trilinos 14.4.0-1 is
underway, although it is taking a bit longer than expected.

In the meantime, I've uploaded trilinos 13.2.0-5 to unstable, which
should fix the build with GCC-13.

Regards
Graham


[1] https://salsa.debian.org/science-team/trilinos

Bug#1041508: tex-common: fmutil fails to rebuild formats

[Paul Gevers]

Hi,

On 04-09-2023 00:21, Preuße, Hilmar wrote:

I've just added an ignore hint for texlive-extra, as the
r-bioc-biocstyle issue is clearly less of a problem than this one (and
bug reports are filed).


Thanks for your response! When will the ignore hint be effective?


Immediately, but I had to decron britney2 because of issues with the 
BTS. That's now fixed, so I enabled britney2 just now and the first 
migration should happen at the 22:00 UTC run.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051003: libgdbm6: trap divide error in libgdbm.so.6.0.0

[Nicolas Mora]

Hello Christopher,

Le 2023-09-04 à 04 h 09, Christopher Voglstätter a écrit :


PAM-shield uses a database file that I migrated from debian 10 to debian 
12 in one big double upgrade.
For testing purposes I deleted that database file, created an empty file 
instead and the trap divide error disappeared. PAM-shield works fine 
again as well and has been for three days now.


So... problem solved for my case.

It's a good and a bad news at the same time. A good news because you 
found a working workaround, and a bad news because since a database 
reset works, it should mean a problem in gdbm itself during some kind of 
upgrades.


Is this problem still relevant for libgdbm as we have a trap divide 
error that should not happen no matter what? Or should I open a ticket 
at libpam-shield so the problem (and the solution) is documented - even 
if the package is orphaned?




I don't know if we can go further with this, but did you keep the old 
database file? So one could try to reproduce the problem, and if so, 
forward it upstream.


/Nicolas

Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Simon McVittie]

On Mon, 04 Sep 2023 at 18:56:52 +0200, Michael Stapelberg wrote:
> > i3 isn’t a desktop environment, it’s a window manager only.
> 
> It's behaving like a (very small) desktop environment to the extent that
> it installs a file in /usr/share/xsessions, which results in it appearing
> in the menu of possible session types in display managers like gdm,
> lightdm or sddm.
> 
> Are you saying only desktop environments may install to the xsessions
> directory?
> 
> If so, what is the mechanism for window managers to show up in the display
> manager menu?

It depends where you draw the line between window manager and desktop
environment. Where I would personally draw that line is:

If it makes sense to log in to a thing as a desktop session in its own
right, which has some way to run programs in order to be independently
useful, and preferably some way to exit, then it makes sense to register
it in xsessions, and it's effectively behaving like a tiny desktop
environment. For instance, openbox and icewm are definitely this: each
has a menu that can launch apps and exit. You could call this a desktop
environment, or if you think that term has other connotations which
don't apply here, you could call it something else, but it's certainly
something that is useful to list as an option in e.g. lightdm.

If it doesn't make sense to log in to a thing because it isn't useful on
its own, then I don't think it should be registered in xsessions or show
up in the display manager menu. For instance, the /usr/bin/mutter in the
mutter package is a window manager, but it intentionally isn't registered
as an xsession, because it isn't useful on its own: it will manage the
windows of any programs you run some other way, but it doesn't have any
built-in way to start any programs, so you need to add at least a way to
run programs (some sort of menu or panel or hotkey mechanism, which it
doesn't have built-in) to make a directly useful user-facing environment.

I don't know which of those i3 wants to be.

> When we stop patching xdg-desktop-portal to hard-code its GTK backend
> as a fallback, the default will be to use no portal backends at all,
> which means the apps I described above will try and fail to make use of
> those desktop features, unless the user has written a portals.conf(5)
> of their own (which they can always do anyway, and it will overrule the
> desktop environment's choices).
> 
> Uhm, why would we actively remove the fallback?
> I don’t understand the logic behind that.
> It seems like a decision that will leave users worse off, for no benefit?

The -gtk backend was never really intended to be a fallback: it was
originally GNOME-specific, and only got used in other environments
as a last resort because of implementation details of how the portal
backend is selected. The upstream design of x-d-p was always intended
to be that each GUI environment would provide its own choice of backend
(either its own, or shared with other GUI environments) that implements
the various interfaces in a desktop-appropriate way.

I suggested in an upstream issue[1] that maybe x-d-p-gtk should be
hard-coded as the portal backend of last resort (as I've done downstream
in Debian for now), but upstream developers didn't think that was
appropriate, and the user who originally opened the issue thought that
an unconfigured x-d-p specifically *shouldn't* start any backends,
so your opinion on this is noted but is not universally shared.

[1] https://github.com/flatpak/xdg-desktop-portal/issues/1077

We have had some quite bad bugs in the past caused by portal backends
being run outside their intended environment, failing to find the
desktop-specific services that they need (for example for screen sharing
and screencasting under Wayland, which are very implementation-specific),
and causing crashes or arbitrary delays, so it's important to avoid
x-d-p's old behaviour where it would arbitrarily pick *any* backend
if there is none that declares that it supports the current desktop
environment. I don't *think* x-d-p-gtk has any such interfaces, but I'm
not in a position to routinely test it on every GUI environment offered
by Debian.

One option that I've thought about is providing a
xdg-desktop-portal-fallback-is-gtk package, containing a
non-desktop-specific /usr/share/xdg-desktop-portal/portals.conf and
depending on x-d-p-gtk, and making that the default alternative for the
x-d-p-backend virtual package, so that Flatpak, Snap, Chromium, etc.
will pull it in as a dependency if no installed desktop environment
already depended on something more appropriate.

The major down side of that is that it would suppress the fallback
code path that uses the deprecated UseIn mechanism, resulting in the
wrong backend being chosen in environments that *do* have a preferred
backend (KDE Plasma, wlroots-based environments, Cinnamon/MATE/XFCE)
if they have not already added their own ${desktop}-portals.conf, so
we 

Bug#1051213: RFS: debianutils/5.12 [ITA] -- Miscellaneous utilities specific to Debian

[Niels Thykier]

Control: owner -1 !

Ileana Dumitrescu:

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

[..]

Niels Thykier and I will be co-maintaining this package.



I got this. :)

Best regards,
Niels

Bug#1050806: O: debianutils -- Essential utilities specific to Debian

[Niels Thykier]

Ileana Dumitrescu:

Hi Niels,

@Ileana: Would you be fine with co-maintaining it with me? We can use 
the existing git repo (https://salsa.debian.org/debian/debianutils) as 
packaging repo and coordinate our changes via that.


That sounds good!

I have submitted a new version of debianutils to mentors to close the 
ITA along with some other updates [1]. Can you give me the necessary 
permissions for the salsa repo and future uploads?


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

Best,



Hi Ileana

Thanks for preparing the changes.

I have sent you an invite for the salsa repo. Please accept and push 
your changes if you have them as individual changes. :) Otherwise, I can 
do an import of the source package (based on `gbp import-dsc`) as an 
alternative.


I will upload once you pushed the git changes or reported back to me 
that I should use import-dsc. :)




Best regards,
Niels

Bug#1051226: python-django: CVE-2023-41164

[Chris Lamb]

Package: python-django
Version: 1:1.11.29-1+deb10u9
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for python-django.

CVE-2023-41164[0]:

  Potential denial of service vulnerability in
  django.utils.encoding.uri_to_iri(); this was subject to potential
  denial of service attack via certain inputs with a very large number
  of Unicode characters.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-41164
https://www.cve.org/CVERecord?id=CVE-2023-41164


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#845463: ITP: conan -- dependency manager for C/C++/golang

[devel]

Hello,


On Wed, 6 Oct 2021 18:00:22 +0200 Bastian Germann  wrote:
> Control: block -1 by 845482
> 
> On Thu, 14 Nov 2019 09:53:16 +0100 Helmut Grohne  
> wrote:
> 
> >  * conan requires patch-ng==1.17.1, but I couldn't find it in unstable.
> >This is a fork of https://github.com/techtonik/python-patch done by
> >conan people. Neither is packaged for Debian. Thankfully, they
> >renamed the Python module from "patch" to "patch_ng". Given that it
> >is forked by conan, vendoring could be considered.
> 
> There is work being done to have patch-ng in Debian.

meanwhile python3-patch-ng has arrived:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845482#57

Maybe this is still relevant for the packaging of conan?

Cheers,
Lars

Bug#1051192: solid-auth, liblog-any-perl: solid-auth became uninstallable after liblog-any-perl dropped liblog-any-adapter-perl Provides

[Axel Beckert]

Hi gregor,

gregor herrmann wrote:
> > > I noticed that liblog-any-adapter-perl was removed in 2015, and, more
> > > importantly, I checked with `apt-cache rdepends
> > > liblog-any-adapter-perl' which, unless I was blind, didn't show
> > > anything.
> > I can confirm that — looks like a bug around virtual packages:
> 
> Thanks for double-checking!

You're welcome.

> > → grep-aptavail -FDepends -P liblog-any-adapter-perl | fgrep 
> > liblog-any-adapter-perl
> 
> Nice, I always forget the syntax.

Didn't get it right on the first try, either. :-)

> With different output:
> 
> % grep-aptavail -FDepends -P liblog-any-adapter-perl -s Source,Package,Depends

I had -S in my mind, but that's the opposite of -P and hence got weird
results. :-)

> > Should we do this in solid-auth, too, or just use solely
> > liblog-any-perl?
> 
> I'd go for only liblog-any-perl everywhere as is gone …

The longer I think about the more I tend towards that direction, too.

gregor herrmann wrote:
> These 4 are fixed in git to only use liblog-any-perl (but not
> uploaded as there is no practical problem).
[…]
> Done for src:libweb-solid-auth-perl, and uploaded.

Perfect. Thanks a lot!

> Hm, and I found more in git:
> 
> % grep liblog-any-adapter-perl */debian/control
> liblog-any-adapter-screen-perl/debian/control: liblog-any-perl | 
> liblog-any-adapter-perl ,
> liblog-any-adapter-screen-perl/debian/control: liblog-any-perl | 
> liblog-any-adapter-perl,
> librdf-linkeddata-perl/debian/control: liblog-any-adapter-perl,
> librdf-linkeddata-perl/debian/control: liblog-any-adapter-perl,
> 
> Not found by grep-aptavail? Next weirdness …

I think I managed to solve that mystery:

> Oh, look, the latter has fresh autopkgtest failures on ci.d.n.

O.o

I think something went wrong here as the commit message doesn't fit at
all with the changes:
https://salsa.debian.org/perl-team/modules/packages/librdf-linkeddata-perl/-/commit/6955989b1474f72cb75c33aa3f0cde418c82ff68

Then again, that was 6 years ago.

Ah, that were solely build-dependencies, not run-time dependencies. At
least that mystery is solved. :-)

Anyway, thanks for your efforts and sorry that I currently can't help
that much with the actual work. (Lagging behind with fixing RC bugs in
my non-team packages, too…)

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

Bug#1051225: libmypaint: update d/watch file

[Patrice Duroux]

Source: libmypaint
Version: 1.6.0-2
Severity: minor

Dear Maintainer,

Here is a suggested patch to.

Regards,
Patrice


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

Kernel: Linux 6.4.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/watch b/debian/watch
index ffd65e1..599379d 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,5 @@
+# Note: @ANY_VERSION@ is not used in matching-pattern to avoid 
2.0.0-(beta|alpha) series that are older
 version=4
-https://github.com/mypaint/libmypaint/releases \
-   .*/libmypaint-([0-9.]+).tar.xz
+opts="filenamemangle=s%(?:.*?)?v?@ANY_VERSION@(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%" 
\
+   https://github.com/mypaint/@PACKAGE@/tags \
+   (?:.*?/)v?(\d[\.\d]*)@ARCHIVE_EXT@

Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Michael Stapelberg]

Thanks for your explanations. Answers inline:

On Sun, 3 Sept 2023 at 22:55, Simon McVittie  wrote:

> On Sun, 03 Sep 2023 at 20:25:52 +0200, Michael Stapelberg wrote:
> > If I'm reading its code correctly, I think i3-wm asks the display
> manager
> > to set XDG_CURRENT_DESKTOP to "i3"?
> >
> > I don’t know what code you’re referring to.
> > I don’t recall i3 asking any display manager anything, but maybe I’m
> missing
> > something?
>
> i3-wm_4.22-2/share/xsessions/i3.desktop contains DesktopNames=i3, which is
> how you ask a display manager to set XDG_CURRENT_DESKTOP=i3 when running
> the command defined in i3.desktop as an X11 session.
>

Ah, understood. Apparently, this line was needed for gdm, at least per the
2016 changelog entry.


>
> > i3 isn’t a desktop environment, it’s a window manager only.
>
> It's behaving like a (very small) desktop environment to the extent that
> it installs a file in /usr/share/xsessions, which results in it appearing
> in the menu of possible session types in display managers like gdm,
> lightdm or sddm.
>

Are you saying only desktop environments may install to the xsessions
directory?

If so, what is the mechanism for window managers to show up in the display
manager menu?


>
> > I’m also not familiar with what these xdg portals are, and I don’t think
> I’m
> > using them (yet)?
>
> I don't expect that i3 uses them, but some of the applications that users
> run within an i3 session are going to be using them.
>
> The most prominent use is that sandboxed Flatpak and Snap apps make D-Bus
> calls to xdg-desktop-portal to get things like File -> Open and File ->
> Save As dialogs, ask to open URLs or files outside the sandbox, pop up
> notifications, take screenshots and other outside-sandbox actions.
> xdg-desktop-portal implements all those things by passing on the request
> to a backend such as xdg-desktop-portal-gtk, which can be desktop-specific.
>
> Non-sandboxed apps are starting to use the same portal mechanism to do
> things that are otherwise hard to do in a desktop-independent way, like
> screenshots, screen-sharing and remote-desktop.
>
> > I don’t want to make the choice of whether gtk or qt should be used for
> parts
> > of a user’s desktop.
> ...
> > I think for the case of i3, the defaults should be fine, so I would
> prefer not
> > to add this config file.
>
> When we stop patching xdg-desktop-portal to hard-code its GTK backend
> as a fallback, the default will be to use no portal backends at all,
> which means the apps I described above will try and fail to make use of
> those desktop features, unless the user has written a portals.conf(5)
> of their own (which they can always do anyway, and it will overrule the
> desktop environment's choices).
>

Uhm, why would we actively remove the fallback?
I don’t understand the logic behind that.
It seems like a decision that will leave users worse off, for no benefit?


>
> I'm aware that i3 is quite an "assemble it yourself" environment, so
> perhaps users of i3 would expect to have to write their own configuration
> to make things like this work? If that's the case then this could be
> closed as "won't fix".


I would interpret the lack of a config file as “just make a reasonable
choice for me”,
so I would say users expect portals to work, in some unspecified way.

I would certainly be surprised if portals just didn’t work,
when they could just fall back to the gtk implementation.

-- 
Best regards,
Michael

Bug#1051192: solid-auth, liblog-any-perl: solid-auth became uninstallable after liblog-any-perl dropped liblog-any-adapter-perl Provides

[gregor herrmann]

On Mon, 04 Sep 2023 16:54:35 +0200, gregor herrmann wrote:

> With different output:
> 
> % grep-aptavail -FDepends -P liblog-any-adapter-perl -s 
> Source,Package,Depends 
> Package: libdata-hal-perl
> Depends: perl:any, libboolean-perl, libclone-perl, libdata-visitor-perl, 
> libfailures-perl, libhttp-message-perl, libjson-perl, liblog-any-perl | 
> liblog-any-adapter-perl, libmime-types-perl, libmoo-perl, libsafe-isa-perl, 
> libstrictures-perl, libtype-tiny-perl, liburi-namespacemap-perl, liburi-perl, 
> liburi-template-perl, libxml-regexp-perl
> 
> Package: liblog-any-adapter-callback-perl
> Depends: perl:any, liblog-any-perl | liblog-any-adapter-perl
> 
> Package: liblog-any-adapter-dispatch-perl
> Depends: perl:any, liblog-any-perl | liblog-any-adapter-perl, 
> liblog-dispatch-perl
> 
> Package: liblog-any-adapter-filehandle-perl
> Depends: perl:any, liblog-any-perl | liblog-any-adapter-perl

These 4 are fixed in git to only use liblog-any-perl (but not
uploaded as there is no practical problem).
 
> Source: libweb-solid-auth-perl
> Package: solid-auth
> Depends: libfile-libmagic-perl, libjson-perl, 
> liblog-any-adapter-log4perl-perl, liblog-any-adapter-perl, 
> liblog-log4perl-perl, libpath-tiny-perl, libstring-escape-perl, 
> libweb-solid-auth-perl, perl:any

> > Should we do this in solid-auth, too, or just use solely
> > liblog-any-perl?
> I'd go for only liblog-any-perl everywhere as is gone …

Done for src:libweb-solid-auth-perl, and uploaded.


Hm, and I found more in git:

% grep liblog-any-adapter-perl */debian/control
liblog-any-adapter-screen-perl/debian/control: liblog-any-perl | 
liblog-any-adapter-perl ,
liblog-any-adapter-screen-perl/debian/control: liblog-any-perl | 
liblog-any-adapter-perl,
librdf-linkeddata-perl/debian/control: liblog-any-adapter-perl,
librdf-linkeddata-perl/debian/control: liblog-any-adapter-perl,

Not found by grep-aptavail? Next weirdness …

Oh, look, the latter has fresh autopkgtest failures on ci.d.n.

Alright, liblog-any-adapter-screen-perl fixed in git, librdf-linkeddata-perl
fixed and uploaded.


Cheers,
gregor, wo notes that removing ancient Provides is a bit hard

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1051206: auto-apt-proxy: Optional support for mDNS

[Antonio Terceiro]

On Mon, Sep 04, 2023 at 11:42:35PM +1000, James Tocknell wrote:
> Package: auto-apt-proxy
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Would you be open to adding optional support (i.e. at the suggests level) for
> mDNS via avahi-browse (or similar mDNS scanning command)? I'd be happy to
> produce a patch if interested.

Sure.


signature.asc
Description: PGP signature

Bug#1051224: buildd.debian.org: Add osm2pgsql to Packages-arch-specific

[Bas Couwenberg]

Package: buildd.debian.org
Severity: normal
Tags: patch

Dear Maintainer,

osm2pgsql upstream no longer supports 32bit architectures, no need to even try 
to build the package there.

Kind Regards,

Bas
>From a49a0961ea98027b486169567f21d6e63f32206e Mon Sep 17 00:00:00 2001
From: Bas Couwenberg 
Date: Mon, 4 Sep 2023 18:37:10 +0200
Subject: Exclude osm2pgsql from 32bit achitectures.

---
 Packages-arch-specific | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Packages-arch-specific b/Packages-arch-specific
index aa69ebe..539bea5 100644
--- a/Packages-arch-specific
+++ b/Packages-arch-specific
@@ -23,6 +23,7 @@
 fdflush: alpha amd64 i386 # 
amd64/i386/alpha specific
 %libgcr410: i386 amd64   # [ANAIS]
 %linux-wlan-ng: amd64 i386 powerpc armel armhf alpha hppa# ANAIS 
[?]
+%osm2pgsql: !armel !armhf !i386 !arc !hppa !hurd-i386 !m68k !powerpc !sh4 !x32 
 # 64bit only
 
 # xorg stuff
 %xf86-input-multitouch: !s390x
-- 
2.39.2

Bug#1051223: rpm: add RPM_FORCE_DEBIAN= env var as alternative to --force-debian

[Luca Boccassi]

Package: rpm
Tags: patch

Command line parameters cannot be passed to dnf, so add support for an
env var to bypass the warning on package install.

In mkosi we use the local dnf package to bootstrap new chroots, which
uses the local rpm package, and shows this warning on every package
being installed, despite the fact that it is perfectly safe to do so
as it is not installing on the host, but in the chroot.

MR on Salsa:

https://salsa.debian.org/pkg-rpm-team/rpm/-/merge_requests/5

-- 
Kind regards,
Luca Boccassi


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

Bug#1051222: mariadb FTCBFS: passes host CFLAGS to the native build

[Helmut Grohne]

Source: mariadb
Version: 1:10.11.4-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mariadb started failing to cross build from source with a recent dpkg
upload. In that upload, the default CFLAGS for arm64 gained a value that
is incompatible with any other architecture. Passing the arm64 CFLAGS to
any other compiler makes things fail. This is what is happening now. In
the native build pass I foolishly forgot to ask debhelper to recompute
the build flags and as a result it passes the host flags to the native
build. The solution is fairly simple and attached. Hope it helps.

Helmut
diff --minimal -Nru mariadb-10.11.4/debian/changelog 
mariadb-10.11.4/debian/changelog
--- mariadb-10.11.4/debian/changelog2023-06-04 20:22:27.0 +0200
+++ mariadb-10.11.4/debian/changelog2023-09-04 08:36:45.0 +0200
@@ -1,3 +1,10 @@
+mariadb (1:10.11.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Do not pass host CFLAGS to the native build. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 04 Sep 2023 08:36:45 +0200
+
 mariadb (1:10.11.4-1) unstable; urgency=medium
 
   [ Otto Kekäläinen ]
diff --minimal -Nru mariadb-10.11.4/debian/rules mariadb-10.11.4/debian/rules
--- mariadb-10.11.4/debian/rules2023-06-04 20:22:27.0 +0200
+++ mariadb-10.11.4/debian/rules2023-09-04 08:36:43.0 +0200
@@ -107,7 +107,7 @@
dh_testdir
 
 ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
-   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_configure 
--builddirectory=builddir-native
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_configure 
--builddirectory=builddir-native --reload-all-buildenv-variables
dh_auto_build --builddirectory=builddir-native -- import_executables
 endif
 

Bug#1051221: pyimagetool: The GUI does not start, and produces a python error 'Qt' has no attribute 'DashLine'

[Emmanuel FARHI]

Source: pyimagetool
Version: GUI fails with error 'Qt' has no attribute 'DashLine'
Severity: important
X-Debbugs-Cc: emmanuel.fa...@synchrotron-soleil.fr

Dear Maintainer,

   * What led up to the situation?

The GUI does not start with command 'python3 -m pyimagetool'. An initial error
is produced:
>> OSError: Packaged data files are not writeable

$ python3 -m pyimagetool
Traceback (most recent call last):
  File "", line 189, in _run_module_as_main
  File "", line 148, in _get_module_details
  File "", line 112, in _get_module_details
  File "/usr/lib/python3/dist-packages/pyimagetool/__init__.py", line 2, in

from .ImageTool import ImageTool
  File "/usr/lib/python3/dist-packages/pyimagetool/ImageTool.py", line 8, in

from .widgets import InfoBar
  File "/usr/lib/python3/dist-packages/pyimagetool/widgets.py", line 6, in

from .cmaps import CMap
  File "/usr/lib/python3/dist-packages/pyimagetool/cmaps/__init__.py", line 1,
in 
from .CMap import CMap
  File "/usr/lib/python3/dist-packages/pyimagetool/cmaps/CMap.py", line 66, in

raise OSError(
OSError: Packaged data files are not writeable, use a helper script.See
/usr/share/pyimagetool/debian_pyimagetool.py

which we also get from ipython3:

$ ipython3
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import pyimagetool
---
OSError   Traceback (most recent call last)
Cell In [1], line 1
> 1 import pyimagetool

File /usr/lib/python3/dist-packages/pyimagetool/__init__.py:2
  1 from .DataMatrix import RegularDataArray
> 2 from .ImageTool import ImageTool
  3 from .PGImageTool import PGImageTool
  5 __all__ = ['ImageTool', 'RegularDataArray']

File /usr/lib/python3/dist-packages/pyimagetool/ImageTool.py:8
  5 import numpy as np
  6 import warnings
> 8 from .widgets import InfoBar
  9 from .PGImageTool import PGImageTool
 10 from .DataMatrix import RegularDataArray

File /usr/lib/python3/dist-packages/pyimagetool/widgets.py:6
  3 from functools import partial
  5 from .DataMatrix import RegularDataArray
> 6 from .cmaps import CMap
  9 class InfoBar(QtWidgets.QWidget):
 10 """Based on the input data, create a suitable info bar (maybe with
tabs?)"""

File /usr/lib/python3/dist-packages/pyimagetool/cmaps/__init__.py:1
> 1 from .CMap import CMap

File /usr/lib/python3/dist-packages/pyimagetool/cmaps/CMap.py:66
 64 modulepath = Path(xdg.xdg_cache_home(), "PyImageTool")
 65 if not os.access(str(modulepath), os.W_OK):
---> 66 raise OSError(
 67 "Packaged data files are not writeable, use a helper script."
 68 "See /usr/share/pyimagetool/debian_pyimagetool.py"
 69 )
 72 class CMap:
 73 _instance = None

OSError: Packaged data files are not writeable, use a helper script.See
/usr/share/pyimagetool/debian_pyimagetool.py


It is possible to allow the package to write in the area area, but an other
error then comes in:

File /usr/lib/python3/dist-packages/pyimagetool/PGImageTool.py:24, in
PGImageTool()
 22 index_to_coord: List[str] = ['x', 'y', 'z', 't']
 23 frame_rate = 60
---> 24 bin_pen = pg.mkPen(style=pg.Qt.QtCore.Qt.DashLine)
 26 mouse_hover = QtCore.Signal(str)  # event fired when the mouse moves on
an image
 28 def __init__(self, data: RegularDataArray, parent=None, layout=0):

AttributeError: type object 'Qt' has no attribute 'DashLine'

   * What outcome did you expect instead?

The GUI, or a python Notebook should be usable, but this is not the case.

Considering that the code has not changed for 3 years, and that the
corresponding issue was sent https://github.com/kgord831/PyImageTool/issues/5
but had no answer, we recommend to drop this package.


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

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

Bug#1051220: libgtk-3-0: inkscape segfaults when exporting files from the command line

[Martin Quinson]

Package: libgtk-3-0
Version: 3.24.38-4
Severity: normal
Tags: patch upstream

Dear maintainers,

when running `inkscape img/cache.svg --export-filename=img/cache.pdf` with the
attached svg file, I get a segfault message indicating that I should report the
bug. But actually, my bug was most probably already reported and fixed
upstream, it's here: https://gitlab.com/inkscape/inkscape/-/issues/4177

The fix does happen to be in inkscape itself but in gtk. The patch is not part
of any release yet (it should be part of 3.39 when it comes out), so the best
solution would be to backport this patch in the Debian package for the time
being.

Could you please include that patch to be part of the next package?

Thanks in advance,
Martin

---
PS: for the record, here are the system information of my inkscape install.
Libgtk information follows

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

Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN,
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 inkscape depends on:
ii  lib2geom1.2.0  1.2.2-3
ii  libatkmm-1.6-1v5   2.28.3-1
ii  libboost-filesystem1.74.0  1.74.0+ds1-22
ii  libc6  2.37-7
ii  libcairo-gobject2  1.16.0-7
ii  libcairo2  1.16.0-7
ii  libcairomm-1.0-1v5 1.14.4-2
ii  libcdr-0.1-1   0.1.7-1
ii  libfontconfig1 2.14.2-4
ii  libfreetype6   2.13.2+dfsg-1
ii  libgc1 1:8.2.4-1
ii  libgcc-s1  13.2.0-2
ii  libgdk-pixbuf-2.0-0    2.42.10+dfsg-1+b1
ii  libglib2.0-0   2.77.2-1
ii  libglibmm-2.4-1v5  2.66.6-2
ii  libgomp1   13.2.0-2
ii  libgsl27   2.7.1+dfsg-5
ii  libgspell-1-2  1.12.2-1
ii  libgtk-3-0 3.24.38-4
ii  libgtkmm-3.0-1v5   3.24.8-2
ii  libharfbuzz0b  8.0.1-1
ii  libjpeg62-turbo    1:2.1.5-2
ii  liblcms2-2 2.14-2
ii  libmagick++-6.q16-8    8:6.9.11.60+dfsg-1.6
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpangocairo-1.0-0    1.51.0+ds-2
ii  libpangoft2-1.0-0  1.51.0+ds-2
ii  libpangomm-1.4-1v5 2.46.3-1
ii  libpng16-16    1.6.40-1
ii  libpoppler-glib8   22.12.0-2+b1
ii  libpoppler126  22.12.0-2+b1
ii  libpotrace0    1.16-2
ii  libreadline8   8.2-1.3
ii  librevenge-0.0-0   0.0.5-3
ii  librsvg2-common    2.54.7+dfsg-2
ii  libsigc++-2.0-0v5  2.12.0-1
ii  libsoup2.4-1   2.74.3-1
ii  libstdc++6 13.2.0-2
ii  libvisio-0.1-1 0.1.7-1+b3
ii  libwpg-0.3-3   0.3.4-3
ii  libx11-6   2:1.8.6-1
ii  libxml2    2.9.14+dfsg-1.3
ii  libxslt1.1 1.1.35-1
ii  python3    3.11.4-5+b1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages inkscape recommends:
ii  aspell   0.60.8-6
ii  fig2dev  1:3.2.9-1
ii  imagemagick  8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6
ii  libimage-magick-perl 8:6.9.11.60+dfsg-1.6
ii  libwmf-bin   0.2.13-1
ii  python3-cssselect    1.2.0-2
ii  python3-lxml 4.9.3-1
ii  python3-numpy    1:1.24.2-1
ii  python3-scour    0.38.2-3

Versions of packages inkscape suggests:
pn  dia   
pn  inkscape-tutorials    
pn  libsvg-perl   
pn  pstoedit  
ii  python3-packaging 23.1-1
pn  python3-uniconvertor  
ii  ruby  1:3.1

-- no debconf information
---


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

Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN,
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 libgtk-3-0 depends on:
ii  adwaita-icon-theme   43-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.49.90-5
ii  libatk1.0-0  2.49.90-5
ii  libc6    2.37-7
ii  libcairo-gobject2    1.16.0-7
ii  libcairo2    1.16.0-7
ii  

Bug#1051219: O: gumbo-parser -- pure-C HTML5 parser

[Bastian Germann]

Package: wnpp

I am orphaning gumbo-parser. I do not have the time to maintain it properly, e.g. import another 
upstream: #950878. Please consider adopting if you have the time and skills to maintain it.


Description: pure-C HTML5 parser
 Gumbo is an implementation of the HTML5 parsing algorithm implemented
 as a pure C99 library with no outside dependencies.  It's designed to serve
 as a building block for other tools and libraries such as linters,
 validators, templating languages, and refactoring and analysis tools.

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

[Steven Robbins]

On Sunday, August 27, 2023 12:43:31 P.M. CDT Karine Crèvecœur wrote:


>   (gdb) disassemble
>…
>0x76cc20e8 <+136>:   movaps %xmm8,%xmm4
>0x76cc20ec <+140>:   mov%edx,-0x4c(%rsp)
>0x76cc20f0 <+144>:   mov0x38(%r9),%rdx
>0x76cc20f4 <+148>:   mulss  %xmm5,%xmm4
>0x76cc20f8 <+152>:   movss  0x3c(%r9),%xmm10
>0x76cc20fe <+158>:   movq   %r10,%xmm7
> => 0x76cc2103 <+163>:   extractps $0x3,%xmm12,%r11d
>0x76cc210a <+170>:   mov%rdx,%r15
>0x76cc210d <+173>:   mov0x28(%rax),%rdx
>0x76cc2111 <+177>:   movshdup %xmm7,%xmm7
>0x76cc2115 <+181>:   extractps $0x2,%xmm12,%edi
>0x76cc211c <+188>:   mulss  %xmm6,%xmm2
>0x76cc2120 <+192>:   movq   %rdx,%xmm15
>0x76cc2125 <+197>:   mov%rdx,-0x40(%rsp)
>…
> 
> The instruction that leads to crash seems to be "extractps".According
> to  it is an instruction
> related to SSE4.1.

Thank you!  That is exactly what I needed to know.  

So it is clear that some folks need a build with SSE4 disabled.  But SSE2 is 
supported on the machines of you and the original reporter so I'll try first 
with SSE2 but not SSE4.

The remaining issue is: I need to figure a way to build two binary packages 
from the source.  The other alternative is to disable SSE4 for everyone but I 
have no idea what performance impact that might have.

Regards,
-Steve


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

Bug#1051218: lastpass-cli: Please update to 1.3.6 upstream to fix version

[Bela Ormos]

Package: lastpass-cli
Version: 1.3.5

The tool reports a different version, so that can mislead users of the version 
of the tool and makes it harder to debug problems.

Bug#1051217: python3-xrt: xrt GUI fails to start with error module 'inspect' has no attribute 'getargspec'.

[Emmanuel FARHI]

Package: python3-xrt
Version: 1.4.0-2
Severity: important
X-Debbugs-Cc: emmanuel.fa...@synchrotron-soleil.fr

Dear Maintainer,

   * What led up to the situation?

The command '/usr/bin/xrtQookStart' or Desktop launcher "XRay Tracer" fails to
start GUI.

   * What was the outcome of this action?

An error message is displayed in the Terminal:
>> AttributeError: module 'inspect' has no attribute 'getargspec'. Did you
mean: 'getargs'?

$ /usr/bin/xrtQookStart
Traceback (most recent call last):
  File "/usr/bin/xrtQookStart", line 30, in 
ex = xQ.XrtQook()
 
  File "/usr/lib/python3/dist-packages/xrt/gui/xrtQook/__init__.py", line 245,
in __init__
self.initAllTrees()
  File "/usr/lib/python3/dist-packages/xrt/gui/xrtQook/__init__.py", line 637,
in initAllTrees
if inspect.getargspec(obj)[3] is not None:
   ^^
AttributeError: module 'inspect' has no attribute 'getargspec'. Did you mean:
'getargs'?

   * What outcome did you expect instead?

The GUI should start.

   * Potential fix

It seems inspect.getargspec is now deprecated in python 3.11. It should be
replaced by inspect.getfullargspec(func)
The upstream code has been fixed, so that a version upgrade to 1.6.0 should fix
the bug.


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

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

Versions of packages python3-xrt depends on:
ii  libjs-mathjax   2.7.9+dfsg-1
ii  python3 3.11.2-1+b1
ii  python3-matplotlib  3.6.3-1+b1
ii  python3-numpy   1:1.24.2-1
ii  python3-opengl  3.1.6+dfsg-3
ii  python3-pandas  1.5.3+dfsg-2
ii  python3-scipy   1.10.1-2
ii  python3-sphinx  5.3.0-4
ii  python3-spyder  5.4.2+ds-5
ii  python3-xdg 0.28-2

python3-xrt recommends no packages.

Versions of packages python3-xrt suggests:
ii  python3-pyopencl  2022.3.1-2.1

-- no debconf information

Bug#1009303: Info received (MR)

[Martin Dosch]

Dear maintainer,

I forgot to mention: If you are too busy to prepare an update right now, 
I might also check if I can prepare an update and put it on mentors.


Best regards,
Martin

On 04.09.2023 15:27, Debian Bug Tracking System wrote:

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
Debian PhotoTools Maintainers 

If you wish to submit further information on this problem, please
send it to 1009...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
1009303: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009303
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


signature.asc
Description: PGP signature

Bug#1051216: reportbug: mantis-xray GUI fails start on error 'PyQt5.QtGui' has no attribute 'QGraphicsScene'

[Emmanuel FARHI]

Package: mantis-xray
Version: 3.0.11-4
Severity: important
X-Debbugs-Cc: emmanuel.fa...@synchrotron-soleil.fr

Dear Maintainer,

   * What led up to the situation?

Launch 'mantis-xray' GUI fails

   * What was the outcome of this action?

An error is displayed in the terminal:
>> AttributeError: module 'PyQt5.QtGui' has no attribute 'QGraphicsScene'


$ mantis-xray
Loading file plugin: file_bim . Not a valid plugin - skipping.
Loading file plugin: file_csv . (text spectrum) Success!
Loading file plugin: file_dataexch_hdf5 . (Exchange) Success!
Loading file plugin: file_json . (JSON) Success!
Loading file plugin: file_ncb . (Ncb) Success!
Loading file plugin: file_nexus_hdf5 . (NXstxm) Success!
Loading file plugin: file_sdf . (SDF) Success!
Loading file plugin: file_sm_netcdf . Not a valid plugin - skipping.
Loading file plugin: file_stk . (STK) Success!
Loading file plugin: file_tif . (Tiff) Success!
Loading file plugin: file_xrm . (XRM) Success!
Traceback (most recent call last):
  File "/usr/bin/mantis-xray", line 33, in 
sys.exit(load_entry_point('mantis-xray==3.0.11', 'gui_scripts', 'mantis-
xray')())
^
  File "/usr/bin/mantis-xray", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/mantis_xray/mantis_qt.py", line 10528,
in 
class ShowHistogram(QtWidgets.QDialog, QtGui.QGraphicsScene):
   
AttributeError: module 'PyQt5.QtGui' has no attribute 'QGraphicsScene'

   * What outcome did you expect instead?

GUI should have started.

   * Potential solution

Perhaps an upstream update to current v3.1.13 would bring a fix. See
https://pypi.org/project/mantis-xray/#history


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

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

Versions of packages mantis-xray depends on:
ii  python3  3.11.2-1+b1
ii  python3-h5py-serial  3.7.0-8
ii  python3-lxml 4.9.2-1+b1
ii  python3-matplotlib   3.6.3-1+b1
ii  python3-numpy1:1.24.2-1
ii  python3-pil  9.4.0-1.1+b1
ii  python3-pyqt55.15.9+dfsg-1
ii  python3-pyqtgraph0.13.2-1
ii  python3-scipy1.10.1-2

mantis-xray recommends no packages.

mantis-xray suggests no packages.

-- no debconf information

Bug#1009303: MR

[Martin Dosch]

Dear maintainer,

I also stumbled upon imv being not up to date and created a merge 
request on s.d.o: https://salsa.debian.org/debian-phototools-team/imv/-/merge_requests/3


I would appreciate if you'd update the package in sid to 4.4.0. :)

Best regards,
Martin


signature.asc
Description: PGP signature

Bug#1050806: O: debianutils -- Essential utilities specific to Debian

[Ileana Dumitrescu]

Hi Niels,

@Ileana: Would you be fine with co-maintaining it with me? We can use 
the existing git repo (https://salsa.debian.org/debian/debianutils) as 
packaging repo and coordinate our changes via that.


That sounds good!

I have submitted a new version of debianutils to mentors to close the 
ITA along with some other updates [1]. Can you give me the necessary 
permissions for the salsa repo and future uploads?


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

Best,

--
Ileana Dumitrescu

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


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051215: O: mtd-utils -- Memory Technology Device Utilities

[Bastian Germann]

Package: wnpp

Hereby I am orphaning mtd-utils. I do not have the time to maintain it properly.
A very nice thing would beimplementing #619442 installer support.
There are not many releases, ~1 per year.

Description: Memory Technology Device Utilities
 Utilities for manipulating memory technology devices, such as flash
 memory, Disk-On-Chip, or ROM.

Bug#1051214: poll->add() returns same id for every socket added

[Fernando M. Maresca (Monitoring Station S.A.)]

Package: php-zmq
Version: 1.1.3-24
Severity: important


poll->add() allways returns same id for the added socket, and only the
first added socket is actually polled.

This affects the current php version, does not occurs in 7.4

This problem seems to originate here:

zend_string *s_create_key(zval *entry)
{
if (Z_TYPE_P(entry) == IS_RESOURCE) {
/* zend_long since 8.1.0 */
return strpprintf(0, "r:%ld", (long)Z_RES_P(entry)->handle);
}
else {
#if PHP_VERSION_ID >= 80100
zend_string *hash = php_spl_object_hash(Z_OBJ_P(entry));
#else
zend_string *hash = php_spl_object_hash(entry);
#endif
zend_string *key = strpprintf(0, "o:%s", hash->val);
zend_string_release(hash);
return key;
}
}


Thank you.

-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages php-zmq depends on:
ii  php-common  2:93
ii  php8.2-zmq  1.1.3-24

php-zmq recommends no packages.

php-zmq suggests no packages.

-- debconf-show failed

Bug#1051213: RFS: debianutils/5.12 [ITA] -- Miscellaneous utilities specific to Debian

[Ileana Dumitrescu]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : debianutils
   Version  : 5.12
   Upstream contact : [fill in name and email of upstream]
 * URL  : [fill in URL of upstream's web site]
 * License  : public-domain, GPL-2+, SMAIL-GPL
 * Vcs  : https://salsa.debian.org/debian/debianutils
   Section  : utils

The source builds the following binary packages:

  debianutils - Miscellaneous utilities specific to Debian

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/debianutils/debianutils_5.12.dsc


Changes since the last upload:

 debianutils (5.12) unstable; urgency=medium
 .
   * d/control:
 - Add myself as maintainer and Niels Thykier as uploader (Closes: 
#1050806).

 - Bump standards version from 4.6.0 to 4.6.2.
   * d/prerm: Make script executable.
   * d/postinst: Use 'set -e' in the body of the script.
   * d/tests/control: Use 'set -e' in the body of the script.
   * d/source/lintian-overrides: Ignore upstream metadata warning for 
Debian

 native package.
   * ischroot.c: Add missing newline in version output.
   * ischroot.1: Fix to say detection is possible for exit status 0.

Niels Thykier and I will be co-maintaining this package.

--
Ileana Dumitrescu

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


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051212: RM: osm2pgsql [i386 armel armhf] -- ROM; 32bit architectures not supported

[Bas Couwenberg]

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

Please remove osm2pgsql from the 32bit architectures where it FTBFS because 
upstream doesn't support them any more.

Kind Regards,

Bas

Bug#1051192: solid-auth, liblog-any-perl: solid-auth became uninstallable after liblog-any-perl dropped liblog-any-adapter-perl Provides

[gregor herrmann]

On Mon, 04 Sep 2023 12:54:58 +0200, Axel Beckert wrote:

> > Oops, sorry for that.
> Well, aptitude automatically suggested to hold back liblog-any-perl. :-)

Heh :)
 
> > I noticed that liblog-any-adapter-perl was removed in 2015, and, more
> > importantly, I checked with `apt-cache rdepends
> > liblog-any-adapter-perl' which, unless I was blind, didn't show
> > anything.
> I can confirm that — looks like a bug around virtual packages:

Thanks for double-checking!
 
> Weird. 

Indeed unfortunate.
 
> > A fix in libweb-solid-auth-perl seems more appropriate to me; unless
> > we have more hidden dependencies …
> As far as I can see, solid-auth should be the last one. All others
> already have it as last part of a list of alternative dependencies, so
> no issue:
> → grep-aptavail -FDepends -P liblog-any-adapter-perl | fgrep 
> liblog-any-adapter-perl

Nice, I always forget the syntax.

With different output:

% grep-aptavail -FDepends -P liblog-any-adapter-perl -s Source,Package,Depends 
Package: libdata-hal-perl
Depends: perl:any, libboolean-perl, libclone-perl, libdata-visitor-perl, 
libfailures-perl, libhttp-message-perl, libjson-perl, liblog-any-perl | 
liblog-any-adapter-perl, libmime-types-perl, libmoo-perl, libsafe-isa-perl, 
libstrictures-perl, libtype-tiny-perl, liburi-namespacemap-perl, liburi-perl, 
liburi-template-perl, libxml-regexp-perl

Package: liblog-any-adapter-callback-perl
Depends: perl:any, liblog-any-perl | liblog-any-adapter-perl

Package: liblog-any-adapter-dispatch-perl
Depends: perl:any, liblog-any-perl | liblog-any-adapter-perl, 
liblog-dispatch-perl

Package: liblog-any-adapter-filehandle-perl
Depends: perl:any, liblog-any-perl | liblog-any-adapter-perl

Source: libweb-solid-auth-perl
Package: solid-auth
Depends: libfile-libmagic-perl, libjson-perl, liblog-any-adapter-log4perl-perl, 
liblog-any-adapter-perl, liblog-log4perl-perl, libpath-tiny-perl, 
libstring-escape-perl, libweb-solid-auth-perl, perl:any


shell alias or function?


> Should we do this in solid-auth, too, or just use solely
> liblog-any-perl?

I'd go for only liblog-any-perl everywhere as is gone …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1051191: libsdl2: Please add stage1 profile to disable pipewire for bootstrap

[Simon McVittie]

On Mon, 04 Sep 2023 at 11:08:01 +0200, John Paul Adrian Glaubitz wrote:
> There is currently a circular build-dependency in src:libsdl2 with 
> src:pipewire which
> makes bootstrapping libsdl2 hard. In order to ease the bootstrap, it would be 
> useful
> if the build dependency on libpipewire-0.3-dev could be disabled with a build 
> profile.
> 
> Could you add a "stage1" or "pkg.libsdl2.nopipewire" build profile to 
> src:libsdl2?

This wouldn't be a "safe" build profile: the resulting binaries would
not be functionally equivalent to binaries of the same name built with
no special build profiles. It's OK to have "unsafe" build profiles if
there's no alternative, but it seems better to avoid them, because names
are interfaces and interfaces are names.

I'd prefer to break this circular dependency from the other end. If it's
possible to add nocheck and noinsttests profiles to pipewire (a similar
arrangement already exists in for example src:dbus), then pipewire would
lose its pipewire-tests binary package, which as far as I can tell is the
only one that depends on SDL, without affecting the contents of other
binary packages.

In fact, since the SDL manual test isn't run at build time, only packaged
to be run later, probably a noinsttests profile in pipewire would be
enough? (That would avoid having to remember how the logical operators
for combining build profiles work!)

smcv

Bug#1041492: xpra: FTBFS with ffmpeg 6.0

[Vincent Lefevre]

Control: tags -1 fixed-upstream

On 2023-07-19 19:10:36 +0200, Sebastian Ramacher wrote:
> xpra FTBFS with ffmpeg 6.0 (available in experimental)

and in unstable since a few weeks.

Any news?

FYI, https://github.com/Xpra-org/xpra/blob/v3.1.x/src/NEWS says that
this is fixed in v3.1.4 (2023-03-05):

- ffmpeg v6 compatibility

and 3.1.5 has even been released on 2023-06-15.

Note also that ffmpeg will be removed from future xpra versions (6.x),
if I understand correctly:

https://github.com/Xpra-org/xpra/commit/20bb5f04233dc650022bc67d5904566d1b158af9

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

Bug#1051168: gtk4: 4.12 regression: FTBFS on riscv64: multiple test failures

[Simon McVittie]

On Mon, 04 Sep 2023 at 07:24:55 -0400, Jeremy Bícha wrote:
> On Mon, Sep 4, 2023 at 5:00 AM Simon McVittie  wrote:
> > I'll apply at least that, but if new architectures can't have llvmpipe
> > for a while, then perhaps it would make more sense to apply the mips%
> > workaround to every architecture.
> 
> I very recently proposed
> https://salsa.debian.org/gnome-team/gtk4/-/merge_requests/17 which
> does the same thing as the patch proposed originally in this bug.

I'm testing a build of that, adapted to collect the image diff output
for all GSK rendering variants (so that we can debug
"gl border-one-rounded flipped") and apply the softpipe workaround
unconditionally (because any architecture could in principle be using
softpipe).

Upstream bug report for the rendering being different with softpipe:
https://gitlab.gnome.org/GNOME/gtk/-/issues/6085

smcv

Bug#1051211: pulseaudio: Pulseaudio loses HDMI output from time to time.

[Marcelo]

Package: pulseaudio
Version: 16.1+dfsg1-2+b1
Severity: important
X-Debbugs-Cc: mmnegre...@gmail.com

Dear Maintainer,

Pulseaudio loses HDMI output from time to time.
It seems that the service stops, as the command "systemctl --user restart
pulseaudio" solves the problem.


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


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

Kernel: Linux 6.5.1.mmn.cma.swap (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser 3.134
ii  init-system-helpers 1.65.2
ii  libasound2  1.2.8-1+b1
ii  libasound2-plugins  1.2.7.1-1
ii  libc6   2.36-9+deb12u1
ii  libcap2 1:2.66-4
ii  libdbus-1-3 1.14.8-2~deb12u1
ii  libfftw3-single33.3.10-1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3+deb12u1
ii  libgstreamer1.0-0   1.22.0-2
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-5
ii  liborc-0.4-01:0.4.33-2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.2.0-1
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.1-1
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.12-1~deb12u1
ii  libtdb1 1.4.8-2
ii  libudev1252.12-1~deb12u1
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libwrap07.6.q-32
ii  libx11-62:1.8.4-2+deb12u1
ii  libx11-xcb1 2:1.8.4-2+deb12u1
ii  libxcb1 1.15-1
ii  libxtst62:1.2.3-1.1
ii  pulseaudio-utils16.1+dfsg1-2+b1
ii  sysvinit-utils [lsb-base]   3.06-4

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.8-2~deb12u1
ii  libpam-systemd [logind]  252.12-1~deb12u1
ii  rtkit0.13-5

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 252.12-1~deb12u1

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

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

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

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

; cookie-file =

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

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

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

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; 

Bug#1051210: cinnamon: bug in cinnamon-settings

[Walter Valenti]

Package: cinnamon
Version: 5.6.8-1
Severity: minor
X-Debbugs-Cc: debian-cinna...@lists.debian.org, waltervale...@yahoo.it


In System Settings -> Appareance -> Backgrouds, in not possible change the
background image.
This the error for example:



Failed to convert /usr/share/desktop-base/joy-inksplat-
theme/wallpaper/contents/images/3840x2160.svg: module 'PIL.Image' has no
attribute 'ANTIALIAS'


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

Kernel: Linux 6.4.0-3-amd64 (SMP w/6 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 cinnamon depends on:
ii  cinnamon-common  5.6.8-1
ii  cinnamon-control-center  5.8.1-1
ii  cinnamon-desktop-data5.6.2-1
ii  cinnamon-screensaver 5.6.3-1
ii  cinnamon-session 5.6.0-1
ii  cinnamon-settings-daemon 5.6.2-3
ii  cjs  5.6.0-1
ii  cups-pk-helper   0.2.6-1+b1
ii  dbus 1.14.8-2
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   23.13.9-3
ii  gir1.2-caribou-1.0   0.4.21-8
ii  gir1.2-cmenu-3.0 5.8.0-1
ii  gir1.2-cvc-1.0   5.6.2-1
ii  gir1.2-ecal-2.0  3.49.3-1
ii  gir1.2-edataserver-1.2   3.49.3-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gkbd-3.0  3.28.1-1
ii  gir1.2-glib-2.0  1.76.1-5
ii  gir1.2-gnomedesktop-3.0  44.0-2
ii  gir1.2-goa-1.0   3.48.0-2
ii  gir1.2-gsound-1.01.0.3-2
ii  gir1.2-gtk-3.0   3.24.38-4
ii  gir1.2-ical-3.0  3.0.16-1+b1
ii  gir1.2-keybinder-3.0 0.3.2-1.1
ii  gir1.2-nemo-3.0  5.6.5-1
ii  gir1.2-nm-1.01.44.0-1
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-notify-0.70.8.2-1
ii  gir1.2-pango-1.0 1.51.0+ds-2
ii  gir1.2-polkit-1.0123-1
ii  gir1.2-soup-2.4  2.74.3-1
ii  gir1.2-timezonemap-1.0   0.4.6-6
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-xapp-1.0  2.6.1-1
ii  gkbd-capplet 3.28.1-1
ii  gnome-backgrounds44.0-2
ii  gnome-themes-extra   3.28-2
ii  gsettings-desktop-schemas44.0-2
ii  iso-flags-png-320x2401.0.2-2
ii  libatk-bridge2.0-0   2.49.90-5
ii  libatk1.0-0  2.49.90-5
ii  libc62.37-7
ii  libcairo21.16.0-7
ii  libcinnamon-desktop4 5.6.2-1
ii  libcinnamon-menu-3-0 5.8.0-1
ii  libcjs0  5.6.0-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.76.1-5
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.77.2-1
ii  libglib2.0-bin   2.77.2-1
ii  libgstreamer1.0-01.22.5-1
ii  libgtk-3-0   3.24.38-4
ii  libmuffin0   5.6.4-1
ii  libpango-1.0-0   1.51.0+ds-2
ii  libpangocairo-1.0-0  1.51.0+ds-2
ii  libx11-6 2:1.8.6-1
ii  libxapp1 2.6.1-1
ii  libxfixes3   1:6.0.0-2
ii  libxml2  2.9.14+dfsg-1.3
ii  mesa-utils   8.5.0-1
ii  muffin   5.6.4-1
ii  nemo 5.6.5-1
ii  network-manager-gnome1.32.0-3
ii  pkexec   123-1
ii  policykit-1-gnome0.105-8
ii  psmisc   23.6-1
ii  python3  3.11.4-5+b1
ii  python3-dbus 1.3.2-5
ii  python3-distro   1.8.0-1
ii  python3-gi   

Bug#1051209: dpkg-dev: dpkg-source --commit should use configured default editor instead of forcing nano

[Axel Kittenberger]

Package: dpkg-dev
Version: 1.22.0
Severity: normal

Dear Maintainer,

   * What led up to the situation?

 using: dpkg-source --commit

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

 I used `update-alternatives --config editor` because I want to edit with 
vim.
 (actually it became the default editor already by manually install 
vim-gtk3)

   * What was the outcome of this action?

dpkg-source uses nano

   * What outcome did you expect instead?

dpkg-source using vim (or just call `editor`)

-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See .

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

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.41-4
ii  bzip2 1.0.8-5+b1
ii  libdpkg-perl  1.22.0
ii  make  4.3-4.1
ii  patch 2.7.6-7
ii  perl  5.36.0-7
ii  tar   1.34+dfsg-1.2
ii  xz-utils  5.4.4-0.1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.10
ii  clang-14 [c-compiler]1:14.0.6-13
ii  fakeroot 1.32.1-1
ii  gcc [c-compiler] 4:13.2.0-1
ii  gcc-13 [c-compiler]  13.2.0-2
ii  gnupg2.2.40-1.1
ii  gpgv 2.2.40-1.1
ii  libalgorithm-merge-perl  0.08-5

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2023.05.26

-- no debconf information

Bug#1051208: linux-headers-amd64 6.1.27-1~bpo11+1 depends on a package that is not in the repos

[Jonas]

Package: linux-headers-amd64
Version: 6.1.27-1~bpo11+1
Severity: important

Dear Maintainer,

When installing linux-headers-amd64 from the Backports repo, it depends
on the linux-headers-6.1.0-0.deb11.9-amd64 (= 6.1.27-1~bpo11+1) package,
which is not found in the mirrors, thus fails. 

Please update the linux-headers-amd64 package in the backports
repository to depend on other kenel, or upload the kernel headers
package to the mirrors (the linux-image package for that version is
available, just the headers are missing).


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

Kernel: Linux 6.2.16-3-pve (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-headers-amd64 depends on:
pn  linux-headers-5.10.0-22-amd64
pn  linux-headers-5.10.0-25-amd64
pn  linux-headers-6.1.0-0.deb11.9-amd64  

linux-headers-amd64 recommends no packages.

linux-headers-amd64 suggests no packages.

Bug#1051205: git grep -F isn't ‒ '(' fails with "fatal: unmatched parenthesis"

[наб]

Control: retitle -1 git grep -F and BRE fail for "'('" with "fatal: unmatched 
parenthesis" but work for "-- '('"?

This is correct:
$ git grep '\('  | head -n1
fatal: command line, '\(': Unmatched ( or \(

This ain't:
$ git grep '('  | head -n1
fatal: unmatched parenthesis
$ git grep -- '('  | head -n1
CONTRIBUTING:   or from git(1) logs or logs in other version control 
systems.
$ git grep -F -- '('  | head -n1
CONTRIBUTING:   or from git(1) logs or logs in other version control 
systems.


signature.asc
Description: PGP signature