Bug#1051441: systemd: user unit is no longer started after upgrade to bookworm

[Michael Biebl]

Control: tags -1 + moreinfo

Am 08.09.23 um 06:15 schrieb Vincent Lefevre:

Package: systemd
Version: 252.12-1~deb12u1
Severity: important

Before the upgrade to bookworm, I had a user unit (rsysinfo) that
was started as expected. This is no longer the case.


Please attach the output of
systemctl --user status rsysinfo.service
systemctl --user cat rsysinfo.service



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1043108: libevent: fails to build against glibc 2.38

[Shengjing Zhu]

On Fri, Sep 8, 2023 at 1:10 AM Samuel Thibault  wrote:
>
> Shengjing Zhu, le ven. 08 sept. 2023 00:05:23 +0800, a ecrit:
> > On Sun, Aug 06, 2023 at 10:30:38AM +0200, Samuel Thibault wrote:
> > > Source: libevent
> > > Version: 2.1.12-stable-8
> > > Severity: important
> > > Tags: patch
> > >
> > > Hello,
> > >
> > > libevent fails to build against glibc 2.38:
> > >
> > > --- debian/libevent-core-2.1-7.symbols.original 2023-08-06 
> > > 10:17:18.031636016 +0200
> > > +++ debian/libevent-core-2.1-7.symbols  2023-08-06 10:17:28.135665241 
> > > +0200
> > > @@ -310,7 +310,6 @@
> > >   event_set_mem_functions@Base 2.1.8-stable
> > >   event_sock_err@Base 2.1.8-stable
> > >   event_sock_warn@Base 2.1.8-stable
> > > - (arch=!musl-linux-any)event_strlcpy_@Base 2.1.8-stable
> > >   event_warn@Base 2.1.8-stable
> > >   event_warnx@Base 2.1.8-stable
> >
> > I don't understand why it's safe to drop this symbol.
>
> Because it's not exposed in the API to other packages:
>
> ./strlcpy-internal.h:#define strlcpy event_strlcpy_
>
> is the only exposure, and that file is not installed, so there is no way
> for another package to produce a reference to it. I did check on the
> archive in the amd64 case, no package does.
>

Thanks, that's indeed not possible to use.

-- 
Shengjing Zhu

Bug#1051442: libnss-mdns can not access /run/avahi-daemon after reinstalling avahi-daemon due to its postrm script

[Max Nikulin]

Package: avahi-daemon
Version: 0.8-10
Severity: normal

I was experimenting with multicast name resolution performed by
libnss-mdns and libnss-resolve when I got the following failure.

apt purge avahi-daemon
# some experiments with systemd-resolved
apt install avahi daemon
getent hosts somehost.local

Nothing returned despite at this moment mdns4_minimal was present in
/etc/nsswitch.conf. Using strace I have find the reason of failure:

connect(3, {sa_family=AF_UNIX, sun_path="/run/avahi-daemon/socket"}, 
110) = -1 EACCES (Permission denied)


ls -ld /run/avahi-daemon
drwx-- 2 avahi avahi 80 Sep  8 10:43 /run/avahi-daemon

However it should be

drwxr-xr-x 2 avahi avahi 80 Sep  8 11:07 /run/avahi-daemon

I believe that the reason is

/var/lib/dpkg/info/avahi-daemon.postrm
# Cleanup /run/avahi-daemon, see #448539
f=/run/avahi-daemon
if [ -d "$f" ]; then
rmdir "$f" || { chown root:root "$f" && chmod 00700 "$f"; }
fi

This code snippet is not ready to current behavior of avahi-daemon
process that does not remove its PID file (#876342) and the socket
(#849454) on exit.

Purging configuration files for avahi-daemon (0.8-10) ...
rmdir: failed to remove '/run/avahi-daemon': Directory not empty

Behavior of mDNS may be surprising due to "SOA local" heuristics in
libnss-mdns and unicast settings of ISP provider. It is unfortunate that
the package script contributes to this mess as well. I admit that purge 
and install again without reboot in between scenario is not frequent.


Perhaps the /run/avahi-daemon directory should be removed by rm -r or by
another not so shy method. Anyway files in /run do not survive reboot.

Workaround:
systemctl stop avahi-daemon.service
rm -r /run/avahi-daemon/

Bug#1016558: ITA: muse-el

[Manphiz]

Nicholas D Steeves  writes:

> Manphiz  writes:
>
>> Nicholas D Steeves  writes:
>>> Manphiz  writes:
 Nicholas D Steeves  writes:
> Manphiz  writes:
>>>
>>> You're welcome.  Yes, I agree that the github fork's structure has
>>> diverged less, and I vaguely remember that that may have been one of the
>>> reasons why I chose to watch it for future releases, but the then tag
>>> never materialised.  As noted previously, I'm ok with switching to the
>>> fork if that's what you'd prefer to do long-term!  As the maintainer you
>>> get to pick the most high-quality and well-maintained upstream for the
>>> Debian source, because you're the one who is responsible to our users.
>>>
>>
>> Sounds good.  I'll give it a little more thoughts.
>
> Wonderful, there's no rush.  As ever, in Debian, you don't need to do
> something you don't want to do.
>
>>> Do you mind if I enhance this significantly?  Find proposal in-line, at
>>> the end of the email.
>>
>> No problem!  Patch applied, rebuilt, and reuploaded to mentors[1].
>> PTAL.
>
> LGTM!
>
>>> Also, I'd like this to be more visible, so I'll
>>> file a bug titled something like "Choose living upstream for muse-el,
>>> and merge updates" if you don't.  I'm vaguely starting to remember that
>>> the issue about a future upstream was raised during my early
>>> contributions, but then I forgot all about it ;) Also, as the fixes for
>>> Emacs compat eventually start accumulating we'll end up becoming a
>>> second fork.
>>>
>>
>> Makes sense.  Filed Bug#1051247 for tracking.  Will probably get to it
>> in the next revision.
>
> Much obliged.
>
> Please refinalise with 'dch -r' and commit with something like "Actually
> release 3.20+dfsg-8 to unstable" (or sid, as you prefer!).  Then push.

Done :)

> Please create an annotated tag called "debian/3.20+dfsg-8", but don't
> push that tag until you receive the "ACCEPTED" email from
> ftp-masters/the archive.

Also done and waiting for submitting.

> It will most likely be less than 24h in
> between pushing the release commit and pushing the tag, during which
> time you'll be waiting for me to actually make the upload.
>

BTW rebuilt and re-uploaded to mentors :)

> As for why?  Well, there's some ambiguity now about whether
> commit:02e95c1 was 3.20+dfsg-8, the fix is easy, and the delay is only
> another day or two.
>
> After this, the package is truly ready.

=)

> Cheers,
> Nicholas
>

-- 
Manphiz


signature.asc
Description: PGP signature

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Russ Allbery]

Luca Boccassi  writes:

> And I am more than a bit sad that sensible, clear-cut, binding and
> already-implemented decisions taken by our constitutional bodies get
> constantly second-guessed and belittled because of an irrational
> attachment to inconsequential accidents of history. But what can we do,
> we'll just have to be sad together, I guess.

> Aside from that, in the future please avoid using the word 'minorities'
> when talking about silly things such as liking or disliking symlinks, as
> in common English it is used to refer to much more serious matters.

Okay, stop.  We are not going to have a Policy conversation like this.
Nothing about this discussion style helps in making a good decision.

Luca, you have asked repeatedly what you can do to advance the status of
your open Policy bugs.  Most of the answer to that question is that a lot
of it is outside of your control; I've been having a spectacularly
annoying summer in a bunch of minor ways and, frankly, simply haven't done
much of anything I'm responsible for in Debian.  But the most helpful
thing that you could possibly do would be to stop being utterly
emotionally exhausting to deal with.

Case in point: now I'm writing this email message rather than doing any of
the other things that I am quite sure you would rather that I be doing and
that you would consider a much higher priority.

In this bug, about a point that from the Policy perspective is mostly not
even normative, which appears to partly be a bug report against Lintian by
proxy (the Policy Editors do not maintain Lintian), you started at an
emotional level of eight out of ten before anyone even disagreed with you.
Let me quote the start of this bug:

I heard many times the policy maintainers mention something along the
lines of 'policy should not be a hammer to beat other maintainers
with'. Today I saw policy being used to force a maintainer to re-add
support for the deprecated and unsupported split-usr filesystem
layout, as 'policy only mentions /bin/sh, not /usr/bin/sh'.

So let's update the policy to refer to modern and supported filesystem
paths as adopted by Debian de-facto and de-jure, and stop other
maintainers from getting beaten with it.

So right from the first message, you're saying that the goal of this
proposal is to stop other people from doing something socially you don't
like that Policy doesn't even tell them to do.  And you're using phrasing
that you know is loaded and contentious and that you know the people
you've been arguing with all over Debian will disagree with.

I have no idea why.  Because you like making them mad?  Because you're mad
and you want to keep rubbing in their face the fact you disagree with
them?  Maybe you think this is your strongest argument?  (It is not.)

This is pretty much guaranteed to turn the bug into a fight regardless of
its technical merits, because this presentation essentially says that
you're spoiling for a fight and want someone to attack you.

I cannot remember the last time I have seen someone who is this unwilling
to win an argument.  It's driving me nuts.  You are winning your technical
arguments in Debian!  The technical design that you support is being
implemented because you and others have convinced people that it is a good
idea, even though some people are very upset about this!  There are even
people who don't entirely agree with you investing significant amounts of
time and energy to help you realize your technical vision of how Debian
should be assembled.

And yet, every time I see you in a Debian architectural discussion, you're
fighting with everyone in sight as if you're losing.  You come across as
the most furious winner of an argument I can remember seeing.  This is
directly undermining what you're attempting to achieve, because the sheer
vehemence of the way that you argue every point you care about means that
even people who agree with you don't want to help you get things done
because even being around this level of fighting is deeply exhausting.

A lot of this hasn't been on Policy, although you do have some of the same
tendency to reply to everything you disagree with until people stop
disagreeing even here.  But elsewhere, including the Technical Committee
discussion that I assume you were referring to above, it happens a lot.  I
can only assume that you think you have to shove harder and harder to get
things to move faster, but this isn't how anything works, particularly in
a volunteer organization.  People work on things they enjoy working on.
Calm and productive technical work is enjoyable to a lot of us.  Watching
people fight is not enjoyable.  What you're actually accomplishing is
building a subconscious emotional association in the brains of people who
are watching and reading between your name and angry arguments.  You are
literally training people to avoid you.

You are never going to convince people to stop disagreeing with you.
Never.  We have a process for 

Bug#1032104: Still present in Bookworm

[Timothy Pearson]

We've started hitting this on a busy server after upgrading to Bookworm:

2023-09-07 17:00:31 0 [Warning] You need to use --log-bin to make 
--expire-logs-days or --binlog-expire-logs-seconds work.
2023-09-07 17:00:31 0 [Note] Server socket created on IP: '127.0.0.1'.
2023-09-07 17:00:31 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.11.3-MariaDB-1'  socket: '/run/mysqld/mysqld.sock'  port: 3306  
Debian 12
2023-09-07 17:00:31 0 [Note] InnoDB: Buffer pool(s) load completed at 230907 
17:00:31
2023-09-07 20:35:06 8630 [ERROR] InnoDB: Database page corruption on disk or a 
failed read of file './database/data_table.ibd' page [page id: space=393, page 
number=1534]. You may have to recover from a backup.
2023-09-07 20:35:06 8630 [Note] InnoDB: Page dump (8192 bytes):
2023-09-07 20:35:06 8630 [Note] InnoDB: 
86c518ee05fe05fd05ff00067ee5a53145bf
2023-09-07 20:35:06 8630 [Note] InnoDB: 
0189000f3eff803d3e030002003a003b
2023-09-07 20:35:06 8630 [Note] InnoDB: 
045a6881
2023-09-07 20:35:06 8630 [Note] InnoDB: 
12d4ae6314accb64e0a8630400b55a4b8f6557796d5eb10dee577503
2023-09-07 20:35:06 8630 [Note] InnoDB: 
c64ee090070c90e9fd7e2014256e140c31c2b84d193051d88fefebbe72b9caaa
2023-09-07 20:35:06 8630 [Note] InnoDB: 
aa36b4985494699461a42852fe41a48ca248f91b5186496a1009f10320bc42d6
2023-09-07 20:35:06 8630 [Note] InnoDB: 
bef79c7b6fd53d7546a73df0b5caf5d53d6b7dafb5f63ed7ba3bdddbd7ceaeb5
2023-09-07 20:35:06 8630 [Note] InnoDB: 
7fbefdb3d5e7b58ff2e2804eeedd3fa674ba789fee9547e9f8f4e4deebc7f4ee
2023-09-07 20:35:06 8630 [Note] InnoDB: 
e2f1bb2fef53393d3a7ef96be5e8f0e5d716f9381d3fb9f7069da6c5c1f26727
2023-09-07 20:35:06 8630 [Note] InnoDB: 
f71eec7ff5de57d2f13bf71e3c3a7aefbdc5e1c3ee95f4b013f28b27ef3f54c6
2023-09-07 20:35:06 8630 [Note] InnoDB: 
a44aac65a0646a544255978c7554b3d05652ff28ff3d12da3fdd5efff9cceaf3
2023-09-07 20:35:06 8630 [Note] InnoDB: 
f9bf6a9f7ff9853ffef2f667ff3bd7b2d4e43c9134ae70a69088490b1b6d0a2a
2023-09-07 20:35:06 8630 [Note] InnoDB: 
7852f8bd97ae751feb1e0c1cfc7c6e0ebe4e3fa483e3270d8074ce09a77dd245
2023-09-07 20:35:06 8630 [Note] InnoDB: 
7b321c284b67524ec12525580ed8b742c631dfbc3f85d9daa0133952d6280ab5
2023-09-07 20:35:06 8630 [Note] InnoDB: 
b028926a9456a6500d8b15e6dbdd7707ccfffbd4f27e1f7fa0c1705e0ac79c95
2023-09-07 20:35:06 8630 [Note] InnoDB: 
cb1c44c93269ca8695676d4b60dec9fa10388efff6fff4b8bfb4fd39e0a72cbc
2023-09-07 20:35:06 8630 [Note] InnoDB: 
2c26daacaab2c20a5d3c809baa6355a29415feadbaffc5dcf8df4a070774daa5
2023-09-07 20:35:06 8630 [Note] InnoDB: 
c3da80d40684a565112db9a26a55896ba254bda7ec8a14b6e4818191d0710eae
2023-09-07 20:35:06 8630 [Note] InnoDB: 
ffd31407316a8a3a3b67854825e69482cd5278958b032f3d077bddf7060e7e39
2023-09-07 20:35:06 8630 [Note] InnoDB: 
3707f7d3c9a3ee0de2c7402254c39102f08aaa751445db2475cd35e8685cd241
2023-09-07 20:35:06 8630 [Note] InnoDB: 
ca5a060a7623c719f8d4c15417184e5c925146061b0c33eace07e3654ac58283
2023-09-07 20:35:06 8630 [Note] InnoDB: 
9e81e7bb3707067e357f172c96c5bc4c3fb28c311738666b63b5a1c860220aa0
2023-09-07 20:35:06 8630 [Note] InnoDB: 
ea628c8f9b06d8c48ca3defbd054de0ba98c660bd12a7c93641f3102285b6f63
2023-09-07 20:35:06 8630 [Note] InnoDB: 
492a8715ea9bdd5b03ea5fcf8e3a1d1086f6c93bb46ce0200b5b4c7b2f7d724e
2023-09-07 20:35:06 8630 [Note] InnoDB: 
3b5652b28dca5a5b83e5b0067e316c1cfbcdff9cca78100163d44aad35a66921
2023-09-07 20:35:06 8630 [Note] InnoDB: 
937c44fb57a525c7487685fd56f79d01fb6fe6c6fe95633a39e9904384371482
2023-09-07 20:35:06 8630 [Note] InnoDB: 
6b4e967c102a455d6d515a4b9b4375687965fd00fe72dc38fadb7f3f95791fdb
2023-09-07 20:35:06 8630 [Note] InnoDB: 
2a11ca05cc561d42162260b21699bc9414d3d9e54df77f73a37f351d3ea4e325
2023-09-07 20:35:06 8630 [Note] InnoDB: 
8050b35656b1e06c6370b93a8995a46b72a8f694f3007c2b641cf38dbda98cd7
2023-09-07 20:35:06 8630 [Note] InnoDB: 
a48553598548c280670cba5c94773561b4b0952bcccf76af0f987ffb34aa7db9
2023-09-07 20:35:06 8630 [Note] InnoDB: 
da83ab46d59443abbb1c83748c1fa4429cbc4a7abbcc2726da07a6d092d1de60
2023-09-07 20:35:06 8630 [Note] InnoDB: 
60586da9266b52a02a5bad83578c939dbdb63f44ce57df8b9372f4f8f0b47bb3
2023-09-07 20:35:06 8630 [Note] InnoDB: 
89b2e5682e3a20d55201371592229a9a527602722e665a36ddaac47743c739d8
2023-09-07 20:35:06 8630 [Note] InnoDB: 
fbc7290ed890434547634df499547186a3935240d529cb7dc637da66ff037373
2023-09-07 20:35:06 8630 [Note] InnoDB: 
d06fa7878b93533a6e304cb04a64af183c44e858283cfcc0d79065117993fa9d
2023-09-07 20:35:06 8630 [Note] InnoDB: 
c071fc2ffc5d8f7bb4cb33a5040e72c56c0f6d7114c8298af83236d5bb7ebedf
2023-09-07 20:35:06 8630 [Note] InnoDB: 
e886dcef7f706efc5f5df069f7e034adbad689e8bc434f1379a36cc88692a4a2
2023-09-07 20:35:06 8630 [Note] InnoDB: 
30dcbca8d10de02f468d237ff1afa7328f0de25451b10a7210b34d356b2f8268
2023-09-07 20:35:06 8630 [Note] InnoDB: 
d97769691c2e56ff879e6ef52f2d092bacf0a86a4c55845ca3774a90909804d9
2023-09-07 20:35:06 8630 [Note] InnoDB: 

