Many thanks @Mark for the quick and effective reaction! The new version works
as desired.
Dear Mark,
> Can you clarify exactly what you did here? Was that before or after the
> dist-upgrade?
I am ways on testing and never changes that. On Sat 10th of June ~20:00 (the
day testing switched to trixie) I simply replaced the directory
/var/cache/apt-cacher (with all content like cached
Package: apt-cacher
Version: 1.7.29
As far as I can see, calling /usr/share/apt-cacher/apt-cacher-cleanup.pl (e.g.
after apt-get dist-upgrade which stores some packages to the cache) under
debian testing/trixie seems to remove ALL package files in the cache
Dear all,
> doing an apt upgrade, the grub-efi-amd64-signed package remained at 2.06-5
I can confirm that behavior. A manual call of grub-install/update-grab is
necessary after the package upgrade to 2.06-7. Otherwise the grub version which
will be used on booting stays 2.06-5 . Maybe the grub
Package: grub-efi-amd64
Version: 2.06-5
Severity: normal
X-Debbugs-Cc: chris...@gmx.de
Dear Maintainer,
I am running debian testing/bookworm. After the updates from grub 2.06-4 to
grub 2.06-5 (about November 18th) in the grub boot menu the box border
characters are not shown as they should.
Hi Dylan,
indeed, version 0.3.60-2 solves the virtualization sound problem. Thanks for
building the package!
All the best,
Chris
Hi Dylan,
thanks for maintaining pipewire and your hint!
Now I did the upgrade on my bare metal installation and there the problem does
not show up (in contrast to the virtualized one). So it is most likely the
upstream issue you have mentioned. However, it is unclear/difficult for me how
to
I am using a kvm virtualized installation of bookworm (I did not try it yet on
my bare metal installation). Below see some informations which may help. Within
syslog I find no spefic entries via 'grep pipewire' which could give me a hint,
but I can provide conrete log snippets if you tell what
Package: pipewire
Version: 0.3.60-1
Severity: important
X-Debbugs-Cc: chris...@gmx.de
Dear Maintainer,
using pipewire 0.59-1 under debian testing (with pusleaudio package uninstalled
if this should matter) makes no problem. I have copied
/usr/share/doc/pipewire/examples/alsa.conf.d to /etc/alsa
This bug was silently fixed in sddm-theme-breeze 4:5.26.0-2 .
Control: reassign sddm-theme-breeze 4:5.25.5-1
I think I have identified the bug now. The breeze package (was upgraded, see
above) changed the wallpaper file types from jpg to png. Now the default config
of sddm/sddm-theme-breeze does not find it, as it wants a jpg in the file
theme.conf .
Please fix theme.conf in package sddm-theme-breeze
Here some entries from an sddm start in /var/log/syslog, filtered by grep sddm:
Oct 18 08:46:21 betty sddm[925]: Initializing...
Oct 18 08:46:21 betty sddm[925]: Starting...
Oct 18 08:46:21 betty sddm[925]: Logind interface found
Oct 18 08:46:21 betty sddm[925]: Adding new display on vt 7 ...
Oct
Package: sddm
Version: 0.19.0-4
Severity: normal
X-Debbugs-Cc: chris...@gmx.de
Dear Maintainer,
immediately after upgrading my bookworm/testing installation on Monday October
17th morning the sddm login screen shows a white background instead the breeze
wallpaper. Further no controls different
Package: thunderbird
Version: 91.4.0-1
Severity: normal
Today the new thunderbird version migrated to testing und I did a upgrade.
However, the translation package (at least for german) does not work although
installed. Thunderbird uses englisch language after starting it (menus items
and so
Package: thunderbird
Version: 91.4.0-1
Severity: normal
Today the new thunderbird version migrated to testing und I did a upgrade.
However, the translation package (at least for german) does not work although
installed. Thunderbird uses englisch language after starting it (menus items
and so
Mesa 21.2.5-1, today release in debian testing shows the same problem.
Hi Norbert,
> But I guess you had, or some cosmic radiation induced bit switch did it
> for you on your hard disk ;-) The default for all installations is being
> on.
yeah, then lets say "maybe" or "probably" I did that, nevertheless, at least it
was a couple of years ago and I cannot remeber
Hi Norbert,
thanks to your repsonse!
> Can you try/check the following:
> * In the Plasma Settings app, go to
> Display and Monitor > Compositor
> and check whether
> Enable compositor on startup
> is selected (on).
Indeed, turning that switch to on and restarting helps.
Today all packages of plasma 5.23 migrated to testing, and it works fine in my
(libvirt) vm. However, on bare metal mesa makes problems (see my bug report
#998386), so in fact there plasma 5.23 stays unusable.
Unfortunately, mesa 21.2.4-1 shows the same problem under plasma 5.23 in
testing. The latter has finally migrated to testing with all packages
yesterday. The combination works fine within my libvirt vm, as I think, it does
not use hw accelleration there. However, on bare metal (see above) it
Package: mesa
Version: 20.3.5-1
Severity: critical
Justification: breaks graphical system like KDE
After updateing mesa from 20.3.5 to 21.2.4 in bookworm (migrated on October
21th to testing) my graphical KDE plasma 5.21 under x11 renders unusable. Note
plasma 5.23 is currently unusable in
KDE/Plasma (package dependencies) are currently completely broken under
testing. Is there currently a chance to (somehow simply) block the partial
transition of plasma 5.23 to testing (so that not related package updates are
easy)? Selectively upgrading single packages with dependencies one
Dear Maintainer, dear Jörg,
the bug is closed since a couple of weeks. However, there was no patch released
at least for debian testing. The (lib)sane version is still 1.0.27 and the
bug(s) still exists.
$ dpkg -l | grep sane
ii libcommon-sense-perl 3.75-1+b1
I can perfectly confirm the issue with my two bullseye instances, one on bare
metal and the other virtualized with kvm.
Chris
On my Buster machine I can completely reproduce that. However, things are more
complicated. For any somehow newer Epson scanner one needs to install the
vendor drivers from http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX
, e.g., like it i the case for my Perfection V37.
While
Dear Steve,
> It's odd that you have files in /boot/efi but on a separate filesystem
> (the rootfs?), not within the ESP.
yep, on the rootfs on /dev/sda2. Must have been done by the deb-installer. Now
I removed the files from the root partition as ESP is mounted over them. As
expected, no
Dear Steve,
I try to deliver missing informations.
> Can you get in to the system? I'm guessing (hoping!) just by disabling
> SB for now.
Fortunately, that is possible.
> Then please do a listing of the EFi System Partition and
> show us what boot variables are set:
> # ls -lR /boot/efi
Dear Steve,
I know that this bug is not closed yet, but maybe the following is of interest
for you.
I noticed your report of bug #930531 which was recently fixed in grub2 version
2.02+dfsg1-19. Thus, I decided to give secure boot another try on my Intel
DH77KC board. Meanwhile grub2
Dear Mathieu,
sorry for the late reply.
> Are you able to reproduce this bug on latest buster (2:4.9.4+dfsg-2 or -3)?
Yes, I still can reproduce it on latest buster with samba 2:4.9.5+dfsg-4 .
> If yes, can you provide your smb.conf?
However, now the bug seems to only show up if I set
Dear Mark,
unfortunately the problem still exists, although you have closed the bug. Is
there any time esitmation, as xemacs is my favorite editor?
Thanks again,
Chris
Meanwhile my Debian Testing systems have (per default) upgraded to libbsd
0.9.1 (and kernel 4.16.0-2). Unfortunaetly, this does not fix the problem
(long ssdm start) under virtualization by kvm, although according to #898088
libvirt 0.9.0-1 should have alredy fixed this.
On productive bare metal
32 matches
Mail list logo
