Bug#998629: pipewire: No sound devices in Pulseaudio after recent pipewire update in bookworm

Package: pipewire Version: 0.3.39-3 Followup-For: Bug #998629 X-Debbugs-Cc: celeo...@gmail.com Same problem for me. After upgrading from pipewire 0.3.38-2 to 0.3.39-3, audio is not working anymore. Thomas Hager wrote: > Anyway, after downgrading pipewire et al to 0.3.38-2 and rebooting, > sound

Bug#978135: cockpit: should recommend sudo

Package: cockpit Version: 233-1 Severity: normal When you login with a normal user, a message on the top of page says that "Web console is running in limited access mode" and the "Turn on administrative access" button is shown. But if you press the button and "sudo" is not installed, this laconic

Bug#977464: virtinst should depend or recommend libosinfo-bin

Package: virtinst Version: 1:3.2.0-3 Severity: normal Virt-install's man page and virt-install --help both say to use the following command to get the list of valid OS variant names: osinfo-query os But this command is provided by libosinfo-bin which is not a dependency of virtinst and so was

Bug#968400: cockpit-ws: Warning on upgrades

Package: cockpit-ws Version: 225-1 Severity: normal Hello. For several cockpit releases, on every package upgrade there are two repeated messages: -- Setting up cockpit-ws (225-1) ... Warning: The home dir /nonexisting you specified can't be accessed: No such file or directory The system

Bug#966811: network-manager: unknown keys in /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf

Package: network-manager Version: 1.26.0-1 Severity: normal Running "NetworkManager --print-config" the following messages are printed: --- # WARNING: unknown key 'wifi.cloned-mac-address' in section [device-mac-addr-change-wifi] of file

Bug#954266: qemu-system-x86: graphical-mode monitor doesn't work

Me too confirm this bug and also what Bernhard has discovered (thank you!): monitor works again if you downgrade libvte-2.91-0 and libvte-2.91-common to version 0.58.3-1. Could be difficult, since that library can have many reverse dependencies. Cesare.

Bug#951436: mate-panel: Clock crashes when adding a location

Package: mate-panel Version: 1.24.0-1 Severity: normal The following steps almost always makes clock applet crash: - Right click on panel's clock - Preferences -> Locations - Add a location and click OK The crash happens as soon I click OK. But the "almost always" in the first sentence is

Bug#950330: libvncclient1: Serious artifacts after upgrading to 0.9.12

On 01/02/20 17:21, Mike Gabriel wrote: can you please test your issue using http://packages.sunweavers.net/debian/pool/main/libv/libvncserver/libvncclient1_0.9.12+dfsg-8~test1_amd64.deb Hello Mike, your package seems to fix the issue. I've tried two connection: (1) TightVNC 2.8.5 (Win7 64

Bug#950330: libvncclient1: Serious artifacts after upgrading to 0.9.12

On 31/01/20 23:00, Mike Gabriel wrote: @Cesare: would you be ok, if I provided you with a binary build of libvncserver outside of the debian.org namespace (via packages.sunweavers.net) for testing? If so, please let me know and I'll provide you with test packages. On the other hand, if you

Bug#950225: libreoffice-writer: Immediate crash lunching mail merge wizard

Package: libreoffice-writer Version: 1:6.4.0-1 Severity: normal The following steps always make LibreOffice crash: - Start Writer with a new empty document - Tools -> Mail Merge Wizard... As soon as I click to start the wizard, LibreOffice closes and the Document Recovery window open up saying:

Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade

Package: gvfs-fuse Version: 1.42.1-1 Followup-For: Bug #942126 Ok, I confirm that replacing fuse with fuse3, as reported by Bert, make gvfs-fuse works as expected, with /run/user/ID/gvfs/ populated again. So please, consider to tighten gvfs-fuse dependencies on fuse3. And, just to clarify, my

Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade

Package: gvfs-fuse Followup-For: Bug #942126 Thank you all for the information provided. During these days I've made several tests, but unfortunally I still have login problems that I cannot identify and upgrading to the latest gvfs and fuse3 renders things worse, I don't know exactly why:

Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade

