On Sun, 15 May 2022 16:02:48 +0300 Adrian Bunk wrote:
Version: 2.6.0~git20220510+dco-1
openvpn (2.6.0~git20220510+dco-1) experimental; urgency=medium
...
* Build against OpenSSL 3.0
-- Bernhard Schmidt Fri, 13 May 2022 00:01:35 +0200
Berni, would you mind uploading this version to
Am 05.05.22 um 17:10 schrieb Salvatore Bonaccorso:
Source: rsyslog
Version: 8.2204.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team
Hi,
The following vulnerability was published for rsyslog. Filling for now
as
Dear arm porters,
can you please take a look at this?
Thanks,
Michael
Am 15.04.22 um 21:19 schrieb Paul Gevers:
Source: exempi
Version: 2.5.2-1
Severity: serious
Control: close -1 2.6.1-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync
Dear
Control: severity -1 important
Am 12.04.22 um 09:15 schrieb Claudio Kuenzler:
Package: systemd
Version: 247.3-7
Severity: critical
Justification: breaks the whole system
Dear Maintainer,
After having created a new LXC container (using lxc-create) using the
lxc-download template and using
Hi
Am 08.04.22 um 10:11 schrieb Michael Biebl:
Am 08.04.22 um 09:56 schrieb Andrej Shadura:
I noticed you uploaded the workaround to Debian, and it’s about to
migrate to testing — how about downgrading the bug from
release-critical? Assuming that it actually helps.
Once NM is in testing
Am 08.04.22 um 09:56 schrieb Andrej Shadura:
Hi,
On Mon, 4 Apr 2022, at 10:47, Michael Biebl wrote:
That said, there might be a workaround available in NetworkManager
I filed
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/964
and a potential fix is now available
On Fri, 25 Mar 2022 07:07:03 +0900 Masashi Honma
wrote:
> Masashi, if I understand you correctly, you argue that this is an issue
> with the AP (or its firmware).
> If so, should the company AVM be contacted about this?
> I'm afraid I'm not too knowledgeable in that regard.
Michael,
Some more data points:
Disabling NetworkManager completely and using wpasupplicant alone with
the following config:
network={
ssid="wgrouter"
psk=""
key_mgmt=WPA-PSK
id_str="wgrouter"
}
does indeed work.
As soon as I enable NetworkManager though, my
Am 19.03.22 um 22:30 schrieb Andrej Shadura:
Hi,
Michael, Masashi, what’s your opinion, what should I do as the maintainer of
wpa in Debian?
I can still reproduce the problem.
If more debugging is needed, please let me know. I'll try to help as
much as I can.
Michael
OpenPGP_signature
Package: python3-fonttools
Version: 4.29.1-2
Severity: serious
Installing python3-fonttools is currently not possible:
# apt install python3-fonttools
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may
Am 18.02.22 um 02:42 schrieb Paul Wise:
systemd upstream seems to have deleted their 247.2 git tag and there is
no reference to it in their NEWS files.
Stable point releases are available from
https://github.com/systemd/systemd-stable
In this specific instance from the v247-stable branch
Am 14.02.22 um 18:51 schrieb Michael Biebl:
I agree.
Apparently this isn't the first time that dmraid has been bitten by this
split-usr issue (and having to manually fiddle with the creation of the
.so symlink) [1]
Getting rid of this unnecessary complexity would solve this once
Am 14.02.22 um 17:55 schrieb Helmut Grohne:
We have this moratorium in place that says you should not move files
from / to /usr, because it could go bad when moving files.
ttbomk, those "bad" things only happen if you move files from /lib to
/usr (under the same name) but *also* move it
/libdmraid.a
statically into libblockdev-dm2
Am 13.02.22 um 14:13 schrieb Michael Biebl:
Control: reassign -1 libdmraid-dev
Control: found -1 1.0.0.rc16-10
Control: affects src:libblockdev
Reassigning accordingly.
Am 13.02.22 um 14:11 schrieb Michael Biebl:
Looking at those symbols, they all
Looking at those symbols, they all appear to come from libdmraid and
this appears to be an issue caused by dmraid (1.0.0.rc16-10)
Building in a sid chroot with libdmraid-dev_1.0.0.rc16-9_amd64.deb and
libdmraid1.0.0.rc16_1.0.0.rc16-9_amd64.deb makes the build succeed.
So I suspect this breakage
Control: reassign -1 libdmraid-dev
Control: found -1 1.0.0.rc16-10
Control: affects src:libblockdev
Reassigning accordingly.
Am 13.02.22 um 14:11 schrieb Michael Biebl:
Looking at those symbols, they all appear to come from libdmraid and
this appears to be an issue caused by dmraid (1.0.0
Control: tag -1 pending
Hello,
Bug #1005543 in d-feet reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Since I could easily reproduce it, I ran git bisect.
7a9c36722511ce4df88b76cceceb241d6c6a151e is the first bad commit
commit 7a9c36722511ce4df88b76cceceb241d6c6a151e
Author: Brian Norris
Date: Fri Feb 28 15:50:47 2020 -0800
DBus: Add "sae" to interface key_mgmt capabilities
This
On Wed, 19 Jan 2022 11:13:05 +0100 Michael Biebl wrote:
I tried the various versions from snapshots.d.o
2:2.9.0-23 - works
2:2.9.0+git20200221+f65da0c-1 - works
2:2.9.0+git20200517+dd2daf0-1 - doesn't work
2:2.9.0+git20210909+a75fdcd-1 - doesn't work
2:2.9.0+git20211018+2e122945fa53-1
Control: tags -1 + unreproducible moreinfo
Control: severity -1 important
Am 20.01.22 um 05:08 schrieb Vincent Lefevre:
Package: systemd
Version: 250.3-1
Severity: critical
Justification: breaks unrelated software
The upgrade to systemd 250.3-1 breaks lightdm / lightdm-gtk-greeter:
the menu
Am 18.01.22 um 21:56 schrieb Andrej Shadura:
Hi Michael,
On Tue, 18 Jan 2022, at 21:52, Michael Biebl wrote:
Am 18.01.22 um 21:47 schrieb Masashi Honma:
The log indicates that the Wi-Fi access point rejected the association
request from the Wi-Fi station with status
code
Am 18.01.22 um 21:47 schrieb Masashi Honma:
The log indicates that the Wi-Fi access point rejected the association
request from the Wi-Fi station with status
code=WLAN_STATUS_INVALID_IE.
We can't read from this log why the Wi-Fi access point rejected the
assocication request.
If I have that
Control: severity -1 grave
Control: forwarded -1 https://github.com/systemd/systemd/issues/21964
Control: tags -1 + fixed-upstream patch
Hi Tollef,
sorry for the inconvenience
Am 18.01.22 um 17:03 schrieb Tollef Fog Heen:
It seems like this is https://github.com/systemd/systemd/issues/21964.
Hardware:
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205
[Taylor Peak] (rev 34)
Subsystem: Intel Corporation Centrino Advanced-N 6205 (802.11a/b/g/n)
Flags: bus master, fast devsel, latency 0, IRQ 35, IOMMU group 13
Memory at f250 (64-bit,
Package: wpasupplicant
Version: 2:2.10-1
Severity: grave
Hi,
during todays upgrade of wpasupplicant 2:2.9.0-23 to 2:2.10-1 my network
connection was killed (I'm using NetworkManager 1.34.0) and I wasn't
able to successfully connect again, even after a reboot.
Only a downgrade to 2:2.9.0-23
Control: found -1 249.7-1
Control: severity -1 important
Am 12.01.22 um 18:20 schrieb Christian Weeks:
I don't see anything in the journal, I've had a fairly long look. I do not have
the coredump utility installed.
As I have mentioned, rebooting fixed whatever caused the problem during the
Control: tags -1 + moreinfo
Hello,
systemd freezes execution when it crashes (you should see a
corresponding log message in the journal).
For this bug report to be actionable, we will need at the very least a
backtrace of the crash.
In case you had systemd-coredump installed, coredumpctl
On Mon, 6 Dec 2021 14:20:51 +0100 Sven Mueller
wrote:
> Package: dnsmasq
> Version: 2.86-1.1
> Severity: Serious
>
> We have this our /etc/NetworkManager/dnsmasq.d/local-proxy:
>
> local=/in.ourdoma.in/127.0.1.1#10053
>
> This leads to:
>
> dnsmasq: Bad address in --address at line 2 of
>
Package: devscripts
Version: 2.21.5
Severity: serious
Hi,
since upgrading to devscrips 2.21.5, uscan fails when trying to run it
for the systemd package:
$ uscan --report --verbose
uscan info: uscan (version 2.21.5) See uscan(1) for help
uscan info: Scan watch files in .
find:
Control: tags -1 + patch
Hi Simon
On 10.11.21 20:44, Michael Biebl wrote:
Simon,
any news here?
Would you mind if I prepare an NMU with
26bbf5a314d833beaf0f147d24409969f05f3dba ?
I decided to follow the rules in [1] and uploaded a fixed package to
DELAYED/2. Please holler if you want me
Simon,
any news here?
Would you mind if I prepare an NMU with
26bbf5a314d833beaf0f147d24409969f05f3dba ?
Regards,
Michael
On Sun, 3 Oct 2021 21:32:53 +0200 Michael Biebl
wrote:
> Control: reassign -1 dnsmasq/2.86-1
>
> It's a (known) regression in dnsmasq 2.86-1
>
> CCing wh
On 04.11.21 15:42, Dylan Aïssi wrote:
Le jeu. 4 nov. 2021 à 14:57, Michael Biebl a écrit :
I guess we could just as well ship a symlink
/usr/bin/pipewire-pulse → /usr/bin/pipewire ?
Dylan, do you know why upstream basically builds the same executable twice?
Thanks! :-) Indeed, I got
I briefly looked into this.
The offending binares are /usr/bin/pipewire and /usr/bin/pipewire-pulse
On amd64 I get:
# objdump -g pipewire-pulse | tail -n 5
Contents of the .gnu_debuglink section (loaded from pipewire-pulse):
Separate debug info file:
Control: reassign -1 dnsmasq/2.86-1
It's a (known) regression in dnsmasq 2.86-1
CCing what I sent Simon privately a couple of days ago
Hi Simon,
as you probably know, the recent update of dnsmasq 2.86 to unstable broke the
systemd autopkgtests, namely test-networkd.py, and more specifically
Am 23.09.21 um 14:14 schrieb Michael Biebl:
Now, with the above change in debhelper, this code no longer works as
intended. One issue I immediately see is that
/var/lib/dpkg/info/systemd.conffiles doesn't contain any version
constraints but only
remove-on-upgrade /etc/dhcp/dhclient-exit
Am 23.09.21 um 14:14 schrieb Michael Biebl:
Or maybe there is another way to fix the immediate breakage?
Fwiw, Ansgar suggested to remove those conffiles from
systemd.maintscript and call dpkg-maintscript-helper manually.
E.g. could "remove-on-upgrade" have a version constraint to
Hi everyone
Am 23.09.21 um 12:22 schrieb Ansgar:
Hi,
On Thu, 2021-09-23 at 09:51 +0300, Martin-Éric Racine wrote:
Setting up systemd (247.9-2) ...
Removing obsolete conffile /etc/dhcp/dhclient-exit-hooks.d/timesyncd
...
Removing obsolete conffile /etc/systemd/timesyncd.conf ...
Setting up
Package: criu
Version: 3.16-1
Followup-For: Bug #994929
Afaics, it's a result of shipping criu-ns
https://salsa.debian.org/debian/criu/-/blob/master/scripts/criu-ns
which has a "#!/usr/bin/env python" shebang.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT
Hi Aurelien,
thanks for the bug report
On Thu, 9 Sep 2021 18:48:42 +0200 Aurelien Jarno wrote:
> One way to workaround the issue would be to force systemd-logind to do a
> NSS lookup, just like it it s already the case when a user log onto the
> system.
Before the upgrade, I assume, i.e. in
Hi Aurelien
Am 07.09.21 um 12:41 schrieb Aurelien Jarno:
Hi,
On 2021-09-07 10:39, Michael Hudson-Doyle wrote:
What's happening is that systemd is running with the old glibc, forks and
then does NSS things that cause the new glibc's NSS modules to load and
they don't necessarily work,
Am 01.09.21 um 13:51 schrieb Debian Bug Tracking System:
This is an automatic notification regarding your Bug report
which was filed against the tracker package:
#993430: Breaks nautilus Settings schema 'org.freedesktop.Tracker.Miner.Files'
is not installed
It has been closed by Debian FTP
Small correction:
nautilus wasn't updated because it would have forced the removal of gedit.
OpenPGP_signature
Description: OpenPGP digital signature
Package: tracker
Version: 3.1.1-3
Severity: serious
The latest update of tracker seems to have broken nautilus (which is
still at version 3.38.2-1 here, has I have plugins like
nautilus-nextcloud which haven't been updated yet).
After this upgrade, nautilus fails to start
$ /usr/bin/nautilus
Hi Niels
Am 31.08.21 um 18:07 schrieb Niels Thykier:
My thought is that this is not something I want in dh_link - dh_link has
no business second guessing the link values it gets. Since dh_link runs
after dh_installsystemd, then we cannot even rely on dh_installsystemd
to perform a fix up
Am 31.08.21 um 10:17 schrieb Vincent Lefevre:
/etc/systemd/system/multi-user.target.wants/rpcbind.service ->
/lib/systemd/system/rpcbind.service
though /lib/systemd/system/rpcbind.service doesn't exist.
That's a separate issue
OpenPGP_signature
Description: OpenPGP digital signature
Am 30.08.21 um 18:31 schrieb Vincent Lefevre:
Package: systemd
Version: 247.9-1
Severity: critical
Justification: breaks unrelated software
systemd provides a dangling symlink:
$ ls -l /lib/systemd/system/portmap.service
lrwxrwxrwx 1 root root 15 2021-08-17 17:31:36
Am 30.08.21 um 18:31 schrieb Vincent Lefevre:
Package: systemd
Version: 247.9-1
Severity: critical
Justification: breaks unrelated software
systemd provides a dangling symlink:
$ ls -l /lib/systemd/system/portmap.service
lrwxrwxrwx 1 root root 15 2021-08-17 17:31:36
Control: tags -1 + moreinfo
Am 27.08.21 um 15:46 schrieb Gianfranco Costamagna:
Source: firewalld
Version: 1.0.1-1
Severity: serious
tags: patch
Hello, looks some tests needs nftables and ipset installed inside the chroot
the following patch makes them pass all.
diff -Nru
Am 18.08.21 um 01:28 schrieb Michael Biebl:
Am 18.08.2021 um 01:18 schrieb Andreas Beckmann:
On 18/08/2021 01.09, Michael Biebl wrote:
It's not a package split.
It looked like one.
systemd-standalone-* are new packages. They follow the debian policy
recommended way using C/R/P against
Am 18.08.2021 um 01:18 schrieb Andreas Beckmann:
On 18/08/2021 01.09, Michael Biebl wrote:
It's not a package split.
It looked like one.
systemd-standalone-* are new packages. They follow the debian policy
recommended way using C/R/P against a virtual package.
You still need versioned B+R
Am 18.08.2021 um 01:09 schrieb Michael Biebl:
Am 18.08.2021 um 01:03 schrieb Andreas Beckmann:
On 18/08/2021 00.41, Michael Biebl wrote:
during a test with piuparts I noticed your package fails to upgrade
from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade
Am 18.08.2021 um 01:03 schrieb Andreas Beckmann:
On 18/08/2021 00.41, Michael Biebl wrote:
during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other
Control: tags -1 + moreinfo
Am 18.08.2021 um 00:33 schrieb Andreas Beckmann:
Package: systemd-standalone-sysusers,systemd-standalone-tmpfiles
Version: 249.3-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package fails to
Am 30.07.21 um 22:26 schrieb Adrian Bunk:
On Wed, Jul 28, 2021 at 10:17:56PM +0200, Michael Biebl wrote:
Just a general remark that using Requires/After=systemd-udev-settle.service
is a really bad idea.
Whenever possible, you should avoid using it.
Quoting from the systemd-udev
On Wed, 28 Jul 2021 18:09:58 +0200 Dennis Filder wrote:
> X-Debbugs-CC: Martin-Éric Racine
>
> A couple of observations:
>
> * You have tpm2-abrmd installed, and its systemd unit is the only one
> defining a Requires=systemd-udev-settle.service. 2.1.0-1 under
> Buster didn't do that yet,
control: reassign -1 ifupdown
Am 28.07.21 um 06:13 schrieb Martin-Éric Racine:
> Package: systemd
> Version: 247.3-6
> Severity: serious
>
Since upgrading to Bullseye, the boot process stalls at network loading [1]
when booting in regular mode. When booting in recovery mode and resuming boot
Hi Matteo
Am 01.06.21 um 15:55 schrieb Matteo F. Vescovi:
Actually, upstream already provided me a patch to fix the issue but I'm
lacking time these days to prepare a revision with the fix.
I can confirm that 1.4.11+dfsg-3 fixes the issue. Thanks!
I'll try to upload a fixed source package
Control: tags -1 patch
1.4.11+dfsg-2 bad
1.4.12+dfsg-1 bad
1.4.13+dfsg-1 bad
1.4.16+dfsg-1 good
1.4.17+dfsg-1 good
git bisect to the rescue
The commit which fixed this issue is
e6a8e76e69f6d614abdf8a2677a37e53b08829c5 is the first bad commit
commit e6a8e76e69f6d614abdf8a2677a37e53b08829c5
Control: severity -1 normal
Control: close -1
Am 01.06.2021 um 10:14 schrieb Andrei POPESCU:
Control: reassign -1 network-manager 1.14.6-2+deb10u1
On Ma, 01 iun 21, 03:56:31, José Luis González wrote:
Package: gnome-network-manager
Version: 1.14.6-2+deb10u1
Severity: critical
GNOME Network
I can only reproduce the issue with GNOME/Wayland, Xorg appears to work
fine.
OpenPGP_signature
Description: OpenPGP digital signature
Package: remmina-plugin-rdp
Version: 1.4.11+dfsg-2
Severity: serious
Hi,
it appears, the current version of remmina / RDP support in remmina is
completely broken under Wayland.
I've created a screencast, which illustrates the issue.
See https://people.debian.org/~biebl/2021-05-27_1035152873.mp4
Am 24.05.21 um 19:00 schrieb Michael Biebl:
Fwiw, I would do the following:
- Move /etc/thinkpad.yaml to /usr/share/doc/thinkpad/examples
- Do not remove /etc/thinkpad.conf (automatically) on upgrades
Or at least only remove it when it is unmodified[1] and do *not* rename
it to dpkg-bak when
Fwiw, I would do the following:
- Move /etc/thinkpad.yaml to /usr/share/doc/thinkpad/examples
- Do not remove /etc/thinkpad.conf (automatically) on upgrades
- Put up a big fat NEWS entry with instructions how to convert from
/etc/thinkpad.conf to /etc/thinkpad.yaml
I know, this will leave
Hi kibi
On Fri, 23 Apr 2021 22:57:40 +0200 Cyril Brulebois wrote:
> - broken rescue mode
Is this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952450 or
something else?
I.e. do you consider #952450 a blocker for d-i?
Regards,
Michael
signature.asc
Description: This is a digitally
Control: reassign -1 opentmpfiles
Am 15.04.2021 um 01:43 schrieb Lorenzo:
Control: reassign -1 systemd
Control: found -1 247.3-5
Control: retitle 986886 systemd-tmpfiles(8) doc --prefix incomplete
On Tue, 13 Apr 2021 17:22:19 +0200 Michael Biebl
wrote:
Am 13.04.2021 um 16:20 schrieb
Control: tags -1 + moreinfo
https://buildd.debian.org/status/package.php?p=avahi=buster
looks good, i.e. avahi has been built on all architectures successfully.
Could you paste the output of
apt-cache policy libavahi-client3:amd64
apt-cache policy libavahi-client3:i386
Maybe you have a package
Hi Santiago
On Fri, 12 Mar 2021 21:33:05 +0100 Santiago Ruano =?iso-8859-
1?Q?Rinc=F3n?= wrote:
> Dear maintainers of the packages that would be removed by the removal
of
> libcgroup,
Checking reverse dependencies...
# Broken Depends:
cinder: cinder-common → cgroup-tools
clsync: clsync →
Am 14.02.2021 um 12:08 schrieb Michael Biebl:
Am 14.02.2021 um 12:06 schrieb Michael Biebl:
Hi Martin,
as written in earlier and in the upstream bug report, this is not a
recent regression but a result of pre-releases being built
--with-more-asserts=100
If you build 1.28.0 this way, python
Am 14.02.2021 um 12:06 schrieb Michael Biebl:
Hi Martin,
as written in earlier and in the upstream bug report, this is not a
recent regression but a result of pre-releases being built
--with-more-asserts=100
If you build 1.28.0 this way, python-dbusmock will fail as well.
See the magic
Hi Martin,
as written in earlier and in the upstream bug report, this is not a
recent regression but a result of pre-releases being built
--with-more-asserts=100
If you build 1.28.0 this way, python-dbusmock will fail as well.
See the magic in configure.ac
Regards,
Michael
Hi Martin,
since you are more familiar with python-dbusmock:
does that ring a bell?
On Fri, 12 Feb 2021 16:22:14 +0200 Adrian Bunk wrote:
> Source: network-manager
> Version: 1.29.90-1
> Severity: serious
>
>
Hi Adrian
Am 12.02.21 um 15:22 schrieb Adrian Bunk:
Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.bwcca9__/downtmp/build.HQy/src/tests/test_networkmanager.py",
line 171, in test_one_wifi_with_accesspoints
subprocess.check_call(['nmcli', 'dev', 'wifi', 'connect',
Package: libelfutils1
Version: 0.182+20210203-1.1
Severity: serious
Hi,
todays "apt upgrade" failed:
# apt-cache policy libelf1:amd64
libelf1:
Installed: 0.182+20210203-1.1
Candidate: 0.182+20210203-1.1
Version table:
*** 0.182+20210203-1.1 500
500 http://ftp.debian.org/debian
Control: forcemerge 964139 -1
Control: tags 964139 + wontfix
Merging with the duplicate.
I don't intend to restore the deprecated SysV init script. So marking as
wontfix.
Am 02.02.21 um 16:25 schrieb Arturo Borrero Gonzalez:
Could you please check if introducing back docbook-xsl as build-dep
fixes the issue?
This is very likely the issue. Without the xsl stylesheets, xsltsproc
will contact the net, and I assume the buildds (at least some of them)
have network
Am 02.02.21 um 16:25 schrieb Arturo Borrero Gonzalez:
I suspect this might be related to this recent change:
https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/commit/4eb323698ee7d8e50132fb271c0f3aa92c727285
Could you please check if introducing back docbook-xsl as build-dep
fixes
Source: nftables
Version: 0.9.8-2
Severity: serious
Hi,
trying to rebuild nftables on sid, I ran into a failure:
make[3]: Entering directory '/build/nftables-0.9.8/doc'
a2x -L --doctype manpage --format manpage -D . nft.txt
a2x -L --doctype manpage --format manpage -D . libnftables-json.adoc
Am 11.01.21 um 22:04 schrieb Eduard Bloch:
Not sure which kind of backup you expect.
Well, you filed a serious bug report against systemd, so I expect at
least some kind of justification for that.
OpenPGP_signature
Description: OpenPGP digital signature
Am 10.01.21 um 20:02 schrieb Jamie Zawinski:
Why would a xscreensaver instance running for user A have any influence on a
xscreensaver instance running for user B? That seems absolutely weird to me and
something I don't understand.
Yeah, that sounds impossible, assuming that the X server has
Am 10.01.21 um 18:48 schrieb Tormod Volden:
OK, so I guess removing the global user enablement will avoid having
xscreensaver running in lightdm. However, I still wonder if this
lingering service that was observed will also be the case if a user
logs out and another (or same) logs in within 15
Hi Tormod
Am 10.01.21 um 15:12 schrieb Tormod Volden:
I should add that although we added the
debian/xscreensaver.user.service file in 5.44+dfsg1-2, we are using
"dh_installsystemduser --no-enable" since 5.45+dfsg1-1, so it won't be
enabled for the lightdm user in new installs or upgrades
Am 10.01.21 um 13:19 schrieb Tormod Volden:
On Sun, Jan 10, 2021 at 12:44 PM Michael Biebl wrote:
Negating @system might work.
Something like ConditionUser=!@system, but untested.
Thanks! I was just about to suggest this myself after searching around for this.
(https://www.freedesktop.org
Am 10.01.21 um 12:20 schrieb Tormod Volden:
On Fri, Jan 8, 2021 at 10:00 PM Jamie Zawinski wrote:
In xscreensaver (or maybe lightdm).
Why is xscreensaver started in the lightdm session anyway?
Is xscreensaver really usable as a per user service or should it be per session?
Why is the lightdm
Am 08.01.21 um 14:12 schrieb Eduard Bloch:
Hallo,
I don't fully agree. If you don't see a problem here, WHERE do you see
it?
In xscreensaver (or maybe lightdm).
Why is xscreensaver started in the lightdm session anyway?
Is xscreensaver really usable as a per user service or should it be per
Control: reassign -1 xscreensaver
I don't see a systemd problem here, so re-assigning to xscreensaver.
Am 08.01.21 um 13:04 schrieb Eduard Bloch:
Package: systemd
Version: 247.2-4
Severity: serious
Hi,
I am reporting this with high severity because it might affect system
security.
For
Control: severity -1 normal
Am 01.01.21 um 01:19 schrieb Vincent Lefevre:
On 2020-12-31 20:22:56 +0100, Michael Biebl wrote:
Am 31.12.20 um 18:37 schrieb Vincent Lefevre:
During the upgrade, network-manager disconnected, so that I completely
lost the network connection. Fortunately, I
Control: tags -1 + moreinfo
Am 31.12.20 um 18:37 schrieb Vincent Lefevre:
Package: network-manager
Version: 1.28.0-1+b1
Severity: serious
During the upgrade, network-manager disconnected, so that I completely
lost the network connection. Fortunately, I was in front of my machine,
but this
Source: apt-listchanges
Severity: serious
I just tried to file a bug report against apt-listchanges and got this
reply
Reporting-MTA: dns;VI1EUR04HT091.mail.protection.outlook.com
Received-From-MTA: dns;DBAPR01MB7126.eurprd01.prod.exchangelabs.com
Arrival-Date: Mon, 14 Dec 2020 23:33:24 +
Package: src:puppet
Version: 5.5.22-1
Severity: serious
X-Debbugs-Cc: debian...@lists.debian.org
Hi,
it appears the autopkgtest of puppet is not really stable on arm64.
https://ci.debian.net/packages/p/puppet/testing/arm64/
I scheduled it a couple of times, as its results were blocking systemd
Control: tag -1 pending
Hello,
Bug #976922 in systemd-bootchart reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Am 12.12.20 um 10:12 schrieb Lucas Nussbaum:
On 11/12/20 at 15:08 +0100, Michael Biebl wrote:
https://github.com/systemd/systemd-bootchart/pull/37
specifically
https://github.com/systemd/systemd-bootchart/pull/37/commits/65320230f5fcb02e81df5131a4dc03092558c263
Could you give this PR a try
Hi Herbert
On Mon, 7 Dec 2020 14:55:06 +1100 Herbert Xu
wrote:
> Sorry, my bad. wait(1) with no arguments ignores the error status
> of the child and always return zero. wait(1) specifically on a
> child obviously returns the error status of that child. Since the
> child was killed, we need
Am 11.12.20 um 09:09 schrieb Lucas Nussbaum:
On 10/12/20 at 22:12 +0100, Michael Biebl wrote:
Am 10.12.20 um 22:10 schrieb John Paul Adrian Glaubitz:
Hi Michael!
On 12/10/20 8:42 PM, Michael Biebl wrote:
Testsuite
Am 11.12.20 um 09:26 schrieb Lucas Nussbaum:
I tried to reproduce this on another system (ARM64, 256 visible cores
because 2 x ThunderX2, 32 cores/cpu, 4 threads/core) and it also
segfaults.
I tried to reproduce on yet another system (x86_64, 128 visible cores
because 4x Intel Xeon Gold 6130,
Am 11.12.20 um 09:09 schrieb Lucas Nussbaum:
0x00014d04 in svg_ps_bars (interval=,
graph_start=2775.3698308829998, ps_first=0x1000505d0, n_cpus=1,
n_samples=10, head=0x100050770, of=0x1000503f0) at src/svg.c:1187
looking at n_cpus=1,
what's the output of /proc/schedstat?
Am 10.12.20 um 22:12 schrieb Michael Biebl:
Am 10.12.20 um 22:10 schrieb John Paul Adrian Glaubitz:
Hi Michael!
On 12/10/20 8:42 PM, Michael Biebl wrote:
Testsuite summary for systemd-bootchart 233
Am 10.12.20 um 22:10 schrieb John Paul Adrian Glaubitz:
Hi Michael!
On 12/10/20 8:42 PM, Michael Biebl wrote:
Testsuite summary for systemd-bootchart 233
Am 10.12.20 um 20:18 schrieb John Paul Adrian Glaubitz:
Hi Michael!
On 12/10/20 7:53 PM, Michael Biebl wrote:
Unfortunately, I can't reproduce the issue on a porter box (plummer).
So I'm not sure if I can do something about it.
It might be an issue with parallel jobs as Lucas built
Control: tags -1 + unreproducible
Hello Lucas
Am 09.12.20 um 09:42 schrieb Lucas Nussbaum:
Source: systemd-bootchart
Version: 233-2
Severity: serious
Justification: FTBFS on ppc64el
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
Hi,
During a rebuild of all
Control: severity -1 important
Control: tags -1 unreproducible
I tested other Wayland clients (on real hardware and in a VM), most
notably GNOME Shell, and could not reproduce the problem. We didn't have
other users confirming this issue either. I'm thus tentatively
downgrading the severity
101 - 200 of 2789 matches
Mail list logo