Bug#1049418: xfce4-pulseaudio-plugin: Please loosen Recommends, and allow pipewire-pulse as an alternative to pulseaudio

[Arnaud Rebillout]

On 08/09/2023 02:30, Yves-Alexis Perez wrote:
I have no idea what pipewire is, could you explain a bit here what it 
is? Is
it a drop-in for pulseaudio or something? Because 
xfce4-pulseaudio-plugin is

(by definition) really linked to pulseaudio.


Hello Yves-Alexis,

Pipewire - https://pipewire.org/ - is a sound server, similar to 
Pulseaudio, but wider in scope, as it handles both audio and video 
streams. It also aims to support both consumer-grade and pro audio, so 
in the long-term it might replace both Pulseaudio and JACK.


The initial release 0.1.0 was in June 2017. Since then, it has become 
the default sound server in GNOME: in April 2021 for Fedora 34, then in 
Ubuntu 22.10 and finally Debian bookworm.


pipewire itself is not a drop-in replacement, however the associated 
daemon pipewire-pulse is. Quoting the man page:


> pipewire-pulse starts a PulseAudio-compatible daemon that integrates 
with the PipeWire media server. This daemon is a drop-in replacement for 
the PulseAudio daemon.


For more details, I recommend 
https://bootlin.com/blog/an-introduction-to-pipewire/, paragraph "API 
and backward compatibility" (1 minute read).


The introduction from https://wiki.debian.org/PipeWire also gives a good 
overview.



And if we have a drop-in replacement, does it really make sense to 
have every
pulseaudio depending package to use alternate dependencies? Isn't 
there a way

to centralize this change?


This was discussed at https://bugs.debian.org/992686. In short, the 
maintainer believe it's better to let each package "opt-in" by depending 
either on pulseaudio or pipewire-pulse, rather than making the package 
pipewire-pulse provide pulseaudio. The discussion explains why.


Having the dependency be "pulseaudio | pipewire-pulse" (in this order) 
won't change the fact that pulseaudio is favored by apt (during an 
installation of Debian with XFCE desktop, for example). So it shouldn't 
change anything for XFCE. However it will make life easier for users (or 
derivatives) who are willing to switch and completely replace pulseaudio.


A data point: I noticed that KDE's followed this route for their audio 
applet plasma-pa, cf. https://bugs.debian.org/994224 (unfortunately the 
bug report doesn't include any discussion).


Another thing that you might want to know. Both packages pulseaudio and 
pipewire-pulse are co-installable, however when both are installed, only 
the daemon pipewire-pulse is started. It's done at the systemd level, as 
can be seen in this file:


    $ cat /lib/systemd/user/pipewire-pulse.service
    [...]
    Conflicts=pulseaudio.service

So in effect, it's pretty easy to test if pipewire-pulse works well for 
you, just install it and reboot.


Hope that it answers all your questions!

Best,

--

Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1051440: RM: lablgtk2 -- ROM; depends on obsolete library

[Stéphane Glondu]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: lablg...@packages.debian.org, debian-ocaml-ma...@lists.debian.org
Control: affects -1 + src:lablgtk2

Dear FTP team,

With unison-2.52 removal (#1050381), lablgtk2 will no longer have
reverse dependencies. It is time to remove it.


Cheers,

-- 
Stéphane

Bug#1051439: elogind: FTBFS: Please add support for loongarch64

[zhangdandan]

Source: elogind
Version: 246.10
Severity: wishlist
Tags: patch ftbfs
User: debian-de...@lists.debian.org
Usertags: loongarch64

   Dear maintainers,

The LoongArch architecture has been supported in elogind upstream 
(v252-stable) [1][2], please see the following link [3].
Please add support for loongarch64 (64-bit LoongArch) in elogind source 
package.


When compiling the package elogind 246.10-1debian1 for loong64 in the 
Debian Package Auto-Building environment [4], the full compilation log 
can be found at [5].


Would it be possible to include the support for LoongArch in the next 
upload?

Your opinions are welcome.
If you have any questions, you can contact me at any time.

[1]:https://github.com/elogind/elogind
[2]:https://github.com/elogind/elogind/tree/v252-stable
[3]:https://github.com/elogind/elogind/pull/231
[4]:https://buildd.debian.org/status/package.php?p=elogind+=sid
[5]:https://buildd.debian.org/status/fetch.php?pkg=elogind=loong64=246.10-1debian1=1693579178=0

thanks,
Dandan Zhang

Bug#1051411: fcoe-utils: Cyclic systemd unit dependencies

[tony mancill]

Hello Stefan,

On Thu, Sep 07, 2023 at 03:19:51PM +0200, Stefan Sterz wrote:
> the unit file "fcoe-utils.service" included in this package contains
> these two lines:
> 
> After=lldpad.service
> Before=network.target
> 
> The package lldpad's "lldpad.service" unit file states this:
> 
> After=network.target
> 
> This leads to a circular dependency where systemd can't start
> fcoe-utils.service after lldpad.service and before network.target while
> also starting lldpad.service after network.target. Hence, systemd breaks
> this circular dependency by not starting one of the services.
> 
> If I understand correctly, to reliably be able to start both services,
> one of these dependencies needs to be changed. From what I can tell,
> from the Github repository, fcoe-utils.service should be started after
> network.target [1]. The unit file there includes this "After" line:
> 
> After=syslog.target network.target

Thank you for the bug report.  My initial instinct is to use the same
unit file and service dependencies as upstream.  Looking at the history
of Debian's patch [2] of the unit file, and specifically this commit
[3], it appears that the change was made to resolve an issue.

The patch to the systemd unit file predates my involvement with this
package, so Valentin may be able to provide more context.  Perhaps
there was a bug in fcoe-utils that necessitated the change at that time,
but we can now revert to the unit file patch?

Valentin, do you have any insight on this?  Without a link to the
original bug, I'm unsure what regression reverting to the upstream unit
file dependencies might cause.

Cheers,
tony
 
[1]: https://github.com/openSUSE/fcoe-utils/blob/master/etc/systemd/fcoe.service
[2]: 
https://salsa.debian.org/fcoe-team/fcoe-utils/-/commits/master/debian/patches/fix-systemd-service.patch
[3]: 
https://salsa.debian.org/fcoe-team/fcoe-utils/-/commit/1519b5cdd46710bf8f19e8662aa0999023c8cabb


signature.asc
Description: PGP signature

Bug#1051351: graphviz: Please package a new upstream version

[Eugene Toder]

Hi László,

Thank you for the quick response. I agree, uploading it to experimental
will make it easier for us (end users) to test it.

On Thu, Sep 7, 2023, 02:50 László Böszörményi (GCS)  wrote:

> Hi Eugene,
>
> On Wed, Sep 6, 2023 at 8:36 PM Eugene Toder  wrote:
> > It appears that the upstream version of graphviz was last updated in
> > September 2019, i.e. almost 4 years ago. Several new versions were
> > released since then with many bug fixes. Please package a new version.
>  I've already received several reports of this. As noted in these,
> I've the newest package version v8.1.0 ready [1]. As it's a big
> upstream release and I've split the original; packages to several
> others it needs testing. Some of it is already done, but I look
> forward your findings if any.
> In short, I think I should upload it to experimental to make it more
> visible for you, end users.
>
> Regards,
> Laszlo/GCS
> [1] dget -x https://people.debian.org/~gcs/graphviz_8.1.0-1.dsc
>

Bug#1016558: ITA: muse-el

[Nicholas D Steeves]

Manphiz  writes:

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

Wonderful, there's no rush.  As ever, in Debian, you don't need to do
something you don't want to do.

>> Do you mind if I enhance this significantly?  Find proposal in-line, at
>> the end of the email.
>
> No problem!  Patch applied, rebuilt, and reuploaded to mentors[1].
> PTAL.

LGTM!

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

Much obliged.

Please refinalise with 'dch -r' and commit with something like "Actually
release 3.20+dfsg-8 to unstable" (or sid, as you prefer!).  Then push.
Please create an annotated tag called "debian/3.20+dfsg-8", but don't
push that tag until you receive the "ACCEPTED" email from
ftp-masters/the archive.  It will most likely be less than 24h in
between pushing the release commit and pushing the tag, during which
time you'll be waiting for me to actually make the upload.

As for why?  Well, there's some ambiguity now about whether
commit:02e95c1 was 3.20+dfsg-8, the fix is easy, and the delay is only
another day or two.

After this, the package is truly ready.
Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Luca Boccassi]

On Fri, 8 Sept 2023 at 00:37, gregor herrmann  wrote:
>
> On Thu, 07 Sep 2023 21:28:15 +0100, Luca Boccassi wrote:
>
> > Yes, that is fine by me, as explained in later replies my main
> > intention is to fix the issue that some wording is being used to
> > reintroduce things that should not be reintroduced
>
> If I understand you correctly, "Reintroduc[ing] things that should not be
> reintroduced" means not acting on bug reports where someone says
> "Please change #!/usr/bin/sh back to #!/bin/sh".
>
> If I'm understanding the technical question correctly, "#!/bin/sh"
> works for both merged-/usr and split-/usr, while "#!/usr/bin/sh" works
> only for merged-/usr and breaks for split-/usr.
>
> Now, how to handle this situation? In my naïve point of view and a
> bit late at night I see two options for maintainers. They can say …

The entire point of the decision that applies since bookworm is that
there is only one supported form. That's not an accident, it is the
entire point of the whole thing. As in, there is no such thing as
"breaks split-/usr" because split-usr is no longer a thing that exists
in Debian stable/backports/testing/unstable/experimental.

> I'm a bit sad that many discussions in Debian (like this one) turn
> into the "my way or the highway" lane, and I'd rather see a way of
> cooperation which gives more leeway to others and take small extra
> steps to accomodate minorities, when it doesn't have any actual cost.

And I am more than a bit sad that sensible, clear-cut, binding and
already-implemented decisions taken by our constitutional bodies get
constantly second-guessed and belittled because of an irrational
attachment to inconsequential accidents of history. But what can we
do, we'll just have to be sad together, I guess.

Aside from that, in the future please avoid using the word
'minorities' when talking about silly things such as liking or
disliking symlinks, as in common English it is used to refer to much
more serious matters.

Bug#1051438: transition: omniorb-dfsg

[Santiago Ruano Rincón]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: omniorb-d...@packages.debian.org, 1042...@bugs.debian.org
Control: affects -1 + src:omniorb-dfsg

Dear release team,

Could you please schedule a transition for omniorb-dfsg 4.3.0. There has
been an ABI bump since 4.2.0. There are four reverse dependencies
listed: omnievents, tango, pytango and logservice. logservice has been
remove from unstable and testing. It is only available in buster.

I have checked how omnievent, tango and pytango:

* tango (don't pay attention the "omniorb-dfsg" in the URL. those
pipelines are run as child pipelines inside omniorb-dfsg:
amd64: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671324
i386: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671325
autopkgtest: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671332

* pytango:
amd64: https://salsa.debian.org/santiago/pytango/-/jobs/4671408
i386: https://salsa.debian.org/santiago/pytango/-/jobs/4671409
(setup autopkgtest in Salsa CI for it is not straightforward yet (WiP!))

* omnievents (orphaned package):
amd64: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4649320
i386: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4649322
it doesn't include autopkgtest

binNMU will be required for them.

Ben file:

title = "omniorb-dfsg";
is_affected = .depends ~ ""/libcos4-2|libomniorb4-2/"" | .depends ~ 
""/libcos4-3|libomniorb4-3/"";
is_good = .depends ~ ""/libcos4-3|libomniorb4-3/"";
is_bad = .depends ~ ""/libcos4-2|libomniorb4-2/"";

Thanks,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1051436: closed by Jeremy Bícha (Re: Bug#1051436: Cannot install Abiword without Evolution-Data-Server)

[debian2023]

On 23/09/07 11:30, Debian Bug Tracking System wrote:
>
>It has been closed by Jeremy Bícha .
>
>Upstream only provides a single library file for abiword. I am not
>going to disable features for everyone just because you don't like
>having certain other packages installed on your system.

Thanks for the clarification. I wrongly assumed that it was a packaging 
issue, not an upstream one. It is clearly not the job of the maintainer 
to split upstream code.

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[gregor herrmann]

On Thu, 07 Sep 2023 21:28:15 +0100, Luca Boccassi wrote:

> Yes, that is fine by me, as explained in later replies my main
> intention is to fix the issue that some wording is being used to
> reintroduce things that should not be reintroduced

If I understand you correctly, "Reintroduc[ing] things that should not be
reintroduced" means not acting on bug reports where someone says
"Please change #!/usr/bin/sh back to #!/bin/sh".

If I'm understanding the technical question correctly, "#!/bin/sh"
works for both merged-/usr and split-/usr, while "#!/usr/bin/sh" works
only for merged-/usr and breaks for split-/usr.

Now, how to handle this situation? In my naïve point of view and a
bit late at night I see two options for maintainers. They can say …

1) "Well, right, *sigh*, ok, let's take the five minutes to change
   this back to "#!/bin/sh", and everyone's happy."

… or …

2) "No way, we are usr-merge, resistence is futile, go  yourself, "#!/usr/bin/sh" is the default, bad luck for
   you 111"


I'm a bit sad that many discussions in Debian (like this one) turn
into the "my way or the highway" lane, and I'd rather see a way of
cooperation which gives more leeway to others and take small extra
steps to accomodate minorities, when it doesn't have any actual cost.


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#1051437: RM: gnome-metronome -- RoQA; RC-buggy; replaced by completely new rust app

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:gnome-metronome

gnome-metronome has a RC bug that kept it from being released with bookworm. This will not be fixed because the app was 
replaced by a new one written in Rust. So please remove this dead implementation. The Rust app can be packaged as 
reintroduction if anybody volunteers to package it.

Bug#1051355: Also affects jquery-timepicker and phpsysinfo

[William Desportes]

This is probably what crashes the test suite of jquery-timepicker and 
phpsysinfo: 
https://ci.debian.net/data/autopkgtest/testing/amd64/j/jquery-timepicker/37547785/log.gz

phpsysinfo does not show up for now since I just realized failures where not 
detected in a proper way. The fix is uploaded.
One crash can be seen in: 
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/phpsysinfo/37551390/log.gz
With the fix the same one as jquery-timepicker shows up.

Here are some crash logs of the chrome webdriver using sid and phpsysinfo 
autopkgtest:

ERROR: test_dynamic_page (__main__.TestPhpSysinfoWeb.test_dynamic_page)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest.Rf2SdY/build.r15/src/./debian/tests/test_phpsysinfo_web.py", 
line 48, in test_dynamic_page
    WebDriverWait(self.driver, 60).until(lambda x: x.find_element(By.ID, 
"s_processes").text != "")
  File "/usr/lib/python3/dist-packages/selenium/webdriver/support/wait.py", 
line 86, in until
    value = method(self._driver)
    
  File "/tmp/autopkgtest.Rf2SdY/build.r15/src/./debian/tests/test_phpsysinfo_web.py", 
line 48, in 
    WebDriverWait(self.driver, 60).until(lambda x: x.find_element(By.ID, 
"s_processes").text != "")

  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", 
line 738, in find_element
    return self.execute(Command.FIND_ELEMENT, {"using": by, "value": 
value})["value"]
^
  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", 
line 344, in execute
    self.error_handler.check_response(response)
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/remote/errorhandler.py", 
line 229, in check_response
    raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.WebDriverException: Message: unknown error: session 
deleted because of page crash
from unknown error: cannot determine loading status
from tab crashed
  (Session info: headless chrome=116.0.5845.180)
Stacktrace:
#0 0x55876cf735aa 
#1 0x55876cc95b89 
#2 0x55876cc8265c 
#3 0x55876cc81be9 
#4 0x55876cc80d3e 
#5 0x55876cc80bda 
#6 0x55876cc7faa9 
#7 0x55876cc800a5 
#8 0x55876cc8e218 
#9 0x55876cc8f059 
#10 0x55876cc9fd63 
#11 0x55876cca3e98 
#12 0x55876cc805a1 
#13 0x55876cc9fa0f 
#14 0x55876cd0acc2 
#15 0x55876ccf364a 
#16 0x55876ccc735b 
#17 0x55876ccc8936 
#18 0x55876cf40fbc 
#19 0x55876cf44113 
#20 0x55876cf43baa 
#21 0x55876cf445fc 
#22 0x55876cf4acda 
#23 0x55876cf44987 
#24 0x55876cf1cdf1 
#25 0x55876cf5dd99 
#26 0x55876cf5df93 
#27 0x55876cf6c243 
#28 0x7ff4384a63ec 