Package: gvfs-fuse Followup-For: Bug #942126 Hello Simon, sorry if my bug report was a bit scarce of information. I was a bit in hurry when I wrote it. Now I try to remedy... On Thu, 10 Oct 2019 19:44:44 +0100 Simon McVittie wrote: > On Thu, 10 Oct 2019 at 19:24:48 +0200, Cesare Leonardi wr

Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade

Package: gvfs-fuse Version: 1.42.1-1 Severity: normal Every time MATE desktop starts, it mounts several SMB share with a command like that: gio mount "smb://host/folder" After upgrading gvfs from 1.42.0+really1.38.1-1 to 1.42.1-1 gvfs those commands still works ok, except that /run/user/ID/gvfs/

Bug#928736: initramfs-tools: With plymouth print misleading resuming from hibernation

Package: initramfs-tools Version: 0.133 Severity: normal When plymouth is installed, every time I power on my notebook the following message is printed on the screen: Resuming from hibernation But I'm not resuming from hibernation, I'm doing a regular boot from power off. Is it possible to show

Bug#924553: linux-image-4.19.0-4-amd64: PKCS#7 signature not signed with a trusted key

Package: src:linux Version: 4.19.28-1 Severity: normal With this kernel version (but not with the last 4.19.0-3) journalctl shows many of these messages: PKCS#7 signature not signed with a trusted key A lot of such messages can also be seen on the early booting phase. Also I noticed that,

Bug#913119: Bug#913138: Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

On 28/02/19 16:44, Thorsten Glaser wrote: please do consider uploading 4.19.24 to buster/sid with some haste. We have headless virtualisation hosts being unreachable/frozen now, and while these are “only” development systems, this is untenable. Like you I'm looking forward for that kernel.

Bug#913119: Bug#913138: Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

On 13/02/19 18:21, Dragan Milenkovic wrote: This patch is already on its way to stable branches. I have tested it and confirmed that it resolves the problem. Hello Dragan, do you know if the patch was eventually included upstream and possibly in which version? Cesare.

Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

On Tue, 5 Feb 2019 01:36:08 +0100 Dragan Milenkovic wrote: I have tracked the issue to this change: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/block/blk-flush.c?id=344e9ffcbd1898e1dc04085564a6e05c30ea8199 Thank you very much for your deep analisys and thank you

Bug#917164: "lvm2-activation-generator: lvmconfig failed" message at boot time

On 24/12/18 11:13, Jean-Michel Pouré wrote: It is impossible to boot using latest kernel. It was possible to boot using Grub menu either selecting an older kernel (4.18.0-3) or using « Recovery mode » and kernel 4.19.0-1. I tried to modify /etc/lvm/lvm.conf as explained but it did not work

Bug#917166: Errors on and after upgrade to 2.03.01-2, swap on lvm not mounted

