Bug#1052028: please update to pydantic 2.x

[Michael Banck]

Hi Timo,

On Sat, Sep 16, 2023 at 12:26:32PM +0200, Timo Röhling wrote:
> I would like to have pydantic updated to the latest 2.x major release,
> because rstcheck depends on it.
> 
> The 2.x API has some breaking changes, but according to the pydantic
> README, version 1.10.4 is shipped as pydantic.v1 legacy module.
> Therefore, any reverse dependency which is incompatible with the 2.x API
> can be fixed trivially at import level.
> 
> As pydantic is only weakly team managed, I am submitting this wishlist
> bug, but I am willing to do the grunt work for this and provide the
> necessary team uploads.

Please go ahead, I don't think I will have time before the end of
Debconf to do this, and then probably even less for a while
afterwards


Michael

Bug#1016703: mkdocs-material: Please package recent version

[Sandro Tosi]

> this bug report is now open for one year, is there something you need
> help with?
>
> I'd really appreciate a recent version could make it's way into the
> archive.

is there something blocked by this?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1051739: Package is uninstallable, bug unacknowledged, therefore release critical

[Joseph Carter]

Control: severity -1 grave

I didn't do this when filing the bug since ages ago it was considered impolite 
for end-users to set severity and particularly to set a severity above 
important. But it's been a week without acknowledgment or fix, and it is 
release critical even if it's a contrib package that isn't for the Holy Gnoman 
Empire DE. 

Joseph

Bug#1051819: fluidsynth: Consider building with pipewire support

[Gianfranco Costamagna]

Hello, i did nmu because... 1) riscv64 porting is finishing and they need to 
build as many packages as possible (this one was blocking a lot of packages) 2) 
im in vac now for more than one week, and i wont have access to laptop or so
Sorry for the rush and indeed feel free to change everything as you prefer :) 
Cheers! 
Gianfranco

Sent from Yahoo Mail on Android 
 
  On Sat, Sep 16, 2023 at 15:27, Johannes Schauer Marin 
Rodrigues wrote:   Hi Nicholas,

Quoting Nicholas D Steeves (2023-09-16 14:06:00)
> Oh my, yes, it seems I forgot to add the new pipewire -dev package to the
> fluidsynth -dev package.  'not sure how that happened, but my mistake!  Isn't
> only waiting 48h a bit rushed for an NMU though?

the number of delayed days are documented here:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-and-how-to-do-an-nmu

It seems that indeed a 0-day nmu was a bit too quick here.

> I can of course import your fix and upload in the next 48h, and I'd like to
> improve your changelog entry, because I think you'll agree that the concept
> of "runtime" doesn't make sense for headers ;)

It does make sense as we have two types of dependencies in Debian: build
dependencies and runtime dependencies. A header package is also a binary
package so it has runtime dependencies like all other binary packages do.

But indeed the term "runtime dependency" is not very widely used. I do not
think that Debian policy uses it. I think the term is mostly used by people
like me who work on dependency resolution software.

> If this is truly 0-day urgent, I'm confident a team member (IIRC Josch is a
> multimedia-team member) will upload.

I'm afraid it was already uploaded and is now in unstable. :(

> ('hope this isn't HTML email, since I'm currently AFK on a phone)

It was HTML but it also had a text/plain part. :)

Thanks!

cheers, josch  

Bug#1052077: cinnamon-screensaver: Screensaver only occupies 1/4 of screen when using 200% scaling after monitor power cycle

[Jared Epp]

Package: cinnamon-screensaver
Version: 5.6.3-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: jared...@pm.me

Dear Maintainer,

When I lock my screen and turn off my monitor, after I turn it on again, the
screensaver only occupies 1/4 of the screen (the top left quarter).

You can see the other 3/4 of the screen as though the screen isn't locked.
So it's a problem if you were depending on the screen saver / locker to hide
any information there. But the whole screen is still locked and you can't
interact with it.

My screen is 4K and I'm using 200% scaling.  I tried reducing scaling to 100%
and it fixes the issue.  I also didn't have the issue in Bullseye and only
encountered it after I upgraded to Bookworm.

My video card is the integrated graphics in an AMD Ryzen 5700G (Vega).

I tagged the bug as "upstream" when reportbug asked because it seems to be an
outstanding bug there:
https://github.com/linuxmint/cinnamon-screensaver/issues/337
but it was initially reported on cinnamon-screensaver 4.4.1, but I didn't have
the issue in Bullseye which used 4.8.1. 

If I can provide any other info let me know.  Thanks!

Jared

-- 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-12-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cinnamon-screensaver depends on:
ii  cinnamon-desktop-data   5.6.1-1
ii  gir1.2-accountsservice-1.0  22.08.8-6
ii  gir1.2-cinnamondesktop-3.0  5.6.1-1
ii  gir1.2-cscreensaver-1.0 5.6.3-1
ii  gir1.2-gkbd-3.0 3.28.1-1
ii  gir1.2-glib-2.0 1.74.0-3
ii  gir1.2-gtk-3.0  3.24.37-2
ii  gir1.2-xapp-1.0 2.4.2-3
ii  iso-flags-png-320x240   1.0.2-2
ii  libc6   2.36-9+deb12u1
ii  libcairo2   1.16.0-7
ii  libcscreensaver05.6.3-1
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.37-2
ii  libpango-1.0-0  1.50.12+ds-1
ii  python3 3.11.2-1+b1
ii  python3-gi  3.42.2-3+b1
ii  python3-gi-cairo3.42.2-3+b1
ii  python3-setproctitle1.3.1-1+b2
ii  python3-xapp2.4.0-1
ii  python3-xlib0.33-2

Versions of packages cinnamon-screensaver recommends:
ii  libpam-gnome-keyring  42.1-1+b2

cinnamon-screensaver suggests no packages.

-- no debconf information

Bug#1051659: GDM does not detect users correctly

[terroreek]

The issue seems to be having my Yubikey plugged in when GDM starts its
looking for pam_sss.so.  If the pam module is missing one cannot login
interactively.  I will try installing libpam-sss, to see if that revolves
the issue.  However it can be fixed by removing my yubikey and plug it in
after logging into gdm.

Bug#1052076: ITP: node-mathjax-full -- JavaScript library to display math in browsers

[Yadd]

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

* Package name: node-mathjax-full
  Version : 3.2.2
  Upstream Contact: The MathJax Consortium
  
* URL : https://github.com/mathjax/Mathjax-src
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : JavaScript library to display math in browsers

MathJax is an open-source JavaScript display engine for LaTeX, MathML,
and AsciiMath notation that works in all modern browsers. It was
designed with the goal of consolidating the recent advances in web
technologies into a single, definitive, math-on-the-web platform
supporting the major browsers and operating systems.  It requires no
setup on the part of the user (no plugins to download or software to
install), so the page author can write web documents that include
mathematics and be confident that users will be able to view it
naturally and easily.  Simply include MathJax and some mathematics in
a web page, and MathJax does the rest.

node-mathjax-full is a dependency of node-jupyterlab. It will be
maintained under JS Team umbrella.

Bug#1052040: mmm-mode: post-install script fails

[Vincent Lefevre]

Control: tags -1 - upstream

The issue actually comes from the 01-xemacs patch.