==
ERROR: test_dynamic_page (__main__.TestPhpSysinfoWeb.test_dynamic_page)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest.Rf2SdY/build.r15/src/./debian/tests/test_phpsysinfo_web.py", 
line 23, in tearDown
    self.driver.close()
  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", 
line 455, in close
    self.execute(Command.CLOSE)
  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", 
line 344, in execute
    self.error_handler.check_response(response)
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/remote/errorhandler.py", 
line 229, in check_response
    raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.InvalidSessionIdException: Message: invalid session 
id
Stacktrace:
#0 0x55876cf735aa 
#1 0x55876cc95b89 
#2 0x55876ccc6ed8 
#3 0x55876ccc8936 
#4 0x55876cf40fbc 
#5 0x55876cf44113 
#6 0x55876cf43baa 
#7 0x55876cf445fc 
#8 0x55876cf4acda 
#9 0x55876cf44987 
#10 0x55876cf1cdf1 
#11 0x55876cf5dd99 
#12 0x55876cf5df93 
#13 0x55876cf6c243 
#14 0x7ff4384a63ec 


==
ERROR: test_static_page (__main__.TestPhpSysinfoWeb.test_static_page)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest.Rf2SdY/build.r15/src/./debian/tests/test_phpsysinfo_web.py", 
line 29, in test_static_page
    vitals = WebDriverWait(self.driver, 60).until(lambda x: x.find_element(By.ID, 
"vitals"))
^^^
  File "/usr/lib/python3/dist-packages/selenium/webdriver/support/wait.py", 
line 86, in until
    value = method(self._driver)
    
  File "/tmp/autopkgtest.Rf2SdY/build.r15/src/./debian/tests/test_phpsysinfo_web.py", 
line 29, in 
    vitals = WebDriverWait(self.driver, 60).until(lambda x: x.find_element(By.ID, 
"vitals"))
^^^
  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", 
line 738, in find_element
    

Bug#1051436: Cannot install Abiword without Evolution-Data-Server

[debian2023]

Package: abiword
Version: 3.0.5~dfsg-3.2

For the last 20 years, I’ve always recommended abiword as a very 
lightweihgt alternative to libreoffice, perfect for older systems low on 
ressource.

I’ve only realized that installing abiword is not possible without also 
installing evolution-data-server, which is quite a hard requirement and 
a strange one for a small word processor.

libabiword seems to depend of a lot of package which should probably be 
optional.

Bug#1051435: python-pytest-asyncio: failing autopkgtest

[Timo Röhling]

Source: python-pytest-asyncio
Version: 0.20.3-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package started failing its autopkgtest because python-hypothesis gained a 
new health check.
Relevant autopkgtest log excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pytest-asyncio/37548165/log.gz

 34s === FAILURES 
===
 34s ___ TestTwo.test_hypothesis 

 34s tests/hypothesis/test_inherited_test.py:8: in test_hypothesis
 34s @given(value=st.integers())
 34s E   hypothesis.errors.FailedHealthCheck: The method 
BaseClass.test_hypothesis was called from multiple different executors. This 
may lead to flaky tests and nonreproducible errors when replaying from database.
 34s E   See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for 
more information about this. If you want to disable just this health check, add 
HealthCheck.differing_executors to the suppress_health_check settings for this 
test.


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmT6TyEACgkQ+C8H+466
LVkQtAwA40RJWbOIQVar32o5ldh8hXMDWs64+01f+RSzKPAJTuov69jOwat7oW3z
yQ+SKaEEmuolmmnFTRe7SqkjxmY8SWWjjWTliqc+kqCCWWEiOQNqMplbiA2yQ97v
w/zEJk2XI063XEtF1EG4pz78a0PMJEW27vEYDMhuqH3rqfIGjnq1whiLGo2bc3xd
felvm1wr8xgzin/tQfRuV/pZqzAfMZ7pzYR5VES3T11DBgU8HWFE9RWUo0314I3U
fsQvk63Khv9gtquJACIxN9TbUKjGcgyXc1LczpFgs11zAN9AeruMo4F5Anp3rM1D
6RxcfEgCiw8KhRuoi2+V1C/6vLNCPseqbcUt2f+xg2PZV/EKFHbEkalqFJPCq7OC
CV2ErrOT7wSMML3Fu2b2DOPGJWw4HGD4IwB1pcdJ4BUUxfeophWFq3kM7btu6IoX
aFlUhFNwXCCkkSSWR1lbn++ceB2b3c1auDcIqax8yPRTJ2WOutXSvzdQyXNLOQ5C
nRuuGgxu
=NDil
-END PGP SIGNATURE-

Bug#1051434: python-h2: failing autopkgtest

[Timo Röhling]

Source: python-h2
Version: 4.1.0-4
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package started failing its autopkgtest because python-hypothesis gained a 
new health check.
Relevant autopkgtest log excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-h2/37548164/log.gz

[...]
 27s 
 27s === FAILURES 
===
 27s _ 
TestFilter.test_range_of_acceptable_outputs[hdr_validation_flags0-validate_outbound_headers]
 _
 27s 
 27s self = 
 27s validation_function = 
 27s hdr_validation_flags = HeaderValidationFlags(is_client=True, 
is_trailer=True, is_response_header=True, is_push_promise=True)
 27s 
 27s @pytest.mark.parametrize('validation_function', validation_functions)
 27s >   @pytest.mark.parametrize('hdr_validation_flags', hdr_validation_combos)
 27s E   hypothesis.errors.FailedHealthCheck: The method 
TestFilter.test_range_of_acceptable_outputs was called from multiple different 
executors. This may lead to flaky tests and nonreproducible errors when 
replaying from database.
 27s E   See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for 
more information about this. If you want to disable just this health check, add 
HealthCheck.differing_executors to the suppress_health_check settings for this 
test.
 27s 
 27s test/test_invalid_headers.py:509: FailedHealthCheck
 27s _ 
TestFilter.test_range_of_acceptable_outputs[hdr_validation_flags1-validate_headers]
 _
 27s 
 27s self = 
 27s validation_function = 
 27s hdr_validation_flags = HeaderValidationFlags(is_client=True, 
is_trailer=True, is_response_header=True, is_push_promise=False)
 27s 
 27s @pytest.mark.parametrize('validation_function', validation_functions)
 27s >   @pytest.mark.parametrize('hdr_validation_flags', hdr_validation_combos)
 27s E   hypothesis.errors.FailedHealthCheck: The method 
TestFilter.test_range_of_acceptable_outputs was called from multiple different 
executors. This may lead to flaky tests and nonreproducible errors when 
replaying from database.
 27s E   See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for 
more information about this. If you want to disable just this health check, add 
HealthCheck.differing_executors to the suppress_health_check settings for this 
test.
 27s 
[...]


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmT6TbAACgkQ+C8H+466
LVnEigv/XHJJjJlTFpvNji7aBNeNCnYzjCvNQMWNMc2Q1URGZnUF28Xnx/gl3SRF
+DHngXG3JLBbL0YRZ3Wz/CdEkGlV0rbR8VbGEiSvIwHv5QjB28Vnu2NJPLK5AMWi
9H7WECs6XMYADAvwEFiTIOR3VJ7Erv95HahIHDJictQ1Vui1tt03VeycAxJky/J7
+N0R2F9j1TwZgjG/oad+rEbZDhqqeloNRIHIsT0OuPXzpkR1jm6Xafw5KCv7GqOB
TnfSMc81VkG8uGib9UlXtuSv2pTppIoSnnJu0s42CqF+zZMTn5zfq0SuyzqHbn45
Fl+8dSpmmxor3RpDn/9oTV9NWzayp/8tRMwG5ZEvhvYwZ2iZRC8erNr9YhpkSykw
yiSCizPLZgRI05rnzt2ZUpzFfo2iGTfSLCDpLzP8WYcaKUSQtvPC188i2FE1kRhD
14UV3g/Qsb2IDYeJeUeiudChSPt0BzDvuwpkJ2+1IdpBlbiPpIGlzCVLRsvStmFW
+DSqehCB
=6Bju
-END PGP SIGNATURE-

Bug#487216: ITP: ultrastardx -- singing competition game

[Thorsten Glaser]

Hi,

I stumbled upon this program by a message in the Performous issue tracker
https://github.com/performous/performous/issues/17#issuecomment-1710604240
and I’m curious about this software because its wiki says it only needs
OpenGL 1.2 (I can’t run Performous on my Thinkpad except with 5 fps Mesa
software rendering because it needs too new OpenGL).

What’s the status of this (and the relicencing/replacing)?

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

Bug#1051432: further info

[Terrance Hendrik]

bluetoothctl