On Sun, 23 Dec 2018 15:58:50 +0100 Piotr Jurkiewicz wrote: On two machines running sid I observed errors during the upgrade to 2.03.01-2. One of these machines became practically unusable immediately after the update (disk IO operations became so slow that even closing aptitude took 2 minutes

Bug#917164: "lvm2-activation-generator: lvmconfig failed" message at boot time

On Sun, 23 Dec 2018 15:36:25 +0100 Xavier Guerrin wrote: I investigated why and what follows are my strace-based conclusions. As you probably know already, lvm2-activation-generator runs: /sbin/lvmconfig global/event_activation global/use_lvmpolld After the latest lvm2 upgrade, it turns out

Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

Hi Hans! On Sat, 24 Nov 2018 01:08:56 +0100 Hans van Kranenburg wrote: You didn't share any part of your logging. Can you share a part of dmesg logging that shows Oops in it? Here it is, attached to this message. Previously I didn't attached it because to me it looks substantially the same

Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

Bug still present with the new 4.18.0-3-amd64 (4.18.20-1). This morning I've tryed to boot this new kernel version, removing the workaround given by the following kernel parameters: scsi_mod.use_blk_mq=0 dm_mod.use_blk_mq=0 The system showed disk hangs in less than 5 hours, and, as in

Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

I've added some details in #913138, which I believe is the same bug as this one. There a commenter suggested two kernel parameters that, so far, have resolved the problem for me. Cesare.

Bug#913138: linux: I/O on md RAID 6 hangs completely

On Thu, 08 Nov 2018 23:28:16 +0100 =?UTF-8?Q?Stanis=C5=82aw?= wrote: I suffer the same problem while running RAID1 with kernel 4.18.10-2. Me too. For me this happens since the switch from 4.16 to 4.17.x, with two different PCs, both with LVM based RAID1. I've already opened bug #913119,

Bug#912943: fireqos fails to install: /usr/lib/firehol/services.fireqos missing

Package: fireqos Version: 3.1.6+ds-3 Severity: normal Same as #912758, but with another file. The reason is reported in the last sentence of that bug report: > I believe the problem is the for loop at line 43 in /usr/sbin/fireqos: it > needs to source some files in /usr/lib/firehol/ but

Bug#912758: fireqos fails to install: /usr/lib/firehol/service.common missing

Package: fireqos Version: 3.1.6+ds-1 Severity: normal The upgrade from fireqos:amd64 3.1.5+ds1-2 to 3.1.6+ds-1 failed during the "setting up" phase of dpkg: - # dpkg --configure -a Setting up fireqos (3.1.6+ds-1) ... Job for fireqos.service failed because the control

Bug#911777: iptables: ferm broken by changed path of iptables-restore

Dear iptables maintainers, reading the initial bug report you can think I haven't read README.Debian before filing this bug, but I did. It's clear that now iptables is handled by update-alternatives, so that the user can choose between the new nftables compatible programs (the dafault) or the

Bug#911777: iptables: ferm broken by changed path of iptables-restore

Package: iptables Version: 1.8.1-1 Severity: normal After the upgrade from 1.6.2-1.1 to 1.8.1-1, ferm firewall cannot start anymore, because it doesn't find /sbin/iptables-restore. Now iptables programs are all under /usr/sbin (with the exception of iptables-xml under /usr/bin), while in 1.6.2

Bug#911591: Info received (network-manager: Segfault at service startup on i386)

Looks similar to #911621. And he is i386 too.

Bug#911591: network-manager: Segfault at service startup on i386

Mmh, log lines are wrapped... I attach them as files, to make them more readable. ott 22 10:09:51 muletto systemd[1]: Starting Network Manager... ott 22 10:09:51 muletto NetworkManager[907]: [1540195791.5867] NetworkManager (version 1.14.2) is starting... (after a restart) ott 22 10:09:51

Bug#911591: network-manager: Segfault at service startup on i386

Package: network-manager Version: 1.14.2-2 Severity: normal This bug report was saved with reportbug but sent with the gmail web interface: I hope it looks good. After upgrading from 1.12.4-1 to 1.14.2-2 the service segfaults and doesn't start anymore. Rebooting doesn't help. But i've

Bug#903165: On boot squid.service starts but doesn't work

I've CCed NetworkManager maintainers: since here /etc/resolv.conf is a symlink created by NetworkManager, perhaps they can provide some advice. Regarding the opening message, I've workarounded the problem overriding the squid service like this: # systemctl edit squid.service ---

Bug#903303: Acknowledgement (fireqos: Fireqos fails to start on boot)

First, to the bug report context I add that my network is managed by NetworkManager and I use a wifi network (so slower to come up than a cable network). Since on one occasion the service started ok on boot, with my basic systemd knowledge I analyzed the fireqos.service and I think the

Bug#903165: squid: When squid.service starts no /etc/resolv.conf is present yet

control: retitle -1 On boot squid.service starts but doesn't work Here at work I have a similar setup in respect to the opening message: Debian Sid, NetworkManager, Squid 4.1. But very different Squid configuration. While the final effect is the same (squid does not start on boot and I have

Bug#903303: Acknowledgement (fireqos: Fireqos fails to start on boot)

Since on my system I have kept some old kernel installed, I've just tried to boot with the following kernels but the the service still doesn't starts: linux-image-4.7.0-1-amd64 (4.7.8-1) linux-image-4.15.0-3-amd64 (4.15.17-1) Cesare.

Bug#903165: squid: When squid.service starts no /etc/resolv.conf is present yet

On 08/07/2018 14:05, Amos Jeffries wrote: What init system are you using; sysV? systemd? something else? Systemd (which I still know at a basic level). If it is systemd, please check that your NetworkManager is part of the nss-lookup.target groups. Squid depends on that target providing

Bug#903303: fireqos: Fireqos fails to start on boot

Package: fireqos Version: 3.1.5+ds1-2 Severity: normal Fireqos.service fails to start on boot, but if I manually starts it afterwards, it starts correctly. The attached fireqos.conf is operational since about 2 year. I believe that I see this problem after the .service was introduced because

Bug#903165: squid: When squid.service starts no /etc/resolv.conf is present yet

Package: squid Version: 4.1-1 Severity: normal For testing purposes I use squid proxy on my laptop. Since upgrading to 4.1, when the system boots, squid service is not operating properly: it always fails to resolve DNS names. And I have to restart the service in order to make it work. Here is the

Bug#897976: arptables bash script installed in /

Package: arptables Version: 0.0.4-1 Severity: normal Try to install this package and then do: ls -l / You'll notice an "arptables" executable bash script, that was clearly meant to be an init script. This can be seen also inspecting the package with: dpkg -L arptables -- System Information:

Bug#879193: unable to exit mouse grab, segfaults

Package: qemu Version: 1:2.11+dfsg-1 Followup-For: Bug #879193 Problems reported in #879532, #879534, #879536, #879193, are still present in 2.11+dfsg-1. Downgrading only qemu-system-x86 to 1:2.10.0+dfsg-1 is still possible and is still the only way i know to workaround all these problems.

Bug#879534: qemu: Cannot move in the monitor's backlog (SDL2?)

Package: qemu Version: 1:2.11+dfsg-1 Followup-For: Bug #879534 Problems reported in #879532, #879534, #879536, #879193, are still present in 2.11+dfsg-1. Downgrading only qemu-system-x86 to 1:2.10.0+dfsg-1 is still possible and is still the only way i know to workaround all these problems.

Bug#879536: qemu: Antialias, graphics artifacts and screen corruptions (SDL2?)

Package: qemu Version: 1:2.11+dfsg-1 Followup-For: Bug #879536 Problems reported in #879532, #879534, #879536, #879193, are still present in 2.11+dfsg-1. Downgrading only qemu-system-x86 to 1:2.10.0+dfsg-1 is still possible and is still the only way i know to workaround all these problems.

Bug#879532: qemu: Qemu multi-windows problems (SDL2?)

Package: qemu Version: 1:2.11+dfsg-1 Followup-For: Bug #879532 Problems reported in #879532, #879534, #879536, #879193, are still present in 2.11+dfsg-1. Downgrading only qemu-system-x86 to 1:2.10.0+dfsg-1 is still possible and is still the only way i know to workaround all these problems.

Bug#879193: unable to exit mouse grab, segfaults

Package: qemu Version: 1:2.10.0+dfsg-2 Followup-For: Bug #879193 I've encountered similar mouse problems with dfsg-2 that were not present with dfsg-1, but i'm currently not able to reproduce it in a deterministic way. Here is my qemu's setup, using Windows 10 as guest OS. qemu-system-x86_64 \

Bug#879534: qemu: Cannot move in the monitor's backlog (SDL2?)

Package: qemu Version: 1:2.10.0+dfsg-2 Severity: normal I've encountered several issue with this version of qemu and I highly suspect they stem from the SDL2 switch. I will file different bugreports for the problems i've encountered, guessing it's better for the qemu's maintainer. I'm currently

Bug#879532: qemu: Qemu multi-windows problems (SDL2?)

Package: qemu Version: 1:2.10.0+dfsg-2 Severity: normal I've encountered several issue with this version of qemu and I highly suspect they stem from the SDL2 switch. I will file different bugreports for the problems i've encountered, guessing it's better for the qemu's maintainer. I'm currently

Bug#852605: util-linux: fdisk l command does not without less installed

Package: util-linux Version: 2.29.2-1 Followup-For: Bug #852605 Hello! Indeed the problem is worse during debian-installer, where less is not available. And if you need to manually partition a GPT disk you will encounter this problem in a rather inconvenient moment. When happened to me i didn't

Bug#816781: [Aptitude-devel] Bug#816781: aptitude: Can not cancel pending upgrade actions

On 30/05/2017 22:42, Axel Beckert wrote: So maybe we should be a little bit more verbose with the short description in the menu or maybe even split "Cancel pending actions" into two separate menu entries: * Cancel pending actions of this session * Cancel all pending actions or similar. It

Bug#816781: [Aptitude-devel] Bug#816781: aptitude: Can not cancel pending upgrade actions

On 29/05/2017 11:31, Axel Beckert wrote: Before you press the corresponding menu entry, but after already having selected it, aptitude will show the following long description in the status line: Cancel all pending actions from this session So this menu entry only cancels actions which

Bug#816781: aptitude: Can not cancel pending upgrade actions

Package: aptitude Version: 0.8.7-1 Followup-For: Bug #816781 Since some times I'm hitting the following bug and today I've found the time to report it to Debian. Even if it's a different use case, I think it's closely related to this bug, so i'm posting here. Steps to reproduce (always

Bug#841423: LVM: raid1 kernel module not loaded

Here i've talked about raid1 because it is what i've tested myself, but since LVM can handle raid0/1/4/5/6/10, perhaps the same arguments apply also to the other raid types. For example i've noticed that the initramfs' hook from mdadm takes care of loading all the raid modules:

Bug#841423: LVM: raid1 kernel module not loaded

Package: initramfs-tools Version: 0.125 Severity: normal Initially i thought to file this bug to lvm2 package but now i suspect it's more related with kernel modules dependencies and the manual_add_modules() hook of initramfs-tools. Suppose your system has lvm2 installed but not mdadm. Now

Bug#836246: Acknowledgement (libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop)

I'd like to thank Michael Biebl, the only one who was friendly, who saw the value in this BR and who understood the reason why i opened this bug: to let Debian developer know about a problem after a recent upgrade. I'm really bewildered with those people that looks pissed off by me reporting

Bug#836246: libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop

Package: libgtk-3-0 Version: 3.20.9-1 Severity: normal On three pc of mine i had to downgrade the following libraries to have a functioning desktop: libgail-3-0 libgtk-3-0 libgtk-3-bin Up to version 3.20.9-1 all were fine but with 3.21.5-1 and 3.21.5-2 i had so many issues that i had to find a

Bug#826680: [Pkg-utopia-maintainers] Bug#826680: network-manager: please move isc-dhcp-client from Depends: to Recommends:

On Tue, 7 Jun 2016 23:49:33 +0200 Michael Biebl wrote: The default configuration still uses isc-dhcp-client, unless it's explicitly configured otherwise. I don't understand this phrase. The default NetworkManager.conf comes with only these directives: -- [main]

Bug#833888: kbd: Consider including upstream vlock

On 10/08/2016 14:37, Andreas Henriksson wrote: Please do direct your mails to the bug report rather than to me, so that the information gets properly/publicly archived. (I'll get a copy of it any way.) I'm very sorry, i didn't noticed that my reply was directed to you rather that the bug

Bug#833843: Acknowledgement (vlock: Upstream source not reachable)

I think i've found the current home of the vlock package: https://github.com/toidinamai/vlock The last release is 2.2.3 (2011), while Debian is at 2.2.2. However, the reposistory last commit is 12 may 2009, so no activity from upstream. Cesare.

Bug#827228: [Pkg-running-devel] Bug#827228: pytrainer: Add firefox-esr to the browser dependency list

On 14/06/2016 08:07, Christian PERRIER wrote: Upload is on its way. However, is there indeed a reason to *keep* iceweasel in the dependency list? Hello Christian, any news on that? Currently i'm unable to remove the iceweasel package, because it's a dependency only of pytrainer. I think

Bug#833843: Acknowledgement (vlock: Upstream source not reachable)

Ouch, i didn't notice that this package was orphaned in 2014... So, given this, and given that kbd Debian package doesn't include the upstream vlock binary, i've opened a bug to kbd as they can reconsider its inclusion. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833888 Maybe it can

Bug#833888: kbd: Consider including upstream vlock

Package: kbd Version: 2.0.3-2 Severity: normal Upstream kbd provides a vlock binary but it's not included in the Debian package. Looking from Debian's changelog it's like that since february 2013. I know that Debian already provides a separate vlock package (i use it), but it was last updated in

Bug#833843: vlock: Upstream source not reachable

Package: vlock Version: 2.2.2-5 Severity: normal I've noted that the copyright entry point to a server that doesn't look to exist enymore: http://cthulhu.c3d2.de/~toidinamai/vlock/archive/ Is upstream still active? Or perhaps now there's a different location and that entry should be updated.

Bug#827228: pytrainer: Add firefox-esr to the browser dependency list

Package: pytrainer Version: 1.10.2~git20160107-3 Severity: normal Currently firefox-esr has replaced iceweasel, that became a transitional package. But pytrainer depends on iceweasel or firefox or abrowser, preventing the iceweasel transitional package to be removed. Please, add firefox-esr to

Bug#808563: really should be serious bug: data loss

I've done the following tests that seems to prove that the bug is with the PAE kernel, also the last 4.4.0-rc5: * Boot with linux-image-4.4.0-rc5-686 (4.4~rc5-1~exp1): OK. * Boot with linux-image-4.4.0-rc5-686-pae (4.4~rc5-1~exp1): ata errors. * Boot with linux-image-4.3.0-1-686 (4.3.3-2): OK. *

Bug#808563: really should be serious bug: data loss

On 21/12/2015 17:20, 積丹尼 Dan Jacobson wrote: ata1.00: exception Emask 0x60 SAct 0x1c SErr 0x800 action 0x6 frozen ata1.00: irq_stat 0x2000, host bus error ata1: SError: { HostInt } ata1.00: failed command: WRITE FPDMA QUEUED ata1.00: cmd 61/00:10:00:a8:10/08:00:26:00:00/40 tag 2 ncq 1048576

Bug#786382: Bug resolved

Today i've upgraded my system and the problem looks resolved. For details, see the bug opened upstream: https://bugs.freedesktop.org/show_bug.cgi?id=90617 To me this bug can be closed. Cesare.

Bug#786382: linux-image-4.0.0-1-amd64: Blank screen switching to a VT (Intel Haswell with HD4400)

When I replied I did not realize that what you intended for upstream was freedesktop.org, not kernel.org. I've just filed the bug upstream, as you requested: https://bugs.freedesktop.org/show_bug.cgi?id=90617 Also, in my initial message i did a typo in the notebook model: it's a PU301LA (not LS).

Bug#786382: linux-image-4.0.0-1-amd64: Blank screen switching to a VT (Intel Haswell with HD4400)

Package: src:linux Version: 4.0.2-1 Severity: normal Since kernel version 4.0 (also the previous 4.0.0-trunk from experimental) if i try to switch to a VT from an X session (also from the login manager), the screen becomes black and i'm not able to recover from that situation, neither for the X

Bug#786382: linux-image-4.0.0-1-amd64: Blank screen switching to a VT (Intel Haswell with HD4400)

2015-05-21 11:28 GMT+02:00 Julien Cristau jcris...@debian.org: Please file this upstream at https://bugs.freedesktop.org/enter_bug.cgi?product=DRIcomponent=DRM/Intel See instructions at https://01.org/linuxgraphics/documentation/development/how-report-bugs Ok, i'll do. I only ask to the

Bug#784627: lightdm-gtk-greeter: the clock no longer appears

Package: lightdm-gtk-greeter Version: 2.0.0-2 Followup-For: Bug #784627 I confirm what reported by Vincent. As him, i've upgraded from 1.8.5-2 to 2.0.0-2 and since then the clock is not displayed anymore. It's the same if i comment my customized clock-format and leave only show-clock=true. Same

Bug#784310: apt update always fails on experimental/non-free

On 05/05/2015 14:58, Axel Beckert wrote: I though currently can't reproduce it on i386. I was almost sure that i got the error on a i386 PC of mine but since i haven't really tried for some time, the doubt started to arise and since your reply i've run some tests. I confirm what Axel said:

Bug#784310: apt update always fails on experimental/non-free

Package: apt Version: 1.0.9.9 Severity: normal Since months i have an error during the apt update phase, always on experimental/non-free. Initially i thought it was a temporary mirror problem, because changing the repository the error went away. But when in the next days i was doing another

Bug#769222: aptitude: Frequent pending actions left

Package: aptitude Version: 0.6.11-1+b1 Severity: normal On three different PCs (Debian unstable, i386, 32 bit) i'm frequently encountering a problem, where aptitude (curses interface), without any error to the user, leaves some package in an incomplete state. I usually follow these steps: - run

Bug#769222: Aptitude screenshot

Here is my current situation, before i run dpkg --configure -a.

Bug#769299: qemu: Readconfig doesn't recognize memory option

Package: qemu Version: 2.1+dfsg-7 Severity: normal The following option is not recognized by qemu config file: [memory] size = 512 To reproduce, follow these steps: * download a memtest image to run with qemu. I've used the live CD SystemRescueCD, that include memtest. *

Bug#767359: [Pkg-xfce-devel] Bug#767359: Bug#767359: lightdm: Selected session not remembered anymore

On 31/10/2014 09:42, Yves-Alexis Perez wrote: Actually, I think it might not be related to 1.10.2-3 changes, but rather the new upstream release 1.10.3. It has a NEWS entry: * Don't access .dmrc files until information from these files is required I've done some tests and looks like you

Bug#767359: [Pkg-xfce-devel] Bug#767359: Bug#767359: lightdm: Selected session not remembered anymore

On 31/10/2014 15:46, Yves-Alexis Perez wrote: First, it seems that between 1.10.2-2 and 1.10.2-3 the “last started session” state of lightdm-gtk-greeter (found in /var/lib/lightdm/.cache/lightdm-gtk-greeter/state) is not saved. On one PC (the one with 1.10.2-3), if i login with session xfce,

Bug#767359: lightdm: Selected session not remembered anymore

Package: lightdm Version: 1.10.3-2 Severity: normal Suppose you have installed multiple desktop environment (in my case XFCE and MATE). At the lightdm login there is the icon that let you choose which one to start: default, mate, xfce. Well, since some lightdm version (if i recall correctly

Bug#740942: [samba] /etc/init.d/samba forbit systemd shutdown system

Package: samba Version: 2:4.1.11+dfsg-1 Followup-For: Bug #740942 I'm experiencing the same problem: 5 minute to shutdown samba service and the same if i try to stop it on the command line. I believed it was related to the fact that i use samba also to login in an active domain but this bug

Bug#740942: [samba] /etc/init.d/samba forbit systemd shutdown system

Package: samba Version: 2:4.1.11+dfsg-1 Followup-For: Bug #740942 Some notes. On shutdown/reboot, occasionally i see this message from systemd, with a countdown and a moving asterisk: - A stop job is running for LSB: ensure samba daemons are started (nmbd and smbd) ( 3 min 2 s / 5 min

Bug#761881: flashplugin-nonfree: Timeout behind proxy

I just added a timeout of 15 seconds in get-upstream-version.pl. Maybe this is already sufficient for you. Can you try this please ? (First remove /var/cache/flashplugin-nonfree/get-upstream-version.pl and then run update-flashplugin-nonfree --status.) Thank you for looking into this. And

Bug#761881: flashplugin-nonfree: Timeout behind proxy

Package: flashplugin-nonfree Version: 1:3.6 Severity: normal Please, add some timeout to wget, both in update-flashplugin-nonfree and in get-upstream-version.pl. If you are behind a proxy and you do the package install/upgrade or update-flashplugin-nonfree --status, they hang forever (or for a

Bug#746448: linux-image-3.14-1-486: acpi-cpufreq not loaded on some older system

Package: src:linux Version: 3.14.2-1 Severity: normal On some older PCs like mine, the acpi-cpufreq module doesn't load anymore with 3.14 kernel (also with the previous rc7 from experimental) so i'm currently stuck with 3.13. The effect on my notebook is that the cpu runs always at full speed,

Bug#743739: clearlooks-phenix-theme: Include gtk2-engines as dependency

Package: clearlooks-phenix-theme Version: 3.0.16-3 Severity: normal Xfce is still based on GTK2 and if gtk2-engines in not installed, clearlooks-phenix looks bad. Upstream says that gtk2-engine is required if GTK2 applications are used, so i think it should be made a dependency or recommendation

Bug#736712: apt-listchanges: dpkg-architecture: warning: couldn't type, falling back to default (native compilation)

Package: apt-listchanges Version: 2.85.13 Followup-For: Bug #736712 I see this problem too, on two machine on which gcc is not installed, because i don't need it. The couldn't determine gcc system type message is displayed for every package you are about to install. For example: 12 packages, 12

Bug#724578: bmon: No qdisc inspection

Package: bmon Version: 1:2.1.1~pre1-1 Severity: wishlist This package doesn't support the netlink module and, as a consequence, bmon cannot show details about qdiscs and classes. It's a big pity, because bmon seems to be the only small program i've found to show useful and human readable

Bug#723675: CPU details

My initial report doesn't show clearly what CPU i have. Maybe it can be useful to diagnose the problem. # lscpu Architecture: i686 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):1 On-line CPU(s) list: 0 Thread(s) per core:1

Bug#723675: Test on another PC

I've tested 3.11-1~exp1 on a completely different PC, intel based and it boots just fine. Apart for the different CPU vendor, they differ also for the architecture: AMD: i686 Intel: x86_64 No more ideas or things to try. Cesare. -- To UNSUBSCRIBE, email to

Bug#723675: linux-image-3.11-trunk-amd64: kernel panic in early boot

Package: src:linux Version: 3.11-1~exp1 Severity: normal Attached the image that shows what i see booting with: linux-image-3.11-trunk-amd64 (3.11-1~exp1) The panic happens just after Booting the kernel. and some of its information scrolled off the screen. The boot is ok with: -

Bug#670046: xfce4-sensors-plugin: hddtemp error launching xfce4sensors

Package: xfce4-sensors-plugin Version: 1.2.5-2 Followup-For: Bug #670046 Bug still present in this version (Xfce 4.10). At each login (and every time you double click on the applet) an alert is showed for each disk you have on your system: if you have, say, two disks, you get two popup alert

Bug#685108: linux-image-3.2.0-3-amd64: Error message on each boot: [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed

Package: src:linux Followup-For: Bug #685108 I see the same message on every boot but the system looks functional. I have a Sandy Bridge too (G640T) with an Intel board (DH1CR). Dmesg attached. Cesare. -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable')

Bug#685108: linux-image-3.2.0-3-amd64: Error message on each boot: [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed

Package: src:linux Followup-For: Bug #685108 Ehm, the attachment... Cesare. -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8

Bug#699656: general: System freezes while using multimedia via DRI [Intel 82865G chip] on kernels above 3.2.0-3-686-pae

On 11/02/2013 03:33, Ben Hutchings wrote: I realise it's critical to you, but if it doesn't affect other users then I'm afraid it's just not that high a priority. Most i865 systems have been thrown out by now, and to be brutally honest I personally a more concerned about supporting today's

Bug#687927: firmware-realtek: Missing rtl8411-1.fw and rtl8402-1.fw

Package: firmware-realtek Version: 0.36 Severity: normal I have an Intel D525MW motherboard (Atom) with a Realtek integrated network card. It doesn't work with the current kernel from testing: linux-image-3.2.0-3-amd64 (3.2.23-1) It doesn't print anything special in the syslog: # dmesg | grep

Bug#656813: cfg80211: failed to add phy80211 symlink to netdev!

Package: linux-2.6 Followup-For: Bug #656813 I admit that starting from the Stanislaw Gruszka's reply i was a bit lost in this bug report... With this followup i only wanted to say that with the kernel 3.5 the message cfg80211: failed to add phy80211 symlink to netdev! is gone. Now i see a

Bug#653669: Installation works now

On 02/06/2012 07:00, Bernhard wrote: One thing, i have observed during installation: The installation of the packages takes very long. If i use ext4 as filesystem, the installation takes a significant shorter time. Maybe the entry regarding dpkg from this blog article could explain this:

Bug#670046: hddtemp error launching xfce4sensors

In the initial message i wrote: Since few days ago the popup error was single, for sda. Now it pops up also for /dev/sdb that it is neither present on my system: Ok, i think this behaviour is explainable (even if not that clear to me) and reproducible: i often use this laptop to recharge my

Bug#652941: Seems resolved

I've just upgraded to Iceweasel 10.0.3esr-1 and the problem looks resolved. Recently i've workarounded the problem setting webgl.disabled=true, as someone suggested on upstream bugzilla. Now i've just verified that the crashes reported in this bug doesn't happen anymore with the default

Bug#652941: This bug will not be resolved

On 09/01/2012 08:51, Mike Hommey wrote: Oh it's not a bug you filed. File a new one, that'll be better. Please mention as much information as you can. Kernel version, X.org driver version, Mesa version, crash backtrace, or even better crash id from the upstream crash reporter (try reproducing

  1   2   3   >