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
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
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
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,
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
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:
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
igration ```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_FIELD config * restart service ```sudo service mailman3 restart
sudo service mailman3-web restart
``` to enable Q_CLUSTER conf
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
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
ot
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
there. Or did the c
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 Ja
ATELY="yes"
fi
And then run manually.
bash -x your-cron-apt-copyIt would help to understand what happens. // Ola On
Mon, 23 Jan 2023 at 23:30, Richard Rosner
wrote:Hi,
sleep 456 and sleep 1200 work without any problems. Also, I don't have any
special kernel. Currently, Output of unam
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
our-cron-apt-copyIt would help to understand what happens. // Ola On
Mon, 23 Jan 2023 at 23:30, Richard Rosner
wrote:Hi,
sleep 456 and sleep 1200 work without any problems. Also, I don't have any
special kernel. Currently, Output of uname -a is "Linux ts 6.1.0-1-amd64 #1 SMP
PREEMPT_DYNAMIC Deb
me 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, 18 Jan 2023 at 15:1
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
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
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
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
23 matches
Mail list logo