[MX Anywhere 3]# info
Device E5:9F:06:B5:08:8D (random)
Name: MX Anywhere 3
Alias: MX Anywhere 3
Appearance: 0x03c2 (962)
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: no
LegacyPairing: no
UUID: Generic Access Profile(1800--1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (1801--1000-8000-00805f9b34fb)
UUID: Device Information(180a--1000-8000-00805f9b34fb)
UUID: Battery Service   (180f--1000-8000-00805f9b34fb)
UUID: Human Interface Device(1812--1000-8000-00805f9b34fb)
UUID: Vendor specific   (0001--1000-8000-011f246d)
Modalias: usb:v046DpB025d0014
Battery Percentage: 0x4b (75)

Bug#1050381: Bug#1041789: RM: unison-2.51+4.13.1 -- RoQA; newer version packaged

[Bastian Germann]

On Sat, 2 Sep 2023 15:32:37 +0200 glo...@debian.org wrote:
I'll wait for unison-2.53 and meta-unison to migrate to testing, and 
then I'll ask for the removal of unison-2.52.


Quick reminder. Please also file a lablgtk2 removal bug.

Bug#1051433: mysql-workbench: FTBFS: error: ‘int64_t’ has not been declared in ‘std’

[Aurelien Jarno]

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


Dear maintainer,

mysql-workbench fails to build from source. From my build log on amd64:
| 
| cd /<>/obj-x86_64-linux-gnu/library/base && /usr/bin/c++ 
-DBOOST_ALL_NO_LIB -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED 
-DGTK_DISABLE_SINGLE_INCLUDES -DRAPIDJSON_HAS_STDSTRING -D__STDC_FORMAT_MACROS 
-Dwbbase_EXPORTS -I/<>/library/base 
-I/<>/backend/wbprivate 
-I/<>/backend/wbprivate/workbench -isystem /usr/include/gtkmm-3.0 
-isystem /usr/lib/x86_64-linux-gnu/gtkmm-3.0/include -isystem 
/usr/include/giomm-2.4 -isystem /usr/lib/x86_64-linux-gnu/giomm-2.4/include 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/x86_64-linux-gnu/glib-2.0/include -isystem /usr/include/libmount 
-isystem /usr/include/blkid -isystem /usr/include/glibmm-2.4 -isystem 
/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -isystem /usr/include/sigc++-2.0 
-isystem /usr/lib/x86_64-linux-gnu/sigc++-2.0/include -isystem 
/usr/include/gtk-3.0 -isystem /usr/include/pango-1.0 -isystem 
/usr/include/harfbuzz -isystem /usr/include/freetype2 -isystem 
/usr/include/libpng16 -isystem /usr/include/fribidi -isystem /usr/include/cairo 
-isystem /usr/include/pixman-1 -isystem /usr/include/gdk-pixbuf-2.0 -isystem 
/usr/include/gio-unix-2.0 -isystem /usr/include/cloudproviders -isystem 
/usr/include/atk-1.0 -isystem /usr/include/at-spi2-atk/2.0 -isystem 
/usr/include/at-spi-2.0 -isystem /usr/include/dbus-1.0 -isystem 
/usr/lib/x86_64-linux-gnu/dbus-1.0/include -isystem /usr/include/cairomm-1.0 
-isystem /usr/lib/x86_64-linux-gnu/cairomm-1.0/include -isystem 
/usr/include/pangomm-1.4 -isystem /usr/lib/x86_64-linux-gnu/pangomm-1.4/include 
-isystem /usr/include/atkmm-1.6 -isystem 
/usr/lib/x86_64-linux-gnu/atkmm-1.6/include -isystem 
/usr/include/gtk-3.0/unix-print -isystem /usr/include/gdkmm-3.0 -isystem 
/usr/lib/x86_64-linux-gnu/gdkmm-3.0/include -isystem /<>/res 
-isystem /usr/include/python3.11 -isystem /usr/include/libxml2 -isystem 
/usr/include/gdal -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 
-Wno-error=deprecated-declarations -Wno-error=maybe-uninitialized -std=gnu++17 
-fPIC -Wall -Wextra -Wno-unused-parameter -Wno-deprecated -Wno-deprecated-copy 
-Wno-deprecated-declarations -Werror -Wno-nonnull -MD -MT 
library/base/CMakeFiles/wbbase.dir/util_functions.cpp.o -MF 
CMakeFiles/wbbase.dir/util_functions.cpp.o.d -o 
CMakeFiles/wbbase.dir/util_functions.cpp.o -c 
/<>/library/base/util_functions.cpp
| In file included from /<>/library/base/util_functions.cpp:32:
| /<>/library/base/base/string_utilities.h:48:12: error: ‘int64_t’ 
has not been declared in ‘std’
|48 | using std::int64_t;
|   |^~~
| In file included from /<>/library/base/util_functions.cpp:77:
| /<>/library/base/base/util_functions.h:82:30: error: ‘int64_t’ 
in namespace ‘std’ does not name a type
|82 | BASELIBRARY_PUBLIC_FUNC std::int64_t get_physical_memory_size(void);
|   |  ^~~
| /<>/library/base/base/util_functions.h:84:30: error: ‘int64_t’ 
in namespace ‘std’ does not name a type
|84 | BASELIBRARY_PUBLIC_FUNC std::int64_t get_file_size(const char 
*filename);
|   |  ^~~
| /<>/library/base/util_functions.cpp:85:8: error: ‘int64_t’ in 
namespace ‘std’ does not name a type
|85 |   std::int64_t _memory_in_bytes;
|   |^~~
| /<>/library/base/util_functions.cpp: In function ‘int 
_get_hardware_info(hardware_info&)’:
| /<>/library/base/util_functions.cpp:557:8: error: ‘struct 
hardware_info’ has no member named ‘_memory_in_bytes’
|   557 |   info._memory_in_bytes = get_physical_memory_size();
|   |^~~~
| /<>/library/base/util_functions.cpp:557:27: error: 
‘get_physical_memory_size’ was not declared in this scope
|   557 |   info._memory_in_bytes = get_physical_memory_size();
|   |   ^~~~
| /<>/library/base/util_functions.cpp: In function ‘std::string 
get_local_hardware_info()’:
| /<>/library/base/util_functions.cpp:578:50: error: ‘struct 
hardware_info’ has no member named ‘_memory_in_bytes’
|   578 |   hardware_string << " - " << base::sizefmt(info._memory_in_bytes, 
false) << " RAM";
|   |  ^~~~
| /<>/library/base/util_functions.cpp: At global scope:
| /<>/library/base/util_functions.cpp:587:6: error: ‘int64_t’ in 
namespace ‘std’ does not name a type
|   587 | std::int64_t get_physical_memory_size() {
|   |  ^~~
| /<>/library/base/util_functions.cpp:652:6: error: ‘int64_t’ in 
namespace ‘std’ does not name a type
|   652 | std::int64_t get_file_size(const char *filename) {
|   |  ^~~
| make[4]: *** 

Bug#1051432: bluez 5.6.9 Some bluetooth mouse not working, problem persists

[Terrance Hendrik]

Package: bluez

Version: 5.6.9-1

Not sure if this issue is about bluez or other packages or modules

System info:

```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux trixie/sid
Release:n/a
Codename:   trixie

$ uname -a
Linux  6.4.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.13-1
(2023-08-31) x86_64 GNU/Linux

```

journalctl -f, after connected


```
Sep 08 04:57:06  blueman-manager[11378]: blueman-manager
04.57.06 WARNING  ManagerDeviceList:396 _monitor_power_levels: Failed
to get power levels, probably a LE device.
Sep 08 04:57:06  bluetoothd[1053]:
src/service.c:service_accept() input-hog profile accept failed for

Sep 08 04:57:06  bluetoothd[1053]:
src/service.c:service_accept() input-hog profile accept failed for

```

Bluetooth adapter: 8087:0026 Intel Corp. AX201 Bluetooth


Mouse is Logitech MX Anywhere 3, and MX Master 3. connected to Bluetooth.

Bug#1051431: libauthen-pam-perl FTCBFS: invokes ./configure without --host

[Helmut Grohne]

Source: libauthen-pam-perl
Version: 0.16-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libauthen-pam-perl fails to cross build from source, because ./configure
is run without --host and fails that way. It is run from Makefile.PL
without any arguments and this makes injecting the --host flag
particularly difficult. I propose making that configure invocation from
Makefile.PL optional. If it sees a config.status, it may assume that
configure was successful and skip it. In the packaging, we can then
simply configure before handing off to Makefile.PL and let
dh_auto_configure pass the right flag. I'm attaching a patch for your
convenience. Does that work for you?

Helmut
diff --minimal -Nru libauthen-pam-perl-0.16/debian/changelog 
libauthen-pam-perl-0.16/debian/changelog
--- libauthen-pam-perl-0.16/debian/changelog2022-06-15 17:58:51.0 
+0200
+++ libauthen-pam-perl-0.16/debian/changelog2023-09-07 22:23:44.0 
+0200
@@ -1,3 +1,10 @@
+libauthen-pam-perl (0.16-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Call ./configure with --host. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 07 Sep 2023 22:23:44 +0200
+
 libauthen-pam-perl (0.16-5) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru libauthen-pam-perl-0.16/debian/patches/cross.patch 
libauthen-pam-perl-0.16/debian/patches/cross.patch
--- libauthen-pam-perl-0.16/debian/patches/cross.patch  1970-01-01 
01:00:00.0 +0100
+++ libauthen-pam-perl-0.16/debian/patches/cross.patch  2023-09-07 
22:23:44.0 +0200
@@ -0,0 +1,15 @@
+--- libauthen-pam-perl-0.16.orig/Makefile.PL
 libauthen-pam-perl-0.16/Makefile.PL
+@@ -5,8 +5,10 @@
+ $ENV{'CC'} # If a compiler is not specified on the command line then
+   or $ENV{'CC'} = $Config{'cc'}; # use the one with which perl was built
+ 
+-system("./configure") == 0 or
+-  die "Error in configuring the Authen::PAM module.\n";
++if (! -e "./config.status") {
++  system("./configure") == 0 or
++die "Error in configuring the Authen::PAM module.\n";
++}
+ 
+ # returns a reference to anonymous hash which is then interpreted as
+ # additional options to the WriteMakeFile
diff --minimal -Nru libauthen-pam-perl-0.16/debian/patches/series 
libauthen-pam-perl-0.16/debian/patches/series
--- libauthen-pam-perl-0.16/debian/patches/series   2022-06-15 
17:58:51.0 +0200
+++ libauthen-pam-perl-0.16/debian/patches/series   2023-09-07 
22:23:44.0 +0200
@@ -1,2 +1,3 @@
 spelling.patch
 perl-inc.patch
+cross.patch
diff --minimal -Nru libauthen-pam-perl-0.16/debian/rules 
libauthen-pam-perl-0.16/debian/rules
--- libauthen-pam-perl-0.16/debian/rules2022-06-15 17:58:51.0 
+0200
+++ libauthen-pam-perl-0.16/debian/rules2023-09-07 22:23:42.0 
+0200
@@ -5,6 +5,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 override_dh_auto_configure:
+   dh_auto_configure --buildsystem=autoconf
dh_auto_configure --buildsystem=perl_makemaker
 
 override_dh_auto_test:

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Luca Boccassi]

On Thu, 7 Sept 2023 at 21:22, Helmut Grohne  wrote:
>
> Hi Luca,
>
> On Wed, Sep 06, 2023 at 10:50:14PM +0100, Luca Boccassi wrote:
> > Package: debian-policy
> > X-Debbugs-Cc: j...@debian.org hel...@subdivi.de
> >
> > Debian only supports merged-usr since Bookworm. We should update policy
> > to reference /usr/bin/sh and similar paths to describe recommended
> > shebangs for scripts.
>
> I disagree. The promise of merged-/usr has always been that both paths
> are valid. /bin/sh remains the location recommended by external
> standards and (like the dynamic loader path) should remain the way it
> is.
>
> > I heard many times the policy maintainers mention something along the
> > lines of 'policy should not be a hammer to beat other maintainers
> > with'. Today I saw policy being used to force a maintainer to re-add
> > support for the deprecated and unsupported split-usr filesystem layout,
> > as 'policy only mentions /bin/sh, not /usr/bin/sh'.
>
> This can also be addressed by adding a note to policy that allows
> maintainers to rely on the aliasing. If there was a need to refer to the
> shell via /usr/bin/sh, we would aim for eventually removing the aliasing
> symlinks. That's not what we're up to.
>
> > So let's update the policy to refer to modern and supported filesystem
> > paths as adopted by Debian de-facto and de-jure, and stop other
> > maintainers from getting beaten with it.
>
> I don't think this is right. We intend to finalize the /usr-merge
> transition by moving files from / to /usr. This is is an implementation
> strategy that arises from the constraints set by the current
> implementation of dpkg and other components. It is not a new filesystem
> layout that we expect upstreams to support. Rather, we promised to
> upstreams that both ways will work. The aspect that in a data.tar we'll
> have to install files to /usr is a technical one and can be supported by
> debhelper. Still, packages may assume that referencing files they
> installed to /usr via aliased paths in / will continue to work.
>
> > Patch attached and also pushed to
> > https://salsa.debian.org/bluca/policy/-/tree/bin_sh
>
> Nack to this particular change, but I agree that it is worth considering
> two changes to policy sooner and later:
>  * Making it explicit that referring to files via either paths for
>read-only consumption is ok.
>  * DEP17 aims for not installing any files in aliased locations and we
>should encode that in policy once there is wide adoption of this rule
>in binary packages.
>
> Would you agree to repurpose this bug to propose the former change?
> While my variant is weaker, it still prevents people from using policy
> to require supporting split-/usr.

Yes, that is fine by me, as explained in later replies my main
intention is to fix the issue that some wording is being used to
reintroduce things that should not be reintroduced

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Helmut Grohne]

Hi Luca,

On Wed, Sep 06, 2023 at 10:50:14PM +0100, Luca Boccassi wrote:
> Package: debian-policy
> X-Debbugs-Cc: j...@debian.org hel...@subdivi.de
> 
> Debian only supports merged-usr since Bookworm. We should update policy
> to reference /usr/bin/sh and similar paths to describe recommended
> shebangs for scripts.

I disagree. The promise of merged-/usr has always been that both paths
are valid. /bin/sh remains the location recommended by external
standards and (like the dynamic loader path) should remain the way it
is.

> I heard many times the policy maintainers mention something along the
> lines of 'policy should not be a hammer to beat other maintainers
> with'. Today I saw policy being used to force a maintainer to re-add
> support for the deprecated and unsupported split-usr filesystem layout,
> as 'policy only mentions /bin/sh, not /usr/bin/sh'.

This can also be addressed by adding a note to policy that allows
maintainers to rely on the aliasing. If there was a need to refer to the
shell via /usr/bin/sh, we would aim for eventually removing the aliasing
symlinks. That's not what we're up to.

> So let's update the policy to refer to modern and supported filesystem
> paths as adopted by Debian de-facto and de-jure, and stop other
> maintainers from getting beaten with it.

I don't think this is right. We intend to finalize the /usr-merge
transition by moving files from / to /usr. This is is an implementation
strategy that arises from the constraints set by the current
implementation of dpkg and other components. It is not a new filesystem
layout that we expect upstreams to support. Rather, we promised to
upstreams that both ways will work. The aspect that in a data.tar we'll
have to install files to /usr is a technical one and can be supported by
debhelper. Still, packages may assume that referencing files they
installed to /usr via aliased paths in / will continue to work.

> Patch attached and also pushed to
> https://salsa.debian.org/bluca/policy/-/tree/bin_sh

Nack to this particular change, but I agree that it is worth considering
two changes to policy sooner and later:
 * Making it explicit that referring to files via either paths for
   read-only consumption is ok.
 * DEP17 aims for not installing any files in aliased locations and we
   should encode that in policy once there is wide adoption of this rule
   in binary packages.

Would you agree to repurpose this bug to propose the former change?
While my variant is weaker, it still prevents people from using policy
to require supporting split-/usr.

Helmut

Bug#1051368: Acknowledgement (python3-selenium: Selenium Python still can't find chromedriver)

[Jonathan Kamens]

Oh, I see, the README.Debian file is packaged in python-selenium-doc.

Shouldn't that be python3-selenium-doc? Or even better, in 
python3-selenium itself? That would at least give people a fighting 
chance of finding it.


Regardless, I don't think this issue can/should be considered "resolved" 
until the module actually works as designed, i.e., the driver manager is 
being installed with it. Burying a "hey, this is the workaround you need 
to do to make this module that used to work continue to work" in a 
README file does not seem like an adequate resolution.

Bug#1051352: ITP: shedskin -- Python-to-C++ compiler designed to speed up Python programs

[Paul Boddie]

On Thursday, 7 September 2023 06:48:11 CEST Paul Wise wrote:
> 
> Please note the extra steps when reintroducing packages, ie bug triage:
> 
> https://www.debian.org/doc/manuals/developers-reference/
pkgs.en.html#reintroducing-packages

Thank you for the reference. I looked in the removal log:

https://ftp-master.debian.org/removals-2020.txt

Here are the bugs closed when the package was removed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757125
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938476
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956489

Only the first one was directly related to the package itself. The others were 
related to Python 2 removal.

As part of repackaging this software, I have set up the packaging repository 
on Salsa:

https://salsa.debian.org/pboddie/shedskin

The CI functionality is being used to run the test suite as part of the 
autopkgtest job in each invoked pipeline:

https://salsa.debian.org/pboddie/shedskin/-/pipelines

This suite takes over an hour to complete and is therefore not part of the 
normal package build process. For example:

https://salsa.debian.org/pboddie/shedskin/-/jobs/4671845

This should at least mitigate against the inadvertent breakage that occurred 
with bug #757125.

Regards,

Paul

Bug#1051367: Acknowledgement (regression: powersave screen blank causes system freeze after upgrade to Debian 12)

[Marcin Owsiany]

Turns out this issue is already fixed in the 6.4.4-3~bpo12+1 version
available in bookworm-backports \o/

Bug#1051430: ITP: python-laspy -- Library for working with LAS LiDAR files

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-laspy
  Version : 2.5.1
  Upstream Author : Grant Brown 
* URL : https://github.com/laspy/laspy
* License : BSD-2-clause
  Programming Lang: Python
  Description : Library for working with LAS LiDAR files

Laspy is a Python library for reading, modifying, and creating LAS LiDAR
files. The ASPRS LAS format is a sequential binary file format used to store
data from LiDAR sensors and by LiDAR processing software for data interchange
and archival.

The package will be team-maintained under the umbrella of the
Debian Python Team 
at https://salsa.debian.org/python-team/packages/python-laspy


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmT6KxwACgkQ+C8H+466
LVndKAwAwgyox6Pw9oGiQr4B9NLQ46BqdaBNkfNDUq5IXIIsdaE2+m2Q3L58HB+r
1AqX2hA5HzEVk9UW/2MaH5wvbbNmjuoPq7Ov0e6Qz2Gy5zKRZWUiFCJLjslinmfI
wUm43POIFt4Ss7fEwPZHUEUHb4Qn5M4JffEgUqeXrjdlylVlkZBM11vzOpeEjhpv
8c5zXEtQT4V98vzSe9y59dpbk91tBWihG6SeDpn1+jamBp8EA+WM4Q6YYJQoVAjX
gmMylOHsAp+C03vxqqvQg7QSIHn/mS5v8xlDT/Vj0v6813Uq791uTko8Ac7F6+MG
jLPlblXri8jhhImcOiLgQ/BA7sMsMH28cCbW0kpudqyG2agrwdxVu9rewm3O8DU6
5VoTdQU1/wm8nhxJ0e5ZjQUp4GX1lSGxdz16lD5u59Sfi8K2OGPipP7+LJkmpqnE
U52OCp1/ZQrrh9gPN5cdtM2qttAIPH8ZSJ29KDwmyDIEROC9TP6iINjAMpwc28X/
weJITNvP
=Ii5X
-END PGP SIGNATURE-

Bug#1050937: protobuf: FTBFS: ModuleNotFoundError: No module named 'tzdata'

[Aurelien Jarno]

Hi,

On 2023-09-03 16:53, László Böszörményi (GCS) wrote:
> Hi,
> 
> On Sat, Sep 2, 2023 at 10:33 AM Gianfranco Costamagna
>  wrote:
> > Hello, probably tzdata split in legacy made this package FTBFS.
>  Seems to be the case.
> 
> > Solutions are:
> > 1) fix the test to work with main tzdata
>  It's Python 3.11 itself which can't handle tzdata related things. It
> has a proposed patch applied for the Debian package [1] but seems not
> fully tested / complete.
> 
> > 2) add dependency on tzdata-legacy package
>  No, it's Python which tries to import a module that doesn't exist.
> Static data has nothing to do with it. Will test with the mentioned
> patch removed Python package version.

3) Use the patch I submitted upstream:
https://github.com/protocolbuffers/protobuf/pull/13882

Regards
Aurelien

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

Bug#1051429: bookworm-pu: package openrefine/3.6.2-2

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org

[ Reason ]

Fixing CVE-2023-37476 in Bookworm.

[ Tests ]

The patch checks if file paths inside Zip/Tar archives are valid and do not
try to escape their root directory. The code looks reasonable to me.

[ Risks ]

The code is trivial.

