Bug#1066018: kakoune: Installs README outside /usr/share/doc/kakoune/
Package: kakoune Version: 2022.10.31-2 Severity: minor Dear Maintainer, I was looking at where the Kakoune package installs its documentation: dpkg-query -L kakoune | sed -e 's@/[^/]*$@@' | sort -u | grep doc ...expecting to find three directories: /usr/share/doc (because it creates a package directory inside here) /usr/share/doc/kakoune/ (Debian package changelog, README, etc.) /usr/share/kak/doc/ (Kakoune's online documentation) Instead, I found an additional fourth directory, /usr/share/doc/kak Apparently the Kakoune README is installed to /usr/share/doc/kak, while all the other package documentation (package changelog, licence, etc.) is installed to /usr/share/doc/kakoune. I think the README should be installed in the directory named after the package, as it is with other Debian packages. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages kakoune depends on: ii libc6 2.37-15 ii libgcc-s1 14-20240201-3 ii libstdc++6 14-20240201-3 kakoune recommends no packages. kakoune suggests no packages. -- no debconf information
Bug#1065138: fwupd: "failed to load BOS descriptor" disables my mouse
Package: fwupd
Version: 1.9.14-1
Severity: important
Dear Maintainer,
I have a Kensington Expert Mouse (trackball) connected by USB. Today I
installed the update to fwupd 1.9.14 that `apt upgrade` offered me. Soon
afterwards, my trackball stopped working. I was able to re-enable it by
disconnecting and reconnecting it, but this proved short-lived - it eventually
cut out again. I reconnected it and it worked for a little longer, then I had
to reconnect it again, and eventually reconnecting it did nothing - it stayed
non-functional.
I started checking the logs, and eventually I noticed this error message
appearing shortly before the messages recording the trackball's reconnection:
fwupd[1106287]: 01:23:55.952 FuUsbDevice failed to load BOS descriptor
from USB device: USB error on device 047d:1020 : Operation timed out [-7]
I can confirm that 047d:1020 identifies my trackball:
$ for name in
/sys/bus/usb/devices/1-1.6/{idVendor,idProduct,manufacturer,product}; do printf
"%s\t%s" "$(basename "$name")"; cat "$name"; done
idVendor047d
idProduct 1020
manufacturerKensington
product Kensington Expert Mouse
I ran "systemctl stop fwupd", reconnected my trackball, and then it worked
fine.
Investigating further, I discovered that I can disable my trackball on-demand
by running "sudo fwupdtool get-devices". It prints the following output:
Loading… [***]05:01:05.132
FuUsbDevice failed to load BOS descriptor from USB device: USB error
on device 047d:1020 : Operation timed out [-7]
Loading… [** ]
...and then my trackball stops working until I reconnect it.
It seems that fwupd 1.19.14's changelog mentions "Fix DS-20 descriptors by
opening the GUsbDevice earlier", and apparently "DS-20 descriptor" is a
specific kind of "BOS descriptor".
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fwupd depends on:
ii adduser3.137
ii libarchive13 3.7.2-1
ii libc6 2.37-15
ii libcbor0.100.10.2-1.1
ii libcurl3-gnutls8.5.0-2
ii libflashrom1 1.3.0-2.1+b1
ii libfwupd2 1.9.14-1
ii libglib2.0-0 2.78.4-1
ii libgnutls303.8.3-1
ii libgudev-1.0-0 238-3
ii libgusb2 0.4.8-1
ii libjcat1 0.2.0-2
ii libjson-glib-1.0-0 1.8.0-2
ii liblzma5 5.4.5-0.3
ii libmbim-glib4 1.30.0-1
ii libmbim-proxy 1.30.0-1
ii libmm-glib01.22.0-3
ii libpolkit-gobject-1-0 124-1
ii libprotobuf-c1 1.4.1-1+b1
ii libqmi-glib5 1.34.0-2
ii libqmi-proxy 1.34.0-2
ii libsqlite3-0 3.45.1-1
ii libsystemd0255.3-2
ii libtss2-esys-3.0.2-0 4.0.1-7
ii libxmlb2 0.3.15-1
ii shared-mime-info 2.4-1
ii zlib1g 1:1.3.dfsg-3+b1
Versions of packages fwupd recommends:
ii bolt 0.9.6-2
ii dbus 1.14.10-4
ii fwupd-amd64-signed [fwupd-signed] 1:1.4+1
ii jq 1.7.1-2
ii python33.11.6-1
pn secureboot-db
ii udisks22.10.1-5
Versions of packages fwupd suggests:
pn gir1.2-fwupd-2.0
-- Configuration Files:
/etc/fwupd/fwupd.conf [Errno 13] Permission denied: '/etc/fwupd/fwupd.conf'
-- no debconf information
Bug#1060297: acmetool's systemd timer is stopped when the package is upgraded
Package: acmetool Version: 0.2.2-2+b1 Severity: normal Dear Maintainer, I installed acmetool a while ago, with the systemd timer unit to keep my certificates refreshed, and I've generally been very happy with it. However, sometimes Let's Encrypt emails me that my certificates are about to expire, and when I check, the systemd timer unit is stopped, and I have been unable to figure out why. Today there was an updated acmetool package, and I caught it in the act. Before I ran "apt upgrade", acmetool was scheduled: ``` $ sudo systemctl list-timers --all NEXT LEFT LAST PASSED UNIT --- -- Tue 2024-01-09 12:27:46 AEDT 1h 18min Tue 2024-01-09 00:21:01 AEDT 10h ago acmetool.timer ``` I then ran "apt upgrade", which completed successfully without errors or warnings. Suddenly, the timer unit had been deactivated: ``` $ sudo systemctl list-timers --all NEXT LEFT LAST PASSED UNIT -- --- -- - - Tue 2024-01-09 00:21:01 AEDT 10h ago acmetool.timer ``` And sure enough, although the unit was still loaded and "enabled" (which I understand means "automatically activated") it was now inactive: ``` $ sudo systemctl status acmetool.timer ○ acmetool.timer - Reconcile Let's Encrypt certificates twice daily Loaded: loaded (/usr/lib/systemd/system/acmetool.timer; enabled; preset: enabled) Active: inactive (dead) since Tue 2024-01-09 11:09:26 AEDT; 1min 59s ago Duration: 3d 22h 57min 44.320s Trigger: n/a Triggers: ● acmetool.service Jan 05 12:11:41 boombah systemd[1]: Started acmetool.timer - Reconcile Let's Encrypt certificates twice daily. Jan 09 11:09:26 boombah systemd[1]: acmetool.timer: Deactivated successfully. Jan 09 11:09:26 boombah systemd[1]: Stopped acmetool.timer - Reconcile Let's Encrypt certificates twice daily. ``` I'm open to the possibility that I have somehow misconfigured systemd in a way that causes this unit (and no others) to be deactivated, but I did follow the instructions in the README.Debian.gz file to set it up. Thank you for packaging such a useful tool! -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages acmetool depends on: ii libc62.37-13 ii libcap2 1:2.66-4+b2 Versions of packages acmetool recommends: ii dialog 1.3-20231002-1 acmetool suggests no packages. -- no debconf information
Bug#998837: gnome-flashback: GNOME Flashback segfaults at login
Package: gnome-flashback
Version: 3.42.0-1
Severity: important
Dear Maintainer,
After updating gnome-flashback today, I am unable to login to the "GNOME
Flashback (Metacity)" sesson - I immediately get the "Oh no, an error occured,
please log out" screen.
Poking around in `journalctl --user` I discovered the following entry at the
time of my login attempt:
gnome-flashback.service: Main process exited, code=killed, status=11/SEGV
After installing systemd-coredump, I managed to extract a backtrace:
#0 gf_logical_monitor_configs_have_monitor
(logical_monitor_configs=logical_monitor_configs@entry=0x55ec78aeb020 =
{...}, monitor_spec=monitor_spec@entry=0x55ec78ad1f50)
at ./backends/gf-logical-monitor-config.c:56
#1 0x55ec77c8bd48 in gf_monitors_config_new
(monitor_manager=monitor_manager@entry=0x7fa438003d70,
logical_monitor_configs=logical_monitor_configs@entry=0x55ec78aeb020 = {...},
layout_mode=layout_mode@entry=GF_LOGICAL_MONITOR_LAYOUT_MODE_PHYSICAL,
flags=flags@entry=GF_MONITORS_CONFIG_FLAG_NONE) at ./backends/gf-monitors-
config.c:179
#2 0x55ec77c934a6 in create_monitors_config
(match_rule=, positioning=MONITOR_POSITIONING_LINEAR,
config_flags=GF_MONITORS_CONFIG_FLAG_NONE, config_manager=,
config_manager=) at ./backends/gf-monitor-config-manager.c:603
#3 0x55ec77c8643b in gf_monitor_manager_ensure_configured
(manager=manager@entry=0x7fa438003d70) at ./backends/gf-monitor-manager.c:2786
#4 0x55ec77c98d79 in gf_monitor_manager_xrandr_ensure_initial_config
(manager=0x7fa438003d70) at ./backends/gf-monitor-manager-xrandr.c:699
#5 0x55ec77c85ce7 in gf_monitor_manager_setup (manager=0x7fa438003d70) at
./backends/gf-monitor-manager.c:2477
#6 0x55ec77c841c3 in gf_backend_new
(type=type@entry=GF_BACKEND_TYPE_X11_CM) at ./backends/gf-backend.c:377
#7 0x55ec77c823e0 in gf_application_init (application=0x55ec78ae4550) at
./gnome-flashback/gf-application.c:328
Looking at the code of gf_logical_monitor_configs_have_monitor(), it takes a
list of GfLogicalMonitorConfig, and the first one in the list looks like:
(gdb) print *((GfLogicalMonitorConfig *)l->data)
$5 = {layout = {x = 3, y = 0, width = 0, height = 0},
monitor_configs = 0xe0001 = {
...which seems very suspicious to me. The second one in the list looks like:
(gdb) print *((GfLogicalMonitorConfig *)logical_monitor_configs->next->data)
$9 = {layout = {x = 0, y = 0, width = 1920, height = 1080},
monitor_configs = 0x55ec78b1ac60 = {0x55ec78b1f020},
transform = GF_MONITOR_TRANSFORM_NORMAL, scale = 1, is_primary = 1,
is_presentation = 0}
...which seems to exactly match the monitor I'm using. There is no third item
in the list.
I walked up the stack to create_monitors_config() where this data structure is
created, and it looks like the `logical_monitor_configs` variable is created,
and then appended to, but never initialised. I don't know if that's actually
the problem, but it's consistent with the symptoms I'm seeing.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gnome-flashback depends on:
ii gnome-flashback-common 3.42.0-1
ii libasound2 1.2.5.1-1
ii libatk1.0-0 2.36.0-2
ii libc62.32-4
ii libcairo21.16.0-5
ii libcanberra-gtk3-0 0.30-8
ii libcanberra0 0.30-8
ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii libgdm1 41.0-3
ii libglib2.0-0 2.70.0-3
ii libgnome-bluetooth13 3.34.5-4
ii libgnome-desktop-3-1941.0-1
ii libgnome-panel0 3.42.0-1
ii libgtk-3-0 3.24.30-3
ii libibus-1.0-51.5.25-2
ii libpam0g 1.4.0-10
ii libpango-1.0-0 1.48.10+ds1-1
ii libpangocairo-1.0-0 1.48.10+ds1-1
ii libpolkit-agent-1-0 0.105-31
ii libpolkit-gobject-1-00.105-31
ii libpulse-mainloop-glib0 15.0+dfsg1-2
ii libpulse015.0+dfsg1-2
ii libsystemd0 249.5-2
ii libx11-6 2:1.7.2-2+b1
ii libx11-xcb1 2:1.7.2-2+b1
ii libxcb-randr01.14-3
ii libxext6 2:1.3.4-1
ii libxfixes3 1:5.0.3-2
ii libxi6 2:1.8-1
ii libxkbfile1 1:1.1.0-1
ii libxrandr2 2:1.5.2-1
ii libxxf86vm1 1:1.1.4-1+b2
ii nautilus 41.1-1
Versions of packages gnome-flashback recommends:
ii dbus 1.12.20-3
ii gnome-settings-daemon 41.0-2
ii libpam-gnome-keyring 40.0-3
Versions of pac
Bug#997665: projectm-pulseaudio should depend on projectm-data
Package: projectm-pulseaudio Version: 3.1.12-1 Severity: normal Dear Maintainer, Today I heard about ProjectM for the first time, so I looked at the list of packages and decided projectm-pulseaudio would be the most useful variant for me. I installed it: $ sudo apt install projectm-pulseaudio The following NEW packages will be installed: projectm-pulseaudio 0 upgraded, 1 newly installed, 0 to remove and 22 not upgraded. Need to get 428 kB of archives. After this operation, 1,349 kB of additional disk space will be used. ...but when I tried to run it, it failed: $ projectM-pulseaudio Default config: /usr/share/projectM/config.inp trying to create /home/st/.projectM/config.inp Cannot find projectM default config, using implementation defaults Aborted `apt-file` tells me that `/usr/share/projectM/config.inp` comes from the package projectm-data, and sure enough if I install that, projectM-pulseaudio starts correctly. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages projectm-pulseaudio depends on: ii libc6 2.32-4 ii libgcc-s1 11.2.0-9 ii libgl1 1.3.4-2+b1 ii libpulse0 15.0+dfsg1-2 ii libqt5core5a5.15.2+dfsg-12 ii libqt5gui5 5.15.2+dfsg-12 ii libqt5opengl5 5.15.2+dfsg-12 ii libqt5widgets5 5.15.2+dfsg-12 ii libstdc++6 11.2.0-9 ii pulseaudio 15.0+dfsg1-2 projectm-pulseaudio recommends no packages. projectm-pulseaudio suggests no packages. -- no debconf information
Bug#974186: /usr/bin/gnome-software: gnome-software uses way too much memory
Package: gnome-software Version: 3.38.0-2 Severity: important File: /usr/bin/gnome-software Dear Maintainer, Thank you for working on keeping GNOME packages up-to-date in Debian, and thank you in particular for packaging GNOME Software, which makes it easy to keep on top of package updates, especially for Testing where they happen regularly. I have a low-end laptop with 2GB of RAM, and I usually run GNOME 3 because it's highly polished and light-weight enough that I can still run a browser and a few terminals to get work done. The one exception is gnome-software, which frequently claims 15% or more of my RAM whenever it checks for updates. Right now, it's sitting at ~18%, or 335MB resident — that may not be much on other computers, but for my little laptop it's often enough to get my browser OOM- killed while I'm in the middle of something. Is there some way I can make GNOME Software stop checking for updates, or at least stop holding (presumably) the entire package list in memory after the update-check is complete? From GNOME Software's hamburger menu, I picked "Update Preferences" and disabled "Automatic Updates" and "Automatic Update Notifications", but that doesn't seem to stop it from checking for updates (what seems like) every time I wake my laptop up. I also went into the "Software & Updates" application, and set "Automatically check for updates" to "Never". Still no change. Previously, I've just sent the gnome-software process a SIGTERM and that cleaned it up until the next time I logged in, but more recently it's been automatically restarted. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/2 CPU threads) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-software depends on: ii appstream0.12.11-1 ii apt-config-icons 0.12.11-1 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-1 ii gnome-software-common3.38.0-2 ii gsettings-desktop-schemas3.38.0-2 ii libappstream-glib8 0.7.17-1 ii libatk1.0-0 2.36.0-2 ii libc62.31-4 ii libcairo21.16.0-4 ii libfwupd21.4.6-2 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.66.2-1 ii libgspell-1-21.8.4-1 ii libgtk-3-0 3.24.23-2 ii libgtk3-perl 0.037-1 ii libgudev-1.0-0 234-1 ii libjson-glib-1.0-0 1.6.0-1 ii libmalcontent-0-00.9.0-2 ii libpackagekit-glib2-18 1.2.1-1 ii libpolkit-gobject-1-00.105-29 ii libsoup2.4-1 2.72.0-2 ii libxmlb1 0.1.15-2 ii packagekit 1.2.1-1 ii software-properties-gtk 0.96.20.2-2.1 Versions of packages gnome-software recommends: ii fwupd 1.4.6-2 Versions of packages gnome-software suggests: pn apt-config-icons-hidpi pn gnome-software-plugin-flatpak pn gnome-software-plugin-snap -- no debconf information
Bug#961332: Fwd: Bug#961332: gnome-flashback: System indicators (volume, bluetooth, ...) do not appear
On 5/6/20 21:02, Alberts Muktupāvels wrote: > I do know that gnome-flashback is used with i3, but it is not really > supported. Doesn't i3 have its own indicators or something like that? i3 has a "bar" which is a bit like GNOME's mini-commander applet - it displays output of a command (that by default shows things like battery charge and system load), but it doesn't have any interactive bits other than a system tray. In particular, it doesn't include a volume control, so I really appreciated the one from gnome-flashback. > If someone really wants the same indicators that were provided by > gnome-flashback then it should not be hard to create them as separate > applications with one exception - input sources. It would need to use > the D-Bus interface provided by gnome-flashback. I don't actually use the input-sources indicator, but I can imagine that being important to some people. > How do you install / configure your session? Do you use something like > Regolith? No, I studied the files installed by Debian's gnome-flashback package, and figured out what I needed to modify. Tim.
Bug#961332: Fwd: Bug#961332: gnome-flashback: System indicators (volume, bluetooth, ...) do not appear
On 24/5/20 7:46 pm, Alberts Muktupāvels wrote: > Mentioned things where turned into gnome-panel applet - System Indicators. Ah, I see - and if I look in Debian's "NEWS" file, I see version 3.35.2 includes "New system indicators applet for gnome-panel". It wasn't clear to me that "system indicators" included things like the volume control, or that "new applet" implied that the old indicator icons were removed. I feel like this change could have been announced a more loudly, but thank you for explaining - I've switched from i3's built-in status-bar to gnome-panel, and now I've got my volume slider back. Thank you again for all the hard work you do maintaining gnome-flashback!
Bug#961332: gnome-flashback: System indicators (volume, bluetooth, ...) do not appear
Package: gnome-flashback Version: 3.36.3-1 Severity: normal Dear Maintainer, First, thank you for packaging and maintaining gnome-flashback! It's really helped my older laptop stay useful and pleasant to use, even as the full GNOME 3 stack is optimised for higher-end hardware. Recently (and I'm afraid I don't have an exact date, although I'm pretty user it was the 3.34 → 3.36 upgrade) gnome-flashback's standard system indicators (the volume control, Bluetooth, the battery charging indicator, etc.) have stopped appearing in the notification area. Other indicators (VLC, Network Manager) appear just fine, but the system indicators are missing. This is still true after logging out and back in, and after rebooting. Full disclosure: I normally use gnome-flashback with the i3 window manager rather than Metacity, according to the instructions in https://zork.net/~st/jottings/gnome-i3.html - although the only difference between gnome-flashback's stock `gnome-flashback-metacity.session` file and mine is that I've swapped `metacity` for `i3` and removed `gnome-panel`. Nevertheless, the missing system indicators are still missing if I log into a standard "GNOME Flashback (Metacity)" session rather than my custom one. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-flashback depends on: ii gnome-flashback-common 3.36.3-1 ii libasound2 1.2.2-2.1 ii libatk1.0-0 2.36.0-2 ii libc62.30-8 ii libcairo21.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-4 ii libgdm1 3.34.1-3 ii libglib2.0-0 2.64.2-1 ii libgnome-bluetooth13 3.34.1-1 ii libgnome-desktop-3-193.36.2-1 ii libgnome-panel0 3.36.1-1+b1 ii libgtk-3-0 3.24.20-1 ii libibus-1.0-51.5.22-5 ii libpam0g 1.3.1-5 ii libpango-1.0-0 1.44.7-4 ii libpangocairo-1.0-0 1.44.7-4 ii libpolkit-agent-1-0 0.105-26 ii libpolkit-gobject-1-00.105-26 ii libpulse-mainloop-glib0 13.0-5 ii libpulse013.0-5 ii libsystemd0 245.5-3 ii libupower-glib3 0.99.11-2 ii libx11-6 2:1.6.9-2+b1 ii libx11-xcb1 2:1.6.9-2+b1 ii libxcb-randr01.14-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-2 ii libxi6 2:1.7.9-1 ii libxkbfile1 1:1.1.0-1 ii libxrandr2 2:1.5.1-1 ii libxxf86vm1 1:1.1.4-1+b2 Versions of packages gnome-flashback recommends: ii dbus 1.12.16-2 ii gnome-settings-daemon 3.36.1-1 ii libpam-gnome-keyring 3.36.0-1 Versions of packages gnome-flashback suggests: ii gnome-power-manager 3.32.0-2 -- no debconf information
Bug#960164: xterm: forceBoxChars mode + cjkWidth mode renders oddly
Package: xterm
Version: 356-1
Severity: minor
Steps to reproduce:
- Launch xterm in "CJK width" mode, forcing xterm to render
box-drawing characters itself:
xterm -cjk_width +fbx
- Run the following command to print some box-drawing characters:
python3 -c 'print("a\u2500\u2500\u2500b\na\u2550\u2550\u2550b\n")'
Expected results:
In non-CJK-width mode, all the printed characters are one character-cell
wide, so the output looks like this (assuming the browser/email client
you're using also uses non-CJK-width mode):
a───b
a═══b
However, the box-drawing characters are "East-Asian Width: Ambiguous"
in Unicode, so in CJK-width mode they should occupy 2 character cells,
looking something like this:
a──b
a══b
Actual results:
a─── b
a═ ═ ═ b
For the second line, I guess xterm doesn't actually treat those box-drawing
characters specially, so it just pads them out, which is fair enough.
For the first line, though, xterm understands the box-drawing characters
should be wide, and it leaves room for them to be wide, but it draws them
narrow. At the very least, if it's going to draw them narrow it should pad
them out like the second line, but if it's going to draw them it might as
well draw them the correct width to begin with.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xterm depends on:
ii libc6 2.30-4
ii libfontconfig1 2.13.1-4
ii libfreetype62.10.1-2
ii libice6 2:1.0.9-2
ii libtinfo6 6.2-1
ii libutempter01.1.6-6
ii libx11-62:1.6.9-2+b1
ii libxaw7 2:1.0.13-1+b2
ii libxext62:1.3.3-1+b2
ii libxft2 2.3.2-2
ii libxinerama12:1.1.4-2
ii libxmu6 2:1.1.2-2+b3
ii libxpm4 1:3.5.12-1
ii libxt6 1:1.1.5-1+b3
ii xbitmaps1.1.1-2
Versions of packages xterm recommends:
ii x11-utils 7.7+5
Versions of packages xterm suggests:
pn xfonts-cyrillic
-- no debconf information
Bug#882768: gargoyle-free: please add %U to gargoyle.desktop
Rather than adding %U (which according to the spec means "a list of
URLs"), it would be better to use "%f" ("A single file name") since
according to the manpage Gargoyle can only load one file at a time, and
does not support URLs.
Bug#931802: evolution: Text gets permanently deleted while composing an email reply
Package: evolution Version: 3.32.2-1 Severity: important Forwarded-To: https://gitlab.gnome.org/GNOME/evolution/issues/531 **Steps to reproduce:** - I sent myself a plain text email containing a single line of text: abc - When I received the email, I hit Ctrl-R to reply - As per my configuration, Evolution opens a new plain-text compose window with the email content quoted: On (time and date), Screwtapello wrote: > abc - I select the text `abc` with my mouse - I press the Delete key on my keyboard to delete it - The "Undo" button on the toolbar becomes enabled, since an editing action has been performed - I click the "Undo" button on the toolbar to bring it back **Actual results:** - The "Undo" button becomes disabled, as though there's nothing to undo - The deleted text does not reappear **Expected results:** - The deleted text reappears - The "Undo" button becomes disabled, since there's nothing left to undo -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evolution depends on: ii dbus 1.12.16-1 ii evolution-common 3.32.2-1 ii evolution-data-server 3.32.2-2 ii libc6 2.28-10 ii libcamel-1.2-623.32.2-2 ii libclutter-gtk-1.0-0 1.8.4-4 ii libecal-1.2-19 3.32.2-2 ii libedataserver-1.2-24 3.32.2-2 ii libevolution 3.32.2-1 ii libglib2.0-0 2.58.3-2 ii libgtk-3-0 3.24.5-1 ii libical3 3.0.4-3 ii libnotify4 0.7.7-4 ii libsoup2.4-1 2.64.2-2 ii libwebkit2gtk-4.0-37 2.24.2-1 ii libxml22.9.4+dfsg1-7+b3 ii psmisc 23.2-1 Versions of packages evolution recommends: ii evolution-plugin-bogofilter 3.32.2-1 ii evolution-plugin-pstimport 3.32.2-1 ii evolution-plugins3.32.2-1 ii yelp 3.31.90-1 Versions of packages evolution suggests: pn evolution-ews ii evolution-plugins-experimental 3.32.2-1 ii gnupg 2.2.12-1 ii network-manager 1.14.6-2 -- debconf information: evolution/needs_shutdown: evolution/kill_processes:
Bug#920158: stterm: Crash when displaying emoji
On Tue, 2019-01-29 at 23:56 +0100, Paride Legovini wrote: > I will report it there, unless you want to report it > yourself (see https://suckless.org/community/). Please, go ahead!
Bug#920158: stterm: Crash when displaying emoji
On Thu, 2019-01-24 at 13:17 +0100, Paride Legovini wrote: > Thanks for your report. Unfortunately I can't reproduce the crash (I > actually get an octagonal sign with that printf), so it is difficult > for > me to debug the issue or forward the bug upstream. Thanks for looking into it! Out of curiosity, what fonts do you have installed? When I search for fonts on my system that provide OCTAGONAL SIGN, I only get one match: $ fc-list :charset=0x1F6D1 /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf: Noto Color Emoji:style=Regular (from the fonts-noto-color-emoji package) It looks like st does glyph-scavenging so it can display glyphs that aren't in the selected font; perhaps it's not prepared to handle fonts that provide colour bitmaps. (I notice xterm added glyph-scavenging support in version 338 on 2018- 12-09, and subsequent versions have added various checks and safeguards to avoid colour bitmap fonts rather than support them)
Bug#920158: stterm: Crash when displaying emoji
Package: stterm Version: 0.8.1-2 Severity: important Steps to reproduce: 1. Launch st with the DejaVu Sans Mono font: st -f "DejaVu Sans Mono-10" 2. Run the following command: printf '\xf0\x9f\x9b\x91\n' Expected result: - st displays U+1F6D1 OCTAGONAL SIGN, or some kind of unknown character glyph, or maybe even just a blank space. Actual result: - st crashes, printing an error: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 139 (RENDER) Minor opcode of failed request: 20 (RenderAddGlyphs) Serial number of failed request: 949 Current serial number in output stream: 985 Note that with st's compiled-in default font, whatever it is, it displays a blank space of the appropriate size instead of crashing. I discovered this crash with Noto Sans Mono from the fonts-noto-core package, but I was able to reproduce it with the much more widely available DejaVu Sans Mono. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stterm depends on: ii libc6 2.28-5 ii libfontconfig1 2.13.1-2 ii libfreetype62.9.1-3 ii libx11-62:1.6.7-1 ii libxft2 2.3.2-2 ii ncurses-term6.1+20181013-1 stterm recommends no packages. stterm suggests no packages. -- no debconf information
Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer
On Sat, 2018-12-15 at 11:37 +, Simon McVittie wrote: > On Sat, 15 Dec 2018 at 15:22:18 +1100, Timothy Allen wrote: > > I discovered the "game-data-packager make-template" command; > > attached > > is the output from: > > > > game-data-packager make-template --base xcom-ufo \ > > setup_xcom_ufo_defense_2.0.0.4.exe > > Does openxcom work if you have the SOUND/ROLAND.CAT from > setup_xcom_ufo_defense_2.0.0.4.exe instead of the (much smaller) one > from the current file list, and if you don't have the other files > listed in "assets not in setup_xcom_ufo_defense_2.0.0.4.exe"? I extracted the installer with innoextract, and manually copied the directories listed for Nightly builds in the OpenXcom documentation[1] to the place where OpenXcom looks, and successfully began a new game and played a mission. I don't know how exhaustively OpenXcom checks its datafiles at startup, but it seemed good to me. I'm not sure how to interpret the "assets not in setup_xcom_ufo_defense_2.0.0.4.exe" section. For example, it starts off looking for a file named "GEODATA/BIGLETS.DAT" with an MD5 of 6a2b1... and it's correct that such a file doesn't exist. The setup file's BIGLETS.DAT has an MD5 of 9f20e... and the generated manifest maps that MD5sum to the name "GEODATA/BIGLETS.DAT?orig". In fact, all the "assets not in setup..." other than ROLAND.CAT are all in the "obsolete" group with the "?orig" suffix. [1]: https://www.ufopaedia.org/index.php?title=Installing_(OpenXcom) > Are any of the other files listed in "remaining contents of > setup_xcom_ufo_defense_2.0.0.4.exe" required? If I delete the SOUND/* files and UFOINTRO/* files listed in "remaining contents..." (other than SOUND/ROLAND.CAT) then OpenXcom still works, so I guess they're not required. None of the other "remaining contents..." are mentioned in the OpenXcom docs, so I guess they're irrelevant.
Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer
Package: game-data-packager Version: 61 Severity: normal Dear Maintainer, I bought X-Com: UFO Defense from GOG.com, and downloaded it with "lgogdownloader" (packaged by Debian), producing a file named setup_xcom_ufo_defense_2.0.0.4.exe, with MD5sum 2bf8035e375a2510807dcc27499d5f99. I ran "game-data-packager xcom-ufo /path/to/setup_xcom_ufo_defense_2.0.0.4.exe", the installer files were extracted, and it printed a whole lot of "identifying..." lines, then spat out some errors: [...] identifying /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/SMALLSET.DAT identifying /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/BIGLETS.DAT identifying /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/GERMAN.DAT identifying /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/ENGLISH.DAT identifying /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/GEODATA/FRENCH.DAT [...] WARNING:game_data_packager.build:found possible "sound/roland.cat" but it is not one of the expected versions: file: /tmp/gdptmp.c7gazy7p/tmp/setup_xcom_ufo_defense_2.0.0.4.exe.d/app/SOUND/ROLAND.CAT size: 143866 bytes md5:8421cdcbe91b1b3e4818d470f32ca859 sha1: 14a236be4e16b7040367dea87e25549d6ff290ba sha256: 6d98825b620eedb563f664161f86a391d60a0102c811400382ff1d9685913836 expected: SOUND/ROLAND.CAT: size: 93853 bytes md5:7194c1480e6ce2d3e188133ece4fdefb sha1: None sha256: None ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided GEODATA/BIGLETS.DAT but did not ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided GEODATA/ENGLISH.DAT but did not ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided GEODATA/FRENCH.DAT but did not ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided GEODATA/GERMAN.DAT but did not ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided GEODATA/SMALLSET.DAT but did not ERROR:game_data_packager.build:/home/st/Archives/Game Data/Windows Games/xcom_ufo_defense/setup_xcom_ufo_defense_2.0.0.4.exe should have provided SOUND/ROLAND.CAT but did not ERROR:game_data_packager.build:Unable to complete any packages. I suspect that the GOG installer might already have the OpenXCOM data patch[1] installed, although I can't find any specific statements for or against it. [1]: https://openxcom.org/downloads-extras/ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages game-data-packager depends on: ii dpkg1.19.2 ii fakeroot1.23-1 ii python3 3.6.7-1 ii python3-debian 0.1.33 ii python3-yaml3.13-1 Versions of packages game-data-packager recommends: ii game-data-packager-runtime 61 Versions of packages game-data-packager suggests: pn arj ii binutils 2.31.1-10 ii cabextract 1.9-1 pn cdparanoia pn dynamite ii gcc4:8.2.0-2 ii gdebi 0.9.5.7+nmu2 ii gir1.2-gdkpixbuf-2.0 2.38.0+dfsg-6 ii innoextract1.7-2+b1 pn lgc-pg ii lgogdownloader 3.4-1+b1 pn lhasa | jlha-utils | lzh-archiver ii make 4.2.1-1.2 ii p7zip-full 16.02+dfsg-6 ii python3-gi 3.30.2-1 ii steam 1.0.0.56-1 pn steamcmd pn unace-nonfree ii unar 1.10.1-2+b3 pn unrar pn unshield ii unzip 6.0-21 ii vorbis-tools 1.4.0-10.1 pn xdelta ii xdelta33.0.11-dfsg-1+b1 -- no debconf information
Bug#895578: kakoune: Please update to official release v2018.04.13
Kakoune has just had another official release, v2018.09.04. I'm really looking forward to having those new features without having to build it myself from source. ;)
Bug#895578: kakoune: Please update to official release v2018.04.13
Package: kakoune Version: 0~2016.12.20.1.3a6167ae-1 Severity: wishlist After many years of continuous, undifferentiated development, Kakoune has started tagging particular snapshots as stable releases. It would be great to have a more up-to-date version of Kakoune in Debian! -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages kakoune depends on: ii libboost-regex1.62.0 1.62.0+dfsg-5 ii libc6 2.27-3 ii libgcc1 1:8-20180402-1 ii libncursesw5 6.1-1 ii libstdc++68-20180402-1 ii libtinfo5 6.1-1 kakoune recommends no packages. kakoune suggests no packages. -- no debconf information
Bug#839155: bash: $HOME/.local/bin missing from $PATH again
Adding some context: bug #820856 was marked fixed in bash-4.3-15, but that version doesn't appear in /usr/share/doc/bash/changelog.Debian.gz for current versions: it skips straight from 4.3-14 to 4.4~beta-1. I presume the -15 release came from some kind of maintenance branch, and the change wasn't merged onto the master branch.
Bug#729950: gnome-settings-daemon: jerky mouse cursor movement since GNOME 3.8 landed
Package: gnome-settings-daemon Version: 3.8.5-2 Severity: normal Yesterday GNOME 3.8 landed in Jessie, and the upgrade has been pretty painless so far (much thanks and congratulations!) but there's one minor thing that's bugging me: my mouse-cursor movement is a lot jerkier than I'm used to. Here's a video I recorded using the new screen-recording feature (~800KB, it plays quite nicely in Iceweasel): https://mediacru.sh/_QdUPxna8n5r Note that as I drag the Nautilus window about, the window movement is silky- smooth, while the cursor lags quite noticeably. This behaviour has survived across several logins and reboots. I have tried disabling all my gnome-shell extensions. The cursor works beautifully as I expect it to on the GNOME 3.8 login screen, "GNOME Flashback" (whether the Metacity compositing mode is enabled or not) and Enlightenment 17; the cursor moves sluggishly as described under the "GNOME" and "GNOME Classic" sessions. I filed this bug against gnome-settings-daemon because I discovered https://bugzilla.gnome.org/show_bug.cgi?id=694758 which implies that gnome- settings-daemon now does some magic cursor manipulation. However, I disabled org.gnome.settings-daemon.plugins.cursor.active, logged out and logged back in, and the laggy cursor still persists. I'm not sure how relevant this information is, but I started with the linux 3.10 package in Testing, and have just now tried updating to the 3.11 package from Unstable (no change). I'm using a Kensington Expert Mouse (despite the name, it's a USB trackball), and the xserver-xorg-video-intel driver (again, the latest in unstable). This is a desktop PC, so there's no trackpad or touch- screen involved. Is there any more information I could provide that would be helpful? Is there a more appropriate place I should be asking for help? Thanks in advance for your attention. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-settings-daemon depends on: ii dconf-gsettings-backend [gsettings-backend] 0.18.0-1 ii gsettings-desktop-schemas3.8.2-2 ii libc62.17-93 ii libcairo21.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libcolord1 1.0.2-1 ii libcups2 1.6.3-1 ii libfontconfig1 2.11.0-1 ii libgdk-pixbuf2.0-0 2.28.2-1 ii libglib2.0-0 2.36.4-1 ii libgnome-desktop-3-7 3.8.4-2 ii libgtk-3-0 3.8.4-1 ii libgudev-1.0-0 204-5 ii libibus-1.0-51.5.3-7 ii liblcms2-2 2.2+git20110628-2.3 ii libnotify4 0.7.6-1 ii libpackagekit-glib2-16 0.8.12-1 ii libpango-1.0-0 1.36.0-1 ii libpulse-mainloop-glib0 4.0-6+b1 ii libpulse04.0-6+b1 ii librsvg2-2 2.40.0-1 ii libupower-glib1 0.9.23-2 ii libwacom20.8-1 ii libx11-6 2:1.6.2-1 ii libxfixes3 1:5.0.1-1 ii libxi6 2:1.7.2-1 ii libxkbfile1 1:1.0.8-1 ii libxtst6 2:1.2.2-1 ii nautilus-data3.8.2-2 ii systemd 204-5 Versions of packages gnome-settings-daemon recommends: ii pulseaudio 4.0-6+b1 Versions of packages gnome-settings-daemon suggests: ii e17 [x-window-manager] 0.17.3-2 ii gnome-screensaver3.6.1-1 ii metacity [x-window-manager] 1:2.34.13-1 ii wmaker [x-window-manager]0.95.5-1 ii x11-xserver-utils7.7+1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724629: RFP: fonts-fira -- sans-serif font family released with FirefoxOS
Package: wnpp Severity: wishlist * Package name: fonts-fira Version : 1.0 Upstream Author : Mozilla * URL : https://github.com/mozilla/Fira * License : SIL Open Font Licence Programming Lang: N/A Description : sans-serif font family released with FirefoxOS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680017: [wine-unstable] Can't install wine-unstable
Package: wine-bin-unstable Version: 1.5.7-2 Followup-For: Bug #680017 Dear Maintainer, I'm not sure that this bug-report is exactly the right place to record this failure, but since somebody else has already mention it I figured I'd add some more detail. - I've been running Testing for several months, playing Windows games in Wine quite happily. - To help ensure the best compatibility, I manually installed wine-unstable from unstable, which seems to have given me "wine-unstable 1.5.6-2". - This evening I saw updated packages available, but when apt-get tries to install them, it downloads and unpacks most of them then fails at the configuration step, giving the same output as in the previous comment: $ sudo dpkg --configure --pending Setting up wine-bin-unstable (1.5.7-2) ... update-binfmts: warning: couldn't find information about 'wine' to import update-binfmts: exiting due to previous errors update-alternatives: error: alternative path /usr/bin/wine32-unstable doesn't exist dpkg: error processing wine-bin-unstable (--configure): subprocess installed post-installation script returned error exit status 2 dpkg: dependency problems prevent configuration of wine-unstable: wine-unstable depends on wine-bin-unstable (>= 1.5.7-2) | wine64-bin; however: Package wine-bin-unstable is not configured yet. Package wine64-bin is not installed. dpkg: error processing wine-unstable (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: wine-bin-unstable wine-unstable - I have tried "apt-get remove --purge"-ing all packages matching "*wine*" then re-installing wine-unstable:i386, but I got the same error. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wine-bin-unstable depends on: ii debconf [debconf-2.0] 1.5.49 ii libwine-bin-unstable 1.5.7-2 ii libwine-gecko-1.4 1.4+dfsg1-3 ii x11-utils 7.7~1 ii xbase-clients 1:7.7+2 wine-bin-unstable recommends no packages. Versions of packages wine-bin-unstable suggests: pn libwine-gl-unstable pn libwine-print-unstable -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696591: winetricks: Does not cleanly install on x86_64 anymore
Package: winetricks Version: 0.0+20121030+svn918-1 Severity: important Dear Maintainer, I'm running Debian Testing on x86_64, and since most of the Windows programs I want to run are 32-bit, I've used the new Multi-Arch feature to install a 32-bit version of wine-unstable (following the instructions printed by the 64-bit wine package). I installed winetricks and used it quite happily for some time. Then a few weeks ago, I was updating my system and suddenly there was a snarl of dependencies where apparently I either had to uninstall winetricks or switch from wine-unstable (which is wine 1.5) to wine (which is wine-1.4). Since I didn't need winetricks right at that moment, I chose to uninstall it and forgot about it for a while. This evening I wanted to tinker with Windows apps again, so I tried to re-install Wine, and this is what apt-get told me: The following extra packages will be installed: libfontconfig1:i386 libltdl7:i386 libodbc1:i386 libwine:i386 libwine-bin:i386 libxslt1.1:i386 wine wine-bin:i386 Suggested packages: libmyodbc:i386 odbc-postgresql:i386 tdsodbc:i386 unixodbc-bin:i386 wine-doc:i386 libwine-cms:i386 libwine-sane:i386 libwine-ldap:i386 libwine-print:i386 libwine-openal:i386 libwine-gphoto2:i386 Recommended packages: libgsm1:i386 libv4l-0:i386 ttf-liberation:i386 libwine-gl:i386 libwine-alsa:i386 libwine-oss:i386 The following NEW packages will be installed: libfontconfig1:i386 libltdl7:i386 libodbc1:i386 libwine:i386 libwine-bin:i386 libxslt1.1:i386 wine wine-bin:i386 winetricks 0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded. Need to get 224 kB/21.4 MB of archives. After this operation, 102 MB of additional disk space will be used. Do you want to continue [Y/n]? Since I already have wine-unstable installed and working nicely, I don't really want to install all that extra stuff. My Debian-fu isn't strong enough to figure out exactly why apt-get wants to install those things, but here's some things that seem to me to be relevant: - I mentioned that the original dependency snarl happened "a few weeks ago", I don't remember the exact date, but I see that about six weeks ago a new version of the winetricks package migrated from unstable to testing[1], and the main change was a simplification of the "Depends" metadata[2]. - "apt-cache show winetricks" tells me that the winetricks package has "Architecture: all", and the only documentation I can find on multi-arch[3] says: "To avoid breaking this assumption, Architecture: all packages will, at least initially, be treated as equivalent to packages of the native architecture for all dependency resolution." I wonder if apt-get is ignoring my installed wine-unstable because it's not the native architecture, although that wouldn't explain why it wants to install a different package from a non-native architecture instead. I'm not completely convinced that this is a problem specific to winetricks (it might possibly be a corner-case in multi-arch support that apt/dpkg don't yet handle), but I figured I should let *somebody* know! Thanks for maintaining the useful winetricks package! [1]: http://packages.qa.debian.org/w/winetricks.html [2]: http://packages.qa.debian.org/w/winetricks/news/20121102T163239Z.html [3]: https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages winetricks depends on: ii cabextract 1.4-3 ii p7zip 9.20.1~dfsg.1-4 ii unzip 6.0-8 ii wget 1.13.4-3 ii wine-bin-unstable 1.5.6-2 Versions of packages winetricks recommends: ii gksu 2.0.2-6 ii sudo 1.8.5p2-1 ii xdg-utils 1.1.0~rc1+git20111210-6 ii zenity 3.4.0-2 Versions of packages winetricks suggests: ii wine-unstable 1.5.6-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672474: tinycdb: cdb(1) interprets query keys as potential options
Package: tinycdb Version: 0.77 Severity: normal Steps to reproduce: 1. Create a database for testing purposes: $ printf "+1,1:a->b\n\n" | cdb -c /tmp/test.cdb 2. Querying for a key that exists returns the value, as expected: $ cdb -q -m /tmp/test.cdb "a" b 3. Querying for an alphabetic key that doesn't exist returns nothing, as expected: $ cdb -q -m /tmp/test.cdb "b"; echo "nothing" nothing 4. However, if you query for a key that starts with "-", you get an error message: $ cdb -q -m /tmp/test.cdb "-_-" cdb: invalid option -- '_' cdb: try `cdb -h' for help I would have expected no output, since the key "-_-" doesn't exist in the database. According to the description of "cdb -q" in the manpage, a parameter after the database filename can only be a key to query, so it seems to be a bug that cdb is trying to interpret it as an option. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tinycdb depends on: ii libc62.13-32 ii libcdb1 0.77 tinycdb recommends no packages. tinycdb suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#615922: dash: The "." builtin does not reset the value of $?
Package: dash Version: 0.5.5.1-7.4 Severity: normal Steps to reproduce: $ cat /tmp/test.sh false . /dev/null echo $? $ dash /tmp/test.sh 1 $ bash /tmp/test.sh 0 The only reference I can find to POSIX behaviour of "." says[1]: EXIT STATUS: Returns the value of the last command executed, or a zero exit status if no command is executed. In the above example, no command is executed (since /dev/null is empty) but the resulting exit status is not zero; in fact, it's left-over from the invocation of "false". For the record, "busybox sh" behaves the same way as dash, as does posh. I came across this problem in a script that used "set -e". Here's a slightly less minimal test-case: $ cat /tmp/test2.sh set -e if false; then echo "hello" else . /dev/null fi $ dash /tmp/test2.sh; echo $? 1 The "." builtin is treated as having failed, even though it was the condition of the if statement that set $? to a non-zero value. [1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/dot.html -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dash depends on: ii debianutils 3.4.4 Miscellaneous utilities specific t ii dpkg 1.15.8.10 Debian package management system ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib dash recommends no packages. dash suggests no packages. -- debconf information: * dash/sh: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568522: Valid client certificates fail with GNUTLS slapd
Hi Apologies for the late reply; I don't seem to have received Sunday or Monday's emails. Initial testing with the new version indicates the problem does seem to have been resolved. Many thanks, tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568522: Valid client certificates fail with GNUTLS slapd
Incidentally, I have reproduced the problem against the version of slapd in unstable. This is how the client connection was invoked: ldap3:~# cat .ldaprc TLS_CACERT /etc/ssl/certs/ca-certificates.crt TLS_CERT/root/ldap3.crt TLS_KEY /root/ldap3.key TLS_REQCERT demand ldap3:~# ldapwhoami -ZZH ldap://ldap3.xxx/ -Y EXTERNAL SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568522: Valid client certificates fail with GNUTLS slapd
Package: slapd Version: 2.4.11-1+lenny1 Severity: important I am in the process of replacing expiring client certificates for use with SASL/EXTERNAL. Unfortunately every certificate I have generated (including commerical certificates) has failed when connecting to the slapd server, with the following error: SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) (The server gives an "unable to get TLS client DN" error.) When building OpenLDAP linked against OpenSSL, the problem disappears. There is also no problem when using the certificates to make a connection between gnutls-cli and gnutls-serv. The certificates also work when used as server certificates in GNUTLS-linked slapd. The only time the certificates do not work is as client certificates connecting to a GNUTLS-linked slapd server. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages slapd depends on: ii adduser 3.110 add and remove users and groups ii coreutils 6.10-6 The GNU core utilities ii debconf [debconf- 1.5.24 Debian configuration management sy ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libdb4.2 4.2.52+dfsg-5 Berkeley v4.2 Database Libraries [ ii libgnutls26 2.4.2-6+lenny2 the GNU TLS library - runtime libr ii libldap-2.4-2 2.4.11-1+lenny1OpenLDAP libraries ii libltdl3 1.5.26-4+lenny1A system independent dlopen wrappe ii libperl5.10 5.10.0-19lenny2Shared Perl library ii libsasl2-22.1.22.dfsg1-23+lenny1 Cyrus SASL - authentication abstra ii libslp1 1.2.1-7.5 OpenSLP libraries ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra ii perl [libmime-bas 5.10.0-19lenny2Larry Wall's Practical Extraction ii psmisc22.6-1 Utilities that use the proc filesy ii unixodbc 2.2.11-16 ODBC tools libraries Versions of packages slapd recommends: ii libsasl2-modules 2.1.22.dfsg1-23+lenny1 Cyrus SASL - pluggable authenticat Versions of packages slapd suggests: ii ldap-utils 2.4.11-1+lenny1 OpenLDAP utilities -- debconf information: slapd/password2: (password omitted) slapd/internal/adminpw: (password omitted) slapd/password1: (password omitted) slapd/allow_ldap_v2: false slapd/password_mismatch: slapd/tlsciphersuite: slapd/suffix_change: false slapd/invalid_config: true shared/organization: maths.ox.ac.uk slapd/dump_database_destdir: /var/backups/slapd-VERSION slapd/upgrade_slapcat_failure: slapd/slurpd_obsolete: slapd/purge_database: false slapd/domain: maths.ox.ac.uk slapd/backend: HDB slapd/no_configuration: false slapd/move_old_database: true slapd/dump_database: when needed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539108: bdf2psf does not handle empty bitmaps
Apologies for the questions in my previous mail, I wasn't thinking
properly.
In the interests of Science, I tried the same experiment on another
computer I have, running Ubuntu 9.10. For some reason, the only
version of bdf2psf in the Ubuntu archives is "1.34ubuntu4", which is
older than the original Debian version I tested with - and yet, the
Ubuntu version works fine: it produces PSF files with empty U+0020
glyphs. I checked the Ubuntu patches linked from
http://packages.qa.debian.org/c/console-setup.html, and it seems Ubuntu
doesn't have any special patches applied to bdf2psf.
I also note that since I filed this bug, Testing has received an
updated version of bdf2psf, version 1.49. Sadly, this behaves exactly
the same as the the version I filed this bug with, 1.44.
I tried copying the 1.34 version to my Debian machine and running it
there, and it still produced a properly working PSF file. So, some
change between 1.34 and 1.44 seems to have broken handling of
degenerate glyphs.
Although I don't know Perl, I spotted a likely-looking change in the
difference between those two versions, and when I apply the attached
patch to a copy of bdf2psf from 1.49, the patched version works
properly.
As a (presumably unrelated) aside, while I investigated the above I was
trying to keep track of which versions of bdf2psf produced which PSF
files, and discovered to my dismay that every run of bdf2psf produces
different output, even using the same version with the same input files
on the same machine. Diffing the binary files, it seems that the
segment from 0x0A05 to 0x0D04 (inclusive) changes all the time - I'm
not sure what's stored there, but it's obviously quite volatile. I
can't see any provision in the PSF file format for a 'creation' time
stamp, so I doubt it's that, and since bdf2psf isn't written in C, it's
unlikely to be un-initialised memory. --- /usr/bin/bdf2psf 2009-11-20 23:56:56.0 +1100
+++ bdf2psf-debian 2009-11-28 21:39:39.0 +1100
@@ -376,25 +376,23 @@
next;
}
if (/^ENDCHAR/) {
- if ($rows > 0) {
- $rows == $height - ($beforebox + $afterbox) / matrix_row_size ()
- or die ("$0: $bdf: invalid number of rows $rows "
- ."at line $current_line\n");
- if ($u == -123456) {
- die ("$0: $bdf: missing ENCODING before ENDCHAR "
- ."at line $current_line\n");
+ $rows == $height - ($beforebox + $afterbox) / matrix_row_size ()
+ or die ("$0: $bdf: invalid number of rows $rows "
+ ."at line $current_line\n");
+ if ($u == -123456) {
+ die ("$0: $bdf: missing ENCODING before ENDCHAR "
+ ."at line $current_line\n");
+ }
+ if (! defined $gliphs{$u}) {
+ if ($beforebox < 0) {
+ @gliph_bytes = @gliph_bytes[-$beforebox..$#gliph_bytes];
}
- if (! defined $gliphs{$u}) {
- if ($beforebox < 0) {
- @gliph_bytes = @gliph_bytes[-$beforebox..$#gliph_bytes];
- }
- if ($afterbox < 0) {
- @gliph_bytes = @gliph_bytes[0 .. $#gliph_bytes+$afterbox];
- }
- $gliphs{$u} = [ (0) x $beforebox,
-@gliph_bytes,
-(0) x $afterbox];
+ if ($afterbox < 0) {
+ @gliph_bytes = @gliph_bytes[0 .. $#gliph_bytes+$afterbox];
}
+ $gliphs{$u} = [ (0) x $beforebox,
+@gliph_bytes,
+(0) x $afterbox];
}
}
if (/^ENDFONT$/) {
Bug#552108: vim-runtime: sh syntax highlighting should default to POSIX.
Package: vim-nox Version: 2:7.2.245-2 Severity: wishlist I'm aware that the issue of Vim's shell-script syntax-highlighting defaults have been a hot issue on the vim-dev mailing-list, spawning long and involved threads such as these: http://thread.gmane.org/gmane.editors.vim.devel/19923 http://thread.gmane.org/gmane.editors.vim.devel/19018/focus=19038 In Debian bug 361177, sh.vim learned a g:is_posix configuration value, and the current sh.vim documentation states: If there's no "#! ..." line, and the user hasn't availed himself/herself of a default sh.vim syntax setting as just shown, then syntax/sh.vim will assume the Bourne shell syntax. No need to quote RFCs or market penetration statistics in error reports, please -- just select the default version of the sh your system uses in your <.vimrc>. Reading through the threads above, it seems one of the major reasons contributing to upstream defaulting to classic Bourne syntax is that many people use Vim on systems with a classic Bourne /bin/sh for legacy reasons. This seems quite reasonable, however Debian is not such a system. I could "just select the default version of sh my system uses in my .vimrc", but since every Debian user has a POSIX /bin/sh, it makes sense that the Debian vim package should be configured appropriately out-of-the-box. Adding this to $VIMRUNTIME/debian.vim along with the other Debian-integration customizations should do the trick nicely: let g:is_posix = 1 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vim-nox depends on: ii libacl1 2.2.48-1 Access control list shared library ii libc6 2.9-25 GNU C Library: Shared libraries ii libgpm2 1.20.4-3.2 General Purpose Mouse - shared lib ii libncurses5 5.7+20090803-2 shared libraries for terminal hand ii libperl5.10 5.10.1-5 Shared Perl library ii libruby1.81.8.7.174-2Libraries necessary to run Ruby 1. ii libselinux1 2.0.85-4 SELinux runtime shared libraries ii python2.5 2.5.4-2An interactive high-level object-o ii tcl8.48.4.19-4 Tcl (the Tool Command Language) v8 ii vim-common2:7.2.245-2Vi IMproved - Common files ii vim-runtime 2:7.2.245-2Vi IMproved - Runtime files vim-nox recommends no packages. Versions of packages vim-nox suggests: pn cscope (no description available) pn vim-doc(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#324276: bzflag-server: bzflag cannot join the local bzfs server
Package: bzflag-server Version: 2.0.2.20050318-0.1 Severity: normal When running the latest bzflag and bzflag-server, bzflag refuses to join a server running on localhost. The error it gives is: Error unpacking world database. The problem does not seem to occur when joining remote servers (I did not test this extensively). It also does not happen with the previous version of bzflag-server (2.0.2.20050318). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages bzflag-server depends on: ii libadns1 1.0-8.3Asynchronous-capable DNS client li ii libc6 2.3.5-4GNU C Library: Shared libraries an ii libcurl3 7.14.0-5 Multi-protocol file transfer libra ii libgcc1 1:4.0.1-5 GCC support library ii libidn11 0.5.18-1 GNU libidn library, implementation ii libncurses5 5.4-9 Shared libraries for terminal hand ii libssl0.9.7 0.9.7g-1 SSL shared libraries ii libstdc++64.0.1-5The GNU Standard C++ Library v3 ii zlib1g1:1.2.3-3 compression library - runtime bzflag-server recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