On 2023-09-16 17:46:23 +0200, Vincent Lefevre wrote:
> An easy solution would be to avoid the XEmacs form (marked as
> obsolete in GNU Emacs since 23.1 and whose support was removed
> in GNU Emacs 28[*]), i.e. change
> 
> (if (not (string-match "XEmacs" (emacs-version)))
> (define-obsolete-function-alias 'mmm-add-find-file-hooks 
> 'mmm-add-find-file-hook
>   "0.3.8"
>   "Both `mmm-add-find-file-hooks' and `mmm-add-find-file-hook' are 
> deprecated.")
>   (define-obsolete-function-alias 'mmm-add-find-file-hooks 
> 'mmm-add-find-file-hook))
> 
> to just
> 
> (define-obsolete-function-alias 'mmm-add-find-file-hooks 
> 'mmm-add-find-file-hook
>   "0.3.8"
>   "Both `mmm-add-find-file-hooks' and `mmm-add-find-file-hook' are 
> deprecated.")

Alternatively, update to release 0.5.10, where upstream has just
removed these obsolete functions:

https://github.com/dgutov/mmm-mode/commit/244f8c4794f20a6be5ebe1e405400a9c35ea6d2f

so that mmm-auto.el no longer needs to be patched for xemacs.

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

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> Aside from more practical considerations, shipping /var
Luca> content in packages is problematic because it's supposed to be
Luca> local variable data,

I agree with the above.

Luca> that can be removed without breaking a
Luca> system.

Says who?
Where?
Do we have any agreement within Debian that is true for Debian systems?
If so, where?  This is the first I am hearing about the idea I should be
able to delete local variable data and have the system  still work.

If you're talking about *empty directories in /var* or *cache
directories in /var*,
I support that as a goal.  I think it is a new goal though, and I'm
uncomfortable stating it as a reality.
(I think tmpfiles.d helps us achieve that and that's one of the
compelling reasons for tmpfiles.d).

But WRT other data in /var, I don't think we've agreed that being able
to delete it is a goal.

Bug#1052075: ITP: node-speech-rule-engine -- NodeJS version of the ChromeVox speech rule engine

[Yadd]

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

* Package name: node-speech-rule-engine
  Version : 3.2.2
  Upstream Contact: Volker Sorge 
* URL : https://github.com/zorkow/speech-rule-engine
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : NodeJS version of the ChromeVox speech rule engine

node-speech-rule-engine (SRE) can translate XML expressions into speech
strings according to rules that can be specified in a syntax using Xpath
expressions.

It's a dependnecy of node-mathjax-full, needed to build node-jupyterlab.
Will be maintained under JS Team upbrella.

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Alexandre Detiste]

Le dim. 17 sept. 2023 à 01:15, Russ Allbery  a écrit :
> Luca Boccassi  writes:
>
> One would need to duplicate empty directories in /var (that don't have
> dynamic ownership).  I'm dubious that's a significant burden (it's two or
> three lines in debian/rules), but if it is,
> one could even automate this
> in debhelper by parsing tmpfiles.d if one really wanted to.

That would be awesome. The less (open) code in d/rules, the better.

There's already this draft RM that this feature could build upon.
https://salsa.debian.org/debian/debhelper/-/merge_requests/102/

Greets

Bug#1051251: /usr/sbin/grub-mkconfig: 300: /etc/grub.d/25_bli: not found due to wrong shell location

[gregor herrmann]

On Sat, 16 Sep 2023 11:43:41 +0200, Julian Andres Klode wrote:

> You have literally hacked around the dependencies of the packages by
> inserting a fake package to pretend to have merged-usr installed to be
> able to maintain a file system layout the project has decided is no
> longer supported.

That's wrong.
Another option is to put init on hold (at the version before it
depends on usr-merge).
 
> FWIW, if you people keep being annoying I (with my apt head on) am
> just going to deliberately make apt error out and refuse any operation
> on unmerged systems.

Your communication style is uncacceptable. Please reconsider.


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#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Luca Boccassi  writes:

> Aside from more practical considerations, shipping /var content in
> packages is problematic because it's supposed to be local variable data,
> that can be removed without breaking a system.

Unless I'm missing something, including the directory in the deb won't
make any difference here.  dpkg won't break if a directory that was
included in the package is deleted.  It would show as an inconsistency if
someone checked the file system against the dpkg database, but as soon as
systemd-tmpfiles runs, it will create the directory again and fix the
inconsistency, so I don't see what problems that would create.

> More practically, one of the purposes of the hermetic-usr pattern is to
> allow several modernizations. The easiest one to achieve is to create
> /var/ on firstboot, and encrypt it against the tpm, so that it can be
> enabled by default, always, so we can't have packages ship and expect
> content in /var from their packages.

(I am a little confused by this wording, but I think what you're saying is
that /usr is encrypted and read-only, and /var is recreated on each boot.
That at least is my understanding of the pattern that you're trying to
enable.)

Here too, I don't see how including an empty directory in /var in the deb
will make any difference here.  When you create such a system, you would
delete /var, so it wouldn't matter if packages created files in there (and
in fact, under every proposal in this bug, installing packages *would*
create files there, since systemd-tmpfiles would be invoked by the
maintainer scripts anyway).

> On top of that, as you mentioned already things will inevitably get out
> of sync, and one will have to duplicate everything.

One would need to duplicate empty directories in /var (that don't have
dynamic ownership).  I'm dubious that's a significant burden (it's two or
three lines in debian/rules), but if it is, one could even automate this
in debhelper by parsing tmpfiles.d if one really wanted to.  The main
thing that could get out of sync is the ownership, which is indeed not
ideal, but I'm also not sure it's going to cause major problems even if
people do get it wrong.  I was trying to remember if dpkg changes
directory (as opposed to file) ownership if it sees a directory owned by
an unexpected user.  I kind of think it doesn't, but I'm not sure about
that.

The benefit we gain from this is attribution of the directories in the
dpkg database, which is useful (although I understand that one can argue
about how useful).

So... I think the answer to my question of whether this will interfere
with your use case is no?  I understand that you don't want to do it, and
expected that, and that opinion is important for the discussion, but I'm
also trying to figure out if it will *break* anything.

> And if dpkg gets the ability to read tmpfiles.d - then that's great,
> and even more reasons not to change policy for something that would
> only be a temporary stop-gap.

I'm not going to assume that this is going to happen on any particular
time scale.  dpkg has to gain a mechanism for registering transient files
first, which in my understanding depends on other significant dpkg
architectural work.

-- 
Russ Allbery (r...@debian.org)  

Bug#1052074: rust-pkcs8: fails to build from source

[Jeremy Bícha]

Source: rust-pkcs8
Version: 0.10.2+ds-6
Tags: ftbfs

rust-pkcs8 fails to build from source:
https://buildd.debian.org/status/package.php?p=rust-pkcs8

Thank you,
Jeremy Bícha

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Simon McVittie  writes:

> The key piece of information that was missing from your previous
> proposal was that systemd-tmpfiles interface versions match upstream
> systemd version numbers. As a concrete example, if someone wants to
> upload an implementation other than the one from systemd, it cannot have

> Provides: systemd-tmpfiles (= 254)

> until it has at least a basic implementation of the new "X", "C+" and
> "--graceful" features introduced in systemd 254.

Yeah, I had missed that, thank you.  I think that's now captured.

> If the package benefits from running tmpfiles.d but does not strictly
> require it (for example dbus-daemon, where /run/dbus/containers is
> needed for some optional functionality), would a Recommends or Suggests
> be allowed by this wording, or are we intending for this to be a
> mandatory hard dependency?

I'm not sure it's going to make a lot of difference in practice, since I
think it will be hard to end up with a system that doesn't have a
systemd-tmpfiles implementation installed, but I agree that in theory this
is too strong.  I'll try to come up with a rewording that allows for the
possibility of Recommends or Suggests.  Maybe just a parenthetical that
says or Recommends or Suggests if this more accurately fits the nature of
the dependency?

I think apart from this and resolving whether to add empty directories
into the deb, the remaining issue before we can merge this is to make sure
that the sysvinit maintainers are okay with adding the requirement that
the init system invoke a systemd-tmpfiles implementation periodically.  As
I would expect, the systemd-standalone-tmpfiles package only provides the
binary, not any init system integration.  Does anyone know if that
integration has already been done to invoke systemd-tmpfiles during boot
on systems using sysvinit?

-- 
Russ Allbery (r...@debian.org)  

Bug#1052073: firefox-esr libwebp trixie concern

[uesr24824382]

Package: firefox-esrVersion: 115.2.0esr-1   Severity: critical  update 
debian trixie's firefox-esr version to 115.2.1esr-1 you swarthy men, every 30 
minutes that pass without updating firefox-esr will make your test levels drop 
by 20 ng/dL.debian buster already received the security update, there 
is zero reason to justify not pushing 115.2.1esr-1 to trixie. 

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Fri, 15 Sept 2023 at 22:18, Russ Allbery  wrote:
>
> Guillem Jover  writes:
>
> > Not shipping these empty directories in the .deb seems like a regression
> > or a disservice to me. Even for things that might get deleted because
> > things like our policy or the FHS allows for it (say stuff under
> > /var/cache), as «dpkg --verify» can be useful. Because of course, these
> > in addition, can be defined via tmpfiles.d, so that they can possibly be
> > recreated if needed (until dpkg provides its own interfaces to do that).
>
> Luca, are there any drawbacks for your purposes in both shipping the
> directories in the deb *and* defining them with tmpfiles.d for those cases
> where it is possible to ship them in the deb (no dynamic owner or group,
> for instance)?  At first glance, it feels like this should be fine, since
> tmpfiles.d will recreate the directories and dpkg will then be happy with
> them.
>
> It does potentially create problems if dpkg and tmpfiles.d have different
> ideas about what the ownership or permissions of the directories should
> be, but at present I don't think such conflicts would create a lot of
> practical problems (tmpfiles.d should essentialy always win), so I think
> it's a fairly minor point.
>
> It's a bit more complicated to specify in Policy because it's not possible
> to include the directory in the deb file in cases where it needs to have
> ownership set based on users or groups created dynamically by the
> maintainer scripts, but hopefully not overly complicated.

Aside from more practical considerations, shipping /var content in
packages is problematic because it's supposed to be local variable
data, that can be removed without breaking a system. This is by
definition not the case if the system's state becomes inconsistent
because packages, that have fixed content, ship files that can then be
removed locally. This is one of the many reasons why recently rpm
moved its database into /usr, as that's really what it is tied to and
where packages ship files into. AFAIK a few people have already
started some time ago to fix this on a package-by-package basis -
fortunately it's not that many, iirc.

More practically, one of the purposes of the hermetic-usr pattern is
to allow several modernizations. The easiest one to achieve is to
create /var/ on firstboot, and encrypt it against the tpm, so that it
can be enabled by default, always, so we can't have packages ship and
expect content in /var from their packages. This is a concrete and
achievable step forward to catch up to other OSes, as Linux is
embarrassingly behind Windows and OSX on the security aspect, and we
have a lot of work to do.

On top of that, as you mentioned already things will inevitably get
out of sync, and one will have to duplicate everything. Also
inevitably it will end up being wrong in cases where different
metadata has to be specified, with conflicts. This seems just busywork
that we can spare ourselves.

And if dpkg gets the ability to read tmpfiles.d - then that's great,
and even more reasons not to change policy for something that would
only be a temporary stop-gap. rpm recently gained native support for
sysusers.d and I believe they are looking into tmpfiles.d next, so
it's the right thing to do regardless.

Bug#1052027: cargo-mozilla 0.66.0+ds1-1~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1052027 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: cargo-mozilla
Version: 0.66.0+ds1-1~deb11u1

Explanation: new "upstream" version, to support building newer firefox-esr 
versions

Bug#970043: galera-4: FTBFS on ia64: [libgalera_smm.so] Error 1

[Otto Kekäläinen]

This issue is still visible in the galera-4 26.4.13-1 build.

It is unclear to me what the error is.

There is no guidance at https://github.com/codership/galera/issues/558
what this could be about.

Last line build log
https://buildd.debian.org/status/fetch.php?pkg=galera-4=ia64=26.4.13-1=1689943818=0
shows:

[ 96%] Linking CXX static library libgalera_smm_static.a
cd /<>/obj-ia64-linux-gnu/galera/src && /usr/bin/cmake -P
CMakeFiles/galera_smm_static.dir/cmake_clean_target.cmake
cd /<>/obj-ia64-linux-gnu/galera/src && /usr/bin/cmake -E
cmake_link_script CMakeFiles/galera_smm_static.dir/link.txt
--verbose=1
/usr/bin/ar qc libgalera_smm_static.a
CMakeFiles/galera_smm_static.dir/wsrep_provider.cpp.o
/usr/bin/ranlib libgalera_smm_static.a
Checking library symbol visibility (hidden)
sh -c "! /usr/bin/objdump -T libgalera_smm.so | grep asio 1> /dev/null"
make[3]: *** [galera/src/CMakeFiles/galera_smm.dir/build.make:113:
libgalera_smm.so] Error 1
make[3]: *** Deleting file 'libgalera_smm.so'
make[3]: Leaving directory '/<>/obj-ia64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1840:
galera/src/CMakeFiles/galera_smm.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs
make[3]: Leaving directory '/<>/obj-ia64-linux-gnu'
[ 96%] Built target galera_smm_static
make[2]: Leaving directory '/<>/obj-ia64-linux-gnu'
make[1]: *** [Makefile:169: all] Error 2
make[1]: Leaving directory '/<>/obj-ia64-linux-gnu'
dh_auto_build: error: cd obj-ia64-linux-gnu && make -j2
"INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2
make: *** [debian/rules:25: binary-arch] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
exit status 2

Bug#1052072: package ontospy contains license CC-BY-1.0

[Thorsten Alteholz]

Package: ontospy
Version: 0~20190225~dfsg1-1
Severity: serious
User: alteh...@debian.org
Usertags: license
thanks


Hi Jonas,

unfortunately your package contains a file with license: CC-BY-1.0

   ontospy/gendocs/misc/html-tests/_FOAFspecification.html

This license is not compatible with DFSG[1], so please remove the file or
move the package to non-free.

Thanks!
 Thorsten

[1] https://lists.debian.org/debian-legal/2004/04/msg00031.html

Bug#993996: RFS: guerillabackup/0.5.0-1 [ITP] -- resilient, distributed backup and archiving solution

[halfdog]

Dear mentors,

A new version of the package is uploaded at mentors with the
following changes compared with the previous version uploaded:

* Upstream integration of improvements from Debian RFS review process,
see merge on previous version v0.4.0-1:
https://salsa.debian.org/halfdog-guest/guerillabackup/-/merge_requests/1


Now I am looking for a sponsor for my package "guerillabackup":

 * Package name : guerillabackup
   Version  : 0.5.0-1
   Upstream contact : m...@halfdog.net
 * URL  : https://github.com/halfdog/guerillabackup
 * License  : LGPL-3.0+
 * Vcs  : https://salsa.debian.org/halfdog-guest/guerillabackup
   Section  : misc

The source builds the following binary packages:

  guerillabackup - resilient, distributed backup and archiving solution

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.5.0-1.dsc

Changes for the initial release:

 guerillabackup (0.5.0-1) unstable; urgency=medium
 .
   * Initial packaging of guerillabackup (Closes: #849714)

Regards,
-- 
  hd

Bug#1049413: update to 2.56

[Matthias Geiger]

On 16.09.23 23:32, Jeremy Bícha wrote:

On Sat, Sep 16, 2023 at 5:26 PM Matthias Geiger  wrote:

I would suggest to switch the upstream to the source on crates.io and
provide the "crate data" on top.

Are you able to provide the "crate data" on top of the current librsvg
in Unstable?

Could you try patching glycin-loaders to accept librsvg 2.54? I see in
the git log that the dependency appears to have been arbitrarily set
from 2.57 to 2.56 and then back to 2.57 so maybe the dependency is
stricter than it needs to be.

Thank you,
Jeremy Bícha


a quick wget of the crate tarball shows the "crate data" is the raw 
source code under src/ , tests/ and benches plus example.svg, build.rs 
and Cargo.toml. I'll test tomorrow if that installed under 
/usr/share/cargo/registry will work for a build.


best,

--
Matthias Geiger (werdahias)
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041973: capnproto: not usable with gcc-13 and c++20

[tony mancill]

On Tue, Jul 25, 2023 at 01:32:18PM +0200, Andre Naujoks wrote:
> Source: capnproto
> Version: 0.9.2-3
> Severity: normal
> Tags: upstream,fixed-upstream
> X-Debbugs-Cc: andre.nauj...@keysight.com
> 
> Currently the C++ generated code from capnproto does not work with gcc-13 and
> C++20.
> This can be reproduced by generating and compiling code for e.g. the sample
> addressbook capnp file
> (https://github.com/capnproto/capnproto/tree/v0.9.2/c%2B%2B/samples), which is
> part of capnproto, like this:
> 
> # capnpc -oc++ addressbook.capnp
> # g++ -std=c++20 -c addressbook.capnp.c++ -o a.o
>   ^^^ this fails
> 
> This seems to be fixed upstream in the current version (0.10.4).

Hello Andre,

Thank you for reporting the issue.  I agree that the upstream fix [1] is
more involved, and is part of a PR [2] that requires C++20.  That's
probably okay for unstable, but I need to take a look at the reverse
dependencies before making the change.  We could accommodate more users
if the header conditionally did the right thing for c++20.

Thank you,
tony

[1] 
https://github.com/capnproto/capnproto/commit/4f8bf494bbe5491cd2ff3c809bf986162dfb7387
[2] https://github.com/capnproto/capnproto/pull/1732


signature.asc
Description: PGP signature

Bug#1052071: ITP: node-esniff -- Low footprint JavaScript source code parser

[Josenilson Ferreira da Silva]

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

* Package name: node-esniff
  Version : 1.1.0
  Upstream Contact: Mariusz Nowak 
* URL : https://github.com/medikoo/esniff
* License : MIT
  Programming Lang: javascript
  Description : Low footprint JavaScript source code parser


Tool that allows you to analyze ECMAScript (JavaScript) code efficiently
 and with low resource usage. The main objective is to examine the JavaScript
 source code for various information such as accessed properties, dependencies,
 and other code-related details.
 .
 Here are some of the key features and functionalities of the project:
  - Code Analysis: “esniff” is capable of analyzing ECMAScript source code and
providing detailed information about how the code is structured.
  - Detection of accessed properties: Can identify properties that are accessed
in the code by providing a list of the properties and their locations in the
source code.
  - Dependency Detection: The project is useful for identifying code
dependencies by telling which other modules or libraries the code
uses.
  - Efficient use of resources: "esniff" is designed to consume few resources,
making it suitable for large-scale analysis of JavaScript code
  - Compatibility: It is compatible with the ECMAScript specification and can be
used to parse modern JavaScript code.

Bug#1049413: update to 2.56

[Jeremy Bícha]

On Sat, Sep 16, 2023 at 5:26 PM Matthias Geiger  wrote:
> I would suggest to switch the upstream to the source on crates.io and
> provide the "crate data" on top.

Are you able to provide the "crate data" on top of the current librsvg
in Unstable?

Could you try patching glycin-loaders to accept librsvg 2.54? I see in
the git log that the dependency appears to have been arbitrarily set
from 2.57 to 2.56 and then back to 2.57 so maybe the dependency is
stricter than it needs to be.

Thank you,
Jeremy Bícha

Bug#1052070: bookworm-pu: package mutt/2.2.12-0.1~deb12u1

[Sebastian Andrzej Siewior]

Package: release.debian.org
Control: affects -1 + src:mutt
X-Debbugs-Cc: m...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
X-Debbugs-Cc: sebast...@breakpoint.cc
Severity: normal

This is an update mutt package as provided by upstream to version 2.2.12
which also available in unstable since 10th September.
The 2.2.x series are bug fix only releases.

The 2.2.10 release changed the message-id generation by using the base64
url-safe dictionary instead of base64 for encoding "random" characters.
The usage of the '/' character in the message-id leads to a problem with
online-archives if the message-id is part of the URL and then '/' gets
interpreted as a "folder delimiter" instead a "file". This is a real
problem for the lore archiver.

The 2.2.11 release listed only build issue on MacOS.

The 2.2.12 release listed only two "crash bugs" which were fixed
recently via the d-security.

The whole history from git:
| a60b22fe2a250 Filter U+200C in pager.
| 2f35d2fdb99de Reset header color after mutt_set_flag().
| ba5e0dc2bcadd Add doc note to MuttLisp about boolean config vars.
| d0faf2d44455b Remove reference to $mark_old inside $mail_check_recent.
| ef2abed29fe02 Fix counters for external maildir 'T' flag changes.
| 16d8ad647bd17 Move MuttLisp boolean config note.
| 7c4fa47888d0d mutt_oauth2: Print access token request message
| cecddeac3be3d base64val: Add support to decode base64 safe URL.
| 5df86199463b5 Use base64 URL safe alphabet for message id generation.
| 216dd145d41dd Improve smtp oauth authentication.
| 9f01d4ab0b8af Abort imap_fast_trash() if previously checkpointed.
| 33f8b7cee857d Update copyright notices.
| 9138232d8daa4 Update UPDATING files for 2.2.10 release.
| e0e92c31228e3 (tag: mutt-2-2-10-rel) automatic post-release commit for 
mutt-2.2.10
| 50954c4ab7408 Fix  behavior for sort=reverse-threads.
| a5423c403381e Updated Japanese translation.
| d52c6115b074d Fix GPGME build failure on MacOS.
| d619496e99899 Update UPDATING file for 2.2.11 release.
| 6b538297bc0ba (tag: mutt-2-2-11-rel) automatic post-release commit for 
mutt-2.2.11
| 7eb9c18f27d14 Add a documentation note that aliases are case insensitive.
| 452ee330e094b Fix rfc2047 base64 decoding to abort on illegal characters.
| 4cc3128abdf52 Check for NULL userhdrs.
| a4752eb0ae0a5 Fix write_one_header() illegal header check.
| 6a155b4933b4b Update UPDATING file for 2.2.12 release.
| 0a81a2a7ca2b4 (mutt-2-2-12-rel) automatic post-release commit for mutt-2.2.12

Sebastian

Bug#1049413: update to 2.56

[Matthias Geiger]

Upstream also chose to publish librsvg on crates.io [0].

This is a bit of an issue since src:librsvg in debian does not provide 
the librsvg crate. Other GNOME apps [1] started depending on the crate 
version,


which results in a build failure as the crate data is not found (this 
affects glycin-loaders and by extension loupe right now).


I could disable svg support, but since this is a common image format 
this doesn't look like a good option to me.


I would suggest to switch the upstream to the source on crates.io and 
provide the "crate data" on top.


Otherwise please find a way to provide this source code as it'll be 
needed inevitably at some point. I can package all remaining 
dependencies to fully de-vendor librsvg.


Another option would be that the rust source code for librsvg is 
provided by a src:rust-librsvg package maintained by the Rust 
maintainers (not building anything else).


Let me know what you think.

[0] https://crates.io/crates/librsvg

[1] 
https://gitlab.gnome.org/sophie-h/glycin/-/blob/main/loaders/glycin-svg/Cargo.toml?ref_type=heads#L14



--
Matthias Geiger (werdahias)
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1052063: regression: nvme drive not found after kernel upgrade from bookworm-security

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi David,

On Sat, Sep 16, 2023 at 04:42:44PM -0300, David da Silva Polverari wrote:
> Package: src:linux
> Version: 6.1.52-1
> Severity: important
> 
> Dear Maintainer(s),
> 
> After upgrading the kernel from linux-image-6.1.0-11-amd64 (6.1.38-4) to
> linux-image-6.1.0-12-amd64 (6.1.52-1) from bookworm-security on my
> laptop (a Dell XPS 9560), the kernel fails to find the nvme disk, making
> it impossible for the initrd to decrypt the drive using LUKS, and as
> such there are no boot messages. On the previous kernel it boots fine.
> With tha 6.1.0-12 kernel, dmesg shows the following:
> 
> [   42.074878] nvme nvme0: Does your device have a faulty power saving mode 
> enabled?
> [   42.074879] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 
> pcie_aspm=off" and report a bug
> [   42.120786] nvme :04:00.0: Unable to change power state from D3cold to 
> D0, device inaccessible
> [   42.121007] nvme nvme0: Removing after probe failure status: -19
> [   42.136737] nvme0n1: detected capacity change from 1000215216 to 0
> 
> When I tried using the suggested parameters, I could boot, boot soon
> afterwards the system hung. I also tried some variations, as trying
> either only nvm_core.default_ps_max_latency_us=0 or pcie_aspm=off, but
> neither one worked.
> 
> I attached the dmesg output from the laptop into this email.

Can you verify if it's this issue known upstream?

https://lore.kernel.org/regressions/5dhv0s.d0f751zf65...@gmail.com/

Does reverting the mentioned patch fix the issue?

Regards,
Salvatore

Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt

[Mathias Gibbens]

On Sun, 2023-08-06 at 15:20 +0100, Richard Lewis wrote:
> A gentle reminder on the last bit of this - getting it into bookworm
> point release. (i think i read somewhere that 12.2 would be at the
> end of august)

  ACK -- the 12.2 point release has been announced for October 7th,
with a processing freeze the weekend prior. I think we should be able
to get the changes done and proposed to the release team by the end of
next week.

>  -- let me know if there's anything i can do to help with this (i
> couldn't find anything listing what it involves!)

  The process for uploads to (old)stable is described here:
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable

  I'll contact you directly, off of this bug report so we can
coordinate.

Mathias


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

Bug#1052068: bookworm-pu: package dbus/1.14.10-1~deb12u1

[Simon McVittie]

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:dbus

[ Reason ]
New upstream bugfix release

[ Impact ]
If not accepted:
1. On kernels not supporting SO_PEERGROUPS (pre-buster or custom kernels),
   the system bus can crash if its configuration/policy is reloaded
   (ReloadConfig() or SIGHUP) while there is a connection whose associated
   groups can't be found via getgrouplist() (dbus#343 upstream). I
   would rate this as Severity: important, because it'll rarely happen
   (particularly on bookworm), but its effect is to make the system
   unusable for many workloads, notably desktop systems.

2. Relatedly, in similar situations, error reporting was wrong and the error
   message was reported as "(null)" (dbus#343 upstream).
   I would rate this as Severity: normal.

3. D-Bus clients could not retrieve the group IDs of a peer that has a
   primary group ID but no supplementary groups. (dbus!422 upstream)
   I would rate this as Severity: normal.

4. On systems with dbus-user-session but not dbus-x11, $XDG_CURRENT_DESKTOP
   was not always propagated to systemd and D-Bus user/session services,
   which will cause problems for backports of xdg-desktop-portal 1.17+
   and possibly other freedesktop-ish services, which want to use
   $XDG_CURRENT_DESKTOP to implement desktop-environment-dependent
   behaviours like having different default programs. (Debian-specific)
   I would rate this as Severity: wishlist right now, but it becomes
   Severity: important if we backport a newer version of xdg-desktop-portal.

Also, if I need to do a security update for dbus 1.14.x during bookworm's
remaining lifetime (relatively likely), it will have a smaller diffstat if
these changes are already in.

[ Tests ]
This is a straightforward backport of a version that has been in unstable
for 2 weeks and in testing for 10 days. A test-build that differs only in
the changelog and version numbering is available from:
https://people.debian.org/~smcv/12.2/pool/main/d/dbus/
and seems to work fine on my household's bookworm laptop/desktop systems.

Automated build-time tests and as-installed tests (autopkgtest) pass.

References to (1.), etc. below refer to the Impact section above:

I did some manual testing on the error handling changes (1. and 2.) during
their upstream development, by modifying the function that uses
SO_PEERGROUPS to make it always fail so that we'd fall back to the
old-kernel code path, and it behaved correctly. There is also a new
automated test which covers (2.), although it isn't sufficiently full-stack
to cover (1.).

Manual test for (3.):
With current bookworm packages, and NetworkManager installed and running
as root as it normally does,
  dbus-send --print-reply --system --dest=org.freedesktop.DBus \
/org/freedesktop/DBus org.freedesktop.DBus.GetConnectionCredentials \
string:org.freedesktop.NetworkManager
prints credentials that include ProcessID = (pid) and UnixUserID = 0.
With the proposed version, it additionally reports UnixGroupIDs = [0]
as expected.

Manual test for (4.):
In a VM with current bookworm packages, after
`apt install --no-install-recommends gdm3 xfce4 xorg; apt purge dbus-x11; 
reboot`
and logging into an XFCE session, `systemctl --user show-environment`
does not include XDG_CURRENT_DESKTOP.  After rebooting into the proposed
version, the same command's output has XDG_CURRENT_DESKTOP=XFCE as
expected.
(For this test it needs to be a desktop environment that has DesktopNames
in its xsessions file, but doesn't upload XDG_CURRENT_DESKTOP
to dbus-daemon/systemd itself, like GNOME and KDE Plasma do. XFCE and
Enlightenment make good examples)

[ Risks ]
All changes are targeted and reasonably obvious, and all except (4.) have
been through upstream review, so I think the regression risk is small.

[ 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 ]
References to (1.), etc. refer to the Impact section above.

bus/connection.c (first diff section), dbus/dbus-sysdeps-util-unix.c,
dbus/dbus-userdb.h, dbus/dbus-userdb-util.c:
Fix (2.) (dbus#343) by propagating a lower-layer error message through
the system to higher layers instead of leaving the higher-layer
error indicator unset

bus/policy.c, bus/connection.c (second diff section),
dbus/dbus-sysdeps-util-win.c:
Adapt to internal interface changes required by (1.) and (2.) by
adding a placeholder parameter where needed

bus/connection.c (the rest):
Fix the crash (1.) (dbus#343) by not leaving a NULL pointer in an
internal data structure on failure, where it would have caused a NULL
dereference and crash later on

bus/bus.c, bus/bus.h:
While fixing (1.) and (2.) (dbus#343) we realised that 

Bug#1052067: ghome-shell: CVE-2023-43090

[Salvatore Bonaccorso]

Source: gnome-shell
Version: 44.4-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6990
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gnome-shell.

CVE-2023-43090[0]:
| Screenshot tool allows viewing open windows when session is locked


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-43090
https://www.cve.org/CVERecord?id=CVE-2023-43090
[1] https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6990
[2] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2944

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1052066: awk: illegal field $(ID=debian), name "0" while upgrading to 1.9.4-2

[Julien Palard]

Package: fwupd
Version: 1.9.4-2
Severity: normal
X-Debbugs-Cc: jul...@palard.fr

Hi,

while upgrading my laptop from Bookworm to Trixie I got:

> Setting up fwupd (1.9.4-2) ...
> /usr/sbin/policy-rc.d returned 101, not running 'restart 
> fwupd-offline-update.service fwupd-refresh.service fwupd-refresh.timer 
> fwupd.service'
> awk: illegal field $(ID=debian), name "0"
>  input record number 4, file /etc/os-release
>  source line number 1
> dpkg: error processing package fwupd (--configure):
>  installed fwupd package post-installation script subprocess returned error 
> exit status 2
> Errors were encountered while processing:
>  fwupd
> E: Sub-process /usr/bin/dpkg returned an error code (1)

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
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 fwupd depends on:
ii  adduser3.137
ii  libarchive13   3.6.2-1
ii  libc6  2.37-8
ii  libcbor0.8 0.8.0-2+b1
ii  libcurl3-gnutls8.2.1-2
ii  libflashrom1   1.3.0-2.1
ii  libfwupd2  1.9.4-2
ii  libgcab-1.0-0  1.6-1
ii  libglib2.0-0   2.78.0-1
ii  libgnutls303.8.1-4+b1
ii  libgudev-1.0-0 237-2
ii  libgusb2   0.4.5-1.1
ii  libjcat1   0.1.9-1
ii  libjson-glib-1.0-0 1.6.6-1
ii  liblzma5   5.4.4-0.1
ii  libmbim-glib4  1.28.4-2
ii  libmbim-proxy  1.28.4-2
ii  libmm-glib01.20.6-2
ii  libpolkit-gobject-1-0  123-1
ii  libprotobuf-c1 1.4.1-1+b1
ii  libqmi-glib5   1.32.4-2
ii  libqmi-proxy   1.32.4-2
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.43.0-1
ii  libsystemd0254.1-3
ii  libtss2-esys-3.0.2-0   3.2.1-3
ii  libxmlb2   0.3.14-2
ii  shared-mime-info   2.2-1

Versions of packages fwupd recommends:
ii  bolt   0.9.5-1
ii  dbus   1.14.10-1
ii  fwupd-amd64-signed [fwupd-signed]  1:1.4+1
ii  jq 1.6-3
ii  python33.11.4-5+b1
pn  secureboot-db  
ii  udisks22.10.0-5

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- Configuration Files:
/etc/fwupd/redfish.conf [Errno 13] Permission non accordée: 
'/etc/fwupd/redfish.conf'

-- no debconf information

Bug#1042989: Consider switching packaging to Incus

[Mathias Gibbens]

Hi Free,

On Fri, 2023-09-15 at 13:22 +0100, Free Ekanayaka wrote:
> Hello!
> 
> as you probably know, the initial fork from:
> 
> https://github.com/cyphar/incus/
> 
> has now been moved under the LXC project:
> 
> https://github.com/lxc/incus,
> 
> and has definitely gained traction since the initial announcement,
> getting support both from the community and from LXD developers that
> have now moved to incus (myself included).

  Yes, I've been keeping an eye on Incus' development and am glad to
see it's off to a good start!

> I wanted to wait for the first official incus release before reaching
> out to Debian fellows, but since I noticed that you might be working
> on updating the LXD package I thought it be good to get in contact.

  I was also planning to wait for the first official release before
diving into packaging for Debian, as I know (at least at first) there
was a ton of churn in dependencies and the naming of binaries. But it's
never too early to start the conversation. :)

  As I've thought over things more, I think the ideal path forward
would be to have both LXD and Incus available in Debian. That will give
users the most freedom to choose what they want to install on their
systems, and if down the road either of the projects winds down we can
help them migrate to the other project as needed.

> As Debian developer myself, incus maintainer and original author of
> dqlite/libraft (which have now been forked too into the new "cowsql"
> project https://github.com/cowsql, used by incus), I'd of course love
> to see Debian switching to incus and cowsql, and in that case I'd
> like to help out with packaging and maintainership.

  Of course! The more the merrier! LXD is currently team-maintained
under the Go Team, although in practice I'm the only one performing
uploads. I would envision a similar setup for the packaging of Incus,
and would welcome your help with it.

  I haven't seen any RFP/ITPs for cowsql, go-cowsql, or the fork of
raft; are you planning to work on getting those packaged for Debian? If
not, eventually I'll get around to them. :) The only heartburn I have
is with the fork of raft -- from a quick inspection, it looks like the
package has the same name (both for the package and shared library) as
Canonical's version of raft which is already packaged. Would it be too
much work to change the name of the fork, so it would be trivial to
have co-installed versions of raft?

> Within the incus team we have discussed possible Debian-specific
> migration strategies and we'd have ideas about how to handle it, so
> users experience the least possible disruption.

  I'd certainly like to see that. Debian is tracking the LTS releases,
and it would be a good release goal for trixie to have a migration path
from LXC -> Incus for users if they wish.

> I'd like to know what are your feelings around these topics, and of
> course I understand if you prefer to just sit on the sidelines for
> now.

  Speaking strictly for myself, I'm planning to switch to Incus once it
hits a "1.0 LTS" sort of release. As such, I'll have a vested interest
in getting it into Debian. I'll be glad to collaborate with you or
anyone else who would like to work on the Debian packaging. And for the
foreseeable future I'll also keep LXD up to date with its LTS releases
for those who choose to stay with it.

Mathias


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

Bug#1052065: libcommons-compress-java: CVE-2023-42503

[Salvatore Bonaccorso]

Source: libcommons-compress-java
Version: 1.22-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libcommons-compress-java.

CVE-2023-42503[0]:
| Improper Input Validation, Uncontrolled Resource Consumption
| vulnerability in Apache Commons Compress in TAR parsing.This issue
| affects Apache Commons Compress: from 1.22 before 1.24.0.  Users are
| recommended to upgrade to version 1.24.0, which fixes the issue.  A
| third party can create a malformed TAR file by manipulating file
| modification times headers, which when parsed with Apache Commons
| Compress, will cause a denial of service issue via CPU consumption.
| In version 1.22 of Apache Commons Compress, support was added for
| file modification times with higher precision (issue # COMPRESS-612
| [1]). The format for the PAX extended headers carrying this data
| consists of two numbers separated by a period [2], indicating
| seconds and subsecond precision (for example “1647221103.5998539”).
| The impacted fields are “atime”, “ctime”, “mtime” and
| “LIBARCHIVE.creationtime”. No input validation is performed prior to
| the parsing of header values.  Parsing of these numbers uses the
| BigDecimal [3] class from the JDK which has a publicly known
| algorithmic complexity issue when doing operations on large numbers,
| causing denial of service (see issue # JDK-6560193 [4]). A third
| party can manipulate file time headers in a TAR file by placing a
| number with a very long fraction (300,000 digits) or a number with
| exponent notation (such as “9e999”) within a file modification
| time header, and the parsing of files with these headers will take
| hours instead of seconds, leading to a denial of service via
| exhaustion of CPU resources. This issue is similar to CVE-2012-2098
| [5].  [1]:  https://issues.apache.org/jira/browse/COMPRESS-612  [2]:
| https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#
| tag_20_92_13_05  [3]:
| https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html
| [4]:  https://bugs.openjdk.org/browse/JDK-6560193  [5]:
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098   Only
| applications using CompressorStreamFactory class (with auto-
| detection of file types), TarArchiveInputStream and TarFile classes
| to parse TAR files are impacted. Since this code was introduced in
| v1.22, only that version and later versions are impacted.


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-42503
https://www.cve.org/CVERecord?id=CVE-2023-42503
[1] https://lists.apache.org/thread/5xwcyr600mn074vgxq92tjssrchmc93c

Regards,
Salvatore

Bug#915583: debian sphinx styling: second attempt

[Russ Allbery]

Stéphane Blondon  writes:

> I've done a new version. It's based on 'sphinx_rtd_theme' theme. So, to
> build the site, the package 'python3-sphinx-rtd-theme' requires to be
> added to dependencies. A new file 'debian.css' is specific to set some
> colors and renderings.

> Reusing 'Read the docs' theme allows to have a responsive design
> automatically.

> The theme could be modified more but it could be considered as a first
> step which is already usable.

> There are temporary demos available:
>  - for debian-policy: http://stephane.yaal.fr/tmp/policy/
>  - for (draft sphinx) release-notes: 
> http://stephane.yaal.fr/tmp/release-notes/

> What do you think about it?

Hi Stéphane,

Thank you so much for this!  I poked around a little bit on your draft
render of Policy and personally I'm quite happy with it.  The sidebar
management with small screens seemed to work for me and is definitely
better that what we have right now.  I would encourage others to also take
a look and provide feedback.  My inclination is to merge this in a future
release of Policy.

The one minor thing that I noticed was that the version number of Policy
in the left sidebar at the top is very difficult to read because it's
almost the same color as the background.

-- 
Russ Allbery (r...@debian.org)  

Bug#1051371: Post-/usr-merge paths for script interpreters

[Russ Allbery]

Bill Allombert  writes:

> One of the issue in the past is that reproducible build was broken
> because different build environment lead to different paths. We at least
> need to address that.

I believe the reproducible build problem specifically will be largely
fixed by /usr-merging the buildds so that they look like all other Debian
systems.  I suspect the problems that you ran into in the past were
precisely because some systems on which the package was built were
/usr-merged and others were not.  But you make a good point that just
because the /bin and /usr/bin paths both work does not mean that package
build systems can pick randomly between them, since that undermines build
reproducibility.  They need to pick one or the other consistently.

I do think packages should be allowed to do a PATH search, and it's up to
the people doing a reproducible build to make sure the PATH stays
consistent from one build to the next.

-- 
Russ Allbery (r...@debian.org)  

Bug#1051371: Post-/usr-merge paths for script interpreters

[Russ Allbery]

Sam Hartman  writes:

> My problem with (b) is that I value interfaces and that especially for
> /bin/sh I do think that /bin/sh is more portable as an interface path
> than /usr/bin/sh.

To be clear, I personally agree with this, and I am sure that I will use
/bin/sh until the end of time, even if every extant UNIX system decides to
create a /usr/bin/sh alias for it (one way or the other).

But from an interface perspective, I think it adds some clarity to think
of it this way: When people started merging /bin and /usr/bin, they added
a new /usr/bin/sh interface for invoking the Bourne shell.  They may not
have intended to do this, but that's what they did, and there was nothing
inherent in the system to prevent people from using that interface.  So
people started doing so.

I'm sure that I'm not the only one who has encountered #!/usr/bin/sh
scripts in the wild, usually because the person who wrote the script was
using some Red Hat or Fedora distribution and didn't really think about
it.  Either they were used to the /usr/bin pattern from Perl and Python or
they ran "which sh" and, as Bill points out, that returns /usr/bin/sh,
etc.  Up until now, those scripts didn't work on Debian systems, which
caused some minor annoyances.  Now they do.

What has essentially happened given the number of distributions that have
done /usr-merge is that Linux has added /usr/bin/sh as a new interface
that is interchangeable with /bin/sh, and now nearly every current Linux
system you run across will also support that interface.  This is annoying
for UNIXes that don't support that interface (I don't know what the BSDs
are doing, for instance), but it's fairly invisible to users unless they
care about portability to non-Linux systems.  I care about portability to
non-Linux systems in at least some situations, but a lot of people don't.

(Incidentally, this interface argument is also why I have some nit-picks
about the wording of Luca's proposed patch, because the guarantees in
Policy apply specifically to /bin/sh and /usr/bin/sh, not to, say,
/usr/local/bin/sh or /usr/xpg4/bin/sh or whatever.  This is an admittedly
very minor point.)

> I care a lot that we use /bin/sh in our documentation and examples
> (especially in policy).

I agree with this.  If we write example scripts, I think they should use
#!/bin/sh.  I don't think my (b) proposal is arguing against that; (b)
says that both paths work and you can use either of them, and Policy will
chose to use /bin/sh at least for the time being because, well, I'm one of
the Policy Editors and I care about things like that.  :)  I think Policy
would only use /usr/bin/sh in documentation and examples if we adopted
(c), which based on the discussion so far seems unlikely.

> I care a lot that we point out that the reality of the situation is
> people will see other paths.

This is the part that I'm really focusing on at the moment, because I
think it's what people are really asking and what directly addresses the
concern about bug reports asking maintainers to switch from /usr/bin/sh to
/bin/sh.  If Debian is going to contain scripts that use /usr/bin/sh, this
is a change and we should say so explicitly.

Bill pointed out precisely the way that I expect this to happen: a lot of
packages use PATH searches in their build systems to find common tools,
and although I think this is ill-advised, some of them do that for sh
(mostly because of old Solaris breakage).  As soon as the buildds are
/usr-merged, those packages are going to start using /usr/bin/sh instead
of /bin/sh because it's first in the PATH, assuming the buildds use the
same PATH setup as /etc/login.defs (I don't know if this is the case).
And the question is do we tell maintainers that they should fix this, or
do we accept that it will happen and not worry about it?

I personally probably would find a way to force /bin/sh somewhere because
I am a perfectionist, but it requires overriding the upstream build system
and maintaining that code going forward and a lot of maintainers aren't
going to want to bother.  I think Policy should provide some guidance to
both maintainers and bug reporters here about what we expect.

> At least for things traditionally in /bin I do not want to encourage
> those other paths, but I also don't think it is often a good use of
> project resources to "fix" those other paths.

Precisely.  To me, that's the heart of the (b) position, although people
advocating for (b) are going to vary from "prefer /bin" to "prefer
/usr/bin" and (b) is sort of inherently a compromise position about what
we're going to *do* among people who have different preferences about
style.

> In some cases (for example what version of a path autoconf detects), I
> think that patching individual packages to detect a particular path
> would be net harmful.

Yeah, it sounds like you're thinking of exactly the case I was thinking
of.

> So I want to argue for (a) with no enforcement mechanism in packages.

> 1) Policy should 

Bug#1052055: Webkit output fully white

[Alberto Garcia]

On Sat, Sep 16, 2023 at 06:29:52PM +0200, R Pi wrote:

> KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
> Failed to create GBM buffer of size 1024x741: Permission denied

Hello and thanks for the bug report.

What happens if you set WEBKIT_DISABLE_DMABUF_RENDERER=1 in
the environment? If it works, does it also work if you set
WEBKIT_DMABUF_RENDERER_DISABLE_GBM=1 instead?

Also, please try with the MiniBrowser (with and without that variable)
to see if it makes a difference.

   /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser
   /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser
   /usr/lib/x86_64-linux-gnu/webkitgtk-6.0/MiniBrowser

The first two should behave the same, I'm curious if there's a
difference with the third one.

Thanks!

Berto

Bug#931591: upgraded Handbrake crashes on encode with custom preset

[Harald Dunkel]

Got the same since the upgrade from 1.6.1+ds1-1 to 1.6.1+ds1-2 (Sid).
If I use a built-in preset there is no such problem.

Regards
Harri

Bug#1050001: Bug#1051371: Post-/usr-merge paths for script interpreters

[Russ Allbery]

Control: unblock 1051371 by 1050001

Ansgar  writes:

> However, there is a proposal by Jackson for an alternative filesystem
> layout based on symlink farms in consideration by the technical
> committee.  This advocates removing compat symlinks in /bin, /sbin over
> time[1], thus requiring (c).

This is not a correct summary of Ian's proposal.  In the message that you
linked, Ian says:

/bin and /lib etc. remain directories (so there is no aliasing).  All
actual files are shipped in /usr.  / contains compatibility symlinks
pointing into /usr, for those files/APIs/programs where this is needed
(which is far from all of them).  Eventualloy, over time, the set of
compatibility links is reduced to a mere handful.

I am absolutely certain that Ian would consider /bin/sh to be one of the
programs for which a compatibility symlink is needed, and one of the
remaining handful of links that would exist indefinitely into the future.
Indeed, he mentions /bin/sh explicitly later in that message.

Given that, I believe Ian's proposal is orthogonal to this bug.  For
/bin/sh and /usr/bin/sh, it would create the same aliasing and thus would
create the same question about how to talk about those paths in Policy.  I
therefore don't think resolution of this bug blocks on the TC bug.

-- 
Russ Allbery (r...@debian.org)  

Bug#1052063: regression: nvme drive not found after kernel upgrade from bookworm-security

[David da Silva Polverari]

Package: src:linux
Version: 6.1.52-1
Severity: important

Dear Maintainer(s),

After upgrading the kernel from linux-image-6.1.0-11-amd64 (6.1.38-4) to
linux-image-6.1.0-12-amd64 (6.1.52-1) from bookworm-security on my
laptop (a Dell XPS 9560), the kernel fails to find the nvme disk, making
it impossible for the initrd to decrypt the drive using LUKS, and as
such there are no boot messages. On the previous kernel it boots fine.
With tha 6.1.0-12 kernel, dmesg shows the following:

[   42.074878] nvme nvme0: Does your device have a faulty power saving mode 
enabled?
[   42.074879] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 
pcie_aspm=off" and report a bug
[   42.120786] nvme :04:00.0: Unable to change power state from D3cold to 
D0, device inaccessible
[   42.121007] nvme nvme0: Removing after probe failure status: -19
[   42.136737] nvme0n1: detected capacity change from 1000215216 to 0

When I tried using the suggested parameters, I could boot, boot soon
afterwards the system hung. I also tried some variations, as trying
either only nvm_core.default_ps_max_latency_us=0 or pcie_aspm=off, but
neither one worked.

I attached the dmesg output from the laptop into this email.

Regards,
David
[0.00] microcode: microcode updated early to revision 0xf4, date = 
2023-02-23
[0.00] Linux version 6.1.0-12-amd64 (debian-ker...@lists.debian.org) 
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 
SMP PREEMPT_DYNAMIC Debian 6.1.52-1 (2023-09-07)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-6.1.0-12-amd64 
root=/dev/mapper/mercurius--vg-root ro acpi_rev_override=1 mitigations=off quiet
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x6a305fff] usable
[0.00] BIOS-e820: [mem 0x6a306000-0x6a306fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x6a307000-0x6a307fff] reserved
[0.00] BIOS-e820: [mem 0x6a308000-0x7838dfff] usable
[0.00] BIOS-e820: [mem 0x7838e000-0x7874afff] reserved
[0.00] BIOS-e820: [mem 0x7874b000-0x78791fff] ACPI data
[0.00] BIOS-e820: [mem 0x78792000-0x78e85fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x78e86000-0x7951] reserved
[0.00] BIOS-e820: [mem 0x7952-0x795fefff] type 20
[0.00] BIOS-e820: [mem 0x795ff000-0x795f] usable
[0.00] BIOS-e820: [mem 0x7960-0x7f7f] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf7ff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00047e7f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.40 by American Megatrends
[0.00] efi: ACPI=0x7875a000 ACPI 2.0=0x7875a000 SMBIOS=0x79367000 
SMBIOS 3.0=0x79366000 TPMFinalLog=0x78b27000 ESRT=0x792bd198 MEMATTR=0x75be0018 
MOKvar=0x79363000 
[0.00] secureboot: Secure boot disabled
[0.00] SMBIOS 3.0.0 present.
[0.00] DMI: Dell Inc. XPS 15 9560/05FFDN, BIOS 1.28.0 03/23/2022
[0.00] tsc: Detected 2800.000 MHz processor
[0.00] tsc: Detected 2799.927 MHz TSC
[0.000717] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.000720] e820: remove [mem 0x000a-0x000f] usable
[0.000730] last_pfn = 0x47e800 max_arch_pfn = 0x4
[0.000844] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.001398] last_pfn = 0x79600 max_arch_pfn = 0x4
[0.009942] found SMP MP-table at [mem 0x000fced0-0x000fcedf]
[0.009956] esrt: Reserving ESRT space from 0x792bd198 to 
0x792bd1d0.
[0.009966] Kernel/User page tables isolation: disabled on command line.
[0.009967] Using GB pages for direct mapping
[0.010344] RAMDISK: [mem 0x304b3000-0x34250fff]
[0.010349] ACPI: Early table checksum verification disabled
[0.010352] ACPI: RSDP 0x7875A000 24 (v02 DELL  )
[0.010356] ACPI: XSDT 0x7875A0D0 00011C (v01 DELL   CBX3 
01072009 AMI  00010013)
[0.010361] ACPI: FACP 0x7877FA78 00010C (v05 DELL   CBX3 
01072009 AMI  00010013)
[0.010366] ACPI: DSDT 0x7875A278 0257FF (v02 DELL   CBX3 
01072009 INTL 20160422)
[

Bug#1038243: unbound: error log flooding when unbound is configured with a DNS over TLS upstream server

[Timo Sigurdsson]

Dear maintainers,

could you please also backport the fix for this issue to the current stable 
distribution via the proposed-updates channel? The next point release for 
bookworm is scheduled for October 7. I really hope the fix for this annoying 
issue makes it into the next point release.

Thank you and kind regards,

Timo

Bug#1050928: enlightenment-data: please provide an enlightenment-portals.conf for xdg-desktop-portal

[Ross Vandegrift]

Hi Simon,

On Sat, Sep 16, 2023 at 07:37:31PM +0100, Simon McVittie wrote:
> On Sat, 16 Sep 2023 at 08:54:11 -0700, Ross Vandegrift wrote:
> > That's correct - but I'm afraid this is the only item in this bug report 
> > that I
> > understand.  I tried to read the documentation you linked, but both assume
> > general familiarity with what's going on here.  For me, this all might as 
> > well
> > be greek.
> 
> Sorry, I'm doing my best to strike a balance between "wall of text" and
> being clear.
> 
> Adapted from an issue report I sent upstream in Xfce,
> https://gitlab.xfce.org/xfce/xfce4-session/-/issues/181, which they seem
> to have found useful:

That was incredibly helpful.  I think I'm clear on what needs to be done now,
and should be able to tackle it soon.

Also, thanks a million for helping me understand the big picture and providing
references to useful tools.  It's very kind of you!

Ross

Bug#1052062: plasma-desktop: Tab order of Application tab within an application's .desktop file is incorrect

[JT Hundley]

Package: plasma-desktop
Version: 4:5.27.5-2
Severity: minor
Tags: a11y upstream

Dear Maintainer,

Steps to reproduce:
1. Right click on any .desktop file and select properties.
2. Click the Application tab at the top.
3. Press tab to cycle through the available LineEdit fields.
4. Observe that the order is Application tab, Name, Description,
Comment, Environment Variables, Program, Browse button, Work path,
browse work path button, Arguments.

The order is from top to bottom with the exception of Arguments being
skipped and then added last. The order should be completely top to
bottom. The end of the current order should be Program browse button,
Arguments, Work path, browse Work path button instead.

I'm pretty sure this is an upstream issue as it's also present in KDE
version 5.27.8 on EndeavorOS. Thank you for your time and hard work
making Debian badass. I apologize if this isn't the right package to
report this in.

-- 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/12 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 plasma-desktop depends on:
ii  accountsservice  22.08.8-6
ii  breeze   4:5.27.5-2
ii  kactivitymanagerd5.27.5-2
ii  kde-cli-tools4:5.27.5.1-2
ii  kded55.103.0-1
ii  kio  5.103.0-1
ii  kpackagetool55.103.0-1
ii  layer-shell-qt   5.27.5-2
ii  libaccounts-qt5-11.16-2
ii  libc62.36-9+deb12u1
ii  libglib2.0-0 2.74.6-2
ii  libibus-1.0-51.5.27-5
ii  libkaccounts24:22.12.3-1
ii  libkf5activities55.103.0-1
ii  libkf5activitiesstats1   5.103.0-1
ii  libkf5authcore5  5.103.0-1
ii  libkf5baloo5 5.103.0-2
ii  libkf5bookmarks5 5.103.0-1
ii  libkf5codecs55.103.0-1
ii  libkf5completion55.103.0-1
ii  libkf5configcore55.103.0-2
ii  libkf5configgui5 5.103.0-2
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5globalaccel-bin5.103.0-1
ii  libkf5globalaccel5   5.103.0-1
ii  libkf5guiaddons5 5.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5itemviews5 5.103.0-1
ii  libkf5jobwidgets55.103.0-1
ii  libkf5kcmutils5  5.103.0-3
ii  libkf5kcmutilscore5  5.103.0-3
ii  libkf5kdelibs4support5   5.103.0-1
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5kiowidgets55.103.0-1
ii  libkf5newstuffcore5  5.103.0-1
ii  libkf5notifications5 5.103.0-1
ii  libkf5notifyconfig5  5.103.0-1
ii  libkf5package5   5.103.0-1
ii  libkf5plasma55.103.0-1
ii  libkf5plasmaquick5   5.103.0-1
ii  libkf5quickaddons5   5.103.0-1
ii  libkf5runner55.103.0-1
ii  libkf5service-bin5.103.0-1
ii  libkf5service5   5.103.0-1
ii  libkf5solid5 5.103.0-1
ii  libkf5sonnetcore55.103.0-1
ii  libkf5sonnetui5  5.103.0-1
ii  libkf5widgetsaddons5 5.103.0-1
ii  libkf5windowsystem5  5.103.0-1
ii  libkf5xmlgui55.103.0-1
ii  libkworkspace5-5 4:5.27.5-2
ii  libnotificationmanager1  4:5.27.5-2
ii  libpackagekitqt5-1   1.1.1-1
ii  libphonon4qt5-4  4:4.11.1-4
ii  libprocesscore9  4:5.27.5-2
ii  libqt5concurrent55.15.8+dfsg-11
ii  libqt5core5a 5.15.8+dfsg-11
ii  libqt5dbus5  5.15.8+dfsg-11
ii  libqt5gui5   

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

[tony mancill]

On Mon, Sep 04, 2023 at 12:07:49PM -0700, tony mancill wrote:
> 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.

After successful testing with this version on trixie/unstable, I have
uploaded 2.7.0~rc2 to unstable and updated the default branch in the
Salsa repo to debian/latest.

As always, thank you for filing bug reports and suggestions.

Perhaps of interest to WSJT-X users is this recent thread [1] on
wsjt-devel regarding new functionality added to PSKReporter for the
upcoming solar eclipse [2].

Cheers,
tony

https://sourceforge.net/p/wsjt/mailman/message/37896251/
https://solarsystem.nasa.gov/eclipses/2023/oct-14-annular/where-when/


signature.asc
Description: PGP signature

Bug#1052061: mrtg: [INTL:nl] Dutch translation of debconf templates

[Frans Spiesschaert]

 
 
Package: mrtg 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of mrtg debconf
messages. A draft has been posted to the debian-l10n-dutch mailing list
allowing for review. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1052060: gkrellm: 'Homepage' in 'd/control' is a holding page.

[Phil Wyett]

Package: gkrellm
Version: 2.3.11-2

'Homepage' in 'd/control' is a holding page.

Looks like the main site for the package is the base address in
'd/watch' i.e. http://gkrellm.srcbox.net

This should maybe the link in 'd/control' going forward.

May also be an idea to mention to upstream that supporting HTTPS would
be a benefit.

Regards

Phil

-- 
Playing the game for the games sake.

* Debian Maintainer

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org

Social:

* Twitter: kathenasorg
* Instagram: kathenasorg




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

Bug#1052059: roundcube: Please apply security fix from 1.6.3

[Martin Dosch]

Package: roundcube
Severity: normal
Tags: upstream

Dear Maintainer,

upstream released version 1.6.3 which fixes a security issue with the 
1.6.x and I kindly ask you to apply the fix for the version in debian 
stable.

https://roundcube.net/news/2023/09/15/security-update-1.6.3-released

Best regards,
Martin

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

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

Versions of packages roundcube depends on:
ii  dpkg1.21.22
pn  roundcube-core  

roundcube recommends no packages.

roundcube suggests no packages.


signature.asc
Description: PGP signature

Bug#1050928: enlightenment-data: please provide an enlightenment-portals.conf for xdg-desktop-portal

[Simon McVittie]

On Sat, 16 Sep 2023 at 08:54:11 -0700, Ross Vandegrift wrote:
> That's correct - but I'm afraid this is the only item in this bug report that 
> I
> understand.  I tried to read the documentation you linked, but both assume
> general familiarity with what's going on here.  For me, this all might as well
> be greek.

Sorry, I'm doing my best to strike a balance between "wall of text" and
being clear.

Adapted from an issue report I sent upstream in Xfce,
https://gitlab.xfce.org/xfce/xfce4-session/-/issues/181, which they seem
to have found useful:

xdg-desktop-portal is a D-Bus service providing access to
desktop-environment-related functionality for applications. It was
originally written to provide sandboxed apps (Flatpak, Snap, etc.) with
limited access to resources outside their sandbox with user consent, but
is increasingly also used by non-sandboxed apps (.deb or equivalent), as a
desktop-environment-independent interface to features like screen-sharing
that are otherwise difficult to implement in a cross-desktop way.

Another highly visible use of xdg-desktop-portal is that non-sandboxed
apps are starting to use it as a way to get "native" File -> Open
and File -> Save As... dialogs that blend in nicely with whatever is
conventional in a particular desktop environment, like using GTK when
running GNOME/Xfce/etc., but using Qt in KDE.

x-d-p itself does not contain any desktop-environment-specific code,
and is shared between all desktop environments. However, a lot of what
it does requires use of desktop-environment-specific mechanisms or user
interface conventions. To allow for that, it contacts a desktop-specific
backend (x-d-p-gtk, x-d-p-gnome, x-d-p-kde and so on) and uses that to
provide its full functionality.

The request here is for Enlightenment to nominate one or more of the
available backends as "please use these if available, in this priority
order", so that the maintainer of x-d-p (me) isn't responsible for
guessing what user interface a typical Enlightenment user would usually
want to see (on the basis that I don't use Enlightenment myself, so my
guesses will not be as good as yours).

If none of the available backends are particularly suitable (which I
suspect they're not, unless Enlightenment developers have written one that
I couldn't find), then the one that tends to be used as a user interface
of last resort is xdg-desktop-portal-gtk, which uses GTK user interfaces
for things like file chooser dialogs and permission requests, and just
doesn't implement desktop-environment-specific interfaces like
screencasting and setting wallpaper. The way to set that up would be
this file:

# /usr/share/xdg-desktop-portal/enlightenment-portals.conf
[preferred]
default=gtk;

At the moment, x-d-p is hard-coded to do the equivalent of that as
a fallback when run under a desktop with no specific configuration,
but that's a Debian-specific patch which upstream are unlikely to
accept, so I don't want to keep that forever (I'm discussing options
with them). Providing enlightenment-portals.conf will future-proof
enlightenment against that fallback changing.

If Enlightenment is moving towards Wayland (which it seems is currently
an experimental feature) then its upstream developers will presumably
start providing its own portal backend at some point, to give apps a way
to ask permission for privacy-impacting things (like screen recording)
that are silently allowed for all apps under X11, but not generally
possible under Wayland without going via either something like x-d-p,
or a desktop-environment-specific private interface.

> I don't know of any portal requirements for Enlightenment, but I'm not really
> clear whether or not that's what you're asking for.

This is not about whether Enlightenment itself wants to use portals
(it probably doesn't). Instead, the question is: when non-Enlightenment
apps like Chromium that you run under Enlightenment ask to use a portal,
which backend is used to implement that?

> How would I test a change that implemented what you're requesting?

A way to test this while using only Debian main would be to install:

libportal-tests-gtk3 xdg-desktop-portal xdg-desktop-portal-gtk

and run, in separate terminals:

/usr/libexec/xdg-desktop-portal --verbose --replace

GTK_USE_PORTAL=1 portal-test-gtk3

Normally xdg-desktop-portal is started by D-Bus activation and sends
some limited logging to the systemd Journal, but running it with
--verbose --replace lets you see some more of what it's thinking.

portal-test-gtk3 is a simple GTK app that talks to various portal
interfaces (File -> Open dialog, File -> Save As... dialog, sending a
notification, taking a screenshot, asking to be allowed to run in the
background, and so on) as a stand-in for a real, useful application for
testing purposes.

If it's working correctly, then xdg-desktop-portal shouldn't log any
warnings about missing portals.conf files during startup, and at least
these interfaces should work:

- file 

Bug#1052058: apt: refuses to downgrade itself to a version that works on the system

[Adam Borowski]

Package: apt
Version: 2.7.5
Severity: important


Once again we have a package that some people consider broken.  That's
natural, disagreements happen.  That apt insists on a bad scheme not
supported by dpkg has been said about elsewhere.  Normally, that would
be solvable by a simple downgrade.

Except, in this case, apt refuses to do this:

# apt install apt=2.7.3 apt-utils=2.7.3
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  apt-doc
The following packages will be DOWNGRADED:
  apt apt-utils
0 upgraded, 0 newly installed, 2 downgraded, 0 to remove and 2 not upgraded.
E: /bin resolved to a different inode than /usr/bin
E: Unmerged usr is no longer supported, install usrmerge to continue.
N: See 
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#a-merged-usr-is-now-required
 for more details.

As you can see, the action I requested specifically solves the problem,
yet apt considers it no good.  Thus, I'd need to take steps that are not
obvious to a regular user, and for this specific package risky to break the
system if done wrong.

Thus, apt should consider an operation that touches apt itself to be
another exception for the usrmerge demand.


Meow!
-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "lz4";
APT::Compressor::lz4::Cost "50";
APT::Compressor::lz4::CompressArg "";
APT::Compressor::lz4::CompressArg:: "-1";
APT::Compressor::lz4::UncompressArg "";
APT::Compressor::lz4::UncompressArg:: "-d";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc 

Bug#1037909: yubioath-desktop: ftbfs with GCC-13

[Jonathan Bergh]

Control: tags -1 + patch

Fixes 1037909 due to upgrade with gcc-13


patch1.debdiff
Description: Binary data

Bug#1037903: xrt: ftbfs with GCC-13

[Jonathan Bergh]

Control: tags -1 + patch

Fixes 1037903 due to upgrade to gcc-13


patch1.debdiff
Description: Binary data

Bug#1052057: ITP: golang-github-dsnet-compress -- Collection of compression related Go packages.

[Nisha Pariyar]

Package: wnpp
Severity: wishlist
Owner: Nisha Pariyar 

* Package name: golang-github-dsnet-compress
  Version : 0.0.1-1
  Upstream Author : Joe Tsai
* URL : https://github.com/dsnet/compress
* License : BSD-3-clause
  Programming Lang: Go
  Description : Compression-related libraries for Go (library)
  This package provides a collection of compression-related libraries
  for Go.
  The goal of this project is to offer pure Go implementations for
  popular
  compression algorithms beyond what the Go standard library provides.
  .
  It includes packages for various compression formats, including
  Brotli, BZip2, DEFLATE, and XFLATE.


OpenPGP_0xD81FCFF8BFC3A65B.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1052006: linux-image-6.5.0-1-amd64 breaks X on amd GPU

[Klaus Ethgen]

Hi,

Am Sa den 16. Sep 2023 um 10:58 schrieb Bastian Blank:
> On Fri, Sep 15, 2023 at 10:18:55PM +0100, Klaus Ethgen wrote:
> > Booting with the new kernel makes the display (1920x1200) heavily
> > flckering, diplaying two times the same one above the other and only
> > displaying about 1/4 of the screen smashed together on the left border
> > of the screen.
> 
> Does it work with native resolution?  Does it work with Wayland?

With the native resolution it works. And also with scaling. But it is
hard to do the switch and the scaling. First due to the dsplaced display
and second due to the tiny size. Thanks to xterm having font size
Enormous.

> > Note that the broken setup has 3 lines of 3840x2400, althogh I use
> > 1920x1200 as resolution.
> 
> With different refresh frequencies, so nothing uncommon.

Well, yes, but not for a eDP, which has a single and only refresh rate.
All others are broken and yould, in the worst case, destroy the display
panel.

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1052021: nftables 1.0.6-2+deb12u2 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nftables
Version: 1.0.6-2+deb12u2

Explanation: fix incorrect bytecode generation hit with new kernel check that 
rejects adding rules to bound chains

Bug#1051937: cairosvg 2.5.0-1.1+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1051937 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: cairosvg
Version: 2.5.0-1.1+deb11u2

Explanation: handle data: URLs in safe mode

Bug#1051936: cairosvg 2.5.2-1.1+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: cairosvg
Version: 2.5.2-1.1+deb12u1

Explanation: handle data: URLs in safe mode

Bug#1051884: openssl 1.1.1w-0~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1051884 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: openssl
Version: 1.1.1w-0~deb11u1

Explanation: new upstream stable release

Bug#1051580: gtk+3.0 3.24.38-2~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: gtk+3.0
Version: 3.24.38-2~deb12u1

Explanation: new upstream stable release; fix several crashes; show more 
information in the "inspector" debugging interface; silence GFileInfo warnings 
if used with a backported version of GLib; use a light colour for the caret in 
dark themes, making it much easier to see in some apps, in particular Evince

Bug#1051578: gtk4 4.8.3+ds-2+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: gtk4
Version: 4.8.3+ds-2+deb12u1

Explanation: fix truncation in places sidebar with large text accessibility 
setting

Bug#1051576: gjs 1.74.2-1+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: gjs
Version: 1.74.2-1+deb12u1

Explanation: avoid infinite loops of idle callbacks if an idle handler is 
called during GC

Bug#1051569: brltty 6.5-7+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: brltty
Version: 6.5-7+deb12u1

Explanation: xbrlapi: Do not try to start brltty with ba+a2 when unavailable; 
fix cursor routing and braille panning in Orca when xbrlapi is installed but 
the a2 screen driver is not

Bug#1051545: systemd 252.16-1~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: systemd
Version: 252.16-1~deb12u1

Explanation: new upstream stable release

Bug#1050722: runit-services 0.5.5~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: runit-services
Version: 0.5.5~deb12u1

Explanation: dhclient: don't hardcode use of eth1

Bug#1052027: bullseye-pu: package cargo-mozilla/0.66.0+ds1-1~deb11u1

[Emilio Pozuelo Monfort]

On 16/09/2023 18:01, Adam D. Barratt wrote:

Control: tags -1 + confirmed

On Sat, 2023-09-16 at 11:15 +0200, Emilio Pozuelo Monfort wrote:

Following up on #1051051, this updates cargo-mozilla for the upcoming
Firefox ESR 115. Just like for rustc-mozilla, the risk here is small
as this package is only used to build firefox-esr and thunderbird.

I have used the resulting package to successfully build and test
firefox-esr 115.0.2 on bullseye.



Please go ahead.


Uploaded.

Cheers,
Emilio

Bug#1050359: RM: gpr -- RoQA; dead upstream; depends on gtk2

[Till Kamppeter]

gpr is not only not upstream-maintained any more and depending oon the 
obsolete GTK2, it is also only used for printing with LPD/gnulpr/LPRng, 
all these being printing systems which are obsolete for near 2 decades 
(replaced by CUPS) and all not maintained upstream any more.


So it does not actually make sense any more to keep gpr in Debian. So I 
am in favor of its removal, too.

Bug#1052056: Intent To Remove: src:libppd

[Christoph Biedl]

Source: libppd
Version: 2:0.10-9
Severity: important
X-Debbugs-Cc: g...@packages.debian.org, debian.a...@manchmal.in-ulm.de, 
till.kamppe...@gmail.com

The libppd package is very old software with little use (maximum popcon
is 148 for libppd0). As far as I understand, it was created by taking
bits from a (today horribly outdated) version of CUPS, added some value
and called it a day.

Years passed, and among other annoyances, there is now a package name
clash on libppd-dev, it could be provided by CUPS as well, and already
does in Ubuntu.

To resolve that problem I tried renaming the binary packages to
something with a "legacy" in it, after some discussion with Till
Kamppeter (CC'id) - that approach however wasn't quite well received. So
instead I now intent to remove src:libppd entirely, I doubt it will be a
great loss.

The last reverse dependency of libppd is gpr (Cc'ed) which doesn't quite
have a huge popcon counter either and is about to be removed sooner or
later for depending on gtk2, see https://bugs.debian.org/1050359

If you have objections, please voice them now. Current plan is to file
the RM in about a week.

Christoph, maintainer of src:libppd



signature.asc
Description: PGP signature

Bug#1036731: python3-debian: fails to parse some debian/control.in files

[Niels Thykier]

Control: reassign -1 devscripts

Hi,

The RTS parser can already cope with non-deb822 input. However, the 
caller has to opt-in to it and wrap-and-sort never that that.


I am doing a patch for this to have wrap-and-sort cope with invalid 
syntactical input.  It will come with degradation of features - notably, 
the package sorting will be disabled as otherwise we risk moving a 
paragraph out of a templated section (and if that templated section is a 
for-loop, you now get a completely different result).


To my knowledge, there is nothing for `python3-debian` to do at the 
moment. Reassigning to devscripts for doing the patch.


Best regards,
Niels

Bug#1042377: Investigation results

[corubba]

Hello,

since v0.99.2 (more specifically commit b68375fd [0]) clamd supports using 
sockets it gets passed as file descriptors. If it gets passed at least one 
socket this way, only those are used and all LocalSocket and TCPSocket 
statements from the config file are ignored. Unfortunately there seems to be no 
mention of this behaviour anywhere in the docs, I found it only by looking at 
the source code.

In bullseye [1] the clamav-daemon package only contains a clamav-daemon.service 
unit-file, in bookworm in addition to the service unit-file it also contains a 
clamav-daemon.socket unit-file. According to the systemd.service man-page [3] a 
service process automatically gets passed the sockets from all same-named 
socket units. Because in bullseye there was no socket unit, clamd didn't get 
passed any sockets from systemd and the statements from the config file were 
used. In bookworm clamd always gets passed a local socket from systemd because 
of the socket unit, and the config statements are ignored.

The workaround/solution I found is to create a drop-in for the socket unit (see 
below), letting systemd open the tcp socket and pass it to clamd. In fact, the 
socket unit-file from upstream [4] already contains a commented-out version of 
this. See the respective man-page [5] for more details about the syntax and 
e.g. how to bind to a specific ip address. I would also recommend to removed 
any socket configuration from clamd.conf to avoid confusion.

/etc/systemd/system/clamav-daemon.socket.d/tcp-socket.conf
```
[Socket]
ListenStream=3310
```

Alternatively you can mask the socket unit (and remove the Requires= from the 
service unit), which bypasses the whole systemd-socket-business and makes clamd 
behave like in bullseye, opening its own sockets according to its config file.


[0] 
https://github.com/Cisco-Talos/clamav/commit/b68375fdbb173b7652bf3b58b5e801906f587a25
[1] https://packages.debian.org/bullseye/amd64/clamav-daemon/filelist
[2] https://packages.debian.org/bookworm/amd64/clamav-daemon/filelist
[3] 
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Sockets=
[4] 
https://github.com/Cisco-Talos/clamav/blob/clamav-1.0.1/clamd/clamav-daemon.socket.in#L10
[5] 
https://www.freedesktop.org/software/systemd/man/systemd.socket.html#ListenStream=


---
Greetings

Corubba

Bug#1052006: linux-image-6.5.0-1-amd64 breaks X on amd GPU

[Klaus Ethgen]

Am Sa den 16. Sep 2023 um 10:58 schrieb Bastian Blank:
> On Fri, Sep 15, 2023 at 10:18:55PM +0100, Klaus Ethgen wrote:
> > Booting with the new kernel makes the display (1920x1200) heavily
> > flckering, diplaying two times the same one above the other and only
> > displaying about 1/4 of the screen smashed together on the left border
> > of the screen.
> 
> Does it work with native resolution?  Does it work with Wayland?

Well, I do not know about wayland as that never worked for me.

And with native resolution, I don't think so but it is dificult to test
as the display is so limited to select an other resolution. But I will
try if I can handle that.

> > Note that the broken setup has 3 lines of 3840x2400, althogh I use
> > 1920x1200 as resolution.
> 
> With different refresh frequencies, so nothing uncommon.

True. Although that are the differences to the older and working kernel.

> > 3840x2400 is no usable resolution as the display content is much to
> > small to be usable.
> 
> That's why we now have scaling and don't need to play with resolutions.

Well, we had that discussion the last time to when it came out that it
was a regression in kernel.

It pretty much looks like this time again.

And more over, the valid resolutions need to work.

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1050083: shotwell: crash in folders_sidebar_entry_construct

[Patrice Duroux]

Hi,

Since I have tried to clean-up all the shotwell conf, cache data, etc, and I am 
still getting
a crash with now the following stack trace (from coredumpctl):

Stack trace of thread 12774:
#0  0x7fd170bddfe4 __GI___wcscoll_l (libc.so.6 + 0xb9fe4)
#1  0x7fd171fddaaf g_utf8_collate (libglib-2.0.so.0 + 
0x93aaf)
#2  0x55b258aaabf7 __lambda12_ (shotwell + 0x210bf7)
#3  0x7fd171edfb46 gee_tim_sort_lower_than (libgee-0.8.so.2 
+ 0x68b46)
#4  0x7fd171ee0321 gee_tim_sort_do_sort (libgee-0.8.so.2 + 
0x69321)
#5  0x7fd171ec7f2f gee_list_real_sort (libgee-0.8.so.2 + 
0x50f2f)
#6  0x55b258aabce3 work_sniffer_real_execute (shotwell + 
0x211ce3)
#7  0x55b2589390f8 workers_thread_start (shotwell + 0x9f0f8)
#8  0x7fd171fd2392 g_thread_pool_thread_proxy 
(libglib-2.0.so.0 + 0x88392)
#9  0x7fd171fd19e1 g_thread_proxy (libglib-2.0.so.0 + 
0x879e1)
#10 0x7fd170bac3ec start_thread (libc.so.6 + 0x883ec)
#11 0x7fd170c2ca2c __clone3 (libc.so.6 + 0x108a2c)


My system is with the following libs:

libc6-dbg/unstable,now 2.37-10 amd64  [installé]
libc6-dev/unstable,now 2.37-10 amd64  [installé]
libc6/unstable,now 2.37-10 amd64  [installé]
libc6/unstable,now 2.37-10 i386  [installé]
libgee-0.8-2-dbgsym/unstable-debug,now 0.20.6-1 amd64  [installé]
libgee-0.8-2/unstable,now 0.20.6-1 amd64  [installé, automatique]
libglib2.0-0-dbgsym/unstable-debug,now 2.78.0-1 amd64  [installé]
libglib2.0-0/unstable,now 2.78.0-1 amd64  [installé]
libglib2.0-0/unstable,now 2.78.0-1 i386  [installé]
libglib2.0-bin-dbgsym/unstable-debug,now 2.78.0-1 amd64  [installé]
libglib2.0-bin/unstable,now 2.78.0-1 amd64  [installé]
libglib2.0-data/unstable,unstable,now 2.78.0-1 all  [installé]
libglib2.0-dev-bin/unstable,now 2.78.0-1 amd64  [installé]
libglib2.0-dev/unstable,now 2.78.0-1 amd64  [installé]

And here is what I am getting using 'gdb':

(gdb) Thread 34 "pool-shotwell" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff8bfff6c0 (LWP 14645)]
0x7687bfe4 in __GI___wcscoll_l (s1=s1@entry=0x0, 
s2=s2@entry=0x7fff842fe660 
L"/home/patrice/Images/Photos/2020/11/15/20201115_154346.jpg", 
l=0x76996580 <_nl_global_locale>) at ../string/strcoll_l.c:273
273 ../string/strcoll_l.c: Aucun fichier ou dossier de ce type.
(gdb) 

#file /home/patrice/Images/Photos/2020/11/15/20201115_154346.jpg
/home/patrice/Images/Photos/2020/11/15/20201115_154346.jpg: JPEG image data, 
Exif standard: [], baseline, precision 8, 5312x2988, components 3


Regards,
Patrice

Bug#1034472: reportbug: auto-apt-proxy prints IPv6 literally incorrectly

[Helmut Grohne]

Control: tags -1 + patch

On Sun, Apr 16, 2023 at 11:08:30AM +0100, Alexander Clouter wrote:
> Though the package functions perfectly (thanks!) when you just run
> auto-apt-proxy on its own, the IPv6 literal is incorrectly concatenated
> to the port.
> 
> It should emit:
> 
> http://[fd69:dead:beef:1::1]:3142
> 
> My local setup has apt-cacher-ng running at apt-proxy:
> 
> alex@sarasti:~$ dig ANY apt-proxy
> 
> ; <<>> DiG 9.18.12-1-Debian <<>> ANY apt-proxy
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33640
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 65494
> ;; QUESTION SECTION:
> ;apt-proxy.   IN  ANY
> 
> ;; ANSWER SECTION:
> apt-proxy.0   IN  fd69:dead:beef:1::1
> apt-proxy.0   IN  A   192.168.1.1
> 
> ;; Query time: 16 msec
> ;; SERVER: 127.0.0.53#53(127.0.0.53) (TCP)
> ;; WHEN: Sun Apr 16 11:00:14 BST 2023
> ;; MSG SIZE  rcvd: 82
> 
> alex@sarasti:~$ auto-apt-proxy 
> http://fd69:dead:beef:1::1:3142
> 
> 
> If you need anything else, do ask.

I also experience this problem. I'm attaching a patch that makes it work
for me, but I am unsure whether the patch is universally correct as it
may need some quoting of the ip in "Acquire::http::Proxy::${ip}=DIRECT"
if the ip contains "::". In my case, the ip does not and therefore it
works. Could you give the patch a try in your environment where "::"
does happen?

Helmut
--- a/auto-apt-proxy
+++ b/auto-apt-proxy
@@ -24,6 +24,17 @@
 }
 trap cleanup INT EXIT TERM
 