[ 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
diff -Nru openrefine-3.6.2/debian/changelog openrefine-3.6.2/debian/changelog
--- openrefine-3.6.2/debian/changelog   2023-04-05 20:20:17.0 +0200
+++ openrefine-3.6.2/debian/changelog   2023-09-07 21:22:17.0 +0200
@@ -1,3 +1,13 @@
+openrefine (3.6.2-2+deb12u1) bookworm; urgency=medium
+
+  * Fix CVE-2023-37476:
+OpenRefine is a free, open source tool for data processing. A carefully
+crafted malicious OpenRefine project tar file can be used to trigger
+arbitrary code execution in the context of the OpenRefine process if a user
+can be convinced to import it. (Closes: #1041422)
+
+ -- Markus Koschany   Thu, 07 Sep 2023 21:22:17 +0200
+
 openrefine (3.6.2-2) unstable; urgency=medium
 
   * Depend on libjoda-time-java and liboro-java.
diff -Nru openrefine-3.6.2/debian/patches/CVE-2023-37476.patch 
openrefine-3.6.2/debian/patches/CVE-2023-37476.patch
--- openrefine-3.6.2/debian/patches/CVE-2023-37476.patch1970-01-01 
01:00:00.0 +0100
+++ openrefine-3.6.2/debian/patches/CVE-2023-37476.patch2023-09-07 
21:22:17.0 +0200
@@ -0,0 +1,24 @@
+From: Markus Koschany 
+Date: Thu, 17 Aug 2023 21:33:50 +0200
+Subject: CVE-2023-37476
+
+Bug-Debian: https://bugs.debian.org/1041422
+Origin: 
https://github.com/OpenRefine/OpenRefine/commit/c40c84d8170c4d61c6a0926531b552a50caa5651
+---
+ main/src/com/google/refine/io/FileProjectManager.java | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/main/src/com/google/refine/io/FileProjectManager.java 
b/main/src/com/google/refine/io/FileProjectManager.java
+index 09197f7..c913199 100644
+--- a/main/src/com/google/refine/io/FileProjectManager.java
 b/main/src/com/google/refine/io/FileProjectManager.java
+@@ -167,6 +167,9 @@ public class FileProjectManager extends ProjectManager  {
+ 
+ while ((tarEntry = tin.getNextTarEntry()) != null) {
+ File destEntry = new File(destDir, tarEntry.getName());
++if 
(!destEntry.toPath().normalize().startsWith(destDir.toPath().normalize())) {
++throw new IllegalArgumentException("Zip archives with files 
escaping their root directory are not allowed.");
++}
+ File parent = destEntry.getParentFile();
+ 
+ if (!parent.exists()) {
diff -Nru openrefine-3.6.2/debian/patches/series 
openrefine-3.6.2/debian/patches/series
--- openrefine-3.6.2/debian/patches/series  2023-04-05 20:20:17.0 
+0200
+++ openrefine-3.6.2/debian/patches/series  2023-09-07 21:22:17.0 
+0200
@@ -4,3 +4,4 @@
 log4j-api.patch
 no-java-files.patch
 gdata-extension.patch
+CVE-2023-37476.patch

Bug#1051428: veyon-master: Veyon remote control screens lack decorations (title bar and icons) on LXDE.

[Marcos García Ochoa]

Package: veyon-master
Version: 4.7.5+repack1-1
Severity: normal

Dear Maintainer,

On Debian Stable, veyon-master starts up correctly, showing the computers to be
managed when the group is selected.
Selecting remote control on a computer works (the screen shows up on the
desktop, the remote computer can be interacted with) but there is no title bar
nor any options to move it around like in the rest of the screens.

The attached screen capture shows a remote screen (with no decorations) and the
main veyon-master window in the background.


-- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (920, 'stable-security'), (910, 'stable-updates'), (900, 
'stable'), (850, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-11-amd64 (SMP w/12 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 veyon-master depends on:
ii  libc6   2.36-9+deb12u1
ii  libqt5core5a5.15.8+dfsg-11
ii  libqt5gui5  5.15.8+dfsg-11
ii  libqt5network5  5.15.8+dfsg-11
ii  libqt5widgets5  5.15.8+dfsg-11
ii  libstdc++6  12.2.0-14
ii  libveyon-core   4.7.5+repack1-1
ii  pkexec  122-3
ii  policykit-1 122-3
ii  veyon-service   4.7.5+repack1-1

Versions of packages veyon-master recommends:
ii  veyon-configurator  4.7.5+repack1-1

veyon-master suggests no packages.

-- no debconf information

Bug#1049418: xfce4-pulseaudio-plugin: Please loosen Recommends, and allow pipewire-pulse as an alternative to pulseaudio

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2023-08-15 at 20:09 +0700, Arnaud Rebillout wrote:
> Changing the Recommends field of xfce4-pulseaudio-plugin to
> 'pulseaudio|pipewire-pulse' would solve those two issues, and more
> generally it would make life easier for people who want to switch to
> pipewire and remove pulseaudio.

Hi Arnaud,

I have no idea what pipewire is, could you explain a bit here what it is? Is
it a drop-in for pulseaudio or something? Because xfce4-pulseaudio-plugin is
(by definition) really linked to pulseaudio.

And if we have a drop-in replacement, does it really make sense to have every
pulseaudio depending package to use alternate dependencies? Isn't there a way
to centralize this change?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmT6JLkACgkQ3rYcyPpX
RFuLXggAsSGLse5tsY/463r+nLS6t5RVkIgIr3XLQHltMn5TINpXJIONAS38XXmT
wqBAkj6oQcOJhj+5qjWtG8eH+eTtpPXhEb/l/1Sl2/7/Xi4QGtQ92ZiKF2lmKwfi
uOZos/w9rPyotUb/2bXnFlXVlOoc2KCWfRRYHMwj5XwgnXsmm9WcKmUJw8LIH091
WC0tjIPmm4pT2DkrwZQ/vPgUNOt+2OCPooqmzfuJvucE37iW8tLA8EEJZjyKlduA
PFIlT0czS30Y7C/kJrRzmcryqnyDKmPCtULR5LndiGx2hZojYrLfsiuXD/sbJkT+
VEdAF3NwYJ+lR2VCL83plPjiQ0HAig==
=83EC
-END PGP SIGNATURE-

Bug#1050802: xfce4-session: please provide an xfce-portals.conf for xdg-desktop-portal

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2023-08-29 at 11:51 +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:

Hi Simon,

thanks for the report but I have no idea what a “portal” is. So feel free to
provide a patch for that, I think it's unlikely we'll look at this soon.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmT6I8MACgkQ3rYcyPpX
RFuC+wf/YhTUai4ctNVzUJC7zPo9F2mgtmGLtOl3IFlD+YaTGtDztZuUIlFrNJL4
J9vIxLjYGtSsxpImkoHnj1lxnn0kX//Msj3cgmn8uyqRmoC0NIQr+Dz2bo8aD2C/
0CsFeflqw20Q9Q2UEKdORppTtbmmosFCyfiyadhL94uSqYhFVC98HnVo7jc+qZoq
2DON8WKNgB4KGe+L4gNbEIV4t8SwhRXsjBx8FVSsE6xWrOjRwBL2MVf/krhxMryr
eCxbC5/Zkb3+u3S5JPEyqhxctD1M3ulanTM42GUT1FUbL96c8YOLq9JwumpLYaBo
QydscbTWY079TGnEH4oTWOI/MRF0Lw==
=qTvF
-END PGP SIGNATURE-

Bug#1051426: RFS: golang-github-jesseduffield-go-git/5.1.2+git20221018.fdd53fe-1 [ITP]

[Jongmin Kim]

Dear Go team,

I am looking for a sponsor for the package "golang-github-jesseduffield-go-git".
This package is a prerequisite for the package "lazygit" (#908894)[1,2].

  [1] https://bugs.debian.org/908894
  [2] https://github.com/jesseduffield/lazygit-debian/wiki/Dependency-graph

The package upstream[3] is a forked version of go-git[4] which is already
packaged in Debian archive[5]. However, the package is needed due to
forked upstream modified some functions[6] for lazygit, which have
discrepency from the original.

  [3] https://github.com/jesseduffield/go-git
  [4] https://github.com/go-git/go-git
  [5] https://tracker.debian.org/pkg/golang-github-go-git-go-git
  [6] https://github.com/jesseduffield/go-git/commits/master

I pushed to the team's Salsa:

  https://salsa.debian.org/go-team/packages/golang-github-jesseduffield-go-git

The package was tested on both gbp and sbuild.
The package has 1 lintian warning:

  (package-has-long-file-name) due to following the Go Debian package naming 
convention.

Could you please reviewing/sponsoring this?
Any kind of reviews and suggestions are appreciated.

-- 
Jongmin Kim

OpenPGP key located at https://jongmin.dev/pgp
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#1051421: cloud-init: Avoid hard dependency on isc-dhcp-client

[Bastian Blank]

On Thu, Sep 07, 2023 at 05:50:41PM +0200, Bastian Blank wrote:
> When the following commit is includes:

Just for background information: cloud-init depends on isc-dhcp-client
because it uses the dhclient binary.  So removing that as dependency is
not feasible right now.

Bastian

-- 
Fascinating, a totally parochial attitude.
-- Spock, "Metamorphosis", stardate 3219.8

Bug#1050573: bullseye-pu: package openssl/1.1.1v-0~deb11u1

[Sebastian Andrzej Siewior]

On 2023-08-26 14:50:09 [+0200], To sub...@bugs.debian.org wrote:
> This is an update of the openssl package to the 1.1.1v version, a patch 
> release

Upstream announced to release 1.1.1w on 11th September. They said it is
a "security-fix" with the highest severity defined as "low". This is
also the case for the current two CVEs. Therefore I assume that they
don't have to be fixed asap (i.e. via -security).
Also it will be the last 1.1.1 release since it will reach EOL on the
11th. I will prepare an update…

The upstream announcement:

https://mta.openssl.org/pipermail/openssl-announce/2023-September/000271.html:

Sebastian

Bug#1051427: perl: libperl symbols for strlcat and strlcpy lost with glibc 2.38

[Niko Tyni]

Source: perl
Version: 5.36.0-7
Severity: important
Tags: ftbfs patch

As noticed by Ubuntu and reported by doko on IRC, this package fails to
build from source with glibc 2.38 (currently in experimental.)

dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libperl5.36/DEBIAN/symbols doesn't match 
completely debian/libperl5.36.symbols
--- debian/libperl5.36.symbols (libperl5.36_5.36.0-8_amd64)
+++ dpkg-gensymbolszhalIX   2023-09-07 18:42:16.688071199 +
@@ -925,8 +925,8 @@
  Perl_my_stat_flags@Base 5.36.0
  Perl_my_strerror@Base 5.36.0
  Perl_my_strftime@Base 5.36.0
- Perl_my_strlcat@Base 5.36.0
- Perl_my_strlcpy@Base 5.36.0
+#MISSING: 5.36.0-8# Perl_my_strlcat@Base 5.36.0
+#MISSING: 5.36.0-8# Perl_my_strlcpy@Base 5.36.0
  Perl_my_strtod@Base 5.36.0
  Perl_my_unexec@Base 5.36.0
  Perl_my_vsnprintf@Base 5.36.0

This is because glibc added strlcpy and strlcat in

  
https://sourceware.org/git/?p=glibc.git;a=commit;h=454a20c8756c9c1d55419153255fc7692b3d2199

so the Configure script now detects them and disables the replacement
implementations inside src:perl, losing the corresponding libperl symbols
in the process.

I suspect nothing external actually uses the lost symbols, but it's best
to be on the safe side. The attached patch tells Configure to ignore
the new glibc functions, so that libperl keeps binary compatibility.

We will need this for whichever version of perl is in sid when glibc
2.38 enters it. I'll upload it soon for 5.36, and see what to do
with 5.38 when the transition is ready to start.
-- 
Niko Tyni   nt...@debian.org
>From edd4457e4f61460f32a04c566e1da68dcf238d98 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Thu, 7 Sep 2023 19:16:29 +0100
Subject: [PATCH] Explicitly do not use strlcpy and strlcat from glibc 2.38

This keeps libperl symbols stable
---
 debian/config.debian | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/config.debian b/debian/config.debian
index 7afc379e7..300416ae2 100644
--- a/debian/config.debian
+++ b/debian/config.debian
@@ -119,6 +119,8 @@ then
 -Ui_libutil	\
 -Ui_xlocale	\
 -Uversiononly \
+-Ud_strlcpy	\
+-Ud_strlcat	\
 -DDEBUGGING=$debugging			\
 -Doptimize=\"$optimize\"			\
 $extra_path	\
-- 
2.39.1

Bug#1051426: ITP: golang-github-jesseduffield-go-git -- highly extensible Git implementation in pure Go

[Jongmin Kim]

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

* Package name: golang-github-jesseduffield-go-git
  Version : 5.1.2+git20221018.fdd53fe
  Upstream Contact: Jesse Duffield 
* URL : https://github.com/jesseduffield/go-git
* License : Apache-2.0
  Programming Lang: Go
  Description : highly extensible Git implementation in pure Go

 This package provides a highly extensible git implementation library
 written in pure Go.
 .
 The library does:
  * can be used to manipulate git repositories at low level (plumbing)
or high level (porcelain), through an idiomatic Go API.
  * supports several types of storage, such as in-memory filesystems, or
custom implementations using the 'Storer' interface.
  * aims to be fully compatible with git, all the porcelain operations
are implemented to work exactly as git does.

The package is in the dependency tree of lazygit (#908894)[1,2].
The package upstream[3] is a forked version of go-git[4] which is
already packaged in Debian archive[5].

[1] https://bugs.debian.org/908894
[2] https://github.com/jesseduffield/lazygit-debian/wiki/Dependency-graph
[3] https://github.com/jesseduffield/go-git
[4] https://github.com/go-git/go-git
[5] https://tracker.debian.org/pkg/golang-github-go-git-go-git

Bug#1051412: grub-common: leftover directory

[Christoph Anton Mitterer]

On Thu, 2023-09-07 at 16:30 +0200, Julian Andres Klode wrote:
> Cleaning it up would certainly be the wrong choice, after all the
> reason
> it sticks around for you is your local configuration snippets you
> dropped in
> there.

Ah, I thought maybe you had just dropped the functionality to have
custom snippets in there.

However, I had no own files in it, yet the directory was left over.


Anyway, thanks for fixing :-)

Bug#1031235: restic: New upstream version 0.15.1

[Ilya Grigoriev]

Package: restic
Version: 0.14.0-1+b6
Followup-For: Bug #1031235
X-Debbugs-Cc: debian.10.il...@xoxy.net

Dear Maintainer,

   You are probably already well aware of this, but just in case, I
wanted to mention that this bug
is a little out of date now that Restic 0.16.0 was released.

  https://restic.net/blog/2023-07-31/restic-0.16.0-released/

  Thanks for maintaining restic and other Go packages!

Ilya


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

Kernel: Linux 5.15.124-20255-g6fec128ef5b0 (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)

Versions of packages restic depends on:
ii  libc6  2.37-7

Versions of packages restic recommends:
ii  fuse3 [fuse]  3.14.0-4

Versions of packages restic suggests:
ii  libjs-sphinxdoc  5.3.0-7
ii  sphinx-rtd-theme-common  1.3.0+dfsg-1

-- no debconf information

Bug#1042728: restic: Package completions for the fish shell

[Ilya Grigoriev]

Package: restic
Version: 0.14.0-1+b6
Followup-For: Bug #1042728
X-Debbugs-Cc: debian.10.il...@xoxy.net

Dear Maintainer,

I created a patch that does what I described previously. It is available at

https://salsa.debian.org/go-team/packages/restic/-/merge_requests/4

I couldn't figure out how to run the CI on it, though.

Thank you for maintaining restic and the other Go packages,

Ilya


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

Kernel: Linux 5.15.124-20255-g6fec128ef5b0 (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)

Versions of packages restic depends on:
ii  libc6  2.37-7

Versions of packages restic recommends:
ii  fuse3 [fuse]  3.14.0-4

Versions of packages restic suggests:
ii  libjs-sphinxdoc  5.3.0-7
ii  sphinx-rtd-theme-common  1.3.0+dfsg-1

-- no debconf information

Bug#1050602: linux: kernel 6.4.11-1 does not recognize TPM on lenovo 14IAU7 (Flex 7i)

[Diederik de Haas]

On Fri, 1 Sep 2023 23:32:34 -0400 Justin King-Lacroix 
 wrote:
> FYI bug is still present in 6.4.13-1

It has been fixed in Linus' tree with 8f7f35e5aa6f2182eabcfa3abef4d898a48e9aa8
And a backport of that is currently available in the stable queue for 6.5, 6.4 
and 6.1, so it should make it into 6.5.3, 6.4.16 and 6.1.53 respectively.

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

Bug#1009027: mesa: Please enable these new drivers and features available since mesa 22

[Nicolas Frattaroli]

Please disable panvk again. It is a known broken driver.
Upstream does not want you to ship it, as you can see from these IRC logs:

https://oftc.irclog.whitequark.org/panfrost/2023-09-07#1694108135-1694109081;

Bug#1051349: closed by Ryan Tandy (Re: Bug#1051349: slapd: DoS after some 'Too many open files'?)

[Patrice Duroux]

Hi Ryan,

Sorry for my fuzzy report.
I have not yet applied for your suggestion but will be back to it very soon.

Many thanks,
Patrice

Le jeu. 7 sept. 2023 à 19:24, Debian Bug Tracking System
 a écrit :
>
> This is an automatic notification regarding your Bug report
> which was filed against the slapd package:
>
> #1051349: slapd: DoS after some 'Too many open files'?
>
> It has been closed by Ryan Tandy .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ryan Tandy 
>  by
> replying to this email.
>
>
> --
> 1051349: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051349
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Ryan Tandy 
> To: Patrice Duroux 
> Cc: 1051349-d...@bugs.debian.org
> Bcc:
> Date: Thu, 7 Sep 2023 10:17:59 -0700
> Subject: Re: Bug#1051349: slapd: DoS after some 'Too many open files'?
> Hello Patrice,
>
> On Wed, Sep 06, 2023 at 04:43:16PM +0200, Patrice Duroux wrote:
> >2023-09-06T14:57:22.996591+02:00  slapd[2200]: warning: cannot 
> >open /etc/hosts.allow: Too many open files
>
> As Quanah said, hitting the open files limit is a common issue on Debian
> because we link the tcp-wrappers library, which unfortunately consumes
> extra file descriptors for each open network connection.
>
> >ulimit is unlimited in the default any root/user env.
> >What about the slapd service that is launched by systemd?
>
> See /proc/$(pidof slapd)/limits. In a systemd-nspawn container, I see a
> default limit of 1024 open files.
>
> >slapd does not have a .service file to change this, right?
>
> Not on disk, but a virtual slapd.service is generated from the init
> script, and can be modified using a drop-in:
>
> mkdir -p /etc/systemd/system/slapd.service.d
> cat > /etc/systemd/system/slapd.service.d/open-files-limit.conf << eof
> [Service]
> LimitNOFILE=524288
> eof
> systemctl daemon-reload
> systemctl restart slapd.service
>
> Now /proc/$(pidof slapd)/limits should reflect the increased limit.
>
> Hope this helps,
> Ryan
>
>
> -- Forwarded message --
> From: Patrice Duroux 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 06 Sep 2023 16:43:16 +0200
> Subject: slapd: DoS after some 'Too many open files'?
> Package: slapd
> Version: 2.5.13+dfsg-5
> Severity: normal
>
> Dear Maintainer,
>
> This happens on one physical machine using a Debian Bookworm and only 
> dedicated to NFS/LDAP
> services.
> I never faced this before for years with Bulleyes before upgrading to 
> Bookworm.
>
> Looking into log files there are the following messages:
>
> [...]
> 2023-09-06T14:57:22.996591+02:00  slapd[2200]: warning: cannot open 
> /etc/hosts.allow: Too many open files
> 2023-09-06T14:57:22.996861+02:00  slapd[2200]: warning: cannot open 
> /etc/hosts.deny: Too many open files
> 2023-09-06T14:57:53.823167+02:00  slapd[2200]: warning: cannot open 
> /etc/hosts.allow: Too many open files
> 2023-09-06T14:57:53.823810+02:00  slapd[2200]: warning: cannot open 
> /etc/hosts.deny: Too many open files
> 2023-09-06T14:59:56.993514+02:00  slapd[2200]: warning: cannot open 
> /etc/hosts.allow: Too many open files
> 2023-09-06T14:59:56.994249+02:00  slapd[2200]: warning: cannot open 
> /etc/hosts.deny: Too many open files
> 2023-09-06T15:00:15.129483+02:00  slapd[2200]: warning: cannot open 
> /etc/hosts.allow: Too many open files
> 2023-09-06T15:00:15.129643+02:00  slapd[2200]: warning: cannot open 
> /etc/hosts.deny: Too many open files
> 2023-09-06T15:00:53.881436+02:00  slapd[2200]: daemon: accept(8) 
> failed errno=24 (Too many open files)
> 2023-09-06T15:01:16.878910+02:00  slapd[2200]: daemon: accept(8) 
> failed errno=24 (Too many open files)
> 2023-09-06T15:01:16.880305+02:00  slapd[2200]: daemon: accept(8) 
> failed errno=24 (Too many open files)
> [...]
>
> During the DoS, 'systemctl status slapd' did not shown me anything strange.
> Restarting the service solved the trouble.
>
> Are there some possible file closing leaks in slapd it-self?
>
> ulimit is unlimited in the default any root/user env.
> What about the slapd service that is launched by systemd?
>
> # systemctl status slapd
> ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
> Access Protocol)
>  Loaded: loaded (/etc/init.d/slapd; generated)
> Drop-In: /usr/lib/systemd/system/slapd.service.d
>  └─slapd-remain-after-exit.conf
>  Active: active (running) since Wed 2023-09-06 15:41:44 CEST; 51min ago
>Docs: man:systemd-sysv-generator(8)
> Process: 135002 ExecStart=/etc/init.d/slapd start (code=exited, 
> status=0/SUCCESS)
>   Tasks: 9 (limit: 38189)
>  Memory: 73.9M
> CPU: 3.444s
>  CGroup: /system.slice/slapd.service
>  └─135008 /usr/sbin/slapd -h "ldap:/// ldapi:///" -g openldap -u 
> openldap -F 

Bug#1051408: Acknowledgement (flameshot: uploads potentially sensitive screenshots to the internet)

[Peter]

Thank you for the quick response to my message.

My message is wrong in one place: I tested the old version from Debian 
Bullseye.


In Bookworm it behaves as follows: There is an "Imgur Application Client 
Id" configured in the installation. So it is possible to use the upload 
without any further configuration. But before uploading there is a 
security prompt. In German: "Möchest du diese Aufnahme hochladen?"/"Do 
you want to upload this image?". You may set "Upload without confirmation".


For privacy reasons I would prefer the image upload function to be 
disabled by default and no Imgur Application Id configured.


Best regards.
Peter

Bug#1043423: ukwm: Incompatible with gsettings-desktop-schemas 45

[Jeremy Bícha]

I realized later that ukwm does appear to work with the new
gsettings-desktop-schemas.

You may be interested in this more extensive commit since I believe
ukwm is a fork of mutter, not of metacity:
https://gitlab.gnome.org/GNOME/mutter/-/commit/b521747d

Thank you,
Jeremy Bícha

Bug#1049343: solved

[Aravinth Manivannan]

On Thu, 17 Aug 2023 10:54:07 +0200 Bardi Laurent  
wrote:

Hi,

at first thanks to all, workaround is working, the case can be closed.

Have a nice day.

--
logo-cnrs


  Laurent Bardi


RSSI IPBS / CRSSI DR14

Institut de Pharmacologie et de Biologie Structurale

+33 5 61 17 59 05 | +33 6 23 46 06 28 | laurent.ba...@ipbs.fr

UMR5089 | CNRS – UT3 | 205 Route de Narbonne BP 64182 – 31077 Toulouse 
Cedex 4


ipbs.fr 


J'étais indéniablement misanthrope.
Je voulus traverser à gué un marigot infesté d'imbéciles.
Quand j'atteignis l'autre rive, j'étais devenu philanthrope.


Hello,

Here's a patch for the salsa GitLab repository[0] that applies the 
workaround mentioned above. I've tested the changes locally and it seems 
to be working. I've requested an account on salsa, I'll create an MR of 
the same once it's approved :)


Warm regards,
Aravinth Manivannan

[0]: https://salsa.debian.org/ruby-team/gitlab/
diff --git a/debian/gitlab.postinst b/debian/gitlab.postinst
index 6baa966d7a..6eb3bf7023 100755
--- a/debian/gitlab.postinst
+++ b/debian/gitlab.postinst
@@ -68,10 +68,7 @@ runuser -u ${gitlab_user} -- sh -c "if ! gem list -i -v 1.8.0 "^graphiql-rails$"
 
 # TODO: Update packages for these gems
 runuser -u ${gitlab_user} -- sh -c "if ! gem list -i -v 1.44.0 "^google-cloud-storage$" >/dev/null; then gem install -v 1.44.0 google-cloud-storage; fi"
-
-runuser -u ${gitlab_user} -- sh -c "gem uninstall -v '~> 3.24.0' google-protobuf"
-runuser -u ${gitlab_user} -- sh -c "gem install -v '= 3.23.4' google-protobuf"
-
+runuser -u ${gitlab_user} -- sh -c "if ! gem list -i -v '~> 3.22.2' "^google-protobuf$" >/dev/null; then gem install -v '~> 3.22.2' google-protobuf; fi"
 runuser -u ${gitlab_user} -- sh -c "if ! gem list -i -v '~> 0.1.3' "^net-protocol$" >/dev/null; then gem install -v '~> 0.1.3' net-protocol; fi"
 runuser -u ${gitlab_user} -- sh -c "if ! gem list -i -v '~> 1.3' "^duo_api$" >/dev/null; then gem install -v '~> 1.3' duo_api; fi"
 runuser -u ${gitlab_user} -- sh -c "if ! gem list -i -v '~> 0.3' "^google-cloud-profiler-v2$" >/dev/null; then gem install -v '~> 0.3' google-cloud-profiler-v2; fi"


OpenPGP_0xF8F50389936984FF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051425: ukwm: undeclared dependency on libqt5-ukui-style1

[Jeremy Bícha]

Source: ukwm
Version: 1.2.0-1
Severity: serious

I installed ukwm on my Debian GNOME Testing install. This adds a UKUI
entry to the session list on my login screen. It is impossible to log
in to that session: it freezes before the desktop is fully loaded.

My systemd journal indicates this is because this file is missing:
/usr/share/glib-2.0/schemas/org.ukui.style.gschema.xml

It is provided by libqt5-ukui-style1. Installing
qt5-ukui-platformtheme would install that package but nothing in
Debian depends on qt5-ukui-platformtheme

Thank you,
Jeremy Bícha

Bug#1051424: ukui-settings-daemon: broken postinst

[Jeremy Bícha]

Source: ukui-settings-daemon
Version: 3.1.1.1-1
Severity: grave

I attempted to install ukwm on my Debian GNOME Testing install and it
got stuck in the postinst. I am filing this as "grave" because a
broken postinst like this breaks dpkg until it is fixed or
ukui-settings-daemon is uninstalled.

As a workaround, I commented out this line in
/var/lib/dpkg/info/ukui-settings-daemon.postinst
save-param

Thank you,
Jeremy Bícha

Bug#1041129: krb5-config install doesn't gracefully handle read-only /etc/krb5.conf file and errors out

[Sam Hartman]

> "Ben" == Ben Brenek  writes:


Ben> Installing Kerberos on other distributions with a similar setup
Ben> does not result in this type of error. Which is why I'm opening
Ben> this bug report.

What forced you to install krb5-config though?
Is there any hard dependency forcing this, or is it just a recommends.
It's generally expected that when installing a package, that package
should be able to write the files it owns.
If all you need to do is not install krb5-config, then I will consider
that sufficient.
Your suggestion that we test /etc/krb5.conf writability can potentially
fail to detect situations where the installation should properly fail.

Bug#1043108: libevent: fails to build against glibc 2.38

[Nicolas Mora]

Hello,

Le 2023-09-07 12:05, Shengjing Zhu a écrit :


I don't understand why it's safe to drop this symbol.

I think the bug is same as https://bugs.debian.org/1023284, which needs
workaround to keep the exported symbol with new glibc.


According to libevent's source code, the function event_strlcpy_ isn't 
used anywhere in libevent, it's only exported, so the change may break 
other packages.


Although as in #1023284, I'll ask the question upstream first to get 
their opinion on this.


Thanks!

/Nicolas

Bug#1043108: libevent: fails to build against glibc 2.38

[Samuel Thibault]

Shengjing Zhu, le ven. 08 sept. 2023 00:05:23 +0800, a ecrit:
> On Sun, Aug 06, 2023 at 10:30:38AM +0200, Samuel Thibault wrote:
> > Source: libevent
> > Version: 2.1.12-stable-8
> > Severity: important
> > Tags: patch
> > 
> > Hello,
> > 
> > libevent fails to build against glibc 2.38:
> > 
> > --- debian/libevent-core-2.1-7.symbols.original 2023-08-06 
> > 10:17:18.031636016 +0200
> > +++ debian/libevent-core-2.1-7.symbols  2023-08-06 10:17:28.135665241 
> > +0200
> > @@ -310,7 +310,6 @@
> >   event_set_mem_functions@Base 2.1.8-stable
> >   event_sock_err@Base 2.1.8-stable
> >   event_sock_warn@Base 2.1.8-stable
> > - (arch=!musl-linux-any)event_strlcpy_@Base 2.1.8-stable
> >   event_warn@Base 2.1.8-stable
> >   event_warnx@Base 2.1.8-stable
> 
> I don't understand why it's safe to drop this symbol.

Because it's not exposed in the API to other packages:

./strlcpy-internal.h:#define strlcpy event_strlcpy_

is the only exposure, and that file is not installed, so there is no way
for another package to produce a reference to it. I did check on the
archive in the amd64 case, no package does.

> I think the bug is same as https://bugs.debian.org/1023284, which needs
> workaround to keep the exported symbol with new glibc.

Yes, because evutil_secure_rng_add_bytes was really exposed in the API,
in /usr/include/event2/util.h

Samuel

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> I would. Having two paths for the same thing is a technical
Bill> debt going forward.

I think the TC has made it clear we're committed to usrmerge at this
point, and I think that one of the drivers behind usrmerge is that we
gain more from having both /bin/python and /usr/bin/python work than we
lose by having two paths.
I understand people disagree,
but I think we should fall in behind the TC decision and accept we've
decided that in this instance we value aliasing.

Bug#1050970: open-vm-tools: CVE-2023-20900

[Bernd Zeimetz]

> 
Hi,

> > https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/compare/15b2b38edd7834b7ad93ae25831fc7ef2bf7ce28...bullseye?from_project_id=38835=false
> > 
> > bookworm:
> > https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/compare/2231c605efb0564efee229d6c535033159cc92bc...bookworm?from_project_id=38835=false
> 
> These look good, please upload to security-master. bookworm needs to
> be build with -sa sicne it's the first upload,
> bullseye doesn't. Thanks!
> 


Both uploaded (and fixed the version for the bookworm upload before
uploading, seems dch still lives in bullseye...).

Cheers,

Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1051367: Acknowledgement (regression: powersave screen blank causes system freeze after upgrade to Debian 12)

[Marcin Owsiany]

Today I switched to an Xorg-based GNOME session, and found out that
invoking `xset dpms force off` also results in the system freezing.
Interestingly, the system was responsive via ssh for another couple seconds
or so.

So I think this regression must be related to the kernel version change
more than anything else. Reassigning the bug.

Again, I'd be more than happy to do whatever is needed to investigate this
deeper. The only idea comes to mind is to try and bisect the kernel history
between 5.10.179-2 and 6.1.38-4, but I'm not sure how feasible it is these
days (it's been almost two decades since I last built my own kernel package
and don't know what config to use between these two versions).

Bug#1051423: Documentation for return command

[Daniel Carpenter]

Package: dash
Version: 0.5.11+git20200708+dd9ef66-5

Dear maintainer,

The dash manpage states:

 The syntax of the return command is

   return [exitstatus]

 It terminates the currently executing function.  Return is implemented
as a builtin command.

I can't find any reference to what happens when exitstatus is omitted. Bash
does this:

   return [n]
  Causes  a  function  to  stop  executing and return the value
specified by n to its
  caller.  If n is omitted, the return status is that of the
last command executed in
  the  function body.

Is it the same? Could a sentence be added to the manpage (or return could
be added to the builtins section, like exit)?

Kind regards,
Dan

Bug#1041494: diffpdf: changes to zoom for small documents (⩽ 19 pages in at least one file) don't take effect on ↩

[Al Ma]

retitle 1041494 diffpdf: changes to zoom for small documents (⩽ 19 pages in at 
least one file) don't take effect on ↩
thanks
You have to take small documents to reproduce this CLEANLY.  Presumably at 
least one of the two compared PDF files must have at most 19 pages to reproduce 
this cleanly.  E.g., run pdflatex on one file containing
\documentclass[ngerman]{article} \usepackage{babel} 
\usepackage[bible]{blindtext} \begin{document} \Blindtext[87] \end{document}
and then run pdflatex on another file containing
\documentclass[ngerman]{article} \usepackage{babel} 
\usepackage[random]{blindtext} \begin{document} \Blindtext[49] \end{document}
and diffpdf the results.
If each of the compared PDF files has at least 20 pages, another bug kicks in, 
namely, http://bugs.debian.org/1051422 http://bugs.debian.org/1051422. In 
short, the function of the zoom field is very broken; please repair this.
Gratefully,
Alma

Bug#1043108: libevent: fails to build against glibc 2.38

[Shengjing Zhu]

X-Debbugs-CC: sthiba...@debian.org

Hi,

On Sun, Aug 06, 2023 at 10:30:38AM +0200, Samuel Thibault wrote:
> Source: libevent
> Version: 2.1.12-stable-8
> Severity: important
> Tags: patch
> 
> Hello,
> 
> libevent fails to build against glibc 2.38:
> 
> --- debian/libevent-core-2.1-7.symbols.original   2023-08-06 
> 10:17:18.031636016 +0200
> +++ debian/libevent-core-2.1-7.symbols2023-08-06 10:17:28.135665241 
> +0200
> @@ -310,7 +310,6 @@
>   event_set_mem_functions@Base 2.1.8-stable
>   event_sock_err@Base 2.1.8-stable
>   event_sock_warn@Base 2.1.8-stable
> - (arch=!musl-linux-any)event_strlcpy_@Base 2.1.8-stable
>   event_warn@Base 2.1.8-stable
>   event_warnx@Base 2.1.8-stable

I don't understand why it's safe to drop this symbol.

I think the bug is same as https://bugs.debian.org/1023284, which needs
workaround to keep the exported symbol with new glibc.

-- 
Shengjing Zhu

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Bill Allombert]

On Wed, Sep 06, 2023 at 04:51:10PM -0600, Sam Hartman wrote:
> > "Luca" == Luca Boccassi  writes:
> Luca> /bin/sh is not universally compatible with non-Linux OSes.
> 
> I claim it is more compatible.
> 
> 
> Luca> Also I thought that policy should not be used to beat other
> Luca> developers (it is because of this) and it should reflect the
> Luca> common practices adopted in Debian (it does not because of
> Luca> this). Is that no longer the case?
> 
> I'd consider it a non-RC bug if someone were manually writing
> #!/usr/bin/sh
> 
> We can debate about normal vs minor.
> 
> I do not think it should be a bug if some automated build process found
> /usr/bin/sh and stuck that into a script.
> I'd support a policy change to make that clear.

I would. Having two paths for the same thing is a technical debt going forward.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1051421: cloud-init: Avoid hard dependency on isc-dhcp-client

[Bastian Blank]

On Thu, Sep 07, 2023 at 05:36:06PM +0200, Michael Prokop wrote:
> Please consider adapting the Depends for the new cloud-init version
> in Debian accordingly, so one can use e.g. cloud-init with udhcpc
> (which also allows co-installation next to dhcpcd), but without
> having to also have isc-dhcp-client present.

When the following commit is includes:

| commit ce7d597a65413f8ed14154f8a0fe64dda126d1f3
| Author: Jean-François Roche 
| Date:   Wed Jul 19 00:37:24 2023 +0200
| 
| net/dhcp: add udhcpc support (#4190)

Bastian

-- 
Too much of anything, even love, isn't necessarily a good thing.
-- Kirk, "The Trouble with Tribbles", stardate 4525.6

Bug#1051421: cloud-init: Avoid hard dependency on isc-dhcp-client

[Michael Prokop]

Hi,

* Michael Prokop [Thu Sep 07, 2023 at 05:36:06PM +0200]:

> as of v21.4-2, Debian's cloud-init has a hard dependency on
> isc-dhcp-client, while the isc-dhcp suite has been deprecated by the
> ISC (also see e.g.
> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#deprecated-components).
> 
> This makes integration/usage of cloud-init with e.g. dhcpcd
> impossible:
> 
> | # apt install cloud-init dhcpcd
> | Reading package lists... Done
> | Building dependency tree... Done
> | Some packages could not be installed. This may mean that you have
> | requested an impossible situation or if you are using the unstable
> | distribution that some required packages have not yet been created
> | or been moved out of Incoming.
> | The following information may help to resolve the situation:
> |
> | The following packages have unmet dependencies:
> |  dhcpcd-base : Conflicts: dhcp-client
> |  E: Unable to correct problems, you have held broken packages.

Sorry, forgot to clarify: the `apt install cloud-init dhcpcd` from
above doesn't work on Debian <=bookworm, while on >= trixie it
works, because dhcpcd-base no longer conflicts with dhcp-client, as
it used to do up and until bookworm:

| root@f50263b65142:/# apt-get install dhcpcd isc-dhcp-client 2>&1 | tail -3
| The following packages have unmet dependencies:
|  dhcpcd-base : Conflicts: dhcp-client
| E: Unable to correct problems, you have held broken packages.
| root@f50263b65142:/# apt-cache show dhcpcd-base | grep Conflicts
| Conflicts: dhcp-client

> Quoting from
> https://github.com/canonical/cloud-init/releases/tag/23.3,
> cloud-init doesn't seem to strictly depend on isc-dhcp-client any
> longer though:
> 
> | network: support busybox micro DHCP client (udhcpc) alternative to
> | deprecated isc-dhcp-client.
> 
> So while one can install udhcpc next to isc-dhcp-client in
> Debian (because they don't conflict with each other), it's
> not yet possible to use Debian with cloud-init, without having
> also isc-dhcp-client on the system.
> 
> Please consider adapting the Depends for the new cloud-init version
> in Debian accordingly, so one can use e.g. cloud-init with udhcpc
> (which also allows co-installation next to dhcpcd), but without
> having to also have isc-dhcp-client present.

While this request still stands of course, to actually get rid of
isc-dhcp-client (at least with >=trixie). :)

regards
-mika-


signature.asc
Description: PGP signature

Bug#1051421: cloud-init: Avoid hard dependency on isc-dhcp-client

[Michael Prokop]

Package: cloud-init
Version: 23.2.1-1
Severity: normal

Hi,

as of v21.4-2, Debian's cloud-init has a hard dependency on
isc-dhcp-client, while the isc-dhcp suite has been deprecated by the
ISC (also see e.g.
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#deprecated-components).

This makes integration/usage of cloud-init with e.g. dhcpcd
impossible:

| # apt install cloud-init dhcpcd
| Reading package lists... Done
| Building dependency tree... Done
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
|
| The following packages have unmet dependencies:
|  dhcpcd-base : Conflicts: dhcp-client
|  E: Unable to correct problems, you have held broken packages.

Quoting from
https://github.com/canonical/cloud-init/releases/tag/23.3,
cloud-init doesn't seem to strictly depend on isc-dhcp-client any
longer though:

| network: support busybox micro DHCP client (udhcpc) alternative to
| deprecated isc-dhcp-client.

So while one can install udhcpc next to isc-dhcp-client in
Debian (because they don't conflict with each other), it's
not yet possible to use Debian with cloud-init, without having
also isc-dhcp-client on the system.

Please consider adapting the Depends for the new cloud-init version
in Debian accordingly, so one can use e.g. cloud-init with udhcpc
(which also allows co-installation next to dhcpcd), but without
having to also have isc-dhcp-client present.

-mika-

Bug#1012739: surf: Doesn't run

[Alberto Garcia]

On Tue, Jun 14, 2022 at 08:14:33PM +0200, Reiner Herrmann wrote:
> surf currently does not support wayland (and I think it's unlikely it will
> get support for it in the long term).
> 
> On the Internet I found the following workaround that might work for you:
> 
>  $ GDK_BACKEND=x11 surf

Since Surf does not currently support Wayland I think that it would be
a good idea to patch the source code to force the X11 backend (see the
attached patch).

Berto
Index: surf-2.1+git20221016/surf.c
===
--- surf-2.1+git20221016.orig/surf.c
+++ surf-2.1+git20221016/surf.c
@@ -347,6 +347,7 @@ setup(void)
 	atoms[AtomUri] = XInternAtom(dpy, "_SURF_URI", False);
 	atoms[AtomUTF8] = XInternAtom(dpy, "UTF8_STRING", False);
 
+	gdk_set_allowed_backends("x11");
 	gtk_init(NULL, NULL);
 
 	gdpy = gdk_display_get_default();

Bug#1051420: O: gnokii -- Datasuite for mobile phone management

[Bastian Germann]

Package: wnpp

I am orphaning gnokii. If you can afford the time to maintain it properly, 
please consider adopting.

Description: Datasuite for mobile phone management
 Gnokii is a suite of programs that allows communication with mobile phones.
 It currently supports many Nokia mobile phones, all AT capable ones as well as
 many Symbian based.

Bug#1051419: O: gcc-avr -- GNU C compiler (cross compiler for avr)

[Bastian Germann]

Package: wnpp

Hereby, I am orphaning gcc-avr. I do not use the package anymore.
Please only consider adopting if you can afford the time to maintain it.

Description: GNU C compiler (cross compiler for avr)
 This is the GNU C compiler, a fairly portable optimizing compiler which
 supports multiple languages.  This package includes support for C.

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Sam Hartman]

> "Ansgar" == Ansgar   writes:

Ansgar> On Wed, 2023-09-06 at 16:51 -0600, Sam Hartman wrote:
>> > > > > > "Luca" == Luca Boccassi  writes:    
>> Luca> /bin/sh is not universally compatible with non-Linux OSes.
>> 
>> I claim it is more compatible.

Ansgar> Why should that matter to Debian?


Debian has traditionally valued supporting common interfaces like posix,
fhs, Linux ABIs, etc where that makes sense.
We recently had a discussion of the value of interfaces in  the
discussion of changing the ABI to make merged /usr easier, and I do not
want to revisit that.

I do value this sort of interface stability, and Debian's alignment with
my values is one of the things that drew me to Debian.

So, yes, I do believe we should support encouraging portability where
that is reasonable for us.
I admit that I care more about OSes like FreeBSD than Mac OS.

More over, when merged /usr was presented to the project, it was
presented as a way to move the physical locations on files and as a way
to create an alias so that we didn't need to argue when different
distributions  made different decisions about /bin vs /usr/bin.
It was not presented as a change to common interface paths like /bin/sh.

This request is new, and given the politics, is something I find highly
problematic.
It is not abusing maintainers to ask them to respect long-standing
interfaces like the location of /bin/sh.
As Simon has pointed out, in a number of cases it is still actually RC
because it can break builds.
It is not abusive to ask maintainers to fix issues that prevent their
packages from building.
We make mistakes.
It is not abusive to get the severity of a bug wrong or even to disagree
with the severity of a bug.

I am sympathetic to the idea that after buildds are updated, we we might
want to reduce the severity of not using longstanding interface paths,
and in some cases not even treat it as a bug.
I reject the idea that /usr/bin/sh should be preferred over /bin/sh or
even the idea that it should be equally preferred.
I am open to the idea that we may not care to record that as a bug or
spend the time fixing it.

However, the tone and approach in this discussion does not encourage me
to participate.
If the current tone continues, I will use up the energy I have for
working toward a compromise and simply stand behind my support of
longstanding practice and  support of portable interfaces.

--Sam


signature.asc
Description: PGP signature

Bug#1051418: obs-studio: clicking on an xcomposite window source makes obs segfault

[Rhonda D'Vine]

Package: obs-studio
Version: 29.1.3+dfsg-2
Severity: important
 
   Hi,
 
 after upgrading from 29.0.2+dfsg-1+b1 to 29.1.3+dfsg-2 (bookworm to trixie) I
couldn't work with the xcomposite window source anymore.  In fact, a
pre-existing scene that was set up to use that source makes obs segfault
immediately when I click the entry in the sources tree, not even able to remove
it and finally switch to a pipewire window source (which has its other quirks).
 
 I'm on gnome with wayland, I guess that is needed information to reproduce it.
When starting obs in the console, the only line that is printed after clicking
on the entry is segfault.
 
 Thanks,
Rhonda
 
 
-- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
 
Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
 
Versions of packages obs-studio depends on:
ii  libavcodec60   7:6.0-6
ii  libavdevice60  7:6.0-6
ii  libavformat60  7:6.0-6
ii  libavutil587:6.0-6
ii  libc6  2.37-7
ii  libcurl3-gnutls8.2.1-1
ii  libfontconfig1 2.14.2-4
ii  libfreetype6   2.13.2+dfsg-1
ii  libgcc-s1  13.2.0-2
ii  libjansson42.14-2
ii  libluajit-5.1-22.1.0~beta3+git20220320+dfsg-4.1
ii  libmbedcrypto7 2.28.3-1
ii  libmbedtls14   2.28.3-1
ii  libmbedx509-1  2.28.3-1
ii  libobs029.1.3+dfsg-2
ii  libpci31:3.10.0-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libpython3.11  3.11.5-3
ii  libqt5core5a   5.15.10+dfsg-3
ii  libqt5gui5 5.15.10+dfsg-3
ii  libqt5network5 5.15.10+dfsg-3
ii  libqt5svg5 5.15.10-2
ii  libqt5widgets5 5.15.10+dfsg-3
ii  libqt5xml5 5.15.10+dfsg-3
ii  librist4   0.2.7+dfsg-1
ii  libspeexdsp1   1.2.1-1
ii  libsrt1.5-openssl  1.5.2-1
ii  libstdc++6 13.2.0-2
ii  libswscale77:6.0-6
ii  libudev1   254.1-2
ii  libv4l-0   1.24.1-3
ii  libva-drm2 2.19.0-1
ii  libva2 2.19.0-1
ii  libx11-6   2:1.8.6-1
ii  libx264-1642:0.164.3095+gitbaee400-3+b1
ii  libxcb-composite0  1.15-1
ii  libxcb-randr0  1.15-1
ii  libxcb-shm01.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb-xinerama0   1.15-1
ii  libxcb11.15-1
ii  python33.11.4-5+b1
ii  python3.11 3.11.5-3
 
Versions of packages obs-studio recommends:
ii  obs-plugins  29.1.3+dfsg-2
 
Versions of packages obs-studio suggests:
ii  pkexec 123-1
ii  policykit-1123-1
ii  v4l2loopback-dkms  0.12.7-2
 
-- no debconf information

-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41

[Alberto Garcia]

On Wed, Aug 30, 2023 at 04:22:04PM +, Alberto Garcia wrote:
> I'm having problems passing the autopkgtests locally with Wayland,
> but already with WebKitGTK 2.40.x ...

I noticed that surf assumes that it's running under an X11 display in
places like this:

   https://sources.debian.org/src/surf/2.1%2Bgit20221016-4/surf.c/#L1403

It doesn't work for me at all in a Wayland environment, even if
Xwayland is available.

I think that this is orthogonal to this GL problem we're talking
about, but surf should force the GDK backend to X11 because that's the
only one that it supports. gdk_set_allowed_backends() before gtk_init()
should be enough:

   gdk_set_allowed_backends("x11");
   gtk_init(NULL, NULL);

https://sources.debian.org/src/surf/2.1%2Bgit20221016-4/surf.c/#L350

Or the GDK_BACKEND=x11 variable for a quick test.

Berto

Bug#1051412: grub-common: leftover directory

[Julian Andres Klode]

Control: tag -1 confirmed

On Thu, Sep 07, 2023 at 03:40:48PM +0200, Christoph Anton Mitterer wrote:
> Package: grub-common
> Version: 2.12~rc1-9
> Severity: normal
> 
> 
> Hey.
> 
> 
> This package apparently used to contain/create /etc/default/grub.d but no 
> longer
> does so.
> 
> On upgrade:
> Unpacking grub-common (2.12~rc1-9) over (2.06-13) ...
> dpkg: warning: unable to delete old directory '/etc/default/grub.d': 
> Directory not empty
> 
> it's leftover and empty afterwards.
> 
> 
> Could you please clean that up on a future upgrade, so that it doesn't stick
> around for ever on people's systems?

Thank you for your bug report,

I think this is a regression from dropping the
/etc/default/grub.d/init-select.cfg file, we now need
to create an empty directory I suppose.

Cleaning it up would certainly be the wrong choice, after all the reason
it sticks around for you is your local configuration snippets you dropped in
there.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1043456: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1043456: fixed in tecla 45~rc-1)

[Christoph Anton Mitterer]

Sorry, hadn't seen that this was already reopened.

Cheers
Chris.

Bug#1034668: Please update to new upstream release 3.22.3 in experimental

[Benjamin Barenblat]

I will do an upload of 20230802.0 to experimental today, but I don’t
think it fixes this issue. scoped_mock_log depends on symbols in
GoogleMock, but there’s no good way to express those dependencies in a
hypothetical libabsl_scoped_mock_log.so since libgmock.so doesn’t exist.

The way upstream (Google) intends for all this to work is for protobuf
to link its Abseil and GoogleMock dependencies statically. Is that
possible? If not, I have some alternative ideas (like building a
libabsl_scoped_mock_log.so without a DT_NEEDED entry for GoogleMock),
but they all seem like hacks. I’m also open to other ideas if anybody
has them.

Bug#1043456: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1043456: fixed in tecla 45~rc-1)

[Christoph Anton Mitterer]

Control: reopen -1

Hey.

Even with 45~rc-1 I still get the same behaviour.

Nothing printed on the keys and a segfault soon as I press any key:

[ +19,376357] tecla[619172]: segfault at 18 ip 55cb938ae404 sp 
7ffc1cbea498 error 4 in tecla[55cb938ac000+4000] likely on CPU 2 (core 4, 
socket 0)
[  +0,28] Code: 5b 5d 41 5c c3 90 48 89 df 31 ed e8 06 e0 ff ff 49 89 c4 e9 
77 ff ff ff e8 39 dd ff ff 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa <48> 8b 7f 18 
e9 c3 dd ff ff 0f 1f 00 f3 0f 1e fa 48 8b 7f 18 e9 73


Cheers,
Chris.

Bug#1051417: gnumeric: Sort columns works incorrectly

[Alexandre Lymberopoulos]

Package: gnumeric
Version: 1.12.55-1
Severity: important

Dear Maintainer,

I have experiencing this problem in a while, solving it with
workarounds (using other software to this part of the taks), but I
think it is important enough to leave it as it is.

After sorting out a column with text (names more precisely),I see the
undesirable order:

Gabriela Somehing
Gabriel Otherthing

The natural lexicographical ordering should put "Gabriel " before "Gabriela".

I can provide any other details upon request. The files where this
happens have sensitive data (names, e-mails, grades etc.) , so I can't
share it here. For instance, libreoffice puts them in the correct
order (this is what I used to sort the data: prepared everything in
gnumeric, sorted what I needed in libreoffice and then finalized the
work in gnumeric again, all using ods file format, but the problem
persists in gnumeric native file format too).

Thanks in advance.

Best, Alexandre

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

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

Versions of packages gnumeric depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  gnumeric-common1.12.55-1
ii  gsfonts2:20200910-7
ii  libatk1.0-02.49.91-2
ii  libc6  2.37-7
ii  libcairo2  1.16.0-7
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1
ii  libglib2.0-0   2.77.2-1
ii  libgoffice-0.10-10 0.10.55-1
ii  libgsf-1-114   1.14.50-1
ii  libgtk-3-0 3.24.38-4
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpangocairo-1.0-01.51.0+ds-2
ii  libxml22.9.14+dfsg-1.3
ii  procps 2:4.0.3-1
ii  pxlib1 0.6.8-1+b1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages gnumeric recommends:
ii  evince45~alpha-2
pn  gnumeric-doc  
ii  lp-solve  5.5.2.5-2+b1

Versions of packages gnumeric suggests:
ii  fonts-liberation1:2.1.5-3
pn  gnumeric-plugins-extra  
pn  libgsf-1-dev

-- debconf information:
  gnumeric/existing-process: false
  gnumeric/existing-process-title:

Bug#1051408: flameshot: uploads potentially sensitive screenshots to the internet

[Sune Stolborg Vuorela]

On Thursday, September 7, 2023 2:46:35 PM CEST Peter wrote:
> Package: flameshot
> Version: 0.9.0+ds1-2

>* What was the outcome of this action?
> Default configuration uploaded my screenshots to imgur, I found a Imgur-link
> in my clipboard
> 
>* What outcome did you expect instead?
> Default configuration should save the screenshot in a local directory

Reading the current code in debian stable and newer does seem to require quite 
some setup to have auto uploads enabled.  That is also the behavior I see when 
trying it out. 

It does look like though that version 0.10 (2y ago) had the following fix:

| The ability to upload to imgur via a hotkey has been removed.
| -   Many users accidentally hit the hotkey and uploaded sensitive data
| -  Users could accidentally upload the entire desktop by hitting the upload 
|key before a region was selection


I do wonder how Kathrina Kessinger managed to reproduce it with version 
12.1.0-2

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#1043456: tecla: shows nothing and segfaults on keypress

[Jeremy Bícha]

On Thu, Sep 7, 2023 at 9:48 AM Marco d'Itri  wrote:
> On Sep 07, Jeremy Bícha  wrote:
>
> > This popup window is Tecla. Does it work correctly?
> This way it does not crash anymore.
> Still, it should be fixed to either not crash or not start if it can
> only be called by gnome-control-center.
>
> (BTW, it does not react to left-alt, while it correctly reports pressing
> right-alt as Alt_R / Meta_R.)

Please report those issues to https://gitlab.gnome.org/GNOME/tecla/-/issues

Thank you,
Jeremy Bícha

Bug#1004914: Bug#1017679: still relevant

[Nicholas Guriev]

reassign 1004914 
libclang-common-14-dev,libclang-common-15-dev,libclang-common-16-dev
found 1004914 llvm-toolchain-14/1:14.0.6-13
found 1004914 llvm-toolchain-15/1:15.0.7-8
found 1004914 llvm-toolchain-16/1:16.0.6-11
thanks

Hello! As of LLVM-16, the bug is not fixed yet. The compiler runtime library is
not built for the IMB Z platform. Because of this C++ exceptions do not work
with the libc++ standard library.

Bug#1051416: src:meta-phosh: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: meta-phosh
Version: 24
Severity: serious
Control: close -1 29
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:meta-phosh has been trying to migrate for 
32 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=meta-phosh



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051415: RFP: qalculate-qt -- QT version of Qalculate

[Sahib]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: sahibz...@gmail.com

* Package name : qalculate-qt
Version : 4.8
Upstream Contact: https://github.com/Qalculate/qalculate-qt
* URL : https://github.com/Qalculate/qalculate-qt
* License : GPL 2.0
Programming Lang: C++
Description : QT version of Qalculate

Hi Maintainers,

Qalculate/QT is an alternative to the already packaged Qalculate/GTK and 
would

be nice to have it included in Debian.

Qalculate/GTK is already available in the following repositories
https://packages.debian.org/search?keywords=qalculate-
gtk=names=all=all

Thanks
Sheik

Bug#1051414: 'ldapvi --in' issue with base64 encoded dn when (len_dn % 3) == 0

[ktetzl]

Package: ldapvi
Version: 1.7-10+b6
Severity: important
Tags: patch upstream
X-Debbugs-Cc: David Lichteblau , lda...@lists.askja.de

'ldapvi --in' has a bug in ldapvi/base64.c read_base64(..) that cause a missing
'\0' terminator when decoding base64 encoded DNs which don't end with padding
(i.e. when (len_decoded_dn % 3) == 0).

Recipe to reproduce the issue:

Example LDIF file (test.ldif):
--
# dn of 'ou=abc,dc=example,dc=com' (length 24) gets base64 encoded
# without padding
dn:: b3U9YWJjLGRjPWV4YW1wbGUsZGM9Y29t
objectclass: organizationalUnit
ou: abc
--

Running:

VISUAL=cat ldapvi --in --add test.ldif 2>/dev/null

results in the following output (note the 'sZGM9Y29t' suffix after 'add
ou=abc,dc=example,dc=com'):
--
# -*- coding: utf-8 -*- vim:fileencoding=utf-8:
# http://www.lichteblau.com/ldapvi/manual#syntax

add ou=abc,dc=example,dc=comsZGM9Y29t
objectclass: organizationalUnit
ou: abc
--


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

Kernel: Linux 5.15.90.1-microsoft-standard-WSL2 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ldapvi depends on:
ii  libc6  2.37-7
ii  libcrypt1  1:4.4.36-2
ii  libglib2.0-0   2.77.2-1
ii  libldap-2.5-0  2.5.13+dfsg-5
ii  libpopt0   1.19+dfsg-1
ii  libreadline8   8.2-1.3
ii  libtinfo6  6.4+20230625-2

ldapvi recommends no packages.

ldapvi suggests no packages.

-- no debconf information
>From 87cfd72067e927665ae819c6d0e3d1aa970777a2 Mon Sep 17 00:00:00 2001
From: ktetzlaff 
Date: Thu, 7 Sep 2023 11:59:34 +0200
Subject: [PATCH] Fix 'ldapvi --in' issue with base64 encoded dn when (len_dn %
 3) == 0

Fix 'ldapvi --in' bug in ldapvi/base64.c read_base64(..) that cause a missing
'\0' terminator when decoding base64 encoded DNs which don't end with
padding (i.e. when (len_decoded_dn % 3) == 0).

Recipe to reproduce the issue without the fix:

Example LDIF file (test.ldif):
--
# dn of 'ou=abc,dc=example,dc=com' (length 24) gets base64 encoded
# without padding
dn:: b3U9YWJjLGRjPWV4YW1wbGUsZGM9Y29t
objectclass: organizationalUnit
ou: abc
--

Running:

VISUAL=cat ldapvi --in --add test.ldif 2>/dev/null

results in the following output (note the 'sZGM9Y29t' suffix after 'add
ou=abc,dc=example,dc=com'):
--
# -*- coding: utf-8 -*- vim:fileencoding=utf-8:
# http://www.lichteblau.com/ldapvi/manual#syntax

add ou=abc,dc=example,dc=comsZGM9Y29t
objectclass: organizationalUnit
ou: abc
--
---
 ldapvi/base64.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ldapvi/base64.c b/ldapvi/base64.c
index b21ded7..755da59 100644
--- a/ldapvi/base64.c
+++ b/ldapvi/base64.c
@@ -278,6 +278,8 @@ read_base64(
 */
if (state != 0)
return (-1);
+   /* Make sure that target is terminated with nul byte. */
+   target[tarindex] = '\0';
}
 
return (tarindex);
-- 
2.40.1

Bug#1051409: podman: Podman man pages use en-dash instead of dash

[Reinhard Tartler]

Control: reassign -1 go-md2man-v2
stop

Thanks for your report Guy,

All manpages in podman are written in markdown, and you can review the
sources at
https://github.com/containers/podman/blob/main/docs/source/Introduction.rst
-- as you can see the sources do not contain any unicode characters.

I strongly suspect that the unicode characters are introduced via the
go-md2man utility. I'm reassigning this to that package for additional
thoughts and suggestions. Please feel free to reassign back if this isn't
coming from e.g.
https://github.com/cpuguy83/go-md2man/blob/master/md2man/roff.go but
something in the libpod packaging.




On Thu, Sep 7, 2023 at 9:24 AM Guy Rutenberg  wrote:

> Package: podman
> Version: 4.3.1+ds1-8+b2
> Severity: minor
> X-Debbugs-Cc: guyrutenb...@gmail.com
>
> Dear Maintainer,
>
> The man pages supplied by the podman package use unicode en-dash (‐) to
> document flags instead of regular dash (-). This is both inconvinient when
> try
> to search the man page, and incorrect (as you would use normal dash in the
> shell).
>
> Thanks,
> Guy
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.1.6+ds1-1
> ii  golang-github-containers-common  0.50.1+ds1-4
> ii  libc62.37-7
> ii  libdevmapper1.02.1   2:1.02.185-2
> ii  libgpgme11   1.18.0-3+b1
> ii  libseccomp2  2.5.4-1+b3
> ii  libsubid41:4.13+dfsg1-1+b1
> ii  runc 1.1.5+ds1-1+b2
>
> Versions of packages podman recommends:
> ii  buildah1.28.2+ds1-3+b2
> ii  dbus-user-session  1.14.10-1
> ii  fuse-overlayfs 1.10-1
> ii  slirp4netns1.2.0-1
> ii  tini   0.19.0-1
> ii  uidmap 1:4.13+dfsg1-1+b1
>
> Versions of packages podman suggests:
> pn  containers-storage  
> pn  docker-compose  
> ii  iptables1.8.9-2
>
> -- Configuration Files:
> /etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied:
> '/etc/cni/net.d/87-podman-bridge.conflist'
>
> -- no debconf information
>


-- 
regards,
Reinhard

Bug#1043456: tecla: shows nothing and segfaults on keypress

[Marco d'Itri]

On Sep 07, Jeremy Bícha  wrote:

> This popup window is Tecla. Does it work correctly?
This way it does not crash anymore.
Still, it should be fixed to either not crash or not start if it can 
only be called by gnome-control-center.

(BTW, it does not react to left-alt, while it correctly reports pressing 
right-alt as Alt_R / Meta_R.)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1051413: src:gpsim-doc: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: gpsim-doc
Version: 0.22.0-2.2
Severity: serious
Control: close -1 0.22.0-3
X-Debbugs-CC: b...@debian.org
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:gpsim-doc has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build from source.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=gpsim-doc



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1043456: tecla: shows nothing and segfaults on keypress

[Jeremy Bícha]

Tecla's initial release is more designed to be run from another app
than directly from the command line. Let's try this:

Make sure you have gnome-control-center 1:45~rc-2 installed
Open the Settings app
Switch to the Keyboard panel.
Click the⋮ button next to your keyboard layout and click View Keyboard Layout

This popup window is Tecla. Does it work correctly?

Thank you,
Jeremy Bícha

Bug#1041866: Package: geeqie

[Andreas Rönnquist]

retitle 1041866 geeqie: incorrect lua dependency
thanks

On Mon, 24 Jul 2023 18:07:03 +0200 Florian Cramer  wrote:
> Package: geeqie
> 
> geeqie (version 1:2.0.1-8+b2, Trixie package) depends on the
> package liblua5.1-0 . However, liblua5.1-0 is not included in the
> dependencies of Trixie's geeqie package and needs to be manually installed.
> Without an installed liblua5.1-0, geeqie quit upon launch with an
> error message about liblua5.1.so.0 missing.
> 
> I am using Debian Trixie with kernel 6.3.0-1-amd64 #1 SMP PREEMPT_DYNAMIC
> Debian 6.3.7-1 (2023-06-12) x86_64 GNU/Linux.

Also, what is the output of 

ldd /usr/bin/geeqie | grep lua

for you?

-- Andreas Rönnquist
gus...@gusnan.se

Bug#1051412: grub-common: leftover directory

[Christoph Anton Mitterer]

Package: grub-common
Version: 2.12~rc1-9
Severity: normal


Hey.


This package apparently used to contain/create /etc/default/grub.d but no longer
does so.

On upgrade:
Unpacking grub-common (2.12~rc1-9) over (2.06-13) ...
dpkg: warning: unable to delete old directory '/etc/default/grub.d': Directory 
not empty

it's leftover and empty afterwards.


Could you please clean that up on a future upgrade, so that it doesn't stick
around for ever on people's systems?


Thanks :-)
Chris.

Bug#1051411: fcoe-utils: Cyclic systemd unit dependencies

[Stefan Sterz]

Package: fcoe-utils
Version: 1.0.34-2
Severity: important

Dear Maintainer,

the unit file "fcoe-utils.service" included in this package contains
these two lines:

After=lldpad.service
Before=network.target

The package lldpad's "lldpad.service" unit file states this:

After=network.target

This leads to a circular dependency where systemd can't start
fcoe-utils.service after lldpad.service and before network.target while
also starting lldpad.service after network.target. Hence, systemd breaks
this circular dependency by not starting one of the services.

If I understand correctly, to reliably be able to start both services,
one of these dependencies needs to be changed. From what I can tell,
from the Github repository, fcoe-utils.service should be started after
network.target [1]. The unit file there includes this "After" line:

After=syslog.target network.target

Kind regards,
Stefan

[1]: https://github.com/openSUSE/fcoe-utils/blob/master/etc/systemd/fcoe.service

-- 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.2.16-12-pve (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fcoe-utils depends on:
ii  libc6  2.36-9+deb12u1
ii  libpciaccess0  0.17-2
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages fcoe-utils recommends:
pn  lldpad  

fcoe-utils suggests no packages.

Bug#1051410: RFP: keysmith -- KDE Keysmith

[Sheik]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: sahibz...@gmail.com

* Package name: keysmith
  Version : 23.08.0
  Upstream Contact: https://invent.kde.org/utilities/keysmith
* URL : https://apps.kde.org/keysmith
* License : https://spdx.org/licenses/GPL-3.0-or-later.html
  Programming Lang: C++
  Description : KDE Keysmith

Hi Maintainers,

KDE/Keysmith is an OTP Client and would be a useful addition to Debian.

Bug#1051409: podman: Podman man pages use en-dash instead of dash

[Guy Rutenberg]

Package: podman
Version: 4.3.1+ds1-8+b2
Severity: minor
X-Debbugs-Cc: guyrutenb...@gmail.com

Dear Maintainer,

The man pages supplied by the podman package use unicode en-dash (‐) to
document flags instead of regular dash (-). This is both inconvinient when try
to search the man page, and incorrect (as you would use normal dash in the
shell).

Thanks,
Guy


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

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

Versions of packages podman depends on:
ii  conmon   2.1.6+ds1-1
ii  golang-github-containers-common  0.50.1+ds1-4
ii  libc62.37-7
ii  libdevmapper1.02.1   2:1.02.185-2
ii  libgpgme11   1.18.0-3+b1
ii  libseccomp2  2.5.4-1+b3
ii  libsubid41:4.13+dfsg1-1+b1
ii  runc 1.1.5+ds1-1+b2

Versions of packages podman recommends:
ii  buildah1.28.2+ds1-3+b2
ii  dbus-user-session  1.14.10-1
ii  fuse-overlayfs 1.10-1
ii  slirp4netns1.2.0-1
ii  tini   0.19.0-1
ii  uidmap 1:4.13+dfsg1-1+b1

Versions of packages podman suggests:
pn  containers-storage  
pn  docker-compose  
ii  iptables1.8.9-2

-- Configuration Files:
/etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied: 
'/etc/cni/net.d/87-podman-bridge.conflist'

-- no debconf information

Bug#1051408: flameshot: uploads potentially sensitive screenshots to the internet

[Kathrina . Kessinger]

Package: flameshot
Version: 12.1.0-2
Followup-For: Bug #1051408

I attach a patch to prevent this from happening. Users will need to
get their own imgur token in order to upload.
diff --git a/src/utils/confighandler.cpp b/src/utils/confighandler.cpp
index 657e896..59c76ba 100644
--- a/src/utils/confighandler.cpp
+++ b/src/utils/confighandler.cpp
@@ -120,7 +120,7 @@ static QMap>
 // NOTE: If another tool size is added besides drawThickness and
 // drawFontSize, remember to update ConfigHandler::toolSize
 OPTION("copyOnDoubleClick"   ,Bool   ( false 
)),
-OPTION("uploadClientSecret"  ,String ( 
"313baf0c7b4d3ff")),
+OPTION("uploadClientSecret"  ,String ( 
"000")),
 };
 
 static QMap> recognizedShortcuts = {
-- 

Bug#1051406: Please upload to unstable

[Matthias Geiger]

Hi Jordi,

> One of my packages uses a vendored copy of vma, so it would benefit from
> this package being generally available in unstable and testing.
>
>Can you please upload it to unstable?

The issue I ran into that vk_mem_alloc.h uses DOS LF. The experimental 
version has a bug with GCC 13 fixable by a single-line patch; I haven't 
been able to


convert it to unix LF and apply the patch. I might grab an upstream 
snapshot; I'll try to reach a solution.


--
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#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Ansgar]

On Wed, 2023-09-06 at 16:51 -0600, Sam Hartman wrote:
> > > > > > "Luca" == Luca Boccassi  writes:
>     Luca> /bin/sh is not universally compatible with non-Linux OSes.
> 
> I claim it is more compatible.

Why should that matter to Debian?

Should Debian invest resources to make upstream software more portable
to systems like Mac OS X? For me this seems out of scope for Debian.

>     Luca> Also I thought that policy should not be used to beat other
>     Luca> developers (it is because of this) and it should reflect
> the
>     Luca> common practices adopted in Debian (it does not because of
>     Luca> this). Is that no longer the case?
> 
> I'd consider it a non-RC bug if someone were manually writing
> #!/usr/bin/sh
> 
> We can debate about normal vs minor.

Should we require Debian maintainers to patch this in software packaged
for Debian? Why?

I think it is fine to wait with this until buildds use merged-/usr for
builds, but I don't see any reason to spend resources on this after
that.


Ansgar

Bug#1051408: flameshot: uploads potentially sensitive screenshots to the internet

[Peter]

Package: flameshot
Version: 0.9.0+ds1-2
Severity: critical
Tags: upstream
Justification: causes serious data loss
X-Debbugs-Cc: pe...@ostwall195.de

Dear Maintainer,

   * What led up to the situation?
I have installed the package for taking screenshots on recommendation

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Installed the package on debian bookworm

   * What was the outcome of this action?
Default configuration uploaded my screenshots to imgur, I found a Imgur-link in
my clipboard

   * What outcome did you expect instead?
Default configuration should save the screenshot in a local directory




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

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

Versions of packages flameshot depends on:
ii  hicolor-icon-theme0.17-2
ii  libc6 2.31-13+deb11u6
ii  libfmt7   7.1.3+ds1-5
ii  libgcc-s1 10.2.1-6
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5dbus5   5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5network55.15.2+dfsg-9
ii  libqt5svg55.15.2-3
ii  libqt5widgets55.15.2+dfsg-9
ii  libspdlog1 [libspdlog1-fmt7]  1:1.8.1+ds-2.1
ii  libstdc++610.2.1-6

flameshot recommends no packages.

Versions of packages flameshot suggests:
ii  ca-certificates  20210119
ii  openssl  1.1.1n-0+deb11u5

Bug#1043415: netdata: Integrated web server displays "File does not exist, or is not accessible: "

[Faidon Liambotis]

Control: severity -1 grave

On Thu, Aug 10, 2023 at 04:43:18PM +0200, Marc Riedel wrote:
> When opening http://localhost:1, only "File does not exist, or is not
> accessible: " is displayed. Maybe related to commit "Refreshing allow-
> symlinks.patch."

I just tried installing netdata to experiment with it, and I couldn't
get the most basic out-of-the-box configuration to work due to this bug.
Hence setting the severity to grave. I rebuilt with the allow-symlinks
patch disabled and everything seemed to work, so I guess the fix may be
easy enough :)

(The package already has a couple more severity: serious bugs and is
marked for autoremoval from testing, so it won't make a huge
difference...)

Faidon

Bug#1050515: gtk-sharp3: Move to GtkSharp upstream

[Jordi Mallach]

Source: gtk-sharp3
Version: 2.99.3-4.1
Followup-For: Bug #1050515
X-Debbugs-Cc: j...@softcatala.org

gbrainy is marked for autoremoval due to RC bugs in gtk-sharp3, and
its upstream author, Jordi Mas, contacted me to ask me about Debian's
plans for this package. Fedora is already using the new source in
https://github.com/GLibSharp/GtkSharp and we should do the same as
soon as possible.

Is anyone working on this? I can devote some time to it.

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

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

Bug#1051407: RFS: srs-server/5.0.170 [ITP] -- simple, high-efficiency, real-time video server

[nmgchenhaibo]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "srs-server":

 * Package name : srs-server
   Version  : 5.0.170
   Upstream contact : chenhaibo 
 * URL  : https://ossrs.io
 * License  : Apache, BSD, GPL-2.0, LGPLv2.1 and GPLv2+, MPL-2.0, MIT 
and MulanPSL-2.0
 * Vcs  : [fill in URL of packaging vcs]
   Section  : video

The source builds the following binary packages:

  srs-server - simple, high-efficiency, real-time video server

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

  https://mentors.debian.net/package/srs-server/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/srs-server/srs-server_5.0.170.dsc

Changes for the initial release:

 srs-server (5.0.170) unstable; urgency=medium
 .
   * Reintroduce srs-server to Debian.
 There are far to many changes since srs-server 0.1.0 to mention them
 here, see:
 https://github.com/ossrs/srs/blob/develop/trunk/doc/CHANGELOG.md
 Many features have already been implemented, see:
 https://github.com/ossrs/srs/blob/develop/trunk/doc/Features.md
 Other documents can be found here:
 https://github.com/ossrs/srs

Regards,
-- 
  chenhaibo