Bug#878379: xscreensaver-screensaver-webcollage: Please provide a means to set safe seach levels for those image search mehods that support it.
Package: xscreensaver-screensaver-webcollage Version: 5.36-1 Severity: wishlist Tags: upstream Dear Maintainer, * What led up to the situation? I installed the package,selected and configured the software. * What exactly did you do (or not do) that was effective (or ineffective)? I read the documentation, skimmed the source, and was surprised that no such options existed even to be passed as command-line parameters. * What was the outcome of this action? A "Wishlist" category bugreport. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.13.0-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xscreensaver-screensaver-webcollage depends on: ii libc62.24-17 ii libgdk-pixbuf2.0-0 2.36.11-1 ii libglib2.0-0 2.54.1-1 ii libice6 2:1.0.9-2 ii libjpeg62-turbo 1:1.5.2-2 ii libsm6 2:1.2.2-1+b3 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxft2 2.3.2-1+b2 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.1.5-1 ii xscreensaver-data-extra 5.36-1 xscreensaver-screensaver-webcollage recommends no packages. xscreensaver-screensaver-webcollage suggests no packages. -- no debconf information
Bug#878373: xscreensaver-screensaver-webcollage: Fails to get resuls from google, bing, and instagram making collages repetitive.
Package: xscreensaver-screensaver-webcollage Version: 5.36-1 Severity: normal Tags: upstream Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I installed the screensaver and selected it, on running I observed lots of repetition, and not that much variety in the images displayed. * What exactly did you do (or not do) that was effective (or ineffective)? Installed a larger dictionary, then ran the demo with verbose output enabled ( -vv ) Although I inspected the upstream source, the idea of trying to compile on an old PII (klamath) machine put me off the idea of attempting to modify the search routines, or try using the slightly newer upstream version. * What was the outcome of this action? The dictionary appeared to make little difference, output from the -vv --no-output options indicated the majority of sources returning no images, and a very heavy reliance on results from flikr. * What outcome did you expect instead? I expected a decent sized dictionary to result in a wide variety of images, without much repetition. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.13.0-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xscreensaver-screensaver-webcollage depends on: ii libc62.24-17 ii libgdk-pixbuf2.0-0 2.36.11-1 ii libglib2.0-0 2.54.1-1 ii libice6 2:1.0.9-2 ii libjpeg62-turbo 1:1.5.2-2 ii libsm6 2:1.2.2-1+b3 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxft2 2.3.2-1+b2 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.1.5-1 ii xscreensaver-data-extra 5.36-1 xscreensaver-screensaver-webcollage recommends no packages. xscreensaver-screensaver-webcollage suggests no packages. -- no debconf information
Bug#918912: python3-gtkspellcheck: Causes reportbug-gtk to crash when no dictionary found
Package: python3-gtkspellcheck Version: 4.0.5-1 Severity: normal Dear Maintainer, Attempting to report a bug in another package reportbug-gtk crashed with the following terminal output: no dictionaries found Traceback (most recent call last): File "/usr/bin/reportbug", line 2275, in main() File "/usr/bin/reportbug", line , in main return iface.user_interface() File "/usr/bin/reportbug", line 2191, in user_interface package, severity, mode, charset=charset, tags=tags) File "/usr/bin/reportbug", line 182, in handle_editing editor, charset) File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1761, in func op = application.call_in_main_thread(klass, parent) File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 584, in call_in_main_thread raise ret File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 571, in callback ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 622, in __init__ self.widget = self.create_widget() File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1323, in create_widget gtkspellcheck.SpellChecker(self.view) File "/usr/lib/python3/dist-packages/gtkspellcheck/spellcheck.py", line 211, in __init__ raise NoDictionariesFound() gtkspellcheck.spellcheck.NoDictionariesFound As no guidence is offered which of Debian's many dictionary types and packages might be appropriate, I switched to the text interface. As a workarund I switched to using the text interface to report bugs! * What outcome did you expect instead? I expected the gtk interface to work without crashing, and spewing errors into the terminal I launced reporrtbug from. Surely if python3-gtkspellcheck is going to crash without a dictionary, it should list dictionaries as a depend so one gets installed if none are present, rather than relying on blind luck that one might be installed? Especially since it renders other packages unuseable. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.19.0-1-686 (SMP w/1 CPU core) Locale: LANG=, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=: (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages python3-gtkspellcheck depends on: ii gir1.2-gtk-3.0 3.24.2-3 ii python3 3.7.1-3 ii python3-enchant 2.0.0-1 ii python3-gi 3.30.4-1 Versions of packages python3-gtkspellcheck recommends: ii iso-codes 4.1-1 Versions of packages python3-gtkspellcheck suggests: pn python-gtkspellcheck-doc -- no debconf information
Bug#855380: reportbug: UI offers "Back", but doesn't allow to edit the data
Package: reportbug-gtk Version: 7.5.1 Followup-For: Bug #855380 Dear Maintainer, Just to note this bug is still present, and sufficiently annoying to make one use the text based reportbug package instead. I have no idea if it's related, but the application also crashed owing to want of a dictinary for python3-gtkspellcheck. I found it as a consequence of the program complaing about a long description, and expected to be able to revise the description by use of the back button, being unable to I was forced to abort the process and start over, I still haven't reported the original bug. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.19.0-1-686 (SMP w/1 CPU core) Locale: LANG=, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=: (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages reportbug-gtk depends on: ii gir1.2-gtk-3.0 3.24.2-3 ii gir1.2-vte-2.910.54.2-2 ii python3-gi 3.30.4-1 ii python3-gi-cairo 3.30.4-1 ii python3-gtkspellcheck 4.0.5-1 ii reportbug 7.5.1 reportbug-gtk recommends no packages. reportbug-gtk suggests no packages. -- no debconf information
Bug#918918: dkms attempts to install incorrect headers (686-pae instead of plain 686)
Package: dkms Version: 2.6.1-3 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? When attempting to install virtualbox-guest-x11, I noticed headers for the pae kernel being pulled in, my virtualbox installation does not support PAE/NX enabled guests. So I backtracked which package was pulling the pae headers in as a depend. It turns out to be dkms. I tried installing the correct headers ahead of time, but they were ignored. I note on the package page that linux-headers-686 are not listed as a possibilty to satisfy the depend. Once I finish this report I'll be seeing if I can modify the control locally to permit linux-headers-686 to be acceptable, or else use equivs to fake the package into thinking the right headers are actually the wrong ones dkms thinks it wants. I was quite surprised not to see linux-headers-686 listed as well as 686-pae on the package information page. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.19.0-1-686 (SMP w/1 CPU core) Locale: LANG=, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=: (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages dkms depends on: ii build-essential 12.5 ii coreutils8.30-1 ii dpkg-dev 1.19.2 ii gcc 4:8.2.0-2 ii kmod 25-2 ii make 4.2.1-1.2 ii patch2.7.6-3 Versions of packages dkms recommends: ii fakeroot 1.23-1 pn linux-headers-686-pae | linux-headers-amd64 | linux-headers- ii lsb-release 10.2018112800 ii sudo 1.8.26-2 Versions of packages dkms suggests: pn menu pn python3-apport
Bug#918918: dkms attempts to install incorrect headers (686-pae instead of plain 686)
Package: dkms Version: 2.6.1-3 Followup-For: Bug #918918 Dear Maintainer, Quick update with more information. * What exactly did you do (or not do) that was effective (or ineffective)? Unpacked the .deb edited control to include linux-headers-686 in addition to the headers listed as a suitable depend, installed dkms using dpkg put dkms on hold till this trivial-to-fix bug is fixed :-) * What was the outcome of this action? Everything worked as expected, modules were built using the correct headers. The built modules appear completely functional. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.19.0-1-686 (SMP w/1 CPU core) Locale: LANG=, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=: (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages dkms depends on: ii build-essential 12.5 ii coreutils8.30-1 ii dpkg-dev 1.19.2 ii gcc 4:8.2.0-2 ii kmod 25-2 ii make 4.2.1-1.2 ii patch2.7.6-3 Versions of packages dkms recommends: ii fakeroot 1.23-1 ii linux-headers-686 4.19+101 *only because I edited control ii lsb-release10.2018112800 ii sudo 1.8.26-2 Versions of packages dkms suggests: pn menu pn python3-apport -- no debconf information
Bug#1005881: runit-init: Not installable in bookworm.
Package: runit-init Severity: grave Justification: renders package unusable Dear maintainer, I just tried to switch to runit-init on bookworm, as I have done many times on installs of stable (bullseye). On a new install with only standard system utilities I executed "apt-get install runit init" What I expected to happen was for apt to complain & to have to repeat the command with --allow-remove-essential specified, watch it install, then reboot to a system using runit-init as pid 1. What happened: Apt still refused to install it, citing init pre-depends on systemd-sysv or sysvinit-core and that neither are installable. Which is funny given currently apt-cache policy systemd-sysv shows version 250.3-2 installed, the very thing I wish to switch away from. What I expected to happen, is for it to install, then to reboot into a system using runit-init & configure from there just as I can when running stable. Even if I had to specify --allow-remove-essential. However, neither that nor even --force-yes would cause runit-init to be installed. I also tried with runit & runit-run installed, just to see if having those present already helped, it didn't. The attempt did leave my system broken though I had to apt-get install --reinstall systemd-sysv then apt-get remove runit* before it would behave again. I iaso tried switching to sysvinit-core first, that switch went well, but the attempt to switch to runit-init had a very similar outcome, namely I couldn't find any way to install the package. Currently I can see no method available to get this package installed. It's possible of course that this is a bug in apt & needs reassigning, that however, is beyond my pay-grade to decide. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages runit-init depends on: pn getty-run pn initscripts pn insserv ii runit2.1.2-44 runit-init recommends no packages. runit-init suggests no packages.