+proxy_url() {
+	case "$1" in
+		*:*)
+			echo "http://[$1]:$2;
+		;;
+		*)
+			echo "http://$1:$2;
+		;;
+	esac
+}
+
 hit() {
   timeout 5 /usr/lib/apt/apt-helper \
 -o Acquire::http::Proxy=DIRECT -o Acquire::Retries=0 \
@@ -76,7 +87,7 @@
 
 detect_apt_cacher() {
   local ip="$1"
-  local proxy=http://$ip:3142
+  local proxy="$(proxy_url "$ip" 3142)"
   hit -o "Acquire::http::Proxy::${ip}=DIRECT" "$proxy" >/dev/null 2>&1 || true;
   if [ -s "$tmpfile" ] && grep -q -i 'Apt-cacher' "$tmpfile"; then
 echo "$proxy"
@@ -87,7 +98,7 @@
 
 detect_apt_cacher_ng() {
   local ip="$1"
-  local proxy=http://$ip:3142
+  local proxy="$(proxy_url "$ip" 3142)"
   if hit -o "Acquire::http::Proxy::${ip}=DIRECT" "$proxy" | grep -q -i '406.*usage.information'; then
 echo "$proxy"
 return 0
@@ -97,7 +108,7 @@
 
 detect_approx() {
   local ip="$1"
-  local proxy=http://$ip:
+  local proxy="$(proxy_url "$ip" )"
   hit -o "Acquire::http::Proxy::${ip}=DIRECT" "$proxy" >/dev/null 2>&1 || true;
   if [ -s "$tmpfile" ] && grep -q -i 'approx\s*server' "$tmpfile"; then
 echo "$proxy"
@@ -110,7 +121,7 @@
 #   If you want that, use squid-deb-proxy-client, which depends on avahi.
 detect_squid_deb_proxy() {
   local ip="$1"
-  local proxy=http://$ip:8000
+  local proxy="$(proxy_url "$ip" 8000)"
   if hit -oDebug::acquire::http=1 -o "Acquire::http::Proxy::${ip}=DIRECT" "$proxy" 2>&1 | grep -q 'Via: .*squid-deb-proxy'; then
 echo "$proxy"
 return 0

Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1

[Luca Boccassi]

On Tue, 05 Sep 2023 20:34:02 +0100 Luca Boccassi 
wrote:
> On Tue, 5 Sep 2023 17:33:27 +0100 Jonathan Wiltshire 
> wrote:
> > Control: tag -1 moreinfo
> > 
> > On Tue, Sep 05, 2023 at 10:30:09AM +0100, Luca Boccassi wrote:
> > > On Wed, 30 Aug 2023 16:27:12 +0100 Simon McVittie

> > > wrote:
> > > > Part of the transition to merged-/usr, and more specifically,
> > > allowing
> > > > us to stop shipping files in trixie whose physical path on disk
> does
> > > > not match their path in the dpkg database due to directory
> aliasing.
> > > > 
> > > > This change needs to be in bookworm (and bullseye, and maybe
> buster)
> > > > before that process can continue, because official buildds run
> > > debootstrap
> > > > from stable (or older).
> > > > 
> > > > I also took the opportunity to backport changes that make the
> > > autopkgtests
> > > > pass.
> > > 
> > > I think it would be nice to let this bake in proposed-updates for
a
> > > while before 12.2 is released, just to be extra-extra-safe. Any
> chance
> > > for a quick review so we can upload it?
> > 
> > It will need a d-i ack as a pre-requisite.
> 
> Thanks Jonathan - d-i team, would it be possible for a quick review
of
> this and #1025708 please? This was tested with d-i as such:
> 
> > Philip Hands built a d-i mini.iso with the proposed version, and it
> seems to have installed GNOME successfully under openQA.

Hi,

The clock for 12.2 is ticking fast. Is there any way I can help in
order to make progress? Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#1037902: xneur: ftbfs with GCC-13

[Jonathan Bergh]

Control: tags -1 + patch

Fixes 1037902 with change to gcc-13.
I believe this is a documented false positive from gcc.


patch1.debdiff
Description: Binary data

Bug#1000009: opencollada: depends on obsolete pcre3 library

[Bastian Germann]

X-Debbugs-Cc: m...@debian.org

This will not be fixed upstream. The blender package has dropped its 
opencollada dependency.
I suggest to remove the package.

Bug#1052055: Webkit output fully white

[R Pi]

Package: libwebkit2gtk-4.0-dev
Version: 2.42.0-1
Severity: important

I'm currently developing an app using Tauri. Since upgrading
libwebkit2gtk-4.0-dev from version 2.40.5-1~deb12u1 to version 2.42.0-1,
whenever I launch my app I'm getting the following messages:

KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 1024x741: Permission denied
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 1024x741: Permission denied
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 1024x741: Permission denied
Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1

The output of the webkit area is fully white, otherwise the content of the
webkit viewport appears to be working underneath (ie: I can interact with my app
but simply cannot see anything).

I was able to rollback to the previous version and keep working on my project
with the following command:

sudo apt-get install libwebkit2gtk-4.0-dev=2.40.5-1~deb12u1 \
libwebkit2gtk-4.0-37=2.40.5-1~deb12u1 \
libjavascriptcoregtk-4.0-18=2.40.5-1~deb12u1 \
gir1.2-webkit2-4.0=2.40.5-1~deb12u1 \
gir1.2-javascriptcoregtk-4.0=2.40.5-1~deb12u1 \
libjavascriptcoregtk-4.0-dev=2.40.5-1~deb12u1

I am using Debian GNU/Linux trixie/sid, kernel 6.5.0-1-amd64
and libc6 2.37-10. I am running the non-free nvidia-driver 525.125.06-2.

-- 
- Romain

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

[Aymeric Agon-Rambosson]

Le samedi 16 septembre 2023 à 16:59, Bastian Germann 
 a écrit :



Please push your changes and make it an experimental upload.
When that is done, please ping me again so that I can upload the 
pkg.

Please do not forget to push an upstream/... tag.


Done, you can upload. The upstream tag is upstream/0.12.0+dfsg.

Oh, and please make the CI pipeline run by adding 
repacksuffix=+dfsg to d/watch's opts.

You can also get rid of the filenamemangle.


Done. The pipeline is fixed, thanks for the indication.

After the experimental version is uploaded, you will have to 
request

a transition slot from the release team.


I'm currently reviewing 
https://wiki.debian.org/Teams/ReleaseTeam/Transitions. I am 
reading that I will have to test build the reverse dependencies 
(stage 4), and report about it in the release.debian.org bug. This 
part should be fine.


But it also says that I will maybe have to make uploads to reverse 
dependencies (stage 10). I will probably need your help for this, 
since I'm not authorised to.


Thank you for your help and explanations.

Best,

Aymeric

Bug#1052054: ITP: node-sort-package-json -- Node.js library to sort package.json

[Yadd]

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

* Package name: node-sort-package-json
  Version : 2.5.1
  Upstream Contact: Keith Cirkel 
* URL : https://github.com/fisker/git-hooks-list
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js library to sort package.json

node-sort-package-json is a small library useful to sort package.json files
of Node.js modules, not in alphabetic order but in logical order (starting
by name and version).

It's a dependency of node-jupyterlab and will be maintained under JS
Team umbrella.

Bug#1052048: Close Bug#1052048:

[Mechtilde Stehmann]

Package: texlive-bibtex-extra
Version: 2023.20230613-2

Comment: Sorry for noise



Am 16.09.23 um 17:21 schrieb Debian Bug Tracking System:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1052048: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052048.

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.

As you requested using X-Debbugs-CC, your message was also forwarded to
   mechti...@debian.org
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
  Debian TeX Task Force 

If you wish to submit further information on this problem, please
send it to 1052...@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.



--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052048: Close Bug#1052048:

[Mechtilde Stehmann]

Package: texlive-bibtex-extra
Version: 2023.20230613-2

Comment: Sorry for noise



Am 16.09.23 um 17:21 schrieb Debian Bug Tracking System:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1052048: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052048.

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.

As you requested using X-Debbugs-CC, your message was also forwarded to
   mechti...@debian.org
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
  Debian TeX Task Force 

If you wish to submit further information on this problem, please
send it to 1052...@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.



--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1037506: Bug#1037306: ITP: apycula -- Tools to generate Gowin FPGA bitstreams

[Simon Richter]

Hi Daniel,

On 06.09.23 17:50, Daniel Gröber wrote:


I've pushed apycula 0.9.0 to https://salsa.debian.org/electronics-team/apycula/



FYI: prjtrellis is also waiting for another upload to appease ftp-master
review https://salsa.debian.org/electronics-team/prjtrellis/


I've uploaded both, and made a test build with nextpnr as well, seems good.

   Simon


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1052053: popularity-contest: race condition between the two cron jobs

[Alexandre Detiste]

Package: popularity-contest
Version: 1.77
Severity: normal

Hi,

I have been unlucky and the two instance of the cronjob
triggered at the same time, stepping on eachother feets.

(at the "savelog -c 7 popularity-contest >/dev/null" step precisely)

Can you implement some locking ?

Or alternatively #923014 will get you locking for free
on systemd running systems.


Greetings,


> PS: the error handling is well lacking in 'savelog':
>
># compress the old uncompressed log if needed
>if test -n "$datum" && test -n "$COMPRESS"; then
>$COMPRESS $COMPRESS_OPTS -- 
> "$newname".[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]
>fi


root@antec:~# journalctl  | grep popul | grep service
sep 16 17:02:28 antec systemd[1]: Starting cron-daily-popularity-contest.service
- [Cron] /etc/cron.daily/popularity-contest...
sep 16 17:02:28 antec systemd[1]: Starting 
cron-popularity-contest-root-d2f25b2334da37b6f3ef98c2dc14fad3.service
- [Cron] "56 18 * * *   roottest -x /etc/cron.daily/popularity-contest 
&& /etc/cron.daily/popularity-contest --crond"...


○ cron-daily-popularity-contest.service - [Cron] 
/etc/cron.daily/popularity-contest
 Loaded: loaded (/etc/cron.daily/popularity-contest; generated)
 Active: inactive (dead) since Sat 2023-09-16 17:05:50 CEST; 95ms ago
TriggeredBy: ● cron-daily-popularity-contest.timer
Process: 793 ExecStart=/etc/cron.daily/popularity-contest (code=exited, 
status=0/SUCCESS)
   Main PID: 793 (code=exited, status=0/SUCCESS)
CPU: 9.798s
2023-09-16T17:02:28+0200 antec systemd[1]: Starting 
cron-daily-popularity-contest.service - [Cron] 
/etc/cron.daily/popularity-contest...
2023-09-16T17:02:28+0200 antec popularity-contest[881]: gzip: 
.//popularity-contest.0: No such file or directory
2023-09-16T17:02:28+0200 antec popularity-contest[892]: mv: impossible 
d'évaluer './/popularity-contest.0.gz': Aucun fichier ou dossier de ce type
2023-09-16T17:02:28+0200 antec popularity-contest[897]: mv: impossible 
d'évaluer 'popularity-contest': Aucun fichier ou dossier de ce type
2023-09-16T17:05:50+0200 antec systemd[1]: 
cron-daily-popularity-contest.service: Deactivated successfully.
2023-09-16T17:05:50+0200 antec systemd[1]: Finished 
cron-daily-popularity-contest.service - [Cron] 
/etc/cron.daily/popularity-contest.
2023-09-16T17:05:50+0200 antec systemd[1]: 
cron-daily-popularity-contest.service: Consumed 9.798s CPU time.

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

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

Versions of packages popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.22.0

Versions of packages popularity-contest recommends:
ii  gpg2.2.40-1.1
ii  nullmailer [mail-transport-agent]  1:2.2+10~g7ed88a0-1
ii  systemd-cron [cron-daemon] 2.1.3-1

Versions of packages popularity-contest suggests:
ii  systemd-cron [anacron]  2.1.3-1
pn  tor 
pn  torsocks

-- debconf information:
* popularity-contest/participate: true
  popularity-contest/submiturls:

Bug#1037799: opencollada: ftbfs with GCC-13

[Jonathan Bergh]

Control: tags -1 + patch

Fixes 1037799 due to change to gcc-13


patch1.debdiff
Description: Binary data

Bug#1051552: timg 1.4.5-1+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: timg
Version: 1.4.5-1+deb12u1

Explanation: fix buffer overflow vulnerability [CVE-2023-40968]

Bug#1050928: enlightenment-data: please provide an enlightenment-portals.conf for xdg-desktop-portal

[Ross Vandegrift]

Hi Simon,

On Thu, Aug 31, 2023 at 02:20:51PM +0100, Simon McVittie wrote:
> xdg-desktop-portal 1.17.x introduces a new way to select which portals will
> be used for which desktop environments, modelled on mimeapps.list:
> 
> - each desktop environment should provide a file like
>   /usr/share/xdg-desktop-portal/enlightenment-portals.conf
> 
> - the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
>   environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
>   from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
> 
> - sysadmins and users can override this via files named portals.conf or
>   ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
>   and ~/.config/xdg-desktop-portal
> 
> Please see portals.conf(5) or its source code
> https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
> for full details.
> 
> If I'm reading its code correctly, I think Enlightenment asks the display 
> manager
> to set XDG_CURRENT_DESKTOP to "Enlightenment"? (But if I'm wrong, please
> adjust my suggestions accordingly.)

That's correct - but I'm afraid this is the only item in this bug report that I
understand.  I tried to read the documentation you linked, but both assume
general familiarity with what's going on here.  For me, this all might as well
be greek.  :)

I don't know of any portal requirements for Enlightenment, but I'm not really
clear whether or not that's what you're asking for.  Is there a more basic
description of what this does?  How would I test a change that implemented what
you're requesting?  And what are the consequences of not doing this?

Thanks,
Ross

Bug#1051374: breaks existing setups using /etc/default/mini-httpd

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Alexandru Mihail (2023-09-16 16:40:38)
> > I asked in #debian-systemd and the fix could be as simple as setting the
> > following in the .service file:
> > 
> > EnvironmentFile=-/etc/default/mini-httpd
> > 
> > Can you confirm?
> I will test this and get back to you as soon as I can confirm the fix.
> Documentation on /etc/default/mini-httpd options is rather scarce, do
> you mind posting a minimal /etc/default/mini-httpd file with which I
> could confirm the fix (a path or port setting perhaps)? It would speed
> up my work here as the package does not provide a default one.

here is my /etc/default/mini-httpd:

START=1
DAEMON_OPTS="-h 127.0.0.1 -p 80 -u nobody -dd /mnt/cache -i 
/var/run/mini-httpd.pid -T UTF-8"

I successfully tested the following patch to the .service file:

@@ -5,7 +5,8 @@
 [Service]
 Type=forking
 PIDFile=/run/mini_httpd.pid
-ExecStart=/usr/sbin/mini_httpd -C /etc/mini-httpd.conf
+EnvironmentFile=-/etc/default/mini-httpd
+ExecStart=/usr/sbin/mini_httpd -C /etc/mini-httpd.conf $DAEMON_OPTS -i 
/run/mini_httpd.pid
 
 [Install]
 WantedBy=multi-user.target

The EnvironmentFile uses "=-" to support a non-existant
/etc/default/mini-httpd. The ExecStart line also adds a -i option to make sure
that neither /etc/mini-httpd.conf nor $DAEMON_OPTS can set -i to something that
is different from the path in PIDFile.

What do you think?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#986740: forked-daapd : please package new upstream release

[Bastian Germann]

On Thu, 02 Mar 2023 23:14:10 +0100 =?ISO-8859-1?Q?S=E9bastien?= Noel 
 wrote:

Ok it's been 2 years now, without even an ACK of some sort
If there isn't any interest on your part in this package,
i'm more than willing to adopt it.


I am happy to review and sponsor your upload.
Please add yourself as Uploader and keep it in the Multimedia Team.
Also, please rename the binary package to owntone.
There is a Debian package available from upstream:
https://github.com/owntone/owntone-apt
Maybe you can use parts of it.

Bug#1049899: bookworm-pu: package exim4/4.96-15+deb12u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2023-09-03 at 14:03 +0200, Andreas Metzler wrote:
> On 2023-08-16 Andreas Metzler  wrote:
> [...]
> > I would like to push another round of cherry-picked upstream fixes
> > to
> > bookworm. They have been part of the uploads to sid up to and
> > including
> > 4.96-19.
> [...]
> 
> Hello,
> 
> I had to update the update since 75_78-Fix-free-of-value-after-
> run.patch
> broke a specific expansion. While at it I also pulled the CI related
> changes from -21.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1052027: bullseye-pu: package cargo-mozilla/0.66.0+ds1-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-09-16 at 11:15 +0200, Emilio Pozuelo Monfort wrote:
> Following up on #1051051, this updates cargo-mozilla for the upcoming
> Firefox ESR 115. Just like for rustc-mozilla, the risk here is small
> as this package is only used to build firefox-esr and thunderbird.
> 
> I have used the resulting package to successfully build and test
> firefox-esr 115.0.2 on bullseye.
> 

Please go ahead.

Regards,

Adam

Bug#1052052: libreoffice-parlatype-extension: FTBFS/autopkgtest failure: needs tos (build-)depend on libreoffice-core

[Rene Engelhard]

Source: libreoffice-parlatype-extension
Version: 3.1.1-1
Severity: important

Dear Maintainer,

I see parlatype-libreoffice-extension failing with the new  upstream
release of libreoffice in experimental (see 
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/parlatype-libreoffice-extension/37751215/log.gz):

 82s autopkgtest [18:31:18]: test unit-tests: [---
 83s Warning: failed to launch javaldx - java may not function correctly
 85s test_extractTimestamp 
(test_parlatype_utils.TestUtils.test_extractTimestamp)
 85s Test extractTimestamp() ... ERROR
 85s test_isValidCharacter 
(test_parlatype_utils.TestUtils.test_isValidCharacter)
 85s Test _isValidCharacter() ... ok
 85s starting LibreOffice with channel:  
pipe,name=pytest6667d0ae-50d1-11ee-8852-00163ebb4c1a
 85s Connecting to:  
uno:pipe,name=pytest6667d0ae-50d1-11ee-8852-00163ebb4c1a;urp;StarOffice.ComponentContext
 85s WARN: NoConnectException: sleeping...
 85s WARN: NoConnectException: sleeping...
 85s tearDown: calling terminate()...
 85s ...done
 85s
 85s ==
 85s ERROR: test_extractTimestamp 
(test_parlatype_utils.TestUtils.test_extractTimestamp)
 85s Test extractTimestamp()
 85s --
 85s Traceback (most recent call last):
 85s   File 
"/tmp/autopkgtest-lxc.djpobicb/downtmp/build.oGP/src/tests/test_parlatype_utils.py",
 line 61, in test_extractTimestamp
 85s text = doc.Text
 85s
 85s AttributeError: 'NoneType' object has no attribute 'Text'
 85s
 85s --
 85s Ran 2 tests in 2.082s
 85s
 85s FAILED (errors=1)
 85s Warning: failed to launch javaldx - java may not function correctly
 86s test_empty_get (test_document_link.TestUtils.test_empty_get)
 86s Get empty custom property "Parlatype" ... ERROR
 86s test_remove_and_get (test_document_link.TestUtils.test_remove_and_get)
 86s Remove custom property "Parlatype" ... ERROR
 86s test_set_and_get (test_document_link.TestUtils.test_set_and_get)
 86s Set custom property "Parlatype" ... ERROR
 86s
 86s ==
 86s ERROR: test_empty_get (test_document_link.TestUtils.test_empty_get)
 86s Get empty custom property "Parlatype"
 86s --
 86s Traceback (most recent call last):
 86s   File 
"/tmp/autopkgtest-lxc.djpobicb/downtmp/build.oGP/src/tests/test_document_link.py",
 line 48, in test_empty_get
 86s self.assertIsNone(getDocumentLink(doc))
 86s   
 86s   File 
"/usr/lib/libreoffice/share/extensions/parlatype/python/components/Parlatype.py",
 line 131, in getDocumentLink
 86s doc_prop = doc.getDocumentProperties()
 86s^
 86s AttributeError: 'NoneType' object has no attribute 'getDocumentProperties'
 86s
 86s ==
 86s ERROR: test_remove_and_get 
(test_document_link.TestUtils.test_remove_and_get)
 86s Remove custom property "Parlatype"
 86s --
 86s Traceback (most recent call last):
 86s   File 
"/tmp/autopkgtest-lxc.djpobicb/downtmp/build.oGP/src/tests/test_document_link.py",
 line 67, in test_remove_and_get
 86s setDocumentLink(doc, "http://test;)
 86s   File 
"/usr/lib/libreoffice/share/extensions/parlatype/python/components/Parlatype.py",
 line 119, in setDocumentLink
 86s doc_prop = doc.getDocumentProperties()
 86s^
 86s AttributeError: 'NoneType' object has no attribute 'getDocumentProperties'
 86s
 86s ==
 86s ERROR: test_set_and_get (test_document_link.TestUtils.test_set_and_get)
 86s Set custom property "Parlatype"
 86s --
 86s Traceback (most recent call last):
 86s   File 
"/tmp/autopkgtest-lxc.djpobicb/downtmp/build.oGP/src/tests/test_document_link.py",
 line 57, in test_set_and_get
 86s setDocumentLink(doc, "http://test;)
 86s   File 
"/usr/lib/libreoffice/share/extensions/parlatype/python/components/Parlatype.py",
 line 119, in setDocumentLink
 86s doc_prop = doc.getDocumentProperties()
 86s^
 86s AttributeError: 'NoneType' object has no attribute 'getDocumentProperties'
 86s
 86s --
 86s Ran 3 tests in 1.075s
 86s
 86s FAILED (errors=3)
 86s WARN: NoConnectException: sleeping...
 86s autopkgtest [18:31:22]: test unit-tests: ---]
 86s unit-tests   FAIL non-zero exit status 1
 86s autopkgtest [18:31:22]: test unit-tests:  - - - - - - - - - - results - - 
- - - - - - - -
 87s 

Bug#1052040: mmm-mode: post-install script fails

[Vincent Lefevre]

Control: forwarded -1 https://github.com/dgutov/mmm-mode/issues/137
Control: tags -1 upstream

On 2023-09-16 17:02:54 +0200, Vincent Lefevre wrote:
> This appears to be related to macro expansion, which seems to
> occur even if the code is not executed.

An easy solution would be to avoid the XEmacs form (marked as
obsolete in GNU Emacs since 23.1 and whose support was removed
in GNU Emacs 28[*]), i.e. change

(if (not (string-match "XEmacs" (emacs-version)))
(define-obsolete-function-alias 'mmm-add-find-file-hooks 
'mmm-add-find-file-hook
  "0.3.8"
  "Both `mmm-add-find-file-hooks' and `mmm-add-find-file-hook' are 
deprecated.")
  (define-obsolete-function-alias 'mmm-add-find-file-hooks 
'mmm-add-find-file-hook))

to just

(define-obsolete-function-alias 'mmm-add-find-file-hooks 'mmm-add-find-file-hook
  "0.3.8"
  "Both `mmm-add-find-file-hooks' and `mmm-add-find-file-hook' are deprecated.")

[*] https://github.com/emacs-mirror/emacs/commit/32c6732

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

Bug#1037699: intel-mediasdk: ftbfs with GCC-13

[Jonathan Bergh]

Control: tags -1 + patch

Fixes FTBFS due to gcc-13 upgrade and closes #1037699


patch1.debdiff
Description: Binary data

Bug#1052048: texlive-bibtex-extra: Can't generate bibliography since last upgrade at trixie

[Preuße]

On 16.09.2023 17:16, Mechtilde Stehmann wrote:

Hello Mechtilde,


After last update at trixie I can't proper build https://salsa.debian.org/ddp-
team/dpb/ locally.

It builds correct on trixie at the Salsa CI at 03.09.2023. The last upload to
trixie was at 05.09.2023.

Do you have some kind of log file, showing an error message? Please 
don't send files having a size of > 100KB.



I lost the bibliography in the pdf of this big document.

That's why I set it to grave.


For now I leave it at this severity, although I don't share you opinion.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986736: RFP: xmake -- A cross-platform build utility based on Lua

[Bastian Germann]

xmake was once part of Debian and was deliberately removed because it was not 
used.
If you want to package software that actually uses xmake please indicate this by blocking this ITP 
by that software's RFP/ITP bug.

Bug#1052051: sagemath: Sagemath 9.5-6 expects libsingular-Singular-4.3.1.so but libsingular-Singular-4.3.2.so is installed

[jagv]

Package: sagemath
Version: 9.5-6
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Typing "sage" and pressing Enter

   * What was the outcome of this action?
Sagemath did not start

   * What outcome did you expect instead?
Sagemath should start

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


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

Kernel: Linux 6.4.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 sagemath depends on:
ii  python3   3.11.4-5+b1
ii  python3-sage  9.5-6

Versions of packages sagemath recommends:
ii  sagemath-doc9.5-6
ii  sagemath-jupyter9.5-6
ii  sagetex 3.6.1+ds-1
ii  texlive-latex-base  2023.20230613-3

Versions of packages sagemath suggests:
pn  dot2tex  
pn  gap-design   
ii  gap-factint  1.6.3+ds-2
pn  gap-grape
pn  gap-guava
ii  gap-laguna   3.9.6+ds-1
pn  gap-sonata   
pn  gap-toric

-- no debconf information

Bug#1052050: multiple problem with GTK3 enabled

[Mikhail Kshevetskiy]

Package: lxpanel
Version: 0.10.1-4
Severity: important
Tags: patch
X-Debbugs-Cc: ChangZhuo Chen (陳昌倬) 

There are a lot of issues with GTK3 version of lxpanel that makes it almost
unusable. The following patches required to apply to fix an issues:
 * 02-Correct-icon-grid-width-under-GTK3.-Fixes-Github-29.patch
 * 03-Correct-panel-size-under-GTK3.-Fixes-Sourceforge-773.patch
 * 04-Support-HiDPI-on-GTK-3.patch
 * 05-Highlight-selected-workspace-in-pager.patch
 * 06-fix-alsa-volume-issue.patch
 * 07-Fix-division-by-zero-with-broken-batteries.patch
 * 08-Use-XkbRF_GetNamesProp-instead-of-xkb_symbols.patch

This patches was taken from https://github.com/lxde-continued/lxpanel.git.
You may look there for more patches/details.

Mikhail Kshevetskiy

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 lxpanel depends on:
ii  libasound2   1.2.9-2
ii  libc62.37-8
ii  libcairo21.17.8-3
ii  libcurl3-gnutls  8.2.1-2
ii  libfm-gtk3-4 1.3.2-4
ii  libfm-modules1.3.2-4
ii  libfm4   1.3.2-4
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.78.0-1
ii  libgtk-3-0   3.24.38-5
ii  libiw30  30~pre9-14
ii  libkeybinder-3.0-0   0.3.2-1.1
ii  libmenu-cache3   1.1.0-1.1
ii  libpango-1.0-0   1.51.0+ds-2
ii  libwnck-3-0  43.0-3
ii  libx11-6 2:1.8.6-1
ii  libxkbfile1  1:1.1.0-1
ii  libxml2  2.9.14+dfsg-1.3
ii  lxmenu-data  0.1.5-2.1
ii  lxpanel-data 0.10.1-4

Versions of packages lxpanel recommends:
ii  foot [x-terminal-emulator]  1.15.3-1
ii  gnome-flashback [notification-daemon]   3.49.1-1+b1
ii  gnome-shell [notification-daemon]   44.4-1
ii  gnome-terminal [x-terminal-emulator]3.49.99-1
ii  konsole [x-terminal-emulator]   4:22.12.3-1
ii  libnotify-bin   0.8.2-1
ii  mate-notification-daemon [notification-daemon]  1.26.0-1
ii  mate-terminal [x-terminal-emulator] 1.26.1-1
ii  pavucontrol 5.0-2
ii  plasma-workspace [notification-daemon]  4:5.27.7-2
ii  xfce4-notifyd [notification-daemon] 0.8.2-1
ii  xfce4-terminal [x-terminal-emulator]1.1.0-1
ii  xkb-data2.38-2
ii  xterm [x-terminal-emulator] 384-1

Versions of packages lxpanel suggests:
ii  dillo [www-browser]3.0.5-7+b1
ii  firefox-esr [www-browser]  115.2.0esr-1
ii  konqueror [www-browser]4:22.12.3-2
ii  links [www-browser]2.29-1
ii  lynx [www-browser] 2.9.0dev.12-1

-- no debconf information
>From 3c1ad6bc7c8b4b3ba66c04e6e10aa741f028ba75 Mon Sep 17 00:00:00 2001
From: Ben Walsh 
Date: Mon, 7 Feb 2022 07:02:05 +
Subject: [PATCH] Correct icon-grid width under GTK3. Fixes Github #29.

---
 src/icon-grid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/icon-grid.c b/src/icon-grid.c
index 2177971e..5948fee6 100644
--- a/src/icon-grid.c
+++ b/src/icon-grid.c
@@ -392,7 +392,7 @@ static void panel_icon_grid_get_preferred_width(GtkWidget *widget,
 }
 panel_icon_grid_size_request(widget, );
 if (minimal_width)
-*minimal_width = requisition.width;
+*minimal_width = ig->constrain_width ? 2 : requisition.width;
 if (natural_width)
 *natural_width = requisition.width;
 }
-- 
2.40.1

>From 12576de7b83c634437217e23d74954070a1be2d5 Mon Sep 17 00:00:00 2001
From: Ben Walsh 
Date: Sat, 6 Jun 2020 10:38:15 +0100
Subject: [PATCH] Correct panel size under GTK3. Fixes Sourceforge #773.

---
 src/panel.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/panel.c b/src/panel.c
index 45188dbe..2b5fc9be 100644
--- a/src/panel.c
+++ b/src/panel.c
@@ -293,6 +293,12 @@ lxpanel_get_preferred_height (GtkWidget *widget,
   if (natural_height)
   *natural_height = requisition.height;
 }
+
+static GtkSizeRequestMode
+lxpanel_get_request_mode (GtkWidget *widget)
+{
+return GTK_SIZE_REQUEST_CONSTANT_SIZE;
+}
 #endif
 
 static void lxpanel_size_allocate(GtkWidget *widget, GtkAllocation *a)
@@ -413,6 +419,7 @@ static void lxpanel_class_init(PanelToplevelClass *klass)
 #if GTK_CHECK_VERSION(3, 0, 0)
 widget_class->get_preferred_width = lxpanel_get_preferred_width;
 widget_class->get_preferred_height = lxpanel_get_preferred_height;
+widget_class->get_request_mode = lxpanel_get_request_mode;
 #else
 widget_class->size_request = lxpanel_size_request;
 #endif
-- 
2.40.1

>From 

Bug#1052049: bacula-director: Please amend bacula-dir.conf to include subfiles

[Niels S. Richthof]

Package: bacula-director
Version: 9.6.7-7
Severity: wishlist

Dear Maintainer,

The bacula director configuration file can get very big and messy, especially 
when backing up many clients.

bacula-director supports the inclusion of subfiles in configuration files,
as documented here:
https://www.bacula.org/9.6.x-manuals/en/main/Customizing_Configuration_F.html#SECTION002023000
(This is also the case in all newer upstream versions.)

Therefore, could you please, in keeping with the way other Debian packages are 
doing this:

1. Create a new (empty) directory "/etc/bacula/bacula-dir.conf.d/"
2. Add the following snipped to "/etc/bacula/bacula-dir.conf":

   # Include subfiles associated with configuration of clients.
   # They define the bulk of the Clients, Jobs, and FileSets.
   # Remember to "reload" the Director after adding a client file.
   #
   @|"sh -c 'for f in /etc/bacula/bacula-dir.conf.d/*.conf ; do echo @${f} ; 
done'"


Thank you
Niels

-- 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 5.10.0-23-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bacula-director depends on:
ii  bacula-common  9.6.7-7
ii  bacula-director-mysql  9.6.7-7
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u1
ii  libstdc++6 12.2.0-14
ii  sysvinit-utils 3.06-4
ii  ucf3.0043+nmu1

bacula-director recommends no packages.

Versions of packages bacula-director suggests:
pn  bacula-doc  

-- no debconf information

Bug#1043836: cmospwd: Fails to build source after successful build

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru cmospwd-5.0+dfsg/debian/changelog cmospwd-5.0+dfsg/debian/changelog
--- cmospwd-5.0+dfsg/debian/changelog   2010-05-10 14:55:37.0 +
+++ cmospwd-5.0+dfsg/debian/changelog   2023-09-16 11:44:58.0 +
@@ -1,3 +1,13 @@
+cmospwd (5.0+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Update maintainer field and unset DMUA
+  * Drop kfreebsd from Architectures and patches (Closes: #1052036)
+  * d/watch: Scan HTTPS
+  * Clean binary (Closes: #1043836)
+
+ -- Bastian Germann   Sat, 16 Sep 2023 11:44:58 +
+
 cmospwd (5.0+dfsg-2) unstable; urgency=low
 
   * Include fix for FTBFS on KFreeBSD (Closes: #580673) 
diff -Nru cmospwd-5.0+dfsg/debian/clean cmospwd-5.0+dfsg/debian/clean
--- cmospwd-5.0+dfsg/debian/clean   1970-01-01 00:00:00.0 +
+++ cmospwd-5.0+dfsg/debian/clean   2023-09-16 11:44:58.0 +
@@ -0,0 +1 @@
+src/cmospwd
diff -Nru cmospwd-5.0+dfsg/debian/control cmospwd-5.0+dfsg/debian/control
--- cmospwd-5.0+dfsg/debian/control 2010-05-10 14:55:37.0 +
+++ cmospwd-5.0+dfsg/debian/control 2023-09-16 11:44:58.0 +
@@ -1,15 +1,14 @@
 Source: cmospwd
 Section: utils
 Priority: optional
-Maintainer: Luke Faraone 
+Maintainer: Luke Faraone 
 Build-Depends: cdbs (>= 0.4.49), debhelper (>= 7)
 Standards-Version: 3.8.4
-DM-Upload-Allowed: yes
 Vcs-Bzr: https://code.launchpad.net/~lfaraone/cmospwd/debian
 Homepage: http://www.cgsecurity.org/wiki/CmosPwd
 
 Package: cmospwd
-Architecture: amd64 i386 kfreebsd-amd64 kfreebsd-i386 
+Architecture: amd64 i386
 Depends: ${shlibs:Depends},  ${misc:Depends},
 Description: decrypt BIOS passwords from CMOS
  CmosPwd is a cross-platform tool to decrypt password stored in CMOS used 
@@ -18,4 +17,3 @@
  This application should work out of the box on most modern systems, but 
  some more esoteric BIOSes may not be supported or may require additional 
  steps. 
- 
diff -Nru cmospwd-5.0+dfsg/debian/patches/ftbfs_kfreebsd.patch 
cmospwd-5.0+dfsg/debian/patches/ftbfs_kfreebsd.patch
--- cmospwd-5.0+dfsg/debian/patches/ftbfs_kfreebsd.patch2010-05-10 
14:55:37.0 +
+++ cmospwd-5.0+dfsg/debian/patches/ftbfs_kfreebsd.patch1970-01-01 
00:00:00.0 +
@@ -1,51 +0,0 @@
 a/src/cmospwd.c
-+++ b/src/cmospwd.c
-@@ -37,7 +37,11 @@
- #define HAVE_SYS_IO_H 1
- #endif
- 
--#ifdef __FreeBSD__
-+#if defined(__FreeBSD__) && ! defined(__FreeBSD_kernel__)
-+# define __FreeBSD_kernel__ __FreeBSD__
-+#endif
-+
-+#ifdef __FreeBSD_kernel__
- #define HAVE_CTYPE_H 1
- #endif
- 
-@@ -181,7 +185,7 @@
- #define GWIOPM_PARAMCOUNT 3// for most functions
- #define GWIOPM_PARAMCOUNT_BYTES GWIOPM_PARAMCOUNT * 4  // for most functions
- 
--#elif defined(__FreeBSD__)
-+#elif defined(__FreeBSD_kernel__)
- FILE *cmos_fd;
- #endif
- 
-@@ -358,7 +362,7 @@
- };
- 
- 
--#if 
defined(__linux__)||defined(__FreeBSD__)||defined(__NetBSD__)||defined(__CYGWIN32__)||defined(__MINGW32__)
-+#if 
defined(__linux__)||defined(__FreeBSD_kernel__)||defined(__NetBSD__)||defined(__CYGWIN32__)||defined(__MINGW32__)
- static __inline__ void outportb(uint16_t port,uint8_t value)
- {
-   __asm__ volatile ("outb %0,%1"
-@@ -1471,7 +1475,7 @@
- perror("i386_iopl");
- exit(1);
-   }
--#elif defined(__FreeBSD__)
-+#elif defined(__FreeBSD_kernel__)
- cmos_fd = fopen("/dev/io", "r");
- if(cmos_fd==NULL){
-perror("fopen /dev/io failed");
-@@ -1485,7 +1489,7 @@
- {
- #ifdef __linux__
-   ioperm(PORT_CMOS_0,4*2,0);
--#elif defined(__FreeBSD__)
-+#elif defined(__FreeBSD_kernel__)
-   fclose(cmos_fd);
- #endif
- }
diff -Nru cmospwd-5.0+dfsg/debian/patches/series 
cmospwd-5.0+dfsg/debian/patches/series
--- cmospwd-5.0+dfsg/debian/patches/series  2010-05-10 14:55:37.0 
+
+++ cmospwd-5.0+dfsg/debian/patches/series  1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-ftbfs_kfreebsd.patch
diff -Nru cmospwd-5.0+dfsg/debian/watch cmospwd-5.0+dfsg/debian/watch
--- cmospwd-5.0+dfsg/debian/watch   2010-05-10 14:55:37.0 +
+++ cmospwd-5.0+dfsg/debian/watch   2023-09-16 11:44:58.0 +
@@ -1,3 +1,3 @@
 version=3
 opts=dversionmangle=s/\+dfsg$// \
-http://www.cgsecurity.org/wiki/CmosPwd 
http://www.cgsecurity.org/cmospwd-(.*)\.tar\.bz2
+https://www.cgsecurity.org/wiki/CmosPwd 
https://www.cgsecurity.org/cmospwd-(.*)\.tar\.bz2

Bug#1052048: texlive-bibtex-extra: Can't generate bibliography since last upgrade at trixie

[Mechtilde Stehmann]

Package: texlive-bibtex-extra
Version: 2023.20230613-2
Severity: grave
X-Debbugs-Cc: mechti...@debian.org

After last update at trixie I can't proper build https://salsa.debian.org/ddp-
team/dpb/ locally.

It builds correct on trixie at the Salsa CI at 03.09.2023. The last upload to
trixie was at 05.09.2023.

I lost the bibliography in the pdf of this big document.

That's why I set it to grave.

Kind regards

Mechtilde


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1956 Sep 10 08:48 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 12  2022 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 27 23:39 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 27 23:39 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Oct 18  2022 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Aug 27 23:39 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Aug 27 23:39 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3197 Sep 10 08:47 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Sep  4  2021 mktex.cnf
-rw-r--r-- 1 root root 475 Oct 18  2022 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-bibtex-extra depends on:
ii  tex-common  6.18
ii  texlive-base2023.20230613-3
ii  texlive-binaries2023.20230311.66589-4
ii  texlive-latex-base  2023.20230613-3

texlive-bibtex-extra recommends no packages.

texlive-bibtex-extra suggests no packages.

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

Versions of packages tex-common suggests:
ii  debhelper  13.11.6

Versions of packages texlive-bibtex-extra is related to:
ii  tex-common6.18
ii  texlive-binaries  2023.20230311.66589-4

-- no debconf information

Bug#1052047: libreoffice-calc: background color not (always) rendered

[Fabrice Aeschbacher]

Package: libreoffice-calc
Version: 4:7.4.7-1
Severity: normal
X-Debbugs-Cc: fabrice.aeschbac...@gmail.com

Dear Maintainer,

Please note that I'm unsure whether the bug should be filled against 
xfce4 or

libreoffice-calc.

I'm running libreoffice-calc under XFCE4 with default theme (High Contrast)

- If I set the cell background color to any color except white, say 
"yellow",

the cell's background color stays white.

- When clicking "File => Print Preview", the cell's background stays white.

- Under "Tools => Options => Accessibility", if I unselect "Use system 
colors

for page previews", the cell's background is rendered correctly (yellow) in
Print Preview, but not in the sheet.

- In XFCE Settings => Appearance, If I change the default style (High 
Contrast)

to say Adwaita (which is another style installed by default), the cell's
background  is rendered correctly, in the sheet like in Print Preview.

The bug happens in versions 4:7.4.7-1 (bookworm) and also with
4:7.5.6-1~bpo12+1 (bookworm-backports). It used to work fine with 
bullseye versions.



-- Package-specific info:
Configuration file    Package Exists Changed
/etc/libreoffice/registry/calc.xcd    libreoffice-calc Yes No
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----===
ii  libreoffice-gtk3 4:7.4.7-1    amd64    office productivity suite 
-- GTK+ 3 integration

un  libreoffice-kf5        (no description available)
un  libreoffice-qt5        (no description available)

-- 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/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
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 libreoffice-calc depends on:
ii  coinor-libcoinmp1v5  1.8.3-3
ii  libc6    2.36-9+deb12u1
ii  libetonyek-0.1-1 0.1.10-3+b1
ii  libgcc-s1    12.2.0-14
ii  libicu72 72.1-3
ii  libmwaw-0.3-3    0.3.21-1
ii  libodfgen-0.1-1  0.1.8-2
ii  liborcus-0.17-0  0.17.2-2+b2
ii  liborcus-parser-0.17-0   0.17.2-2+b2
ii  libreoffice-base-core    4:7.4.7-1
ii  libreoffice-common   4:7.4.7-1
ii  libreoffice-core 4:7.4.7-1
ii  librevenge-0.0-0 0.0.5-3
ii  libstaroffice-0.0-0  0.0.7-1
ii  libstdc++6   12.2.0-14
ii  libuno-cppu3 4:7.4.7-1
ii  libuno-cppuhelpergcc3-3  4:7.4.7-1
ii  libuno-sal3  4:7.4.7-1
ii  libuno-salhelpergcc3-3   4:7.4.7-1
ii  libwps-0.4-4 0.4.13-1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  lp-solve 5.5.2.5-2
ii  ucf  3.0043+nmu1
ii  uno-libs-private 4:7.4.7-1

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
ii  ocl-icd-libopencl1  2.3.1-1

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.14.1-4
ii  fonts-opensymbol    4:102.12+LibO7.4.7-1
ii  libabsl20220623 20220623.1-1
ii  libboost-locale1.74.0   1.74.0+ds1-21
ii  libc6   2.36-9+deb12u1
ii  libcairo2   1.16.0-7
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1.1
ii  libclucene-core1v5  2.3.3.4+dfsg-1.1
ii  libcups2    2.4.2-3+deb12u1
ii  libcurl3-gnutls 7.88.1-10+deb12u1
ii  libdbus-1-3 1.14.8-2~deb12u1
ii  libdconf1   0.40.0-4
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.10-1
ii  libexpat1   2.5.0-1
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.14.1-4
ii  libfreetype6    2.12.1+dfsg-5
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-0    2.74.6-2
ii  libgpgmepp6 1.18.0-3+b1
ii  libgraphite2-3  1.3.14-1
ii  libgstreamer-plugins-base1.0-0  1.22.0-3+deb12u1
ii  libgstreamer1.0-0   1.22.0-2
ii  libharfbuzz-icu0    6.0.0+dfsg-3
ii  libharfbuzz0b   6.0.0+dfsg-3
ii  libhunspell-1.7-0   1.7.1-1
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.10-1
ii