I can second that bug. For me, at least nautilus, gnome-console,
org.gnome.Shell.Screencast, gnome-remote-desktop-daemon, localsearch-3,
file-roller and org.gnome.Settings.desktop are spamming these messages. Though
that may be due to the fact that I force all GTK apps supporting that to use
t
It seems it's an upstream bug tracked here:
https://bugzilla.kernel.org/show_bug.cgi?id=217415
This must have been because of a local installation of self compiled Mesa that
I thought I couldn't get to be used by programs. Removing it solved the issue.
Case closed, sorry about that.
Addendum: this is the output of dmesg related to mt7921e that shows up
when this happens:
[Th May 9 18:36:50 2024] [01;31m[Kmt7921e[m[K :01:00.0:
firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7922_1.bin
[Th May 9 18:36:50 2024] [01;31m[Kmt7921e[m[K :01:00.0: ASIC
re
Package: src:linux
Version: 6.7.12-1
Severity: normal
Dear Maintainer,
Since upgrading to Linux 6.7.12 from 6.6.15, connecting to WiFi after
waking up
from hibernation fails. The journal lists these kernel errors, I can't
see any
other relevant errors:
Mai 07 16:53:03 kernel: mt7921e :01:00.
Package: installation-reports
Severity: important
Boot method: USB stick
Image version:
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-gnome.iso
Date: 19.04.2024
Machine: Framework 16
Processor: AMD Ryzen 7 7840HS w/ Radeon 780M Graphics
Memory: 2 x
Package: initramfs-tools
Version: 0.142
Severity: wishlist
Dear Maintainer,
I'm not sure if this is a bug that should be fixed or a feature request for
better error handling. I noticed by accident, that when /etc/crypttab
ends in
the line of the last entry and not a new line character,
update-ini
Package: postfix-mysql
Version: 3.7.9-0+deb12u1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
With the update in stable-updates, this package seems to be no longer working.
removing it and going back to 3.7.6 solves the issue. This is what it writes to
journal:
Jan 1
PS: this only fixed the problem with mailman3-web not working. The problem that
mailman3-full and mailman3-web can't be configured (which means apt will retry
any time I update stuff) still exists. If anybody got recommendations for this
it would be appreciated too.
smime.p7s
Description: S/M
With this I was finally able to fix my problem too. Both times the manage.py
script went through, but I had to make some aditional changes:
as I've replaced the mailman3-web systemd unit with an ini for the uwsgi
emperor, which runs mailman3-web with list:list, I've owned the mailman-web.py
in
Nevermind, executing manage.py as root did solve the error. The question only
is if that means some permissions are off. Any way to check that?
But in the end, doing as you explained didn't change anything. Basically the
same errors are still present:
WARNING: apt does not have a stable CLI int
600,
'save_limit': 100,
'orm': 'default',
'poll': 5,
}``` * make django migration ```sudo -u www-data
/usr/share/mailman3-web/manage.py makemigrations
sudo -u www-data /usr/share/mailman3-web/manage.py migrate``` to enable
DEFAULT_AUTO_FI
It would be very much appreciated if a solution could be found, or at least
help provided to figure out the problem. Right now, both mailman3-full and
mailman3-web can't be configured, so every time apt runs, it also tries to fix
them. While mailman3 itself is working, mailman3-web is completel
Package: mailman3-web
Version: 0+20200530-2.1
Severity: important
Dear Maintainer,
I just made the upgrade from bullseye to bookworm. mailman3 was up and running
before, but the upgrade failed at the point mailman3-full and mailman3-web
where supposed to be configured by dpkg. dpkg --configure
I now found the problem. The mails from cron had been sorted into spam because
they had "root (Cron Daemon)" as sender and rspamd didn't like the sender
domain to be forged to r...@domain.de. Anyway, the error message says
"/usr/bin/test: /usr/bin/test: can't execute file". I guess it didn't li
that do not
seem to arrive either. Strange. Can you change the line in cron so it outputs
stdout and stderr to a file instead? // Ola On Fri, 27 Jan 2023 at 07:20,
Richard Rosner wrote:They are supposed to be
sent to the mail address defined in the cron-apt config. It didn't arrive
ther
d get the cron output from bash -x in an email so I could
>see more what happens. It should be sent to the root user. Or have
>you redirected those emails so you do not get them?
>
>Sorry for not being clear on that.
>
>Best regards
>
>// Ola
>
>On Thu, 26 Jan 2023
;
+ logger -p user.notice -t cron-apt -f /tmp/cron-apt.X5DFeL/temp
+ '[' upgrade = always ']'
+ '[' verbose = verbose ']'
+ createloginfo 3-download
+ createdivinfo /var/log/cron-apt/log /tmp/cron-apt.X5DFeL/temp
/etc/cron-apt/logmsg.d/3-download /tmp/cron-ap
No, and it did send a mail.
--
Richard Rosner
Studierendenschaft der RWTH Aachen University
Fachschaft Materialwissenschaft und Werkstofftechnik
Intzestraße 1
52072 Aachen
Tel.: +49 241 80-95781
rros...@fsmuw.rwth-aachen.de
www.fsmuw.rwth-aachen.de
Am Dienstag, 24. Januar 2023 16:44 CET
#x27; upgrade = always ']'
+ '[' verbose = verbose ']'
+ createloginfo 3-download
+ createdivinfo /var/log/cron-apt/log /tmp/cron-apt.X5DFeL/temp
/etc/cron-apt/logmsg.d/3-download /tmp/cron-apt.X5DFeL/runlog
/tmp/cron-apt.X5DFeL/actionlog ''
+ FILE=/var/log/cr
eep.
Do you have some special kernel? The kernel should not give that problem.
cron-apt do not do anything magic. It just executes sleep
It could also be that it is not the sleep command itself. It could be the
random number generation done a few lines earlier in that script. // Ola On
Wed,
Package: cron-apt
Version: 0.13.0.1
Severity: important
Dear Maintainer,
when running cron-apt as shipped it works normal, running at 4 am and sending
an email when anything can be updated. But when adding the recommended RUNSLEEP
variable to the config, the only thing that happens is throwing
Package: cron-apt
Version: 0.13.0.1
Severity: important
Dear Maintainer,
when running cron-apt as shipped it works normal, running at 4 am and sending
an email when anything can be updated. But when adding the recommended RUNSLEEP
variable to the config, the only thing that happens is throwing a
Package: cron-apt
Version: 0.13.0.1
Severity: important
X-Debbugs-Cc: sub...@bugs.debian.org
Dear Maintainer,
when running cron-apt as shipped it works normal, running at 4 am and sending
an email when anything can be updated. But when adding the recommended RUNSLEEP
variable to the config, the
The problem has now been solved. The solution was to use http instead of uwsgi
as protocol. Also, communication is running through http instead of a socket. I
can't tell if http protocol would also work through a socket, but uwsgi wasn't
working through either. Maybe the uwsgi.ini should contai
Package: mailman3-web
Version: 0+20180916-8
Severity: important
Dear Maintainer,
I recently installed mailman3-full to make the switch from mailman 2.x before
it's being discontinued. While the installation was quite a hassle since both
mailman3 and mailman3-web had severe issues talking to mys
26 matches
Mail list logo
