Bug#807996: 807996 still exists; workaround
Sorry, I just discovered this bug report. I have been having this problem for years, and don't remember when it started. I have been using a workaround, but would like to find a better solution. I see the workaround I have been using is one of those Kingsley G. Morse tried but could not get to work. The workaround is, after registering each CD-ROM using apt-cdrom, modify the /etc/sources.list file. Edit it to add the "trusted" flag to the entry for each CD-ROM. (In my case, I am using DVDs.) For example: deb [trusted=yes] cdrom:[Debian GNU/Linux 10.9.0 _Buster_ - Official amd64 DVD Binary-2 20210327-10:39]/ buster contrib main Then run "apt update". Which now works, although it generates an annoying number of "ign:" messages. Presumably it is okay to "trust" your CD-ROM set because you have physical control of it, and thus are reasonably sure it has not been tampered with. However, recently I happened to read the apt-secure man page, which warns that some future release of apt will no longer honor flags like "trust". That warning started me hunting for a better solution. Haven't found it yet, but did find this bug report. I can replicate the bug in a variety of situations, but below I give an example of a particularly simple test case: I am running Debian stable amd-64 with a fairly standard desktop selection of packages. First I use my favorite Internet mirror to update to the latest stable release 10.9. No problems. Then, I download the first few DVD images of the same release. So far, these are reasonable actions for someone who doesn't always have good Internet. Next, register the DVDs using apt-cdrom, but for testing purposes, I only register one of them. I choose the second DVD of the set, because I happen to know the names of some packages it contains but I have not yet installed. Next, I disable the Internet repository, by editing /etc/sources.list to comment out its entry. Then run "apt update", which results in the following errors: Ign:1 cdrom://[Debian GNU/Linux 10.9.0 _Buster_ - Official amd64 DVD Binary-2 20210327-10:39] buster InRelease Err:2 cdrom://[Debian GNU/Linux 10.9.0 _Buster_ - Official amd64 DVD Binary-2 20210327-10:39] buster Release Please use apt-cdrom to make this CD-ROM recognized by APT. apt-get update cannot be used to add new CD-ROMs Hit:3 http://security.debian.org/debian-security buster/updates InRelease Reading package lists... Done E: The repository 'cdrom://[Debian GNU/Linux 10.9.0 _Buster_ - Official amd64 DVD Binary-2 20210327-10:39] buster Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. Next, I verify the DVD really was excluded from the update. I run "apt search" on some of its packages. As expected, "apt search" does not find them. To test the workaround, I apply it as described above. After running "apt update" I then run "apt search" for the same packages as before, confirming apt now knows they exist. I then run "apt install" on one of the packages on DVD #2, and confirm it installs okay.
Bug#870641: light-locker: screen stays black after closing and opening laptop lid
On Tue, 14 Jul 2020, Aaron Lu wrote: Anyway, I downloaded this package directly from the mirror's pool: linux-image-4.19.0-10-amd64-unsigned_4.19.131-2_amd64.deb Is the above package correct? And the good news is, this kernel also works fine :-) I tried something similar, but am having mixed results. I added "buster-proposed-updates main" to sources.list, and installed linux-image-4.19.0-10-amd64. Which I think should be the same as Aaron Lu retrieved, except I have the signed variant. I installed on a Panasonic CF-19 laptop running Debian 10.4 and xfce. Recovering from screen blanking and locking does work with that version of the kernel. So, on my computer, it does work better than the standard buster kernel 4.19.0-9. However, suspend and hibernate still don't work. I haven't had a chance to try Aaron Lu's suggestion of backported kernel 5.6.0. However, I have been using 5.4.0 for a while, and blanking, locking, suspend, and hibernate all work with that version. Hope this information is helpful.
Bug#870641: light-locker: screen stays black after closing and opening laptop lid
I see I am coming to this thread a bit late, but for what it is worth, here is some additional information. But first, thanks to Udo Richter for suggesting the workaround of installing linux-image-5.4.0-0.bpo.2-amd64, in other words backporting the testing/bullseye kernel into buster. On my laptop, this fixed the intermittent problem restoring blanked screen. It also seems to have introduced a new problem where the computer occasionally does not blank or lock when it should, but that is far better than occasionally losing work-in-progress due to inability to restore the screen. However, this does not seem to simply be a case of buster's default 4.19.0 kernel being buggy. I say this, because I tried the backport version of 4.19.0 in stretch. On my laptop, screen blanking and locking work just fine in stretch, regardless whether it is the default 4.9.0 or the backported 4.19.0 kernel. Apparently, something besides the kernel changed between stretch and buster. Some background info: I have been testing with the xfce desktop on a Panasonic CF-19 laptop. Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
Bug#722089: rectangle select slows gimp
Package: gimp Version: 2.8.2-2 The gimp slows noticably when I use the rectangle select tool. On my 1.9 GHz Pentium 4 machine, it is quite responsive doing tasks like changing the color balance of a 10 megapixel photo, but after selecting a region using the rectangle tool, it slows markedly. All gimp functions I have tried get slow, for example, opening a menu takes upwards of 5 seconds. Cursor movement remains responsive, although it can take a few seconds for the cursor symbol to update. Examining the running processes, 'gimp' looks okay but 'x' continuously uses about 85% of the CPU. Memory use looks okay. If I switch to another application, for example LibreOffice, that application is responsive. The gimp remains slow and x remains a CPU hog until I close the image or I dismiss the selection using the 'select none' command. One peculiar aspect, xcf files seem to preserve whatever causes the problem. If I save a file while the gimp is slow, then the gimp will slow again when I reopen the file. To demonstrate this, I created the attached example by opening the gimp, and created an empty image with the letter template. To make the image a little more interesting, I used the gradient tool to apply a conical gradient. The gimp showed almost no hesitation to any of these commands. Then I selected a small region with the rectangle tool and the gimp slowed. I patiently did a crop to selection to make the image smaller for your convenience. Then saved and closed the gimp. Then I opened the gimp with this small file. The gimp immediately becomes slow. Patiently open a 10 megapixel JPEG, whose window happens to cover the small image, and the gimp becomes responsive. Bring the window with the small image forward, and the gimp slows. Issue the 'select none' command and the gimp becomes responsive. Problem started when I upgraded from Debian 6.6 to 7.1. With 6.6, the gimp was responsive even with multiple ten-megapixel images open with multiple regions selected. I am running Debian 7.1 with pretty much standard desktop installation except xfce instead of gnome. kernel 3.2.0-4-686-pae libc6 2.13-38 X server-common 2:1.12.4-6 xfce4 4.8.0.3 gimp 2.8.2-2 Asus P4T 533-C Intel Pentium 4 478 1.9 GHz PNY Verto GeForce FX 5900SE AGP conical_crop_small.xcf Description: application/xcf
Bug#648570: floppy device in 6.0.6
Regarding the floppy mounting problem with Debian 6.0.3 Dr Gursel reported as bug 64857, I am experiencing nearly identical problem in 6.0.6. The difference in my case, floppy media work fine as long as I refrain from using any other sort of removable media. For example, after booting the computer, I insert a floppy disk into the internal drive, mount it using either xfce or command line. The floppy works fine. Then I insert a USB flash memory drive. From then on, I can mount and unmount USB or other media whenever desired, but cannot unmount the floppy. I tried Dr Gursel's workaround involving modifying /etc/rc.local, and it works. I am running an ordinary desktop install of Debian i386, except using xfce instead of gnome. Asus P4T533-C motherboard with Mitsumi floppy drive. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
